Gerenciando Computadores no Active Directory com PowerShell – Comandos úteis

Sempre que faço alguma coisa em um Active Directory acabo usando comandos do PowerShell. Isso facilita muito a vida, principalmente quando preciso salvar os resultados e/ou comparar com alguma coisa.

Alguns comandos úteis que acabo usando:

Para Listar todos os computadores do Active Directory:

Get-ADComputer -Filter * | Select-Object -Property Name

Como algumas empresas usam algum padrão para nomes, podemos usar parte de nomes. Por exemplo, para encontrar todos os computadores que o nome começa por ESTRH:

Get-ADComputer -Filter ‘Name -like “ESTRH*”‘ | Select-Object -Property Name

Para listar os computadores pela ordem alfabética:

Get-ADComputer -Filter * | Select-Object -Property Name | Sort-Object -Property Name

Para listar os Computadores com Windows e seus Sistemas Operacionais, mostrando o resultado pela ordem dos nomes:

Get-ADComputer -Filter ‘OperatingSystem -like “*Windows*”‘ -Properties Name,Operatingsystem | Select-Object -Property Name,Operatingsystem | Sort-Object
-Property Name

Para listar os Computadores com Windows, o SO, versão do SO e se sem algum Service Pack, além do resultado ordenado pelo nome usamos:

Get-ADComputer -Filter ‘OperatingSystem -like “*Windows*”‘ -Properties Name, Operatingsystem, OperatingSystemVersion, OperatingSystemServicePack
| Select-Object -Property Name, Operatingsystem, OperatingSystemVersion, OperatingSystemServicePack | Sort-Object -Property Name

Para listar os Computadores criados na última semana, pela ordem de criação, usamos:

$date = [DateTime]::Today.AddDays(-7); Get-ADComputer -Filter ‘whenCreated -ge $date’ -Properties whenCreated, Name, Operatingsystem | Select-Object -Property Name, Operatingsystem, whenCreated | Sort-Object -Property whenCreated

Para alterar a data mude os dias no comando da variável $date.

Outro comando útil é ver quais computadores não logam no AD há algum tempo. Neste caso vamos usar 60 dias:

$date = [DateTime]::Today.AddDays(-60); Get-ADComputer -Filter ‘LastLogonDate -ge date’-Properties LastLogonDate, Name, Operatingsystem | Select-Object -Property Name, Operatingsystem, LastLogonDate | Sort-Object -Property LastLogonDate

Novamente, para alterar a data mude os dias no comando da variável $date.

Para listar todos os computadores que estão desabilitados e suas OUs, pode-se usar:

Get-ADComputer -Filter {(Enabled -eq $False)} | ft Name, DistinguishedName

Para desabilitar os computadores que não logam no AD há mais de 60 dias:

$date = [DateTime]::Today.AddDays(-60); Get-ADComputer -Filter ‘LastLogonDate -ge date’-Properties LastLogonDate, Name, DistinguishedName | Select-Object -Property DistinguishedName | Disable-ADAccount

Espero que algum desses comandos possa ser útil!!

Até a próxima!

Azure Nested Virtualization

Neste artigo vamos ver como rodar um Hyper-V em uma VM no Azure e comando em PowerShell para ativação da Feature do Hyper-V, Inicialização e formatação de um disco novo em um Windows, criação de switch virtual e configurações para a VM poder acessar a internet, tudo via PowerShell.

Já faz algum tempo onde existe a possibilidade de se usar o Hyper-V dentro de uma Máquina Virtual que roda no Azure. Esse processo é chamado de Nested Virtualization – lembrando que isso já tinha no Hyper-V normal antes de ter no Azure.

Basicamente, digamos que seja preciso fazer testes de alguma coisa, pode-se usar esse recurso no Azure para criarmos máquinas virtuais da maneira requerida, sem ter que usar os tamanhos do azure. Claro que, este recurso rodando dentro de uma VM do Azure ela será limitada pelo tamanho da Azure VM criada.

