Virtualização de controladores de domínio com o Hyper-V

Aplica-se a: Windows Server 2022, Microsoft Hyper-V Server 2019, Windows Server 2019, Microsoft Hyper-V Server 2016, Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

O Windows Server 2012 e posteriores oferecem suporte aos controladores de domínios (DCs) virtualizados com proteções para evitar a reversão do número de sequência de atualização (USN) em DCs virtuais e a capacidade de clonar DCs virtuais. A virtualização consolida diferentes funções de servidor em uma única máquina física. Para obter mais informações, consulte Virtualização segura do Active Directory Domain Services (AD DS).

Este guia descreve como executar DCs como sistemas operacionais convidados de 32 ou 64 bits.

Planejamento da Virtualização

As seções a seguir contêm considerações de planejamento que você deve saber ao virtualizar um DC, incluindo requisitos de hardware, arquitetura, configuração e gerenciamento de segurança e desempenho.

Requisitos do Hyper-V

Para instalar e usar a função Hyper-V, seu hardware deve atender aos seguintes requisitos:

• Você deve ter um processador x64.

• O processador deve permitir que você habilite o recurso de virtualização assistida por hardware.

  • Normalmente, essa configuração é conhecida como Intel Virtualization Technology (Intel VT) ou Advanced Micro Devices Virtualization (AMD-V).

• O processador deve oferecer suporte à Proteção de Execução de Dados (DEP) de Hardware

  • Você só pode usar o Hyper-V ao ativar o bit XD (Execute Disable) da Intel ou o bit NX (No Execute) da AMD.

Evitar pontos únicos de falha

Ao planejar a implantação do DC virtual, você deve preparar uma estratégia para evitar a criação de pontos únicos de falha. Você pode evitar a introdução de possíveis pontos únicos de falha ou áreas onde o tempo de inatividade pode fazer com que todo o sistema pare de funcionar, implementando a redundância do sistema.

As recomendações a seguir podem ajudar a evitar pontos únicos de falha. No entanto, também é importante lembrar que seguir essas recomendações pode aumentar os custos administrativos.

• Execute pelo menos dois DCs virtualizados por domínio em hosts de virtualização diferentes. Essa configuração reduz o risco de perder todos os DCs se um host de virtualização parar de funcionar.

• Diversifique o hardware que executa seus DCs. Por exemplo, use diferentes CPUs, placas-mãe, adaptadores de rede e assim por diante. Diversos hardwares evitam danos causados por mau funcionamento de dispositivos e hardwares ou pela configuração do fornecedor.

• Se possível, execute seus DCs em hardwares localizados em diferentes regiões. Essa abordagem reduz as consequências de desastres que afetam um dos sites que hospedam seus DCs.

• Adicione DCs físicos a todos os seus domínios. Configurar o sistema para ter DCs físicos impede que os sistemas host apresentem mau funcionamento da plataforma de virtualização.

Considerações de segurança

Você deve gerenciar o computador host no qual você executa seus DCs virtuais com o mesmo cuidado que teria com um DC gravável,mesmo que o computador seja apenas um computador de grupo de trabalho ou de domínio unido. Este é um requisito de segurança. Hosts mal gerenciados são vulneráveis a ataques de elevação de privilégio, em que usuários maliciosos obtêm acesso a privilégios mais altos do que deveriam porque o administrador atribuiu o nível errado de permissão a uma atribuição de função de nível inferior. Esses ataques podem comprometer todas as máquinas virtuais (VMs), domínios e florestas hospedados pelo computador afetado.

Ao planejar a virtualização do seu DC, tenha em mente as seguintes considerações de segurança:

• As credenciais de administração locais de um computador que hospeda DCs virtuais graváveis deve ser considerada equivalente ao administrador de domínio de falha de todos os domínios e florestas aos quais os DCs pertencem.

• Recomendamos que você configure seu sistema para ter um host executando uma instalação Server Core do Windows Server sem aplicativos além do Hyper-V. Essa configuração limita a quantidade de aplicativos e servidores instalados no servidor. Essa limitação resulta em melhor desempenho do sistema e também cria uma superfície de ataque reduzida, onde há menos pontos de entrada para ataques maliciosos por meio de aplicativos e serviços.

• Para filiais ou outros locais difíceis de proteger, recomendamos que você use DCs somente leitura (RODCs). Se você tiver uma rede de gerenciamento separada, recomendamos conectar somente o host à rede de gerenciamento. Para obter mais informações sobre RODCs, consulte Instalar um controlador de domínio somente leitura (RODC) do Active Directory do Windows Server (nível 200).

• Você pode proteger seus DCs com o BitLocker. No Windows Server 2016 e posteriores, você também pode usar o recurso Trusted Platform Module (TPM) virtual, que fornece ao convidado o material de chave necessário para desbloquear o volume do sistema.

• A malha protegida e as VMs blindadas podem fornecer outros controles para proteger seus DCs.

Para obter mais informações sobre a proteção de DCs, consulte o Guia de melhores práticas para proteger instalações do Active Directory.

Limites de segurança para configurações de host e convidado

