Uso de Windows Azure Active Directory para administrar Office 365
Última modificación del tema: 2015-03-09
Resumen: Use Windows PowerShell para administrar Office 365 mediante cmdlets, scripts y procesos por lotes de Windows PowerShell.
Sí, es cierto: cuando vemos el término “Azure Active Directory”, lo primero que nos viene a la cabeza no es precisamente “¡Ah! Seguro que así es como se administra Office 365 con Windows PowerShell”. La realidad, sin embargo, es que “Azure” ha sido durante mucho tiempo lo que ha designado al servicio de nube de Microsoft, mientras que “Active Directory” siempre ha sido el nombre de... bueno, de Active Directory. Combinémoslos y obtendremos Azure Active Directory, una tecnología que permite usar Windows PowerShell para administrar los usuarios, grupos, licencias y suscripciones de Office 365. En este tema encontrará información sobre lo siguiente:
Devolver información de las cuentas de usuario de Office 365
Selección de los valores de propiedad de cuenta de usuario que se van a devolver
Configuración de los valores de propiedad de cuenta de usuario
Trabajar con licencias de usuario de Office 365
Nota rápida sobre los parámetros de posición y Office 365
En caso de que quiera obtener más información sobre los cmdlets de Azure Active Directory, puede acceder a ella aquí.
Devolver información de las cuentas de usuario de Office 365
Nombres aparte, es mucho más interesante (e importante) centrarse en las tareas de administración que se pueden hacer con Azure Active Directory. Azure Active Directory incluye 66 cmdlets, que se usan en su mayoría para administrar los usuarios, grupos y licencias de Office 365. Por ejemplo, ¿necesita ver rápidamente una lista de sus usuarios de Office 365? Pruebe con este comando:
Get-MsolUser
Aunque nos desviemos un poco del tema, puede que sea un buen momento para hablar de los nombres de los cmdlets. Si nos fijamos en los nombres de los cmdlets de Azure Active Directory, veremos que tienen una cosa en común:
Add-MsolForeignGroupToRole
Add-MsolGroupMember
Add-MsolRoleMember
Confirm-MsolDomain
Connect-MsolService
Como se puede apreciar, cada nombre de cmdlet (la parte del nombre tras el guion) comienza por el prefijo Msol. ¿Coincidencia? No del todo. El prefijo Msol (forma abreviada de referirnos a MsOnline) sirve para distinguir a estos cmdlets como cmdlets de Azure Active Directory. Todos los cmdlets de Azure Active Directory deben incluir el prefijo Msol, y ningún otro cmdlet de Windows PowerShell puede usarlo. Por ejemplo, todos los cmdlets de SharePoint Online tienen el prefijo:
Add-SPOUser
Connect-SPOService
Disconnect-SPOService
Get-SPOAppErrors
Get-SPOAppInfo
Todos los cmdlets de Lync Online, por su parte, usan el prefijo Cs:
Get-CsAudioConferencingProvider
Get-CsOnlineUser
Get-CsTenant
Get-CsTenantFederationConfiguration
Get-CsTenantHybridConfiguration
El prefijo Cs es la abreviación de Communication Server. Esto es así porque Lync Server antes se denominaba Office Communications Server. Cuando el nombre se cambió oficialmente, ya se había completado un gran número de cmdlets. Como cambiar los nombres de los cmdlets a última hora podría haber retrasado el lanzamiento del producto, se tomó la decisión de mantener el prefijo Cs.
Es bastante interesante comprobar que los cmdlets de Exchange no usan ningún tipo de prefijo:
Add-RecipientPermission
Get-LinkedUser
Get-RecipientPermission
Get-RemovedMailbox
Get-SendAddress
¿Por qué no? Exchange fue el primer producto de servidor que publicó un conjunto de cmdlets de Windows PowerShell. En ese momento, nadie obligaba a usar un prefijo de cmdlet ni ningún otro identificador. Sin embargo, a medida que los equipos de servidor empezaban a crear cmdlets, quedó claro que existía un problema: si Exchange tuviera un cmdlet llamado Set-User (lo tiene, de hecho), ¿que tendrían que hacer los otros equipos que necesitaran un cmdlet para establecer las propiedades de usuario? Los nombres de cmdlet deben ser exclusivos. La solución era usar prefijos. El resultado es que ahora tenemos cmdlets con nombres como Set-MsolUser, Set-CsUser y Set-SPOSiteUser.
Sea cual sea el caso, cuando Get-MsolUser se ejecuta, devolverá información como la siguiente:
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
Esos son todos sus usuarios de Office 365.
Pero imaginemos que quiere ver una lista solamente de los usuarios sin licencia; es decir, usuarios que se han agregado a Office 365, pero que carecen de licencia para usar ninguna de las aplicaciones de software. Esto es fácil también:
Get-MsolUser -UnlicensedUsersOnly
Hemos vuelto a recurrir al cmdlet Get-MsolUser, solo que esta vez nos hemos concentrado en el parámetro UnlicensedUsersOnly. Como se puede deducir de su nombre, este parámetro acota los datos devueltos a únicamente aquellos usuarios para los que no se han emitido licencias:
UserPrincipalName DisplayName isLicensed
----------------- ----------- ----------
BrianJ@litwareinc.onmicrosoft.com Brian Johnson False
ScottW@litwareinc.onmicrosoft.com Scott Wallace False
Estupendo.
Es preciso decir también que Windows PowerShell tiene fama de ser un lenguaje de computación creado por marcianos, y es que cuando la gente piensa en Windows PowerShell le vienen comandos como este a la cabeza:
gc test.txt | sort {[int]$_} |% {$i = 1}{while ($i -lt $_){$i;$i++};$i++}
De acuerdo, este comando es algo... obtuso. Pero, por otra parte, aquí hemos descrito un comando que ha devuelto solo los usuarios sin licencia de Office 365, para lo cual usamos un cmdlet llamado Get-MsolUser y un parámetro llamado UnlicensedUsersOnly:
Get-MsolUser -UnlicensedUsersOnly
Y, cuando hemos ejecutado el comando, hemos obtenido solo los usuarios sin licencia.
Todo esto quiere decir, simplemente, que Windows PowerShell es tan críptico o tan simple y llano como el usuario quiera.
Selección de los valores de propiedad de cuenta de usuario que se van a devolver
Windows PowerShell le da la posibilidad de hacer las cosas como desea hacerlas. Por ejemplo, ya vimos que cuando ejecutamos el cmdlet Get-MsolUser se devuelven tres valores de propiedad:
UserPrincipalName
DisplayName
isLicensed
Eso está bien, pero ¿qué sucede si lo que realmente quisiéramos ver es el nombre para mostrar del usuario, el departamento en el que trabaja y el país o región en el que nuestro usuario "consume" los servicios de Office 365? ¿Entonces qué?
Nota
Sí, "consume" tampoco es precisamente la mejor palabra. Pero no se preocupe por la terminología: la propiedad UsageLocation indica la ubicación geográfica en la que el usuario usa normalmente Office 365. Y eso es muy importante: las licencias, directivas y características disponibles de Office 365, de cierta forma, giran en torno a esta ubicación.
Como ya hemos visto, Get-MsolUser solo nos muestra una de nuestras propiedades preferidas: DisplayName. Parece que no tenemos suerte, ¿cierto?
Cierto. Bueno, a menos que ejecutamos el siguiente comando en su lugar:
Get-MsolUser | Select-Object DisplayName, Department, UsageLocation
Esto es lo que devuelve el 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
Hoy no nos molestaremos en explicar cómo funciona todo esto; es demasiado para un artículo introductorio. En su lugar, solo señalaremos que el cmdlet Select-Object (que se suministra como parte de Windows PowerShell 3.0) permite elegir las propiedades que queremos que un cmdlet devuelva. ¿Dice que solo desea ver los valores para la propiedad UsageLocation? Indique a Select-Object que solo devuelva esa propiedad:
Get-MsolUser | Select-Object DisplayName
Select-Object incluso permite devolver todos los valores de propiedad de un elemento. Intente ejecutar este comando y vea lo que ocurre:
Get-MsolUser | Select-Object *
Eso es útil porque, como ya hemos visto, los cmdlets no siempre devuelven toda la información disponible de un artículo. Si desea ver todo lo que Get MsolUser tiene que decir acerca de un usuario, use un comando similar al siguiente:
Get-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" | Select-Object *
Y este es un comando extra muy práctico, que devuelve información acerca de los usuarios que no tienen una ubicación de uso. (Eso es importante porque no podrá hacer algunas cosas con esos usuarios hasta que dicha ubicación se haya establecido). Este es el comando:
Get-MsolUser | Where-Object {$_.UsageLocation -eq $Null} | Select-Object DisplayName, Department, UsageLocation
Y estos son los datos que se obtienen:
DisplayName Department UsageLocation
----------- ---------- -------------
Brian Johnson
Scott Wallace Operations
Esos son los únicos dos usuarios que actualmente no tienen una propiedad UsageLocation.
Configuración de los valores de propiedad de cuenta de usuario
Hasta ahora hemos visto cómo usar Windows PowerShell para devolver información. Quizás aún mejor es el hecho de que también se pueden usar los cmdlets de Azure Active Directory para configurar información. Supongamos que Belinda Newman se ha mudado a Francia y necesita que su ubicación de uso se establezca en FR, el código ISO (Organización Internacional de Normalización) para Francia. Bien:
Set-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" -UsageLocation "FR"
Ya ve qué fácil es. Ya sabemos que el cmdlet Get-MsolUser puede devolver una propiedad denominada UsageLocation. Entonces, ¿establecemos ese valor de la propiedad? Simplemente usamos el cmdlet Set-MsolUser correspondiente y, sí, el parámetro UsageLocation:
Set-MsolUser -UserPrincipalName "BelindaN@litwareinc.onmicosoft.com" -UsageLocation "FR"
En realidad no es nada difícil.
Y aquí hay algo muy interesante: Supongamos que todos sus usuarios se han mudado a Francia. Pan comido:
Get-MsolUser | Set-MsolUser -UsageLocation "FR"
En este caso, hemos usado el cmdlet Get-MsolUser para devolver todas las cuentas de usuario. Después hemos "canalizado" dicha información al cmdlet Set-MsolUser. Observe el pequeño carácter separador de barra vertical en el comando, el carácter que tiene el aspecto siguiente:
|
Cuando vea la barra vertical en un comando de Windows PowerShell, significa que va a tomar la información que haya recuperado mediante el primer cmdlet (Get-MsolUser) y proporcionársela al segundo cmdlet (Set-MsolUser). En este caso, significa que vamos a hacer que MsolUser tome todas las cuentas de usuario y establezca la propiedad UsageLocation en FR.
No está mal, si lo podemos decir nosotros.
Nota
Bien, quizá para nosotros sea fácil decirlo. Pero no hay que preocuparse: aquí hay una buena introducción al uso de canalizaciones con Windows PowerShell.
Trabajar con licencias de usuario de Office 365
Como señalamos antes, hay muchas cosas que se pueden hacer con los cmdlets de Azure. Por ejemplo, este comando devuelve información acerca del número de licencias de Office 365 que tiene, así como el número de licencias que aún no distribuye:
Get-MsolAccountSku
Va a devolver datos similares a estos:
AccountSkuId ActiveUnits WarningUnits ConsumedUnits
------------ ----------- ------------ ------------
litwareinc:ENTERPRISEPACK 25 0 25
En nuestros datos de ejemplo, se han emitido 25 licencias (ActiveUnits) para el dominio litwareinc y las 25 licencias están asignadas actualmente a usuarios (ConsumedUnits).
Eso es bueno. Desde luego, sería aún mejor tener la posibilidad de ver las licencias que se han asignado a un usuario individual. Sin explicar todos los detalles, esta es la forma en que podemos buscar las licencias asignadas actualmente a Ken Myer:
Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com" | Select-Object -ExpandProperty Licenses | Select-Object -ExpandProperty ServiceStatus
Está bien, le ofreceremos una explicación somera porque este es definitivamente un comando más complicado. En este comando, primero usamos Get-MsolUser para devolver información para el usuario kenmyer@litwareinc.onmicrosoft.com. Después canalizamos esa información al cmdlet Select-Object y usamos el parámetro ExpandProperty para “expandir” la propiedad Licenses. Necesitamos hacerlo porque Licenses es una propiedad multivalor. Esto significa que contiene varios valores (en este caso, varias licencias) y queremos asegurarnos de que estamos trabajando con todas las licencias. A continuación, canalizamos la información de licencia a Select-Object y expandimos la propiedad ServiceStatus para obtener información detallada acerca de cada licencia individual.
Nota
Eche un vistazo en este artículo sobre las propiedades multivalor si esa explicación somera no resultó ser una explicación en absoluto.
Al fin y al cabo, deberíamos obtener algo similar a esto:
ServicePlan ProvisioningStatus
----------- ------------------
YAMMER_ENTERPRISE None
RMS_S_ENTERPRISE Success
OFFICESUBSCRIPTION Success
MCOSTANDARD Success
SHAREPOINTWAC Success
SHAREPOINTENTERPRISE Success
EXCHANGE_S_ENTERPRISE Success
Ciertamente, es posible que no sea evidente a primera vista lo que está pasando. Afortunadamente, no es tan obtuso como podría parecer. La propiedad ServicePlan contiene una colección de licencias (las licencias disponibles en su organización dependen del plan de Office 365 que haya adquirido). Los valores de la propiedad ServicePlan equivalen a lo siguiente:
| Número de índice | Plan de servicio | Producto |
|---|---|---|
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 su vez, la propiedad ProvisioningStatus indica si la licencia se ha asignado o no:
Ninguno significa que no se ha asignado ninguna licencia.
Correcto significa que la licencia está asignada.
Deshabilitado significa que la licencia se asignó, pero desde entonces se deshabilitó.
Como puede ver, a Ken Myer se le asignaron todas las licencias disponibles excepto la de Yammer.
Nota
¿Qué es el número de índice en la tabla anterior? El número de índice es otro identificador para el plan de servicio. Según una buena programación informática anticuada, al primer elemento de una colección como esta se asigna el número de índice 0. De este modo, YAMMER_ENTERPRISE tiene el número de índice 0. Al segundo elemento en la colección se le asigna el número de índice 1, al tercero se le asigna el número de índice 2, y así sucesivamente. Como veremos en un momento, estos números se pueden usar para hacer cosas como mostrar todos los usuarios que tienen una licencia de Yammer o todos los usuarios que no tienen una.
¿Entonces podemos cambiar estas asignaciones de licencias? Por ejemplo, ¿podemos deshabilitar la capacidad de Ken para usar Exchange y Lync Online? Por supuesto que sí se puede. De nuevo, no nos molestaremos en explicar cómo funciona todo esto; ese es un tema para otro día. Sin embargo, en Office 365 se pueden administrar licencias (en parte de todos modos) indicando cuáles deben deshabilitarse. Para ello se crea un nuevo objeto de opciones licencias, como este:
$disabledLicenses = New-MsolLicenseOptions -AccountSkuId "litwareinc:ENTERPRISEPACK" -DisabledPlans "MCOSTANDARD","EXCHANGE_S_ENTERPRISE"
Lo que hicimos aquí es simplemente decir que, para el dominio litwareinc (que adquirió el paquete de licencias de empresa), queremos deshabilitar dos planes: Lync (MCOSTANDARD) y Exchange (EXCHANGE_S_ENTERPRISE). Tenga en cuenta que este comando, por sí mismo, no deshabilita estas licencias para ningún usuario. En su lugar, crea una licencia de usuario genérica en la que se deshabilitan Lync y Exchange. Después podemos usar esa licencia de usuario genérica y asignarla a una persona real:
Set-MsolUserLicense -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com" -LicenseOptions $disabledLicenses
Si ejecutamos ese comando y después echamos un segundo vistazo en las licencias de usuario de Ken, deberíamos ver algo parecido a esto:
ServicePlan ProvisioningStatus
----------- ------------------
YAMMER_ENTERPRISE None
RMS_S_ENTERPRISE Success
OFFICESUBSCRIPTION Success
MCOSTANDARD Disabled
SHAREPOINTWAC Success
SHAREPOINTENTERPRISE Success
EXCHANGE_S_ENTERPRISE Disabled
¡Listo! Exchange y Lync Online se han deshabilitado.
Ver la información de licencia de Office 365 de varios usuarios
Admitámoslo: las licencias de usuario de Office 365 pueden ser algo complejas. Pero esto no tiene nada que ver con Office 365; es, digamos, pues eso, que las licencias de usuario de Office 365 pueden ser algo complejas. Después de todo, hay disponibles varios paquetes de licencias a través de Office 365, y se pueden asignar tantas (o tan pocas) licencias de productos individuales como se considere adecuado. Tener un control de todo esto no es fácil, sobre todo por el hecho de que el Centro de administración de Office 365 solo permite ver los detalles de licencia de un usuario cada vez. ¿Quién no querría ver una lista de todos los usuarios que tienen asignada una licencia para Lync Online? Todos querríamos. Pero el centro de administración no puede suministrar esta información rápidamente.
Windows PowerShell, sin embargo, sí que puede. ¿Se acuerda de los números de índice de los que hablamos en el artículo Trabajar con licencias de usuario de Office 365? Si se acuerda, es probable que recuerde que, en nuestro paquete de licencias, Lync Online tiene el número de índice 3. Esto quiere decir que podemos usar la siguiente línea de código (críptica, sí) para obtener una lista de todos los usuarios para los que se ha emitido una licencia para Lync Online:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Disabled"}
Y sí, es un poco complicado. Pero devuelve la información que pidió que devolviera:
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 lo prefiere, también podría obtener una lista de todos los usuarios para los que no se ha emitido una licencia para Lync Online:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Enabled"}
Esto devolverá una lista de usuarios totalmente distinta:
UserPrincipalName DisplayName isLicensed
----------------- ----------- ----------
BonnieK@litwareinc.onmicrosoft.com Bonnie Kearney True
BrianJ@litwareinc.onmicrosoft.com Brian Johnson False
¿Qué sucedería si no queremos información sobre las licencias de Lync Online, sino sobre las licencias de SharePoint Online? Si regresamos de nuevo a la tabla de licencias, veremos que las licencias de SharePoint Online tienen el número de índice 5. En nuestro código de ejemplo anterior, cuando especificamos la propiedad ServiceStatus, utilizamos el número de índice 3 (que es el correspondiente a Lync Online):
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[3].ProvisioningStatus -ne "Disabled"}
Para obtener las licencias de SharePoint Online, solo tendrá que cambiar el 3 por un 5:
Get-MsolUser | Where-Object {$_.isLicensed -eq $true -and $_.Licenses[0].ServiceStatus[5].ProvisioningStatus -ne "Disabled"}
Sí, es así de fácil.
Para más información, eche un vistazo al artículo sobre la concesión de licencias a usuarios para cargas de trabajo de Office 365. ¿Que hay que dedicar algo de esfuerzo a dominar las opciones de licencia disponibles al usar Windows PowerShell? Por supuesto. ¿Que merece la pena ese pequeño esfuerzo para poder explotar todas las opciones de licencia disponibles al usar Windows PowerShell? Depende de la opinión de cada cual.
Pero: sí.
Nota rápida sobre los parámetros de posición y Office 365
Los cmdlets de Azure Active Directory son distintos de los cmdlets de Exchange y Lync Online, al menos en lo relativo a su funcionamiento con cuentas de usuario individuales. Así, por ejemplo, con Lync Online y el cmdlet Get-CsOnlineUser, puede incluir el parámetro Identity en el comando o prescindir de él. Dicho de otro modo, estos dos comandos funcionan y ambos devuelven exactamente la misma información:
Get-CsOnlineUser -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-CsOnlineUser "kenmyer@litwareinc.onmicrosoft.com"
Pero esto no es así en el caso de los cmdlets de Azure Active Directory. Este comando funciona:
Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com"
Nota
Aquí hemos usado el parámetro UserPrincipalName porque Get-MsolUser carece de un parámetro Identity.
Pero este comando no:
Get-MsolUser "kenmyer@litwareinc.onmicrosoft.com"
¿Por qué no? Sin entrar en detalles técnicos, muchos de los cmdlets de Lync Online y Exchange configuran el parámetro Identity como "parámetro de posición". Esto significa que (en estos casos al menos) si no especifica un nombre de parámetro (por ej., Identity), el cmdlet presupone que el primer parámetro del comando es el parámetro Identity. Siempre que se empiece un comando indicando la identidad del usuario, el parámetro Identity podrá usarse o no. Funcionará en cualquier caso:
Get-CsOnlineUser -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-CsOnlineUser "kenmyer@litwareinc.onmicrosoft.com"
Los cmdlets de Azure Active Directory, sin embargo, no admiten parámetros de posición. Imaginemos que incluye un valor sin un parámetro que lo acompañe:
Get-MsolUser "kenmyer@litwareinc.onmicrosoft.com"
En este caso, aparecerá un mensaje de error como este:
Get-MsolUser : A positional parameter cannot be found that accepts argument 'kenmyer@litwareinc.onmicrosoft.com'.
Recuerde además que en Exchange y en Lync Online se puede hacer referencia a usuarios de diversos modos. Por ejemplo, todos estos comandos de Exchange devuelven la misma información de buzón:
Get-Mailbox -Identity "Ken Myer"
Get-Mailbox -Identity "kenmyer@litwareinc.onmicrosoft.com"
Get-Mailbox -Identity "kenmyer"
Estos comandos usan, respectivamente, el nombre para mostrar de Active Directory del usuario, su nombre principal de usuario o su alias de correo. Todas esas identidades funcionarán. Pero esto es lo que sucede con Exchange y con Lync Online. Por lo general, Azure Active Directory requiere usar el nombre principal de usuario única y exclusivamente:
Get-MsolUser -UserPrincipalName "kenmyer@litwareinc.onmicrosoft.com"
Nota
Técnicamente, puede usar el parámetro ObjectId, pero para eso hay que escribir el GUID (identificador único global) asignado a la cuenta de usuario. Por ejemplo:
Get-MsolUser –ObjectId "62e90394-69f5-4237-9190-012177145e10"
Dejaremos a su entera elección decidir entre UserPrincipalName o ObjectId.
Hay que reconocer que sería mucho pedir, al menos para alguien profano en Windows PowerShell. Si es profano en Windows PowerShell, puede que le interese echar un vistazo a nuestro artículo de introducción sobre cómo trabajar con parámetros.
Vea también
Las mejores formas de administrar Office 365 con Windows PowerShell