Von Exchange zu Office 365

Dieser Beitrag beschreibt die Migration von lokalen Postfächern zu Office 365 inkl. Synchronisierung der Benutzer mit dem lokalen Active Directory und Single-Sign-On.

Gegeben ist in diesem Beispiel eine Umgebung mit einem Exchange Server 2010 und über 500 Postfächern. Der Kunde möchte seine lokale Domäne weiter betreiben, jedoch ohne Exchange. Die Benutzer sollen vom lokalen AD in die Cloud synchronisiert werden. Gewünscht ist auch, dass an Domänenrechnern angemeldete Benutzer sich für Outlook oder SharePoint nicht erneut anmelden müssen.

Abklärungen

Synchronisierung der Benutzerkonten / SSO

Es stehen folgende Login-Methoden zur Wahl:

• Kennworthashsynchronisierung (PHS)
• Passthrough-Authentifizierung (PTA)
• Verbundauthentifizierung

Die Vor- und Nachteile der verschiedenen Verfahren sind unter https://docs.microsoft.com/de-de/azure/active-directory/hybrid/plan-connect-user-signin ausführlich beschrieben. Für uns kam nur die Kennworthashsynchronisierung in Frage, da die anderen Verfahren komplexer in Betrieb und Unterhalt sind und die Authentifizierung in Office 365 abhängig ist von der Verfügbarkeit der lokalen Infrastruktur. Man sollte jedoch auch mit Office 365 arbeiten können, wenn die lokale Infrastruktur nicht verfügbar oder vom Internet her nicht erreichbar ist.

Mit neuen Versionen von Windows und Office funktioniert SSO mit PHS. Man hat den Komfort der automatischen Anmeldung in Office 365 vom Domänenrechner aus, ohne aber das Login von der lokalen Infrastruktur abhängig zu machen. Das Verfahren ist unter https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso detailliert beschrieben.

Migration der Postfächer

Für die Migration der Postfächer gibt es mehrere Methoden, die auf https://www.msxfaq.de/cloud/betrieb/migration2office365.htm gut beschrieben werden. Wir haben uns für die Variante "PST-Import" entschieden. Diese ähnelt der Cutover-Migration, bei welcher aber ohne "Tricks" keine Synchronisation der Benutzer möglich ist, da diese vom Import-Tool angelegt werden. Hybrid kam nicht in Frage, da der lokale Exchange Server nach der Migration ausser Betrieb genommen werden sollte. Normalerweise würde man bei über 500 Postfächern keinen "alles auf einmal"-Weg wählen, aber uns kam entgegen, dass der Kunde eine Schule war und während dem zweiwöchigen Urlaub kein funktionierendes E-Mail benötigte.

Vorgehen

Azure AD Connect

Da die Benutzernamen in Office 365 weltweit eindeutig sein müssen, erfolgt die Anmeldung über den UPN, welcher eine öffentliche Domäne als Suffix haben muss. Diese Domäne muss bei Office 365 eingetragen sein, der Besitz muss also bestätigt werden. Sprich: der UPN muss der E-Mail-Adresse entsprechen. (Müsste theoretisch nicht, aber das wäre für die Benutzer unverständlich.)

Falls das Suffix im AD noch nicht erfasst ist, kann es mit dem Befehl

Get-ADForest | Set-ADForest -UPNSuffixes @{add="domain.ch"}

erfasst werden.

Die UPNs der bestehenden Benutzer können dann mit folgendem Script angepasst werden:

$LocalUsers = Get-ADUser -SearchBase "OU=Benutzer,DC=domain,DC=lan" -Filter {UserPrincipalName -like '*domain.lan'} -Properties userPrincipalName,EmailAddress
$LocalUsers | foreach {
    if($_.EmailAddress -and -not $_.EmailAddress -eq "")
    {
        $newUpn = $_.EmailAddress.ToLower()
    }
    else
    {
        $newUpn = $_.UserPrincipalName.Replace("domain.lan","domain.ch")
    }
    Set-ADUser $_ -UserPrincipalName $newUpn
}