Por exemplo, digamos que você queira implantar um ambiente com System Center e quer um ambiente de testes. Pode-se criar uma VM no Azure, habilitar o Hyper-V nela e usar como se fosse um servidor de Hyper-V que se tenha dentro de casa. Com isso será possível fazer alguns testes de deployment que no Azure seriam diferentes por n motivos.

O Link abaixo tem todas as informações necessárias:

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/nested-virtualization

Eu vou seguir com o artigo para compartilhar alguns detalhes. Se você tem pressa e quer apenas os comandos, siga o link acima que vai ser mais rápido! Eu tenho algumas poucas considerações:

O primeiro ponto são as versões de VMs com suporte. Basicamente precisamos de VMs v3 para que isso possa ocorrer.

O segundo ponto é que isso pode não ser a melhor escolha caso se queira usar em produção. Funciona, mas não é o ideal, o ideal é usar as VMs do Azure (Azure VMs) para rodar os workloads. Nas VMs dos Azure temos muitos recursos interessantes e fáceis de usar como Backup e Disaster Recovery. Ok, se eu tiver o backup da Azure VM onde rodam VMs com Nested Virtualization, essas VMs terão backup, mas o tempo de restauração pode ser alto.

Outro ponto importante é que para uma Nested VM no Hyper-v se comunicar com uma Azure VM que não o próprio Host do Hyper-V é necessário que tenha um NAT (vamos ver mais abaixo) ou ainda um roteamento, o que deixa o cenário um pouco mais complexo (isso fica para um próximo artigo).

Basicamente vamos fazer a instalação do Hyper-V, Configuração de um disco para as VMs, criar, configurar e iniciar uma VM e depois vamos testar o acesso para a internet.

O Requisito para fazer as configurações é uma Azure VM, qualquer instância, desde que v3. Eu estou usando uma Standard D4s v3 (4 vcpus, 16 GiB memory)

Instalação da Feature do Hyper-V

Observação: Várias das etapas podem ser feitas via console. Eu vou fazer a maior parte via PowerShell pois é mais divertido!

Uma vez iniciada a VM a primeira ação é instalar o serviço do Hyper-V. O comando a ser usado é:

Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart

Abaixo um erro de quando tentamos rodar o comando num servidor que não tem suporte:

Esse comando vai instalar a feature do Hyper-V e depois vai reiniciar o servidor. Basicamente é o mesmo processo executado num Windows Server normal quando se instala o Hyper-V.

Quando o servidor reiniciar pode-se abrir a console do Hyper-V.

Nessa VM que eu criei no Azure, tenho um disco do Sistema Operacional (Standard HDD) e outro disco para dados de 256 GiB em Premium SSD que eu acabei de atachar na VM.

Os próximos passos podem ser pulados caso você já tenha uma pasta ou volume para as VMs do Hyper-V.

Inicialização e Formatação de Disco

O próximo passo que vou fazer é criar uma pasta para as ISOs que vou baixar e outra para as VMs, isso no disco dos dados que eu acabei de atachar. Para poder usar o disco, vou dar os seguintes comandos:

Primeiro passo dar um get-disk e ver se o disco apareceu corretamente.

Get-Disk

Nesse caso o disco número 2 é o disco de dados que acabei de apresentar para a VM.

Podemos ver que a partição dele está como RAW. Para listar todos os discos nessa situação poderíamos usar o comando:

Get-Disk | Where partitionstyle -eq ‘raw’

Podemos ver que temos o mesmo resultado!

O próximo passo é inicializar o disco. Claro que se abrirmos o Disk Management, nossa vida fica muito mais simples.

Caso queira simplificar, apenas digite no PowerShell: diskmgmt.msc

Como aqui vamos fazer via PowerShell vamos dar o seguinte comando para inicializar o disco:

