Versionshinweise zur Sun Java Communications Suite 5

Kompatibilitätsprobleme mit Messaging Server

Informationen zum Löschen von Benutzern mit iPlanet Delegated Administrator bei der Ausführung von Messaging Server 6.3 finden Sie unter Löschen von Benutzern mit iPlanet Delegated Administrator und Messaging Server 6.3

In der folgenden Tabelle werden Kompatibilitätsprobleme mit Messaging Server erläutert:

Inkompatibilität	Umgehung	Kommentare
Das Programm `comm_dssetup.pl` zur Vorbereitung des Directory-Servers für Messaging Server (Calendar Server und Delegated Administrator) wurde so geändert, dass es nun mit Directory Server 6.0 und Directory Server 5.x verwendet werden kann: Im interaktiven Modus: Server-Root- und Directory Server-Instanzen	Directory Server-Instanzen befinden sich im Server-Root oder einem expliziten Directory Server-Instanzverzeichnis. In vorherigen Versionen von Directory Server wurde ein Server-Root mit mehreren Instanzen und Konfigurationsinformationen verwendet. Directory Server 6 wird nicht mehr als Server-Root verwendet. Instanzen können in einem beliebigen Verzeichnis gespeichert werden. Dabei muss der Benutzer folgende Schritte ausführen: 1) Das Instanzverzeichnis angeben. Oder, wenn der Benutzer eine Vorgängerversion von Directory Server verwendet: 2) Das Server-Root-Verzeichnis angeben, in dem sich die Instanzen befinden. Sie werden zusätzlich aufgefordert, eine Instanz aus dem Server-Root zu wählen. Oder 3) Ein Benutzer, der zuvor Directory Server 5x verwendete und nun Directory Server 6 verwendet, kann nun manuell sämtliche Directory Server-Instanzen in einem übergeordneten Verzeichnis (dem früheren Server-Root) speichern. Hinweis – Die Server-Root-Terminologie wurde aus Directory Server 6 entfernt.	Keine weiteren Kommentare
Das Programm `comm_dssetup.pl` zur Vorbereitung des Directory-Servers für Messaging Server (Calendar Server und Delegated Administrator) wurde so geändert, dass es nun mit Directory Server 6.0 und Directory Server 5.x verwendet werden kann: Stille Installation: Server-Root-Verzeichnis	In vorherigen Versionen der stillen Installation wurde sowohl ein Server-Root- als auch ein Instanzverzeichnis angegeben. Wenn Sie Directory Server 5.x verwenden, gilt dies noch immer. Da in Directory Server 6.0 kein Server-Root-Verzeichnis vorhanden ist, muss das übergeordnete Verzeichnis der Directory Server-Instanz angegeben werden.	Keine weiteren Kommentare
Der Speicherort des Directory Preparation Tool `(comm_dssetup.pl)` wurde geändert.	`comm_dssetup.pl` befindet sich jetzt in einem eigenen Paket im Verzeichnis `/opt/SUNcomds` für Solaris und im Verzeichnis `/opt/sun/comms/dssetup` für Linux. Vorhandene Skripts, die den alten Pfad verwenden, müssen aktualisiert werden.	Vergewissern Sie sich, dass zur Installation des Pakets das Directory Preparation Tool im entsprechenden Installationsbildschirm ausgewählt ist.
In Messaging Server 5.x konnte ein Administrator mit dem IMAP-Befehl `list` alle Ordner des Nachrichtenspeichers anzeigen. Bereits bei einem nur durchschnittlichen Nachrichtenspeicher würde dieser Befehl eine ungewöhnlich lange Liste abrufen. In Messaging Server 6.x zeigt der IMAP-Befehl `list` nur die gemeinsam genutzten Ordner an.	Zur Auflistung aller Ordner des Nachrichtenspeichers verwenden Sie das Dienstprogramm `mboxutil`.	Weitere Informationen zum Dienstprogramm `mboxutil` finden Sie im Sun Java System Messaging Server 6.3 Administration Guide.
Das Konfigurationsprogramm für Delegated Administrator wurde geändert.	Installieren Sie Delegated Administrator, und führen Sie das Konfigurationsprogramm aus. Das aktuelle Programm befindet sich unter: für Solaris `/opt/SUNWcomm/sbin/ config-commda` für Linux `/opt/sun/comms/ config-commda`	Führen Sie ein Upgrade auf den neuen Delegated Administrator aus, wenn Sie diese Version von Messaging Server installieren.
Änderung beim Upgrade von Messaging Server mit Webmail über das IMAP-Protokoll (6397425, 6397451, 2137362)	Der Backend-Server muss vor dem Frontend-Server aufgerüstet werden. Sowohl das Webmail-over-IMAP-Protokoll als auch der Backend-Nachrichtenspeicher müssen dieselbe Produktversion aufweisen. Einzelheiten finden Sie im Sun Java Communications Suite 5 Upgrade Guide.	Keine weiteren Kommentare
Diese Version von Communications Express ist mit der Vorgängerversion von Messaging Server inkompatibel.	Bei einem Upgrade von Communications Express muss auch Messaging Server aktualisiert werden.	Dies gilt auch für Calendar Server. Weitere Informationen zu Communications Express finden Sie in Kapitel 6, Versionshinweise zu Sun Java System Communications Express 6.3 .
Bei der RTF/HTML-Bearbeitung und der Browser-Kompatiblität für Messenger Express und Communications Express ist eine Klarstellung erforderlich. (6311363)	Bei Messenger Express können Sie RTF/HTML-Bearbeitung für Internet Explorer-Browser verwenden. Mit Mozilla- und Netscape-Browsern ist keine RTF/HTML-Bearbeitung möglich. In der JES 2004Q2-Version von Communications Express können Sie RTF/HTML-Bearbeitung für Internet Explorer-Browser verwenden. Mit Mozilla- und Netscape-Browsern ist keine RTF/HTML-Bearbeitung möglich. In der JES 2005Q1-Version von Communications Express können Sie RTF/HTML-Bearbeitung für Internet Explorer 5.5 oder höher, Mozilla 1.3 oder höher oder Netscape 7.2 oder höher verwenden.	Keine weiteren Kommentare.
Der Fehler "`session.timeout` Login Again" wird angezeigt, wenn Sie in Portal Server auf Communications Express klicken. (6417988)	Ignorieren Sie die Fehlermeldung, schließen Sie das Fenster, und fahren Sie mit der Verwendung von Communications Express fort.	Keine weiteren Kommentare.
Wenn Sie Messaging Server mit Access Manager Single Sign-on verwenden, wird Java Enterprise System 2004Q2 Access Manager Server nicht unterstützt. Access Manager 6.3 und höher wird jedoch unterstützt.	Die folgenden Versionen von Messaging Server bieten keine Unterstützung für Java Enterprise System 2004Q2 Access Manager Server: Messaging Server 6.2-6.01 und höher Messaging Server 6.3	Führen Sie vor einem Upgrade von Messaging Server ein Upgrade von Access Manager (JES2004Q2) durch.
Für Access Manager gibt es nun zwei Installationstypen: Realm (Version 7.x) und Legacy (Version 6.x).	Wenn Sie Access Manager mit Messaging Server, Calendar Server, Instant Messaging, Delegated Administrator oder Portal Server installieren, müssen Sie den Legacy-Modus (Version 6.x) auswählen. Weitere Informationen finden Sie unter Sun Java System Access Manager 7 2005Q4 Release Notes	Falls der falsche Access Manager installiert wird, können Sie Delegated Administrator nicht mehr ausführen.

