Letzte Woche meldete ein Benutzer, dass er sein Kennwort zurückgesetzt hatte, es aber im angeschlossenen HR-System nicht geändert worden war.
Da dies ein Hinweis darauf ist, dass der Password Change Notification Service (PCNS) nicht funktionierte, habe ich die Ereignisanzeige auf dem Synchronization Engine Server überprüft. Während ich mehrere Ereignis-IDs sah, die anzeigten, dass Heartbeats von den DCs empfangen wurden, gab es in den letzten Stunden keine Ereignis-IDs 6903. 6903 ist das Ereignis, das anzeigt, dass eine Kennwortbenachrichtigung von PCNS empfangen wurde.
Aus irgendeinem Grund wurden Kennwortänderungen nicht an das Synchronisierungsmodul gesendet.
In dieser Umgebung haben wir einen benutzerdefinierten Workflow, der es dem Helpdesk ermöglicht, das Kennwort eines Benutzers zurückzusetzen. Indem ich die Protokollierung für diesen Workflow aktivierte, konnte ich den DC ermitteln, an den die Anforderung zur Kennwortänderung gesendet wurde. Mit Hilfe eines Mitglieds der IT Ops-Gruppe überprüften wir diesen Domain Controller und stellten fest, dass der PCNS-Dienst lief.
Als wir in der Ereignisanzeige für diesen DC nachschauten, gab es überhaupt keine PCNS-Meldungen, weder Fehler noch Informationsereignisse.
Etwas verwirrt starteten wir den PCNS-Dienst neu und erhielten die Fehlermeldung 6032: "Die Filterkonfiguration für das Ziel 'xxxxx' ist ungültig. Dies führt dazu, dass ALLE Benachrichtigungen für dieses Ziel gefiltert werden. Überprüfen Sie, ob das Zielobjekt korrekte Werte für die Inclusion und Exclusion Security Identifiers (SID's) hat".
Dies erschien merkwürdig, da es seit Monaten keine Änderungen an dieser Konfiguration gegeben hatte. Die Meldung schien darauf hinzuweisen, dass FIM weder die Einschlussgruppe noch die Ausschlussgruppe finden konnte.
Nach ein wenig Nachforschung fanden wir heraus, dass die Ausschlussgruppe fehlte. Es stellte sich heraus, dass während eines Wartungsprozesses alle Gruppen ohne Mitglieder gelöscht wurden und die Ausschlussgruppe zufällig leer war (neue Lektion gelernt: fügen Sie immer eine Beschreibung in die Einschluss- und Ausschlussgruppen ein, damit die Administratoren wissen, dass sie sie nicht löschen sollen - in einer großen Organisation wissen oft nicht alle Administratoren, wofür die Gruppe verwendet wird).
Da wir keine Ausschlussgruppe benötigten, versuchten wir, pcnscfg auszuführen, um PCNS so einzustellen, dass es keine Ausschlussgruppe benötigt, mit dieser command:
pcnscfg MODIFYTARGET /N:fimsyncsvc.domain.com /A:fimsyncsvc.domain.com /D:PCNSCLNT/fimsyncsvc.domain.com /FI: "Domain Users" /FE:
Wenn Sie den Wert für den Parameter /FE: leer lassen, sollte die Ausschlussgruppe aus der Konfiguration entfernt werden, aber in unserem Fall erhielten wir die Fehlermeldung, dass der Name nicht aufgelöst werden konnte.
Da wir wussten, dass die Ausschlussgruppe fehlte, gingen wir davon aus, dass sie versuchte, die Gruppe zu finden, um die Änderung zu übertragen und sie zu entfernen.
Um dieses Problem zu beheben, haben wir eine neue Sicherheitsgruppe für die Ausschlussgruppe erstellt und den PCNSCFG command unter Angabe dieser Gruppe ausgeführt. Ich gehe davon aus, dass MODIFYTARGET command den Wert der Ausschlussgruppe auch dann überschreiben kann, wenn es den vorherigen Namen nicht auflösen kann, dass es aber in diesem Fall den Wert der Ausschlussgruppe nicht löschen kann.
Nach der Angabe der neuen Ausschlussgruppe und dem Neustart des Dienstes begannen die Kennwortsynchronisierungen wieder zu laufen.
Da dieser Konfigurationsfehler verhinderte, dass alle Kennwortänderungen an das Ziel übermittelt wurden, gab es keine Warteschlange von Kennwortänderungsanforderungen, die an den Synchronisierungsserver weitergeleitet wurde. Wir sahen daher nur, dass sie eintrafen, wenn Benutzer ihre Kennwörter erneut änderten.
Schließlich führten wir die command mit dem leeren Parameter /FE: erneut aus, starteten den PCNS-Dienst neu und die Kennwortsynchronisierung funktionierte wieder, so dass wir die Ausschlussgruppe löschen konnten.