Initialize-Disk -Number 2 -PartitionStyle GPT

Nesse momento o disco foi inicializado, mas ainda não temos uma partição neste disco. O espaço estará como não alocado. Abrindo o Disk Management podemos ver como está:

Agora se rodarmos o primeiro comando, o Get-Disk podemos observar que mudou:

Com o disco inicializado podemos criar o volume desejado (ou volumes, caso seja a necessidade). Para isso usamos o comando:

Get-Volume

Com esse comando podemos ver as unidades já usadas.

Para as VMs quero usar a unidade V com todo o tamanho disponível no disco 2, o disco que acabou de ser inicializado.

Para criar uma nova partição no disco, usando o tamanho total e atribuindo a letra V vamos usar o seguinte comando:

New-Partition -DiskNumber 2 -UseMaximumSize -DriveLetter V

Rodado o comando, vamos ver uma mensagem dizendo que para usar o disco, precisamos formatar com um sistema de arquivos.

Nesse momento o Disk Management está assim:

Basicamente o que precisa ser feito neste momento para usar o disco é formatar. Para isso usamos o seguinte comando:

Format-Volume -DriveLetter V -FileSystem NTFS -NewFileSystemLabel “HyperVData” -Confirm:$false

Nesse momento podemos acessar a partição e começar a usar. O Disk Manager no final ficou assim:

Claro que fizemos os scripts passo a passo. Tudo poderia ser simplificado dessa maneira (desde que soubesse o nro do disco):

Get-Disk -Number 3 | Initialize-Disk -PartitionStyle GPT

Get-Disk -Number 3 | New-Partition -UseMaximumSize -DriveLetter V | Format-Volume -FileSystem NTFS -NewFileSystemLabel “HyperVData” -Confirm:$false

Com o disco devidamente pronto, vou criar duas pastas, uma para as ISOs que vou usar e outra para as VMs.

O comando, ultra simples é:

md v:\ISO, v:\VMs

Criação de Virtual Switch

Agora com o devido disco, podemos criar um Virtual Switch:

New-VMSwitch -Name “Virtual Switch InternalNAT” -SwitchType Internal

O Virtual Switch é criado como Internal pois não adiantaria criar como um disco externo. Como um Switch do tipo Interno a rede das VMs vai conseguir se comunicar com o Host do Hyper-V, uma vez que uma interface de rede é criada no Host quando criamos o Virtual Switch.

Podemos ver as interfaces de rede com o comando:

Get-NetAdapter | ft -AutoSize

A interface de nome Ethernet é a interface padrão da VM do Azure. A outra interface, vEthernet (Virtual Switch InternalNAT) é a interface criada para utilização com o Virtual Switch criado acima.

Criação do NAT

Nesse exemplo que estamos criando, uma VM criada dentro do Host vai conseguir interagir com outras VMs (dentro do Host) e com o próprio Host. Porém, ela não poderá receber uma conexão de outras VMs que estejam criadas no Azure, por exemplo. Por padrão nem acessar um serviço rodando em outra VM do Azure uma VM criada dentro do Host, ou mesmo acessar uma página na internet, seria possível. É como se nosso computador em casa ou na empresa não tivesse acesso a internet, só se comunicaria dentro da rede local…

Para resolver essa questão, usamos uma configuração de NAT no Host do Hyper-V, assim as VMs criadas dentro dele podem se comunicar com a Internet ou outras VMs criadas no Azure. Porém, novamente, ela pode iniciar uma conexão, mas não pode receber uma conexão. Voltando a analogia da rede de casa, o Host faz o papel do NAT, que para nós normalmente é realizado pelo roteador, que hoje, normalmente está integrado ao modem. Agora ninguém na internet consegue acessar nossa estação sem um DNAT. Em outro post vamos ver como uma VM no Azure (ou dispositivo na rede local da empresa) pode se comunicar com uma VM rodando dentro de outra VM no Azure. Para isso é preciso mexer em tabelas de roteamento e fica para outra explicação.

