Utilisation de Windows Azure Active Directory pour gérer Office 365

Article
10/08/2015

Dernière rubrique modifiée : 2015-03-09

Résumé : Utilisez Windows PowerShell pour gérer Office 365 à l’aide des cmdlets, des scripts et des processus de traitement par lots Windows PowerShell.

Vous avez raison : quand vous voyez le terme « Azure Active Directory », votre première pensée n’est probablement pas « Je parie que c’est ce que l’on utilise pour gérer Office 365 avec Windows PowerShell ». Pourtant, « Azure » est depuis longtemps le nom du service cloud de Microsoft et « Active Directory » celui … d’Active Directory. Combinez-les et vous obtenez l’annuaire Azure Active Directory, une technologie qui vous permet d’utiliser Windows PowerShell pour gérer les utilisateurs, groupes, licences et abonnements Office 365. Cette rubrique comporte des informations sur :

Renvoi d’informations de compte d’utilisateur Office 365
Sélection des valeurs de propriété de compte d’utilisateur à renvoyer
Configuration des valeurs de propriété de compte d’utilisateur
Utilisation de licences utilisateur Office 365
Note rapide sur les paramètres positionnels et Office 365

Vous trouverez davantage d’informations sur les cmdlets Azure Active Directoryici.

Renvoi d’informations de compte d’utilisateur Office 365

Outre les noms, il est beaucoup plus intéressant (et important) de se concentrer sur les tâches de gestion qui peuvent être effectuées à l’aide de Azure Active Directory. Azure Active Directory comprend 66 cmdlets, dont la plupart est utilisée pour gérer vos utilisateurs, groupes et licences Office 365. Par exemple, supposons que vous ayez besoin d’une liste rapide de vos utilisateurs Office 365. Essayez cette commande :

Get-MsolUser

Bien que cela nécessite d’ouvrir une parenthèse, il est judicieux de parler un instant des noms des cmdlets. Si vous regardez les noms des cmdlets Azure Active Directory, vous remarquerez qu’elles ont toutes une chose en commun :

Add-MsolForeignGroupToRole
Add-MsolGroupMember
Add-MsolRoleMember
Confirm-MsolDomain
Connect-MsolService

Comme vous pouvez le constater, chaque nom de cmdlet (la partie du nom qui vient après le trait d’union) commence par le préfixe Msol. Est-ce une coïncidence ? Pas tout à fait. Le préfixe Msol (abréviation de MsOnline) est utilisé pour identifier ces cmdlets en tant que cmdlets Azure Active Directory. Toutes les cmdlets Azure Active Directory doivent utiliser le préfixe Msol, et aucune autre cmdlet Windows PowerShell ne peut utiliser ce préfixe. Par exemple, les cmdlets SharePoint Online ont toutes le préfixe SPO :

Add-SPOUser
Connect-SPOService
Disconnect-SPOService
Get-SPOAppErrors
Get-SPOAppInfo

Les cmdlets Lync Online utilisent toutes le préfixe Cs :

Get-CsAudioConferencingProvider
Get-CsOnlineUser
Get-CsTenant
Get-CsTenantFederationConfiguration
Get-CsTenantHybridConfiguration

Le préfixe Cs est en réalité l’abréviation de Communications Server. Ceci s’explique par le fait que Lync Server était anciennement appelé Office Communications Server. Au moment où le nom a été officiellement modifié, un grand nombre de cmdlets avait déjà été finalisé. Comme la modification des noms des cmdlets à cette date tardive aurait reporté la sortie du produit, la décision a été prise de conserver le préfixe Cs.

Il est intéressant de constater que les cmdlets Exchange n’utilisent aucun type de préfixe :

Add-RecipientPermission
Get-LinkedUser
Get-RecipientPermission
Get-RemovedMailbox
Get-SendAddress

Pourquoi ? Exchange a été le premier produit serveur à lancer un ensemble de cmdlets Windows PowerShell. À cette époque, personne n’imposait l’utilisation d’un préfixe de cmdlet ou d’un autre identificateur. D’autres équipes de serveurs ont commencé à créer des cmdlets, mais il est vite devenu évident qu’il y avait un problème : si Exchange avait une cmdlet nommée Set-User (ce qui était le cas), alors qu’étaient censées faire les autres équipes qui avaient besoin d’une cmdlet pour définir des paramètres utilisateur ? (Les noms de cmdlets doivent être uniques.) La solution a consisté à utiliser des préfixes. Par conséquent, nous avons désormais des cmdlets avec des noms comme Set-MsolUser, Set-CsUser et Set-SPOSiteUser.

