Verwendung von Windows Azure Active Directory zur Verwaltung von Office 365

 

Letztes Änderungsdatum des Themas: 2015-03-09

Zusammenfassung: Verwenden Sie Windows PowerShell zum Verwalten von Office 365 mithilfe von Windows PowerShell-Cmdlets, -Skripts und -Stapelverarbeitungsvorgängen.

Sie haben recht: wenn Sie den Begriff “Azure Active Directory” sehen, dann ist Ihr erster Gedanke wahrscheinlich nicht, “Hey, ich wette, so wird Office 365 mithilfe von Windows PowerShell verwaltet.” Es stellt sich jedoch heraus, dass “Azure” seit langer Zeit der Name für den Cloud-Dienst von Microsoft und “Active Directory” seit langer Zeit der Name für Active Directory war. Setzt man sie zusammen, erhält man das Verzeichnis Azure Active Directory, eine Technologie, mit deren Hilfe Sie Windows PowerShell zum Verwalten von Office 365 Benutzern, Gruppen, Lizenzen und Abonnements verwenden können. Dieses Thema enthält Informationen zu:

• Zurückgeben von Office 365-Benutzerkontoinformationen

• Auswählen der zurückzugebenden Eigenschaftswerte von Benutzerkonten

• Konfigurieren der Eigenschaftswerte von Benutzerkonten

• Arbeiten mit Office 365-Benutzerlizenzen

• Ein kurzer Hinweis zu Positionsparametern und Office 365

Wenn Sie weitere Informationen zu den Azure Active Directory-Cmdlets wünschen, finden Sie diese Informationen hier.

Zurückgeben von Office-365 Benutzerkontoinformationen

Ungeachtet der Namen ist es viel interessanter (und wichtiger), sich auf die Verwaltungsaufgaben zu konzentrieren, die mithilfe von Azure Active Directory ausgeführt werden können. Azure Active Directory bietet 66 Cmdlets, von denen die meisten zur Verwaltung Ihrer Office 365-Benutzer, -Gruppen und -Lizenzen verwendet werden. Brauchen Sie z. B. kurzerhand eine Liste Ihrer Office 365-Benutzer? Geben Sie folgenden Befehl ein:

Get-MsolUser

Obwohl wir jetzt einen kleinen Umweg machen, so ist es doch an der Zeit, über Cmdlet-Namen zu sprechen. Wenn Sie sich die Namen der Azure Active Directory-Cmdlets ansehen, werden Sie feststellen, dass sie alle etwas gemeinsam haben:

• Add-MsolForeignGroupToRole

• Add-MsolGroupMember

• Add-MsolRoleMember

• Confirm-MsolDomain

• Connect-MsolService

Wie Sie sehen können, beginnt jeder Cmdlet-Name (der Teil des Namens, der nach dem Bindestrich steht) mit dem Präfix Zufall? Diese Antwort ist nicht ganz richtig. Vielmehr wird das Präfix Msol (Abkürzung für MsOnline) verwendet, um diese Cmdlets als Azure Active Directory-Cmdlets zu identifizieren. Alle Azure Active Directory-Cmdlets müssen das Präfix Msol beinhalten, und keine anderen Windows PowerShell-Cmdlets dürfen dieses Präfix verwenden. Beispielsweise haben alle SharePoint Online-Cmdlets das Präfix:

• Add-SPOUser

• Connect-SPOService

• Disconnect-SPOService

• Get-SPOAppErrors

• Get-SPOAppInfo

Die Lync Online-Cmdlets verwenden alle das Präfix Cs:

• Get-CsAudioConferencingProvider

• Get-CsOnlineUser

• Get-CsTenant

• Get-CsTenantFederationConfiguration

• Get-CsTenantHybridConfiguration

Das Cs-Präfix ist die Abkürzung von Communication Server. Aus diesem Grund war der Lync-Server ehemals als Office Communications Server bekannt. Als der Name offiziell geändert wurde, war der Großteil der Cmdlets bereits abgeschlossen. Da die Änderung der Cmdlet-Namen zu diesem späten Zeitpunkt die Veröffentlichung des Produkts verzögert hätte, wurde entschieden, den Cs-Präfix beizubehalten.

