Office 365 Lizenzverwaltung

Mit dem Office 365 können Sie den O365 DirSync nutzten, damit die Benutzer aus ihrem OnPremise-Active Directory auch in der Cloud angelegt und verwaltet werden. Dank O365 ADFS kann sogar die Anmeldung einfach "durchlaufen", d.h. der Anwender wird oft nicht mal nach Anmeldedaten gefragt, weil der Client sich automatisch beim ADFS-Server authentifiziert und ein Ticket bekommt. Sie können auch einfach Postfächer in der Cloud manuell anlegen oder lokal als "Remote Mailbox" anlegen und dann durch den DirSync in der Cloud anlegen lassen. Aber damit hat der Anwender noch keine Lizenz. Die muss immer noch manuell zugewiesen werden. Es gibt hier noch keinen Automatismus durch den DirSync oder in Office 365 selbst.

Lizenzen per GUI verwalten

Der normale Weg ist die Zuweisung der Lizenz über die Weboberfläche durch den Office 365 Admin:

Deses Verfahren skaliert aber nicht bei vielen Anwendern, selbst wenn Sie diese Aufgabe an ein weniger privilegiertes Konto delegieren. Office 365 erlaubt diese unterscheidung. Sie können so in Verbindung mit ADFS sogar jemand aus dem Einkauf oder Personalabteilung diese Aufgabe übertragen, schließlich kostet jede zugewiesene Lizenz ja auch Geld. Der "Benutzerverwaltungsadministrator" kann die Lizenzen verwalten.

Überlegen Sie selbst, ob das für ihre Umgebung sinnvoll ist, denn diese Rolle kann auch noch Kennworte zurücksetzen, den Dienststatus überwachen, Benutzerkonten und Benutzergruppen verwalten und Serviceanfragen stellen. Allerdings nur für "normal" Benutzer und nicht für andere Administratoren.

Auswertung von Lizenzen

Ich habe (Stand Sep 2013) keine einfache Tabelle o.ä. in der Webverwaltung gefunden, um den aktuellen Lizenzstatus zu ermitteln. Aber mit der Office 365 PowerShell geht das auch recht schnell.

