Uso di Windows Azure Active Directory per gestire Office 365
Ultima modifica dell'argomento: 2015-03-09
Riepilogo: Utilizzare Windows PowerShell per gestire Office 365 mediante cmdlet, script e processi di batch di Windows PowerShell.
È vero: quando si vede il termine "Azure Active Directory" probabilmente il primo pensiero non sarà "Scommetto che sia il modo in cui gestire Office 365 con Windows PowerShell". Ebbene, tuttavia, "Azure" è stato a lungo il nome del servizio cloud di Microsoft e "Active Directory" è stato a lungo il nome di Active Directory. Se si uniscono, si ottiene Azure Active Directory Directory, una tecnologia che consente di utilizzare Windows PowerShell per gestire gli utenti, i gruppi, le licenze e gli abbonamenti di Office 365. In questo argomento vengono fornite informazioni relative a:
Restituire informazioni sull'account utente di Office 365
Selezione dei valori della proprietà dell'account utente da restituire
Configurazione dei valori delle proprietà dell'account utente
Utilizzo delle licenze utente di Office 365
Una nota rapida sui parametri posizionali e Office 365
Per ulteriori informazioni sui cmdlet di Azure Active Directory, leggere qui.
Restituire informazioni sull'account utente di Office 365
Nomi a parte, è molto più interessante (e importante) concentrarsi sulle attività di gestione che possono essere portate a termine con Azure Active Directory. Azure Active Directory include 66 cmdlet, la maggior parte dei quali viene utilizzata per gestire gli utenti, i gruppi e le licenze di Office 365. Serve un elenco rapido degli utenti di Office 365? Provare questo comando:
Get-MsolUser
Anche se può risultare una piccola deviazione, può essere utile parlare dei nomi dei cmdlet. Se si guardano i nomi dei cmdlet di Azure Active Directory, si noterà che hanno tutti una cosa in comune:
Add-MsolForeignGroupToRole
Add-MsolGroupMember
Add-MsolRoleMember
Confirm-MsolDomain
Connect-MsolService
Come si può vedere, ogni nome di cmdlet (la parte del nome che segue il trattino) inizia con il prefisso Msol. Coincidenza? Non esattamente. Al contrario, il prefisso Msol (forma breve di MsOnline) viene utilizzato per identificare i cmdlet come cmdlet di Azure Active Directory. Tutti i cmdlet Azure Active Directory devono utilizzare il prefisso Msol e nessun altro cmdlet Windows PowerShell può usare tale prefisso. Ad esempio, i cmdlet di SharePoint Online hanno tutti il prefisso:
Add-SPOUser
Connect-SPOService
Disconnect-SPOService
Get-SPOAppErrors
Get-SPOAppInfo
I cmdlet di Lync Online utilizzano tutti il prefisso Cs:
Get-CsAudioConferencingProvider
Get-CsOnlineUser
Get-CsTenant
Get-CsTenantFederationConfiguration
Get-CsTenantHybridConfiguration
Il prefisso Cs è effettivamente l'abbreviazione di Communication Server. Questo perché il server di Lync era conosciuto in precedenza come Office Communications Server. Nel momento in cui il nome venne modificato ufficialmente, un gran numero di cmdlet era stato già completato. Poiché modificare i nomi dei cmdlet così in ritardo avrebbe potuto ritardare l'uscita del prodotto, venne deciso di mantenere il prefisso Cs.
Cosa abbastanza interessante, i cmdlet di Exchange non utilizzano alcun tipo di prefisso:
Add-RecipientPermission
Get-LinkedUser
Get-RecipientPermission
Get-RemovedMailbox
Get-SendAddress
Perché no? Exchange è stato il primo prodotto server a rilasciare un set di cmdlet di Windows PowerShell. In quel momento, nessuno stava spingendo per l'utilizzo di un prefisso di cmdlet o di altro identificativo. Tuttavia, quando gli altri team di server iniziarono a creare cmdlet, divenne presto chiaro che c'era un problema: se Exchange aveva un cmdlet denominato Set-User (e lo aveva) allora cosa avrebbero dovuto fare gli altri team che avevano bisogno di un cmdlet per configurare le proprietà dell'utente? (i nomi dei cmdlet devono essere univoci). La soluzione fu quella di utilizzare i prefissi. Di conseguenza, ora abbiamo cmdlet con nomi come Set-MsolUser, Set-CsUser e Set-SPOSiteUser.
In ogni caso, eseguendo Get-MsolUser verranno restituite informazioni simili a quelle che seguono:
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
Questi sono tutti gli utenti di Office 365.
Supponiamo invece che l'utente desideri visualizzare un elenco solo degli utenti senza licenza; vale a dire gli utenti che sono stati aggiunti a Office 365 ma ai quali ancora non è stata concessa la licenza per l'utilizzo delle applicazioni software. Eccone uno facile, troppo:
Get-MsolUser -UnlicensedUsersOnly
Di nuovo, abbiamo chiamato il cmdlet Get-MsolUser, solo questa volta siamo passati al parametro UnlicensedUsersOnly. Come implica il nome, il parametro limita i dati restituiti agli utenti senza licenza:
UserPrincipalName DisplayName isLicensed
----------------- ----------- ----------
BrianJ@litwareinc.onmicrosoft.com Brian Johnson False
ScottW@litwareinc.onmicrosoft.com Scott Wallace False
Molto interessante.
Potremmo inoltre segnalare che Windows PowerShell ha la reputazione di essere un linguaggio di computer creato dai marziani. Quando molti utenti pensano a Windows PowerShell pensano a comandi simili a quelli che seguono:
gc test.txt | sort {[int]$_} |% {$i = 1}{while ($i -lt $_){$i;$i++};$i++}
Concesso che il comando è un po'...ottuso... D'altra parte, abbiamo mostrato un comando che restituisce solo gli utenti senza licenza di Office 365. Per farlo, è stato usato un cmdlet denominato Get-MsolUser e un parametro UnlicensedUsersOnly:
Get-MsolUser -UnlicensedUsersOnly
Eseguito il comando, sono stati ottenuti solo gli utenti senza licenza.
Il che significa semplicemente che è spesso possibile rendere Windows PowerShell criptico oppure semplice come lo si desidera
Selezione dei valori della proprietà dell'account utente da restituire
Windows PowerShell consente di effettuare delle operazioni nel modo desiderato. Ad esempio, sappiamo che eseguendo il cmdlet Get-MsolUser si riportano tre valori di proprietà:
UserPrincipalName
DisplayName
isLicensed
È interessante, ma cosa succede se quello che si desidera visualizzare è il nome visualizzato dell'utente, il dipartimento in cui lavora e il paese o regione in cui l'utente "esaurisce" i servizi Office 365? Cosa accadrebbe?
Nota
Sì, "esaurisce" non è una bella parola. Ma non preoccupiamoci della terminologia: la proprietà UsageLocation indica la posizione geografica in cui l'utente solitamente utilizza Office 365. Ed è molto importante: licenze, criteri e funzionalità disponibili di Office 365 ruotano, in parte, sulla posizione.
Come abbiamo già visto, Get-MsolUser visualizza solo una delle nostre proprietà preferite: DisplayName. Sembra che siamo proprio sfortunati, vero?
Giusto. Bene, a meno che non eseguiamo quest'altro comando:
Get-MsolUser | Select-Object DisplayName, Department, UsageLocation
Ecco che cosa restituisce il comando:
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
Adesso non è necessario capire come funziona tutto ciò; sarebbe troppo per un articolo introduttivo. È possibile invece considerare che il cmdlet Select-Object (che fa parte di Windows PowerShell 3.0) consente di individuare e scegliere le proprietà da far restituire al cmdlet. Si desidera visualizzare i valori di proprietà di UsageLocation? Chiedere quindi a Select-Object di restituire solo una proprietà:
Get-MsolUser | Select-Object DisplayName
Select-Object consente anche di restituire tutti i valori delle proprietà per un elemento. Provare a eseguire questo comando e vedere cosa succede:
Get-MsolUser | Select-Object *
Si tratta di un'operazione utile perché, come è già stato visto, i cmdlet non sempre restituiscono tutte le informazioni disponibili per un elemento. Se si desidera visualizzare tutto quello che Get-MsolUser può dire su un utente, utilizzare un comando simile al seguente:
Get-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" | Select-Object *
Ecco un pratico comando che restituisce informazioni sugli utenti che non utilizzano l'ubicazione. (È molto importante da sapere perché in questo modo non sarà possibile effettuare determinate operazioni fin quando gli utenti non impostino la propria posizione). Ecco il comando:
Get-MsolUser | Where-Object {$_.UsageLocation -eq $Null} | Select-Object DisplayName, Department, UsageLocation
E anche i dati che vengono restituiti:
DisplayName Department UsageLocation
----------- ---------- -------------
Brian Johnson
Scott Wallace Operations
Questi sono i soli due utenti che attualmente non dispongono di un UsageLocation.
Configurazione dei valori della proprietà dell'account utente
Finora, è stato discusso come utilizzare Windows PowerShell per restituire le informazioni. Inoltre, per configurare le informazioni è possibile utilizzare i cmdlet di Azure Active Directory. Quali operazioni effettuare se Belinda Newman si è trasferita in Francia ed è necessario impostare il suo percorso di utilizzo su FR, il codice ISO (International Organization for Standardization) per la Francia? OK:
Set-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" -UsageLocation "FR"
questa operazione è molto facile da effettuare. È già noto come il cmdlet Get-MsolUser possa restituire una proprietà denominata UsageLocation. Quindi, come si imposta tale valore della proprietà? È sufficiente utilizzare il cmdlet Set-MsolUser corrispondente e il parametro UsageLocation:
Set-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" -UsageLocation "FR"
Come già detto, questa operazione è molto facile da effettuare.
Inoltre: se tutti gli utenti si sono trasferiti in Francia? Nessun problema:
Get-MsolUser | Set-MsolUser -UsageLocation "FR"
In questo caso, è necessario utilizzare il cmdlet Get-MsolUser per restituire tutti gli account degli utenti. Tali informazioni, vengono in seguito "indirizzate" al cmdlet Set-MsolUser. Prestare attenzione al carattere separatore barra verticale del comando, che avrà un aspetto analogo al seguente:
|
Quando viene visualizzato un carattere barra verticale in un comando Windows PowerShell vuol dire che si otterranno le informazioni recuperate tramite il primo cmdlet (Get-MsolUser) e in seguito tali informazioni verranno trasmesse al secondo cmdlet (Set-MsolUser). In questo caso, il carattere indica che il cmdlet Set-MsolUser comprenderà tutti gli account utente e imposterà la proprietà UsageLocation su FR.
Non male, è possibile ammetterlo.
Nota
Probabilmente, è più facile per noi ammetterlo. Ma non c'è motivo di agitarsi: di seguito è riportata una utile introduzione sull'utilizzo del pipelining e delle pipeline con Windows PowerShell.
Utilizzo delle licenze utente di Office 365
Come detto in precedenza, è possibile utilizzare i cmdlet di Azure per effettuare molte operazioni; ad esempio, il comando restituisce le informazioni relative al numero di licenze di Office 365 dell'utente, nonché sul numero di licenze che possono essere ancora distribuite:
Get-MsolAccountSku
In questo modo verranno restituiti dati analoghi ai seguenti:
AccountSkuId ActiveUnits WarningUnits ConsumedUnits
------------ ----------- ------------ ------------
litwareinc:ENTERPRISEPACK 25 0 25
Nei dati di esempio, il dominio litwareinc ha pubblicato 25 licenze (ActiveUnits) e tutte le 25 licenze sono assegnate agli utenti (ConsumedUnits).
Ciò non rappresenta un problema. Ovviamente, la possibilità di visualizzare le licenze assegnate a un singolo utente sarebbe un vantaggio. Senza spiegare tutti i dettagli, di seguito verrà descritto come individuare le licenze attualmente assegnate a Ken Myer:
Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com" | Select-Object -ExpandProperty Licenses | Select-Object -ExpandProperty ServiceStatus
Verrà fornita una spiegazione sommaria poiché si tratta di un comando molto più complicato. In tale comando, si utilizza innanzitutto Get-MsolUser per restituire informazioni relative all'utente kenmyer@litwareinc.onmicrosoft.com. In seguito, si esegue il piping delle informazioni nel cmdlet Select-Object e si utilizza il parametro ExpandProperty per "espandere" la proprietà Licenses. È necessario effettuare tale operazione poiché Licenses rappresenta una proprietà con più valori. Ciò significa che include diversi valori (in questo caso, più licenze) e si desidera accertare l'utilizzo di tutte le licenze. In seguito, viene eseguito il piping delle informazioni di licenza in Select-Object e si espande la proprietà ServiceStatus per ottenere informazioni dettagliate sulle licenze individuali.
Nota
Consultare il seguente articolo relativo ai valori con più proprietà se questa spiegazione sommaria non è sufficiente.
Al termine di questa operazione, si dovrebbe visualizzare un risultato analogo al seguente:
ServicePlan ProvisioningStatus
----------- ------------------
YAMMER_ENTERPRISE None
RMS_S_ENTERPRISE Success
OFFICESUBSCRIPTION Success
MCOSTANDARD Success
SHAREPOINTWAC Success
SHAREPOINTENTERPRISE Success
EXCHANGE_S_ENTERPRISE Success
In realtà, a un primo sguardo potrebbe non essere chiaro cosa accade in questo passaggio. Per fortuna, non è così complesso come sembra. La proprietà ServicePlan contiene una raccolta di licenze (quelle disponibili nell'organizzazione dipendono dal piano di Office 365 che è stato acquistato). I valori della proprietà ServicePlan saranno equivalenti ai seguenti:
| Numero indice | Piano di servizio | Prodotto |
|---|---|---|
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 |
A sua volta, la proprietà ProvisioningStatus indica se la licenza è stata assegnata o meno.
Nessuno significa che non sono mai state assegnate licenze.
Riuscito significa che la licenza è assegnata.
Disabilitata significa che la licenza è stata assegnata ma è stata disabilitata.
Come è evidente, all'utente Ken Myer sono state assegnate tutte le licenze disponibili tranne Yammer.
Nota
Che cosa indica Numero indice nella precedente tabella? Il numero di indice rappresenta un altro identificatore del piano di servizio. In base alla programmazione di vecchia generazione, al primo elemento di una raccolta di questo tipo viene assegnato il numero indice 0. Pertanto, YAMMER_ENTERPRISE dispone del numero indice 0. Al secondo elemento della raccolta viene assegnato il numero indice 1, al terzo il numero 2 e così via. Come verrà descritto più avanti, tali numeri possono essere utilizzati per effettuare operazioni quali la visualizzazione di tutti gli utenti che dispongono di una licenza Yammer o tutti gli utenti che non ne dispongono.
È possibile modificare l'assegnazione di tali licenze? Ad esempio, è possibile disabilitare la possibilità di utilizzare Exchange e Lync Online per Ken? Certamente, è possibile. Anche in questo caso verrà fornita una spiegazione sommaria. Tuttavia, in Office 365 è possibile gestire le licenze (almeno in parte) indicando quali licenze devono essere disabilitate. È possibile effettuare questa operazione creando un nuovo oggetto relativo alle opzioni di licenza, come il seguente:
$disabledLicenses = New-MsolLicenseOptions -AccountSkuId "litwareinc:ENTERPRISEPACK" -DisabledPlans "MCOSTANDARD","EXCHANGE_S_ENTERPRISE"
In questo passaggio è stato semplicemente detto che si desidera disabilitare due piani per il dominio litwareinc (che ha acquistato il pacchetto di licenza di Enterprise): Lync (MCOSTANDARD) ed Exchange (EXCHANGE_S_ENTERPRISE). Tenere presente che questo comando non consente di disabilitare le licenze per tutti gli utenti. Invece, crea una licenza utente generica nella quale sia Lync che Exchange vengono disabilitati. È possibile assegnare tali licenze utente generiche a una persona fisica:
Set-MsolUserLicense -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com" -LicenseOptions $disabledLicenses
Se si esegue il comando e si esaminano di nuovo le licenze utente di Ken, verranno visualizzati elementi analoghi eseguenti:
ServicePlan ProvisioningStatus
----------- ------------------
YAMMER_ENTERPRISE None
RMS_S_ENTERPRISE Success
OFFICESUBSCRIPTION Success
MCOSTANDARD Disabled
SHAREPOINTWAC Success
SHAREPOINTENTERPRISE Success
EXCHANGE_S_ENTERPRISE Disabled
Ecco fatto. Sia Exchange che Lync Online sono stati disabilitati.
Visualizzazione delle informazioni sulla licenza di Office 365 per più utenti
È vero, l'assegnazione delle licenze utente di Office 365 può essere un po' complicata. Ciò non ha però nulla a che fare con Office 365; al contrario, è dovuto al fatto che l'assegnazione delle licenze utente di Office 365 può essere un po' complessa. Dopo tutto, esistono molti pacchetti di licenze per Office 365 e agli utenti possono essere assegnate tutte le licenze dei singoli prodotti disponibili. Tenere traccia di tutto non è semplice, particolarmente alla luce del fatto che l'interfaccia di amministrazione di Office 365 consente di visualizzare i dettagli delle licenze di un utente alla volta. Si desidera un elenco di tutti gli utenti ai quali è stata assegnata una licenza di Lync Online? Ovviamente. Ma l'interfaccia di amministrazione non può aiutare in questa operazione.
Tuttavia, può farlo Windows PowerShell. Si ricordano i numeri di indice descritti nella sezione Utilizzo delle licenze utente di Office 365? In caso di risposta affermativa, l'utente allora ricorderà che, nel nostro pacchetto di licenza, Lync Online presenta un numero di indice pari a 3. Ciò significa che è possibile utilizzare questa riga di codice dall'aspetto criptico per restituire un elenco di tutti gli utenti per i quali è stata emessa una licenza di Lync Online:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Disabled"}
E sì, effettivamente è un po' complicato. Ma consente di ottenere le informazioni desiderate:
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
Se si preferisce, è possibile inoltre ottenere un elenco di tutti gli utenti ai quali non è stata concessa una licenza per Lync Online:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Enabled"}
In questo modo si otterrà un elenco di utenti completamente diverso:
UserPrincipalName DisplayName isLicensed
----------------- ----------- ----------
BonnieK@litwareinc.onmicrosoft.com Bonnie Kearney True
BrianJ@litwareinc.onmicrosoft.com Brian Johnson False
Ma cosa succede se non si vogliono conoscere le licenze di Lync Online e si vogliono conoscere quelle di SharePoint Online? Bene, se si osserva la tabella delle licenze, è possibile vedere che le licenze di SharePoint Online presentano un numero di indice pari a 5. L'esempio di codice precedente utilizzava un numero di indice pari a 3 (il numero di indice di Lync Online) quando è stata specificata la proprietà ServiceStatus:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Disabled"}
Per ottenere le licenze di SharePoint Online, basta sostituire il 3 con il 5:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[5].ProvisioningStatus -ne "Disabled"}
È davvero facile.
Per ulteriori informazioni, leggere l'articolo Concedere licenze agli utenti per carichi di lavoro di Office 365. Ci vuole un po' di sforzo per diventare esperti delle opzioni di licenza disponibili utilizzando Windows PowerShell? Sì. Vale la pena sforzarsi per essere in grado di trarre vantaggio dalle opzioni di licenza disponibili utilizzando Windows PowerShell? Questa decisione spetta all'utente.
Ma: sì.
Una nota rapida sui parametri posizionali e Office 365
I cmdlet di Azure Active Directory sono diversi dai cmdlet di Exchange e Lync Online, almeno quando si tratta di lavorare con singoli account utente. Ad esempio, con Lync Online e il cmdlet Get-CsOnlineUser, è possibile includere il parametro Identity nel comando o è possibile escludere tale parametro. In altre parole, questi due comandi funzionano entrambi ed entrambi restituiscono esattamente le stesse informazioni:
Get-CsOnlineUser -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-CsOnlineUser "kenmyer@litwareinc.onmicrosoft.com"
Tuttavia, non vale per i cmdlet di Azure Active Directory. Questo comando funziona:
Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com"
Nota
Qui è stato utilizzato il parametro UserPrincipalName perché Get-MsolUser non ha un parametro Identity.
Tuttavia questo comando non funziona:
Get-MsolUser "kenmyer@litwareinc.onmicrosoft.com"
Perché? Senza scendere nei dettagli tecnici, molti dei cmdlet di Lync Online ed Exchange configurano il parametro Identity come un "parametro posizionale". Ciò significa che (ad ogni modo in questi casi), se non si specifica un nome del parametro (ad esempio, –Identity) il cmdlet presuppone che il vero primo parametro nel comando sia il parametro Identity. Fin quando si comincia specificando l'identità dell'utente, è possibile sia utilizzare il parametro –Identity che non utilizzarlo. Entrambi i modi funzionano:
Get-CsOnlineUser -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-CsOnlineUser "kenmyer@litwareinc.onmicrosoft.com"
I cmdlet di Azure Active Directory tuttavia non supportano i parametri posizionali. Si supponga di includere un valore senza un parametro accompagnatorio:
Get-MsolUser "kenmyer@litwareinc.onmicrosoft.com"
In tal caso, verrà visualizzato un messaggio di errore simile al seguente:
Get-MsolUser : A positional parameter cannot be found that accepts argument 'kenmyer@litwareinc.onmicrosoft.com'.
Notare inoltre che Exchange e Lync Online consentono di fare riferimento agli utenti in molti modi diversi. Ad esempio, tutti i comandi di Exchange restituiscono le stesse informazioni sulle cassette postali:
Get-Mailbox -Identity "Ken Myer"
Get-Mailbox -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-Mailbox -Identity "kenmyer"
Tali comandi utilizzano rispettivamente il nome di visualizzazione di Active Directory dell'utente, il suo nome principale utente, e il relativo alias. Una di queste identità funzionerà. Ma vale per Exchange e Lync Online. Per la maggior parte, Azure Active Directory richiede all'utente di utilizzare solo il nome principale dell'utente:
Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com"
Nota
Poi, tecnicamente, è possibile utilizzare il parametro ObjectId. Ciò richiede però di inserire il GUID (identificatore univoco globale) assegnato all'account utente. Esempio:
Get-MsolUser –ObjectId "62e90394-69f5-4237-9190-012177145e10"
Viene concesso all'utente di decidere se utilizzare UserPrincipalName o ObjectId.
Effettivamente, tutto ciò potrebbe essere molto da assorbire, almeno per coloro con poca esperienza con Windows PowerShell. Se l'utente non è esperto di Windows PowerShell potrebbe essere utile dare un'occhiata all'articolo introduttivo sull'uso di parametri.