AADConnect DirSync aus- und wieder einschalten

Was passiert eigentlich, wenn ich auf meinem Office 365 Tenant die Funktion "DirSync" abschalte und wieder einschalte. Das beschreibe ich auf dieser Seite.

Diese Aktion ist nicht der Regelfall sondern soll eher dem Verständnis dienen. Ich kann mit aber durchaus vorstellen, dass die Kenntnisse z.B.: bei einer Migration von Benutzern in einen anderen Forest von Interesse sein kann. Ehe Sie an ihrem produktiven Forest solche Änderungen vornehmen, sollten Sie alle anderen Optionen ausgeschlossen haben. Auch eine zweite Meinung ist durchaus lohnenswert, damit die Ergebnisse wie gewünscht ausfallen.

Ausgangssituation

Ich habe also einen meiner Office 365 Tenants mit aktiviertem AADConnect genommen und mit Testdaten versehen. In meinem Tenant gab es natürlich noch alle Benutzer und Gruppen:

Auch per PowerShell kann ich anhand des Attributs "LastDirSyncTime" sehen, wann welche Objekte repliziert wurden.

PS C:\Users\fcarius> Get-MsolUser | ft userprincipalname,lastDirsynctime

UserPrincipalName                               LastDirSyncTime
-----------------                               ---------------
clouduser1@carius.onmicrosoft.com
clouduser2@carius.onmicrosoft.com
user4@carius.onmicrosoft.com                    10.03.2016 21:26:28
raum2@msxfaq.net
testuser@carius.de                              26.09.2016 12:51:56
user5@carius.onmicrosoft.com                    10.03.2016 21:26:28
NoUPN@msxfaq.net                                22.03.2016 17:09:33
raum1@msxfaq.net
user2@carius.onmicrosoft.com                    10.03.2016 21:26:28
user9@carius.de                                 23.05.2016 14:07:22
Sync_DCUSER_20b512fdfadd@carius.onmicrosoft.com 10.03.2016 21:23:35
frank@carius.de                                 01.06.2017 22:03:32
User1@carius.de                                 19.03.2016 10:46:42
user3@carius.onmicrosoft.com                    10.03.2016 21:26:28
user7@msxfaq.net                                22.05.2016 21:51:56
Shared1@msxfaq.net

Sie sehen hier schon eine nette Testserie. Auch bei synchronisierten Gruppen gibt es das Feld "LastDirSyncTime". Allerdings kein Feld "ImmutableID". Auch der AADConnect-Status ist sauber

DirSync abschalten

Es gibt eigentlich nur ganz wenige Fälle, wann ein DirSync abgeschaltet werden sollte. Aber wenn es mal erforderlich wird, dann muss man schon schauen, was passiert. Zuerst also das Abschalten:

# Mit Office 365 verbinden
Connect-MSOLService

# DirSync abschalten
Set-MsolDirSyncEnabled -EnableDirSync $false

# Status abfragen
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled 

In der Regel wird die Statusabfrage sehr schnell mit einem "$False" beantwortet. Sobald der Status auf "$false" ist, sehen Sie sehr schnell die Fehler im AADConnect:

Das Abschalten des DirSync blockiert den AADConnect-Prozess.

Hintergrundjob abwarten

Allein das Abschalten der AADConnect bedeutet aber noch nicht, dass die Objekte im Office 365 Tenant schon "frei" sind. Im Hintergrund von Office 365 läuft ein Prozess, der bis zu 72h benötigt um aus den "Synched with Active Directory" einen "In Cloud " Objekt zu wandeln. Mit folgendem Befehl können Sie den Status pro Benutzer sehen

# Entfernen aller Benutzer 
Get-MsolUser | ?{$_.lastDirsynctime}

# Entfernen aller Verteiler
Get-MsolGroup | ?{$_.lastDirsynctime}

Wenn der DirSync abgeschaltet und der Cleanup-Prozess durchgelaufen ist, dann ist das Feld "lastDirsynctime" leer ($null)

Auch die Webseite verändert ist. Hier verschwindet die Spalte "Sync Type". Die Spalte verschwindet, nachdem der Prozess gelaufen ist und damit die Abschaltung des DirSync auch abgeschlossen wurde:

Die Spalte ist einfach verschwunden. Allerdings zeigt diese Tabelle nicht alles. Denn ein Blick per PowerShell zeigt interessante Felder:

PS C:\> Get-MsolUser | ft UserPrincipalName,immutableid,LastDirSyncTime