Você pode implementar máquinas virtuais (VMs) em muitos tipos diferentes de configurações de DC. Portanto, você precisa considerar cuidadosamente como essas VMs afetam os limites e as relações de confiança na topologia do Active Directory. A lista a seguir descreve duas configurações que você pode configurar para DCs e hosts do Active Directory em um servidor Hyper-V e computadores convidados que são VMs em execução no servidor Hyper-V:

• Um host que é um grupo de trabalho ou computador membro com um convidado que é um DC.
• Um host que é um grupo de trabalho ou computador membro com um convidado que também é um grupo de trabalho ou computador membro.

O diagrama a seguir demonstra uma configuração de três VMs convidadas de DC hospedadas em um servidor Hyper-V.

Um diagrama de uma implantação de exemplo de três máquinas virtuais (VMs) e um servidor Hyper-V. As três VMs estão dentro de um retângulo azul rotulado como "máquinas convidadas". Todas as três VMs são controladoras de domínio. A VM 1 está no domínio Corp e na floresta Contoso.com. A VM2 está no domínio Fabrikam e na floresta Fabrikam.com. A VM 3 está no domínio HQ e na floresta Fineartschool.net. O servidor Hyper-V está fora do retângulo azul. É um servidor membro localizado no domínio Corp e na floresta Contoso.com.

Com base na configuração de exemplo no diagrama anterior, estas são algumas considerações importantes que você deve fazer ao planejar uma implantação como esta:

• Acesso do administrador

  • As credenciais de administrador no computador host devem ser tratadas da mesma forma que as do administrador de domínio no controlador de domínio gravável. Para um convidado RODC, as credenciais de administrador do computador host devem ser tratadas da mesma forma que as do administrador local no RODC convidado.

• Direitos administrativos de DC no computador host

  • Um administrador de um DC virtualizado tem direitos administrativos no host se você associar o host ao mesmo domínio. No entanto, esse privilégio de acesso também pode dar aos usuários maliciosos a oportunidade de comprometer todas as VMs se eles puderem obter acesso à VM 1. Esse cenário cria um possível vetor de ataque. Você pode impedir esse vetor de ataque certificando-se de que todos os DCs configurados para vários domínios ou florestas tenham um domínio de administração centralizado confiável para todos os domínios, e tornem o host de virtualização um membro do domínio de administração altamente privilegiado. Essa abordagem impede que administradores de domínio individuais controlem o host e, portanto, os outros domínios.

• Evitando ataques

  • Usuários maliciosos podem atacar a VM 1 mesmo se você instalá-la como um RODC. Embora os administradores do RODC não tenham explicitamente direitos de administrador de domínio, eles ainda podem usar o RODC para aplicar diretivas ao computador host. Essas diretivas podem incluir scripts de inicialização, por exemplo. Se um ator malicioso encontrar uma maneira de obter direitos de administrador RODC e enviar uma política com um script de inicialização malicioso, ele poderá comprometer o computador host e usá-lo para comprometer outras VMs no host.

• Segurança de arquivos VHD (disco rígido virtual)

  • Os arquivos VHD para um DC virtual são como o disco rígido físico de um DC físico. Você deve ter o mesmo cuidado com a proteção do arquivo VHD como faria com um disco rígido. Certifique-se de que você só permite que administradores confiáveis acessem esses arquivos VHD.

• RODCs

  • Você pode colocar RODCs em locais onde a segurança física não é garantida, como filiais. Você pode proteger seus arquivos VHD usando a Criptografia de Unidade de Disco BitLocker do Windows contra ataques no host que envolvam roubo do disco físico. No entanto, essas proteções não se aplicam aos sistemas de arquivos dentro do RODC.

Considerações sobre o desempenho

A arquitetura Microkernel de 64 bits tem melhor desempenho do Hyper-V em relação às plataformas de virtualização anteriores.

O desempenho da VM depende da carga de trabalho para a qual você a usa. Recomendamos que você teste topologias de VM específicas para garantir que esteja satisfeito com o desempenho de implantação do Active Directory. Você pode avaliar o desempenho das cargas de trabalho durante um período de tempo específico usando ferramentas como o Monitor de Confiabilidade e Desempenho (Perfmon.msc) ou o kit de ferramentas MAP (Microsoft Assessment and Planning). A ferramenta MAP também pode ajudá-lo a fazer um inventário de todos os servidores e funções de servidor atualmente em sua rede.

Para ter uma ideia de como o teste de desempenho de DC virtualizado funciona, criamos um exemplo de teste de desempenho usando a Ferramenta de Teste de Desempenho do Active Directory (ADTest.exe).

Os testes LDAP (Lightweight Directory Access Protocol) foram realizados em um DC físico usando ADTest.exe. Os mesmos testes foram executados em um DC virtualizado que consistia em uma VM hospedada em um servidor idêntico ao DC físico. Somente um processador lógico foi usado nesta compilação de exemplo para o computador físico e apenas um processador virtual para a VM. Essa configuração permitiu que a implantação atingisse facilmente 100% de utilização da CPU.

