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!!

Hyper-V Server – Dos comandos iniciais ao Cluster

Nesse post será mostrado as configurações iniciais em um host com Hyper-V Server 2012 R2 até a configuração de um cluster entre dois nós.

Para isso serão usados dois nós com Hyper-V Server 2012 R2 e quatro interfaces de rede para as seguintes funções:

1 – Gerenciamento do Servidor – Nome: MANAGEMENT;
2 – Rede Pública – Utilizada para a rede das VMs – Nome: PUBLIC_NETWORK;
3 – Live Migration – Rede utilizada para a migração de VMs entre os dois nós – Nome: LIVE_MIGRATION;
4 – Heartbeat – Rede utilizada para comunicações do Cluster – Nome: HEARTBEAT.
Teremos três discos compartilhados, um vai ficar como quórum e os outros dois ficarão para as VMs.

Alguns passos como instalação serão pulados. Vou mostrar a configuração de apenas um host.

Tela inicial após instalação:
Após instalar o SO e logar no servidor a seguinte tela aparecerá:

1401

Instalação de drivers de rede:
Detalhe interessante foi que o servidor não reconheceu os drivers de rede. Esse será o primeiro passo, fazer a instalação dos drivers de rede.
A instalação dos drivers de rede é muito simples, basta inserir um pendrive com os executáveis no servidor e pelo Prompt de Comando executar.

1402

Isso pode ser realizado tanto para a instalação de drivers que não foram reconhecidos pelo SO quanto para atualização.
Com os drivers de rede reconhecidos o próximo passo é configurar o adaptador de rede que será usado para o gerenciamento do servidor e então continuar as configurações através do acesso remoto e não mais pela console.

Configuração de endereços IP e nomenclatura nas interfaces:

A configuração do IP na interface de rede pode ser realizada pelo Server Configuration ou via PowerShell. Se for o caso de fazer via powershell, basta no prompt de comando digitar Powershell.

1403

Configurando a interface via PowerShell:
1º Passo é identificar as interfaces de rede do servidor. Para isso usar o comando:
Get-NetAdapter
No meu caso sei qual interface vai fazer o que através do MAC Address. Para ver qual o MAC de cada placa basta digitar:
Get-NetAdapter | ft Name, MacAddress
Identificada a placa vamos dar o nome para ela. Nesse caso o nome será MANAGEMENT e a placa correspondente está com o nome “Ethernet 4”
Rename-NetAdapter -name “Ethernet 4” -NewName “MANAGEMENT”
Caso exista um DHCP entregando IP para essa interface de rede não será preciso fazer nenhuma configuração. Caso contrário para setar as configurações de IP podem ser usados os comandos:
New-NetIPAddress -InterfaceAlias “MANAGEMENT” -IPAddress 10.10.0.222 -PrefixLength “24” -DefaultGateway 10.10.0.254
Set-DnsClientServerAddress -InterfaceAlias “MANAGEMENT” -ServerAddresses “10.10.0.209”,”10.10.0.202″
No caso acima será configurado o IP 10.10.0.222 com máscara 255.255.255.0, gateway 10.10.0.254 e DNS 10.10.0.209 e 10.10.0.202.

Feita essa configuração pelo PS é possível voltar até o Server Manager e visualizar as alterações usando a opção 8: “Network Settings”
Como as configurações para as outras três redes são iguais, não vou mostrar aqui.

Configuração de VLAN em uma interface de rede:
Caso seja preciso adicionar uma VLAN em alguma placa:
O seguinte comando mostra as placas e VLANs:
Get-NetAdapter | ft Name, Status, Linkspeed, VlanID
Para alterar a Vlan de uma placa basta usar o seguinte comando:
Set-NetAdapter –Name “LIVE_MIGRATION” -VlanID 618
O comando acima coloca a VLAN 618 na placa de nome “LIVE_MIGRATION”.
Caso ocorra um erro será preciso ver se no registro da placa existe o campo de VLANID.

Para acrescentar no registro:
Precisamos do Interface Guid da placa. No caso vamos usar a “LIVE_MIGRATION”:
Get-NetAdapter -name “LIVE_MIGRATION” | ft InterfaceGuid

1404

Feito isso será preciso abrir o Registro (basta digitar regedit no Prompt de comando ou PowerShell) e procurar pelo InterfaceGuid dentro de:
HKEY_LOCAL_MACHINE\SYSTEM\ControlSet0001\Control\Class\{4D36E972-E325-11CE-BFC1-08002bE10318}

1405

Quando encontrar será preciso criar uma nova string chamada VlanId e colocar o número da Vlan:

