Versionshinweise zur Sun Java Communications Suite 5

Neuheiten in dieser Version von Calendar Server

Calendar Server 6.3 umfasst die folgenden Änderungen und neuen Funktionen:

Calendar Server-Unterstützung in der Delegated Administrator-Konsole

In der Vergangenheit konnte Calendar Server für Schema 2 mithilfe des Delegated Administrator-Dienstprogramms bereitgestellt werden, nicht jedoch über die Delegated Administrator-Konsole. Vor dieser Version diente die Konsole ausschließlich als grafische Weboberfläche für die Verwaltung von Messaging Server. Jetzt kann die Konsole auch zur Verwaltung von LDAP-Einträgen für Calendar Server verwendet werden. Über die Konsole können Sie LDAP-Einträge für Calendar-Benutzer, -Gruppen, -Ressourcen und Domänen hinzufügen, entfernen oder bearbeiten. Der Konsole wurden zur Unterstützung von Calendar Server neue Bildschirme und Menüelemente hinzugefügt. Anweisungen zur Verwendung der Benutzeroberfläche finden Sie in der Onlinehilfe von Delegated Administrator. Weitere Informationen finden Sie auch im Sun Java System Calendar Server 6.3 Administration Guide.

WCAP-Anlagenunterstützung in Calendar Server 6.3

Durch das Hinzufügen neuer Parameter und Werte bieten die WCAP-Befehle ab sofort Unterstützung für Anlagen.

Benutzer von Universal Web Client (Communications Express) und Connector für Microsoft Outlook können ihren Ereignissen und Aufgaben Anlagen hinzufügen und Anlagen mit Einladungen versenden.

Im Rahmen der Anlagenunterstützung wurden die folgenden Änderungen an WCAP vorgenommen:

fetchattachment.wcap: Es wurde ein neuer Befehl für den Abruf von Anlagen hinzugefügt. Hierbei wird nur die Anlage abgerufen, nicht der Termin oder die Aufgabe selbst.
deleteattach: Es wurde ein neues Argument für den Befehl storeevents hinzugefügt, mit dem vorhandene Anlagen aus einem Termin oder einer Aufgabe gelöscht werden können, ohne den Termin bzw. die Aufgabe selbst zu löschen.
fetchattach : Es wurde allen fetch_by_*-Befehlen ein neuer Parameter hinzugefügt, damit sowohl Anlagen als auch die Termin- und Aufgabendaten selbst zurückgegeben werden können.
sendattach : Ein neuer Parameter für den Befehl storeevents, mit dem festgelegt werden kann, ob die Anlage mit der iTIP-Einladung gesendet werden soll oder nicht.
X-S1CS-CLIENT-ATTACH-ID : Ein X-Token mit der eindeutigen ID für die Anlage. Dieses X-Token wird nur dann ausgegeben, wenn der Client die Anlagen-ID beim Speichern der Anlage bereitgestellt hat. Anderenfalls wird die eigentliche Anlage mit dem Termin gesendet.
Das verworfene zu den Befehlen storeevents und storetodos gehörende Argument attachments kann URL-Verweise zu Anlagen außerhalb des Datenspeichers von Calendar Server speichern. Diese Methode der Anlagenverwendung kann für die Rückwärtskompatibilität in dieser Version verwendet werden. In Distributionen folgender Versionen ist sie jedoch nicht mehr enthalten.

Weitere Informationen zu Anlagen finden Sie im Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

Unterstützung für LDAP-Gruppen in Calendar Server 6.3

Es ist ab sofort möglich, mithilfe von Delegated Administrator LDAP-Gruppen zu erstellen. Gruppen weisen die folgende Funktionalität auf:

Eine Gruppe ist eine Liste von Benutzern. Die Gruppe "beinhaltet" nicht die aufgeführten Benutzer. Es handelt sich nicht um einen Container.
Es kann ein Gruppenkalender für eine Gruppe vorhanden sein.
An eine Gruppe gesendete Einladungen werden in den Kalendern aller Mitglieder sowie im Gruppenkalender angezeigt.
Alle Mitglieder der Gruppe haben die gleichen Zugriffsrechte in Bezug auf den Gruppenkalender.
Es gibt keinen primären Besitzer für einen Gruppenkalender.