A tabela a seguir lista os resultados do teste para os DCs físicos e virtuais. As letras e números entre parênteses ao lado dos nomes dos testes são seus rótulos em ADTest.exe. Esses dados mostram que o desempenho do DC virtualizado ficou entre 88% e 98% do desempenho do CD físico.

Medida	Teste	Físico	Máquina	Delta
Pesquisas/s	Procura nome comum no escopo base (L1)	11508	10276	-10,71%
Pesquisas/s	Procura um conjunto de atributos no escopo base (L2)	10123	9005	-11,04%
Pesquisas/s	Procura todos os atributos no escopo base (L3)	1284	1242	-3.27%
Pesquisas/s	Procura nome comum no escopo de subárvore (L6)	8613	7904	-8.23%
Associações bem-sucedidas/s	Realizar ligações rápidas (B1)	1438	1374	-4,45%
Associações bem-sucedidas/s	Realizar ligações simples (B2)	611	550	-9,98%
Associações bem-sucedidas/s	Usar NTLM para realizar ligações (B5)	1068	1056	-1,12%
Gravações/s	Gravar vários atributos (W2)	6467	5885	-9,00%

Para maximizar o desempenho em nossa implantação de teste, instalamos componentes de integração (IC) nesta compilação de teste para permitir que o sistema operacional convidado use drivers sintéticos com reconhecimento de hipervisor. Ao instalar um IC, às vezes você precisa usar IDEs (Integrated Drive Electronics) emulados ou drivers de adaptador de rede. Em ambientes de produção, você deve substituir essas unidades de disco emuladas por unidades de disco sintéticas para aumentar o desempenho.

Com base nesse teste, considere as seguintes recomendações para melhorar o desempenho:

• Quando você monitora o desempenho da VM usando a ferramenta Perfmon.msc, às vezes as informações da CPU para a VM não são totalmente precisas. Essa imprecisão se deve à forma como a CPU virtual está programada para ser executada no processador físico. Para obter informações mais precisas sobre a CPU de uma VM em execução em servidores Hyper-V, use os contadores do Processador Lógico Hypervisor do Hyper-V na partição host. Para mais informações sobre o ajuste de desempenho do AD DS e do Hyper-V, consulte Diretrizes de ajuste de desempenho para o Windows Server.

• Recomendamos que você evite usar VHDs de disco diferencial em uma VM configurada como um DC, pois VHDs de disco diferencial podem reduzir o desempenho. Para saber mais sobre os tipos de disco do Hyper-V, incluindo discos diferenciados, consulte Assistente do novo disco rígido virtual.

• Também recomendamos que você se familiarize com as informações sobre como usar o AD DS em ambientes de hospedagem virtual com Aspectos a considerar ao hospedar DCs do Active Directory em ambientes de hospedagem virtual.

Considerações sobre implantação

As seções a seguir descrevem práticas comuns de VM a serem evitadas ao implantar DCs e considerações especiais sobre sincronização de tempo e armazenamento.

Recomendações de implantação

As plataformas de virtualização, como o Hyper-V, oferecem muitos recursos que facilitam o gerenciamento, a manutenção, o backup e a migração de computadores. No entanto, existem certas recomendações que você precisa seguir para aproveitar esses recursos para seus DCs virtuais.

• Para garantir a durabilidade das gravações do Active Directory, não implemente arquivos de banco de dados de um DC virtual, como o banco de dados NTDS.DIT do Active Directory, logs e SYSVOL em discos IDE virtuais. Em vez disso, crie um segundo VHD (disco rígido virtual) conectado a um controlador SCSI (Small Computer System Interface) virtual e verifique se os arquivos de banco de dados estão no disco SCSI da VM quando você instalar o DC.

• Não implemente VHDs de disco diferenciais em uma VM que você está configurando como DC. Enquanto essa abordagem facilita a reversão da sua implantação para versões anteriores, ela também diminui o desempenho. Para obter mais informações sobre os tipos de VHD, consulte Assistente do novo disco rígido virtual.

• Não implemente novos domínios e florestas do Active Directory em uma cópia de um sistema operacional Windows Server sem antes usar a ferramenta de Preparação do Sistema (Sysprep) para prepará-los para a implantação. Para obter mais informações sobre a execução do Sysprep, consulte Visão Geral de Sysprep (Preparação do Sistema).

  Aviso

  A execução do Sysprep em um controlador de domínio promovido não é recomendada, pois pode afetar negativamente o banco de dados do AD e os componentes relacionados e causar os seguintes problemas:

  • Perda de dados
  • Corrupção do banco de dados do AD
  • Problemas de estabilidade e funcionalidade
  • Problemas de aplicativos, serviços e drivers

• Não implante outros DCs com uma cópia de um arquivo VHD de um DC implantado. O não uso de cópias impede possíveis cenários de reversão de USN. Para obter mais informações sobre a reversão de USN, confira USN e reversão de USN.

  • No Windows Server 2012 e posteriores, os administradores podem clonar imagens de DC para implantar mais DCs somente se usarem imagens preparadas adequadamente.