1406

Após podemos verificar no powershell:
Get-NetAdapter | ft Name, Status, Linkspeed, VlanID

1407

Um dado importante, após essa alteração no registro será preciso reiniciar o servidor.

Habilitando o Acesso Remoto:
Com o IP da interface de gerenciamento configurado o próximo passo é habilitar o acesso remoto ao servidor para continuarmos as configurações. Para isso no server manager basta escolher a opção 7: “Remote Desktop” que vem desabilitada por padrão.
Será perguntado o que fazer e deverá ser inserido E para habilitar.

1408

Então será perguntado o nível de autenticação e pode ser escolhido o 1. Então vira a mensagem que o Remote Desktop foi habilitado:

1409

Liberando o Firewall para Acesso Remoto:
Com o Remote Desktop habilitado pode-se acessar o servidor como qualquer conexão RDS.
Caso o acesso não seja possível será preciso verificar o firewall do Hyper-V. Para verificar as regras de Acesso remoto precisamos do comando:
Get-NetFirewallRule | where DisplayName -Match “Remote Desktop” | ft DisplayName, Enabled
ou
Get-NetFirewallRule -Group “@FirewallAPI.dll,-28752” | ft DisplayName, Enabled
E habilitamos:
Enable-NetFirewallRule -Group “@FirewallAPI.dll,-28752”
Feito isso o acesso remoto deve funcionar.

Configurando o Nome do Servidor:
Acessando o servidor remotamente, o próximo passo pode ser acertar o nome.
Pelo Server Configuration escolher a opção 2 e digitar o novo nome. Será pedido para reiniciar o servidor.

Ingressando no Domínio:
Após o servidor reiniciar e acessar remotamente, um passo interessante é colocar no domínio para ele poder entrar nas políticas da organização.
Para ingressar o servidor no domínio basta escolher a opção 1 no Server Configuration.
Para ingressar no domínio deve-se apertar D e então será pedido o nome do domínio. Após digitar o nome do domínio será pedido o nome do usuário que tenha permissão para ingressar o servidor no domínio. Quando o usuário for adicionado, uma nova janela abrirá para que seja colocada a senha. Nessa janela não vai aparecer nenhum caractere quando a senha for digitada. Ao final basta dar Enter. Será pedido se queremos trocar o nome do servidor e de ser escolhido não e então o servidor será reiniciado.

Atualização de todos os drivers:
Com o servidor reiniciado algumas coisas precisam ser finalizadas.
Os drivers devem ser atualizados e as interfaces de rede devem ser configuradas.
As instruções para atualização de drivers podem ser encontradas no seguinte link:
http://technet.microsoft.com/en-us/library/jj647787.aspx

Atualização do Servidor:
Após a atualização dos drivers e acerto de todas as interfaces de rede o ideal é atualizar o servidor. Em Server Configuration escolher a opção 6. Um novo prompt vai surgir perguntando se é para procurar todos os downloads ou somente os recomendados. Pode-se escolher todos pressionando A.

1410

Quando o servidor terminar de verificar os updates disponíveis ele pedirá qual a opção de instalação, se todos, nenhum ou algum update em específico. Nesse caso vamos escolher todos, para isso pressionamos A novamente.

1411

1412

Após será pedido para reiniciar o servidor.

1413

Configurações de disco:

Com o servidor atualizado, com drivers corretos, ingressado no domínio e com as interfaces de rede funcionando chegou a hora de configurar os discos.
Para usar o Disk Management o ideal é utilizar outro computador. Antes de acessar é preciso de uns poucos comandos:
No host hyper-v, dentro do Powershell utilizar os comandos:
Add-WindowsFeature -Name File-Services
Enable-NetFirewallRule -DisplayGroup “Remote Volume Management”
Start-Service vds
Nesse momento devemos reiniciar o servidor.

1414

Na estação ou servidor que vai ser usado para acessar o servidor remotamente usar os comandos:
cmdkey /add:”IP Hyper-V Host” /user:domínio\usuário /pass
Exemplo: cmdkey /add:”10.10.0.222” /user:contoso\administrator /pass
Vai ser requerida a senha.
netsh advfirewall firewall set rule group=”Remote Volume Management” new enable=yes

Acessando o Disk Management Remotamente:
Feito isso será possível abrir o Disk Management do host Hyper-V através do Computer Management da estação ou servidor remoto.
Após abrir o Computer Management ir em Action e Connect to Another computer …

1415

Instalação do MPIO:
Acessando o disk manager do servidor podemos fazer as ações necessárias. Nesse caso vou instalar o Multi-Path IO. Para isso vou usar o comando no PowerShell:
Add-WindowsFeature -name multipath-io

