ADM de Redes

Um Blog sobre o dia a dia do Administrator de Redes e Servidores Microsoft

May
17

By

Virtualização com Windows Server 2012 Standard.

Category: Hyper-V, Licenciamento, Virtualização, Windows Server 6 Comments

Olá Pessoal,

Fechando nossa série de dúvidas de licenciamento com Windows Server 2012, queria colocar um outro ponto que causa uma certa confusão. Como dito em posts anteriores, a licença do Windows Server 2012 Standard licencia 2 processadores e possui o direito de execução de 2 Máquinas Virtuais com Windows Server 2012 Standard.

A forma como isto está descrito no PUR (Product User Rights) é, mais ou menos, da seguinte forma:

- Você deve associar cada licença a um único servidor.
- Uma licença é necessária para cada 2 processadores no servidor.
- Para licenças Standard, você pode utilizar uma licença ativa no OSE (Operating System Environment, ou seja, ambiente de SO) Físico, e para cada licença associada, até 2 OSE Virtuais rodando a licença de servidor.

Há ainda alguns outros pontos, mas para o nosso caso, queria destacar esse último parágrafo. Veja que você pode ter, com uma licença de Windows Server 2012 Standard, 3 instalações do mesmo, sendo uma na máquina física e duas em VMs executadas neste Host.

Há ainda outro ponto muito importante, que diz o seguinte:

- Se as duas licenças de OSE Virtuais estiverem utilizadas, a instalação do OSE físico é permitido apenas para funções de virtualização de Máquinas Virtuais.

Esse último ponto pode gerar muita discussão, e a idéia deste post é esclarecer exatamente isso. No cenário onde você tem apenas uma licença de Windows Server 2012 Standard e está executando as duas licenças em Máquinas Virtuais, o Host pode receber a instalação do Windows Server 2012 Standard também, porém, apenas para fins de Virtualização. Isso significa que você não pode destinar esse Host para ser um File Server, por exemplo, ou um Domain Controller, assim como qualquer outra aplicação que irá atender aos usuários da empresa.

Neste momento, você pode estar pensando. Mas e se eu tiver uma aplicação que apenas monitora o ambiente de Virtualização, ou até mesmo, uma aplicação para Backup do Host e das Máquinas Virtuais em execução? Neste caso, e apenas para estes casos, você pode instalar estas aplicações. Veja, se a aplicação que você vai instalar no Host, serve para o propósito de monitoração ou backup do ambiente de Virtualização, então ela não fere os direitos de utilização desta licença no Host e das Máquinas Virtuais que você tem direito.

Espero que esta dica tenha ajudado!
Até mais!

May
15

By

Reassociação de Licenças do Windows Server 2012

Category: Hyper-V, Licenciamento, Virtualização, Windows Server 1 Comment

Olá Pessoal,

Como licenciamento tem se mostrado um assunto quente, estou entrando em maiores detalhes em alguns casos que merecem mais atenção. Hoje, vamos falar mais sobre Reassociação de Licenças do Windows Server 2012. De fato, a maioria dos softwares Microsoft podem ser reassociados, mas isso varia de software para software e em casos de Licenças como CAL e External Access, há ainda alguns detalhes para serem seguidos. Aqui vamos discutir alguns cenários de utilização do Windows Server 2012 e principalmente com Virtualização.

Antes de entrarmos na questão da reassociação de licenças, vale a pena lembrar que as licenças de Windows Server 2012, tanto Standard como Datacenter, devem ser associadas a um Host de acordo com o número de Processadores do mesmo. Cada licença, tanto Standard como Datacenter, licenciam 2 processadores físicos, mas a versão Standard tem direito de Virtualização de 2 VMs e a Datacenter, ilimitadas VMs.

A reassociação de Licenças, como disse, é possível. Isso significa que uma licença atrelada a um Host e seus processadores pode ser repassada para outro servidor. Porém, algumas regras devem ser obedecidas.

Para ficar mais fácil o entendimento, veja a imagem abaixo:

Redesignacao

Na imagem acima, o Host 01 possui o Hyper-V Server instalado e tem 2 licenças do Windows Server 2012 Standard associadas. Além disso, o Host 01 tem 4 processadores. O host 02 por sua vez não tem SO instalado. Este cenário está perfeitamente licenciado. Veja agora, os seguintes cenários:

- Se instalarmos o Windows Server 2012 no Host 02, que tem 2 processadores, precisamos de no mínimo mais uma licença de Windows Server 2012 Standard associada ao Host 02.

- Se instalarmos o Hyper-V Server 2012 no Host 02, ele não tem direitos de virtualização. Para que possamos colocar qualquer VM com Windows Server instalado, uma licença de Windows Server deve ser associada a este host, mas enquanto uma VM com Windows Server não é criada, o cenário está licenciado corretamente também.

- Caso seja instalado o Hyper-V Server 2012 no Host 02, podemos reassociar a(s) licença(s) de Windows Server 2012 Standard para este Host para que as VMs sejam movidas para o mesmo.

Este último ponto é o mais importante aqui. Quando reassociamos uma licença de Windows Server de um servidor para outro, o processo de reassociação desta licença não pode ser feito novamente dentro de 90 dias. Isso significa que você não pode ficar movendo a licença de um lado para outro a qualquer momento. Veja, se o Host 01 e 02 possuem licenças para hospedar todas as VMs, ou seja, existem 4 licenças de Windows Server 2012 Santandard, 2 para cada Host, o processo de movimentação das VMs pode ser feito sem nenhum problema. A licença de execução de uma VM com Windows Server é uma coisa, a VM em si é outra.

Para o cenário acima onde a VM vai ser movida de uma lado para o outro a qualquer momento, o correto é ter 2 licenças Windows Server 2012 Standard para cada Host, ou seja, 4 licenças de Windows Server 2012 Standard.

Eu mencionei também, que o Host 02 tem apenas 2 processadores e que cada licença cobre 2 processadores, certo? Isso significa que apenas uma licença atende neste caso? Não, pois neste caso, temos 4 VMs com Windows Server. Com isso, se faz necessário o número de licenças para todas as VMs, sendo ignorado o número de processadores menor.

Existe porém, um caso onde a movimentação de licenças do Windows Server é permitida mesmo que antes dos 90 dias padrão. Veja na imagem abaixo:

Redesignacao01

Na imagem acima, o Host 01 tem 2 licenças de Windows Server 2012 Standard associadas a ele e o Host 02 não tem nenhuma licença associada. Ambos tem o Hyper-V Server 2012 instalado. Porém, o Host 01 apresentou uma falha de hardware permanente e não será mais colocado de volta em funcionamento. Neste caso as VMs de 01 a 04 serão movidas para o Host 02. Para este caso, a movimentação de licenças é permitida mesmo que o período de 90 dias da última movimentação não esteja completo. Veja que o Host 01 será aposentado, ou seja, não será ligado novamente devido a esta falha de hardware. Qualquer outra situação, como conserto de hardware, deve obedecer ao período de 90 dias.

Espero que mais esta dica tenha ajudado!
Até mais!

May
14

By

Licenciamento de Hyper-V Replica com Software Assurance

Category: Hyper-V, Licenciamento, Virtualização, Windows Server 4 Comments

Olá Pessoal,

Licenciamento sempre é assunto que chama a atenção. Vide este post que fiz explicando o licenciamento do Windows Server 2012 que teve diversos comentários. E algumas situações acabam sendo tão específicas que merecem um post a parte. É o caso do Hyper-V Replica.

O Hyper-V Replica é um recurso do Hyper-V 3.0 presente no Windows Server 2012 e no Hyper-V Server 2012. Com ele você pode ter uma replica de determinada VM em outro servidor. A ideia do Hyper-V Replica é que você possa fazer o failover desta VM caso o host original seja comprometido. Com o Hyper-V Replica, você pode ter uma solução de Site Disaster Recovery com custo zero. É preciso, porém, tomar cuidado com o licenciamento destas VMs.

No caso do Hyper-V Replica, a VM original está em funcionamento e precisa sar licenciada. A VM de destino, apesar de desligada, está operante e também precisa ser licenciada. Veja o caso abaixo:

Veja a imagem abaixo:

Replica01