• Não use o recurso Hyper-V Export para exportar uma VM que esteja executando um DC.

  • No Windows Server 2012 e posteriores, o sistema lida com a exportação e importação de convidados virtuais do DC como uma restauração não autorizada. Esse processo detecta se houve uma alteração da ID de geração e se o DC não está configurado para clonagem.

  • Ao exportar uma VM convidada, você deve certificar-se de que ninguém a está usando. Para facilitar as coisas, você pode usar a Replicação do Hyper-V para criar uma cópia inativa do DC. Ao começar a usar a imagem replicada, você também deve executar a limpeza como faria para a imagem de origem depois de exportar uma imagem de convidado de DC.

Conversão física para virtual

O System Center VM Manager (VMM) permite gerenciar máquinas físicas e VMs de forma unificada. Você também pode usar o VMM para migrar uma máquina física para uma VM. Esse processo de migração é chamado de conversão física para VM, ou conversão P2V. Para iniciar o processo de conversão P2V, você deve verificar se a VM e o DC físico que você está migrando não estão sendo executados ao mesmo tempo. Garantir que as duas máquinas não estejam sendo executadas ao mesmo tempo evita cenários de reversão de USN, conforme descrito em USN e reversão de USN.

Você deve executar a conversão P2V no modo offline para garantir que os dados do diretório sejam consistentes quando o DC for ligado novamente. Você pode alternar o modo offline no instalador Converter Servidor Físico. Para obter mais informações sobre como usar o modo offline, consulte P2V: Converter computadores físicos em VMs no VMM.

Você também deve desconectar a VM da rede durante a conversão P2V. Você só deve habilitar o adaptador de rede depois de concluir o processo de conversão e verificar se tudo funciona. Neste ponto, você deve desligar o computador de origem física. Não ligue novamente o computador de origem física e reconecte-a à rede até depois de reformatar o disco rígido.

Evitando a reversão de USN

Ao criar DCs virtuais, você deve evitar a criação de cenários de reversão de USN. Para evitar a reversão, você pode configurar um novo DC virtual por meio de promoção regular, promoção da Instalação a partir da Mídia (IfM) ou ao clonar o DC se você já tiver pelo menos um DC virtual. Essa abordagem também permite que você evite problemas de hardware ou problemas relacionados à plataforma que os convidados virtuais convertidos em P2V possam encontrar.

Aviso

Para evitar problemas com a replicação do Active Directory, certifique-se de que existia apenas um DC virtual ou físico em uma determinada rede em qualquer momento. Você pode reduzir a probabilidade de o clone antigo ser um problema usando um dos seguintes métodos:

• Quando o novo DC virtual estiver em execução, execute o seguinte comando duas vezes para alterar a senha da conta do computador:

  netdom resetpwd /Server:<domain-controller>
  

• Exporte e importe o novo convidado virtual para forçá-lo a se tornar uma nova ID de geração e uma ID de invocação de banco de dados.

Ambientes de teste e migração de P2V

Você pode usar a migração P2V com o VMM para criar ambientes de teste. Com esse método, você pode migrar DCs de produção de computadores físicos para VMs para criar um ambiente de teste sem derrubar permanentemente os DCs de produção. No entanto, o ambiente de teste deve estar em uma rede diferente do ambiente de produção para permitir a existência de duas instâncias do mesmo DC. É importante evitar reversões de USN ao criar ambientes de teste usando a migração P2V.

Criando um ambiente de teste

Recomendamos que você faça o seguinte ao criar ambientes de teste usando P2V:

• Migre um controlador de domínio em produção de cada domínio para uma VM de teste usando P2V com base nas recomendações em Conversão física para virtual.

• Localize os computadores físicos de produção e teste as VMs em redes diferentes quando elas estiverem online novamente.

• Para evitar reversões de USN no ambiente de teste, desconecte todos os DCs que você planeja migrar da rede. Você pode desconectar seus DCs interrompendo o serviço NTDS ou reiniciando os computadores no Modo de Restauração dos Serviços de Diretório (DSRM).

• Não introduza novas atualizações no ambiente depois de desconectar os DCs da rede.

• Não conecte nenhum dos computadores à rede durante a migração P2V. Você só pode reconectá-los depois de concluir a migração de todos os computadores.

• Você só deve promover DCs de teste feitos após a conversão P2V como réplicas no ambiente de teste.

Serviço e sincronização de tempo

Para VMs configuradas como DCs, é recomendável desabilitar a sincronização de tempo entre o sistema host e o SO convidado que está atuando como um DC. Se o controlador de domínio convidado não sincronizar com o sistema host, ele sincronizará com a hierarquia de domínio.

Para desabilitar o provedor de sincronização de tempo do Hyper-V, desative a VM e vá para as configurações da VM, selecione Serviços de integração e desmarque a caixa de seleção Sincronização de tempo.

Armazenamento e otimização

Recomendamos que você siga as recomendações de armazenamento nesta seção para otimizar o desempenho da VM de DC e garantir que as gravações do Active Directory sejam duráveis.

