Nach einer vollständigen Migration von einem lokalen Exchangeserver auf Office 365 kann man den lokalen Exchange Server deinstallieren. Damit ist er aber auch nicht mehr für Mails von Geräten wie Kopierern (Scan to email) oder Meldungen über Mail von der Firewall, dem Backup und ähnlichem verfügbar.

Microsoft schlägt für diesen Fall gemäss diesem Technet Artikel 3 mögliche Varianten vor.

Der beste Weg ist “Client SMTP Submission”, wenn das Gerät dies unterstützt, was nicht für alle Geräte zutrifft. In dem Fall authentifiziert sich das Gerät an Office 365, wie wenn sich ein Benutzer über OWA anmelden würde. Damit ist sichergestellt, dass die Verbindung zu Office 365 verschlüsselt stattfindet und nicht durch einen Spamfilter gefiltert wird.

Dazu muss man ein Benutzerpostfach in Office 365 für das Gerät (oder alle Geräte) erstellen. Das Passwort soll für diese Postfächer am besten gar nie ablaufen.

Dann trägt man die Benutzerdaten bei dem Gerät ein, wenn es dies unterstützt. Im Bild unten als Beispiel unsere Firewall (Sophos UTM). Unter “Management” –> “Notifications” kann man auf der Registerkarte “Advanced” einen externen SMTP Server angeben. Hier muss man den dafür vorgesehenen SMTP Server von Office 365 (smtp.office365.com) , den Port 587 mit TLS und die vorher angelegten Benutzerdaten eintragen.

Für Geräte, die diesen Weg nicht unterstützen, empfiehlt Microsoft den Weg “SMTP Relay”. Dabei muss man die IP-Adresse, über die das Gerät seine Mails verschickt in Office 365 bekannt gemacht werden. Danach erlaubt der Mailserver von Office 365, dass Mails von dieser IP über ihn geschickt werden (sogenanntes Relaying). Dabei kann aber nicht sichergestellt werden, dass die Verbindung verschlüsselt abläuft.

Viel eleganter ist es aber, wenn man für diese Geräte die Sophos UTM (oder irgend ein anderes Gerät, das dies kann) als SMTP Server einträgt. Somit werden auch die Mails von diesen Geräten wie oben beschrieben verschlüsselt durch das Internet übertragen. Bei der UTM muss man die oben schon beschriebenen Daten auch bei „Email Protection“ -> „SMTP“ -> Registerkarte „Advanced“ -> „Smarthost Settings“ eintragen, damit auch alle an die UTM übergebenen Mails weitergeleitet werden. Bei “Smarthost” kann der gleiche Eintrag wie oben bei “Notifications” genommen werden.

Ausserdem muss man unter “Email Protection” –> “SMTP” –> Registerkarte “Routing” die Route umstellen. Vorher war bei mir “Route by: Static Host List” ausgewählt und als Host der lokale Exchangeserver eingetragen. Neu habe ich “Route by: MX records” ausgewählt. Dies bedeutet, dass ein Mail an eine der aufgeführten Domänen an den MX record von der Domäne weitergeleitet wird (das ist dann ein Server von Office 365). Ausgeliefert werden alle solchen Mails über den Smarthost von oben und daher TLS verschlüsselt. Ziel erreicht.

Hier ein Beispiel eines Kopierers, der seine Mails an die UTM weitergibt.

zurück zur Übersicht

In diesem Video wird erklärt, welche Funktionen der Office 365 Plan für unsere Schule beinhaltet.

zurück zur Übersicht

Wir haben ein paar Mailaccounts, deren Passwort nie ablaufen sollte, wie z.b. der Account unter dem die Kopierer ihre Scans per Mail verschicken oder die Telefonanlage ihre Voicemail-Aufzeichnungen. Im Office 365 Portal gibt es nur die Möglichkeit eine Zeit zwischen 14 und 730 Tagen einzustellen, aber keine, damit das Passwort nie geändert werden müsste.

Dies lässt sich aber über die Powershell erledigen. Ich bin diesem Technet-Artikel gefolgt. Als erstes muss man den Microsoft Online Services-Anmelde-Assistenten für IT-Experten RTW und Azure Active Directory-Modul für Windows PowerShell (64-Bit-Version) installieren. Man sollte diese Programme aber nicht auf dem Server installieren, auf dem DirSync ausgeführt wird. Bei mir funktionierte danach DirSync nicht mehr.