O Host 01 no Site A tem 4 VMs. Se você licenciar o Host 01 com a Edição Standard, você irá precisar de 2 licenças pois cada licença dá direito a 2 VMs licenciadas. Veja que este servidor não pode ter mais do que 4 processadores físicos também, pois tanto Standard como Datacenter cobrem 2 processadores, com cada licença. Porém, a versão Datacenter licencia ilimitadas VMs.

Veja que a mesma situação é aplicada no Host 02 do Site B. As VMs que estão neste Host são replicas das VMs do Host 01 no Site A e precisam ser licenciadas. É aqui que entra em ação um dos benefícios do Software Assurance. Se você tem um contrato válido com a Microsoft com Software Assurance em vigência, as VMs do Host 02 no site B não precisam de licenciamento. Quando uma falha ocorrer no site A, você pode ligar as VMs no Site B e transferir a Licença que estava vinculada ao Host 01 ao Host 02.

Veja que algumas condições devem ser atendidas:

- As VMs no site de Replica devem ficar desligadas todo o tempo, a não ser para Testes. Segundo o Product User Rights, você poderia ligar estas VMs de Disaster Recovery apenas para Patch, Testes ou Disaster Recovery, mas Patch não vem ao caso pois toda a configuração está sendo replicada automaticamente.

- Se o Host 01 fizer parte de um Cluster e estas VMs estiverem com Alta Disponibilidade, as VMs replica não podem fazer parte do mesmo cluster, ou seja, o Host 02 não pode fazer parte do mesmo cluster que o Host 01. Ele pode ser uma servidor Node de outro Cluster. Poderiamos também ter o inverso. O Host 01 ser um host standalone e o Host 02 fazer parte de um cluster, mas de qualquer forma, as VMs não poderiam estar no mesmo cluster.

- Este benefício termina no momento que seu contrato com Software Assurance também termina. Para continuar com este benefício o Software Assurance deve ser renovado.

Bom, espero que esta dica tenha ajudado pessoal. Se tiver alguma dúvida, fique a vontade para discutirmos nos comentários.
Até mais!

May
6

By

Alta Disponibilidade de Serviços de Impressão no WS2012

Category: Cluster, Hyper-V, Virtualização, Windows Server 2 Comments

Olá Pessoal,

Se você está acostumado a projetos de cluster, provavelmente, você já se deparou com um projeto de cluster de servidores de impressão. Até o Windows Server 2008 R2, este era um assunto um tanto quanto delicado.

Delicado pois para se ter um cluster de impressão até o Windows Server 2008 R2, você deveria montar um cluster “padrão” e adicionar o serviço de impressão como uma “Role” do cluster. Por funcionar como uma “Role” do cluster, muitas impressoras tinham incompatibilidade de drivers, o gerenciamento não era tradicional como uma impressora instalada normalmente, além de alguns processos requererem scripts que normalmente não eram fáceis de se desenvolver.

Enfim, gerenciar um cluster de impressão era um processo, como disse, um tanto delicado. Isso mudou drasticamente no Windows Server 2012. A primeira mudançca que alguém irá perceber é o fato de o serviço de impressão não estar mais disponível como uma “Role”:

image

Bom, não se desespere. Há um motivo para o serviço de impressão não estar disponível aqui. Na verdade, houve uma mudança de conceitos no Windows Server 2012.

No Windows Server 2012, se você quiser um serviço de impressão com Alta Disponibilidade, você deverá criar uma Máquina Virtual com Alta Disponibilidade e nesta Máquina Virtual você irá configurar o serviço de impressão normalmente, como faria em um servidor de impressão qualquer.

Por que isso? Bom, como dito acima, configurar um serviço de impressão em Alta Disponibilidade, pode gerar mais confusão do que resolver problemas. Com isso, este novo modelo se mostra muito mais flexível. Com a VM com alta disponibilidade, fica fácil de gerenciar o serviço de impressão, não há problemas de incompatibilidade de drivers, e etc.

Basicamente, com este novo modelo, você terá um servidor de impressão como qualquer outro. E no caso de falha de um dos nós do seu cluster, a VM será ligada em outro nó, retornando o serviço de impressão ao estado normal.

