Advanced Provisioning

Diese Seite ist "Gripsgymnastik" für ADSync und Provisioning-Administratoren und basiert auf einer realen Kundensituation. Leider habe ich keine passende Testumgebung, um die Schritte per Bildschirmfotos zu erläutern. Daher müssen ein paar Visio-Bilder reichen.

Auslöser

Die Umgebung in diesem Beispiel bestand aus einem Account-Forest, einem Exchange Ressource-Forest und einem Office 36t Tenant. Lange ist nichts passiert und erst bei der Einrichtung von "Remote Room Mailboxen" für den Betrieb von Surface Hubs ist etwas schief gegangen.

Die gleich geschilderten Probleme könnten aber genauso mit anderen Vorgängen passieren. Daher ist dies nur ein Beispiel, um die Herausforderungen beim Provisioning deutlich zu machen

Die Reihenfolge der Schritte war:

  1. Das Provisioning hat das AD-Konto im Anmeldeforest angelegt
  2. Das Provisioning hat das AD-Konto im Exchange Ressourceforest angelegt
  3. Das Exchange Ressourceforest Konto wurde mit "Enable-RemoteMailbox -room" zu einem Raumpostfach in der Cloud aktiviert
    Leider kennt "Enable-RemoteMailbox" nicht den Parameter "LinkedMasterAccount". Wer also z.B. eine Mailbox oder einen Raum in Exchange Online anlegt und lokal mit einem Ressource Forest arbeitet, kann nicht mit einem Schritt auch diese Konfiguration durchführen, sondern muss zusätzlich mit "Set-User" einen zweiten Befehl verwenden.
  4. LinkedMasterAccountSID mit "Set-User" addiert
    So hat man schon früher die MasterAccountSID bei einer Mailbox addiert, bis "Set-Mailbox" endlich diese Funktion bereit gestellt hat. Set-RemoteMailbox kennt die Option ja nichts.
  5. Warten auf ADSync
    Nach einiger Zeit ist das Postfach auch in der Cloud aufgetaucht.
  6. Exchange Parametrisierung
    Erst dann konnte dann mittels Exchange Online PowerShell die weiteren Einstellungen mit Set-CASMailbox, Set-Calendarprocessing u.a. umsetzen.

In den meisten Fällen ist das auch gut gegangen und das Ergebnis sah wie folgt aus:

Aber manchmal gab es dann doch ein Problem, dass ADSync eine Doppelte Proxy-Addresse berichtete. Also haben wir gesucht und wurden fündig

ADSync und Zeitplan

Der Fehler trat immer dann auf, wenn zwischen Punkt 2 und 4 zu viele Zeit verstrichen ist und ADSync in dem Zeitfenster mit einem "Delta Import" die Änderungen der beiden lokalen Verzeichnisdienste eingelesen hat. Dann ist nämlich folgendes passiert:

Da erst mit Schritt 4 die Verbindung durch das Feld "msexchMasterAccountSID" hergestellt wurde, hat ADSync davor einfach zwei eigenständige Objekte gesehen und diese auch als eigene Identitäten in das MetaVerse geschrieben. Beim Export Richtung Office 365 wurden dann auch zwei Konten im AzureAD angelegt. Das erste Konto wurde noch fehlerfrei angelegt und hat aufgrund des UPN und MAIL auch die ProxyAddresse bekommen, die auch das zweite Konto haben sollte. Damit war die "Dublette" generiert und der Export der zweiten Identität war fehlerhaft.

Auflösung

Diese Problem kann sowohl bei der Neuanlage als auch bei späteren Veränderungen auftreten. Es ist also keine Lösung nun das Objekt in der Quelle zu löschen und richtig neu anzulegen. Eine Lösung ist relativ einfach, denn die Fehlermeldung liefert ihnen die beiden Objects-IDs und über ADConnect können sie im Metaverse auch nach den Objekten mit dem Konfliktfeld suchen. Im Metaverse ist es problemlos möglich und auch erlaubt, dass mehrere Objekte identische Feldinhalte haben. Als Beispiel können Sie das z.B. Straße, Firmenname o.ä. heranziehen, deren Inhalte sicher nicht einmalig verwendet werden. Erst beim Export kann das Zielsystem dann Konflikte erkennen.

In dem Fall was die Lösung einfach, das beide Objekte in den lokalen ADs bereits angelegt und provisioniert waren aber d.h. das "RemotePostfach" in Exchange Online noch nie genutzt werden konnte. Unser Ziel war daher ein Matching auch nachträglich wieder zu erreichen. Ein Schlüssel dazu ist der SourceAnchor (Feld ms-DS-ConsistencyGuid)