Interessant ist aber, dass die Exchange-Cmdlets überhaupt keinen Präfix verwenden:

• Add-RecipientPermission

• Get-LinkedUser

• Get-RecipientPermission

• Get-RemovedMailbox

• Get-SendAddress

Warum nicht? Exchange war das erste Serverprodukt, das eine Reihe von Windows PowerShell-Cmdlets veröffentlichte. Zu diesem Zeitpunkt war die Verwendung eines Cmdlet-Präfix oder einer anderen ID nicht zwingend notwendig. Als jedoch andere Serverteams begannen, Cmdlets zu erstellen, war bald offensichtlich, dass es ein Problem gab: wenn Exchange ein Cmdlet mit dem Namen Set-User hatte (das wirklich existiert), was machen dann die anderen Teams, die ein Cmdlet für die Konfiguration von Benutzereigenschaften benötigen? (Cmdlet-Namen müssen eindeutig sein.) Die Lösung lag in der Verwendung von Präfixen. Demzufolge haben wir jetzt Cmdlets mit Namen wie Set-MsolUser, Set-CsUser und Set-SPOSiteUser.

Zumindest werden durch Ausführen von Get-MsolUser Informationen wie folgende zurückgebracht:

UserPrincipalName                     DisplayName           isLicensed
-----------------                     -----------           ----------
ZrinkaM@litwareinc.onmicrosoft.com    Zrinka Makovac        True
BonnieK@litwareinc.onmicrosoft.com    Bonnie Kearney        True
FabriceC@litwareinc.onmicrosoft.com   Fabrice Canel         True
BrianJ@litwareinc.onmicrosoft.com     Brian Johnson         False 
AnneWlitwareinc.onmicrosoft.com       Anne Wallace          True

Dies sind alle Ihre Office 365-Benutzer.

Angenommen, Sie möchten eine Liste der nicht lizenzierten Benutzer sehen, d. h. Benutzer, die zu Office 365 hinzugefügt, aber noch für keine der Software-Anwendungen lizenziert wurden. Das ist auch ganz einfach:

Get-MsolUser -UnlicensedUsersOnly

Wir haben wiederum das Cmdlet Get-MsolUser aufgerufen, nur dieses Mal haben wir den Parameter UnlicensedUsersOnly gewählt. Wie der Name schon sagt begrenzt der Parameter die zurückgegebenen Daten auf Benutzer, für die noch keine Lizenzen erstellt wurden:

UserPrincipalName                     DisplayName           isLicensed
-----------------                     -----------           ----------
BrianJ@litwareinc.onmicrosoft.com     Brian Johnson         False
ScottW@litwareinc.onmicrosoft.com     Scott Wallace         False

Sehr schön.

Wir sollten außerdem darauf hinweisen, dass Windows PowerShell angeblich eine von Martians entwickelte Computersprache ist. Wenn viele Menschen an Windows PowerShell denken, denken sie an Befehle, die wie folgt aussehen:

gc test.txt | sort {[int]$_} |% {$i = 1}{while ($i -lt $_){$i;$i++};$i++}

Wird er erteilt, ist der Befehl ein bisschen... stumpf... Andererseits haben wir Ihnen soeben einen Befehl gezeigt, mit dem nur die Benutzer zurück gegeben werden, die nicht für Office 365 lizenziert wurden. Hierzu verwendeten wir ein Cmdlet Get-MsolUser und einen Parameter UnlicensedUsersOnly:

Get-MsolUser -UnlicensedUsersOnly

Und als wir diesen Befehl ausführten, erhielten wir ausschließlich die unlizenzierten Benutzer.

Das bedeutet, dass Sie Windows PowerShell oft so verschlüsselt oder so klar und direkt konfigurieren möchten, wie Sie wollen.

Auswählen der zurückzugebenden Eigenschaftswerte von Benutzerkonten

Windows PowerShell gibt Ihnen die Möglichkeit, Dinge so zu tun, wie Sie es möchten. Wie wir bereits gesehen haben, gibt beispielsweise das Ausführen des Get-MsolUser-Cmdlets drei Eigenschaftswerte zurück:

• UserPrincipalName

• "DisplayName"

• isLicensed

Das ist schön, aber was ist, wenn wir den Anzeigenamen des Benutzers sehen möchten, die Abteilung, in der er arbeitet, und das Land bzw. die Region, in der der Benutzer Office 365-Dienste nutzt? Was dann?

Hinweis

Nun, "nutzen" ist nicht gerade ein großer Begriff. Aber kümmern Sie sich nicht um die Terminologie: Die "UsageLocation"-Eigenschaft gibt den geografischen Standort an, an dem der Benutzer normalerweise Office 365 verwendet. Und das ist sehr wichtig: Office 365-Lizenzen, -Richtlinien und verfügbare Features "rotieren" teilweise um diesen Standort herum.

Wie wir bereits gesehen haben, zeigt "Get-MsolUser" uns nur eine der bevorzugten Eigenschaften an: DisplayName. Sieht aus wie Pech, richtig?

Richtig. Aber nur bis wir diesen Befehl ausführen:

Get-MsolUser | Select-Object DisplayName, Department, UsageLocation

Hier ist, was dieser Befehl zurückgibt:

DisplayName             Department                       UsageLocation
-----------             ----------                       -------------
Zrinka Makovac          Sales & Marketing                US
Bonnie Kearney          Sales & Marketing                US
Fabrice Canel           Legal                            US
Brian Johnson
Anne Wallace            Executive Management             US
Alex Darrow             Sales & Marketing                US
David Longmuir          Operations                       US

Wir wollen nicht lange erklären, wie dies heutzutage funktioniert; das ist zu viel für einen Übersichtsartikel. Wir möchten nur betonen, dass Sie mit dem "Select-Object"-Cmdlet (das zusammen mit Windows PowerShell 3.0 ausgeliefert wird) die Eigenschaften auswählen können, die das Cmdlet zurückgeben soll. Sie möchten nur Werte für die "UsageLocation"-Eigenschaft anzeigen? Dann teilen Sie "Select-Object" mit, nur diese eine Eigenschaft zurückzugeben:

Get-MsolUser | Select-Object DisplayName

Mit "Select-Object" können Sie aber auch alle Eigenschaftswerte eines Elements zurückgeben. Führen Sie den Befehl aus, und achten Sie darauf, was passiert:

Get-MsolUser | Select-Object *

Das ist hilfreich, denn - wie wir bereits gesehen haben - geben Cmdlets nicht in jedem Fall alle verfügbaren Informationen eines Elements zurück. Wenn Sie alles anzeigen möchten, was "Get-MsolUser" über einen Benutzer aussagen kann, verwenden Sie einen ähnlichen Befehl wie diesen:

Get-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" | Select-Object *

Und hier noch ein weiterer praktischer Befehl, der Informationen zu Benutzern ohne Verwendungsstandort zurückgibt. (Das ist wichtig, denn Sie gewisse Aktionen können Sie erst bei Benutzern ausführen, wenn ihr Standort bestimmt wurde.) Hier ist der Befehl:

Get-MsolUser | Where-Object {$_.UsageLocation -eq $Null} | Select-Object DisplayName, Department, UsageLocation

Und sind die vom Befehl zurückgegebenen Daten:

DisplayName              Department                      UsageLocation
-----------              ----------                      -------------
Brian Johnson 
Scott Wallace            Operations

Dies sind aktuell die beiden einzigen Benutzer ohne "UsageLocation".

Konfigurieren der Eigenschaftswerte von Benutzerkonten

Bis jetzt haben wir gelernt, wie Sie Windows PowerShell verwenden, um Informationen zurückzugeben. Noch besser ist vielleicht die Tatsache, dass Sie mit Azure Active Directory-Cmdlets auch Informationen konfigurieren können. Angenommen, Belinda Newman ist nach Frankreich umgezogen und muss ihren Verwendungsstandort auf "FR" setzen, das ist der ISO-Code (International Organization for Standardization) für Frankreich. Gut.

Set-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" -UsageLocation "FR"