Isso fica ainda mais interessante quando combinamos esse novo modelo com um novo recurso do Windows Server 2012. O recurso de VM Monitoring, ou Monitoração de VM. Este recurso permite que o cluster verifique os serviços desejados nas VMs e tome uma ação caso o serviço não esteja em seu funcionamento padrão. Em uma VM que é servidor de impressão, você teria algo como o abaixo:

image

Com este recurso configurado, caso os nós estejam funcionando, mas o serviço de impressão dentro da VM apresente uma falha, o próprio serviço de cluster poderá tentar remediar a VM. Primeiramente, por padrão, ele tentará reiniciar a VM. Isso, no caso de um serviço de impressão poderá resolver o problema. Mas se o problema persistir, o serviço de cluster fará o Live Migration desta VM para outro nó, imaginando que se for algum problema de hardware, este será resolvido. Com isso, muito provavelmente o problema será resolvido. Mesmo assim, se o problema não for resolvido, a VM ficará indicada como “Application in VM State Critical”.

Espero que vocês tenham gostado das novidades e que de agora em diante fique mais fácil criar seus cluster de Servidores de Impressão.
Até mais!

Mar
25

By

MVP Virtual Conference

Category: Eventos Leave a Comment

image

Olá Pessoal,

Começa amanhã o MVP Virtual Conference. Serão uma série de webcasts sobre diversos assuntos. Recomendo fortemente que você acesse o site do evento para saber mais informações e se cadastrar. O site do evento é: http://mvpvirtualconference.azurewebsites.net/.

Na quinta-feira, eu farei uma sessão sobre Nuvem Hibrida com System Center 2012 SP1. Não perca a oportunicade de conhecer essas tecnologias e engajar com profissionais de primeira linha.

Até mais!

Mar
22

By

Geo Cluster ou Hyper-V Replica?

Category: Cluster, Hyper-V, Virtualização, Windows Server 1 Comment

Olá Pessoal,

Recentemente, me deparei com uma situação onde era necessário escolher a melhor opção de Disponibilidade e Recuperação de Desastre em um projeto. O parceiro que estava no projeto com o cliente levantou as necessidades e minha parte foi basicamente explicar as diferentes soluções que poderiam atender este caso. Gostaria de compartilhar com vocês as soluções e quais os benefícios de cada uma das opções.

Desde o Windows Server 2008, a Microsoft facilitou muito a configuração de um Cluster Geográfico. A opção de se ter um File Share Witness é um dos exemplos disso. Antes de mais nada, vamos entender o que é um Geo Cluster:

Um Cluster Geográfico é um cluster onde os nós deste cluster estão em sites diferentes da empresa. Imagine que você tem um Cluster chamado Cluster 01 e este cluster tem 2 nós. Um dos nós poderia estar em uma localidade e o outro nó estaria em outra. Não vou entrar em detalhes de links, mas é importante que os nós estejam sempre se comunicando. Por ser o mesmo cluster, os recursos que são criados no Cluster, como VMs, poderão iniciar em qualquer um dos nós. É aí que vem a primeira vantagem de um cluster geográfico. Caso um dos nós pare de funcionar, a VM que estava neste local, poderá iniciar em uma outa localidade. E o mais importante, este processo de HA será operado pelo cluster automaticamente. Este processo automatico é o que muitos entendem como grande benefício. Porém, alguns pontos devem ser observados e muitas vezes, estes pontos impossibilitam um projeto como este. Vamos lá:

Para que um cluster funcione, um armazenamento compartilhado é necessário. No caso de um Geo Cluster, isso também é verdade, mas em cada localidade os Hosts irão ter seu storages, logo, estamos falando de 2 Storages. Além disso, os storages devem estar atualizados em relaão um ao outro. O Windows Server não irá fazer este processo. Isso é um serviço que deve ser adquirido com o fabricante do storage (ou uma consultoria que faz este trabalho). Além disso, o File Share Witness é um ponto importante no processo. Isso por que é ele quem irá garantir que apenas seja feito HA caso o Nó de um dos sites realmente esteja off-line. Para que o caso de uma queda de links não impacte o processo de HA, o File Share Witness deve estar em uma terceira localidade. Então além dos 2 sites onde os nós do cluster estão, o File Share Witness devem estar em uma terceira localidade, terceiro site.

