Usar o Windows Azure Active Directory para gerenciar o Office 365

 

Tópico modificado em: 2015-03-09

Resumo: Use o Windows PowerShell para gerenciar o Office 365 usando cmdlets, scripts e processos em lote do Windows PowerShell.

Você está certo: quando vê o termo “Active Directory do Azure”, seu primeiro pensamento provavelmente não é "Ei, aposto que é assim que você gerencia o Office 365 usando o Windows PowerShell”. No entanto, como se pode ver, o “Azure” é o nome do serviço de nuvem da Microsoft há muito tempo e “Active Directory” é, há muito tempo, o nome do, bem, do Active Directory. Junte-os e você obterá o Active Directory do Azure Directory, uma tecnologia que possibilita que você use o Windows PowerShell para gerenciar usuários, grupos, licenças e assinaturas do Office 365. Este tópico inclui informações sobre:

• Retornar informações de conta de usuário do Office 365

• Seleção dos valores de propriedade das contas de usuários a serem retornados

• Configurando valores de propriedade de contas de usuário

• Trabalhar com licenças de usuário do Office 365

• Uma observação rápida sobre parâmetros posicionais e o Office 365

Se você quiser mais informações sobre os cmdlets do Active Directory do Azure, pode encontrá-las aqui.

Retornar informações de conta de usuário do Office 365

Nomes à parte, é muito mais interessante (e importante) se concentrar em tarefas de gerenciamento que podem ser executadas usando o Active Directory do Azure. O Active Directory do Azure inclui os 66 cmdlets, que são usados para gerenciar os seus usuários, grupos e licenças do Office 365. Por exemplo, você precisa de uma lista rápida dos seus usuários do Office 365? Experimente este comando:

Get-MsolUser

Embora isto se desvie do assunto principal, acho que poderia ser um bom momento para falar sobre nomes de cmdlet. Se você observar os nomes dos Active Directory do Azure cmdlets, você perceberá que todos tem algo em comum:

• Add-MsolForeignGroupToRole

• Add-MsolGroupMember

• Add-MsolRoleMember

• Confirm-MsolDomain

• Connect-MsolService

Como você pode ver, cada substantivo cmdlet (a parte do nome após o hífen) começa com o prefixo MSOL . Coincidência? Não exatamente. Em vez disso, o prefixo MSOL (curto para MsOnline) é usado para identificar estes cmdlets como Active Directory do Azure cmdlets. Todos os Active Directory do Azure cmdlets devem usar o prefixo Msol, e nenhum outro Windows PowerShell cmdlets poderão usar o prefixo Msol. Por exemplo, todos os cmdlets do SharePoint Online têm o prefixo:

• Add-SPOUser

• Connect-SPOService

• Disconnect-SPOService

• Get-SPOAppErrors

• Get-SPOAppInfo

Todos os cmdlets do Lync Online utilizam o prefixo Cs:

• Get-CsAudioConferencingProvider

• Get-CsOnlineUser

• Get-CsTenant

• Get-CsTenantFederationConfiguration

• Get-CsTenantHybridConfiguration

O prefixo Cs é realmente curto para a adequação do servidor de comunicação. Isso porque o servidor do Lync era conhecido anteriormente como o Office Communications Server. Quando o nome foi oficialmente modificado, um número grande de cmdlets já estavam completos. Já que a mudança dos nomes dos cmdlets nessa etapa poderia atrasar o lançamento do produto, foi tomada a decisão de manter o prefixo Cs.

Curiosamente, os cmdlets do Exchange não usam prefixos de nenhum tipo:

• Add-RecipientPermission

• Get-LinkedUser

• Get-RecipientPermission

• Get-RemovedMailbox

• Get-SendAddress

