Virtualizando controladores de domínio com Hyper-V

O Windows Server 2012 e versões posteriores oferecem suporte a controladores de domínio virtualizados (DCs) com proteções para impedir 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 Virtualizando com segurança os Serviços de Domínio Ative Directory (AD DS).

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

Planejando a 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.

Hyper-V requisitos

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 suportar a DEP (Proteção de Execução de Dados de Hardware).

  • Você só pode usar Hyper-V quando ativar o bit execute disable (XD) da Intel ou o bit no execute (NX) da AMD.

Evite pontos únicos de falha

Ao planejar sua implantação de 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 em que o tempo de inatividade pode fazer com que todo o sistema pare de funcionar, implementando 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 opera os seus DCs. Por exemplo, use diferentes CPUs, placas-mãe, adaptadores de rede e assim por diante. Hardware diversificado evita danos causados por mau funcionamento do dispositivo e hardware ou configuração do fornecedor.

• Se possível, execute seus DCs em hardware localizado em regiões diferentes. 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 seu sistema para ter controladores de domínio (DCs) físicos impede que os seus sistemas anfitriões sofram de mau funcionamento da plataforma de virtualização.

Considerações de segurança

Você deve gerenciar o computador host onde executa os seus controladores de domínio virtuais com o mesmo cuidado que faria com um controlador de domínio gravável, mesmo que o computador seja apenas associado a um domínio ou a um grupo de trabalho. Este requisito deve-se a razões de segurança. Os hosts mal gerenciados são vulneráveis a ataques de elevação de privilégio, em que usuários mal-intencionados 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 hospedadas pelo computador afetado.

Quando você planeja virtualizar seu DC, tenha em mente as seguintes considerações de segurança:

• As credenciais de administrador local de um computador que hospeda DCs graváveis virtuais devem ser tratadas como iguais ao administrador de domínio padrão de todos os domínios e florestas a que esses 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 quantos aplicativos e servidores você instala no servidor. Essa limitação resulta em um melhor desempenho do sistema e também cria uma superfície de ataque reduzida, onde há menos pontos de entrada para ataques mal-intencionados por meio de aplicativos e serviços.

• Para filiais ou outros locais de difícil segurança, recomendamos o uso de Controladores de Domínio de Somente Leitura (RODCs). Se você tiver uma rede de gerenciamento separada, recomendamos que conecte apenas o host à rede de gerenciamento. Para obter mais informações sobre RODCs, consulte Instalar um controlador de domínio Read-Only Ative Directory do Windows Server (RODC) (Nível 200).

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

• Malha protegida e VMs blindadas podem fornecer outros controles para proteger seus DCs.

Para obter mais informações sobre como proteger DCs, consulte o Guia de práticas recomendadas para proteger instalações do Ative 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 em sua topologia do Ative Directory. A lista a seguir descreve duas configurações que você pode configurar para DCs e hosts do Ative 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 computador de grupo de trabalho ou membro com um convidado que também é um computador de grupo de trabalho ou membro.

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

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

• Acesso de administrador

  • As credenciais de administrador no computador host devem ser tratadas da mesma forma que as do administrador de domínio no DC 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 do DC no computador anfitrião

  • Um administrador de um centro de dados virtualizado tem direitos administrativos sobre o host caso este seja ingressado no mesmo domínio. No entanto, esse privilégio de acesso também pode dar aos usuários mal-intencionados a oportunidade de comprometer todas as VMs se eles puderem obter acesso à VM 1. Este cenário cria um possível vetor de ataque. Você pode evitar 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 por todos os domínios e torne 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.

• Evitar ataques

  • Usuários mal-intencionados 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 políticas ao computador host. Essas políticas podem incluir scripts de inicialização, por exemplo. Se um ator mal-intencionado encontrar uma maneira de obter direitos de administrador do RODC e enviar uma política com um script de inicialização mal-intencionado, ele poderá comprometer o computador host e usá-lo para comprometer outras VMs no host.

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

  • 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 permitir que apenas administradores confiáveis e 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 envolvendo roubo do disco físico. No entanto, essas proteções não se aplicam aos sistemas de arquivos dentro do RODC.

