Tentant2Tenant Client

Bei einer Tenant2Tenat Migration darf der Fokus nicht nur auf den Identitäten und Daten in der Cloud liegen, die übertragen werden sollen, sondern auch die Clients sind immer enger mit der Cloud verzahnt. Wenn Sie  einen Benutzer in einen neuen Tenant umstellen, müssen Sie daher auch Aktionen auf dem Client durchführen. Früher, ohne Cloud, konnte man Clients mit ADMT -Active Directory Migration Toolkit, zwischen Domänen und Forests verschieben und damit auch Benutzerprofile u.a. umstellen.

Windows Desktop Client

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.

Ein Windows PC kann ja nicht nur im lokalen AD ein Member-System sein sondern auch in Azure einen der vier Status einnehmen:

  • Nicht bekannt
  • AzureAD Registered
  • AzureAD Joined
  • Hybrid AzureAD Joined

Zusätzlich kann ein Anwender auch noch weitere "Konten" verbinden"

Den aktuellen Status bekommen Sie auch 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!

Windows Registry Editor Version 5.00

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

Windows Profil

Auf dem lokalen Windows PC finden sie im Dateisystem unter %userprofile% und in der Registrierung als "HKEY_CURRENT_USER" das Benutzerprofil. Je nach Form ihrer Migration gibt es hier unterschiedliche Szenarien.

Szenario Beschreibung

AAD Hybrid Joined ohne AD-Migration

Wenn ihre PCs "Azure Hybrid Joined" sind, dann melden sich die Anwender immer noch an einer lokalen Domain an. Wenn Sie nun die Daten aus einem Tenant zum anderen Tenant umziehen, dann ändert sich das das lokale AD-Konto samt SID erst einmal nicht. Auch die Änderung des UPN hat keinen Einfluss auf das AD-Profil, so dass in dem Fall keine Änderung zum Profil direkt zu erwarten ist.

Allerdings stehen in diesem Profil natürlich die alten AzureAD-Daten mit drin, die pro Applikation angepasst werden müssen. Dies beschreibe ich weiter untern.

AAD Hybrid und AD-Migration

Etwas anders sieht es aus, wenn Sie nicht nur den Benutzer im Tenant umziehen, sondern parallel auch ein lokales AD-Konto umgezogen wird. Das neu angelegte der mit ADMT migrierte Konto im neuen Forest würde ja per ADSync dann auch in den neuen Tenant repliziert werden. Für den lokalen PC ist das natürlich ein komplett neuer Benutzer.

Natürlich gibt es Programme wie "USMT" oder Tools das Profil umzuschreiben. Ob Sie diese nutzen können oder wollen, wäre individuell zu prüfen. Auch die Verknüpfungen zum AzureAD-Konto, z.B. die Office 365 Lizenz, sind zu aktualisieren.

Ein besonderes Augenmerk ist hier auf ADSync und Computerkonten zu sehen. Wenn ein Computer zuerst im AzureAD registriert ist, kann er z.B. nicht mehr einfach in ein lokales AD aufgenommen werden.

AzureAD-Joined

Es gibt schon Systeme, die gar nicht mehr als Mitglied im lokalen AD geführt werden. Das Benutzerprofil ist daher nicht mit einer Domain-SID o.ä. verbunden. Wird der Client nun in ein anderes AzureAD umgehängt, kann sich der alte Benutzer erst einmal nicht mehr online anmelden und wenn er sich als neues Konto anmeldet, kann der Desktop den Benutzer nicht zuordnen.

Die Fragestellungen rund um das Benutzerprofil sind aus meiner Erfahrung doch sehr individuell und nicht pauschal zu beantworten. Vielleicht kann ich später eine eigene Seite dazu erstellen.

Die weiteren Abschnitte beschäftigen sich mit der Konfiguration und Einstellung von Programmen innerhalb des Profils.

Teams

Mit dem Umzug eines Benutzers in einen anderen Tenant verliert auch Teams die Verbindung. Das passiert sogar, wenn der Anmeldename (UPN) des Anwender gleich bleibt, denn Teams speichert im lokalen Cache anscheinend eine GUID und nicht den UPN. Wenn ich einen Benutzer mit dem gleichen Anmeldenamen nach dem Umzug in einem anderen Tenant wieder Teams starten lasse, dann sieht er folgenden Fehler:

Teams behauptet, dass er den User nicht in dem alten Tenant findet. Das ist an sich richtig, aber Teams ist nicht smart genug, dann eine Art "Autodiscover" durchzuführen. Teams versucht es immer wieder. Nach ca. 12? Neustarts scheint Teams dann den Weg aufzugeben. Ob und wann Microsoft dies ändert, weiß ich nicht aber für den Anwender ist es immer zu oft und führt zu Rückfragen beim Helpdesk. Daher ist es besser, eine Lösung beim Umzug gleich mit einzubauen.