Standardmäßiger Multi-Domänen-Modus in Calendar Server 6.3

In früheren Versionen der Calendar Server-Software war keine Domänenstruktur vorhanden. Auf sämtliche Benutzer- und Gruppen-LDAP-Datensätze konnte nur über den Root zugegriffen werden. In darauf folgenden Versionen konnte zwischen der Einrichtung einer oder mehrerer Domänen gewählt werden, die entweder als Host-Domänen oder als virtuelle Domänen bezeichnet wurden. In der Calendar Server 6.3-Software erfolgen alle Installationen im standardmäßigen Multi-Domänen-Modus. Dass heißt, dass mindestens eine Domäne (die Standarddomäne) unter der Root-Domäne vorhanden sein muss. Sämtliche Benutzer- und Gruppen-LDAP-Einträge müssen sich unter dieser Standarddomäne befinden. Sie können wahlweise auch mehrere Domänen auswählen. Im Multi-Domänen-Modus muss jede kanonische Domäne eindeutige Benutzer- und Gruppen-IDs enthalten. Weitere Informationen zu Multi-Domänen finden Sie im Sun Java System Calendar Server 6.3 Administration Guide, insbesondere in Kapitel 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment in Sun Java System Calendar Server 6.3 Administration Guide.

Führen Sie das Konfigurationsprogramm csconfigurator.sh aus, um eine Laufzeitumgebung zu erstellen, und geben Sie in der Eingabeaufforderung den Namen Ihrer Standarddomänen an. Wenn die Domäne nicht vorhanden ist, wird diese vom Programm automatisch erstellt.

Wurden in der vorherigen Calendar Server-Bereitstellung nicht mehrere Domänen oder sogar gar keine Domänen verwendet, müssen Sie die Benutzer- und Gruppen-LDAP-Datensätze in die neue Standarddomäne verschieben.

Um zusätzliche Domänen in einer Schema 2-Umgebung zu erstellen, verwenden Sie Sun Java System Delegated Administrator Console oder Utility. Weitere Informationen zu Delegated Administrator finden Sie im Sun Java System Delegated Administrator 6.4 Administration Guide.

Wenn Sie Schema 1 verwenden, und Sie nicht auf Schema 2 migirieren, können Sie mit dem Calendar Server-Dienstprogramm csdomain weitere Domänen erstellen.

Erweiterung des Konfigurationsprogramms von Calendar Server 6.3

Dem Konfigurationsprogramm wurden Bildschirme für folgende Aufgaben hinzugefügt:

Erstellen einer LDAP-Standarddomäne

Beginnend mit dieser Version ist unter Root mindestens eine Domäne vorhanden. Diese wird als Standarddomäne festgelegt. Sie können ab sofort den Namen der Standarddomäne für Ihre Multi-Domänen-Umgebung im Konfigurationsprogramm festlegen.

Unterstützung für verteilte Calendar Server-Datenbanken

Sie können jetzt die Namen der Front-End- und Back-End-Computer für Ihre verteilte Datenbankumgebung festlegen, die das DWP-Protokoll und das CLD-Plugin verwenden. Die Kalenderdatenbanken können über eine oder mehrere Back-End-Computer verteilt werden. Diese Computer können mit einem Front-End-Computer verknüpft werden. Die neuen Bildschirme des Konfigurationsprogramms können zur Benennung der Back-End-Computer sowie zur Verknüpfung derselben mit dem Front-End-Computer eingesetzt werden.

Neues E-Mail-Adressfeld im Konfigurations-Assistenten

Dem Bildschirm für die Standarddomäne wurde ein neues Feld für die E-Mail-Adresse des Superusers von Calendar Server (calmaster) hinzugefügt.