Considerações sobre desempenho

A arquitetura Microkernel de 64 bits tem melhor desempenho Hyper-V do que as plataformas de virtualização anteriores.

O desempenho da VM depende da carga de trabalho para a qual você a utiliza. Recomendamos que você teste topologias de VM específicas para garantir que está satisfeito com o desempenho da implantação do Ative Directory. Você pode avaliar o desempenho em 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 Microsoft Assessment and Planning (MAP). 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 dar uma ideia de como funciona o teste de desempenho de DC virtualizado, criamos um exemplo de teste de desempenho usando a Ferramenta de Teste de Desempenho do Ative Directory (ADTest.exe).

Os testes de LDAP (Protocolo Leve de Acesso a Diretórios) foram realizados num 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. Apenas um processador lógico foi usado neste exemplo de compilação 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 estava entre 88% e 98% do desempenho do DC físico.

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 SO convidado use drivers sintéticos com reconhecimento de hipervisor. Quando você instala um IC, às vezes você precisa usar emulado Integrated Drive Electronics (IDE) ou drivers de adaptador de rede. Em ambientes de produção, você deve substituir esses drivers emulados por drivers sintéticos 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 Perfmon.msc ferramenta, às vezes as informações da CPU da VM não são totalmente precisas. Essa imprecisão é devido à forma como a CPU virtual está programada para ser executada no processador físico. Para obter informações mais precisas sobre a CPU da VM em execução em servidores Hyper-V, use os contadores do Processador Lógico do Hipervisor Hyper-V na partição do host. Para obter 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 evitar o uso de VHDs de disco diferencial numa VM configurada como um DC, pois VHDs de disco diferencial podem reduzir o desempenho. Para saber mais sobre os tipos de disco Hyper-V, incluindo discos diferenciais, consulte o Assistente para 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 lendo Coisas a considerar ao hospedar DCs do Ative 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 para sincronização de tempo e armazenamento.

Recomendações de implantação

Plataformas de virtualização como Hyper-V têm muitos recursos que facilitam o gerenciamento, a manutenção, o backup e a migração de máquinas. No entanto, há certas recomendações que você precisa seguir para aproveitar esses recursos para seus DCs virtuais.

• Para garantir que suas gravações do Ative Directory sejam duráveis, não implante arquivos de banco de dados DC virtuais, como o NTDS. Banco de dados DIT Ative Directory, logs e SYSVOL, em discos IDE virtuais. Em vez disso, crie um segundo disco rígido virtual (VHD) 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ê instala o DC.

• Não implemente VHDs de disco diferenciais numa VM que está a configurar como Controlador de Domínio. Embora essa abordagem facilite a reversão da implantação para versões anteriores, ela também diminui o desempenho. Para obter mais informações sobre tipos de VHD, consulte o Assistente para criação de novo disco rígido virtual.

• Não implante domínios e florestas do Ative Directory em uma cópia de um sistema operacional Windows Server sem primeiro usar a ferramenta de preparação do sistema (sysprep) para prepará-los para a implantação. Para obter mais informações sobre como executar o Sysprep, consulte Visão geral do Sysprep (Preparação do sistema).

  Warning

  A execução do Sysprep em um DC 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 implemente outros DCs com uma cópia de um ficheiro VHD de um DC que você implantou. Não utilizar cópias impede possíveis cenários de reversão do USN. Para obter mais informações sobre a reversão de USN, consulte USN e reversão de USN.

  • No Windows Server 2012 e versões mais recentes, os administradores podem clonar imagens de controladores de domínio (DC) para implantar mais DCs, mas somente se usarem imagens preparadas corretamente.

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

  • No Windows Server 2012 e posterior, o sistema lida com a exportação e importação de convidados virtuais DC como uma restauração não autoritativa. Esse processo deteta se a ID de geração foi alterada 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 simplificar, podes usar a replicação 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 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 deto-VM física ou conversão P2V. Para iniciar o processo de conversão P2V, você deve certificar-se de que a VM e o DC físico que você está migrando não estejam sendo executados ao mesmo tempo. Garantir que as duas máquinas não estejam a funcionar ao mesmo tempo evita situações de rollback de USN, como descrito em USN e Reversão de USN.