UserPrincipalName                               ImmutableId              LastDirSyncTime
-----------------                               -----------              ---------------
user4@carius.onmicrosoft.com                    7fYQXz7cz0yw1AoU5PML5g==
raum2@msxfaq.net
testuser@carius.de                              QEXSU3DIB0iwwFgyOLp0Mw==
user5@carius.onmicrosoft.com                    jzvTkG2A8kmfizuCDSTbaw==
NoUPN@msxfaq.net                                ay4f2rY3b0m+760P45Ju2g==
raum1@msxfaq.net
user2@carius.onmicrosoft.com                    AxwAYaSJZEKIuQ1gUndETA==
user9@carius.de                                 VuOFtgUp8k+Rmmf/bXj6bw==
Sync_DC_1234567890ab@carius.onmicrosoft.com
frank@carius.de                                 0AELcaZXH06GiIq4Ed+cqA==
User1@carius.de                                 9PuWxEPKY0S9o18N1rN2LQ==
ingrid@carius.de
user3@carius.onmicrosoft.com                    MMqDsdGGjU2cwXh2v3QWOA==
user7@msxfaq.net                                YlmLRIg5F0ee+5JH5PH1GQ==
Shared1@msxfaq.net
admin@carius.onmicrosoft.com

Obwohl alle Benutzer keine "LastDirSyncTime" haben und damit nicht mehr als "Synced with AD" sind, so hat der Aufräumprozess vergessen, die "ImmutableID" zu entfernen.

Solange die Objekte noch eine "ImmutableID" haben, kann AADConnect die Objekte erst mal nicht wieder matchen. Sie bekommen auch nicht alleine wieder den "Sync from AD" Status. Der Cleanup-Prozess entfernt wirklich das "lastDirsynctime", welches für AzureAD auch ein Zeichen ist, dass das Objekt "im Sync" ist

Richtige "Cloud only"-Objekte haben auch keine ImmutableID. Das wird gleich beim "Matching" wichtig. Es wurden natürlich keine Objekte durch da Abschalten des DirSync gelöscht, so dass auch noch das Dienstkonto des AADConnect-Service vorhanden ist. Das sollten Sie nicht löschen, wenn Sie die gleiche Instanz des AADConnect später wieder in Betrieb nehmen.

Matchen und Neuanlage

Wenn ich den DirSync auf dem Tenant aktiviere, dann habe ich ja das Ziel auch wieder einen AADConnect einzurichten oder wieder in Betrieb zu nehmen. Dabei gibt es nun mehrere Szenarien

  • Bestehender AADConnect reaktivieren
    Dabei sind die früher schon replizierten Objekte ja immer noch im Metaverse. In dem Fall passen auch "ImmutableID" im MetaVerse und das Feld ms-ds-consistencyGUID zusammen
  • Neuer AADConnect einrichten
    Wenn nur der AADConnect-Server "verloren" gegangen ist, dann können Sie den einfach frisch installieren. Er liest dann aus dem lokalen AD die Objekte samt "ms-ds-consistencyGUID" aus und kann so die Objekte wieder "matchen"
  • Neuer Forest
    Ganz anders sieht es aus, wenn Sie auch das Active Directory wieder aufgebaut haben. In dem Fall haben Sie zwei Optionen, um ein Matching zu unterstützen. Sie können in der Cloud die ImmutableID entfernen und dann auf das "Normal" Matching anhand der Mailadresse bzw. des UPN vertrauen. Oder sie setzen On-Premises bei den Benutzern den richtigen Wert in das Feld "ms-ds-ConsistencyGUID"

Wenn keine der drei Optionen greift, dann legt AADConnect einfach neue Benutzer an und vergibt dynamisch einen neuen UPN in der Cloud, wenn der UPN durch ein früheres Objekt noch "belegt" ist. Um also hier ein "Matching" bei einer ganz neuen lokalen AD-Forest-Installation mit neuen Benutzern zu erreichen, müssen Sie dem System beim Matching helfen.

  • Sie pflegen das Feld "ms-ds-consistencyGUID" auf der Quelle
    Damit AADConnect diesen Wert importiert und auf das bestehende Objekt in der Cloud verbindet. Dazu müssen Sie aber das BASE64-codierte Feld in der Cloud auslesen und im AD als HEX-Wert eintragen
  • Sie leeren die ImmutableID in der Cloud
    Dann läuft das ganz normale "Matching" (Siehe dazu auch ADSync User Matching) auf Basis der Maildresse oder des UPN ab.

Ich würde den einfachen Weg wählen und die "Cloud Only"-User in Office 365 einfach um ihre ImmutableID berauben und auf das "Matchen" vertrauen.

Dieser Schritt ist wirklich nur dann notwendig, wenn Sie die Objekte im lokalen Active Directory Forest neu angelegt haben und diese dort keinen Wert in "ms-de-consistentcyGUID" haben.