Seriendetails in E-Mail-Einladungen in Calendar Server 6.3

Für wiederkehrende Ereignisse enthalten an Teilnehmer gesendete E-Mail-Einladungen jetzt Seriendetails.

csstored in Calendar Server 6.3 jetzt ein erforderlicher Prozess

Der Daemon csstored verwaltet ab sofort die verschiedenen Calendar Server-Datenbanken. Da jeder Dienst mit Zugriff auf den Speicher von einem erfolgreichen Start dieses Speicherdienstes abhängt, sollte dieser auf allen Servern (sowohl Front-End als auch Back-End) ausgeführt bleiben, solange das Calendar Server-System ausgeführt wird. Die regulären Befehle zum Starten und Herunterfahren, start-cal und stop-cal, starten und beenden csstored zusammen mit anderen Daemons.

In früheren Versionen war, sofern keine automatischen Sicherungen konfiguriert waren, die Ausführung des PERL-Skripts csstored.pl nicht erforderlich. Das Skript konnte nach eigenem Ermessen gestartet und angehalten werden. Das PERL-Skript wurde zugunsten des Daemons csstored verworfen. Die Ausführung dieses Daemons ist nicht länger optional, unabhängig davon, ob automatische Sicherungen konfiguriert werden oder nicht.

Zuvor konnte das Skript durch Setzen des ics.conf-Parameters local.store.enable auf "no" deaktiviert werden. Jetzt muss csstored jedoch immer aktiviert sein. Die Standardeinstellung des Parameters local.store.enable lautet daher nun "yes".

Automatischer Neustart von Kalenderdiensten mit Watcher

Calendar Server und Messaging Server verwenden ab sofort denselben Mechanismus für das Starten und Anhalten. Mit dem Befehl start-cal wird der watcher-Prozess und anschließend alle weiteren Prozesse gestartet. Der watcher-Prozess erkennt Abhängigkeiten der weiteren Dienste und ermittelt, in welcher Reihenfolge die Dienste gestartet werden sollten.

Jeder registrierte Dienst (Prozess) öffnet eine Verbindung zum Watcher. Wenn ein Prozess ohne ordnungsgemäßen Verbindungsabbau endet, wird er über den Watcher neu gestartet. Wird der Prozess innerhalb einer festgelegten Zeitspanne zweimal beendet, führt der Watcher keinen Neustart durch. Dieser Zeitüberschreitungswert ist konfigurierbar.

Zusätzliche Informationen zum Watcher:

Vom Watcher überwachte Calendar Server-Dienste

Der Watcher überwacht alle für ihn registrierten Dienste. Für Calendar Server lauten die registrierten Prozesse folgendermaßen: cshttpd, csadmind , csdwpd, csnotifyd und csstored.

Der Daemon csstored muss aktiviert sein. Legen Sie hierzu den Konfigurationsparameter local.store.enable auf "y" fest. Die Aktivierung von csstored war in der vorherigen Version von Calendar Server optional, ab sofort ist sie jedoch erforderlich. Der Daemon csstored muss erfolgreich gestartet worden sein, damit auf den Speicher zugreifende Dienste gestartet werden können. Wenn der Speicher angehalten wird, müssen die abhängigen Prozesse ebenfalls angehalten und wieder neu gestartet werden.

Watcher-Konfiguration in Calendar Server 6.3

Der Watcher ist per Voreinstellung aktiviert. Zur Verwaltung des Watcher-Prozesses wurden der Datei ics.conf neue Parameter hinzugefügt:

local.watcher.enable = "y": Das Startprogramm (csservice) versucht, den Watcher vor jedem anderen Dienst zu starten. Wenn dieser Parameter auf "n" gesetzt ist, ist das Watcher-Programm deaktiviert.
service.autorestart = "y": Der Watcher startet angehaltene Prozesse automatisch neu. Wenn Sie diesen Parameter auf "n" setzen, startet der Watcher angehaltene Prozesse nicht neu. Wenn dieser Parameter auf "n" ist, überwacht der Watcher weiterhin die Dienste und sendet Meldungen zu Fehlern oder Nichtverfügbarkeit an die Konsole und die Datei cal-svr-base/data/log.
local.autorestart.timeout = "600": Die standardmäßige Zeitspanne, nach der ein zweiter Serverfehler den Watcher veranlasst, keinen Neustart mehr durchzuführen.
local.watcher.port: Der Standardport lautet "49994". Da jedoch Messaging Server ebenfalls diesen Port überwacht, kann es zu Konflikten mit Calendar Server kommen, wenn Sie beide Produkte einsetzen. Zur Vermeidung möglicher Probleme sollten Sie für den Watcher einen anderen Port festlegen.

Watcher-Protokollierung in Calendar Server 6.3

Der Watcher schreibt in ein Protokoll, cal-svr-base/data/log/watcher.log, das die folgenden Informationen enthält:

Fehlermeldungen und Meldungen zur Nichtverfügbarkeit, die an die Administratorkonsole gesendet wurden.
Zeichnet sämtliche Start- und Stoppereignisse für den Server auf.

Automatischer Neustart in Hochverfügbarkeitsbereitstellungen in Calendar Server 6.3

Wenn ein Server innerhalb der festgelegten Zeitspanne für die Zeitüberschreitung zweimal ausfällt, versucht das System nicht mehr, den Server neu zu starten. In einem Hochverfügbarkeitssystem wird Calendar Server geschlossen und ein Failover auf das Zweitsystem durchgeführt.

Starten und Stoppen von Calendar Server 6.3 mithilfe von Wrapper-Skripts für csservice

Die öffentlichen Schnittstellen zu csservice sind start-cal und stop-cal. In diesem Abschnitt wird die Verwendung dieser Wrapper-Skripts aufgezeigt und es werden verschiedene Tabellen mit Erläuterungen der Optionen und eine Liste der zu startenden oder zu stoppenden Komponenten bereitgestellt.

Wrapper-Skript start-cal für Calendar Server 6.3

Verwenden Sie start-cal wie folgt:

./start-cal [Optionen...] [Komponenten...]

Es sind folgende Optionen verfügbar:

-? oder --help: Zeigt diese Hilfeliste an.
-d: Aktiviert den Debugging-Modus.
-l: Liste der aktiven Dienste.
-L: Liste der aktivierten Dienste.
-A: Liste aller Dienste.

Im Folgenden sehen Sie eine Liste der Komponenten:

watcher

ens

store

notify

admin

http

dwp

Wenn keine Komponenten aufgeführt werden, startet start-cal alle aktivierten Dienste.

Wrapper-Skript stop-cal für Calendar Server 6.3

Verwenden Sie stop-cal wie folgt:

./stop-cal [Optionen...] [Komponenten...]

Es sind folgende Optionen verfügbar:

-? oder --help: Zeigt diese Hilfeliste an.
-d: Aktiviert den Debugging-Modus.
-f: Erzwungene Beendigung über SIGKILL. (Dies funktioniert nur auf UNIX®-Plattformen.)

Im Folgenden sehen Sie eine Liste der Komponenten:

watcher

mfagent

ens

store

notify

admin

http

dwp

Falls keine Komponenten aufgeführt werden, beendet stop-cal alle aktivierten Dienste.

Integration des Monitoring Framework in Calendar Server 6.3

In diesem Abschnitt wird die Calendar Server-Implementierung des Monitoring Framework beschrieben. Es werden u. a. die folgenden Themen behandelt:

Weitere Informationen zum Java Enterprise System Monitoring Framework finden Sie im Sun Java Enterprise System 5 Monitoring Guide.

Implementierung des Monitoring Framework in Calendar Server

Calendar Server und Messaging Server werden minimal in das Monitoring Framework für Java Enterprise System integriert. Bei Ausführung des Monitoring Framework wird periodisch das Attribut operationalStatus geprüft, das entweder den Status OK (das System wird ausgeführt) oder den Status DOWN (das System wird nicht ausgeführt) aufweisen kann.