Löschen von Benutzern mit iPlanet Delegated Administrator und Messaging Server 6.3

Wenn Sie iPlanet Delegated Administrator verwenden und auf Messaging Server 6.3 aufrüsten, können Sie den Befehl imadmin user purge nicht zum Entfernen von Benutzern aus dem Verzeichnis verwenden, wie es in früheren Versionen von Messaging Server möglich war (6486836). Führen Sie zum Entfernen von Benutzern stattdessen die folgenden Schritte aus.

Dieses Kompatibilitätsproblem tritt auf, weil die Administrationskonsole und Administration Server in Messaging Server 6.3 entfernt wurden. In früheren Versionen von Messaging Server kann imadmin user purge wie zuvor verwendet werden.

Hinweis –

Das ursprünglich mit Messaging Server 5.x verwendete Dienstprogramm iPlanet Delegated Administrator wurde verworfen. Es handelt sich nicht um dasselbe Tool wie Communications Suite Delegated Administrator, das mit Messaging Server 6.x eingeführt wurde. Communications Suite Delegated Administrator unterstützt Schema 2. iPlanet Delegated Administrator unterstützt Schema 1. (Administratoren, die Messaging Server auf 6.x aufgerüstet haben, jedoch weiterhin Schema 1 verwenden, setzen zur Bereitstellung von Benutzern weiterhin iPlanet Delegated Administrator ein.

So entfernen Sie Messaging Server 6.3-Benutzer mit iPlanet Delegated Administrator

Wenden Sie iPlanet Delegated Administrator-Patch 1.2p3 an.

Dieser Patch kann auf der folgenden Seite heruntergeladen werden:

http://www.sun.com/download/index.jsp?cat=Collaboration%20%26%20Communication&tab=3

Wählen Sie das Delegated Administrator 1.2-Patch 3 für Messaging. Mit diesem Patch kann der Befehl imadmin user purge mit Messaging Server 6.3 verwendet werden. Zum Aktivieren dieses neuen Verhaltens führen Sie die verbleibenden Schritte aus.

Ändern Sie die Eigenschaft MsgSvrN-adminurl in der iPlanet Delegated Administrator-Datei resource.properties.

Über die Eigenschaft MsgSvrN-adminurl wird die Administration Server-URL festgelegt. Wenn für diese Eigenschaft eine tatsächliche URL festgelegt wird, versucht der Befehl imadmin user purge, Administration Server zu ermitteln, die Komponente antwortet jedoch nicht. Der Befehl imadmin user purge gibt einen Fehler zurück.

Setzen Sie MsgSvrN-adminurl auf den folgenden Wert: NO_ADMIN_SERVER.

Die Datei resource.properties befindet sich standardmäßig in folgendem Verzeichnis:

iDA_Install_Directory /nda/classes/netscape/nda/servlet/resource.properties

Hinweis –
Mehrere Nachrichtenspeicher auf Messaging Server 6.3 aufgerüstet:

Der Wert N in MsgSvrN-adminurl ist eine Variable, die durch einen spezifischen Wert (z. B. 0) ersetzt werden muss, die das Nachrichtenspeichersystem angibt, das auf Messaging Server 6.3 aufgerüstet wurde. Wenn Sie mehrere Backend-Nachrichtenspeicher in Messaging Server 6.3 bereitgestellt haben, muss dieser Wert für jede Instanz der Eigenschaft MsgSvrN-adminurl geändert werden.

Wenn Sie z. B. über drei Backend-Nachrichtenspeicher verfügen, muss diese Eigenschaft in den resource.properties-Dateien für alle drei Speicher geändert werden. Sie würden z. B. die Eigenschaften MsgSvr0-adminurl , MsgSvr1-adminurl und MsgSvr2-adminurl ändern.

Mehrere Nachrichtenspeicher mit unterschiedlichen Versionen von Messaging Server:

Angenommen, Sie verwenden mehrere Nachrichtenspeicher, von denen einige auf Messaging Server 6.3 aufgerüstet wurden, andere hingegen mit früheren Versionen von Messaging Server eingesetzt werden. Ändern Sie in diesem Fall die Eigenschaft MsgSvrN-adminurl nur für die Speicher, die auf Messaging Server 6.3 aufgerüstet wurden.

Wenn Sie den Befehl imadmin user purge für einen Speicher ausführen, für den die Eigenschaft MsgSvrN-adminurl in NO_ADMIN_SERVER geändert wurde, weist der Befehl das neue Verhalten (siehe Schritt 5 unten) auf.

Wenn Sie den Befehl imadmin user purge für einen Speicher ausführen, für den die Eigenschaft MsgSvrN-adminurl nicht geändert wurde (und weiterhin auf die Administration Server-URL verweist), weist der Befehl das alte Verhalten auf.

Starten Sie den Webserver neu, auf dem iPlanet Delegated Administrator bereitgestellt wurde.

Der Webserver, auf dem iPlanet Delegated Administrator ausgeführt wird, muss neu gestartet werden, damit die Änderungen an der Datei resource.properties wirksam werden.

Verwenden Sie den Befehl imadmin user delete, um einen Benutzer als gelöscht zu markieren.

imadmin user delete setzt das Attribut inetUserStatus auf "gelöscht". Zum Löschen mehrerer Benutzer verwenden Sie die Option -i. Beispiel:

imadmin user delete -D chris -L user1 -n siroe.com -w bolton

Verwenden Sie den Befehl msuserpurge, um das Postfach des Benutzers zu entfernen.

msuserpurge ermittelt alle Benutzereinträge, für die inetUserStatus oder mailUserStatus auf gelöscht gesetzt ist, löscht diese Benutzerpostfächer aus dem Nachrichtenspeicher, und setzt mailUserStatus auf entfernt. Beispiel:

msuserpurge -d domain

Vor dem Ausführen des nächsten Schritts (Entfernen des Benutzereintrags aus dem Verzeichnis) muss msuserpurge ausgeführt werden, da das Postfach des Benutzers anderenfalls verwaist.

Der Befehl msuserpurge kann mit dem configutil-Parameter local.schedule.userpurge geplant werden. Beispiel:
configutil -o local.schedule.userpurge -v "30 2 * * 0 /opt/SUNWmsgsr/lib/msuserpurge -g 20"
Im oben stehenden Beispiel wird msuserpurge sonntags um 2:30 ausgeführt. Dabei werden sämtliche Postfächer von Benutzern entfernt, die seit mehr als 20 Tagen zum Löschen markiert sind.

Verwenden Sie den Befehl imadmin user purge, um den Benutzereintrag aus dem Verzeichnis zu entfernen.

In früheren Versionen führte dieser Befehl die folgenden Aktionen aus:
1. Durchsuchen des Verzeichnisses nach Benutzern, die zum Löschen markiert sind.
2. Löschen der persönlichen Adressbücher der Benutzer aus dem Verzeichnis.
3. Löschen der Postfächer der Benutzer aus dem Nachrichtenspeicher.
4. Wenn das Attribut inetUserStatus eines Benutzers auf gelöscht gesetzt ist, wird der Benutzereintrag entfernt. Wenn mailUserStatus für einen Benutzer auf gelöscht gesetzt ist, werden die Mailattribute aus dem Eintrag entfernt.
Da die Eigenschaft MsgSvr0-adminurl geändert wurde, wird Administration Server nicht aufgerufen. In einer Meldung wird angezeigt, dass Administration Server nicht aufgerufen wurde. Schritt C (siehe oben) wird nicht ausgeführt. Das Postfach wurde bereits durch msuserpurge in Schritt 3 entfernt.

Wenn mailuserstatus für einen Benutzer in Messaging Server 6.3 auf gelöscht gesetzt wurde (über msuserpurge) und keine weiteren Dienste im Benutzereintrag vorhanden sind, entfernt der Befehl imadmin user purge den Benutzereintrag aus dem Verzeichnis.

Wenn die Attribute eines anderen Dienstes (z. B. Calendar Service) im Benutzereintrag vorhanden sind, wird der Eintrag nicht entfernt.