Por que não? O Exchange foi o primeiro produto de servidor a lançar um conjunto de cmdlets do Windows PowerShell. Naquela época, o uso do prefixo do cmdlet ou outro identificador não estava implementado. Visto que outras equipes de servidor começaram a criar cmdlets, logo ficou evidente que havia um problema: se o Exchange tinha um cmdlet denominado Set-User (e em verdade tem), neste caso, o que as outras equipes que precisavam de um cmdlet para a definição de propriedades de usuário deveriam fazer? (Os nomes dos Cmdlet deveriam ser únicos.) A solução era o uso de prefixos. Como resultado, agora temos cmdlets com nomes como Set-MsolUser, Set-CsUser, e Set-SPOSiteUser.

De qualquer forma, a execução do Get-MsolUser apresentará informações similares a estas:

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

Estes são todos os seus Office 365 usuários.

Mas digamos que você gostaria de ver uma lista contendo apenas os usuários sem licença; ou seja, usuários que já foram adicionados ao Office 365 mas ainda não foram liberados para usar os aplicativos do software. Isso também é fácil:

Get-MsolUser -UnlicensedUsersOnly

Novamente, acessamos o cmdlet Get-MsolUser, mas desta vez, somente lidaremos com os parâmetros do UnlicensedUsersOnly. Como o nome indica, esse parâmetro limita os dados retornados aos usuários cujas licenças ainda não foram emitidas:

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

Isso é muito bom.

Gostaríamos de salientar também, que o Windows PowerShell possui a reputação de uma linguagem de computador criada por marcianos. Quando muitas pessoas pensam no Windows PowerShell, nas suas mentes aparecem comandos como estes:

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

Realmente, aquele comando é um pouco....confuso …. Por outro lado, mostramos um comando que apresentou usuários que não possuíam uma licença para o Office 365. Para fazer isso, usamos um cmdlet denominado Get-MsolUser e um parâmetro denominado UnlicensedUsersOnly:

Get-MsolUser -UnlicensedUsersOnly

E quando executamos este comando, acessamos os usuários sem licença.

Isso simplesmente quer dizer que você pode torná-lo Windows PowerShell o mais enigmático possível, ou o mais claro e simples, depende de você.

Seleção dos valores de propriedade das contas de usuários a serem retornados

Windows PowerShell dá a você a habilidade de fazer as coisas da forma que você quiser fazê-las. Por exemplo, nós já vimos que executar o cmdlet Get-MsolUser retorna três valores de propriedade:

• UserPrincipalName

• DisplayName

• isLicensed

Isso é bom, mas e se o que realmente queremos ver é o nome de exibição do usuário, o departamento para o qual ele trabalha e o país/região onde nosso usuário "consume" Office 365 serviços? O que fazer?

Dica

Sim, "consome" não é exatamente uma palavra boa também. Mas não se preocupe sobre a terminologia: a propriedade UsageLocation indica a localização geográfica onde o usuário normalmente usa Office 365. E isso é muito importante: as licenças, políticas e recursos disponíveis do Office 365 giram, em parte, ao redor desta localização.

Como já vimos, Get-MsolUser apenas nos mostra uma das nossas propriedades preferenciais: DisplayName. Ao que parece, estamos sem sorte, certo?

Certo. Bem, a menos que, ao invés disso, executarmos este comando:

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

Aqui está o que esse comando retorna:

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

Não nos preocuparemos explicando como tudo isso funciona hoje; isso é muito para um artigo de visão geral. Ao invés disso, nós apenas observaremos que o cmdlet Select-Object (o qual é enviado como parte do Windows PowerShell 3.0) permite que você separe e escolha as propriedades que você quer que um cmdlet retorne. Você diz que deseja apenas ver valores para a propriedade UsageLocation? Então diga ao Select-Object para retornar apenas uma propriedade:

Get-MsolUser | Select-Object DisplayName

Select-Object ainda permite que você retorne todos os valores de propriedade para um item; tente executar este comando e veja o que acontece:

Get-MsolUser | Select-Object *

Isso é útil porque, como nós já vimos, cmdlets nem sempre retornam todas as informações disponíveis para um item. Se você quiser ver tudo que Get-MsolUser tem a dizer sobre um usuário, então use um comando semelhante a este:

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