Dans tous les cas, l’exécution de la commande Get-MsolUser renverra des informations de ce type :

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

Il s’agit de tous vos utilisateurs Office 365.

Mais disons que vous aimeriez voir uniquement la liste des utilisateurs sans licence, c’est-à-dire des utilisateurs qui ont été ajoutés à Office 365 mais qui n’ont pas encore de licence leur permettant d’utiliser toutes les applications logicielles. Ceci est également facile :

Get-MsolUser -UnlicensedUsersOnly

Là encore, nous avons appelé la cmdlet Get-MsolUser, mais cette fois nous lui avons ajouté le paramètre UnlicensedUsersOnly. Comme son nom l’indique, ce paramètre limite les données renvoyées aux utilisateurs ne disposant pas de licences :

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

Très bien.

Nous pourrions aussi souligner que Windows PowerShell a la réputation d’être un langage informatique créé par les Martiens. Lorsque la plupart des gens pensent à Windows PowerShell, ils s’imaginent des commandes comme celle-ci :

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

Nous sommes d’accord, cette commande est quelque peu obscure... D’un autre côté, nous venons de vous montrer une commande qui renvoie uniquement les utilisateurs qui ne disposent pas de licence pour Office 365. Pour ce faire, nous avons utilisé une cmdlet nommée Get-MsolUser et un paramètre nommé UnlicensedUsersOnly :

Get-MsolUser -UnlicensedUsersOnly

Et en exécutant cette commande, nous avons obtenu les utilisateurs sans licence uniquement.

Cela signifie simplement que vous pouvez souvent rendre Windows PowerShell aussi obscur, ou au contraire aussi clair et simple, que vous le désirez.

Sélection des valeurs de propriété de compte d’utilisateur à renvoyer

Windows PowerShell vous donne la possibilité de procéder comme vous le souhaitez. Par exemple, nous avons déjà vu que l’exécution de la cmdlet Get-MsolUser renvoie trois valeurs de propriété :

UserPrincipalName
DisplayName
isLicensed

C’est bien, mais que faire si ce que nous aimerions vraiment voir, c’est le nom d’affichage de l’utilisateur, le service pour lequel il travaille et le pays/la région où notre utilisateur « consomme » des services Office 365 ? Que se passe-t-il alors ?

Remarque :
Certes, « consommer » n’est pas exactement le mot approprié. Mais ne vous inquiétez pas de la terminologie : la propriété UsageLocation indique l’emplacement géographique où l’utilisateur emploie généralement Office 365. Et ceci est très important : les licences, stratégies et fonctionnalités disponibles d’Office 365 tournent en partie autour de cet emplacement.

Comme nous l’avons déjà vu, Get-MsolUser affiche uniquement l’une de nos propriétés privilégiées : DisplayName. Il semblerait que nous n’ayons pas de chance, non ?

En effet. À moins d’exécuter cette commande à la place :

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

Voici ce que renvoie cette commande :

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

Mieux vaut ne pas expliquer comment tout cela fonctionne aujourd’hui. Ceci est en effet trop important pour n’y consacrer qu’un article de présentation. Au lieu de cela, nous allons simplement noter que la cmdlet Select-Object (qui est fournie dans le cadre de Windows PowerShell 3.0) vous permet de choisir les propriétés que vous souhaitez qu’une cmdlet renvoie. Vous voulez peut-être voir uniquement les valeurs de la propriété UsageLocation. Indiquez alors à Select-Object de ne renvoyer qu’une seule propriété :

Get-MsolUser | Select-Object DisplayName

Select-Object vous permet même de renvoyer toutes les valeurs de propriété d’un élément ; essayez d’exécuter cette commande et observez ce qui se passe :

Get-MsolUser | Select-Object *

Ceci est utile car, comme nous l’avons déjà vu, les cmdlets ne renvoient pas toujours toutes les informations disponibles pour un élément. Si vous voulez voir tout ce que Get-MsolUser peut indiquer au sujet d’un utilisateur, appliquez une commande semblable à celle-ci :

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

Et voici une commande bonus pratique, qui renvoie des informations sur les utilisateurs qui ne disposent pas d’un emplacement d’utilisation. (Ceci est important, car vous ne pourrez pas effectuer certaines opérations avec ces utilisateurs tant que l’emplacement n’aura pas été défini.) La commande est la suivante :

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

Et voici les données renvoyées :

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