Enfim, a não ser que o processo automatico de HA seja extremamente importante, um Geo Cluster é algo que nem todas as empresas poderão contar. Mas o Windows Server 2012 trouxe uma novidade que muitas empresas poderão adotar que é extremamente mais acessível. Trata-se do Hyper-V Replica.

O Hyper-V Replica é um recurso do Hyper-V 3 que está disponível nas 2 versões do Windows Server 2012 (Standard e Datacenter) e também no Hyper-V Server 2012, ou seja, é um recurso gratuíto.

O Hyper-V Replica, consiste em ter um host de virtualização em uma localidade e outro Host em uma segunda localidade.O Replica é aplicado por VM, logo, para as VMs que você quer replicar, você irá configurar a replicação tendo uma máquina virtual de origem ligada e funcionando, e outra máquina virtual de destino desligada. No caso de uma falha, você deverá manualmente fazer o failover desta VM para que a VM de destino seja ligada. Neste caso, você poderá escolher entre os Pontos de Recuperação disponíveis, caso você tanha habilitado esta configuração, ou então, a última replicação conhecida, lembrando que a replicação do Hyper-V Replica é assincrona. Os pontos fortes do Hyper-V Replica é que este não precisa de replicação de storage. De fato, você poderia utilizar até mesmo os discos locais dos servidores Hosts para hospedar as VMs. Nenhum tipo de storage compartilhado é necessário neste caso.

Veja que com o Hyper-V Replica também é possível automatizar o processo. Para isso você poderá utilizar vários “gatilhos”, como um script Powershell, System Center Orchestrator, Operations Manager, Service Manager ou qualquer outra solução que consiga iniciar o processo. A questão aqui é a mesma que o que foi dito acima sobre o File Share Witness. Este componente que automatiza o processo precisa estar isolado dos sites onde estão os hosts.

Resumindo: Se você precisa de um processo de Recuperação Automatizado e o serviço ou aplicação que você quer proteger não puder ficar parado por muito tempo (tempo para um processo de failover manual) o ideal é ter um cluster Geográfico. Mas lembre-se que você precisará de recursos extras para isso. Agora, se a aplicação pode ter um tempo de inatividade aceitável, o Hyper-V Replica é uma excelente solução pois é simples de se configurar, não tem nenhum custo nem necessita de serviço de terceiro.

Espero que tenham gostado da expliação!
Até mais!

Mar
21

By

Virtualização de Domain Controllers – Parte 04

Category: Hyper-V, Virtualização, Windows Server 3 Comments

Olá Pessoal,

Mais uma parte de nossa série de posts sobre Domain Controllers Virtualizados, hoje abordando um cenário que pode causar muitos problemas. Trata-se da dependencia do Serviço de Cluster no Windows Server sobre o Active Directory.

A essa altura do campeonato, você já deve ter percebido que ter os Domain Controllers virtualizados não é impossível nem algo de outro mundo. Requer alguns cuidados a mais, sim, mas é plausível. Porém, há uma configuração de DC virtualizado que pode ser um problema. Este problema é quando você virtualiza todos os Domain Controllers em cima, não de um Host de Virtualização, mas de um Cluster.

Até o Windows Server 2008 R2, o serviço de cluster só irá iniciar se o contato com um Domain Controller for estabelecido. Se você colocar todos os seus Domain Controllers virtualizados em um Cluster, você terá problemas se por algum motivo como falta de energia, os hosts do seu cluster desligarem. Para resolver essa situação, temos duas alternativas:

A primeira é colocar o nó do cluster como Domain Controller, apenar de ser fortemente desencorajado, essa situação é relativamente comum, mesmo para quem não tem o DC virtualizado e não teria o problema acima, mas quer garantir que o acesso ao AD esteja sempre disponível. Essa solução não é mais suportada no Windows Server 2012, e já explicarei por que…

A segunda alternativa é criar 2 clusters e colocar DCs virtualizados em ambos. Esse cenário é interessante quando você pensa que os dois clusters não irão parar de funcionar ao mesmo tempo. Sendo assim, se um cluster cair, haverá um DC virtualizado no outro cluster que estará disponível para o cluster que está iniciando. Mesmo assim, se os dois cluesters pararem ao mesmo tempo, você terá problemas.