get-msoluser | ft UserPrincipalName,DisplayName,*lic* `
 -AutoSize 

UserPrincipalName    DisplayName       IsLicensed LicenseReconciliationNeeded Licenses
-----------------    -----------       ---------- --------------------------- --------
user1@msxfaq.de      Voicemail Zentrale         False           False {} 
user2@msxfaq.de      Carius, Frank           True           False {msxfaq:ENTER...

Mein Vorschlag lautet so, dass ein Office 365 Konto angelegt wird, welches nicht unbedingt auch mit ADFS verbunden sein muss (aber kann) und ein Skript mit diesem Dienstkonto und etwas Logik die Lizenzierung steuert. Da sind wir dann aber schon wieder näher beim Administrator.

Lizenzen mit PowerShell verwalten

Wenn Sie aber schon auf der Microsoft Online PowerShell sind, dann gibt es zwei weitere interessante Befehle. Der erste ermittelt das aktuelle Lizenzmodell, welches verwendet wird:

PS C:\> Get-MsolAccountSku

AccountSkuId           ActiveUnits     WarningUnits    ConsumedUnits
------------           -----------     ------------    -------------
msxfaq:ENTERPRISEPACK      250         0       21

So erhalten sie nicht nur die AccountSkuId, sondern auch die Anzahl der zugewiesenen Lizenzen. Nun müssen wir nur noch überlegen, wie der Personenkreis für die Lizenzen ermittelt werden kann. für Exchange ist es relativ einfach zu erkennen, ob ein Benutzer eine Exchange Lizenz benötigt. Office 365 Mailboxen werden bei einer Hybrid-Konfiguration in der OnPremise-Umgebung "Remote user Mailbox" geführt. Eine solches Kriterium gibt es für Lync, Sharepoint und Office leider nicht. Aber hier können Sie ja in ihrem Active Directory z.B. Windows Gruppen pflegen um darüber per Gruppenrichtlinie, Softwareverteilung o.ä. zu bestimmen, wer eine Outlook oder Office-Lizenz bekommt.

Mit diesen Daten als Quelle kann ein PowerShell-Skript einfach die Mitglieder der Gruppe nehmen und eine Lizenz zuweisen. ähnliche Lösungen habe ich schon mit Grp2ExInet und GRP2CAS veröffentlich, welche die Mitgliedschaft von Gruppen nutzt, um bestimmte Funktionen einzuschalten. Die beiden Befehle dazu sind:

$AccountSkuID = (Get-MsolAccountSku).AccountSkuID

Set-MsolUserLicense `
   -UserPrincipalName user@msxfaq.de `
   -AddLicenses $AccountSkuID 

Set-MsolUserLicense `
   -UserPrincipalName user@msxfaq.de `
   -RemoveLicenses $AccountSkuID 

Hier sehen Sie auch, dass die "AccountSkuId" wieder interessant ist.

Hinweis
Wenn Sie einem User eine Lizenz zuweisen wollen, die er eh schon hat, dann kommt leider eine Fehlermeldung, die behauptet, dass die AccountSkuId ungültig ist.

Nun gibt es in Office 365 ja die Möglichkeit, auch innerhalb einer SKU noch weitere Unterscheidungen vorzunehmen. Links sehen Sie die normalen Produktlizenzen und die "E5-Lizenz" habe ich rechts noch einmal erweitert.

Auch diese Abstufungen sind nicht nur per Webbrowser sondern auch per Powershell verwaltbar. Der Weg dazu braucht aber einen Zwischenschritt mehr, da ich mir erst auf Basis der Grundlizenz ein neues Paket erstellen. Dazu muss man aber erst mal die Strings für die einzelnen Pakete kennen. Hier eine Teilmenge, die sich in einer Hashtable gerne als Lookup verwende.

$Sku = @{
   "EXCHANGESTANDARD" = "Office 365 Exchange Online Only"
   "STANDARDPACK" = "Office 365 (Plan E1)"
   "STANDARDWOFFPACK" = "Office 365 (Plan E2)"
   "EMS" = "Enterprise Mobility Pack"
   "ENTERPRISEPACK" = "Office 365 (Plan E3)"
   "ENTERPRISEPACKLRG" = "Office 365 (Plan E3)"
   "ENTERPRISEWITHSCAL" = "Office 365 (Plan E4)"
   "ENTERPRISEPREMIUM" = "Office 365 (Plan E5)"
   "ENTERPRISEPREMIUM_NOPSTNCONF" = "Office 365 (Plan E5) w/o PSTN conferencing"
   "VISIOCLIENT" = "Visio"
   "POWERAPPS_INDIVIDUAL_USER" = "Microsoft PowerApps"
   "YAMMER_ENTERPRISE" = "Yammer"
   "OFFICESUBSCRIPTION" = "Office Professional Plus"
   "MCOSTANDARD" = "Skype for Business ohne PSTN Conferencing/Cloud PBX"
   "SHAREPOINTWAC" = "Office Web Apps"
   "SHAREPOINTENTERPRISE" = "SharePoint Online"
   "EXCHANGE_S_ENTERPRISE" = "Exchange Plan 2"
   "RMS_S_ENTERPRISE" = "Azure Rights Management"
   "INTUNE_O365" = "Mobile Device Management für Office 365"
   "SWAY" = "Sway"
   "SHAREPOINTSTANDARD" = "SharePoint Online"
   "EXCHANGE_S_STANDARD" = "Exchange Plan 1"
}

Wenn man nun einem Benutzer eine abweichende Lizenz zuweisen wollen, müssen Sie immer erst die "Base Lizenz" zuweisen und dann die nicht gewünschten Optionen deaktivieren. Dazu brauchen Sie aber erst mal den Name der BaseSKU, die in der Regel mit dem Namen des Tenant startet. Hier mal die meines Tenant

PS C:\> Get-MsolAccountSku

AccountSkuId                    ActiveUnits     WarningUnits    ConsumedUnits
------------                    -----------     ------------    -------------
msxfaq:ENTERPRISEPACK           5               0               5
msxfaq:INTUNE_A                 5               0               0
msxfaq:EMS                      0               0               0


PS C:\> (Get-MsolAccountSku).servicestatus

ServicePlan                             ProvisioningStatus
-----------                             ------------------
PROJECTWORKMANAGEMENT                   Success
SWAY                                    Success
INTUNE_O365                             Success
YAMMER_ENTERPRISE                       Success
RMS_S_ENTERPRISE                        Success
OFFICESUBSCRIPTION                      Success
MCOSTANDARD                             Success
SHAREPOINTWAC                           Success
SHAREPOINTENTERPRISE                    Success
EXCHANGE_S_ENTERPRISE                   Success
INTUNE_A                                Success
RMS_S_PREMIUM                           Disabled
INTUNE_A                                Success
RMS_S_ENTERPRISE                        Success
AAD_PREMIUM                             Success
MFA_PREMIUM                             Success

Mit dem Namen kann ich mir dann eine "eigene" SKU" zusammenbauen und zuweisen:

$demoLicenseSku = New-MsolLicenseOptions ` 
   -AccountSkuId msxfaq:ENTERPRISEPACK `
   -DisabledPlans EXCHANGE_S_STANDARD

Set-MsolUserLicense `
   -UserPrincipalName $UPN `
   -AddLicenses msxfaq:ENTERPRISEPACK `
   -LicenseOptions $demoLicenseSku