Sie können sehen, wie einfach dies ist. Wir wissen bereits, dass das "Get-MsolUser"-Cmdlet eine Eigenschaft namens "UsageLocation" zurückgibt. Legen wir also diesen Eigenschaftswert fest? Wir verwenden einfach das entsprechende Set-MsolUser-Cmdlet und den Parameter "UsageLocation":

Set-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" -UsageLocation "FR"

Es ist wirklich nicht kompliziert.

Und jetzt noch ein cooler Trick. Angenommen, alle Benutzer sind nach Frankreich umgezogen. Kein Problem:

Get-MsolUser | Set-MsolUser -UsageLocation "FR"

In diesem Fall verwenden wir das "Get-MsolUser"-Cmdlet, um alle Benutzerkonten zurückzugeben. Wir haben dann diese Informationen an das "Set-MsolUser"-Cmdlet weitergeleitet. beachten Sie das Pipe-Trennzeichen im Befehl, ein Zeichen wie dieses:

|

Wenn Sie das Pipe-Zeichen in einem Windows PowerShell-Befehl sehen, heißt das, Sie nehmen die Informationen, die mit dem ersten Cmdlet (Get-MsolUser) abgerufen wurden, und geben diese weiter an das zweite Cmdlet (Set-MsolUser). In diesem Fall übernimmt "Set-MsolUser" alle Benutzerkonten und setzt die Eigenschaft "UsageLocation" auf "FR":

Nicht schlecht, nicht wahr.

Hinweis

OK, wir können das einfach so sagen. Weitere Informationen finden Sie in der Einführung in Piping und Pipelines mit Windows PowerShell.

Arbeiten mit Office 365-Benutzerlizenzen

Wie bereits zuvor erwähnt, stehen Ihnen mit den Azure-Cmdlets viele Möglichkeiten zur Verfügung; mit diesem Befehl können Sie beispielsweise Informationen über die Anzahl Ihrer Office 365-Lizenzen und die Anzahl der Lizenzen, die Sie noch verteilen müssen, zurückgeben:

Get-MsolAccountSku

Dadurch werden die Daten wie folgt zurückgegeben:

AccountSkuId                 ActiveUnits   WarningUnits  ConsumedUnits
------------                 -----------   ------------   ------------
litwareinc:ENTERPRISEPACK    25            0              25

In unseren Beispieldaten wurden für die litwareinc-Domäne 25 Lizenzen (ActiveUnits) ausgegeben und alle 25 Lizenzen sind aktuell Benutzern (ConsumedUnits) zugewiesen.

Das ist gut. Natürlich wäre es noch besser, wenn die Möglichkeit bestünde, die Lizenzen anzuzeigen, die einzelnen Benutzern zugewiesen wurden. Ohne zu sehr ins Detail zu gehen, wird im Folgenden erläutert, wie Sie die aktuell Ken Myer zugewiesenen Lizenzen finden können:

Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com" | Select-Object -ExpandProperty Licenses | Select-Object -ExpandProperty ServiceStatus

OK, wir stellen Ihnen eine oberflächliche Erklärung bereit, da es sich hier um einen komplizierteren Befehl handelt. In diesem Befehl verwenden wir zunächst Get-MsolUser, um Informationen für den Benutzer "kenmyer@litwareinc.onmicrosoft.com" zurückzugeben. Anschließend reichen wir diese Informationen an das "Select-Object"-Cmdlet weiter und verwenden den Parameter "ExpandProperty" zum Erweitern der Eigenschaft "Licenses". Wir müssen so vorgehen, da es sich bei Lizenzen um eine mehrwertige Eigenschaft handelt; das bedeutet, sie enthält mehrere Werte (in diesem Fall mehrere Lizenzen) und wir möchten sicherstellen, dass wir mit allen Lizenzen arbeiten. Wir leiten die Lizenzinformationen anschließend mithilfe von Pipelining an das Select-Object-Cmdlet um und erweitern die ServiceStatus-Eigenschaft, um detaillierte Informationen zu jeder einzelnen Lizenz abzurufen.

Hinweis

Sehen Sie sich diesen Artikel zu Werten mit mehreren Eigenschaften an, wenn sich bei dieser oberflächlichen Erklärung herausstellte, dass sie nicht hilfreich war.