Wir haben dazu folgende Schritte durchlaufen.

  1. Exchange Objekt ausschließen
    Zuerst haben wir uns die ADSync Konfiguration angeschaut, damit wie das im Metaverse doppelte Exchange-Objekt ausschließen können. Fast jede Firma konfiguriert ADSync mit einem Filter, dass nur Objekte mit einem bestimmten LDAP-Feld, Gruppenmitgliedschaft oder aus bestimmten OUs von ADSync gesehen werden. Wir haben das Objekt also einfach in eine OU verschoben, die von ADSync ignoriert wird
  2. ADSync Import+Sync
    Dann durfte ADSync diesen Forest einmal Lesen und Synchronisieren. Als Ergebnis wurde das Objekt als "gelöscht" erkannt und im Metaverse entfernt. Beim nächsten Export in die Cloud würde dann Objekt dort auch wieder verschwunden. Wenn Sie den Export verzögern, dann müssen Sie im Schritt 6 den Export ggfls. doppelt machen.
  3. Exchange Object "matchbar" machen
    Damit wir das Exchange Objekt wieder mit ADSync lesen und mit dem bestehenden Objekte im Metaverse zusammenführen können, haben wir zuerst das Feld "ms-DS-ConsistencyGuid" gelöscht. Das ist erforderlich, damit ADSync dieses Objekt als "unbekannt" ansieht. Ansonsten würde ADSync ein passendes Objekt im AzureAD suchen und wieder verknüpfen.
    Zudem haben wir nun natürlich über die MasterAccountSID dafür gesorgt, dass es eine Verbindung zum Anmeldekonto gibt.
  4. Exchange Objekt wieder mit ADSync lesen
    Das so korrigierte Objekte wurde dann wieder an seine originale OU verlagert und ADSync durfte einen Import/Sync auf den Forest machen. Diesmal erkennt ADSync das Objekt wieder als "neu", da es keinen Wert in ms-DS-ConsistencyGuid hat. ADSync führt die Daten aus dem Exchange Ressource Forest nun im Metaverse mit dem vorhandenen Anmeldekonto zusammen.
  5. Metaverse kontrollieren
    Den Erfolg dieser Aktion kontrollieren wir natürlich im Metaverse-Browser
  6. Export zu AzureAD
    Nun darf ADSync die neuen Daten auch in das AzureAD exportieren. Da wir zügig gearbeitet haben, gab es im AzureAD immer noch beide Objekte und der Update des vorhandenen Objekts war nicht beim ersten Lauf erfolgreich, weil es das andere Objekte noch gab. In dem gleichen Lauf löschte aber ADSync das zweite ungeliebte Objekt, weil in Schritt 2 der Reparatur das Objekt im Metaverse entfernt wurde. Es bedarf eines zweiten Export, damit das verbliebene Objekt nun endlich aktualisiert werden kann.

Das ganze Procedere war natürlich nur möglich, weil das bei der Aktion gelöschte Postfach noch keine Inhalte hatte. Bei solchen "Doppelkonten" müssen Sie immer überlegen, welches Konto sie in der Cloud löschen. Sollten tatsächlich schon beide Konten entsprechende Daten beinhalten, ist eine Migration der Inhalte zu prüfen. Mit Exchange geht das relativ einfach, denn das bei dieser Aktion gelöschte Postfach ist ja weiter als "Deleted User" vorhanden. Sie können es in der Cloud bis zu 30 Tage wieder herstellen. Es ist dann ein "Cloud Only"-Konto, welches nicht durch ADSync versorgt wird und es ist kein Problem, die Daten per Export oder als SharedMailbox einzubinden, um diese Daten in das richtige Postfach zu verschieben. Diese Zeit sollte aber nicht lange sein, denn diese Art "Recovery Mailbox" hat natürlich eine "onmicrosoft.com"-Adresse und ist On-Premises nicht im Adressbuch sichtbar. Das Zielpostfach sollte daher auch in der Cloud liegen, damit Outlook eine Verbindung herstellen kann.

Lernkurve und Analogien

Diese Beispiel ja mir gezeigt, dass Provisioning nicht immer gerade verläuft und verschiedene Prozesse nicht immer aufeinander abgestimmt werden können. Programmierer müssen mit den unterschiedlichsten Anforderungen umgehen können und nach der Anwendung einer Änderung sollten sie nicht nur prüfen, ob es tatsächlich angekommen ist, sondern auch sicherstellen, dass es überall angekommen ist.

Wer per LDAP einen Benutzer anlegt und gleich drauf per "Enable-RemoteMailbox" diesen Benutzer mit einem Postfach in der Cloud versieht, sollte auf die Wahl des gleichen Domaincontrollers achten. Ansonsten schlägt die Exchange PowerShell fehlt, da sie den Benutzer noch nicht findet. Das geht so weiter, denn die Zuweisung einer Lizenz in der Cloud geht auch erst, nachdem ADSync das Objekt dort angelegt hat und erst wenn das Postfach in Exchange Online vorhanden ist, können Sie mit "Set-CASMailbox" die Details zum Postfach einstellen, die lokal nicht möglich sind und ADSync auch nicht repliziert.

Eine Lösung könnte so aussehen, dass Sie neue AD-Objekte in einer OU anlegen, die ADSync nicht kennt und erst nachdem alle lokalen Einstellungen vorgenommen werden, wird das Objekt an die finale Zielposition verschoben. Dann kann ADSync nur alles oder nichts sehen. Wobei auch hier die AD-Replikation immer noch quer schießen kann.

Bei den ein oder anderen Projekten habe ich mir den Luxus erlaubt, einfach das "LastModified"-Feld zu lesen und Objekte erst dann zu betrachten, wenn Sie sich "stabilisiert" haben. Das führt natürlich zu einer gewollten Verzögerung mit entsprechenden Wartezeiten. In unserer schnelllebigen Welt ist das nicht immer akzeptiert.

Andere Prozesse arbeiten Änderungen als Warteschlange ab und versuchen eben einen "Retry", wenn die Änderung beim ersten Mal nicht erfolgt ist. Das entspricht dann einer "Job-Verarbeitung".

Übrigens gibt es solche Herausforderungen auch an anderen Orten. Wenn mehrere Prozesse sich um die gleichen Dateien streiten, dann hat es sich bewährt, wenn die Dateien von einem Prozess erst "gesehen" werden, wenn der andere Prozess fertig ist. Anstatt mit Dateisperren zu arbeiten, kann man Dateien einfach in die richtigen Ordner verschieben oder entsprechend umbenennen. Exchange verfährt mit einen EDB-Logs ja genauso, dass er eine Logdatei beschreibt und diese dann zum Abschluss umbenennt.

Insofern immer noch einmal nachdenken, wie ein Prozess "wasserdicht" gestaltet werden kann.

Weitere Links