Já no Windows Server 2012, uma das diversas novidades sobre cluster é justamente essa dependencia do Active Directory para que o serviço inicie. No WS2012 o serviço do Cluster poderá iniciar com uma conta de serviço local, o que fará com que o serviço inicie e as funções do cluster possam iniciar. No caso de qualquer VM, como um DC virtualizado, isso permitirá que a VM inicie e o AD esteja disponível. Vale ressaltar que o fato do serviço do cluster iniciar, não garante que todas as funções iniciem. Por exemplo: O serviço do Excahnge precisa do AD de qualquer forma.

Essa novidade do WS2012 para serviço de Cluster resolve o cenário onde todos os Domain Controllers estão virtualizados e em cluster. Neste cenário, se você tiver um cluster com DCs virtualizados e este cluster for desligado, no momento que se iniciar o cluster, o serviço irá subir, permitindo que as VMs que rodam neste cluster iniciem, pois a inicialização de VMs não é um serviço que depende do AD. Com as VMs ligadas e consequentemente, o AD de volta no ar, todos os serviços do cluester ficam dispoíveis. Para verificar as demais novidades sobre cluster no WS2012, acesse o link: http://technet.microsoft.com/en-us/library/hh831414.aspx. Sobre as novidades de cluster com AD, vá até http://technet.microsoft.com/en-us/library/hh831414.aspx#BKMK_AD.

Espero que esta dica tenha ajudado!
Até mais!

Mar
18

By

Virtualização de Domain Controllers – Parte 03

Category: Hyper-V, Virtualização, Windows Server 5 Comments

Olá Pessoal,

Mais um post da série que pretende dismistificar a virtualização de Domain Controllers. Nesse post vamos falar sobre a utilização de Snapshots em VMs que são Domain Controllers.

No último post comentei um pouco sobre a replicação entre Domain Controllers. A replicação é uma das atividades mais importantes do Active Directory, pois garante que todos os Domain Controllers tenham a mesma informação na base de dados.

Se você tem mais um Domain Controller (E você deveria ter!) a replicação deve ser monitorada para que não haja nenhum problrema dentro do seu ambiente. A replicação é feita por diversos componentes que garantem que todos os itens necessários estarão atualizados em todos os Domain Controllers. Sendo muito simplista, existem dois componentes que são importantes na resplicação e que precisam ser entendidos para que possamos continuar.

O primeiro é a informação de que um item é autoritativo naquele servidor. Imagine que um usuário trocou sua senha. Esse processo é feito na máquina do usuário que envia a informação de troca de senha do usuário para o Domain Controller mais próximo onde este usuário se autenticou. O DC com esta informação mais recente, marca esse item como autoritativo para que ele possa enviar esta informação aos outros DCs. Logo, tudas as novas informações são autoritativas no DC ao qual a modificação foi feita, seja troca de senha, criação de usuário, deleção de usuário e todo mais que altera-se na base do AD. Uma vez que este Domain Controller passou isso aos demais, a informação se torna autoritativa em todos.

Para que isso não vire uma bagunça, existem diversos outros componentes que garantem que a última informação sempre seja a que vale. E para que todos os DCs possam se entender, há um outro componente chamado USN ou Update Sequence Number (Número de Sequencia de Atualização). O USN garante que todos os Domain Controllers estão com a informação mais atual possível.

Logo, a utilização de todos estes componentes garantem que todos os DCs estejam atualizados. Porém, se você está com um Domain Controller virtualizado, há uma variável aqui que pode atrapalhar este processo. Trata-se do Snapshot.

Quando você tira o snapshot de uma VM, basicamente, você cria uma imagem desta VM em um momento no tempo. Para testes, desenvolvimento e qualquer coisa fora de produção, não há muito problema com isso. Especificamente para o AD o Snapshot pode ser um grande problema. Na verdade para qualquer tipo de banco de dados onde você precisa replicar as informações, isso será um problema.