So können Sie einzelne Dienste bei Benutzern auch per PowerShell abschalten.

Lizenzen per Skript verwalten

Ich habe hier exemplarisch auf die Abfrage von lokalen Active Directory Gruppen verzichtet sondern nutzt Office 365 Gruppen. Durch den Verzeichnisabgleich werden im Hybrid-Mode diese Gruppen auch basierend auf dem Active Directory gepflegt aber enthalten sicher nur Mitglieder, die es auch in Office 365 gibt.

Das Commandlet erwartet idealerweise die ObjectID der Gruppe. Wenn Sie sicher sind, dass die Suche nur genau eine Gruppe liefert, dann kann folgendes funktionieren.

PS C:\> get-msolgroupmember `
    -groupobjectid (get-msolgroup -SearchString "ExchangeUser").objectid.guid

Schöner (und lesbarer) ist vielleicht der Zwischenschritt über eine Variable ,vor allem wenn Sie die Mitglieder dann weiter verarbeiten wollen. Leider gibt es nicht den umgekehrten Weg, beim Benutzer zu prüfen, ob dieser in einer Gruppe enthalten ist. Wer also z.B. über die Mitgliedschaft einer Gruppe eine bestimmte Funktion in Office 365 bearbeiten will, muss sich zuerst die Mitglieder der Gruppen holen aber dann sequentiell alle Benutzer abarbeiten oder man nutzt doch die lokale Information über Gruppenmitgliedschaften und Veränderungen , wie ich das mit GET-ADChanges bei Kunden schon mache.

Hier mal eine einfache Version als "Volldurchlauf".

#AccountSkuID  holen
$AccountSkuID = (Get-MsolAccountSku).AccountSkuID

write-host "get group"
$group = get-msolgroup -SearchString "ExchangeUser")

write-host "Loading member of Group"
$member = get-msolgroupmember -groupobjectid $group.objectid.guid

write-host "copy members into hashtable"
$dictmember = @{}
$member | %{$dictmember.add($_.objectid.guid,$_.emailaddress)}

get-msoluser -all | % {
    write-host "Processing user "$_.emailaddress
    if ($dictmember.containskey($_.ObjectId.guid)) {
    write-host "User found. add license settings"
    Set-MsolUserLicense `
        -objectid $_.ObjectId.guid `
        -AddLicenses $AccountSkuID
    }
    else {
    write-host "User no found. remove license settings"
    Set-MsolUserLicense `
        -objectid $_.ObjectId.guid `
        -RemoveLicenses $AccountSkuID
    }
}

Das Skript sollte natürlich ausführlich getestet, um Monitoring und Alerting erweitert und dann regelmäßig gestartet werden. Idealerweise natürlich nach einem erfolgten Office 365 DirSync. Wer mag kann dazu z.B. einfach den folgenden Eventlogeintrag aus dem DirSync-Server nutzen

Log Name:      Application
Source:    Directory Synchronization
Event ID:      4
Task Category: None
Level:     Information
Keywords:      Classic
Description:
 Export has completed.

So könnten Sie das Skript zeitnah nach dem Export/Update der Elemente in Office 365 starten lassen.

Lizenzen richtig verwenden !

Über Office 365 kommen Sie mit den richtigen Paketen durchaus zu interessanten Konditionen an die Office Produkte (Word, Excel, Outlook etc.). Dabei sollten Sie aber ein paar Dinge beachten

  • Aktualität, Kein Downgrade-Rechte
    Microsoft fordert, dass Sie zeitnah die Clientsoftware aktualisieren. Diverse Dokumente sprechen hierbei von 6 Monaten, in denen Sie eine neue Version auch ausgerollt haben müssen. Das deckt sich auch mit der Aussage, dass Sie im Gegensatz zu anderen Verträgen kein "Downgrade-Recht" haben, d.h. sie können keine vorherige Version installieren.
  • Updates
    Die installierten Office-Produkte kommen als "Click Once"-Applikation im Streaming-Verfahren und werden auch dem Client gar nicht richtig "installiert" sondern nur eingebunden. Damit können WSUS und andere Produkte diese Versionen nicht aktualisieren. Aktuelle Versionen bekommt der Client direkt über die Cloud. Eine Kontrolle haben Sie als Administrator nicht darüber und die Bandbreite auf dem Internet ist zu beachten.
  • Kein Home Use Right
    Einige Lizenzmodelle von Office in Firmen erlauben es dem Mitarbeiter eine Office-Version kostenfrei auf dem Heim-PC zu installieren und zu nutzen. Auch dies ist mit Office aus dem Office 365-Paket nicht mehr erlaubt. Anscheinend gewährt Microsoft aber Firmen, die ihr Lizenzschema umstellen, hier eine Übergangsfrist von 1 Jahr.

Weitere Links