Você deve executar a conversão P2V no modo offline para manter os dados do diretório consistentes quando você ligar o DC 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. Nesse ponto, você deve desligar a máquina de origem física. Não ligue novamente a máquina de origem física nem a reconecte à rede até depois de reformatar o disco rígido.

Evitando a reversão do USN

Ao criar DCs virtuais, você deve evitar a criação de cenários de reversão USN. Para evitar a reversão, você pode configurar um novo DC virtual com promoção regular, promoção de Install from Media (IfM) ou clonando o DC se você já tiver pelo menos um DC virtual. Essa abordagem também permite evitar problemas de hardware ou plataforma que os convidados virtuais que foram convertidos usando P2V possam enfrentar.

Ambientes de teste e migração P2V

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

Criando um ambiente de teste

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

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

• Coloque as máquinas de produção físicas e as VMs de teste em redes diferentes quando as colocar 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 as máquinas 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 nenhuma das máquinas à rede durante a migração P2V. Você só pode reconectá-los quando terminar de migrar todas as máquinas.

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

Serviço de tempo e sincronização

Para VMs configuradas como DCs, recomendamos que você desabilite a sincronização de tempo entre o sistema host e o SO convidado que está atuando como um DC. Se o DC convidado não sincronizar com o sistema host, então sincroniza com a hierarquia de domínio.

Para desabilitar o provedor de sincronização de tempo Hyper-V, desative a VM e vá para as configurações da VM, selecione Integration Services 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 DC e garantir que as gravações do Ative Directory sejam duráveis.

• Para armazenamento de convidado, armazene o arquivo de banco de dados do Ative Directory (Ntds.dit) e os arquivos de log e SYSVOL em um disco virtual separado dos arquivos do sistema operacional. Recomendamos que você armazene esses arquivos em um disco SCSI virtual em um segundo VHD conectado a um controlador SCSI virtual. Um disco SCSI virtual aumenta o desempenho e suporta FUA (Forced Unit Access). Com o FUA, o sistema operacional grava e lê diretamente da mídia, ignorando quaisquer mecanismos de cache.

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

• Ao armazenar arquivos VHD em hosts, você deve usar um disco que não seja usado com freqüê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 deve atender a pelo menos um dos seguintes critérios para atender aos requisitos de integridade de dados da 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 alimentado por bateria.

  • O anfitrião utiliza um controlador de armazenamento, tal como um sistema RAID (conjunto redundante de discos independentes), como 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 porque 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 perda potencial de dados ao reverter para um snapshot anterior.

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

  • Em servidores Hyper-V que hospedam DCs virtuais, deve-se usar unidades físicas SCSI. Se o seu cenário não permitir que você use unidades SCSI, desative o cache de gravação na unidade ATA (Advanced Technology Attachment) ou IDE (Integrated Drive Electronics) que está usando. Para obter mais informações, consulte 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 a DCs executados em máquinas físicas. Ao usar um controlador de domínio virtualizado, você deve seguir estas diretrizes:

• Não pause, pare ou armazene o estado salvo de um DC em uma VM por mais tempo do que o tempo de vida da lápide da floresta. Retomar um estado salvo que foi pausado ou guardado por mais tempo do que o tempo de preservação do marcador de estado pode interferir na replicação. Para saber como determinar o tempo de vida da lápide para a floresta, consulte Determinar o tempo de vida da lápide para a floresta.

• Não copie ou clone VHDs.

• Não tire 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 Exportar em uma VM que executa um DC.

• Não restaure ou reverta seu DC ou o conteúdo de um banco de dados do Ative Directory usando um método de backup sem suporte.

Considerações sobre o backup e o restauro

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 suportado pelo Ative Directory 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 Ative Directory, como o Backup do Windows Server. Para obter mais informações sobre os métodos de backup suportados, consulte o 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 Ative Directory. Por exemplo, se você restaurar um DC usando uma cópia do arquivo VHD e não atualizar a versão do banco de dados do DC depois de restaurá-lo, isso poderá causar problemas com a replicação devido a números de rastreamento imprecisos entre as réplicas do DC. Na maioria dos casos, a replicação não deteta esse problema e não relata 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 que você use 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 tecnicamente você possa 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ê o restaurar. Essa inconsistência nos números de rastreamento significa que, se você iniciar o VHD no modo normal, poderá causar uma reversão do USN.

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