Sie müssen dazu aber nicht Teams selbst deinstallieren, sondern nur den Cache leeren. Teams ist als "Moderne App" ja nicht mehr pro Computer, sondern pro Anwender installiert und speichert auch die Konfiguration nicht in der Registrierung ab.

==================Client Tenant Change=========
rd "%appdata%\Microsoft\Teams\Cache"
rd "%appdata%\Microsoft\Teams\blob_storage"
rd "%appdata%\Microsoft\Teams\databases"
rd "%appdata%\Microsoft\Teams\GPUCache"
rd "%appdata%\Microsoft\Teams\IndexedDB"
rd "%appdata%\Microsoft\Teams\Local Storage"
rd "%appdata%\Microsoft\Teams\tmp"
rd "%appdata%\Microsoft\Teams\preauth

Die Teams Programmdaten in %localappdata%\Microsoft\Teams müssen Sie hingegen nicht löschen.

Wenn Sie verhindern möchten, das Microsoft Teams automatisch den UPN des gerade angemeldeten Benutzers ausfüllt, dann hilft folgender Registrierungsschlüssel:

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Teams]
"HomeUserUpn"="frank.carius@netatwork.de"
"SkipUpnPrefill"=dword:00000001

Office Apps

Über die Office 365 Anmeldung bekommen auch die lokal installierten Office Applikationen (Word, Excel, PowerPoint, Outlook etc.) ihre Lizenz. Mit dem Wechsel des Tenants durch den Anwender bricht natürlich auch diese Zuordnung. Die Office Apps können mit dem bestehenden Benutzer nicht mehr anfangen, selbst wenn der UPN in den neuen Tenant mit umzieht und zeigen z.B. folgenden Fehler:

Das Problem tritt nicht auf, wenn sich der Anwender vor dem Umzug an Office "abgemeldet" hat. Nach dem Umzug reicht es, wenn der Anwender die vorgeschlagene "Reparatur" durchführt. Sie können dies aber auch per Skript automatisieren, wenn Sie den Client nach dem Umzug noch verwalten können.

An dem Konto hängen übrigens auch die "Last recently Used-Links", die mit dem Umzug auch nicht mehr gültig sind, denn auch die OneDrive-Pfade haben sich durch den Tenant-Wechsel geändert.

Outlook/Exchange Profil

Wenn das Postfach vorher im alten Exchange Online Tenant gelegen hat, dann verweisen natürlich die verschiedenen Profile auf das Postfach. Es hängt nun auch davon ab, wie sie migriert haben und welcher Client sich verbindet. Nach dem Umzug hat sich die MailboxGUID und die TenantID auf jeden Fall geändert. Der UPN kann gleich geblieben sein und der "Client Zugriffspunkt" bleibt mit "outlook.offce.com" auch identisch. Denn noch passen natürlich die auf dem Client vorgehaltenen OAUTH-Zertifikate nicht mehr zum Benutzer nach dem Umzug.

Einige Clients sind "smart" genug und erkennen, dass gerade gar nichts mehr passt und starten eine Ersteinrichtung, die dank Autodiscover funktionieren kann. Andere Clients kleben an der alten Konfiguration fest und brauchen manuelle Hilfe.

Bei Outlook ist die OST-Datei noch interessant, die eine "Offline-Kopie" des alten Postfach enthält. Es könnte sein, dass der Anwender während der "offline-Zeit" ein paar Termine und Kontakte angelegt und Mails vorbereitet hat. Theoretisch können Sie den Inhalt einer OST-Datei sogar wieder mit einem anderen Postfach verbinden, wenn bei der Migration auch die "Schlüsselinformation" im Postfach mit migriert wurde. Davon würde ich aber eher nicht ausgehen, dass dies funktioniert.

Daher sind sie gut beraten, dass die Mitarbeiter mit Start des Umzugs nichts mehr ändern ("Frozen Zone") und nach Abschluss ein neues Profil einrichten. Die erste Replikation der Mails wird natürlich etwas die Leitungen glühen lassen. Das alte Profil können Sie dann samt OST-Datei entfernen lassen.

Mobile Client

ActiveSync-Clients haben beim Einrichten der Partnerschaft einen Schlüssel ausgetauscht. Über die ActiveSync Quarantäne oder Conditional Access können Sie sehr gut steuern, welche Geräte sich verbinden dürfen. Da diese Informationen nicht migriert werden, steht auch hier ein Löschen der bestehenden Konfiguration und eine Neukonfiguration an. Prüfen Sie, inwieweit ihnen dabei Intune oder einer anderen MDM-Lösung bei der Verteilung von Profilen helfen kann.

Der "Gerätewechsel" selbst ist natürlich auch noch eine Aufgabe für die MDM-Plattform, der individuell betrachtet werden muss. Im schlimmsten Fall läuft es auf ein "Wipe" mit Neueinrichtung hinaus.

OneDrive und Dateien