1416

Para acessar o MPIO basta digitar:
mpiocpl
As configurações do MPIO podem mudar conforme o vendor.

CLUSTER:
Adicionando a feature de Cluster:
O próximo passo é configurar o cluster. Nos hosts adicionar a feature:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools

1417

Teste dos nós do Cluster:
Instalada a feature, será preciso testar se será possível criar o host entre os nós:
Test-Cluster -Node hc01b10, hc01b11

1418

Como é possível observar ocorreu um aviso. Abrindo o documento é possível ver que o aviso é sobre rede. Esse aviso se deve ao fato de ter algumas interfaces de rede que não vou usar ativas. Para isso vou desabilitar as interfaces de rede que não vou usar. Para executar o comando pode-se usar o seguinte comando em PS:
Get-NetAdapter | where status -eq disconnected | Disable-NetAdapter (será preciso dar um Y para confirmar cada interface)

Criando o Cluster:
Para criar efetivamente o cluster usar:
New-Cluster -Name CONTOSOCLUSTER -Node HC01B10, HC01B11 -StaticAddress 10.10.0.30

11419

Acessando o Cluster Remotamente:
Nesse momento já é possível usar a interface gráfica em outro servidor ou estação para acessar o cluster criado e fazer o gerenciamento. Apenas um detalhe importante, apesar de o gerenciamento abrir através de um WS 2012 (abre mas não vai ser possível administrar corretamente), deve-se usar um WS 2012 R2 ou o RSAT para Windows 8.1 para o gerenciamento.

Renomeando as interfaces de rede do Cluster:
Depois de criado, será preciso nomear as interfaces de rede no cluster, para facilitar o gerenciamento.
Para isso vamos usar o comando:
Get-ClusterNetworkInterface

1420

Com isso vamos renomear as interfaces de rede do cluster. A rede de nome “Cluster Network 1” é na realidade a rede Heartbeat nos servidores, então vou renomear a rede do cluster para esse nome:
(Get-ClusterNetwork | where name -eq “Cluster Network 1”).Name = “HEARTBEAT”
Usar Get-ClusterNetwork para ver como ficou.

1421

Após alterar os nomes, será preciso verificar as métricas, tendo a HEARTBEAT como mais baixa:
Get-ClusterNetwork | ft Name, Metric, AutoMetric, Role
O commando acima verifica as métricas e o comando abaixo altera a métrica da rede Heartbeat:
(Get-ClusterNetwork “HEARTBEAT”).Metric=900
A alteração da métrica pode ser feita em apenas um servidor, já que é um comando de cluster.
Para finalizar a configuração vamos criar um Virtual Switch usando a rede Public_Network. Esse comando poderia ser executado antes da criação do cluster:
Para criar um Switch Virtual chamado “Public_Network – Virtual Switch” usando a interface de nome Public_Network usamos o seguinte comando:
New-VMSwitch –Name “Public_Network – Virtual Switch” –NetAdapterName “Public_Network” –AllowManagementOS $false

Configurando os discos do Cluster:
Finalizando a configuração do cluster temos os discos:
Para mostrar os discos do cluster basta usar o seguinte comando:
Get-ClusterResource | where ResourceType -eq “Physical Disk”

1422

Para saber se o cluster já indicou um disco de quórum basta usar o seguinte comando:
Get-ClusterQuorum
Para adicionar os outros dois discos como Cluster Shared Volume:
Add-ClusterSharedVolume “Cluster Disk 3”

1423

Renomeando os discos do Cluster:
Finalmente para renomear um cluster disk podemos usar o seguinte comando:
(Get-ClusterSharedVolume -Name “Cluster Disk 2”).Name = “POC_2”

Pronto. Agora é só usar o cluster criado no Hyper-V Server 2012 R2.

Para gerenciamento de Cluster com PowerShell existe este post: http://yudicezar.wordpress.com/2013/12/14/comandos-powershell-em-cluster-2012/
Para gerenciamento de VMs com PowerShell existe este post: http://yudicezar.wordpress.com/2013/06/18/gerenciando-vms-no-hyper-v-com-powershell/

PowerShell no Azure

Claro, o PowerShell (PS) também pode ser usado para um grande número de tarefas no Microsoft Azure.

O primeiro passo é baixar o módulo do PowerShell do Azure. Esse mesmo link pode ser encontrado em: http://azure.microsoft.com/pt-br/downloads/.
Feita a instalação basta abrir o Windows Azure Powershell.
Como dizia um professor, o óbvio deve ser dito, para se conectar no Azure é preciso de uma subscription. Partindo do pressuposto que você tenha uma subscription no Azure vamos aos métodos de conexão:

Método Azure AD:
Basta digitar, no Azure PS Add-AzureAccount. Após dar o enter abrirá uma janela pedindo as credenciais da subscription.
Um detalhe interessante é que a credencial, nesse método, fica válida por 12 horas e depois expira, sendo necessário logar novamente.

Método Certificado:
No Azure PS digitar Get-AzurePublishSettingsFile
Após esse comando, no browser abrirá pedindo autenticação. Depois de autenticar, será preciso baixar o arquivo com as informações (o download vai abrir automaticamente).
Após baixar o arquivo será preciso importar no PS:
Com o comando PS Import-AzurePublishSettingsFile seguido pelo caminho do arquivo. Exemplo:
Import-AzurePublishSettingsFile ‘D:\Cert\WindowsAzure-5-15-2014credentials.publishsettings’

Após isso basta usar os comandos do PS para gerenciar os serviços no Microsoft Azure.

Em breve devo postar alguns comandos para gerenciamento de VMs e rede dentro do Azure para extensão do Datacenter.

Até a próxima!!

Removendo hosts do System Center Virtual Machine Manager 2012 SP1

Um problema que pode acontecer quando se administra um ambiente de virtualização com o System Center Virtual Machine Manager (VMM) é perder um host e ele continuar aparecendo na console e, através dela, ocorre um erro ao tentar remove-lo. Quando isso acontece é preciso ir no SQL onde a Database está e fazer a remoção manual dos registros.

Antes de tudo deve ser realizada um backup da database do VMM.
Outra boa atitude é parar o serviço do VMM.

Para isso é preciso seguir os seguintes passos (Observação: Será mostrado baseado no VMM 2012 SP1. Em versões anteriores algumas tabelas não existem pois são recursos novos, isso pode acontecer no 2012 R2, também):

Dentro do banco de dados todos os hosts terão um HostID. O HostID será usado nas queries nas outras tabelas e para a remoção dos registro.

Para isso vamos supor que precisamos deletar o servidor chamado Servidor01 e o domínio é o contoso.com e esse servidor pertencia a um cluster e estava conectado a um storage via iSCSI.

Abrir o SQL Server Management Studio e conectar ao servidor onde está o bando de dados do VMM;
Encontrar o bando VirtualManagerDB e expandir Tables.

Dentro das tabelas procurar a que tem o seguinte nome: dbo.tbl_ADHC_Host. Nessa tabela iremos encontrar o HostID. Para visualizar o conteúdo existem duas possibilidades:

Clicar com o botão direito e ir em Select Top 1000 Rows. Com essa opção serão mostrados os 1000 primeiros registros.

Caso existam mais de 1000 registros ou muitos registros e exista um desejo de se encontrar o resultado mais rápido será preciso ir em New Query e digitar o seguinte:
SELECT HostID FROM tbl_ADHC_Host WHERE (ComputerName = ‘FQDN’)

E executar. Lembrando que o FQDN é o nome qualificado do computador: Exemplo Server01.contoso.com. Com isso a query ficaria:
SELECT HostID FROM tbl_ADHC_Host WHERE (ComputerName = ‘Server01.contoso.com’)

O Resultado da query ou pelas 1000 linhas teremos o HostID algo parecido com:

F34FDB64-C78C-4EC0-BDB8-75811292277C esse HostID iremos utilizar bastante nessa jornada para eliminação do registro. Outro registro que será interessante copiar é o HostGroupID.

O processo é bastante simples, mesmo para hosts envolvendo conexões iSCSI:
Começamos com uma query para determinar as interfaces de rede:
Para essa query será utilizado o HostID capturado anteriormente.
SELECT * FROM tbl_ADHC_HostNetworkAdapter WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)

Após esse comando será preciso copiar todos os NetworkAdapterID.
Na próxima query vamos começar a deletar. Não importa que nenhuma seja deletada, o importante é seguir na ordem.

Nessa query serão utilizados os HostNetworkAdapterID, que no meu caso eram seis.