E aqui está um comando extra útil, um que retorna informações sobre os usuários que não tenham uma localização de uso. (Isso é importante, porque você não poderá fazer determinadas coisas com esses usuários até que o local tenha sido definido.) Aqui está o comando:

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

E aqui estão os dados que retornam:

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

Esses são apenas dois usuários que temos que no momento não têm um UsageLocation.

Configurando valores de propriedade de contas de usuário

Até aqui descobrimos como você pode usar o Windows PowerShell para retornar informações. Talvez, ainda melhor seja o fato de que você também pode usar os cmdlets do Active Directory do Azure para configurar informações. Você diz que Belinda Newman se mudou para a França e precisa fazer com que seu local de uso seja definido para FR, o código da ISO (Organização Internacional de Padronização) para a França? OK:

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

Você vai descobrir como isso é fácil. Já sabemos que o cmdlet Get-MsolUser pode retornar uma propriedade chamada UsageLocation. Então definimos esse valor de propriedade? Nós simplesmente usamos o cmdlet Set-MsolUser correspondente e, sim, o parâmetro UsageLocation:

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

Não há realmente nada de complicado nisso.

E aqui está uma coisa legal. Você diz que todos os seus usuários se mudaram para a França? Sem problema:

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

Nesse caso, usamos o cmdlet Get-MsolUser para retornar todas as nossas contas de usuário. Podemos então ter essas informações em "pipe" para o cmdlet Set-MsolUser. Consulte o pequeno caractere separador de pipe no comando, o caractere tem esta aparência:

|

Quando você vê o caractere de pipe em um comando do Windows PowerShell isso significa que você obterá quaisquer informações que foram recuperadas usando o primeiro cmdlet (Get-MsolUser) e depois entregará todas essas informações para o segundo cmdlet (Set-MsoIUser). Neste caso, isso significa que o Set-MsolUser reunirá todas as nossas contas de usuário e definirá a propriedade UsageLocation para FR.

Nada mal, se virmos a situação dessa maneira.

Dica

OK, talvez seja fácil dizer. Mas não precisamos nos preocupar: aqui está uma boa introdução para usar piping e pipelines com o Windows PowerShell.

Trabalhar com licenças de usuário do Office 365

Conforme observamos anteriormente, podemos realizar várias ações com os cmdlets do Azure; por exemplo, este comando retorna informações sobre a quantidade de licenças do Office 365 que você possui, bem como a quantidade de licenças que você ainda poderá distribuir:

Get-MsolAccountSku

Os dados retornados serão similares a estes:

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

Em nossos dados de amostra, o domínio litwareinc emitiu 25 licenças (ActiveUnits) e todas as 25 licenças atualmente estão alocadas aos usuários (ConsumedUnits).

Isso é bom. Obviamente, seria melhor ainda ter a capacidade de ver as licenças que foram designadas a um usuário específico. Sem explicar todos os detalhes, mencionamos aqui como podemos encontrar as licenças atribuídas atualmente para Paulo Araújo:

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

Muito bem, ofereceremos uma explicação superficial, porque se trata de um comando mais complicado. Neste comando, primeiro usaremos Get-MsolUser para retornar as informações para o usuário pauloaraujo@litwareinc.onmicrosoft.com. Em seguida, canalizamos essas informações para o cmdlet Select-Object e usamos o parâmetro ExpandProperty "expandir" a propriedade Licenses. Precisamos fazer isso porque Licenses é uma propriedade com valores múltiplos; isso significa que contém vários valores (no caso, várias licenças), e queremos ter certeza de que estamos trabalhando com todas as licenças. Em seguida, canalizamos as informações da licença para Select-Object e expandimos a propriedade ServiceStatus para obter informações detalhadas sobre cada licença individual.

Dica

Consulte este artigo sobre propriedades com vários valores se a explicação rápida não foi suficiente.