Ein neuer Prozess, der Monitoring Framework-Agent (csmfagent), wird beim Start des Systems gestartet (start-cal). Dieser Prozess wird zuerst gestartet. Der Prozess instanziiert eine Anwendung und legt deren Status als OK fest. SIGTERM wird ebenfalls abgefangen, in diesem Fall wird der Status auf DOWN gesetzt, und der Prozess wird beendet.

Ähnlich wird, sofern der Watcher konfiguriert und ausgeführt wird, bei einem Systemfehler oder bei Nichtverfügbarkeit des Systems vom Watcher ein SIGTERM-Signal abgesetzt, wodurch csmfagent beendet wird.

Konfiguration von Calender Server für das Monitoring Framework

Bearbeiten Sie die Konfigurationsdatei ics.conf, sodass diese die folgenden Parameter enthält:

local.csmfagent.enable = "y"

Konfiguration des Monitoring Framework für Calendar Server

Führen Sie die folgenden Schritte aus:

Kopieren Sie /opt/SUNWcsgar/config/com.sun.cmm.cs.xml nach /opt/SUNWmfwk/xml.
Beenden Sie den Manufacturing Framework-Prozess, und starten Sie ihn neu.

Installationsanforderungen für das Monitoring Framework für Calendar Server 6.3

Für die Verwendung des Monitoring Framework gelten zwei Anforderungen:

Das Java Enterprise System Monitoring Framework (JESMF) muss installiert sein.

Falls JESMF nicht installiert ist, kann csmfagent nicht ausgeführt werden.
Calendar Server muss die erforderlichen Bibliotheken ermitteln können.

Calendar Server ermittelt die Bibliotheken unter Verwendung symbolischer Links in /opt/SUNWics5/lib.

Dies sind die JESMF-Bibliotheken:

/opt/SUNWmfwk/lib/libMfTransaction.so

/opt/SUNWmfwk/lib/libMfRelations.so

/opt/SUNWmfwk/lib/libMflog4c.so

/opt/SUNWmfwk/lib/libMfMEServer.so

/opt/SUNWmfwk/lib/libmfBeepConnectorServer.so

/opt/SUNWmfwk/lib/libMfRserver.so

/opt/SUNWmfwk/lib/libMfMEInstrum.so

/opt/SUNWmfwk/lib/libMfDiscovery.so

/opt/SUNWmfwk/lib/libMfHashTable.so

/opt/SUNWmfwk/lib/libMflog.so

/opt/SUNWmfwk/lib/libasn1cebuf.so

/opt/SUNWmfwk/lib/libbeepcore.so

/opt/SUNWmfwk/lib/libbeepxmlutil.so

/opt/SUNWmfwk/lib/libbptostransport.so

/opt/SUNWmfwk/lib/libbptosutil.so

/opt/SUNWmfwk/lib/libbptoswrapper.so

/opt/SUNWmfwk/lib/libbputil.so

/opt/SUNWmfwk/lib/libcmm_native.so

/opt/SUNWmfwk/lib/libmfCserver.so

/opt/SUNWmfwk/lib/libmfNotificationProfile.so

/opt/SUNWmfwk/lib/libmfRequestResponseProfile.so

/opt/SUNWmfwk/lib/libmfTimers.so

/opt/SUNWmfwk/lib/libmfTimersJNI.so

/opt/SUNWmfwk/lib/libmfUtils.so

/opt/SUNWmfwk/lib/libmfber.so

/opt/SUNWmfwk/lib/libmfberj.so

/opt/SUNWmfwk/lib/libxmlglobal.so

Hinweis –

In der Liste werden alle JESMF-Bibliotheken aufgeführt. Möglicherweise sind nicht alle diese Bibliotheken zur Implementierung der Calendar Server-Partition des Monitoring Framework erforderlich.

Übergang auf Message Queue für Benachrichtigungsdienste von Calendar Server

