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-PropertyName
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:
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:
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 é:
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|Wherepartitionstyle-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:
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.
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:
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 é:
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.
Após Adicionar a ISO para instalarmos o Sistema Operacional, podemos ver com está a ordem do Boot, usando o comando Get-VMFirmware:
(Get-VMFirmwarevmad01-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:
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-NameVMAD01-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.
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.
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.
O primeiro ponto é vermos todas as políticas da imagem acima no PowerShell.
Política no Portal
Política no PowerShell
Meeting Policy
TeamsMeetingPolicy
Messaging policy
TeamsMessagingPolicy
Live events policy
TeamsMeetingBroadcastPolicy
App permission policy
TeamsAppPermissionPolicy
App setup policy
TeamsAppSetupPolicy
Call park policy
TeamsCallParkPolicy
Calling policy
TeamsCallingPolicy
Caller ID policy
CallingLineIdentity
Teams policy
TeamsChannelsPolicy
Emergency calling policy
TeamsEmergencyCallingPolicy
Emergency call routing policy
TeamsEmergencyCallRoutingPolicy
Dial plan
TenantDialPlan
Voice routing policy
OnlineVoiceRoutingPolicy
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:
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)
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.
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.
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:
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):
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):
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.
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á:
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.
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.
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
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}
Quando encontrar será preciso criar uma nova string chamada VlanId e colocar o número da Vlan:
Após podemos verificar no powershell: Get-NetAdapter | ft Name, Status, Linkspeed, VlanID
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.
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:
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.
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.
Após será pedido para reiniciar o servidor.
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.
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 …
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
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
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
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
1
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
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.
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”
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”
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.
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.
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}
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
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.
Sem dúvida a melhor forma de se monitorar uma infraestrutura de TI é utilizando o System Center Operations Manager (SCOM). Agora, caso não exista um SCOM em seu ambiente ou ele ainda está em implantação e serviços precisam ser monitorados, isso pode ser feito via PowerShell (PS).
Neste post vai ser mostrado como verificar o status de serviços em um servidor local e em servidores remotos de uma forma simples. Também será mostrado como podem ser feitos scripts um pouco mais elaborados para essas tarefas.
Em um host local para verificar os serviços que estão rodando basta digitar: Get-Service
Esse comando padrão traz o status do serviço (se está rodando ou não) o nome do serviço e o nome que aparece no Windows de forma amigável.
Em um host para verificar os serviços que estão parados: Get-Service | where status -eq “stopped”
Em um host para verificar os serviços que estão rodando: Get-Service | where status -eq “running”
Para poder verificar todos os serviços no servidor remoto (chamado SCVMM2012) precisamos do seguinte comando via PS: Get-Service –Computername scvmm2012
O próximo comando é utilizado para verificar os serviços que começam com CM: Get-Service cm* -ComputerName scvmm2012
Para verificar se os serviços em que o nome começa por “cm” estão rodando no servidor remoto: Get-Service cm* -ComputerName scvmm2012 | Where-Object {$_.status -eq “running”}
Se a ideia é verificar um mesmo serviço em dois servidores diferentes pode ser usado o seguinte comando: $srv = “scvmm2012”, “scom2012” Get-Service –Name spooler –Computername $srv
O comando acima vai verificar o status do serviço Spooler nos servidores SCVMM01 e SCOM01.
No caso acima vemos duas vezes o serviço rodando, mas não sabemos em qual está. Se em um estivesse parado iria ser interessante saber em qual dos dois. Para essa situação podemos usar: $srv = “scvmm2012”, “scom2012” Get-Service –Name spooler –Computername $srv | format-table –property machinename, status, displayname – auto
Para melhorar um pouquinho mais o detalhamento da saída poderia ser usado ainda: $srv = “scvmm2012”, “scom2012” Get-Service –Name spooler –Computername $srv | format-table –property machinename, status, name, displayname – auto
Se a intenção é verificar o serviço de vários servidores uma opção interessante é criar um documento txt com o nome dos servidores, isso facilitaria o trabalho.
O exemplo abaixo mostra um arquivo chamado servers.txt dentro da pasta c:\ps.
Os nomes dos servidores devem estar um em cada linha. $server = get-content c:\ps\servers.txt Get-Service –name Spooler –computername $server | format-table –property machinename, status, name, displayname – auto
Uma coisa que pode acontecer é um servidor ser inicializado e algum serviço, que deveria iniciar automaticamente não inicia. Para ver os serviços que devem iniciar de forma automática (no próprio servidor): Get-WmiObject -Class Win32_Service | where startmode -eq “auto”
O comando acima vai dar um monte de informações. É possível diminuir a quantidade de informações: Get-WmiObject -Class Win32_Service | where startmode -eq “auto” | Format-Wide -Property Name -Column 1
O comando interessante seria ver os serviços que deveriam iniciar automaticamente e estão parados. Para isso usamos o comando: Get-WmiObject -Class Win32_Service | where startmode -eq “auto” | where state -eq “stopped”
Para verificar o status de um serviço específico usamos o seguinte comando: Get-WmiObject -Class Win32_Service | where name –eq skypeupdate
Para iniciar um serviço que esteja parado podemos usar o comando: Get-WmiObject -Class Win32_Service | where name -eq skypeupdate | start-service
Obviamente para parar um serviço que esteja rodado podemos usar o mesmo comando, apenas mudando o final: Get-WmiObject -Class Win32_Service | where name -eq skypeupdate | stop-service
Para iniciar todos os serviços que deveriam iniciar automaticamente e estão parados usamos o seguinte comando: Get-WmiObject -Class Win32_Service | where startmode -eq “auto” | where state -eq “stopped” | start-service
Pensando em vários servidores é possível criar um comando que verifica de uma vez vários serviços em vários servidores. Para esse exemplo usaremos os servidores SCVMM2012 e SCOM2012 e verificaremos o serviço MSSQLSERVER, presente em ambos, e o serviço SCVMMSERVICE presente apenas no servidor SCVMM2012 e o serviço OMSDK presente apenas no servidor SCOM2012: $srv = “scvmm2012”, “scom2012” $services = “scvmmservice”, “omsdk”, “mssqlserver” Get-Service –name $services –computername $srv| format-table –property machinename, status, name, displayname
Para o mesmo exemplo acima, adicionando o serviço de Remote Access, que está parado em ambos servidores: $srv = “scvmm2012”, “scom2012” $services = “scvmmservice”, “omsdk”, “mssqlserver”, “remoteaccess” Get-Service –name $services –computername $srv| format-table –property machinename, status, name, displayname
Agora vamos fazer o seguinte, vamos monitorar os serviços acima, só que vamos mudar o serviço de Remote Access para o serviço de Audio do Windows. O serviço de áudio também está parado nos dois servidores. O próximo comando vai verificar os quatro serviços nos dois servidores e iniciar se algum estiver parado (no caso o serviço de áudio estará parado em ambos: $srv = “scvmm2012”, “scom2012” $services = “scvmmservice”, “omsdk”, “mssqlserver”, “audiosrv” Get-Service –name $services –computername $srv| format-table –property machinename, status, name, displayname Get-Service –name $services –computername $srv| start-service Get-Service –name $services –computername $srv| format-table –property machinename, status, name, displayname
O script acima vai mostrar o status dos serviços e após irá iniciar os que estiverem parados e, novamente, irá mostrar o status.
Como fazer essas operações de forma remota fora do domínio no servidor VMM01: $cred = get-credential Invoke-Command -ComputerName vmm01 -ScriptBlock {get-service } -credential $cred
Quando o commando $cred = get-credential é digitado, vai abrir uma janela pedindo que seja digitado o usuário e a senha. Para que o usuário seja completado pode ser usado $cred = get-credential contoso\administrator
Que tal criar um script em PowerShell de uma forma um pouco mais elaborada?
Qualquer um dos comandos acima pode ser salvo em um arquivo .ps1 para ser rodado todo de uma vez só. Quando é feito um script podemos aprimorar algumas coisas. Copiar os scripts abaixo e salvar em um arquivo.ps1.
O script abaixo vai verificar os serviços no localhost: $servers = “localhost” foreach ($i in $servers) {write-host “Verificando Serviços no Servidor” $i Get-wmiobject -computername $servers -class win32_service | Select-Object -property name, state, startmode, startname | sort-object -property startmode, state, name | Format-table *}
O mesmo script verificando os serviços nos servidores SCVMM2012 e SCOM2012: $servers = “scvmm2012”, “scom2012” foreach ($i in $servers) {write-host “Verificando Serviços no Servidor” $i Get-wmiobject -computername $servers -class win32_service | Select-Object -property name, state, startmode, startname | sort-object -property startmode, state, name | Format-table *}
O script acima não pede credenciais, então deve ser rodado no mesmo domínio.
Que tal um script onde é perguntado o nome do servidor onde verificar o status dos serviços e ainda verifica as credenciais: $ComputerName = Read-Host “Digite o Nome do Servidor” $UserName = Read-Host “Digite o Usuario” $Password = Read-Host -AsSecureString “Digite a Senha” $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $UserName , $Password $Service = Get-WmiObject -Class Win32_Service -ComputerName $ComputerName -Credential $Credential $Service
E agora é dado duas opções de servidores para se escolher:
Write-Host Bem Vindo ao verificador de Serviços. Servidor VMM01 é opção 1. Servidor OM01 é opção 2. $ComputerName = Read-Host “Digite a opcao” if ($ComputerName -eq 1) { $comp = “vmm01” } elseif ($ComputerName -eq 2) { $comp = “om01” } else { Write-Host “Opção inválida”; exit } $UserName = Read-Host “Enter User Name” $Password = Read-Host -AsSecureString “Enter Your Password:” $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $UserName , $Password $Service = Get-WmiObject -Class Win32_Service -ComputerName $Comp -Credential $Credential $Service
Para finalizar, um script que pergunta o nome do host e o tipo de verificação:
Write-Host Bem Vindo ao verificador de Serviços. $Comp = Read-Host “Digite o nome do Servidor” Write-Host Tipos de verificação: Write-Host 1 – Para verificar o status de todos os serviços; Write-Host 2 – Para verificar os serviços que estão rodando; Write-Host 3 – Para verificar os serviços que estão parados; Write-Host 4 – Para verificar os serviços que estão parados e tem inicialização automática; Write-Host 5 – Para digitar o nome do serviço a ser verificado; $vertype = Read-Host “Digite o tipo de verificação” $UserName = Read-Host “Enter User Name” $Password = Read-Host -AsSecureString “Enter Your Password” $Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $UserName , $Password if ($vertype -eq 1) { $Service = Get-WmiObject -Class Win32_Service -ComputerName $Comp -Credential $Credential $Service } elseif ($vertype -eq 2) { $Service = Get-WmiObject -Class Win32_Service -ComputerName $Comp -Credential $Credential $Service | where state -eq “running” | format-table -property name, state } elseif ($vertype -eq 3) { $Service = Get-WmiObject -Class Win32_Service -ComputerName $Comp -Credential $Credential $Service | where state -eq “stopped” | format-table -property name, state } elseif ($vertype -eq 4) { $Service = Get-WmiObject -Class Win32_Service -ComputerName $Comp -Credential $Credential $Service | where startmode -eq “auto” | where state -eq “stopped” | format-table -property name, state } elseif ($vertype -eq 5) { $Service = Read-Host “Digite o nome do Serviço” $Service2 = Get-WmiObject -Class Win32_Service -ComputerName $Comp -Credential $Credential | where name -eq $service $service2 } else { Write-Host “Opção inválida”; exit }
Antes que alguém fale, eu sei que, no script acima, a verificação da opções deveria vir antes de digitar o usuário e senha.
Depois de todos esses scripts podemos ver como é possível combinar os scripts e criar visualizações diferentes.
Espero que esses scripts possam ser úteis!!!
Resource Metering é uma das novas features do Windows Server 2012. Sua função é monitorar máquinas virtuais (VMs) quanto ao uso de CPU, Memória, espaço em disco e rede.
Sete métricas podem ser coletadas por este recurso:
• Uso médio de CPU por uma VM;
• Uso médio de Memória por uma VM;
• Mínimo de Memória usada por uma VM;
• Máximo de Memória usada por uma VM;
• Máximo de espaço em disco alocado para uma VM;
• Tráfego total de entrada por um adaptador de rede virtual;
• Tráfego total de saída por um adaptador de rede virtual;
Para habilitar o Resource Metering em uma VM (neste caso chamada FTP01) basta digitar no host Hyper-V dessa VM:
Enable-VMResourcemetering –VMName FTP01
Quando este comando é dado para uma VM os contadores começam a rodar. Para mostrar o resultado, basta rodar o seguinte comando:
Measure-VM –Vmname FTP01ou ainda Measure-VM –Vmname FTP01 | fl
Para demonstrar o tráfego de entrada copiei um arquivo para dentro da VM, pela imagem abaixo é possível ver o tráfego (em magabytes) aumentando.
É interessante dizer que as estatísticas perduram mesmo que a VM seja reiniciada ou desligada. Mesmo se ocorrer um Live Migration ou Storage Migration as estatiscas não são perdidas.
Para resetar as estatísticas deve ser usado o comando: Reset-VMResourceMetering –VMName FTP01
Para parar a coleta de estatísticas basta dar o comando: Disable-VMResourcemetering –VMName FTP01
Outra coisa interessante é rodar este comando de um servidor remoto. Do servidor B09 para pegar as estatíscas da VM FTP01 no servidor B10 basta digitar: Measure-VM –Computername B10 –vmname FTP01
Para saber, dentro de um host Hyper-V, quais VMs estão com os contadores ativados, basta dar o seguinte comando: Get-VM | format-list name,resourcemeteringenabled
Para salvar as estatísticas da VM FTP01 em um arquivo CSV podemos usar os seguintes comandos: $repVM = get-vm ftp01 | measure-vm $repVM | Export-Csv -NoTypeInformation -Path c:\reports\report-ftp01.csv
Para finalizar, também é possível criar um pool de monitoramento juntando várias VMs.
Para ver as estatísticas de uso de memórias de duas VMs devemos fazer o seguinte:
Get-VMResourcePool– Este comando vai mostrar os pools disponíveis. New-VMResourcePool –Name MemoryPool1 –ResourcePoolType Memory – Este comando vai criar um novo pool de memória chamado MemoryPool1. Get-VM -name FTP01,TST_01 | Stop-VM – Este comando vai desligar as VMs FTP01 e TST_01 que servirão para mostrar o uso do pool. Elas precisam estar desligadas para o próximo comando. Set-VMMemory -VMName FTP01,TST_01 – ResourcePoolName MemoryPool1– Seta as duas VMs para usarem o Pool MemoryPool1, recém criado. Enable-VMResourcemetering -VMName FTP01,TST_01 – Habilita a coleta de estatísticas das duas VMs. Get-VM -name FTP01,TST_01 | Start-VM – inicia as VMs. Measure-VMResourcePool –Name MemoryPool1 – Mostra as estatísticas, neste caso de memória e das duas VMs.
Esses comandos podem ser conferidos na figura abaixo:
Gerenciando infraestrutura de TI 