Die Rückmeldung sollte dann in etwa so aussehen:

ServicePlan                      ProvisioningStatus
-----------                      ------------------
YAMMER_ENTERPRISE                None
RMS_S_ENTERPRISE                 Success
OFFICESUBSCRIPTION               Success
MCOSTANDARD                      Success
SHAREPOINTWAC                    Success
SHAREPOINTENTERPRISE             Success
EXCHANGE_S_ENTERPRISE            Success

Zugegebenermaßen ist auf den ersten Blick nicht ersichtlich, was hier geschieht. Zum Glück ist es nicht so unscheinbar, wie es scheint. Die ServicePlan-Eigenschaft enthält eine Sammlung von Lizenzen (die in Ihrer Organisation verfügbaren Lizenzen hängen von dem von Ihnen erworbenen Office 365-Plan ab). Die Werte in unserer ServicePlan-Eigenschaft setzen sich wie folgt zusammen:

Indexnummer	Dienstplan	Produkt
0	YAMMER_ENTERPRISE	Yammer
1	RMS_S_ENTERPRISE	Windows Azure Active Directory
2	OFFICESUBSCRIPTION	Office Professional Plus
3	MCOSTANDARD	Lync
4	SHAREPOINTWAC	Office Web Apps
5	SHAREPOINTNETERPRISE	SharePoint
6	EXCHANGE_S_ENTERPRISE	exchange

Die ProvisioningStatus-Eigenschaft wiederum gibt an, ob die Lizenzen zugewiesen oder nicht:

• Keine bedeutet, dass noch nie eine Lizenz zugewiesen wurde.

• Erfolg bedeutet, dass die Lizenz zugewiesen ist.

• Deaktiviert bedeutet, dass die Lizenz zugewiesen, danach jedoch deaktiviert wurde.

Wie Sie sehen können, wurden Ken Meyer alle verfügbaren Lizenzen bis auf die für Yammer zugewiesen.

Hinweis

Wie lautet die Indexnummer in der obigen Tabelle? Die Indexnummer ist ein weiterer Bezeichner für den Serviceplan. Basierend auf dem guten alten Computerprogrammieren wird dem ersten Element einer solchen Sammlung die Indexnummer 0 zugewiesen. YAMMER_ENTERPRISE weist also die Indexnummer 0 auf. Dem zweiten Element der Sammlung wird die Indexnummer 1 zugewiesen, dem dritten Element die Indexnummer 2 usw. Wie wir gleich feststellen werden, können diese Nummern verwendet werden, um beispielsweise alle Benutzer, die eine Yammer-Lizenz besitzen oder alle Benutzer ohne Yammer-Lizenz anzuzeigen.

Wir können also die Lizenzzuweisungen ändern; aber können wir beispielsweise auch die Möglichkeit von Ken deaktivieren, Exchange und Lync Online zu verwenden? Natürlich ist das möglich. Wir werden nun aber nicht genau ins Detail gehen, wie das alles funktioniert; dazu ein anderes Mal mehr. Sie können in Office 365 jedoch Lizenzen (zum Teil jedenfalls) verwalten, indem Sie angeben, welche Lizenzen deaktiviert werden sollen. Dazu müssen Sie ein neues Lizenzierungsoptionsobjekt erstellen, wie hier:

$disabledLicenses = New-MsolLicenseOptions -AccountSkuId "litwareinc:ENTERPRISEPACK" -DisabledPlans "MCOSTANDARD","EXCHANGE_S_ENTERPRISE"

Für die litwareinc-Domäne (für die das Unternehmenslizenzierungspaket erworben wurde) möchten wir zwei Pläne deaktivieren: Lync (MCOSTANDARD) und Exchange (EXCHANGE_S_ENTERPRISE). Beachten Sie, dass dieser Befehl alleine die Lizenzen für keinen Benutzer deaktiviert. Stattdessen wird dadurch eine allgemeine Benutzerlizenz erstellt, in der Lync und Exchange deaktiviert wurden. Anschließend können wir diese allgemeine Benutzerlizenz einer tatsächlichen Person zuweisen:

Set-MsolUserLicense -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com" -LicenseOptions $disabledLicenses

Wenn wir den Befehl ausführen und dann einen zweiten Blick auf die Benutzerlizenzen von Ken werfen, wird Folgendes angezeigt:

ServicePlan                      ProvisioningStatus
-----------                      ------------------
YAMMER_ENTERPRISE                None
RMS_S_ENTERPRISE                 Success
OFFICESUBSCRIPTION               Success
MCOSTANDARD                      Disabled
SHAREPOINTWAC                    Success
SHAREPOINTENTERPRISE             Success
EXCHANGE_S_ENTERPRISE            Disabled

Voila! Exchange und Lync Online wurden deaktiviert.

Anzeigen von Office 365-Lizenzierungsinformationen für mehrere Benutzer

Zugegeben, die Office 365-Benutzerlizenzierung kann ein wenig kompliziert sein. Aber das hat nichts mit Office 365 zu tun. Es ist vielmehr so, dass die Office 365-Benutzerlizenzierung eben etwas kompliziert ist. Schließlich stehen über Office 365 verschiedene Lizenzpakete zur Verfügung, und Benutzern können so viele (oder so wenige) einzelne Produktlizenzen zugewiesen werden, wie Sie möchten. Hierbei den Überblick zu behalten, ist nicht leicht, besonders da Sie im Office 365 Admin Center nur Lizenzdetails für jeweils einen Benutzer anzeigen können. Hätten Sie gern eine Liste aller Benutzer, denen eine Lizenz für Lync Online zugewiesen wurde? Natürlich. Das Admin Center kann dies jedoch nicht ohne Weiteres liefern.

Aber Windows PowerShell kann. Erinnern Sie sich an die Indexnummern, über die wir im Abschnitt Arbeiten mit Office 365-Benutzerlizenzen gesprochen haben? Dann erinnern Sie sich vielleicht, dass Lync Online in unserem Lizenzpaket die Indexnummer 3 hat. Das heißt, wir können mit dieser zugegebenermaßen kryptisch aussehenden Codezeile eine Liste der Benutzer zurückgeben, denen eine Lizenz für Lync Online ausgestellt wurde:

Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Disabled"}

Und ja, sie ist wirklich ein wenig kompliziert. Aber sie gibt die Informationen zurück, die Sie haben wollten:

UserPrincipalName                     DisplayName           isLicensed
-----------------                     -----------           ----------
ZrinkaM@litwareinc.onmicrosoft.com    Zrinka Makovac        True
FabriceC@litwareinc.onmicrosoft.com   Fabrice Canel         True
AnneW@litwareinc.onmicrosoft.com      Anne Wallace          True
AlexD@litwareinc.onmicrosoft.com      Alex Darrow           True

Sie könnten auch eine Liste aller Benutzer zurückerhalten, denen keine Lizenz für Lync Online ausgestellt wurde:

Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Enabled"}

Das ergibt eine völlig andere Liste von Benutzern:

UserPrincipalName                     DisplayName           isLicensed
-----------------                     -----------           ----------
BonnieK@litwareinc.onmicrosoft.com    Bonnie Kearney        True
BrianJ@litwareinc.onmicrosoft.com     Brian Johnson         False

Und wenn wir nicht an Lync Online-Lizenzen interessiert sind, sondern an SharePoint Online-Lizenzen? Nun, wenn Sie nochmals auf die Lizenztabelle blicken, sehen Sie, dass SharePoint Online-Lizenzen die Indexnummer 5 haben. In unserem vorherigen Codebeispiel wurde bei der Angabe der ServiceStatus-Eigenschaft die Indexnummer 3 verwendet (die Indexnummer für Lync Online):

Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Disabled"}

Um wieder SharePoint Online-Lizenzen zu erhalten, ersetzen Sie einfach die 3 durch eine 5:

Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[5].ProvisioningStatus -ne "Disabled"}

Es ist wirklich so einfach.

Weitere Informationen finden Sie im Artikel Lizenzieren von Benutzern für verschiedene Office 365-Arbeitsauslastungen. Ist es nicht etwas mühsam, die verfügbaren Lizenzierungsoptionen mit Windows PowerShell zu verwalten? Ja. Lohnt sich dieser Aufwand, um die verfügbaren Lizenzierungsoptionen mit Windows PowerShell nutzen zu können? Das müssen Sie selbst entscheiden.

