Arbeitsumgebung aktualisiert sich nicht nach User- Umzug

[Tode]

Wir haben hier einen Cluster von 2 auf 3 Server aufgebohrt (einer der Server soll bald abgeschaltet werden) und die User per "Benutzer verschieben" im Admin- Client auf den neuen Server umgezogen... Ist auch alles sauber durchgelaufen, und die Personendokumente der Benutzer enthalten auch die Felder "OldMailServer" usw. aber die Arbeitsumgebungen bleiben trotzdem auf dem alten Server stehen und aktualisieren sich nicht automatisch.

Das Feld "AcceptUpdates" steht in den Arbeitsumgebungen auf "1", daran kann es also nicht liegen.

Die Arbeitsumgebungen wurden ursprünglich mal mittels BCC Client Genie erstelllt, aber inzwischen wird die DLL bei Neuinstallationen nicht mehr mit ausgerollt.

Hat jemand ne Idee, wonach ich noch schauen könnte?

Danke & Gruß
Torsten

[Manfred W.]

Hallo Torsten,

wird der Server vielleicht über eine Desktop-Policy gesetzt?

Grüße
Manfred

[Tode]

Guter Tipp, daran hatte ich wirklich nicht gedacht... aber nein: Server steht in keiner Desktop- Policy.

[CarstenH]

In solchen Fällen empfehle ich immer die erforderlichen Administrationsanforderungen für den Vorgang herauszusuchen und mit den tatsächlichen in der Admin4 (inklusive Erledigungsstatus) zu vergleichen, an der Stelle wo es endet die Voraussetzungen und den Ausführungszeitpunkt genau prüfen - dann hat man i.d.R. den Verursacher.

Wo endet die Kette bei dir? Klingt in deiner Beschreibung nach "Neue Maildateifelder überwachen", Ausführung   "Wenn der Router den neuen Mail-Server für die Maildatei erkennt." Dann wäre die AU beim Nutzer noch gar nicht dran.

Die Arbeitsumgebung beim User ist erst nach dem Schritt "Maildateifelder ersetzen" dran und wird gefolgt von "Änderungen an neuen Mail-Server senden (Push)", was der Hinweis ist, das beim Client nichts mehr passieren wird (oder muss, weil schon passiert).

Hier nochmal die komplette Liste für den Schnellen Vergleich:

Maildatei von einem Server auf einen anderen verschieben:

Mail-Serverzugriff überprüfen   Sofort
Speicher für gehostete Organisation überprüfen   Sofort
Zugriff des neuen Mail-Servers hochstufen   Sofort
Neue Mailreplik erstellen   Sofort
Neue Maildateifelder hinzufügen   Sofort
Neue Maildateifelder überwachen   Wenn der Router den neuen Mail-Server für die Maildatei erkennt.
Maildateifelder ersetzen   Sofort
Änderungen an neuen Mail-Server senden (Push)   Sofort
Datei-Informationen zum Löschen abrufen   Intervall
Dateilöschung bestätigen   Nach Ermessen des Administrators.
Dateilöschung anfordern   Intervall
Maildatei löschen   Intervall
Nicht verlinkte Maildatei löschen   Intervall
Veraltete Änderungsanforderung löschen   Täglich

HTH
Carsten

[Tode]

Hi Carsten, danke für den Hinweis, aber die Admin- Anforderungen sind komplett durchgelaufen (inklusive automatischer Dateilöschung auf dem Quellserver, obwohl ich das nicht angehakt hatte, aber das ist eine andere Geschichte).

Das hatte ich als erstes geprüft. Danke dass Du es nochmal in den Thread geschrieben hast, ist für andere auf jeden Fall relevant.

[CarstenH]

Hallo Torsten,

ich wollte dir nicht unterstellen, dass du das nicht kontrolliert hast. Darf ich trotzdem an der Stelle nochmal einhaken.

Der Request "Änderungen an neuen Mail-Server senden (Push)" wird eigentlich erst erstellt, nachdem das PAB aktualisiert wurde, d.h. der Client gibt das OK, der Server macht normalerweise nicht von sich aus weiter:

Nachdem das persönliche Domino-Verzeichnis aktualisiert wurde, erstellt Notes eine Anforderung des Typs Änderungen an neuen Mail-Server senden (Push), die das Löschen der Maildatei auf dem alten Mail-Server auslöst. Wenn der Benutzer ausschließlich über den Replikator auf den Home-Server zugreift, wird das persönliche Domino-Verzeichnis nicht aktualisiert und die Anforderung Änderungen an neuen Mail-Server senden (Push) wird nicht erstellt.

Das "persönliche Domino-Verzeichnis" ist natürlich nur wieder eine tolle Übersetzung für Persönliches Adressbuch (PAB).

Wenn also der AdminP mit den nächsten Requests weitergemacht hat muss der Client beim Nutzer zumindest kurzfristig etwas an den AU geändert haben. Ohne Änderung am PAB sollte der Prozeß hier abbrechen und bis zum Verfallsdatum der Requests warten. Vielleicht wurde die AU ja wieder zurück geändert...
- z.B. weil der Nutzer mehr als einen Client benutzt;
- das PAB in mehreren Repliken existiert und die Änderung wieder überschrieben wurde;
- die Änderung im PAB nicht zum Server zurück repliziert wurde (Stichwort Roaming);
- sind Managed Replicas aktiv? Vielleicht auch hier in Kombination mit Roaming oder AU's die auf lokale Mailfiles zeigen?

Einfach nur ein paar Gedankenanstöße.

HTH
Carsten