Für die Benutzer ändert sich damit vorerst nichts, da lokal auch der sAMAccountName zur Anmeldung verwendet werden kann. Man kann sich am Rechner also immer noch als "domain\hmuster" anmelden. Nach der Umstellung funktioniert dann auch "hans.muster@domain.ch".

Zur Prüfung, ob die Benutzerkonten kompatibel mit Azure AD sind, gibt es ein Tool namens "IdFix": https://docs.microsoft.com/en-us/office365/enterprise/install-and-run-idfix In unserer Domäne wurden nur wenige User mit Sonderzeichen im UPN bemängelt.

Danach kann AAD Connect konfiguriert werden. Wichtig: das Attribut " msExchangeMailboxGuid" muss von der Synchronisation ausgeschlossen werden! Sonst erstellt Office 365 kein Postfach für den Benutzer, weil es davon ausgeht, dass dieser lokal schon eines hat. Das Vorgehen ist hier beschrieben: https://mikeparker365.co.uk/2016/01/07/how-to-filter-out-msexchmailboxguid-from-aad-connect-sync/

Nachdem die Synchronisation abgeschlossen wurde, sind die Benutzer im Office 365 Portal sichtbar. Es wurden jedoch noch keine Postfächer für sie erstellt, da sie keine Lizenz zugewiesen haben.

Der Befehl "Get-MsolAccountSku" zeigt die verfügbaren Lizenzen an. Mit folgendem Script kann man sie zuweisen und gleich noch die Spracheinstellungen für die Benutzer setzen:

$Cred = Get-credential "admin@kunde.onmicrosoft.com"

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $Session –AllowClobber

$mbs = Get-Mailbox -ResultSize unlimited | ? {$_.RecipientTypeDetails -eq "UserMailbox"}
ForEach ($mb in $mbs) { 
    $regionalconfig = Get-MailboxRegionalConfiguration –identity $mb.identity 
    if ($regionalconfig.Language -ne "de-CH" ) {
        $mb.identity
        Set-MailboxRegionalConfiguration -identity $mb.identity -Language "de-CH" -DateFormat "dd.MM.yyyy" -TimeFormat "HH:mm" -TimeZone "W. Europe Standard Time" -LocalizeDefaultFolderName
    }
}

Connect-MsolService -Credential $cred

Get-MsolUser -All -UnlicensedUsersOnly | Set-MsolUser -UsageLocation "CH"
Get-MsolUser -All -UnlicensedUsersOnly | Set-MsolUserLicense -AddLicenses "schulexy:STANDARDWOFFPACK_STUDENT"

Nachdem die Benutzer eine Lizenz zugewiesen bekommen haben, wird ihr Postfach automatisch innert weniger Minuten erstellt.

Postfachmigration

Die E-Mails können beim Export nach Datum gefiltert werden. Man kann also in einem Schritt alle E-Mails exportieren, testen und dann nach Umstellung des MX-Records eine Woche später die E-Mails der letzten Woche nachziehen. Beides kommt im Script vor:

$mbs = Get-Mailbox -OrganizationalUnit domain.lan/Benutzer

foreach($mb in $mbs) {
	if(!(Test-Path "\\server\mailboxexport\diff\$($mb.alias).pst")) {
		#New-MailboxExportRequest $mb -FilePath "\\server\mailboxexport\$($mb.alias).pst"
		New-MailboxExportRequest $mb -FilePath "\\server\mailboxexport\diff\$($mb.alias).pst" -ContentFilter {(Received -gt "04/26/2019 00:00:00 AM") -and (Received -lt "04/27/2019 00:00:00 AM") -or (Sent -gt "04/26/2019 00:00:00 AM") -and (Sent -lt "04/27/2019 00:00:00 AM")}
	} else {
		Write-Host "Datei $($mb.alias).pst existiert schon!"
	}
}

Durch einen Bug muss zumindest bei Exchange 2010 die Ländereinstellung von Windows auf "Englisch (US)" eingestellt werden, bevor man die PowerShell öffnet. Ansonsten können die Datumseingaben nicht verarbeitet werden.

Für den Import bei Office 365 muss eine Zuordnungsdatei (CSV) erstellt werden. Das geht mit folgendem Script:

$files = Get-ChildItem "\\server\MailboxExport" -Filter *.pst
$csv = "C:\temp\usermapping.csv"
Add-Content -Path $csv "Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,ContentCodePage,SPFileContainer,SPManifestContainer,SPSiteUrl"

foreach($file in $files) {
    $user = Get-ADUser $file.BaseName -Properties userPrincipalName
    Add-Content -Path $csv "Exchange,,$file,$($user.userPrincipalName),FALSE,/,,,,"
}

Der Importvorgang ist hier ausführlich beschrieben: https://docs.microsoft.com/en-us/office365/securitycompliance/use-network-upload-to-import-pst-files

Wichtig: Für diesen Schritt unbedingt genügend Zeit einplanen. Der Import startet manchmal erst nach einigen Stunden, je nachdem wie viel Kapazität auf den Servern von Microsoft dafür frei ist. Die Postfächer in unserem Fall waren total nur 26 GB gross, trotzdem hat der Import fast 48 h gedauert!

Umstellung

Nach dem Import aller Postfächer kann man den MX umstellen, die Autodiscover-Einträge im DNS erstellen und den internen SCP entfernen. Letzteres ist wichtig, da die internen Clients sonst noch zum alten Exchange verbinden. Den SCP entfernt man mit:

Set-ClientAccessServer –Identity ServerName -AutoDiscoverServiceInternalUri $null

Danach kann man bei Bedarf die geänderten bzw. neu hinzugekommenen Mails als PST exportieren und in Office 365 importieren.

Damit SSO funktioniert, muss man (zum Beispiel per GPO) noch " https://autologon.microsoftazuread-sso.com" der Intranetzone vom Internet Explorer bzw. deren Pendant in anderen Browsern hinzufügen. Unter https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start ist das Vorgehen gut erklärt.

Bei Office 2013 muss "Modern Authentication" in der Registry aktiviert werden, siehe https://social.technet.microsoft.com/wiki/contents/articles/32211.modern-authentication-behavior-across-office-2013-and-office-2016.aspx.

Anmerkungen

Verhalten der Clients

Bestehende Outlook-Clients werden beim nächsten Start einen Autodiscover-Vorgang starten und nach einiger Zeit melden, dass der Administrator eine Änderung vorgenommen habe, welche einen Neustart von Outlook erfordere. Nach dem Neustart sind sie mit Office 365 verbunden. Bei Outlook 2010 muss das Passwort von Hand eingegeben werden, da es kein SSO unterstützt.

Beim ersten Start von Outlook ohne eingerichtetes Profil wird die E-Mail-Adresse angezeigt. Ein Klick darauf und das Konto wird eingerichtet.

Bei OWA und OneDrive müssen auch Benutzer an Domänenrechnern ihre E-Mail-Adresse eingeben. Dies, weil der Server nicht wissen kann, gegen welche Domäne er authentifizieren soll. Mittels spezieller Links lässt sich das umgehen:

• Outlook Web Access: https://outlook.office.com/domain.ch
• OneDrive: https://domainch.onedrive.com (wobei "domainch" der Tenant-Name ist, der Teil vor ".onmicrosoft.com")

Ausserbetriebnahme des Exchange Servers

Zur Zeit befindet man sich mit der gezeigten Umgebung in einer nicht unterstützen Konfiguration, wenn man den Exchange Server ausser Betrieb nimmt.

Da die Benutzer vom lokalen AD stammen, kann man in Office 365 keine Eigenschaften wie E-Mail-Aliase, Weiterleitungen etc. anpassen. Diese Anpassungen müssen lokal erfolgen und werden dann synchronisiert. Nur gibt es ohne Exchange keine offizielle Möglichkeit, diese Sachen anzupassen. Es geht jedoch schon, zum Beispiel per ADSI Edit. Die offizielle Möglichkeit ist jedoch, weiterhin einen Exchange Server lokal zu betreiben. Für diesen gibt es die Lizenz kostenlos, wenn er keine Postfächer beherbergt. Es gab schon verschiedentlich Gerüchte, dass Microsoft ein anderes Tool zur Verwaltung der Benutzer veröffentlicht. Bis jetzt ist das leider noch nicht passiert.