Il s’agit des deux seuls utilisateurs qui ne disposent pas d’un paramètre UsageLocation.

Configuration des valeurs de propriétés de compte utilisateur

Jusqu’à présent, nous avons vu comment vous pouvez utiliser Windows PowerShell pour renvoyer des informations. Ce qui est peut-être encore mieux, c’est de pouvoir également utiliser les cmdlets Azure Active Directory pour configurer des informations. Vous dites que Belinda Newman a déménagé en France et que son emplacement d’utilisation doit être défini sur FR, le code ISO (Organisation internationale de normalisation) de la France ? OK :

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

Vous pouvez constater à quel point c’est simple. Nous savons déjà que la cmdlet Get-MsolUser peut renvoyer une propriété nommée UsageLocation. Par conséquent, définissons-nous cette valeur de propriété ? Nous utilisons simplement la cmdlet Set-MsolUser correspondante et le paramètre UsageLocation :

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

Il n’y a vraiment rien de compliqué à cela.

Et voici un aspect sympathique. Vous dites que tous les utilisateurs ont déménagé en France ? Aucun problème :

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

Dans ce cas, nous avons utilisé la cmdlet Get-MsolUser pour renvoyer tous nos comptes d’utilisateur. Nous avons ensuite « transmis » ces informations à la cmdlet Set-MsolUser. Regardez la petite barre verticale de séparation dans la commande, qui ressemble à ceci :

Quand vous voyez la barre verticale dans une commande Windows PowerShell, cela signifie que vous allez obtenir toutes les informations qui ont été récupérées à l’aide de la première cmdlet (Get-MsolUser), puis remettre ces informations à la deuxième cmdlet (Set-MsolUser). Dans ce cas, cela signifie que Set-MsolUser va prendre tous nos comptes d’utilisateur et définir la propriété UsageLocation sur FR.

Pas mal, pourrions-nous dire en toute modestie.

Remarque :
D’accord, c’est peut-être facile à dire pour nous. Mais nul besoin de s’inquiéter : voici une bonne introduction à l’utilisation des canalisations et du pipelining avec Windows PowerShell.

Utilisation de licences utilisateur Office 365

Comme nous l’avons vu précédemment, les cmdlets Azure permettent d’effectuer un grand nombre d’opérations ; par exemple, la commande suivante renvoie des informations sur le nombre de licences Office 365 dont vous disposez, ainsi que le nombre de licences qu’il vous reste à distribuer :

Get-MsolAccountSku

Cette commande renvoie des données semblables aux suivantes :

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

Dans nos exemples de données, le domaine litwareinc a reçu 25 licences (ActiveUnits) et ces 25 licences sont actuellement attribuées aux utilisateurs (ConsumedUnits).

Cette répartition est convenable. Bien entendu, il serait préférable de pouvoir visualiser les licences qui ont été attribuées à un utilisateur en particulier. En bref, voici comment rechercher les licences actuellement attribuées à Ken Myer :

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

Nous vous proposons une explication sommaire, car il s’agit d’une commande plus complexe que celles que nous avons vues jusqu’à présent. Dans cette commande, nous utilisons d’abord Get-MsolUser pour renvoyer les informations relatives à l’utilisateur kenmyer@litwareinc.onmicrosoft.com. Nous transmettons ensuite ces informations à l’applet de commande Select-Object et utilisons le paramètre ExpandProperty pour développer la propriété Licenses. Cette opération est indispensable, étant donné que Licenses est une propriété à valeurs multiples : cela signifie qu’elle contient plusieurs valeurs (dans ce cas, plusieurs licences), et nous voulons nous assurer que nous utilisons toutes les licences. Nous transmettons ensuite les informations de licence à Select-Object et développons la propriété ServiceStatus afin d’obtenir des informations détaillées sur chaque licence.

Remarque :
Si cette explication sommaire n’est pas suffisante, consultez l'article suivant sur les propriétés à valeurs multiples.

À la fin de ce processus, nous devons obtenir un résultat semblable au suivant :

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

À première vue, ce résultat n’est pas facile à interpréter. Toutefois, il semble plus complexe que ce qu’il n’est en réalité. La propriété ServicePlan contient une collection de licences (les licences disponibles dans votre organisation dépendent de l’abonnement Office 365 que vous avez souscrit). Les valeurs de la propriété ServicePlan correspondent aux éléments suivants :