Vamos supor que você tem 4 Domain Controllers e resolve tirar um snapshot deles em uma terça-feira as 12:00. Na quarta-feira as 12:00 você percebe que um dos DCs apresenta uma falha. Para resolver o problema rapidamente, você resolve aplicar o snapshot que tinha do DC. Isso, porém, fará com que o DC que teve o snapshot aplicado ache que a informação de USN, digamos 90, é a mais atual pois isso é autoritativo para ele. Os outros DCs estão, digamos, com o USN em 120, ou seja, outras alterações ocorreram entre teça-feira as 12:00 e quarta-feira as 12:00.

Neste momento, este DC irá interromper a replicação pois estes DCs estão divergindo na informação mais atual. Para resolver este problema, você deverá recuperar o backup do AD não-autoritativo e aguardar a replicação dos outros DCs para este DC recuperado.

Até o Windows Server 2008 R2, essa era a forma de operação. Ou seja, se ainda não está rodando o Windows Server 2012, tome muito cuidado com snapshot de DCs.

Já se você está utilizando o Windows Server 2012 como Host de seu ambiente de Virtualização e o DC também é Windows Server 2012, esse problema não ocorre. Isso por que no AD do WS2012 uma informação é verificada após a aplicação de um Snapshot, o Virtualization ID. Este item basicamente comprova que um snapshot foi aplicado nesta VM. Com essa informação, o AD é capaz de marcar o USN como não-autoritativo na VM que é um Domain Controller. Sabendo que não é autoritativo, este Domain Controller inicia o processo de replicação dos outros DCs normalmente.

 

image

Resumo: Se você utiliza Windows Server 2008 R2, seja como Host ou VM, não utilize Snapshot de VM. Se você utiliza WS2012 como Host e DC em máquina virtual, enjtão isso não será um problema.

Até mais!

Mar
15

By

Virtualização de Domain Controllers – Parte 02

Category: Active Directory, Virtualização, Windows Server Leave a Comment

Olá Pessoal,

Continuando nossa série de posts sobre virtualização de Domain Controllers, hoje quero falar sobre um assunto muito importante que se dá pouca importancia:  Sincronismo de Horário.

Muita gente acaba administrando o Active Directory sem se dar conta de alguns itens importantes sobre o mesmo. O AD é um serviço de diretório que pode ter uma arquitetura simples, para atender pequenos ambientes e com pouca configuração está pronto para funcionar, ou pode ter uma arquitetura bem complexa para atender organizações maiores. Porém, em ambos os casos, o funcionamento é o mesmo.

Desde o Active Directory na versão do Windows 2000 Server, o AD é multimaster, o que significa que todos os Domain Controllers podem escrever na base do AD. Isso é muito bom pois torna o AD muito simples para se implementar Alta disponibilidade. Porém, a reaplicação se torna algo extremamente importante. Mas o que vem ao caso aqui, é que mesmo sendo multimaster, algumas operações são executadas apenas por alguns servidores específicos. São os FSMO ou Flexible single master operation. São 5 FSMO, e para Virtualização uma delas é muito importante, o PDC Emulator.

Uma das funções do PDC Emulator é ser o ponto principal de Horário para os outros Domain Controllers, que por sua vez, fornecem o horário correto para as estações.

O problema é que no Hyper-V, quando você cria uma VM, a configuração padrão é que haja uma sincronia de horário entre VM e Host. Para um Domain Controller, isso é um problema, pois ele deveria estar seguindo a hierarquia do Active Directory.

A resolução deste problema é muito simples. Para VMs que são Domain Controllers, é preciso desmarcar a opção de sincronismo de horário nas opções de Integration Services.

image

Até mais!

Mar
13

By

Experiência em Nuvem versus Experimentos em Nuvem?

Category: Cloud, Hyper-V, Windows Server Leave a Comment

image

Olá Pessoal,

Queria deixar a dica de uma nova campanha da Microsoft para vocês. Para conhecer a campanha, acesse o site: http://www.microsoft.com/en-us/server-cloud/versus.aspx

Aproveite também para ler o post no Blog do time de produtos: http://blogs.technet.com/b/server-cloud/archive/2013/03/13/vmware-zigs-then-zags.aspx

Até mais!

« Older Posts