Para este exemplo, então, vamos trabalhar com NAT, assim a VM poderá acessar a internet ou outras VMs rodando no Azure.

O primeiro passo é pagar o ifindex da interface de rede criada anteriormente. Podemos ver na imagem acima que o ifindex da interface padrão é 4 e que o ifindex que queremos, o da interface vEthernet (Virtual Switch InternalNAT), é 12.

Também podemos rodar o seguinte comando:

Get-NetIPAddress | where {$_.AddressFamily -eq “IPv4” -and $_.IPAddress -ne “127.0.0.1”} | ft InterfaceAlias, InterfaceIndex, IPAddress

Esse comando é interessante pois mostra os endereços de IP das duas interfaces. Podemos ver um endereço APIPA na interface recém criada.

Antes de efetivamente criar a NAT o que vamos fazer é dar um endereço de IP para a interface. Esse endereço vai servir como base para os endereços das VMs que serão criadas. Se uma VM for criada num endereço diferente do usado aqui ela não vai conseguir se conectar com nada, a não ser alguma outra VM que possa estar no mesmo range.

Para isso vamos usar o seguinte endereçamento: 192.168.64.0/24.

O primeiro passo que vamos fazer é colocar um IP na interface usando o primeiro endereço válido do range acima escolhido e usando o ifindex para saber em qual interface aplicar:

New-NetIPAddress -IPAddress 192.168.64.1 -PrefixLength 24 -InterfaceIndex 12

Se rodarmos o comando para vermos as informações de IP das interfaces teremos:

Get-NetIPAddress | where {$_.AddressFamily -eq “IPv4” -and $_.IPAddress -ne “127.0.0.1”} | ft InterfaceAlias, InterfaceIndex, IPAddress

Agora criamos uma NAT para que as VMs criadas no Host possam se comunicar para fora dele (sempre que iniciarem a conexão). O comando para criar a NAT é:

New-NetNat -Name “InternalNat” -InternalIPInterfaceAddressPrefix 192.168.64.0/24

Com isso, uma VM criada neste Host e usando um endereço do Range 192.168.64.0/24 e usando como gateway o IP 192.168.64.1 vai conseguir navegar na Internet ou acessar outros servidores fora dessa VM no Azure que é nosso host Hyper-V.

Criação de VM

Feitas as configurações, o próximo passo é criar uma VM e testar se funciona. Vamos criar uma Nova VM chamada VMAD01-01. Vamos criar um VHD (do tipo dinâmico) de 40GB para essa VM. Ela terá 40 GB e 1 vCPU.

O comando que cria a VM e cria um VHDx novo é:

New-VM -Name VMAD01-01 -MemoryStartupBytes 4GB -BootDevice VHD -Path v:\VMs\VMData -NewVHDPath v:\VMs\VHDs\VMAD01-01-SO.vhdx -NewVHDSizeBytes 40GB -Generation 2 -Switch “Virtual Switch InternalNAT”

Agora que a VM foi criada, vou colocar a ISO do 2019 (versão de avaliação) e vou iniciar a VM:

Add-VMDvdDrive -VMName VMAD01-01 -Path v:\ISO\17763.737.190906-2324.rs5_release_svc_refresh_SERVER_EVAL_x64FRE_en-us_1.iso -ControllerNumber 0 -ControllerLocation 1

Após Adicionar a ISO para instalarmos o Sistema Operacional, podemos ver com está a ordem do Boot, usando o comando Get-VMFirmware:

(Get-VMFirmware vmad01-01).bootorder

Nesse caso, o ideal seria trocar a ordem. Do jeito que está precisamos esperar o boot de rede para depois ir para o DvdDrive. Precisamos mudar a ordem deixando esse DvdDrive em segundo lugar. Para isso usamos o comando:

Set-VMFirmware -vmname VMAD01-01 -BootOrder (get-vmfirmware vmad01-01).bootorder[0],(get-vmfirmware vmad01-01).bootorder[2],(get-vmfirmware vmad01-01).bootorder[1]

O comando acima seta a ordem nova baseada no get da ordem atual. Após o comando, podemos ver que a ordem foi alterada. Se o comando for rodado de novo, a ordem vai ser alterada novamente.

E por último, mas não menos importante, iniciamos a VM com o comando:

Start-VM -Name VMAD01-01

Testes

Com o Windows Instalado, vamos setar o endereço IP da VM como: 192.168.64.10, máscara de subrede 255.255.255.0, gateway 192.168.64.1 e DNS 8.8.8.8.

O próximo teste será testar o acesso a alguma coisa.

O acesso na VM é realizado através do console.

Primeiro vamos tentar um ping no 8.8.8.8.

Vendo que não dá, vamos dar um Get-NetAdapter isso vai nos dizer o nome da interface e a interface index.

Após vamos ver o IP dela com o DNS.

Os comando são:

Get-NetIPAddress -InterfaceAlias Ethernet | Where AddressFamily -ne “IPv6” | fl interfacealias, interfaceindex, ipaddress

Get-DnsClientServerAddress -InterfaceAlias Ethernet

Agora vamos setar o endereço IP, o DNS e criar uma rota padrão. Os comandos são (na ordem):

New-NetIPAddress –InterfaceAlias Ethernet –IPAddress “192.168.64.10” –PrefixLength 24 -DefaultGateway 192.168.64.1

Set-DnsClientServerAddress -InterfaceAlias Ethernet -ServerAddresses 8.8.8.8

Então vamos setar o IP e o DNS e vamos tentar pingar o 8.8.8.8 novamente.

Feito isso a VM pode acessar a internet e outras Azure VMs. Em um dos próximos artigos vamos mostrar como fazer uma VM rodando dentro de um Hyper-V no Azure se comunicar com Azure VMs ou rede local.

Publicando a VM

O acesso para a VM, neste momento, somente é possível através do Host Hyper-V. Para poder acessar de outra Azure VM ou rede que tenha acesso ao IP do Host vamos fazer uma publicação. Esse é um procedimento muito parecido ao que fizemos uma publicação de um serviço.

A desvantagem desse modelo é a questão de portas que não podem se sobrepor na publicação. Esse é outro motivo para evitar usar esse serviço em produção. O ideal para uma situação em que várias VMs tenham serviços que precisam ser acessados é através de roteamento de rede (coberto em um próximo host)

Como temos uma VM dentro do Hyper-V com o IP 192.168.64.12, vamos fazer a para acesso remoto da VM no Host Hyper-V. Porém, como também usamos essa porta (3389) no Hyper-V, vamos fazer a publicação com a porta 3390.

Para isso usamos o comando:

Add-NetNatStaticMapping -NatName “InternalNat” -Protocol “TCP” -ExternalIPAddress 0.0.0.0 -ExternalPort 3390 -InternalIPAddress “192.168.64.12” -InternalPort 3389

De outra Azure VM que tem acesso no meu Host Hyper-V uso o comando: mstsc /v 10.0.3.4:3390.

Com isso consigo acessar a VM IP 192.168.64.12 que foi criada dentro do Hyper-V. o IP 10.0.3.4 é o IP do Host Hyper-V dentro da rede do Azure.

Até a próxima!

Políticas do Microsoft Teams com PowerShell

O Microsoft Teams tem tido uma grande adoção como ferramenta unificada de colaboração, comunicação e engajamento entre equipes.

O Teams também tem sido adotado em larga escala como ferramenta de instituições de ensino para aulas colaborativas.

Praticamente todas as funcionalidades que o Teams proporciona podem ser controladas através de políticas. As políticas podem ser alteradas para fazer com que recursos/funcionalidades estejam ou não acessíveis pelos usuários.