DELETE FROM tbl_NetMan_HostNetworkAdapterToIPSubnetVLan WHERE (HostNetworkAdapterID = ‘CD45D8CF-7945-4B14-A4C8-270186DAA4F4’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToIPSubnetVLan WHERE (HostNetworkAdapterID = ‘7B247D6E-6F77-4F1C-865E-4F8BDFDF4DAC’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToIPSubnetVLan WHERE (HostNetworkAdapterID = ‘A34EFC2E-C43D-496E-AFC5-73D30F5EDA88’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToIPSubnetVLan WHERE (HostNetworkAdapterID = ‘C52FF0DE-67C7-4631-B1EE-8366B8DA92A4’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToIPSubnetVLan WHERE (HostNetworkAdapterID = ‘D533398C-40E4-4461-8A5C-D9CC9C623807’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToIPSubnetVLan WHERE (HostNetworkAdapterID = ‘EDFE213C-D656-4A35-9B41-EB6D0D0F40FD’)

A próxima query só deve ser utilizada caso haja problema nas posteriores, nela é utilizado o HostGroupID:
DELETE FROM tbl_NetMan_LogicalNetworkDefinitionToHostGroup WHERE (HostGroupID = ‘4FAC29F3-9964-4049-AB7D-E07A2D4C732A’)

Se nas próximas queries houverem problemas, utilizar a anterior:

DELETE FROM tbl_NetMan_HostNetworkAdapterToLogicalNetwork WHERE (HostNetworkAdapterID = ‘CD45D8CF-7945-4B14-A4C8-270186DAA4F4’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToLogicalNetwork WHERE (HostNetworkAdapterID = ‘7B247D6E-6F77-4F1C-865E-4F8BDFDF4DAC’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToLogicalNetwork WHERE (HostNetworkAdapterID = ‘A34EFC2E-C43D-496E-AFC5-73D30F5EDA88’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToLogicalNetwork WHERE (HostNetworkAdapterID = ‘C52FF0DE-67C7-4631-B1EE-8366B8DA92A4’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToLogicalNetwork WHERE (HostNetworkAdapterID = ‘D533398C-40E4-4461-8A5C-D9CC9C623807’)
DELETE FROM tbl_NetMan_HostNetworkAdapterToLogicalNetwork WHERE (HostNetworkAdapterID = ‘EDFE213C-D656-4A35-9B41-EB6D0D0F40FD’)

 

Nas próximas queries será utilizado o HostID novamente:

DELETE FROM tbl_ADHC_HostNetworkAdapter WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_ADHC_VirtualNetwork WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_ADHC_HostVolume WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_ADHC_HostDisk WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_WLC_PhysicalObject WHERE (HostId = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_WLC_VObject WHERE (HostId = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)

 

Se houver uma ou mais interfaces iSCSI os passos abaixo precisam ser executados, caso contrários passe para as três últimas queries.

A próxima query é um select. Copie os ISCSIHbaID. Para ela, será preciso saber o iqn do servidor:
SELECT ISCSIHbaID FROM tbl_ADHC_HostInternetSCSIHba WHERE (ISCSINodeName = ‘iqn.1991-05.com.microsoft:Servidor01.contoso.com’)

Após o Select vamos deletar as entradas:

DELETE FROM tbl_ADHC_ISCSIHbaToPortalMapping WHERE (ISCSIHbaID = ’95B34A35-BA98-40C8-9E62-1AB645D55AA8′)
DELETE FROM tbl_ADHC_ISCSIHbaToPortalMapping WHERE (ISCSIHbaID = ‘DB93CDF4-23C5-4780-8520-45FC27F74981’)
DELETE FROM tbl_ADHC_ISCSIHbaToPortalMapping WHERE (ISCSIHbaID = ‘F38976A4-8361-4D5D-95CC-74F55292D7D6’)
DELETE FROM tbl_ADHC_ISCSIHbaToPortalMapping WHERE (ISCSIHbaID = ’04D4AF9D-8C27-44D1-82F5-A1D53EA1F467′)
DELETE FROM tbl_ADHC_ISCSIHbaToPortalMapping WHERE (ISCSIHbaID = ‘85390938-1D23-4E3E-BF30-BC7095C98035’)

DELETE FROM tbl_ADHC_ISCSIHbaToTargetMapping WHERE (ISCSIHbaID = ’95B34A35-BA98-40C8-9E62-1AB645D55AA8′)
DELETE FROM tbl_ADHC_ISCSIHbaToTargetMapping WHERE (ISCSIHbaID = ‘DB93CDF4-23C5-4780-8520-45FC27F74981’)
DELETE FROM tbl_ADHC_ISCSIHbaToTargetMapping WHERE (ISCSIHbaID = ‘F38976A4-8361-4D5D-95CC-74F55292D7D6’)
DELETE FROM tbl_ADHC_ISCSIHbaToTargetMapping WHERE (ISCSIHbaID = ’04D4AF9D-8C27-44D1-82F5-A1D53EA1F467′)
DELETE FROM tbl_ADHC_ISCSIHbaToTargetMapping WHERE (ISCSIHbaID = ‘85390938-1D23-4E3E-BF30-BC7095C98035’)
DELETE FROM tbl_ADHC_HostInternetSCSIHba WHERE (ISCSIHbaID = ’95B34A35-BA98-40C8-9E62-1AB645D55AA8′)
DELETE FROM tbl_ADHC_HostInternetSCSIHba WHERE (ISCSIHbaID = ‘DB93CDF4-23C5-4780-8520-45FC27F74981’)
DELETE FROM tbl_ADHC_HostInternetSCSIHba WHERE (ISCSIHbaID = ‘F38976A4-8361-4D5D-95CC-74F55292D7D6’)
DELETE FROM tbl_ADHC_HostInternetSCSIHba WHERE (ISCSIHbaID = ’04D4AF9D-8C27-44D1-82F5-A1D53EA1F467′)
DELETE FROM tbl_ADHC_HostInternetSCSIHba WHERE (ISCSIHbaID = ‘85390938-1D23-4E3E-BF30-BC7095C98035’)

Finalmente as últimas três queries:

DELETE FROM tbl_ADHC_HostBusAdapter WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_NetMan_InstalledVirtualSwitchExtension WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)
DELETE FROM tbl_ADHC_Host WHERE (HostID = ‘F34FDB64-C78C-4EC0-BDB8-75811292277C’)

Pronto, o Host foi removido.

Via PowerShell para se tentar remover um host o comando é:
remove-vmhost Server01.contoso.com –force
Mas se não foi pela console, muito provavelmente via PS também vá dar erro.

Para se remover um cluster via SQL:

SELECT ClusterID FROM tbl_ADHC_HostCluster WHERE (Name = ‘CLUSTER.contoso.com’)
Após o select, copiar o ClusterID. Lembrando que o cluster não pode ter hosts associados:
DELETE FROM tbl_ADHC_ClusterDisk WHERE (ClusterID = ‘A67C6DC5-286C-4E7A-AE16-702CBA45107D’)
DELETE FROM tbl_ADHC_HostCluster WHERE (Name = ‘CLUSTER.contoso.com’)

 

Até a próxima!!

Comandos Powershell em Cluster 2012

Quando falamos em virtualização, a melhor forma para gerenciamento é através do System Center. Agora, caso não se use o system center ou você seja um daqueles que gostam de usar powershell para quase tudo seguem alguns comandos para gerenciamento de VMs em cluster com Windows Server 2012 ou Hyper-V 2012. Esses comandos também funcionam nos 2012 R2:

Dentro de um dos hosts podemos usar os seguintes comandos:

Verificar o nome do cluster:
Get-Cluster

Verificar o Cluster Group:
Get-ClusterGroup

Verificar os nós de um cluster:
Get-ClusterNode

Verificar as VMs em todos os nós do Cluster e em qual nó cada VM está:
Get-ClusterResource | where resourcetype -eq “Virtual Machine” | fl ownergroup, ownernode

Outra forma de verificar as VMs de todos os nós de um cluster:
Get-ClusterNode | foreach ($_.name) {get-vm -computername $_.name}
No caso acima não fica espeficificado em qual host a VM está.

Aqui especifica em qual host cada VM está:
Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | ft vmname, computername}
Um detalhe interessante é que os dois scripts acima verificam todas as VMs em hosts físicos de um cluster, porém, pode acontecer de algumas VMs não estarem clusterizadas.

Para verificar todas as VMs de um cluster usamos o seguinte comando:
Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | where IsClustered -eq $true | ft vmname, computername}

Para ver as VMs que estão em hosts do cluster sem estarem clusterizadas rodamos o comando quase igual ao anterior:
Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | where IsClustered -eq $false | ft vmname, computername}

Verificar as configurações de processador de todas as VMs do Cluster:
Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | Get-VMProcessor}

Verificar as VMs de um cluster onde a compatibilidade do processador para migração entre hosts com processadores de diferentes versões não está habilitada:
Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | Get-VMProcessor | where CompatibilityForMigrationEnabled -eq $false}

Se houver uma ideia de alterar essas VMs que não estão com compatibilidade de processador para o status ativo podemos usar o seguinte comando (lembrando que essa feature só pode ser alterada com a VM desligada, então o script irá desligar as VMs e ligar após a alteração)

$a = Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | Get-VMProcessor | where CompatibilityForMigrationEnabled -eq $false} | foreach ($_.vmname) {$_.vmname}
$b = Get-ClusterNode | foreach ($_.name)  {get-vm -computername $_.name | Get-VMProcessor | where CompatibilityForMigrationEnabled -eq $false} | foreach ($_.vmname) {$_.computername}
Write-Host Atualmente as VMs que não tem compatibilidade de processador para Migracoes sao: $a
foreach ($c in $a)
{stop-vm –computername $b -vmname $c}
foreach ($d in $a)
{Get-VM –computername $b -vmname $d | Set-VMProcessor -CompatibilityForMigrationEnabled 1}
foreach ($e in $a)
{start-vm -computername $b -vmname $e}

Para o comando acima, o ideal seria salvar como .ps1. Alguns erros podem aparecer, pois o script não testa se a vm está em um nó especifico. Esses erros não atrapalham o resultado.

Para verificar a versão do Integration Services das VMs dos hosts do cluster:
Get-ClusterNode | foreach ($_.name) {get-vm -computername $_.name | ft name, integrationservicesversion}

Para verificar as VMs que estão com uma isso montada em todos os hosts do cluster:
Get-ClusterNode | foreach ($_.name) {get-vm -computername $_.name | Get-VMDvdDrive | where path -ne $null | select VMName, path} | foreach ($_.vmname) {$_.vmname}

Para remover a iso montada das VMS em um cluster:
Get-ClusterNode | foreach ($_.name) {get-vm -computername $_.name | Get-VMDvdDrive | where path -ne $null | Set-VMDvdDrive -Path $null} | foreach ($_.vmname) {$_.vmname}

Até a próxima!!

Adicionando um Domain Controller com Windows Server 2012 em uma Floresta existente com PowerShell

Nesse post será mostrado adicionar um servidor com Windows Server 2012 como Domain Controller (DC) em uma Floresta já existente utilizando somente comandos em PowerShell e após fazer a transferência das regras FSMO.

O primeiro passo é logar em um DC e fazer pequenas verificações:
Para verificar informações sobre a floresta:
Get-adforest
Uma dica, para verificar os domínio em uma mesma floresta basta usar os seguintes comandos:
$forest = get-adforest
$forest.domains
Para verificar informações do domínio:
Get-Addomain

O segundo passo é logar no servidor com Windows Server 2012 e que será promovido a DC e adicionar a role de AD DS:
Para Adicionar a Feature de AD DS:
Install-WindowsFeature -name “ad-domain-services” -IncludeAllSubFeature –IncludeManagementTools

Após vamos ingressar no domínio contoso.com:
Install-addsdomaincontroller –installdns –domainname “contoso.com” –credential (get-credential contoso\administrator)
Neste momento deverá ser inserida a senha do usuário administrator do domínio. Após será questionada a senha do DSRM.
Uma vez instalada essa role, o servidor também irá reiniciar.
 
Para verificar onde estão as regras FSMO podemos digitar:
Netdom query fsmo

Para mover as regras FSMO basta digitar:
Move-ADDirectoryServerOperationMasterRole -Identity “SERVIDOR DESTINO” -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator
Caso fosse necessário fazer um seizing das FSMO o comando seria praticamente o mesmo:
Move-ADDirectoryServerOperationMasterRole -Identity “SERVIDOR DESTINO” -OperationMasterRole SchemaMaster, RIDMaster, InfrastructureMaster, DomainNamingMaster, PDCEmulator -force

Até a próxima!!

Gerenciando VMs no Hyper-V com PowerShell

Outro grande avanço do Windows Server 2012 foi trazer nativamente comandos PowerShell para o Hyper-V. No Windows Server 2008 R2 é possível gerenciar o servidor através de um módulo baixado do Codeplex: http://pshyperv.codeplex.com/

Neste post será mostrado como fazer o gerenciamento básico de uma VM em um servidor com Hyper-V (Windows Server 2012):

Para verificar informações básicas do host como memória e processadores lógicos basta digitar no PowerShell:
Get-vmhost
Para ver informações mais detalhadas:
get-vmhost | fl
Para verificar se já existem VMs rodando no host:
Get-VM
Bom, o primeiro passo é verificar os adaptadores de rede para criar os switches virtuais.
Para verificar os adaptadores presentes no host digitar:
Get-NetAdapter
Para verificar se existe algum Virtual Switch criado, basta digitar:
Get-VMSwitch
Definido o adaptador e o tipo de switch virtual, basta criar com o comando a seguir: (Será criado um Switch chamado Public_Network utilizando a placa de rede chamada Ethernet, onde estará habilitado o gerenciamento do host e será do tipo externo):
New-VMSwitch –Name “Public_Network” –NetAdapterName “Ethernet” –AllowManagementOS $true
Para criar um switch virtual privado chamado VMSwPr1 poderia ser usado o seguinte comando:
New-VMSwitch –Name “VMSwPr1” –switchtype Private
Para criar uma VM nova o comando simples é:
New-VM
Com o comando acima será criada uma VM nova, com 512 MB de memória fixa, um processador virtual, sem um VHDx atribuído utilizando as pastas padrões do Hyper-V. Seu nome será New Virtual Machine Para saber a pasta padrão onde está sendo criada a VM basta digitar:
Get-VMHost | select VirtualMachinePath, VirtualHardDiskPath
Se foi utilizado o comando acima para criar a VM, para visualizar as configurações basta digitar:
Get-vm -Name new* | fl *
Se a ideia é criar uma VM do zero com configurações específicas e em pastas específicas vamos usar o mesmo comando, só que com parâmetros:
New-VM -Name VMT01 -MemoryStartupBytes 1GB -Path d:\vms –NewVHDPath d:\vms\VMT01\VMT01.vhdx -NewVHDSizeBytes 60GB -SwitchName Public_Network
Com o comando acima foi Criada uma nova VM chamada VMT01, com 1 processador virtual (padrão) e memória fixa de 1 GB. Ainda foi configurado um Adaptador de Rede utilizando o Virtual Switch Public_Network. Foi criado um VHDx novo de 60 GB (mas é dinâmico – até 60 GB) na pasta D:\VMs\VMT01\ chamado VMT01 e o caminho da VM foi colocado como D:\VMs. (A VM cria uma pasta com o próprio nome. Quando a VM é criada seu status é desligada.
Nesse momento é interessante verificar o status dessa nova VM criada:
Get-Vm -Name VMT01 | fl *
Criada a VM ainda existem alguns comandos interessantes. Para essa VM, antes de iniciar, vamos fazer as seguintes alterações:
Mudar de 1 processador virtual para 2:
Get-VM VMT01 | Set-VMProcessor -count 2
Mudar de 1 GB de Memória Fixa para memória dinâmica entre 512 MB e 2 GB sendo 1 GB de inicialização;
Get-VM VMT01 | Set-VMmemory –DynamicMemoryEnabled $true –MaximumBytes 2GB –MinimumBytes 512MB –StartupBytes 1GB
Adicionar a ISO do Windows Server 2012 para a instalação do Windows;
Set-VMDvdDrive -vmname VMT01 -Path ‘D:\ISO\Windows Server 2012\Windows_Server_2012_Datacenter_VL.ISO’
Uma vez feita as alterações a VM está pronta para ser inicializada:
Get-VM VMT01 | Start-VM
Pronto a VM está rodando, pronta para ser utilizada.
Agora vamos supor que nós vamos criar mais um VHDx, chamado VMT01_D2 de 20 GB dinâmico na mesma pasta:
New-VHD -path d:\vms\VMT01\VMT01_D2.vhdx -SizeBytes 20GB
Sò que o VHDx criado acima deveria ser fixo. Para transformar de dinâmico para Fixo podemos usar:
Convert-VHD -path d:\vms\VMT01\VMT01_D2.vhdx –DestinationPath “d:\vms\VMT01\VMT01_D3.vhdx” –VHDtype Fixed
E que tal adicionar esse VHDx na VM criada com ela ligada:
Add-VMHardDiskDrive –Vmname VMT01 –ControllerType SCSI –ControllerNumber 0 –Path d:\vms\VMT01\VMT01_D3.vhdx
Para finalizar os comandos básicos:
Desligar a VM:
Get-VM VMT01 | Stop-VM
Para Suspender a VM:
Get-VM VMT01 | Suspend-VM
Reinicia a VM com Shutdown do SO:
Get-VM VMT01 | Restart-VM
Para Verificar os Snapshots da VM:
Get-VM VMT01 | Get-VMSnapshot
Para criar um Snapshot da VM:
Get-VM VMT01 | Checkpoint-VM
Para renomear um Snapshot:
Get-VM VMT01 | Rename-VMSnapshot –name “VMT01 – (6/18/2013 – 4:39:44 PM)” –newname SNAP1
Para voltar o Snapshot de uma VM:
Get-VM VMT01 | Restore-VMSnapshot –name SNAP1
Para Deletar um Snapshot:
Get-VM VMT01 | Remove-VMSnapshot –name SNAP1
Todos os comando podem ser encontrados em:
http://technet.microsoft.com/en-us/library/hh848559(v=wps.620).aspx

Espero que este post possa ser útil no gerenciamento do seu ambiente Hyper-V 3.0.

Até a próxima!!!