T2T Device

Heute werden nicht nur Benutzer und Dienste von einem Tenant in einen anderen Tenant umgezogen. Auch die Endgeräte bedürfen einer Betrachtung. Auf dieser Seite geht es um Computer und Mobilgeräte in den verschiedenen "Join-Zuständen".

Mittlerweile hat auch Microsoft einen Artikel veröffentlicht.
Support tip: How to transfer Windows Autopilot devices between tenants
https://techcommunity.microsoft.com/t5/intune-customer-success/support-tip-how-to-transfer-windows-autopilot-devices-between/ba-p/3920555

Umgebung

Ohne die Cloud ist ein Windows Client meist nur Mitglied einer lokalen Active Directory Umgebung und der Anwender meldet sich auf dem PC an. Einen Bezug zur Cloud gibt es nicht und wenn Sie den Benutzer in einen anderen Tenant verschieben, können Sie den lokalen PC durchaus im gleichen AD-Forest mit dem gleichen AD-Benutzer weiter betreiben. Der Wechsel des lokalen PCs in einen anderen Forest, z.B. per ADMT möchte ich hier nicht weiter betrachten. Genaugenommen gibt es nicht eine Ausgangssituation und ein Ziel, sondern gleich mehrere mögliche Kombinationen, denn ein Endgerät kann einen von vier Zuständen mit dem AzureAD einnehmen, die sich von den verschiedenen Mitgliedschaften ableiten:

  • Mitgliedschaft in lokalem AD-Forest
    Sehr viele PCs sind sicher Mitglied in einem lokalen AD aber es gibt durchaus Umgebungen, in denen die Endgeräte entweder nicht Mitglied sind oder am Beispiel eines Smartphone nicht sein können.
  • Mitgliedschaft im AzureAD
    Hier kann das Gerät einen der drei Zustände "HybridAzureADJoined", "AzureAD Joined", "AzureAD registered/Standalone" einnehmen.

Aus der Kombination einer lokalen AD-Mitgliedschaft und der AzureAD-Konfiguration gibt es vier Zustände und natürlich auch vier mögliche Zielzustände. Schauen wir uns mal einige davon an.

  • Hybride (Windows-)Geräte
    Diese werden im lokalen AD verwaltet und mit ADSync auch ins AzureAD repliziert. Hier gilt es zu unterscheiden, ob sie bei einer T2T-Migration nur das AzureAD-Konto umhängen aber das lokale AD unverändert belassen oder ob es neben der T2T-Migration in der Cloud auch noch lokal eine Umstellung gibt, z.B. eine Migration in einen anderen Forest oder Domain mit ADMT oder der zukünftige Verzicht auf eine lokale Domainmitgliedschaft des Computers
  • AzureAD-Joined
    Wenn das Gerät in der Quelle schon nur im AzureAD als Mitglied geführt wird, dann kann eine T2T-Migration bedeuten, dass der Computer in einen anderen Tenant umkonfiguriert wird oder vielleicht zuerst in einem lokalen AD neu aufgenommen wird um dann zu einem Hybrid AzureADJoined Device zu werden.

Geräte, die nur in einer AD-Domain aber nicht in Azure vorhanden sind oder reine "AzureAD Registered" Geräte betrachte ich nicht weiter.

Umstellen oder Neuaufbauen

Beim Wechsel des Tenants haben wie wie bei jeder Migration die Wahl, ob sie den Computer "irgendwie" aus der alten Umgebung auslösen und in die neue Umgebung unter Beibehaltung der aktuell Installation aufnehmen. In dem Fall werden Windows und die Applikationen nicht neu installiert. Der Vorteil ist, dass es vermutlich schneller geht aber sie sich vor allem die Nachinstallation von lokaler Software weitestgehend ersparen.

Die Herausforderung dabei sind aber insbesondere die Benutzerprofile auf dem Computer. Nach dem Umzug kann sich der bisherige Anwender so erst einmal nicht mehr anmelden, da der PC nicht mehr dem alten AzureAD vertraut. Meldet sich der Anwender mit dem neuen Konto an, dann ist Dies für den Computer ein ganz anderer Benutzer und dieser bekommt ein neues leeres Profil.

Sie können als Administrator dann natürlich die Daten aus dem alten Profil kopieren, was aber lange dauert und nicht die verschiedenen Einstellungen mitnimmt. Daher sollten Sie prüfen, ob sie vor der ersten Anmeldung des Benutzers mit seinen neuen Anmeldedaten nicht das vorhandene Profil entsprechend umschreiben. Für On-Premises-Umgebungen war das ADMT -Active Directory Migration Toolkit das häufig genutzt Tool. Es hilft aber bei AzureAD nicht weiter.

Natürlich können sie den PC auch einfach in der neuen Umgebung frisch installieren. ZeroConfig und AutoPilot sind hier die Stichpunkte, mit denen Sie Windows 10/11 auf einem PC sehr schnell installiert bekommen und auch als Mitglied in einer Domain oder dem AzureAD aufnehmen können. Allerdings sind dann alle Benutzerdaten und Profile gelöscht und auch Applikationen müssen nachinstalliert werden. Wer seine Clients "kennt", die Installation automatisiert hat und die Dateien sicher auf einem Server oder in der Cloud liegen, kann diesen Weg gehen.

AzureAD1 zu AzureAD2

