Quest Migration Manager for AD – Probleme mit der Directory Synchronisation lösen
Im Moment betreue ich die Migration einer Active Directory Domäne mit
Quest Migration Manager for Active Directory 8.7
Die Verzeichnis-Synchronisierung (Directory Synchronisation – DSA) lief mit ca. 400.000 Objekten für mehr als 6 Wochen stabil.
Vor 3 Wochen bekamen wir Meldungen über Benutzerkonten, die nicht migriert worden.
Workload für Directory Synchronization Agent (DSA) zu hoch
Mit Hilfe des Quest Supports, welchen ich hier lobend erwähnen will, konnten wir die Probleme mit der Directory Synchronisation eingrenzen und schließlich lösen.
Ich habe ein paar neue Kniffe zur Fehlersuche gelernt:
Der Ursprung des Problems lag in einer zu hohen Last für den Directory Synchronization Agent (DSA).
Wie stelle ich jedoch eine zu hohe Last des DSA fest?
Der DSA macht nach einem vollständigen Lauf (cycle) eine Pause. Diese Pause wird im DSA.log mit folgendem Eintrag erfasst:
1 | „Common *** CFG: going to sleep“ |
Pfad zur Datei DSA.log: „Quest Software\Migration Manager\DSA\CONFIGS\DSA.log“
Im Normalbetrieb hatten wir zwischen 30 und 50 Pausen pro Tag. Seit einem bestimmten Tag vor 3 Wochen hatten wir plötzlich keine Pausen mehr.
Tipp: das ShareWare tool Total Commander kann die gepackten Logfiles im LogArchive nach Text durchsuchen.
Der Quest Directory Synchronization Agent (DSA) verarbeitet einige Änderungen in einer sog. „rerequest queue“. Diese “rerequest queue” wird erst nach einer Pause des Directory Synchronization Agent (DSA) verarbeitet. In unserem speziellen Fall kommen manche neu angelegte Benutzerkonten in diese “rerequest queue”, was zur Folge hatte, dass diese Konten nicht migriert wurden. Als Auslöser für das Problem konnten wir einen Metadirectory Dienst ausfindig machen. Hier wurden in einer Endlosschleife immer wieder die gleichen Änderungen in die Domäne geschrieben. Diese Änderungen haben den Quest Directory Synchronization Agent (DSA) derart beschäftigt, sodass keine Zeit für eine Pause war und somit auch die rerequest queue nicht mehr verarbeitet wurde.
Wie kann man die Verarbeitung der re-request queue im Logfile erkennen?
Wenn Objekte zur weiteren Verarbeitung an die rerequest queue gesendet werden, erfolgt folgender Eintrag:
1 | Target JobID:0 |
Die Verarbeitung der rerequest queue wird mit folgenden Einträgen protokolliert (nicht unmittelbar aufeinander folgend)
1 2 | Common JobID:0 Forced Request Handler start Source JobID:0 -> Forced Request Handler finish |
Leave a Reply
Danke für Ihre Anregungen, Fragen und Hinweise.
Infos zum Datenschutz