As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
Modernização da zona DNS _msdcs
A modernização de uma _msdcs zona DNS é um pré-requisito obrigatório antes da criação do diretório Hybrid AD. Em ambientes modernos do Active Directory, _msdcs.<ForestRoot> é criado como uma zona replicada separada em toda a floresta armazenada na partição do ForestDnsZones aplicativo. Em ambientes legados originalmente criados no Windows NT 4.0 ou no Windows 2000 (e posteriormente atualizados), nunca _msdcs foi separado; ele existe simplesmente como um subdomínio padrão (subpasta) diretamente dentro do arquivo de zona do domínio pai.
Quando um novo controlador de domínio é promovido com o DNS instalado, seu processo de instalação procura a partição dedicada do _msdcs.<ForestRoot> aplicativo. Como ele não encontra uma zona autônoma, ele cria automaticamente uma nova _msdcs zona em branco localmente e reivindica autoridade sobre esse namespace. Isso impede completamente que o novo DC leia os registros do subdomínio legado na zona principal e atualiza a delegação do NS para apontar para si mesma.
O resultado é um conflito arquitetônico. Todos os clientes associados ao domínio agora são referenciados a um DC que tem uma _msdcs zona vazia, enquanto os registros reais do localizador de DC (_ldap._tcp.dc._msdcs,, registros do Catálogo Global_kerberos._tcp.dc._msdcs, CNAMEs do DC GUID) permanecem isolados no antigo subdomínio da zona principal, onde nenhum cliente pode acessá-los. Isso interrompe a autenticação Kerberos, a descoberta do LDAP e a localização do DC com reconhecimento do site em toda a floresta.
Design de zona _msdcs antigo versus moderno
- Legado (subdomínio delegado)
-
Padrão no Windows Server 2000, 2003, 2008 e 2008 R2. Nesse design,
_msdcsexiste como um subdomínio delegado na zona principal. Os registros NS na zona principal apontam para DCs específicos como autoritativos para o namespace._msdcs - Moderno (zona autônoma)
-
Padrão no Windows Server 2012 e versões posteriores. Nesse design,
_msdcs.<forest>existe como sua própria AD-integrated zona, replicada para todos os DCs na floresta por meio da partição do ForestDnsZones aplicativo. Todos os DCs são autorizados e podem read/write gravar diretamente.
Como identificar o design da zona _msdcs
Você pode identificar o design _msdcs da sua zona executando o seguinte em qualquer controlador de domínio:
-
Liste todas as zonas DNS e procure
_msdcs:Get-DnsServerZone | Where-Object { $_.ZoneName -like "*_msdcs*" }Design moderno (nenhuma ação é necessária) — você verá uma
_msdcs.<forest-name>lista como zona primária:ZoneName ZoneType IsAutoCreated IsDsIntegrated IsReverseLookupZone IsSigned -------- -------- ------------- -------------- ------------------- -------- _msdcs.premier.local Primary False True False FalseDesign antigo (conversão necessária) — NÃO
_msdcs.<forest-name>aparecerá na lista de zonas. Em vez disso,_msdcsexiste somente como um subdomínio delegado na sua zona florestal. Você pode confirmar isso verificando os registros NS da delegação:Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NSSe isso retornar registros NS, seu ambiente usará o design de subdomínio delegado legado.
-
Validação adicional — confirme o tipo de zona:
# This will succeed on modern design Get-DnsServerZone -Name "_msdcs.<forest-name>" # If you get an error like "Zone _msdcs.<forest-name> was not found", you have the legacy design
Como modernizar a zona DNS _msdcs
Essas etapas devem ser executadas antes de iniciar a criação do diretório AWS Managed Microsoft AD Hybrid. Todas as etapas são executadas em controladores de domínio autogerenciados existentes com acesso ao Gerenciador de DNS com administrador de domínio e privilégios. DnsAdmins
-
Crie a zona autônoma
_msdcsEm um controlador de domínio autogerenciado existente:
dnscmd localhost /ZoneAdd "_msdcs.<forest-name>" /DsPrimary /dp /forestIsso é criado
_msdcs.<forest-name>como uma AD-integrated zona dedicada com escopo de Forest-wide replicação. Todos os DCs na floresta receberão uma cópia por meio da ForestDnsZones partição.Aguarde a propagação da replicação do AD:
repadmin /syncall /AeDVerifique se a zona existe (executada em vários DCs):
Get-DnsServerZone -Name "_msdcs.<forest-name>" -
Remova a delegação antiga da zona principal
O antigo nó do
_msdcssubdomínio e seus registros ainda existem na zona principal. Eles devem ser removidos para que as consultas de DNS sejam atendidas exclusivamente da nova zona autônoma.# Remove the _msdcs subtree (NS delegation + all child records) from the parent zone dnscmd localhost /NodeDelete <forest-name> _msdcs /tree /fImportante
Execute essa etapa somente após confirmar que a zona autônoma foi criada com êxito na Etapa 1. Se você pular a Etapa 1, a exclusão dos registros antigos causará uma interrupção imediata.
-
Forçar todos os DCs a registrar novamente os registros SRV
Com o subdomínio antigo removido e a nova zona autônoma estabelecida, todos os DCs devem registrar novamente seus registros localizadores na nova zona.
Execute o seguinte em cada controlador de domínio local:
# Flush DNS cache ipconfig /flushdns # Restart Netlogon — this triggers re-registration of all SRV, CNAME, and A records net stop netlogon net start netlogon # Force host record registration ipconfig /registerdns -
Verificar
Aguarde de 5 a 10 minutos pela replicação e, em seguida, verifique:
Confirme os registros preenchidos na nova zona autônoma:
Get-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -RRType SRVVocê deve ver
_ldap._tcp.dc,,_kerberos._tcp.dc_ldap._tcp.gc, e registros específicos do site para todos os DCs locais.Confirme se a resolução de DNS funciona de ponta a ponta:
Resolve-DnsName "_ldap._tcp.dc._msdcs.<forest-name>" -Type SRV Resolve-DnsName "_kerberos._tcp.dc._msdcs.<forest-name>" -Type SRVTodos os DCs locais devem aparecer nos resultados.
Confirme se a delegação antiga saiu da zona principal:
Get-DnsServerResourceRecord -ZoneName "<forest-name>" -Name "_msdcs" -RRType NS -ErrorAction SilentlyContinueIsso não deve retornar nada.
Para obter mais informações sobre a modernização de
_msdcszonas DNS, consulte Como dividir e migrar registros DNS de domínio secundário para uma zona DNS dedicada nosite do blog Microsoft Core Infrastructure and Security.
Solução de problemas
Se a nova zona autônoma permanecer vazia após a Etapa 3:
O Netlogon não pode se registrar novamente se acreditar que os registros já existem. Forçar um novo registro limpo:
# Delete the Netlogon DNS registration cache Remove-Item "HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\DnsAvoidRegisterRecords" -ErrorAction SilentlyContinue # Restart Netlogon again net stop netlogon net start netlogon
Se os registros ainda não aparecerem, crie manualmente os registros críticos usando os valores da zona principal antiga (disponíveis no backup ou em outros DCs que os armazenaram em cache):
# Example: SRV record for LDAP DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_ldap._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 389 # Example: SRV record for Kerberos DC locator Add-DnsServerResourceRecord -ZoneName "_msdcs.<forest-name>" -Name "_kerberos._tcp.dc" -Srv -DomainName "dc1.<forest-name>" -Priority 0 -Weight 100 -Port 88
Se os aplicativos continuarem falhando após a conversão:
Limpe os caches de DNS nos servidores de aplicativos e máquinas clientes afetados:
ipconfig /flushdns
As entradas negativas do cache DNS (do período de interrupção) podem persistir por até 900 segundos (15 minutos) antes de expirar.