Aber: Ja.

Ein kurzer Hinweis zu Positionsparametern und Office 365

Die Azure Active Directory-Cmdlets unterscheiden sich von den Exchange- und Lync Online-Cmdlets zumindest hinsichtlich der Arbeit mit einzelnen Benutzerkonten. Mit dem Lync Online und dem Get-CsOnlineUser-Cmdlet können Sie den Identitätsparameter in Ihren Befehl integrieren, oder Sie können den Identitätsparameter leer lassen. Anders gesagt, diese beiden Befehle funktionieren beide, und sie ergeben beide genau dieselbe Information:

Get-CsOnlineUser -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-CsOnlineUser "kenmyer@litwareinc.onmicrosoft.com"

Das gilt aber nicht für die Azure Active Directory-Cmdlets. Dieser Befehl funktioniert:

Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com"

Hinweis

Wir haben hier den Parameter UserPrincipalName verwendet, weil Get-MsolUser keinen Identitätsparameter hat.

Aber dieser Befehl funktioniert nicht:

Get-MsolUser "kenmyer@litwareinc.onmicrosoft.com"

Warum nicht? Ohne technisch zu sehr ins Detail zu gehen, viele der Lync Online und der Exchange-Cmdlets konfigurieren den Identitätsparameter als einen "Positionsparameter". Das bedeutet, wenn (in diesen Fällen) kein Parametername festgelegt wird (wie z. B. Identität), dann geht das Cmdlet davon aus, dass der allererste Parameter im Befehl der Identitätsparameter ist. Solange Sie mit der Angabe der Benutzeridentität beginnen, können Sie den Identitätsparameter entweder nutzen oder nicht. Beides funktioniert:

Get-CsOnlineUser -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-CsOnlineUser "kenmyer@litwareinc.onmicrosoft.com"

Die Azure Active Directory-Cmdlets unterstützen jedoch keine Positionsparameter. Nehmen wir an, dass Sie einen Wert ohne einen zugehörigen Parameter einbeziehen:

Get-MsolUser "kenmyer@litwareinc.onmicrosoft.com"

In diesem Fall erhalten Sie eine Fehlermeldung, die wie folgt aussieht:

Get-MsolUser : A positional parameter cannot be found that accepts argument 'kenmyer@litwareinc.onmicrosoft.com'.

Beachten Sie, dass wir mit Exchange und Lync Online auf verschiede Weise auf Benutzer Bezug nehmen können. Z. B. ergeben alle diese Exchange-Befehle dieselbe Mailbox-Information.

Get-Mailbox -Identity "Ken Myer"
Get-Mailbox -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-Mailbox -Identity "kenmyer"

Diese Befehle verwenden den Anzeigenamen von Active Directory; jeweils seinen oder ihren Prinzipalnamen und seine oder ihre E-Mail-Adresse. Keine dieser Identitäten wird funktionieren. Allerdings werden es die von Exchange und Lync Online. Für die meisten Teile müssen Sie bei Azure Active Directory den Anwendungsprinzipalnamen oder den Benutzerprinzipalnamen verwenden.

Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com"

Hinweis

Technisch gesehen können Sie den Parameter ObjektId verwenden. Aber hierfür müssen Sie den GUID (Globally Unique Identifier) eingeben, der dem Benutzerkonto zugewiesen wurde. Beispiel:
Get-MsolUser –ObjectId "62e90394-69f5-4237-9190-012177145e10"
Sie können selbst entscheiden, ob Sie UserPrincipalName oder ObjectId verwenden möchten.

Das ist zugegebenermaßen viel für den Anfang, zumindest für jemanden, der neu bei Windows PowerShell ist. Wenn Sie neu bei Windows PowerShell sind, möchten Sie sich vielleicht unseren einleitenden Artikel über die Arbeit mit Parametern anschauen.

Siehe auch

Beste Möglichkeiten zum Verwalten von Office 365 mit der Windows PowerShell