Essas políticas podem ser acessadas, editadas e atribuídas através da console de administração do Teams ou via PowerShell. Por padrão existem políticas globais com parâmetros determinados. Muitas empresas acabam não mudando estes parâmetros pois eles tendem a funcionar de uma maneira satisfatória para elas.

O intuito deste post não é discutir sobre as políticas em si, mas sim no gerenciamento destas políticas via PowerShell.

Como principal base de exemplos vamos usar a política de reunião (Meeting Policy) como exemplo. Abaixo um print de parte dessa política.

Nessa política padrão, chamada de global, qualquer pessoa da organização é admitida automaticamente na reunião. Pessoas de fora da organização ficam no lobby, aguardando para serem admitidas.

Abaixo uma imagem com todas as políticas que podem ser atribuídas aos usuários:

Os usuários precisam de uma política aplicada. Quando uma política é alterada, essa alteração é automaticamente aplicada para todos os usuários que têm aquela política.

Se uma política nova for criada ela deverá ser atribuída aos usuários.

Quando se tem um ambiente pequeno, todas as alterações podem ser realizadas pelo próprio portal assim como a atribuição. Quando o ambiente é maior, a atribuição das políticas pode ser realizada via PowerShell para facilitar a vida de quem está atribuindo essas políticas.

Antes de ir para o PowerShell um ponto é importante. Como sabemos o PowerShell é modular, muitas vezes podemos conseguir a mesma informação com diferentes módulos.

Neste caso criar e atribuir políticas para os usuários é realizado com o módulo do Skype for Business Online.

Outro ponto importante, as funcionalidades dos módulos podem sofrer alterações. Por exemplo, quando se cria um Time é possível colocar uma foto para esse time. Essa funcionalidade está presente até o módulo 0.9x (Módulo do MicrosoftTeams). Se for usar o módulo 1.05, por exemplo, não existe essa possibilidade.

Para baixar o módulo do Teams: https://www.powershellgallery.com/packages/MicrosoftTeams

Para baixar o módulo do Skype for Business Online: https://www.microsoft.com/download/details.aspx?id=39366

O primeiro ponto é vermos todas as políticas da imagem acima no PowerShell.

Política no PortalPolítica no PowerShell
Meeting PolicyTeamsMeetingPolicy
Messaging policyTeamsMessagingPolicy
Live events policyTeamsMeetingBroadcastPolicy
App permission policyTeamsAppPermissionPolicy
App setup policyTeamsAppSetupPolicy
Call park policyTeamsCallParkPolicy
Calling policyTeamsCallingPolicy
Caller ID policyCallingLineIdentity
Teams policyTeamsChannelsPolicy
Emergency calling policyTeamsEmergencyCallingPolicy
Emergency call routing policyTeamsEmergencyCallRoutingPolicy
Dial planTenantDialPlan
Voice routing policyOnlineVoiceRoutingPolicy

Obs: ao usar o comando das políticas, sempre tem o CS na frente

O primeiro passo pode ser verificar quais políticas existem para aquela necessidade. Como na maioria das vezes, vamos verificar o Meeting Policy:

O comando que vamos usar é (Módulo do Skype):

Get-CSTeamsMeetingPolicy | fl identity

Podemos ver que além da Global existem diversas outras políticas. Fora a política Global222 e MeetingPolicies, todas as outras são padrões do Teams. Essas duas políticas diferentes das que são padrões foram criadas para os usuários.

Quando se tem muitas políticas para um tipo específico de política, pode ser interessante saber quais tem uma configuração específica. Por exemplo, se quisermos saber quais políticas (dentro de meeting policy) que permitem que Todos dentro da empresa possam ser admitidos automaticamente na reunião usamos:

Get-CSTeamsMeetingPolicy | Where-Object {$_.AutoAdmittedUsers -eq ‘EveryoneInCompany’} | fl identity