Quando terminado, obteremos algo similar a isto:

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

Talvez o que está ocorrendo não seja óbvio à primeira vista. Felizmente, não será tão obtuso quando parece ser. A propriedade ServicePlan contém um conjunto de licenças (as licenças disponíveis na sua empresa dependem do plano adquirido do Office 365). Os valores na nossa propriedade ServicePlan equivalem ao seguinte:

Número do índice	Plano de serviço	Produto
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

Por sua vez, a propriedade ProvisioningStatus nos informa se esta licença já foi designada ou não:

• Nenhum significa que nenhuma licença foi distribuída.

• Êxito significa que a licença foi distribuída.

• Desabilitado significa que a licença foi atribuída, mas já está desativada.

Como se pode ver, Ken Myer já distribuiu todas as licenças disponíveis com a exceção de Yammer.

Dica

Qual é o Número de índice na tabela anterior? O número de índice é outro identificador do plano de serviço. Como em uma boa programação de computadores das antigas, o primeiro item em uma coleção como esta recebe o número de índice 0. Portanto, o YAMMER_ENTERPRISE possui o número de índice 0. O segundo item na coleção receberá o número de índice 1, o terceiro item terá o número de índice 2, e assim por diante. Como veremos em instantes, esses números podem ser usados para ações como mostrar aos usuários quem são os detentores de uma licença do Yammer, ou todos os usuários que não têm uma licença do Yammer.

Portanto, podemos alterar estas designações de licenças; por exemplo podemos desabilitar a licença do Ken para usar o Exchange e o Lync Online? Claro que podemos. Novamente, não explicaremos como tudo isto funciona; trataremos disso outro dia. No entanto, no Office 365 você pode gerenciar licenças (pelo menos em parte), indicando quais licenças devem ser desabilitadas. Isso é feito criando um novo objeto de opções de licenciamento, como este:

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

O que fizemos aqui é simplesmente dizer que gostaríamos de desativar os dois planos do domínio litwareinc (que adquiriu o pacote de licenciamento empresarial): Lync (MCOSTANDARD) e Exchange (EXCHANGE_S_ENTERPRISE). Observe que este comando por si só não desabilitará as licenças de qualquer usuário. Em vez disso, criará uma licença de usuário genérica em que o Lync e o Exchange foram desativados. Então, poderemos usar essa licença genérica de usuário e atribuí-la para uma pessoa real:

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

Ao executar esse comando e observarmos as licenças de usuário do Ken, veremos algo parecido com isto:

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

Pronto! Tanto o Exchange e o Lync Online foram desativados.

Visualizar informações de licenciamento do Office 365 para vários usuários

Reconhecidamente, Office 365 licenciamento de usuário pode ser um pouco complicado. Mas isso não tem nada a ver com Office 365; em vez disso, é porque, bem, licenciamento de usuário do Office 365 pode ser um pouco complicado. Afinal, há três pacotes de licenças diferentes disponíveis através de Office 365 e pode-se atribuir a usuários quantas (ou algumas) licenças de produtos individuais você achar adequado. Cuidar de tudo isso não é fácil, principalmente devido ao fato de que o Centro de administração do Office 365 apenas permite que você visualize os detalhes de licença para um usuário por vez. Você gostaria de uma lista de todos os usuários aos quais uma licença para Lync Online foi atribuída? É claro que gostaria. Mas o Centro de administração não pode fornecer isso prontamente.

Mas o Windows PowerShell pode. Lembra-se dos números de índice sobre os quais falamos na seção Trabalhar com licenças de usuário do Office 365? Se você se lembra, então você pode lembrar-se que, no nosso pacote de licença, Lync Online tem um número de índice 3. Isso significa que podemos usar esta linha de código aparentemente cifrada para retornar uma lista de todos os usuários que receberam uma licença para Lync Online:

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

E sim, isso é definitivamente um pouco complicado. Mas ele retornará as informações solicitadas para retornar:

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 você preferir, você também pode obter de volta uma lista de todos os usuários que receberam uma licença para Lync Online:

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

