Um Office 365 Lizenzen mit Powershell zu verwalten, muss man das Azure Active Directory Modul für Powershell verwenden. Hier ist beschrieben, wie man das installiert und verwendet.

Um herauszufinden, welche Lizenzen man zur Verfügung hat, kann man folgenden Befehl verwenden.

Get-Msolaccountsku

Eine Lizenz zuweisen kann man mit folgendem Befehl.

Set-MsolUserLicense –AddLicenses schalt:STANDARDWOFFPACK_STUDENT

Wenn man nun allen Accounts, die eine Studentlizenz haben auch das Student ProPlus Benefit zuweisen möchte, muss man eine Abfrage erstellen und dann den gefundenen die entsprechende Lizenz zuweisen. Nachtrag: Dies muss neu nicht mehr gemacht werden.

Get-MsolUser –all | Where-Object {$_.Licenses.AccountSkuID –eq “schalt:STANDARDWOFFPACK_STUDENT”} | Set-MsolUserLicense –AddLicenses schalt:OFFICESUBSCRIPTION_STUDENT

Der Befehl lieferte bei mir eine rote Fehlermeldung, dass es sich dabei um keine gültige Lizenz handle. Trotzdem funktionierte alles wie gewünscht.

zurück zur Übersicht

Wenn alle Benutzerpostfächer migriert sind und Versand und Empfang von Mails über Office 365 funktioniert, kann man die Migration gemäss dem Punkt 8 aus diesem Technet Artikel abschliessen.

Zum einen kann man nun die DNS Einträge vollständig übernehmen. Bisher wurden die Mails ja zum lokalen Exchangeserver geliefert, der sie dann an Office 365 weitergeleitet hat. Die Benutzer verbinden sich aber seit Teil 5 dieser Beiträge mit dem Exchangeserver von Office 365. Diese “Umleitung” kann man nun entfernen.

Dazu meldet man sich im Office 365 Admin Center an und wählt “Domänen” und dann “Probleme beheben”.

Die nun angezeigten DNS-Einträge müssen bei den öffentlichen DNS Einstellungen hinzugefügt werden. Ich hatte dabei Mühe mit den SRV Einträgen bei hosttech.ch. Der Support hat mir dann aber angegeben, wie man diese eintragen muss:

Host: “Dienst”.”Protokoll”.domain.tld
Inhalt: “Gewichtung” “Port” “Ziel”

Es kann unterschiedlich lange dauern, bis die neuen Einträge bei allen Teilnehmern des Internets angekommen sind. Bis alle umgestellt haben, sollte man den lokalen Exchangeserver noch in Betrieb lassen.

In den Internetkopfzeilen (in Outlook bei “Kategorien” auf den kleinen Pfeil klicken) finden sich Angaben über den verwendeten Weg durchs Internet. Im Bild unten sieht man, wie das Mail noch auf den lokalen Exchangeserver (mail.schalt.ch) geleitet und erst dann weitergeleitet wurde.

Microsoft empfiehlt beim Einsatz von DirSync einen lokalen Exchangeserver vor Ort weiter zu betreiben, um die Exchange-spezifischen Attribute im AD weiter bearbeiten zu können.

If you implement a single sign-on solution, we strongly recommend that you maintain at least one Exchange server so that you can access Exchange System Manager (Exchange 2003) or the Exchange Management Console/Exchange Management Shell (Exchange 2007, Exchange 2010, and Exchange 2013) to manage mail-related attributes on the on-premises mail-enabled users. For Exchange 2007 and Exchange 2010, the Exchange server that you maintain should have the Hub Transport, Client Access, and Mailbox server roles installed. For Exchange 2013, you should maintain the Mailbox and Client Access servers.

Man kann aber Aufgaben wie eine zusätzliche Mailadresse (proxyAddresses) auch über den ADSI Editor oder die Registerkarte Attribut-Editor bei den Eigenschaften eines Users in “Active Directory-Benutzer und –Computer” oder gar mit einem Powershell Skript lösen.

Wenn man sich entschieden hat, trotzdem alle Exchange Server zu entfernen, kann man gemäss diesem Technet Artikel vorgehen. Einfach über die Systemsteuerung deinstallieren.

Hier muss man die Häklein entfernen, damit die entsprechende Rolle deinstalliert wird.

Bei der Überprüfung wird dann bemängelt, dass noch ein Sende Connector konfiguriert ist. Wenn man auf “empfohlene Aktion” klickt, kommt man auf diese Seite.

Also gemäss der Empfehlung den Sendeconnector entfernen. Wenn man danach im Bild oben auf “Wiederholen” klickt, läuft die Überprüfung problemlos durch und man kann den Exchangeserver deinstallieren.

Danach noch das Backup anpassen und den Server herunterfahren.

zurück zur Übersicht

Man kann sich mit Powershell an Office 365 anmelden, um verschiedene Aufgaben zu erledigen. Es gibt aber zwei Wege, wie man sich anmeldet und mir war am Anfang nicht klar, wann welcher zu verwenden ist. Da ich bisher erst wenig damit gearbeitet habe, bin ich immer noch nicht ganz sicher, meine aber, dass es folgendermassen ist.

Wenn es sich um allgemeine Aufgaben handelt, die man über den Browser im “Office 365 Admin Center” bearbeiten würde, verwendet man am einfachsten das “Azure Active Directory-Modul für Windows PowerShell”, wie das z.B. in diesem Beitrag gemacht wurde.

Um aber Exchange spezifische Aufgaben zu erledigen, für die man im Browser das “Exchange Admin Center” verwenden würde, verwendet man die “normale” Powershell ohne das “Azure Active Directory-Modul” und verbindet sich gemäss diesem TechNet Artikel über:

$UserCredential = Get-Credential

Danach muss man sich mit Benutzernamen und Passwort an Office 365 anmelden.

Durch die folgenden Befehle wird man mit Office 365 verbunden:

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

Import-PSSession $session

zurück zur Übersicht

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