• Para o armazenamento de convidados, armazene o arquivo do banco de dados do Active Directory (Ntds.dit) e os arquivos log e SYSVOL em um disco virtual separado dos arquivos do SO. Recomendamos que você armazene esses arquivos em um disco SCSI virtual em um segundo VHD conectado a um controlador SCSI virtual. Discos SCSI virtuais aumentam o desempenho e oferecem suporte a FUA (Acesso forçado à unidade). Com o FUA, o SO grava e lê dados diretamente da mídia, ignorando todos os mecanismos de cache.

• Se você estiver usando o BitLocker para proteger seu convidado de controlador de domínio virtual, configure os volumes extras para desbloqueio automático usando o cmdlet Enable-BitLockerAutoUnlock do PowerShell.

• Ao armazenar arquivos VHD em hosts, você deve usar um disco que não seja usado com frequência por outros serviços ou aplicativos, como o disco do sistema para o sistema operacional host. Armazene cada arquivo VHD em uma partição separada do sistema operacional host e outros arquivos VHD, de preferência em uma unidade física separada.

• O sistema de disco físico do host também deve atender a pelo menos um dos seguintes critérios para atender aos requisitos de integridade dos dados de carga de trabalho virtualizada:

  • O host usa discos de classe de servidor, como SCSI ou Fibre Channel.

  • O host garante que os discos estejam conectados a um HBA de cache com bateria.

  • O host usa um controlador de armazenamento como um sistema RAID (matriz redundante de discos independentes) como seu dispositivo de armazenamento.

  • O host usa uma fonte de alimentação ininterrupta (UPS) para alimentar o disco.

  • O host desabilita o recurso de cache de gravação do disco por padrão.

• Ao usar arquivos VHD, recomendamos o uso de discos de passagem ou VHDs de tamanho fixo, pois eles são otimizados para desempenho. Não recomendamos a expansão dinâmica e a diferenciação de discos porque eles podem causar atrasos, degradação do desempenho durante alta atividade do disco e possível perda de dados ao reverter para um snapshot anterior.

• Recomendamos que você use controladores SCSI virtuais para reduzir a chance de seus dados do Active Directory serem corrompidos.

  • Em servidores Hyper-V que hospedam DCs virtuais, você deve usar unidades físicas SCSI. Se o cenário não permitir que você use unidades SCSI, você deve desabilitar o cache de gravação na unidade ATA (Advanced Technology Attachment) ou IDE (Integrated Drive Electronics) que você está usando. Para mais informações, confira ID do evento 1539 – Integridade do banco de dados.

Restrições operacionais para controladores de domínio VM

Os controladores de domínio executados em VMs têm restrições operacionais que não se aplicam aos DCs executados em computadores físicos. Ao usar um controlador de domínio virtualizado, você deve seguir estas diretrizes:

• Não pause, pare ou armazene o estado salvo de um controlador de domínio em uma VM por mais tempo do que a vida útil da marca de exclusão da floresta. Retomar um estado salvo que você pausou ou salvou por mais tempo do que a vida útil da marca de exclusão pode interferir na replicação. Para saber como determinar o tempo de vida da marca de exclusão para a floresta, consulte Determinar o tempo de vida da marca de exclusão para a floresta.

• Não copie ou clone VHDs.

• Não pegue nem use instantâneos de DCs virtuais. Em vez disso, você deve usar um método de backup mais permanente e confiável.

• Não use o recurso Export em uma VM que esteja executando um DC.

• Não restaure ou reverta seu controlador de domínio ou o conteúdo de um banco de dados do Active Directory usando um método de backup sem suporte.

Considerações de backup e restauração

Você deve fazer backup de seus DCs para evitar a perda de dados devido a cenários de desastre ou erros administrativos. O método de backup para o qual o Active Directory oferece suporte está usando um aplicativo de backup para restaurar um backup de estado do sistema feito a partir da instalação atual do DC. O aplicativo deve ser compatível com o Active Directory, como o Backup do Windows Server. Para obter mais informações sobre métodos de backup com suporte, consulte Guia passo a passo de backup e recuperação do AD DS.

Em implantações virtualizadas, você precisa prestar atenção especial a determinados requisitos para operações de backup do Active Directory. Por exemplo, se você restaurar um controlador de domínio usando uma cópia do arquivo VHD e não atualizar a versão do banco de dados do controlador de domínio depois de restaurá-lo, isso poderá causar problemas com a replicação devido a números de controle imprecisos entre as réplicas de controlador de domínio. Na maioria dos casos, a replicação não detecta esse problema e não informa erros, mas inconsistências entre DCs podem causar problemas em determinados cenários.

Método recomendado para fazer backup e restaurar DCs virtualizados

O método que recomendamos para fazer backup e restaurar seus DCs virtualizados é executar o Backup do Windows Server no SO convidado. Para obter mais informações, consulte Restaurar um controlador de domínio virtual.

Embora você possa tecnicamente usar instantâneos ou cópias de arquivos VHD para restaurar um backup, não recomendamos o uso desses métodos pelos seguintes motivos:

• Se você copiar ou clonar um arquivo VHD, o banco de dados ficará obsoleto porque seu número de versão do banco de dados não será atualizado automaticamente quando você restaurá-lo. Essa inconsistência nos números de controle significa que, se você iniciar o VHD no modo normal, poderá causar uma reversão de USN.