Reversão de USN e USN

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

Como os Serviços de Diretório do Active Directory (AD DS) e os controladores de domínio (DCs) usam USNs

O AD DS usa USNs para acompanhar a replicação de dados entre DCs. Cada vez que se altera informação no diretório, o USN aumenta para indicar uma nova alteração.

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

Você pode encontrar as tabelas de metadados de replicação que contêm os USNs no vetor up-to-dateness e marca d'água alta. Os DCs de origem e de destino usam essas tabelas para filtrar as atualizações necessárias para o DC de destino.

O DC de destino mantém a tabela de vetores de dateness de up-topara rastrear as atualizações de origem que recebe de todos os DCs de origem. Quando um controlador de domínio de destino solicita alterações para uma partição de diretório, ele fornece o seu vetor de atualidade de up-toao controlador de domínio de origem. Em seguida, o controlador de domínio de origem usa esse valor para filtrar as atualizações que envia para o controlador de domínio de destino. O DC de origem envia o seu vetor de temporalidade "up-to" para o DC de destino após a conclusão de um ciclo de replicação bem-sucedido. O DC de origem usa o USN para controlar se o DC de destino está sincronizado com as atualizações de origem em cada DC e se as atualizações para os destinos estão no mesmo nível que a origem.

O DC de destino mantém a tabela de marcas de referência para rastrear as alterações mais recentes recebidas de um DC de origem específico para uma partição específica. A tabela de limite máximo de dados impede que o controlador de domínio (DC) de origem envie alterações que o DC de destino já recebeu do DC de origem.

Identidade do banco de dados de diretório

Além dos USNs, os DCs mantêm registo da base de dados de diretório dos parceiros de replicação de origem. O sistema mantém a identidade do banco de dados de diretório em execução no servidor separadamente da identidade do próprio objeto do servidor. A identidade do banco de dados de diretório em cada DC é armazenada no atributo invocationID do objeto NTDS Settings, que está localizado no caminho LDAP (Lightweight Directory Access Protocol) cn=NTDS Settings, cn=ServerName, cn=Servers, cn=*SiteName*, cn=Sites, cn=Configuration, dc=*ForestRootDomain*.

O sistema armazena a identidade do objeto do servidor no objectGUID atributo do NTDS Settings objeto. A identidade do objeto de servidor nunca muda. No entanto, a identidade do banco de dados de diretório muda nas seguintes 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, remova-a e adicione-a novamente.

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

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

O invocationID atributo relaciona um conjunto de atualizações originadas em um controlador de domínio com uma versão específica do banco de dados de diretório. O vetor de datação up-toe as tabelas de ponto de referência usam o invocationID e o GUID DC, respectivamente, para que os DCs reconheçam de qual cópia do banco de dados do Active Directory as informações de replicação estão vindo.

O invocationID atributo é um valor de identificador global exclusivo (GUID) que fica visível perto da parte superior da saída depois de executar o repadmin /showrepl comando. O texto a seguir representa a 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 invocationID atributo. Essa alteração aumenta o tráfego de replicação, com duração relativa ao tamanho da partição que você está replicando.

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 deteta o invocationID valor em VDC1 após uma reposição num cenário de restauro suportado.

Reversão de USN

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

Muitos fatores podem causar uma reversão do 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 do 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 ou use um instantâneo de uma VM DC.

• Não copie o ficheiro DC VHD.

• Quando não estiver executando o Windows Server 2012 ou posterior, não exporte uma VM que esteja executando um DC.

• Restaure apenas um controlador de domínio ou reverta o conteúdo de uma base de dados do Active Directory usando soluções de backup de primeira parte com suporte, como o Windows Server Backup.