In dieser Version stehen zwei Benachrichtigungsdienste für Ereignisbenachrichtigung und Alarme zur Verfügung: Sun Java System Message Queue (JMQ) und das Event Notification System (ENS). Für eine künftige Version der Kommunikationsdienste ist die ausschließliche Unterstützung von JMQ geplant, die Unterstützung von ENS soll eingestellt werden. Die vorliegende Version der Kommunikationsdienste (Messaging Server, Calendar Server und Instant Messaging) basiert jedoch weiterhin auf ENS, und Sie können ENS weiterhin für Benachrichtigungen und Alarme einsetzen.

Wenn Sie anstelle von ENS lieber JMQ verwenden möchten, müssen Sie Sun Java System Message Queue installieren und konfigurieren. Zudem müssen Sie Ihre Benachrichtigungen selbst schreiben, da von Calendar Server 6.3 keine bereitgestellt werden.

Installieren Sie das Produkt unter Verwendung des Sun Java Enterprise System-Installationsprogramms. Informationen zur Installation von Message Queue finden Sie in der Message Queue-Dokumentation.

Calendar Server-Konfigurationsparameter für JMQ

Zur Konfiguration von Calendar Server für JMQ müssen Sie der Datei ics.conf die folgenden Zeilen hinzufügen:

local.server.csmfagent.enable = "yes"

caldb.serveralarms.jmqlib = "/opt/SUNWics5/cal/lib/libmqcrt.so" (für Solaris)

Alternative:

caldb.serveralarms.jmqlib = "/opt/sun/calendar/lib/libmqcrt.so" (für Linux)

caldb.serveralarms.dispatchtype = "jmq"

caldb.serveralarms.jmqhost = "localhost"

caldb.serveralarms.jmqport = "7676"

caldb.serveralarms.jmqUser = "guest"

caldb.serveralarms.jmqPWD = "guest"

caldb.serveralarms.jmqTopic = "JES-CS"

Message Queue-Eigenschaften der Aktualisierungsbenachrichtigung für Calendar Server 6.3

Jede Nachricht muss die folgende Eigenschaft aufweisen: MQ_MESSAGE_TYPE_HEADER_PROPERTY . Über diese Eigenschaft wird die Art der Benachrichtigung identifiziert.

Darüber hinaus können Benachrichtigungen weitere Eigenschaften aufweisen, wie in der folgenden Tabelle gezeigt:

action: Eine Zeichenfolge, die den über diese Nachricht erzeugten Aktionstyp angibt. Diese Eigenschaft kann folgende Werte annehmen: "EMAIL", "AUDIO", "DISPLAY", "PROCEDURE", "FLASHING".
aid: Eine Zeichenfolge mit der Alarm-ID.
calid: Eine Zeichenfolge mit der Kalender-ID.
comptype: Eine Zeichenfolge, die den Komponententyp angibt. Dieser Wert lautet entweder "event" oder "todo".
rid: Eine Ganzzahl mit der Serien-ID.
uid: Eine Zeichenfolge mit der Komponenten-ID, die entweder die event-ID (Termin-ID) oder die todo-ID angibt (Aufgaben-ID).

Message Queue-Werte der Aktualisierungsbenachrichtigung für Calendar Server 6.3

Es gibt zwei Benachrichtigungstypen: Alarm- und Aktualisierungsbenachrichtigungen für Ereignisse und Aufgaben.

Für Alarmbenachrichtigungen lautet der Wert von MQ_MESSAGE_TYPE_HEADER_PROPERTY einfach "alarm".

Für Aktualisierungsbenachrichtigungen richtet sich der Wert von MQ_MESSAGE_TYPE_HEADER_PROPERTY nach dem Typ der Aktion, die mit der Benachrichtigung ausgelöst wird. Tabelle 2–2 führt die auslösenden Aktionen und die zugehörigen Werte für diese Eigenschaft auf.

Tabelle 2–2 Werte für die Aktualisierungsbenachrichtigung


