Você costuma virtualizar seu Controlador de Domínio? Sabia que o uso de um recurso da Virtualização de forma incorreta, pode comprometer todo seu ambiente? Ouvi muito isso, pesquise, estudei e encontrei o bendito problema relacionado ao uso conjunto destas duas tecnologias fantásticas.

Como sabemos, a virtualização é o recurso do momento. Temos recursos e benefícios incontáveis em um ambiente virtualizado. Caso você ainda não esteja por dentro do assunto, de uma olhada nesse artigo aqui e depois continue lendo, assim será mais tranquilo de entender.

Antes de começar a pensar que sou louco em dizer que não é legal virtualizar um AD, quero que entenda que essa é uma dica, não uma regra, OK?! Vamos ao que interessa.

Como você já leu o artigo anterior deve saber que a flexibilidade é algo cativante na virtualização. Existe um recurso que agrega esse nicho chamado de “Snapshot”. Com esse cara é possível “tirar uma foto” do seu ambiente e se for de sua vontade, restaurar essa foto. Pense comigo:

– Você instalou um servidor agora e não tem certeza se uma atualização funcionará. Para não ter que, em caso de falhas, reinstalar tudo do zero, você pode simplesmente tirar um Snapshot do server, atualizar e, se tiver problemas, voltar o snapshot. Fácil, né?!

O grande e principal risco da virtualização do AD está justamente no Snapshot. Como sabemos, o AD utiliza o USN pra manter as bases atualizadas (estamos falando de um ambiente multi-domínio, ok?). As replicações parte sempre do server que possui maior USN. Vamos analisar a imagem abaixo para entender onde e como o problema acontece;

Temos dois controladores de Domínio, DC-A e DC-B. Antes de iniciar é importante explicar que controladores de domínio possuem uma tabela de referencia, os valores contidos  nesta que determina se uma replicação é necessária ou não. Cada DC possui uma UTDV (up-to-dateness vector) que lista o USN referente aos respectivos parceiros de replicação. Estamos entendidos?

Let’s go!

No momento T1 o DC-A possui um USN 100, e o DC-B possui essa informação registrada em sua UTDV. No momento T2 o admin de rede resolve tirar um Snapshot do DC-A.

Logo mais em T3, 75 usuários são criados, alterando o USN para 175 (exemplo). O DC-B atualiza, portanto, as informações referentes ao DC-A. Um pouco mais a frente em T4 o admin resolve voltar o Snapshot, e logo em seguida criar 15 usuários.

Veja que, no momento do restore do snapshot, o USN do DC-A voltou a ser 100 e depois com a criação dos 15 users passou a ser 115. Como o DC-B possui um USN, referente ao DC-A, maior do que 115, eles entendem que não existe atualização a ser realizada de DC-A para DC-B, sendo assim, nada ocorre.

Esse tipo de situação pode fazer com que esses 15 usuários novos nunca não sejam replicados, impactando sua floresta. Mas Nathan, o AD não é inteligente o suficiente para entender e mitigar esse problema?? Sim e Não. Desde o Win Server 2003 uma detecção de Rollback USN (nome bonito do problema) existe, mas pode não se aplicar a todos os cenários.

O mecanismo de defesa, assim por dizer, assim que detecta esse problema isola do DC problemático, isolando replicações e parando o Netlogon service, além de gerar o Event ID 2095.

Utilizando a mesma imagem um segundo problema pode ocorrer. Apenas troque o USN pelo RID (se não conhece esse cara, verifique o que é nesse artigo). Ali em T5, após o restore do Snapshot ocorre reuso dos RIDs de 100 a 115.

Para mitigar esse tipo de situação, sempre que houve conflito de RID, os objetos que conflitam são deletados de todas as bases. Nada bom, right?!

Haaaa, Nathan, mas ai então se eu fizer uma restauração do AD vai ocorre esse mesmo problema!! Nops, na restauração a história muda pois é algo que o sistema é preparado para, e se for autoritativa o USN virá alto, replicando para os demais DCs da rede.

E ai, entendeu o “perigo” da virtualização para o AD?! O lance é evitar os snapshots….really simple!

Vamos manter contato…cadastre-se ai e receba as atualizações do site.

Grande abraço!! Até o próximo artigo