Office 365 Lizenzverwaltung

Mit dem Office 365 können Sie den O365 DirSync nutzten, damit die Benutzer aus ihrem On-Prem-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.

Beachten Sie dazu auch die Seite SelfServicePurchase - So steuern Sie, wie Benutzer selbst an M365 Lizenzen kommen

Mittlerweile können sie Office 365 Lizenzen mit Azure Groups verwalten

Eine gute Gegenüberstellung der verschiedenen Pakete finden Sie auf https://m365maps.com/matrix.htm

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. Installieren Sie dazu zuerst die MSOnline PowerShell.

Install-Module MSOnline 

Connect-MSOLService

Danach können Sie dann alle entsprechende PowerShell-Befehle nutzen.

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 {}

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.

Solche Auswertungen sind mittlerweile auch per Graph möglich, so dass Sie sogar per PowerBI

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 On-Prem-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"
   "EXCHANGE_S_STANDARD"          = "Exchange Plan 1"
   "STANDARDPACK"                 = "Office 365 (Plan E1)"
   "STANDARDWOFFPACK"             = "Office 365 (Plan E2)"
   "ENTERPRISEPACK"               = "Office 365 (Plan E3)"
   "ENTERPRISEPACKLRG"            = "Office 365 (Plan E3)"
   "ENTERPRISEWITHSCAL"           = "Office 365 (Plan E4)"
   "ENTERPRISEPREMIUM"            = "Office 365 (Plan E5 with PheonSystem)"
   "ENTERPRISEPREMIUM_NOPSTNCONF" = "Office 365 (Plan E5) w/o PSTN conferencing"
   "VISIOCLIENT"                  = "Visio"
   "POWERAPPS_INDIVIDUAL_User"    = "Microsoft PowerApps"
   "OFFICESUBSCRIPTION"           = "Office Professional Plus"
   "MCOIMP"                       = "Skype for Business Plan 1"
   "MCOSTANDARD"                  = "Skype for Business Plan 2 ohne PSTN Conferencing/CloudPBX"
   "MCOProfessional"              = "Skype for Business mit CloudPBX"
   "MCOEV"                        = "Phone System"
   "MCOVoiceConf"                 = "PSTN Conferencing DialOn"
   "MCOMEETADV"                   = "Audioconferenzen"
   "MCOPSTN1"                     = "Domestic Calling Plan (3000 min US / 1200 min EU plans)"
   "MCOPSTN2"                     = "International Calling Plan"
   "MCOPSTN5"                     = "Domestic Calling Plan (120 min calling plan)"
   "MCOPSTN6"                     = "Domestic Calling Plan (240 min calling plan)"
   "MCOPSTNC"                     = "Communications Credits"
   "SHAREPOINTWAC"                = "Office Web Apps"
   "SHAREPOINTENTERPRISE"         = "SharePoint Online"
   "EXCHANGE_S_ENTERPRISE"        = "Exchange Plan 2"
   "RMS_S_ENTERPRISE"             = "Azure Rights Management"
   "EMS"                          = "Enterprise Mobility Pack"
   "INTUNE_O365"                  = "Mobile Device Management für Office 365"
   "SWAY"                         = "Sway"
   "SHAREPOINTSTANDARD"           = "SharePoint Online Plan 1"
   "YAMMER_ENTERPRISE"            = "Yammer"
}

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

Get-MsolAccountSku

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


(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.

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,$_.userprincipalname)}

get-msolUser -all | % {
    write-host "Processing User "$_.emailaddress
    if ($dictmember.containskey($_.ObjectId.guid)) {
    write-host "User found. add license settings"
    Set-MsolUser `
        -objectid $_.ObjectId.guid `
        -UsageLocation "DE"
    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 mit Azure AD Gruppen verwalten

Mit einem Azure AD Basic Abonnement können Sie die Zuweisung von Office 365 Lizenzen auch direkt in Office 365 vornehmen. Genauer können Sie im Azure Portal die Lizenzen anhand von Gruppen oder Benutzern zuweisen. da aber viele Lizenzen auch an den Standort gebunden sind, müssen Sie vorher im ADSync noch dafür sorgen, dass auch das Feld "UsageLocation" im AzureAD gepflegt ist.

Siehe dazu Office 365 Lizenzen mit Azure Groups

Lizenzcheck mit Reconciliation

Bei dem Commandlet "Get-MsolUser" gibt es einen interessante Parameter "LicenseReconciliationNeededOnly". Damit bekommen Sie die Objekte aufgelistet, die einer "Lizenzüberprüfung" bedürfen. Häufiger Fall dabei sind z.B. Benutzer mit einer Exchange Mailbox aber ohne passende Lizenz. Beachten Sie, dass so ein Benutzer für 30 Tage Karenzzeit seine Mailbox weiter nutzen kann aber danach die Mailbox entfernt wird.

Insofern ist es eine gute Idee, den Befehl ab und an mal zu machen, nachdem Sie an den Lizenzzuweisungen etwas geändert haben. Er kann sogar ins Monitoring aufgenommen werden.

Get-MsolUser `
   -LicenseReconciliationNeededOnly

Leider sendet Microsoft selbst keine Mails, wenn ein Benutzer in diesem Status ist.

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.

Teams Meeting ohne Teams-Lizenz

Es kann passieren, dass Benutzer ohne Teams-Lizenz nicht in Teams-Meetings teilnehmen können. Beim Zutritt in ein Meeting fragt Teams im Browser, ob der Anwender per "Browser" oder per "Teams App" beitreten will. Wenn er hier die "App" installiert, wird die App auch versuchen, den Benutzer anzumelden. Wen der Anwender dann keine Teams Lizenz hat, kommt er nicht in das Meeting sondern sieht die Meldung, dass er eben keine Teams-Lizenz hat.

Daher sollten Anwender, die bereits ein Konto in Office 365/AzureAD haben aber keine Teams-Lizenz besitzen, den Weg über den Browser wählen und "anonym" beitreten.

Weitere Links