Auslöser	Wert für die Aktualisierungsbenachrichtigung
Löschen eines Kalenders	`DELETECAL`
Ändern eines Ereignisses	`MODIFYEVENT`
Ändern einer Aufgabe	`MODIFYTODO`
Erstellen eines Ereignisses	`CREATEEVENT`
Erstellen einer Aufgabe	`CREATETODO`
Aktualisieren eines Ereignisses	`REFRESHEVENT`
Aktualisieren einer Aufgabe	`REFRESHTODO`
Antwort auf ein Ereignis	`REPLYEVENT`
Antwort auf eine Aufgabe	`REPLYTODO`

Ereignisorganisatoren empfangen Antwortbenachrichtigungen per E-Mail in Calendar Server 6.3

Es ist ab sofort möglich, E-Mail-Benachrichtigungen an Organisierer zu senden, wenn Teilnehmer auf eine Einladung antworten.

Sie konfigurieren diese Funktion, indem Sie den ics.conf-Parameter ine.reply.enable setzen. Mit "y" wird die Funktion für das gesamte System aktiviert. Mit "n" wird die Funktion deaktiviert. Die Funktion ist per Voreinstellung aktiviert.

Die drei Antworttypen lauten: accept, decline, tentatively accept. Die Benachrichtigung gibt an, ob die Antwort auf eine einzelne Einladung oder ein wiederkehrendes Ereignis erfolgt. Es wurden die folgenden neuen Nachrichtenformat-Dateiparameter hinzugefügt: Ebenfalls hinzugefügt wurden die folgenden entsprechenden Formatdateien:

calmail.imipeventacceptnotification.fname= "mail_eventacceptnotification.fmt"
calmail.imipeventdeclinenotification.fname= "mail_eventdeclinenotification.fmt"
calmail.imipeventtentativeacceptnotification.fname= "mail_eventtentativeacceptnotification.fmt"
calmail.imipeventacceptnotificationrecur.fname= "mail_eventacceptnotificationrecur.fmt"
calmail.imipeventdeclinenotificationrecur.fname= "mail_eventdeclinenotificationrecur.fmt"
calmail.imipeventtentativeacceptnotificationrecur.fname= "mail_eventtentativeacceptnotificationrecur.fmt"

Hinweis –

Bei dieser Funktion handelt es sich nicht um eine Benutzereinstellung, sondern um einen systemweiten Konfigurationsparameter, der auf alle Benutzer angewendet wird, die Einladungen versenden.

Weitere Informationen zur Konfiguration von Calendar Server für die E-Mail-Benachrichtigung finden Sie im Abschnitt To Enable Email Notifications in Sun Java System Calendar Server 6.3 Administration Guide.

Teilnehmer können ihre Ereigniskopien bearbeiten

Über die WCAP-Schnittstelle können ab sofort Teilnehmer Kopien von Kalenderereignissen bearbeiten, die Felder "Zusammenfassung" und "Beschreibung" eingeschlossen.

Erweiterung des Dienstprogramms für die Umbenennung

Das Dienstprogramm rename in Calendar Server 6.3 enthält gelöschte Elemente, wenn Kalenderinformationen umbenannt werden.

Geänderte Frei/Gebucht-Berechnung in Calendar Server 6.3

Abgelehnte Ereignisse erscheinen im Frei/Gebucht-Kalender nicht länger als belegte Zeiten.

Deaktivierung der alten Calendar Express-Benutzeroberfläche in Calendar Server 6.3

Bei früheren Versionen von Calendar Server wurde Calendar Express (die alte Benutzeroberfläche) automatisch installiert und aktiviert. Deaktivieren Sie dieses nicht, selbst wenn Sie die Benutzeroberfläche nicht verwenden. Wenn Sie ein Upgrade von einer früheren Version von Calendar Server auf Calendar Server 6.3 durchführen, wird bei der Aktualisierung service.http.ui.enable="y" der Datei ics.conf hinzugefügt. Auf diese Weise kann die alte Benutzeroberfläche weiterhin unverändert eingesetzt werden.