• Embora o Windows Server 2016 e versões posteriores sejam compatíveis com instantâneos, os instantâneos não fornecem o tipo de histórico de backup estável e permanente de que você precisa para restaurar consistentemente o sistema durante cenários de desastre. Os instantâneos baseados em VSS (Serviço de Cópias de Sombra de Volume) que você pode criar no Windows Server 2016 Hyper-V e posteriores também não são compatíveis com o BitLocker, o que pode causar possíveis problemas de segurança. Esse problema impede que o mecanismo de banco de dados do Active Directory acesse o banco de dados que contém o instantâneo quando o Hyper-V tenta montar o volume de instantâneo.

Observação

O projeto de VM blindada descrito em Malha protegida e VMs blindadas tem um backup controlado por host Hyper-V como uma meta não atingida para a proteção máxima de dados da VM convidada.

USN e reversão de USN

Esta seção descreve os problemas de replicação que podem ocorrer como resultado de uma restauração incorreta do banco de dados do Active Directory com uma versão mais antiga de uma VM. Para obter mais informações sobre o processo de replicação do Active Directory, consulte Conceitos de replicação do Active Directory.

Como o AD DS e os DCs usam USNs

O AD DS usa USNs para manter o controle da replicação de dados entre os DCs. Cada vez que uma alteração é feita nos dados do diretório, o USN é incrementado para indicar uma nova alteração.

Os DCs de destino usam USNs para rastrear atualizações para cada partição de diretório que armazenam. O USN também acompanha o status de todos os DCs que armazenam réplicas dessas partições de diretório. Quando os DCs replicam alterações entre si, eles consultam seus parceiros de replicação em busca de alterações com USNs maiores que a última alteração que o DC recebeu de cada parceiro.

Você pode encontrar as tabelas de metadados de replicação que contêm os USNs no vetor de atualização e marca d'água alta. Tanto os DCs de origem quanto de destino usam essas tabelas para filtrar updates necessários para o DC de destino.

O DC de destino mantém a atualização da tabela de vetor para acompanhar as atualizações de origem recebidas de todos os DCs de origem. Quando um DC de destino solicita alterações em uma partição de diretório, ele fornece seu vetor atualizado ao DC de origem. O DC de origem usa esse valor para filtrar as atualizações que envia ao DC de destino. O DC de origem envia seu vetor atualizado para o DC de destino após a conclusão de um ciclo de replicação. O controlador de domínio de origem usa o USN para definir se o controlador de domínio de destino está sincronizado com as atualizações de origem em cada controlador de domínio e se as atualizações para os destinos estão no mesmo nível que o de origem.

A tabela de marca d'água alta é mantida pelo DC de destino para acompanhar as alterações mais recentes recebidas de um DC de origem específico para uma partição específica. A tabela de marca d'água alta impede que o DC de origem envie alterações que o DC de destino já tenha recebido dele.

Identidade do banco de dados do diretório

Além dos USNs, os DCs mantêm o controle do banco de dados de diretório dos parceiros de replicação de origem. A identidade do banco de dados do diretório executado no servidor é mantida separadamente da identidade do próprio objeto do servidor. A identidade do banco de dados do diretório em cada DC é armazenada no atributo invocationID do objeto NTDS Settings, que está localizado no caminho cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain* do Protocolo LDAP.

A identidade do objeto do servidor é armazenada no atributo objectGUID do objeto NTDS Settings. A identidade do objeto do servidor nunca muda. No entanto, a identidade do banco de dados do diretório é alterada nestas circunstâncias:

• Quando ocorre um procedimento de restauração do estado do sistema no servidor.

• Quando você adiciona uma partição de diretório de aplicativos ao servidor, remove-a e adiciona-a novamente.

• Quando uma instância do Hyper-V dispara seus gravadores VSS em uma partição que contém o VHD de um DC virtual.

  Nesse cenário, o convidado dispara seus próprios gravadores VSS. Essa ação é o mesmo mecanismo que o processo de backup e restauração usa. Esse método redefine o atributo invocationID.

O atributo invocationID relaciona um conjunto de atualizações originadas em um DC com uma versão específica do banco de dados do diretório. As tabelas de vetor atualizado e a marca d'água alta usam invocationID e GUID de DC, respectivamente, para que os DCs reconheçam a cópia do banco de dados do Active Directory de onde as informações de replicação estão vindo.

O atributo invocationID é um valor de identificador global exclusivo (GUID) que fica visível próximo à parte superior da saída depois que você executa o comando repadmin /showrepl. O seguinte texto representa uma saída de exemplo do comando:

Repadmin: running command /showrepl against full DC local host
Default-First-Site-Name\VDC1
DSA Options: IS_GC
DSA object GUID: 966651f3-a544-461f-9f2c-c30c91d17818
DSA invocationID: b0d9208b-8eb6-4205-863d-d50801b325a9

Quando você restaura o AD DS em um DC, o sistema redefine o atributo invocationID. Essa alteração aumenta o tráfego de replicação, em que a duração é relativa ao tamanho da partição que está sendo replicada.