Dieser Fall ist recht einfach durchzuspielen, das Sie nur einen Office 365 Tenant benötigen. Intune o.ä. ist nicht erforderlich. Ein Anwender des Tenants meldet sich auf einem Windows Client einfach an und nimmt den Computer in AzureAD auf, wenn dies noch nicht erfolgt ist. Eine Mitgliedschaft in einem lokalen Active Directory ist hier nicht vorgesehen. Wenn ich diesen Computer in einen neuen Tenant ohne Neuinstallation übertragen möchte, dann sind grob folgende Schritte erforderlich:

  • Anmelden als lokaler Administrator
    ggfls. muss ein entsprechendes Konto zuerst angelegt werden
  • Profil- und Datenexport
    Eine Übernahme von „Profilen“ ist nicht sichergestellt. Daher ist es wichtig, dass relevante lokale Daten entweder z.B. per OneDrive in die Cloud gesichert wurden und später migriert werden oder die lokalen Daten und das Profil wird anderweitig gesichert (z.B. Tool von https://www.forensit.com/)
  • Verlassen des AzureAD
    Dann kann der PC angewiesen werden, das AzureAD zu verlassen
Dsregcmd /leave
  • Umstellen des PCs
    Wenn noch nicht passiert, kann der PC nun im neuen Forst den Service Connection Point lesen oder mittels Gruppenrichtlinie den Ziel-Tenant zugewiesen bekommen.
  • Join ins AzureAD
    Sofern der Computer sich nicht allein im neuen AzureAD registriert, kann dies durch einen lokalen Benutzer angestoßen werden
Dsregcmd /join
  • Statuskontrolle
    Ob sich der Client korrekt angemeldet hat, ist ebenfalls per dsregcmd ermittelbar:
dsregcmd /status

Automatische Umschaltung?

Eine manuelle Umstellung kann ich sicher für wenige Geräte vor Ort durchführen. Wenn ich aber viele Geräte umzustellen habe, dann stellt sich die Frage der Automatisierung. Dazu müssen wir natürlich besser wissen, sie der Device Join in ein AzureAD im Grunde funktioniert. Das ist keine Magie und man muss nur wissen, wo Sie nachschauen können.

Es mag überraschend sein, aber Windows hat einen sehr leistungsfähigen Taskplaner und dort findet sich auch ein Task, der für den "Automatic-Device-Join" zuständig ist und bei jeder Benutzeranmeldung und einem Eventlog getriggert wird.

Im Grunde startet er auch nur ein "DSREGCMD.EXE", wenn sich ein Anwender anmeldet.

Ich habe schon Clients gefunden, bei denen dieser Dienst nach erfolgreichem Join auf "deaktiviert" gestellt wurde.

Ich bin aber noch nicht sicher, wann das genau passiert, denn DSREGCMD alleine scheint dies nicht zu tun.

Wenn ich eine Umstellung manuell durchführen kann, dann sollte das aber auch automatisch passieren. Solange also der Task aktiv ist, muss ich den Client nur in den Status bringen, dass er eben nicht AzureAD-Joined ist und sich dann an den neuen Tenant wendet. Den aktuellen Status bekommen Sie per Kommandozeile heraus.

Rem  Aktueller Status abfragen
PS C:\> dsregcmd /status

Mit dem Wechsel des Tenant muss der PC natürlich "umgehängt" werden. Die Verbindung zum alten Tenant lässt sich zum AzureAD einfach per Kommandozeile lösen.

PS C:\> dsregcmd /leave

Danach sollte der PC nicht mehr im AzureAD "joined" sein. Beachten Sie aber, dass ein PC sich normalerweise am einem Service Connection Point in ihrem lokalen AD orientiert, um sich wieder automatisch in ein AzureAD zu addieren. Wird der PC nicht zeitgleich in einen anderen AD-Forest verschoben sondern bleibt im gleichen lokalen AD, dann müssen Sie über lokale Richtlinien steuern, zu welchem Tenant er sich verbindet.

Wichtig: Damit diese Einstellung wirksam wird, müssen Sie den SCP entfernen!

Alternativ können Sie den SCP weglassen und per Gruppenrichtlinie die folgenden Werte entsprechend setzen

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
"TenantID"="<tenantid>"
"TenantName"="<tenant>.onmicrosoft.com"

Hier ein Beispiel, wie dies bei einem meiner Lab-Tenants aussieht.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\CDJ\AAD]
"TenantId"="604d9047-44e5-443a-ad8f-98abe5748b0a "
"TenantName"="msxfaqdev.onmicrosoft.com"

Zusammenfassung

Es ist möglich, einen Computer aus einem bestehenden AzureAD zu trennen und in ein anderes AzureAD neu aufzunehmen. Sie müssen dazu nur sicherstellen, dass..

  • ein Domain-Joined Computer aus dem lokalen AD eine passenden Service Connection Point oder Gruppenrichtline bekommt
  • Der Computer dann aus dem alten AzureAD entfernt wird
  • Der Task startet, um den PC wieder aufzunehmen

Kniffliger kann es aber werden, wenn sie gar kein lokales AD haben und daher SCP oder Gruppenrichtlinien nicht wirken können. In einer "Azure AD Joined"-Umgebung ohne lokale AD melden sich die Anwender ja entweder nur lokal oder direkt mit dem AzureAD-Konto an. Hier müssen Sie aufpassen, dass Sie durch die Loslösung aus der Quelle nicht alle Benutzerrechte verlieren und auch das Intnue-Management dann nicht mehr weiter hilft. Legen Sie sich auf jeden Fall vorab ein lokales Admin-Konto an.

Aufgrund der Weiterentwicklung kann es sein, dass die Beschreibung hier nicht mehr aktuell ist oder es bessere Wege gibt. Eventuell ist es aber auch einfach, die Clients komplett neu, z.B. mit Windows AutoPilot, zu installieren, um jegliche Verbindungen zum alten Tenant zu unterbrechen. Beachten Sie auch die enge Verzahnung eines Benutzers mit seinem Tenant auf Tentant2Tenant Client

Weitere Links