Isso trará de volta uma lista de usuários totalmente diferente:

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

Mas e se não quisermos saber sobre licenças do Lync Online; e se você quiser saber sobre licenças do SharePoint Online? Bem, se você quiser relembrar a tabela de licenciamento, você verá que as licenças do SharePoint Online têm um número de índice de 5. Nosso exemplo de código anterior usou um número de índice de 3 (o número de índice para Lync Online) quando nós especificamos a propriedade ServiceStatus:

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

Para obter novamente as licenças do SharePoint Online, simplesmente substitua o 3 por um 5:

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

Isso realmente é fácil.

Para obter mais informações, dê uma olhada no artigo Licenciar Usuários para Cargas de Trabalho do Office 365. Isso exige um pouco de esforço para dominar as opções de licenciamento disponíveis a você usando o Windows PowerShell? Sim, exige. Esse pouco de esforço vale a pena para poder aproveitar as opções de licenciamento disponíveis para você usando Windows PowerShell? Isso realmente é você quem decide.

Mas: sim.

Uma observação rápida sobre parâmetros posicionais e o Office 365

Os cmdlets do Active Directory do Azure são diferentes dos cmdlets do Exchange e do Lync Online, pelo menos quando se trata de trabalhar com contas de usuários individuais. Por exemplo, com o Lync Online e o cmdlet Get-CsOnlineUser, você pode incluir o parâmetro Identidade no seu comando ou pode excluir o parâmetro Identidade. Em outras palavras, esses dois comandos funcionam e ambos retornam exatamente a mesma informação:

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

Mas isso não é verdadeiro para os cmdlets do Active Directory do Azure. Este comando funciona:

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

Dica

Nós usamos o parâmetro UserPrincipalName aqui porque Get-MsolUser não tem um parâmetro Identidade.

Mas este comando não funciona:

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

Por que não? Sem entrar em muitos detalhes técnicos, muitos dos cmdlets do Lync Online e do Exchange configuram o parâmetro Identidade como um "parâmetro posicional". Isso significa que (nesses casos, de qualquer maneira), se você não especificar um nome de parâmetro (como Identidade) o cmdlet supõe que o primeiro parâmetro no comando é o parâmetro Identidade. Desde que você inicie especificando a identidade do usuário, você pode usar o parâmetro -Identidade ou não usá-lo. Qualquer uma das formas funciona:

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

No entanto, os cmdlets do Active Directory do Azure não suportam parâmetros posicionais. Suponha que você inclui um valor sem um parâmetro de acompanhamento:

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

Nesse caso, você receberá uma mensagem de erro como esta:

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

Observe, também o Exchange e o Lync Online permitem que você consulte usuários de várias formas diferentes. Por exemplo, todos esses comandos do Exchange retornam as mesmas informações de caixa de correio:

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

Os comandos usam o nome para exibição do usuário do Active Directory; seu nome de usuário principal; e seu alias de email, respectivamente. Qualquer uma dessas identidades funcionará. Mas isso é com o Exchange e com o Lync Online. Para a maior parte, o Active Directory do Azure requer que você use o nome principal e apenas o nome principal de usuário:

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

Dica

Bem, tecnicamente, você pode usar o parâmetro ObjectId. Mas isso requer que você digite o GUID (identificador global exclusivo) atribuído à conta de usuário. Por exemplo:
Get-MsolUser –ObjectId "62e90394-69f5-4237-9190-012177145e10"
Vamos deixá-lo decidir sozinho se usar UserPrincipalName ou ObjectId.

Reconhecidamente, pode ser muito a absorver, pelo menos para alguém novo ao Windows PowerShell. Se você for novo no Windows PowerShell você pode querer dar uma olhada no nosso artigo introdutório em trabalhando com parâmetros.

Veja também

Melhores maneiras de gerenciar o Office 365 com o Windows PowerShell