Podemos notar que no resultado não consta a política Global222. Nessa política essa configuração está diferente.

Se quisermos ver qual a configuração de todas as políticas (dentro de meeting policy) para uma determinada configuração podemos usar o seguinte comando:

Get-CSTeamsMeetingPolicy | ft identity, AutoAdmittedUsers

Com o comando acima podemos ver que a política Global222 tem uma configuração diferente das outras.

Obs: A formatação do resultado pode ficar a cargo do que se achar melhor. Alguns preferem usar format-list, outros format-table. Para estes exemplos não há nenhuma preferência.

Mesmo não sendo a intenção do post de discutir as políticas, precisamos fazer as configurações das políticas via PowerShell. Vamos ver esse como alterar uma configuração em uma política já existente. Vamos pegar essa configuração AutoAdmittedUsers e alterar para EveryoneInSameAndFederatedCompany na política MeetingPolicies (Comando via módulo Skype for Business Online)

Set-CsTeamsMeetingPolicy -Identity MeetingPolicies -AutoAdmittedUsers “EveryoneInSameAndFederatedCompany”

Após rodar o comando, podemos rodar o comando para verificar como está a configuração em todas as políticas:

A criação de políticas pode ser feita via PowerShell. Particularmente, eu prefiro fazer a criação via Portal. Eu tenho essa opinião pois, normalmente, não vão ser criadas diversas políticas, normalmente são poucas. Pelo portal temos a opção de duplicar políticas, resetar a política global e criar novas, que serão baseadas na política atual da Global.

Um ponto interessante é que, por exemplo, a criação da política de Configuração de aplicativos nem é recomendada criar via powershell. Veja: https://docs.microsoft.com/en-us/powershell/module/skype/new-csteamsappsetuppolicy?view=skype-ps

A criação de uma política é simples e não precisamos colocar todos os parâmetros. Os que não forem setados vão pegar as informações da política global.

Vejamos, abaixo temos minha política global que foi alterada:

Get-CsTeamsMeetingPolicy -Identity global

Nessa política foi alterado o AllowTranscription para True.

Para criar uma política nova usamos o os comandos de criação. Abaixo vamos criar uma política de Reunião com a opção de Habilitar a gravação em nuvem desabilitada. Somente vamos colocar esse parâmetro.

New-CsTeamsMeetingPolicy -Identity Global333 -AllowCloudRecording $false

Como Podemos ver a política foi criada igual a política global atual, exceto pelo parâmetro alterado.

Agora vamos ver como alterar o parâmetro AllowTranscription para falso na política global e criar uma nova política:

Set-CsTeamsMeetingPolicy -Identity global -AllowTranscription $false

Após rodar o comando, verificamos como está a política global:

Agora vamos criar uma nova política de reuniões chamada Global444 com as opções AllowMeetNow e AllowWhiteboard desativadas:

New-CsTeamsMeetingPolicy -Identity Global444 -AllowMeetNow $false -AllowWhiteboard $false

Como é possível observar os parâmetros desejados foram alterados e o parâmetro AllowTranscription está desabilitado, pois, neste momento, é assim que ele está na política Global.

Bom, agora para saber quais políticas um usuário tem aplicada? Vou mostrar duas formas.

A primeira é usando o módulo do Skype for Business Online:

Get-CsOnlineUser user@company.com | select teams*

Aqui é possível observar que o usuário tem a política Global222 aplicada. Todas as outras estão em branco, o que significa que a política padrão (Global) está aplicada.

A segunda opção que temos para verificar as políticas do usuário é usando o módulo do Teams:

Get-CsUserPolicyAssignment -Identity user@company.com

Aqui a mesma coisa, para as políticas usando a Global Policy não vamos ter resultados. Abaixo o resultado de outro usuário onde todas as políticas foram alteradas (nos dois modelos)

