Haben sie sich schon einmal gefragt was passiert, wenn man einen User in der Cloud mit Dirsync“zer-synct”?
Also ganz zu Anfang mal, was heißt “zer-synct”? Ich glaub jeder IT-Admin kennt das. Jeder Benutzer hat seine Mailbox, meist mit rund 5 Geräten (Handy, Tablet, Notebook, StandPC,…) die damit syncen und da kanns schon mal vorkommen dass man durch einen kleinen Fehlgriff oder durch den absolut unwahrscheinlich Fall eines Bugs beim Sync doppelt, dreifach oder einfach leere Mailboxen produziert.
Dasselbe kann in Einzelfällen und durch absolut unmögliche Zufälle auch mit Accounts im Fall eines DirSyncs passieren. Also stelle man sich einfach mal folgende Situation vor:
Historie
Ein Kunde hatte bisher keine Hybrid Umgebung sondern eine lokale Umgebung für User in Österreich sowie einen Office 365 Tenant für User in weiteren Standorten. Jeder Mitarbeiter in den Aussenstandorten hat zwar einen lokalen AD User aber keine Mailbox. Der Grund dafür ist einfach: Die Mailbox wurde extern gehostet und der User benötigt aber Terminal Server Zugriff und daher einen OnPrem-Account.
Somit gibt es nun eine doppelte Wartung, die historisch gewachsen ist. Bisher gab es eine strenge Trennung zwischen den Welten.
Nun Hybrid
Nun wird der Standort Österreich jetzt ebenfalls in denselben Tenant migriert. Somit baut man eine Hybrid Umgebung auf, synchronisiert die User per Dirsync rauf und ignoriert dabei alle Gemeinsamkeiten. ähhhh.. jo..
Es kommt gerade bei solchen Szenarien gern mal vor, dass ein User der OnPrem existiert auch in der Wolke vorhanden ist und vielleicht auch Gleichheiten bei Mailadressen auftreten. Wie man das Matching konkret von bestehenden Usern macht bzw. nachträglich bereinigt wurde ja schon Mal in Forever Immutable – ID gefällig - oder - Dirsync extended beschrieben.
Aber in gewissen Fällen kommt dabei etwas ganz Interessantes raus. Ein User OnPrem hat eine produktive Mailbox in der Cloud die durch SMTP Matching auf einen falschen Account matched. So passiert, weil ein disabled Account (ausgetretener Mitarbeiter) seine Mailadresse an einen anderen User abtreten musste und damit beim Matching der korrekte Mitarbeiter plötzlich die “alte” Mailbox vom Cloud User bekommen hat. Eher “blöd”… die produktive Mailbox ist jetzt .. weg oder auch “zer-synct” ... Oder?
PowerShell hilft
Wie immer, löst Powershell viele Probleme und kann uns bei der Lösungsfindung unterstützen.
Zunächst verbinden wir uns wie gewohnt per Remote Powershell auf den Exchange O365 Tenant.
$OnlineCred = Get-Credential -Message 'O365 Admin Account'
Import-PSSession ( New-PSSession -ConfigurationName microsoft.exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $OnlineCred -AllowRedirection -Authentication Basic ) –AllowClobber
Per einfachem Powershell Command sehen wir nach, ob die Mailbox nicht vielleicht gelöscht wurde:
Siehe da – hier ist sie ja…
Sollte die Mailbox nicht gelöscht sein oder hier auftauchen, dann einfach etwas warten (dauert so ca. 2.4 – 2.6 Minuten bis der gelöschte MSOL User zum O365 Tenant durchschlägt). Alternativ hilft es zu überprüfen, ob nicht vielleicht die Mailadresse auf einem anderen User drauf war und deshalb zum Beispiel auf einem anderen User gelandet ist.
Mir ist zum Beispiel aufgefallen dass ein User beim RawName sein Kürzel stehen hat und beim LegacyExchangeDN ein _anderer_ RawName am Ende steht. (Im Screenshot ist das richtig, aber ich kann das Echt-Beispiel leider nicht herzeigen…)
Dann ist das Prinzip auch recht einfach. Den “falschen” MSOL User einfach löschen (und damit die Mailbox) und dann landet die Mailbox auch im Papierkorb aus dem wir sie jetzt wieder zurückholen können.
WICHTIG: Wir brauchen die GUID! (siehe Screenshot oben)
Es gibt aber einen einfachen Weg per New-Mailbox:
New-Mailbox -Name RESTORE -RemovedMailbox fc3fdfb1-a282-40ed-8558-1b1ba89d7d03 -Password $(ConvertTo-SecureString -AsPlainText -String 'Pa$$w0rd' -Force) -DisplayName RESTORE -PrimarySmtpAddress restore@atworkdemo365.onmicrosoft.com
Mit dem Parameter –RemovedMailbox kann man mit Angabe der GUID die gelöschte Mailbox einfach auf einen neuen Account hängen.
Jetzt – wieder so ca. 2.4 Minuten warten bis der Account als Cloud Account in der MSOL Powershell auftaucht. Und nicht vergessen, dem User eine Lizenz zuweisen (sonst wird die Box ja wieder gelöscht).
Ebenso eine Immutable ID setzen (wie schon im Artikel Forever Immutable – ID gefällig - oder - Dirsync extended beschrieben) damit der “richtige” Account jetzt trifft und ganz wichtig: Den UPN kontrollieren – der sollte auf jeden Fall dem des OnPrem Users entsprechen. Sonst einfach per Powershell setzen:
Set-MsolUserPrincipalName -UserPrincipalName Restore@atworkdemo365.onmicrosoft.com -NewUserPrincipalName OnPremUser@2und40.at
Einfach richtig leicht oder?
LG Christoph