Zur Deaktivierung von Calendar Express geben Sie für service.http.ui.enable den Wert "n" in der Datei ics.conf an.

Keine automatische Installation der Calendar Express-Benutzeroberfläche in Calendar Server 6.3

Calendar Express wird bei einer Neuinstallation nicht automatisch installiert. Wenn Sie Calendar Server 6.3 neu installieren, jedoch Calendar Express als Benutzeroberfläche verwenden möchten, müssen Sie dies ausdrücklich mit dem Communications Suite 5-Installationsprogramm installieren. Anschließend müssen Sie diese konfigurieren, indem Sie service.http.ui.enable="y" zur Datei ics.conf hinzufügen. (Die Standardeinstellung bei der Neuinstallation lautet "n". Setzen Sie diesen Wert auf "y".)

Wenn Sie ein Upgrade von einer früheren Version von Calendar Server durchführen, wird bei der Aktualisierung dieser Parameter der Datei ics.conf hinzugefügt und auf "y" gesetzt. Auf diese Weise kann die Legacy-Benutzeroberfläche weiterhin unverändert eingesetzt werden. Wenn Sie die alte Benutzeroberfläche jedoch deaktivieren möchten, setzen Sie den Parameter auf "n".

Installation auf gemischten Hardwareplattformen

In der Vergangenheit war es für verteilte Datenbankumgebungen (DWP mit CLD-Plugin) aufgrund von Übersetzungsproblemen von Big-Endian zu Little-Endian-Problemen erforderlich, dass Front-End- und Back-End-Prozesse auf derselben Hardwareplattform installiert werden. Diese Einschränkung gilt ab sofort nicht mehr. Front-End- und Back-End-Prozesse können nun auf unterschiedlichen Hardwareplattformen installiert werden.

Beispielsweise kann als Front-End-Computer ein x86-Rechner verwendet werden und als Back-End ein SPARC-Rechner.

iTIP-Kompatibilität in Calendar Server 6.3

Von Calendar Server gesendete Nachrichten sind nun iTIP-kompatibel (für Interoperabilität mit Microsoft Outlook).

comm_dssetup.pl: Neue Option erhöht für die Passwortdatei die Sicherheit in Calendar Server 6.3

Zur Verbesserung der Sicherheit ist es jetzt möglich, bei Ausführung von comm_dssetup.pl anstelle eines Textpassworts eine Passwortdatei festzulegen. Mit der neuen Option -j <Passwortdateiname> können Sie Passwörter schützen und die Sicherheit erhöhen. Dies ist insbesondere für Skripts von Vorteil. Wenn Sie über Skripts verfügen, die derzeit das Passwort offenlegen, können Sie dies ändern, indem Sie die Option -w < Passwort> löschen und durch die neue Option ersetzen.

Hinweis –

Es handelt sich hierbei um einen Fix für Problem 6392093.

Calendar Server 6.3-Dienstprogramme csdb, cscal und csuser verschoben nach cal/sbin

In früheren Versionen von Calendar Server befanden sich csdb, cscal und csuser im Verzeichnis cal/bin, ab sofort lautet der neue Speicherort jedoch cal/sbin.

SSL-Änderungen an der Datei ics.conf für Calendar Server 6.3

Aufgrund von Änderungen am Calendar Server-Programmcode wurden die folgenden Änderungen an der Datei ics.conf vorgenommen:

service.http.ssl.certdb.path verworfen zugunsten von local.ssldbpath. Der angegebene Pfad sollte auf die Datei config verweisen ("/etc/opt/SUNWics5/ config").
Statt das Passwort für die Zertifikatdatenbank in die Datei ics.conf einzufügen, wird das Passwort jetzt in einer Datei (sslpassword.conf) im Verzeichnis config gespeichert.

Das Format für ein Passwort in dieser Datei lautet folgendermaßen:
```
Internal (Software) Token:Passwort
```