Às vezes, o sistema não consegue detetar a reversão de USN antes que ela possa causar erros de replicação. Quando 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 do USN, consulte ID do evento 1388 ou 1988 da replicação do Active Directory: um objeto persistente é detetado.

Deteção de reversão USN

Na maioria dos casos, o sistema pode detetar reversões de USN rastreando inconsistências no invocationID atributo causadas pela restauração de um DC sem redefinir o atributo. Windows Server 2008 fornece proteções contra erros de replicação após operações de restauração de DC não suportadas. Essas proteções são acionadas 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 como significando que seus metadados de replicação estão desatualizados. Metadados desatualizados significam que o banco de dados do Ative Directory no DC de origem foi revertido para um estado anterior, portanto, o sistema responde de acordo.

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

• O AD DS pausa o serviço Logon de Rede, que impede que contas de usuário e contas de computador alterem senhas de conta. Esta ação evita a perda de tais alterações se ocorrerem após uma restauração indevida.

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

• O AD DS gera a ID de Evento 2095 no log de eventos do Serviço de Diretório para registrar o que aconteceu.

O diagrama a seguir mostra a sequência de eventos que ocorrem quando o AD DS detecta a reversão de USN no VDC2, o DC de destino que está a correr numa VM. Nesta ilustração, a deteção de reversão de USN ocorre no VDC2 quando um parceiro de replicação deteta que o VDC2 enviou um valor USN up-toanteriormente visto pelo DC de destino. Essa condição indica que o banco de dados VDC2 sofreu uma reversão.

Resolver problemas do ID de evento 2095

Se vir a ID de Evento 2095 no registo 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 relatadas se originaram desse DC e se propagaram para outros DCs. Se o evento foi resultado do uso de um instantâneo ou cópia de uma VM, tente descobrir quando ocorreu a reversão do USN. Assim que tiver tempo, verifique os parceiros de replicação desse controlador de domínio 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 Monitorando e solucionando problemas de replicação do Ative Directory com o Repadmin. Se não conseguir fazer uma determinação, contacte o Suporte da Microsoft para obter assistência.

3. Rebaixar com força o DC. Essa operação envolve a limpeza dos metadados do DC e assumir as funções de mestre operacional, também conhecidas como funções FSMO (funções flexíveis de mestre único). 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 detetada

O DC pode não detetar a reversão de USN nos seguintes cenários:

• O arquivo VHD é anexado a diferentes VMs em execução em vários locais simultaneamente.

• A USN na DC restaurada aumentou além da última USN recebida pela outra DC.

No cenário de arquivo VHD, outros DCs podem replicar com qualquer uma das VMs e as alterações podem ocorrer em qualquer VM sem serem replicadas para a outra. Esta divergência da floresta é difícil de detectar e causa respostas de diretório imprevisíveis. 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 acontecer se vários DCs virtuais forem criados a partir do mesmo DC físico e, em seguida, executados na mesma rede.

No cenário USN, um intervalo de USNs se aplica a dois conjuntos diferentes de alterações. Esse cenário pode continuar por longos períodos sem ser detetado. Quando você modifica um objeto criado durante esse período, o sistema deteta um objeto persistente e o relata como ID de Evento 1988 no Visualizador de Eventos. O diagrama a seguir mostra por que o DC pode não detetar a reversão de USN nesse cenário.

DCs somente leitura

Controladores de domínio somente leitura (RODCs) são DCs que hospedam cópias somente leitura das partições em um banco de dados do Ative Directory. Os RODCs evitam a maioria dos problemas de reversão de USN porque não replicam nenhuma alteração nos outros DCs. No entanto, se um RODC replicar a partir de um DC gravável que foi afetado pela reversão de USN, essa reversão também afetará o RODC.

Não recomendamos o uso de um instantâneo para restaurar um RODC. Você só deve restaurar um RODC usando um aplicativo de backup compatível com o Ative Directory. Além disso, como acontece com DCs graváveis, você não deve permitir que um RODC fique offline por mais do que o tempo de vida da lápide. Esta condição pode resultar em objetos persistentes no RODC.

Para obter mais informações sobre como implementar RODCs, consulte o guia passo a passo de controladores de domínioRead-Only.

Conteúdo adicional

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