Para demonstrar esse cenário, o diagrama a seguir descreve um ambiente de exemplo em que o controlador de domínio virtual VDC1 e o controlador de domínio DC2 são dois DCs no mesmo domínio. Este diagrama mostra como o DC2 detecta o valor invocationID em VDC1 após uma redefinição em um cenário de restauração com suporte.

Um diagrama representando um fluxograma da visão de VDC1 de si mesmo e a visão de DC2 de VDC1. Na linha VDC1, ele começa com um USN de 1.000 e um ID de invocação B. Em seguida, ele é restaurado para sua versão anterior, que tem um USN de 500 e um valor InvocationID B. As alterações ocorrem no VDC1, trazendo-o de volta para USN 600 enquanto o ID de invocação permanece o mesmo. Na linha que diz "DC2 view of VDC1", DC2 começa com um ID de invocação de VDC1(A)@USN1000. Depois que o VDC1 é restaurado, o DC2 redefine seu USN esperado de 1.000 para 500, tornando seu valor para ID de invocação B VDC1(B)@USN500. Ele continua a rastrear a ID de invocação A e a ID de invocação B. Após o próximo conjunto de alterações no VDC1, o DC2 agora rastreia o ID de invocação A do VDC1 de USN 1.000 e seu novo ID de invocação B de USN 600.

Reversão de USN

A reversão de USN ocorre quando o sistema não consegue atualizar um USN normalmente, um usuário contorna as atualizações de USN ou um DC tenta usar um USN inferior à atualização mais recente. Quando o sistema detecta uma reversão de USN, ele interrompe a replicação antes que a incompatibilidade possa causar uma divergência na floresta.

Muitos fatores podem causar uma reversão de USN. Por exemplo, isso pode acontecer se você usar arquivos VHD antigos ou executar a conversão P2V sem desconectar permanentemente a máquina física após a conversão.

Impedindo a reversão de USN

Você pode evitar reversões de USN tomando as seguintes precauções:

• Quando não estiver executando o Windows Server 2012 ou posterior, não tire nem use um instantâneo de uma VM do DC.

• Não copie o arquivo VHD do DC.

• Quando não estiver executando o Windows Server 2012 ou posterior, não exporte VMs que estejam executando um DC.

• Somente restaure um controlador de domínio ou reverta o conteúdo de um banco de dados do Active Directory usando soluções de backup primário com suporte, como o Backup do Windows Server.

Às vezes, o sistema não consegue detectar a reversão de USN antes que ela possa causar erros de replicação. Ao encontrar erros de replicação, você deve identificar a extensão do problema e resolvê-lo o mais rápido possível. Para obter mais informações sobre como remover objetos persistentes que podem ocorrer como resultado da reversão de USN, consulte ID de Evento de replicação do Active Directory 1388 ou 1988: um objeto persistente é detectado.

Detecção de reversão de USN

Na maioria dos casos, o sistema pode detectar reversões de USN rastreando inconsistências no atributo invocationID causadas pela restauração de um controlador de domínio sem redefinir o atributo. O Windows Server 2008 fornece proteções contra erros de replicação após operações de restauração de DC sem suporte. Essas proteções disparam quando uma restauração sem suporte cria USNs inferiores às versões originais, representando alterações que os parceiros de replicação já receberam.

No Windows Server, quando um DC de destino solicita alterações usando um USN usado anteriormente, o DC de destino interpreta a resposta do parceiro de replicação para significar que seus metadados de replicação estão desatualizados. Metadados desatualizados significam que o banco de dados do Active Directory no controlador de domínio de origem foi revertido para um estado anterior, portanto, o sistema responde de acordo.

Por exemplo, digamos que o arquivo VHD de uma VM tenha sido revertido para uma versão anterior. Nesse caso, o DC de destino inicia as seguintes medidas de quarentena no DC que foi identificado como tendo sido submetido a uma restauração sem suporte:

• O AD DS pausa o serviço de logon de rede, o que evita a mudança de senhas nas contas do usuário e do computador. Essa ação evitará a perda de tais alterações se elas ocorrerem após uma restauração inadequada.

• O AD DS desabilita a replicação de entrada e de saída do Active Directory.

• O AD DS gera a ID do evento 2095 no log de eventos do Serviço de Diretório para gravar o acontecido.

o diagrama a seguir mostra a sequência de eventos que ocorrem quando a reversão de USN é detectada pelo AD DS no VDC2, o DC de destino que está sendo executado em uma VM. Nesta ilustração, a detecção de reversão de USN ocorre no VDC2 quando um parceiro de replicação detecta que o VDC2 enviou um valor de USN atualizado visto anteriormente pelo DC de destino. Essa condição indica que o banco de dados VDC2 sofreu uma reversão.