Numéro d’index	Plan de services	Produit
0	YAMMER_ENTERPRISE	Yammer
1	RMS_S_ENTERPRISE	Windows Azure Active Directory
2	OFFICESUBSCRIPTION	Office Professionnel Plus
3	MCOSTANDARD	Lync
4	SHAREPOINTWAC	Office Web Apps
5	SHAREPOINTNETERPRISE	SharePoint
6	EXCHANGE_S_ENTERPRISE	Exchange

À son tour, la propriété ProvisioningStatus indique si la licence a été attribuée :

None signifie qu’aucune licence n’a été attribuée.
Success signifie que la licence est attribuée.
Disabled signifie que la licence a été attribuée, mais qu’elle a été désactivée depuis.

Comme vous pouvez le constater, toutes les licences disponibles ont été attribuées à Ken Myer, à l’exception de celle concernant Yammer.

Remarque :
Qu’est-ce que le numéro d’index dans le tableau précédent ? Le numéro d’index est un autre identificateur pour le plan de services. Conformément à l’ancienne programmation informatique, le numéro d’index 0 est attribué au premier élément d’une collection de ce type. YAMMER_ENTERPRISE possède le numéro d’index 0. Le numéro d’index 1 est attribué au deuxième élément de la collection, le numéro d’index 2 est attribué au troisième, et ainsi de suite. Comme nous le verrons dans un instant, ces numéros peuvent par exemple être utilisés pour afficher tous les utilisateurs disposant (ou non) d’une licence Yammer.

Qu’est-ce que le numéro d’index dans le tableau précédent ? Le numéro d’index est un autre identificateur pour le plan de services. Conformément à l’ancienne programmation informatique, le numéro d’index 0 est attribué au premier élément d’une collection de ce type. YAMMER_ENTERPRISE possède le numéro d’index 0. Le numéro d’index 1 est attribué au deuxième élément de la collection, le numéro d’index 2 est attribué au troisième, et ainsi de suite. Comme nous le verrons dans un instant, ces numéros peuvent par exemple être utilisés pour afficher tous les utilisateurs disposant (ou non) d’une licence Yammer.

Par conséquent, est-il possible de modifier ces attributions de licences ? Pouvons-nous, par exemple, désactiver l’attribution de licences Exchange et Lync Online de Ken ? Bien entendu ! Nous vous expliquerons la procédure à suivre ultérieurement. Toutefois, dans Office 365, vous pouvez gérer les licences (au moins partiellement) en indiquant les licences à désactiver. Pour ce faire, créez un objet d’options de licences, tel que le suivant :

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

Pour le domaine litwareinc (qui a acheté le pack de gestion de licences d’entreprise), nous souhaitons désactiver deux plans : Lync (MCOSTANDARD) et Exchange (EXCHANGE_S_ENTERPRISE). Cette commande ne désactive pas à elle seule ces licences pour tous les utilisateurs. À la place, elle crée une licence utilisateur générique dans laquelle Lync et Exchange ont été désactivés. Nous pouvons ensuite attribuer cette licence utilisateur générique à une personne réelle :

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

Si nous exécutons cette commande, puis observons à nouveau les licences utilisateur de Ken, nous devrions obtenir un résultat semblable au suivant :

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

Voilà ! Exchange et Lync Online ont été désactivés.

Affichage des informations de licence Office 365 pour des utilisateurs multiples

Il est vrai que la gestion des licences utilisateur d’Office 365 peut être un peu complexe. Mais cela n’a rien à voir avec Office 365. Ceci est dû au fait que la gestion des licences utilisateur d’Office 365 peut être un peu complexe. Après tout, différents packs de licences sont disponibles dans Office 365 et vous pouvez attribuer aux utilisateurs autant (ou aussi peu) de licences de produits individuelles que bon vous semble. Garder la trace de tout cela n’est pas facile, d’autant plus que le Centre d’administration Office 365 vous permet uniquement d’afficher les détails de licence d’un utilisateur à la fois. Souhaitez-vous obetnir la liste de tous les utilisateurs auxquels une licence a été attribuée pour Lync Online ? Bien entendu. Mais le Centre d’administration ne peut pas aisément la fournir.

En revanche, Windows PowerShell le peut. Vous vous souvenez des numéros d’index dont nous avons parlé dans la section Utilisation de licences utilisateur Office 365 ? Si c’est le cas, alors vous vous souvenez que dans notre pack de licences, Lync Online a le numéro d’index 3. Cela signifie que nous pouvons utiliser cette ligne de code à l’apparence certes obscure pour renvoyer la liste de tous les utilisateurs qui ont reçu une licence pour Lync Online :

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

