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"

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 Registrierungschlü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 Tenantwechsel 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