Nun kann man das neu installierte “Windows Azure Active Directory-Modul für Windows PowerShell” starten und sich mit Office 365 verbinden.

connect-msolservice

Nun kann man gemäss dieser Seite mit folgendem Befehl festlegen, dass das Passwort des entsprechenden Benutzers nicht mehr abläuft.

Set-MsolUser -UserPrincipalName <user ID> -PasswordNeverExpires $true

Nachtrag:

Neu kann man das gleiche mit MgGraph erreichen:

Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All"
Update-MgUser -UserId user@contoso.com -PasswordPolicies DisablePasswordExpiration

Um zu überprüfen, ob bei einem Account eingestellt ist, dass das Passwort nie abläuft, kann man diesen Befehl verwenden.

Get-MgUser -UserId user@contoso.com -Property UserPrincipalName, PasswordPolicies |
Select-Object UserPrincipalName,@{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

zurück zur Übersicht

Standardmässig werden von DirSync alle Benutzer synchronisiert. Diese Benutzer können dann für das Abrufen der Mails von Office 365 das Passwort benutzen, das sie auch für die Anmeldung innerhalb des Netzwerks benutzen. Bevor das Passwort abläuft, werden sie am Computer aufgefordert, dieses zu ändern.

Wir haben aber Mailaccounts für Schulratsmitglieder, Sekretariatsmitarbeiter/-innen und andere, die nie an einem Computer innerhalb des Schulnetzwerks arbeiten. Damit diese eine Mailadresse erhalten, mussten wir einen Benutzeraccount im AD anlegen. Das Passwort konnten sie von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem dieses abgelaufen war. Für diese Benutzer erstellt man besser nur in Office 365 einen Account und löscht den lokalen nach der Migration des Postfachs.

Um in DirSync die OU’s herauszufiltern, die man nicht synchronisiert haben möchte, kann man im “Synchronization Service Manager” “Management Agents” und dann den “Active Directory Connector” auswählen und dann auf “Properties” klicken. In dem sich öffnenden Fenster wählt man “Configure Directory Partitions” und dann “Containers…”

Man muss sich dann mit Benutzernamen und Passwort mit Administratorberechtigungen für das lokale AD anmelden. Den voreingestellten Benutzernamen kann man einfach überschreiben.

Hier kann man nun alle Häklein ausser bei den gewünschten OU’s entfernen.

Nachdem sollte man einen “Full Import Full Sync” ausführen. Die Accounts in den nicht mehr synchronisierten OU’s werden dabei in Office 365 gelöscht. Diese können nun manuell als nicht synchronisierte “cloud only” Accounts in Office 365 angelegt werden.

Man kann übrigens solche nicht synchronisierte Accounts ganz normal über einen Migration-Batch in die Cloud migrieren. Nur die Mailadresse muss stimmen, die Accounts müssen lokal und in Office365 nicht einmal das gleiche Passwort besitzen.

zurück zu Teil 5: Benutzer migrieren

zurück zur Übersicht

Bei der Installation von Office auf Computern kann man die einzelnen Komponenten mit dem “Office Customization Tool” (OCT) anpassen. Damit die Benutzer kein eigenes Profil für Outlook erstellen müssen, habe darüber ein Profil verteilt, das den lokalen Exchangeserver als Server eingetragen hat.

Für Benutzer, die Outlook noch nie geöffnet haben, wird beim ersten Öffnen von Outlook ein Profil erstellt. Wenn nun solche Benutzer nach Office 365 migriert werden, erstellt Outlook automatisch die neuen Einträge wie in diesem Artikel ganz unten beschrieben.

Wenn nun aber ein Benutzer bereits nach Office 365 migriert ist, bevor er das erste Mal Outlook geöffnet hat, wird beim ersten Start versucht, die Verbindung mit dem lokalen Exchangeserver, der über das Office-Anpassungstool (OCT) eingetragen wurde, herzustellen. Das geht aber nicht und Outlook lässt sich dann nicht öffnen.

Um diesen Fall aufzufangen, kann man mit dem OCT eine MSP-Datei erstellen, die sich verteilen lässt. Da bei der Installation von Office damals OCT benutzt wurde, kann man einfach die Installationsdateien z.B. auf eine virtuelle Maschine kopieren und “setup.exe /admin” ausführen.

Wenn man nun unter “Outlook-Profil” –> “Vorhandenes Profil verwenden:” auswählt, wird nichts an bereits eingerichteten Profilen geändert, aber bei der Neuerstellung von einem Profil kommt die Abfrage und es wird nicht mehr versucht, mit dem voreingestellten lokalen Exchangeserver Kontakt aufzunehmen.

Ich ändere gerade auch noch die Einstellung für den Cachemodus (aus anderen Gründen).

Über “Datei” –> “Speichern” kann man die Einstellungen als MSP-Datei speichern und diese z.B. mit SCCM verteilen. Das Programm könnte z.B. lauten:

msiexec /p Office365.msp /qn

Wenn sich nun ein Benutzer zum ersten Mal anmeldet, kommt wie gewünscht der Start-Assistent.

Da kann man sich durchklicken, bis zur Anmeldung. Hier muss man als Benutzernamen die vollständige Mailadresse und das Passwort eingeben.

Wenn das Postfach bereits eingerichtet ist, der Benutzer also Outlook schon einmal geöffnet hat, ändert sich nichts, man muss den Assistenten nicht durchklicken.

zurück zu Teil 5 „Benutzer migrieren“

zurück zur Übersicht

Es gibt verschiedene Wege, die Benutzer auf Office 365 zu migrieren. Mit dem Exchange 2013 Server Deployment Assistant kann man herausfinden, welche Migration für die eigene Umgebung in Frage kommt.

In meinem Fall mit mehr als 1’000 Accounts und einem Exchange 2007 Server wählt man die sogenannte “Staged Exchange Migration”.

Die “Staged Exchange Migration” kann sich über mehrere Wochen oder sogar Monate hinziehen. Wichtig ist, dass bis zum Abschluss der Migration die öffentlichen DNS-Einträge (Autodiscover-  und MX-Einträge) auf den lokalen Exchange Server zeigen. Dies bedeutet zwar, dass im Office 365 Admin Center die Domänen ein rotes Kreuz haben, was aber während der Migration richtig ist.

Der lokale Exchangeserver leitet nämlich die an ihn gerichteten Mails der bereits migrierten Benutzer an Office 365 weiter. Erst wenn alle Benutzer migriert sind, kann man die DNS Einträge auf Office 365 umstellen, damit die Mails direkt dorthin geroutet werden.

Wenn alles vorbereitet ist, kann man gemäss diesem Technet Artikel eine CSV-Datei für die Migration bereitstellen. Da das Passwort über DirSync mit dem Active Directory synchronisiert wird, benötigt man nur die Spalte “EmailAddress”. In einer CSV-Datei dürfen maximal 1’000 User vorkommen.

Diese CSV-Datei kann man nun im “Exchange Admin Center” vom Office 365 Portal”“ unter “Empfänger” –> “Migration” hinzufügen.

Beim Migrationstyp wählt man aus den oben erwähnten Gründen “Mehrstufige Migration”, also eine “staged migration”.

Im nächsten Fenster wählt man die vorher erstellte CSV-Datei aus.

Als nächstes muss man die Angaben zum Server angeben.

Nun muss man dem Migrationsbatch noch einen Namen vergeben.

Wenn man möchte, dass man per Mail über die erfolgreiche Abarbeitung des Batches informiert wird, kann man eine Mailadresse eintragen.

Nachdem der Migrationsbatch durchgelaufen ist, haben die migrierten Benutzer zwei Postfächer, eines auf dem lokalen Exchangeserver und eines in Office 365. Mails werden wegen den noch nicht umgestellten DNS Einträgen weiterhin an den lokalen Exchangeserver geliefert, welcher nun die Mails an Office 365 weiterleitet. Dies wird erreicht, indem im Active Directory die Adresse von Office 365 bei targetAddress eingetragen wird. Man kann dies mit dem ADSI-Editor überprüfen.

Ein Problem bleibt nun aber das bestehende Postfach auf dem lokalen Exchangeserver. So verbindet sich z.B. Outlook über den Autodiscover-Eintrag weiterhin mit dem lokalen Exchangeserver. Dieses und weitere Probleme kann man beheben, indem man das Benutzerpostfach auf dem lokalen Exchangeserver zu einem “mail-enabled user” abändert. Microsoft stellt dafür eine Anleitung und Powershellskripts zur Verfügung.

Als erstes lädt man die beiden Powershellskripts in einen Ordner, kopiert die CSV-Datei mit den migrierten Benutzern dazu und ändert den Namen auf migration.csv.

Nun kann man in der Exchange Management Shell das erste Skript  .\ExportO365UserInfo.ps1 ausführen lassen.

Für die Verbindung mit Office 365 muss man sich mit Benutzernamen und Passwort für Office 365 anmelden.

Wenn das Skript erfolgreich durchgelaufen ist, wird eine neue Datei cloud.csv erstellt.

Mit .\Exchange2007MBtoMEU.ps1 <FQDN von einem Domänencontroller> kann man nun die Umwandlung auslösen.

Wenn alles erfolgreich gelaufen ist, haben die Accounts kein Postfach mehr in Exchange, sondern sind nur noch als E-Mail-Kontakt mit der externen Mailadresse von Office 365 aufgeführt.

Im Office 365 Portal kann man nun unter “Benutzer” –> “Aktive Benutzer” die migrierten Benutzer auswählen.

Tipp: Ich habe mir eine neue Ansicht erstellt, die die Benutzer mit einem Postfach, aber ohne Lizenz anzeigt. Dies sind dann gerade die noch zu ändernden Benutzer.

Diese kann man nun alle auswählen und bearbeiten. So kann man für alle migrierten Benutzer die Standarddomäne auswählen, den Benutzerstandort auf Schweiz setzen und eine Lizenz zuweisen.

Wenn alles korrekt funktioniert hat, kann man den Batch im Exchange Admin Center unter “Empfänger” –> “Migration” beenden und löschen

Die migrierten Benutzer können sich nun auf verschiedenen Wegen anmelden. An Outlook Web App kann man sich über https://outlook.office365.com und am Portal über https://portal.office365.com anmelden.

Bei der ersten Anmeldung muss man noch Sprache und Zeitzone auswählen.

Über Active Sync kann man wie gewohnt ein neues Exchange Konto hinzufügen und die persönlichen Daten eintragen. Bei mir genügten die Mailadresse und das Passwort nicht. Es wurde auch der Benutzername (gleich wie Mailadresse) und der Server (outlook.office365.com) abgefragt. Ich gehe davon aus, dass dies nicht mehr nötig ist, wenn nach der vollständigen Migration die DNS Einträge angepasst sind.

Bei einem bereits eingerichteten Outlook Profil muss man die neue Verbindung herstellen. Beim Starten von Outlook erscheint ein Anmeldefenster. Beim Benutzernamen wird die intern verwendete Domäne vorgeschlagen, welche auf die korrekte öffentliche Mailadresse geändert werden muss.

Am Schluss kommt eine Meldung, dass Outlook nun neu gestartet werden muss.

Danach startet Outlook korrekt mit der neuen Verbindung zu Office 365.

Über diese Änderungen sollte man die Benutzer mit einer Anleitung informieren.

Alternativ könnte man mit dem “Office Customization Tool” eine angepasste MSP-Datei erstellen, die sich dann verteilen lässt. Wegen einem Problem mit Benutzern, die Outlook noch nie geöffnet haben, musste ich so eine angepasste MSP-Datei verteilen. Weitere Informationen findet man in diesem Beitrag.

Es bleiben ein paar weitere “Real-World” Probleme.

Public Folders
Microsoft bietet zwar Skripts zum Migrieren der öffentlichen Ordner, aber solange diese Skripts nicht ausgeführt wurden, können die migrierten Benutzer nicht auf die öffentlichen Ordner zugreifen und nachdem sie ausgeführt wurden, können die noch nicht migrierten Benutzer nicht mehr auf sie zugreifen…

Passwort ändern
Bisher konnten Benutzer, die nicht an einem Computer in unserem Netzwerk arbeiten (z.b. Schulräte), ihr Passwort von extern über Outlook Web Access (OWA) zurücksetzen, auch nachdem es abgelaufen ist. Da DirSync aber die lokalen Passwörter nach Office 365 synchronisiert, können die Passwörter nur noch von intern geändert werden. Der beste Weg wird wohl sein, nicht das ganze AD zu synchronisieren und für diese Benutzer nicht synchronisierte “cloud-only” Accounts anzulegen.

zurück zur Übersicht

Wie im 1. Teil beschrieben, favorisiere ich das Modell, bei dem die Passwörter von Office 365 mit den Passwörtern im lokalen Active Directory synchronisiert werden.

Um die Synchronisierung einzurichten, kann man “Benutzer und Gruppen” und dann “Aktive Benutzer” auswählen. Rechts wird nun “Active Directory Synchronisierung” angezeigt. Hier wählt man “Einrichten”.

Nun kann man unter Punkt 3 die Active Directory Synchronisierung aktivieren.

Unter Punkt 4 lässt sich nun das DirSync Tool herunterladen.

Um DirSync zu installieren, muss das .Net Framework 3.5 SP1 und 4.0 installiert sein.

Das .Net Framework 3.5 kann man über den Servermanager als Feature installieren. Unter Windows 2012 R2 ist das .Net Framework 4.5 bereits installiert. Die Version 4.0 muss also nicht installiert werden, da 4.5 die Version 4.0 bereits enthält.

Vor der Installation wird noch bemängelt, dass Powershell 2.0 benötig werde (obwohl $PSVersionTable ausgibt, dass Version 4 installiert sei).

Dies ist aber ein Fehler bei der Abfrage von Powershell. Man kann dies umgehen, indem man die Einstellungen fürs Zahlenformat auf Englisch stellt und sich ab- und wieder anmeldet. Dieses Verhalten wird bei der nächsten Version von DirSync behoben sein.

Danach funktioniert die Installation.

Wenn man das Häklein stehen lässt, startet direkt der Konfigurations-Assistent.

Auf der nächsten Seite kann man die Benutzerdaten für die Verbindung mit Office 365 eingeben.

Auf dieser Seite muss man die Anmeldeinformationen eines Kontos angeben, das Admin-Berechtigungen auf das lokale Active Directory hat.

Hier könnte man die “Hybride Bereitstellung aktivieren”. Da ich aber plane, den Exchangeserver bei uns ganz mit Office 365 zu ersetzen, lasse ich das Häklein weg. Ausserdem bin ich nicht sicher, ob das überhaupt gehen würde. Wir haben noch einen Exchange 2007 Server im Einsatz, ich meine aber gelesen zu haben, dass Exchange 2010 Mindestvoraussetzung sei.

Im nächsten Fenster sollte man “Kennwortsynchronisierung aktivieren” auswählen. Ziel ist es ja, dass für Office 365 das gleiche Kennwort wie für die Computeranmeldung im lokalen Netzwerk verwendet werden kann.

Nun kann man die Verzeichnisse synchronisieren.

Vor dem Abschluss des Konfigurations-Assistenten wird noch ein Link angezeigt, mit dem man überprüfen kann, ob die Verzeichnissynchronisierung korrekt durchgeführt wird.

Nach der Synchronisation findet man die Accounts im Portal.

Um die Synchronisierung zu überprüfen, kann man den “Synchronization Service Manager” verwenden. Dieser befindet sich unter C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell als Programm miisclient. Ich habe gleich eine Verknüpfung auf dem Desktop angelegt.

Hier lassen sich dann die Änderungen verfolgen. Durch einen Klick auf Updates, kann man einzelne Updates überprüfen.

Grundlage für diesen Beitrag war dieser Blog. Vielen Dank dafür.

Um einen manuellen Sync durchzuführen (z.B. weil man nicht so lange warten möchte), kann man das DirSync Modul in Powershell importieren und dann das Start-OnlineCoexistenceSync Cmdlet ausführen.

Import-Module DirSync
Start-OnlineCoexistenceSync

zurück zur Übersicht