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