Já que estamos falando em usuário, abaixo vamos ver como alterar a política de um usuário. Vamos pegar o user@company.com que tem como Teams Meeting Policy a política Global222 e vamos mudar para a política Global333 (Usando o módulo do Skype for Business Online):

Grant-CsTeamsMeetingPolicy -Identity user@company.com -PolicyName Global333

Aplicado o comando para alterar essa política, podemos ver o resultado (Usando o Módulo do Teams):

Vendo as políticas pelo comando Get-CsOnlineUser:

Agora que a alteração foi feita, podemos precisar voltar essa política para a padrão. Se observarmos quando a política padrão é usada não aparece nada, apenas quando temos outras políticas. Nesse caso atribuímos a política da mesma forma, mas usando o $null.

O comando a ser usado é (lembrando que estamos usando a política de reuniões – Módulo do Skype):

Grant-CsTeamsMeetingPolicy -Identity user@company.com -PolicyName $null

Para verificarmos usamos um dos comandos para verificar as políticas do usuário:

Podemos ver que não existe mais a política de Reuniões.

Uma observação importante: Os comandos podem demorar um pouco para serem aplicados. Então as vezes podemos aplicar uma política e rodar o comando, por exemplo, Get-CsOnlineUser e o resultado ainda não ter propagado ou aplicado. Isso ocorre com a console do portal. As vezes é necessário fechar o portal e abrir novamente.

A atribuição das políticas para os usuários não é um processo rápido usando os comandos acima. É importante que cada empresa tenha uma estratégia para lidar com as políticas. Algumas não vão nem mexer nas políticas, outras poderão criar diversas políticas a atribuir aos usuários.

É importante lembrar que sempre que um novo usuário for criado ele terá as políticas padrões e devemos atribuir as políticas diferentes, caso seja essa a necessidade. Nesse sentido pode ser melhor deixar a política padrão de uma forma que atinja o maior número de usuários. Por exemplo, se um parâmetro deve ser para todos, o ideal é ter ele na política padrão. Se um outro parâmetro é diferente para poucos usuários o ideal seria criar uma nova política com aquele parâmetro diferente e atribuir a esses usuários.

A atribuição das políticas pode ser feita através de uma variável que contenha diversos usuários. Para isso usamos um foreach.

No exemplo abaixo temos um arquivo chamado usuarios.txt (onde está o UPN de cada usuário) na pasta c:\scripts e vamos aplicar a política Global333 para todos esses usuários.

$users = Get-Content -Path C:\scripts.txt

foreach ($user in $users) {Grant-CsTeamsMeetingPolicy -Identity $user -PolicyName Global333}

Por último pode acontecer de termos muitos usuários para aplicarmos as políticas. Para isso podemos fazer um comando em massa. Essa forma é mais eficaz do que o comando acima. Esse comando usa o módulo do Teams.

Nesse caso vamos imaginar que vamos usar o mesmo arquivo usado acima.

New-CsBatchPolicyAssignmentOperation -PolicyType TeamsMeetingPolicy -PolicyName “Global333” -Identity $users -OperationName “Batch0005”

Caso o comando não funcione corretamente sugiro remover o OperationName que não é requerido.

Quando o comando for executado ele vai gerar um ID. Podemos usar outro comando para verificar como está a execução deste ID:

Esse comando pode ser usado para apenas um usuário. É o meu caso, vou usar:

New-CsBatchPolicyAssignmentOperation -PolicyType TeamsMeetingPolicy -PolicyName “Global222” -Identity user@company.com -OperationName “Batch0005”

Podemos observar que após o comando rodar temos o ID da Operação.

Para ver o resultado (ou andamento) usamos o seguinte comando (use o seu OperationId):

Get-CsBatchPolicyAssignmentOperation -OperationId a9803475-34d7-4304-b556-c077866957d9 | Select -ExpandProperty UserState

Espero que isso possa ajudar!

Até a próxima!!