En effet, c’est sans aucun doute un peu compliqué. Mais cela renvoie les informations que vous avez demandées :

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

Si vous préférez, vous pouvez également récupérer la liste de tous les utilisateurs qui n’ont pas reçu de licence pour Lync Online :

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

Cela renverra une liste d’utilisateurs totalement différente :

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

Mais que se passe-t-il si les licences Lync Online ne vous intéressent pas et que ce sont les licences SharePoint Online qui vous intéressent ? Si vous revenez en arrière et que vous regardez le tableau des licences, vous verrez que les licences SharePoint Online ont le numéro d’index 5. Notre exemple de code précédent utilisait le numéro d’index 3 (le numéro d’index de Lync Online) lorsque nous avons indiqué la propriété ServiceStatus :

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

Pour obtenir les licences SharePoint Online, il suffit de remplacer 3 par 5.

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

C’est vraiment simple.

Pour plus d’informations, reportez-vous à l’article relatif à l’attribution de licence aux utilisateurs pour les charges de travail Office 365. La maîtrise des options de licence disponibles lorsque vous utilisez Windows Powershell nécessite-t-elle un peu d’efforts ? Oui. Ce petit effort vaut-il la peine d’être fait pour pouvoir profiter des options de licence dont vous disposez lors de l’utilisation de Windows PowerShell ? C’est à vous de voir.

Mais : oui.

Note rapide sur les paramètres positionnels et Office 365

Les cmdlets Azure Active Directory sont différentes de celles d’Exchange et de Lync Online, du moins en cas d’utilisation de comptes d’utilisateur individuels. Par exemple, avec Lync Online et la cmdlet Get-CsOnlineUser, vous pouvez inclure le paramètre Identity dans votre commande ou vous pouvez l’omettre. En d’autres termes, ces deux commandes fonctionnent et elles renvoient exactement les mêmes informations :

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

Mais ce n’est pas vrai pour les cmdlets Azure Active Directory. Cette commande fonctionne :

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

Remarque :
Nous avons utilisé le paramètre UserPrincipalName ici car la cmdlet Get-MsolUser ne possède pas de paramètre Identity.

Mais cette commande ne fonctionne pas :

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

Pourquoi ? Sans entrer dans les nombreux détails techniques, la plupart des cmdlets Lync Online et Exchange configurent le paramètre Identity comme un « paramètre positionnel ». Cela signifie (dans ce cas tout du moins) que, si vous n’indiquez pas de nom de paramètre (comme -Identity), la cmdlet suppose que le premier paramètre de la commande est le paramètre -Identity. Tant que vous démarrez en indiquant l’identité de l’utilisateur, vous pouvez utiliser ou non le paramètre -Identity. Les deux options fonctionnent :

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

Les cmdlets Azure Active Directory ne prennent toutefois pas en charge les paramètres positionnels. Supposons que vous incluiez une valeur sans paramètre d’accompagnement :

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

Dans ce cas, vous obtiendrez un message d’erreur tel que celui-ci :

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

Notez également qu’Exchange et Lync Online vous permettent de faire référence aux utilisateurs de plusieurs façons différentes. Par exemple, toutes ces commandes Exchange renvoient les mêmes informations de boîte aux lettres :

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

Ces commandes utilisent respectivement le nom d’affichage Active Directory de l’utilisateur, son nom d’utilisateur principal et son alias de messagerie. L’une de ces identités fonctionnera. Mais cela fonctionnera avec Exchange et avec Lync Online. Pour l’essentiel, Azure Active Directory exige que vous utilisiez le nom principal de l’utilisateur et uniquement celui-ci :

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

Remarque :
Certes, techniquement, vous pouvez utiliser le paramètre ObjectId. Mais pour cela, vous devez entrer le GUID (identificateur global unique) attribué au compte de l’utilisateur. Par exemple : Get-MsolUser –ObjectId "62e90394-69f5-4237-9190-012177145e10" Il vous incombe de décider si vous souhaitez utiliser le paramètre UserPrincipalName ou ObjectId.

Ceci représente effectivement beaucoup d’informations à assimiler, tout du moins pour un nouvel utilisateur de Windows PowerShell. Si vous êtes novice en matière d’utilisation de Windows PowerShell, vous voudrez peut-être consulter notre article d’introduction sur l’utilisation des paramètres.

Voir aussi

Meilleures méthodes pour gérer Office 365 avec Windows PowerShell