So entfernen Sie die ImmutableID auf allen Objekten in ihrem Tenant:

# Verbindung herstellen
connect-msolservice

# ImmutableID bei einem Benutzer entfernen
Set-MsolUser `
   -UserPrincipalName user7@msxfaq.net `
   -ImmutableId "$null"

#ImmutableID bei allen Cloud Only Benutzern entfernen
Get-MsolUser `
   | ?{$_.immutableid -and -not $_.LastDirSyncTime} `
   | Set-MsolUser -ImmutableId "$null"

Hinweis: Die "Anführungsstriche" bei der Angabe von $null beim Parameter ImmutableID ist notwendig, da ansonsten die ImmutableID nicht geleert wird.

Das geht natürlich nur für Objekte mit dem Status "Cloud Only". Wenn Sie dies bei einem Objekt versuchen, welches schon wieder einen Wert in "LastDirSyncTime" hat, dann scheitert der Aufruf mit einem:

PS C:\Users\fcarius> Set-MsolUser -UserPrincipalName ADUSER1@carius.de -ImmutableId "$null"
Set-MsolUser : Unable to update parameter. Parameter name: IMMUTABLEID.
In Zeile:1 Zeichen:1
+ Set-MsolUser -UserPrincipalName ADUSER1@carius.de -ImmutableId "$null ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : OperationStopped: (:) [Set-MsolUser], MicrosoftOnlineException
    + FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online.Administration.Automation.SetUser

Wenn Sie dann ein passendes Objekt im lokalen AD haben, geht es sehr schnell wieder weiter.

Achtung: Lokales AD sticht AzureAD
Sie sollten vorab auf jeden Fall sicherstellen, dass die OnPrem Benutzer alle erforderlichen Properties haben. Dazu zählen auch Exchange Properits (RemoteMailbox, SMTP-Adressen), Skype for Business Einstellungen und natürlich die allgemeinen Stammdaten wie Telefonnummern, Firma, Abteilung, Adresse und was Sie sonst noch als relevant betrachten.

Ich habe noch kein Skript oder Programm gesehen, welches die Daten von den Objekten in einem Office 365 Tenant vorab extrahiert und an Neu angelegte lokale AD-Benutzer so überträgt, dass Sie beim späteren AADConnect unverändert angewendet werden. Dabei müsste es ja auch z.B. eine Exchange Online Mailbox im lokalen AD als "Remote Mailbox" provisionieren, damit AADConnect dann die Werte in der Cloud nicht beschädigt..

Tue, was du willst aber

Jetzt, wo der DirSync abgeschaltet ist, können wir natürlich alle Änderungen an den Office 365 Objekten vornehmen, die wie vornehmen wollen. Auch per Weboberfläche können Benutzer gelöscht und Gruppenmitgliedschaften verändert werden. Sie können per Exchange Management Shell oder ECP auch die Exchange Eigenschaftender Anwender bearbeiten. Alles ist wieder so als hätte es nie einen DirSync gegeben.

Alle Änderungen sind aber nur solange "gültig", bis sie wieder einen DirSync einrichten und diese Objekte auf ein lokalen AD-Objekt verbunden werden. Dann bestimmt wieder das lokale AD bzw. die Eigenschaften des AD-Objekt.

Insofern sollten Sie also nicht so viel ändern, wenn eine spätere Reaktivierung eines AADConnect geplant ist.

Reaktivieren des DirSync

So, wie wir den DirSync auf dem Tenant deaktiviert haben, können wir ihn auch wieder aktivieren. Das geht diesmal ohne Wartezeit.

# Mit Office 365 verbinden
Connect-MSOLService

# DirSync abschalten
Set-MsolDirSyncEnabled -EnableDirSync $true

# Status abfragen
(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

Sie können diese Änderung auch durch eine Installation eines AADConnect oder eine Aktualisierung der Konfiguration eines noch bestehenden AADConnect durchführen. Das Ergebnis ist identisch. Wenn Sie ihren noch besehenden lokalen AADConnect-Service beobachten, dann sollte dieser nach einiger Zeit dann auch wieder "live" gehen. Interessant wird es dann natürlich zu sehen, was mit den Objekten passiert. Im Azure-AD sind die Objekte nun ja "Cloud Objekte". Die Spalte "Sync Typed" ist nun wieder sichtbar

Noch sind die Benutzer alle "in der Cloud", da der DirSync aktiviert ist aber AADConnect noch keinen Lauf gestartet hat.

Sobald nun aber AADSync seinen Lauf gestartet hat und das Matching auf bestehende Objekte anhand der Mailadresse oder UPN  bzw. bei Gruppen anhand der Mailadresse funktioniert, bekommen die Objekte wieder den Status "Synced with AD".

Weitere Links