Die Cloud dient auch immer mehr als "Dateiserver" aber über die langen "WAN-Leitungen" kann es länger dauern. Daher ist der Einsatz des OneDrive-Clients sinnvoll um die eigenen und häufigen anderen Dateien lokal in einem Cache vorzuhalten. Dieser Cache ist natürlich mit ihrem Benutzernamen verbunden und nach dem Wechsel des Tenant hat sich sowohl ihre BenutzerID als auch der Pfad zum persönlichen OneDrive geändert. Aus einem "https://<tenantalt>-my.sharepoint.com" wurde ein "https://<tenantneu>-my.sharepoint.com" und auch die gemeinsamen Dokumentbibliotheken haben eine neue URL.

Die Herausforderung bestehen nun darin, dass zum einen die Verknüpfung aufgehoben und neu eingerichtet wird. Für den Anwender wäre es natürlich am einfachsten, wenn die lokalen Pfade identisch bleiben würden. Dann besteht aber das Risiko, dass Dateien doppelt erscheinen, wenn bei der Migration die Inhalte auch im Backend kopiert wurden.

Auf eine Migration auf dem Client würde ich mich aber nicht verlassen, denn sie können ja nicht sicher sein, dass ein Anwender sein "komplettes OneDrive" als lokale Kopie vorhält und selbst dann wäre die Rückreplikation in die Cloud vermutlich sehr langsam. Gerade DSL-Leitungen sind ja asynchron, d.h. schneller Download und weniger Upload.

Eine OneDrive Daten-Migration muss daher immer serverseitig erfolgen. Der Anwender sollte dann seinem "Netzwerk" trauen und folgende Schritte durchführen:

  • OneDrive Verbindung kappen
    Damit endet die Synchronisierung aber die lokalen Daten bleiben natürlich erhalten.
  • Lokale Dateien entfernen
    Um die spätere Neueinrichtung nicht zu torpedieren, wird das persönliche OneDrive-Verzeichniss geleert. Die vorsichtigeren Naturen verschieben die Dateien einfach an einen anderen Ort, wenn die lokale Festplattenkapazität ausreicht. Das gemeinsame OneDrive sollten Sie aber löschen, denn der neue Tenant heißt ja auch anders und bekommt daher einen anderen Dateinamen.
    Wenn Sie die Dateien nicht dem Benutzer entziehen, besteht das Risiko, dass er weiter mit den alten Dateien arbeitet, die aber nicht mehr synchronisiert werden.
  • OneDrive-Partnerschaft neu einrichten
    Mit der Verbindung zum neuen Tenant wird das persönliche OneDrive idealerweise wieder mit dem gleichen Pfad verbunden und die Replikation der Struktur startet. OneDrive holt wie bisher dann dynamisch die genutzten Dateien oder der Anwender kann auch manuell wieder ein "Immer Offline" auswählen. Die Replikation kann natürlich etwas dauern.

Diese Beschreibung passt für die "normalen Dateien". Wer aber auch seine DefaultOrdner (Desktop etc.) eingebunden hat oder mit Ordnerumleitungen arbeitet, muss noch mal genauer hinschauen.

In den Dokumentationen von Microsoft finden Sie Hinweise auf die Auswirkungen eines UPN-Wechsels z.B. aufgrund eines Namenswechsels (Heirat/Scheidung). Dabei bleibt aber der GUID des Benutzers gleich und die Fehler sollten nach einigen Stunden verschwinden, wenn die Änderung überall aktiv geworden ist.

"The sync app (on both Windows and Mac) will automatically switch to sync with the new OneDrive location after a UPN change. While the UPN change is propagating through your environment, users may see an error in the OneDrive sync app that "One or more libraries could not be synced." If they click for more information, they will see "You don't have permission to sync this library." Users who see this error should restart the sync app. The error will go away when the UPN change has been fully propagated and the sync app is updated to use the user's new OneDrive URL."
https://docs.microsoft.com/en-us/onedrive/upn-changes

Das passt aber nicht für Tenant Wechsel.

Sonstiges Apps

Der Schwerpunkt dieser Seite liegt auf den "häufigen Clients". Natürlich gibt es noch andere Angebote von Microsoft wie z.B. Dynamics oder Drittherstellern, die auf AzureAD und dessen Authentifizierung aufsetzen. (OAUTH). Daher ist eine gute Ist-Aufnahme und ein Testfeld für eine Tenant2Tenant-Migration unerlässlich. Bei den Kosten für eine DNS-Domain sollte es aber kein Problem sein, eine zusätzliche Domain an den alten Tenant zu hängen und ein paar Test-Clients und Benutzer samt Applikationen, Daten und Konfiguration aufzubauen, die dann in den neuen Tenant migriert werden. So können Sie verifizieren, dass Sie an alles gedacht haben und welche manuellen Schritte durch die Anwender erforderlich sind.

Weitere Links