Um diagrama representando um fluxograma de atualizações VDC2 e valor de atualização DC1 para VDC2. VDC2 começa com um USN de 100 e ID de invocação A. Em seguida, atualiza seus USNs de 101 para 200, o que é replicado no DC1. No entanto, o usuário também faz uma cópia VHD do VDC2 USN 200. Em seguida, o VDC2 atualiza para USN 201 a 350 e replica essas alterações no DC1. No entanto, VDC2 falha. Em seguida, o usuário restaura o VDC2 com a cópia feita no VHD USN 200. Depois disso, o usuário faz outra atualização para VDC2 para uma nova versão dos USNs 201-355. O DC1 solicita alterações maiores que USN 350 de VDC2 e é replicado porque o USN em VDC2 é maior que DC1. No entanto, a nova versão dos USNs 201 a 350 não são os mesmos do DC1, causando uma reversão de USN.

Resolver problemas da ID de Evento 2095

Se você vir a ID de Evento 2095 no log de eventos do Serviço de Diretório, siga estas instruções imediatamente:

1. Isole a VM que registrou o erro da rede.

2. Verifique se as alterações informadas se originaram dessa DC e se propagaram para outras DCs. Se o evento foi resultado de um instantâneo ou cópia de uma VM sendo usada, tente determinar o horário em que ocorreu a reversão de USN. Uma vez que você tenha o horário, é possível verificar os parceiros de replicação desse DC para determinar se a replicação ocorreu após a reversão.

   Você pode usar a ferramenta Repadmin para verificar de onde vieram as alterações. Para obter informações sobre como usar o Repadmin, consulte Monitorar e solucionar problemas de replicação do Active Directory com o Repadmin. Se não for possível fazer uma determinação, entre em contato com o Suporte da Microsoft para obter assistência.

3. Rebaixar o DC à força. Essa operação envolve a limpeza dos metadados do DC e o controle das funções de mestre de operações, também conhecidas como funções de operações mestras simples flexíveis ou FSMO. Para obter mais informações, consulte Recuperar da reversão de USN.

4. Exclua todos os arquivos VHD anteriores do DC.

Reversão de USN não detectada

O controlador de domínio pode não detectar a reversão de USN nos seguintes cenários:

• O arquivo VHD é conectado a diferentes VMs executadas em vários locais simultaneamente.

• O USN no DC restaurado aumentou além do último USN recebido pelo outro DC.

No cenário do arquivo VHD, outros DCs podem replicar com qualquer uma das VMs, e as alterações podem ocorrer em uma das VMs sem serem replicadas para a outra. Essa divergência da floresta é difícil de detectar e causa respostas imprevisíveis do diretório. Essa situação pode ocorrer após uma migração P2V se o DC físico e a VM forem executados na mesma rede. Essa situação também pode ocorrer se vários DCs virtuais forem criados a partir do mesmo DC físico e, em seguida, executados na mesma rede.

No cenário de USN, uma série de USNs se aplica a dois conjuntos diferentes de alterações. Esse cenário pode continuar por longos períodos sem ser detectado. Quando você modifica um objeto criado durante esse período, o sistema detecta um objeto remanescente e o informa como ID de Evento 1988 no Visualizador de Eventos. O diagrama a seguir mostra por que o controlador de domínio pode não detectar a reversão de USN nesse cenário.

Diagrama que mostra um fluxograma para o processo de detecção de reversão em uma compilação de exemplo. Há dois controladores de domínio rotulados como "VDC1" e "DC2". O estágio inicial do fluxograma mostra o DC virtual, VDC1, tirar um instantâneo quando seu USN é 2.000. Após o instantâneo, o VDC1 cria 100 usuários e o VDC1 atualizado agora tem um USN de 2.100. As atualizações no VDC1 replicam para DC2, que agora compartilha o USN de 2.100. No entanto, o VDC1 usa o instantâneo necessário para reverter para sua versão USN 2.000. A versão revertida do VDC1 cria 150 novos usuários, o que eleva seu USN para 2.150. O VDC1 atualizado replica para DC2, mas DC2 não detecta as alterações incompatíveis porque seu USN é maior do que o USN do DC2 de 2.100. O texto na parte inferior diz: "Reversão de USN não detectada", o que resulta em uma divergência não detectada em que os USNs 2.001 a 2.100 não são os mesmos entre os dois controladores de domínio.

Controladores de domínio somente leitura

Os RODCs (Controladores de Domínio Somente Leitura) são DCs que hospedam cópias de somente leitura das partições em um banco de dados do Active Directory. Os RODCs evitam a maioria dos problemas de reversão de USN porque não replicam nenhuma alteração para os outros DCs. No entanto, se um RODC replicar de um DC gravável afetado pela reversão de USN, ele também afeta o RODC.

Não recomendamos o uso de um snapshot para restaurar um RODC. Sempre restaure um RODC usando um aplicativo de backup compatível com o Active Directory. Além disso, assim como ocorre com os DCs graváveis, não permita que um RODC fique offline por mais tempo do que o tempo de vida útil da marca de exclusão. Essa condição pode resultar em objetos persistentes no RODC.

Para obter mais informações sobre a implementação de RODCs, consulte o Guia de passo a passo dos Controladores de Domínio Somente Leitura.

Conteúdo adicional

Saiba como restaurar DCs virtualizados em Restaurar controladores de domínio virtualizados.