Temos um Controlador de Domínio Principal do Servidor 2008 R2 que parece ter amnésia quando se trata de descobrir em que tipo de rede ele está. A (única) conexão de rede é identificada na inicialização como uma 'Rede pública'.
No entanto, se eu desabilitar e reativar a conexão, descobrirá que ela faz parte de uma rede de domínio.
Isso ocorre porque os Serviços de Domínio do AD não são iniciados quando o local da rede é inicialmente elaborado?
Esse problema faz com que algumas dores de cabeça com as Regras do Firewall do Windows (que eu saiba mais possam ser resolvidas de outras formas), então estou mais curioso para ver se alguém sabe por que isso acontece.
Você tem um gateway padrão nessa conexão? Responde às solicitações de ping?
O Windows usa gateways para identificar redes; se ele não tiver um gateway configurado, ou se não puder executar ping com êxito, ele não conseguirá identificar a rede à qual está conectado e assumirá que ele é público.
Se a rede de um controlador de domínio é classificada como domínio de rede não depende da configuração do gateway.
O comportamento de uma falsa classificação de rede pode ser causado pelo serviço NLA (reconhecimento de local de rede) starts before the domain is available . Nesse caso, a rede pública ou privada é escolhida e não corrigida posteriormente.
Como verificar se esta situação de falha é dada
Quando o controlador de domínio após a reinicialização estiver na rede pública, reinicie o serviço NLA ou desconecte / reconecte a rede. O controlador de domínio deve estar na rede de domínio depois.
Como resolver isso
Pode ajudar a definir o serviço NLA para atrasar o início . Melhor, verifique porque o domínio precisa de muito tempo para estar presente. Parece que o domínio precisa de mais tempo para iniciar quando há várias placas de rede.
Quando não ajuda
Quando nem a aceleração do carregamento do domínio nem o atraso da ajuda do NLA e o erro são causados pelo longo carregamento do domínio (veja "como verificar ..."), então há mais algumas coisas que podem ser feitas .
Desloca o carregamento do serviço NLA até o final do serviço, alterando a ordem de carregamento no registro (perigoso)
A seguinte entrada do Registro define as dependências para NSI RpcSs TcpIp Dhcp Eventlog NTDS DNS :
REGEDIT4
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NlaSvc]
"DependOnService"=hex(7):4e,53,49,00,52,70,63,53,73,00,54,63,70,49,70,00,44,68,\
63,70,00,45,76,65,6e,74,6c,6f,67,00,4e,54,44,53,00,44,4e,53,00,00
Execute "IPCONFIG / RENEW" do agendador na inicialização com um atraso de 1 ou 2 minutos (melhor do que iniciar o serviço NLA)
Mais uma causa também pode ser quando o controlador de domínio tem dois ou mais IPs configurados (na mesma placa ou em outras placas de rede) e as redes adicionais não estão configuradas no DNS.
Reprodução do comportamento
Em um controlador de domínio de teste (DC único!), Excluí a entrada do gateway padrão e defino DNS Server to delayed start . Fazendo isso, o domínio precisou de muito tempo para ser carregado e a rede foi classificada como public . Depois de desconectar e reconectar o cabo de rede, a rede foi classificada corretamente como domain network .
Editar anúncios
grato pelos comentários de Daniel Fisher lennybacon e Joshua Hanley :
Como adicionar uma dependência do NlaSvc ao DNS e ao NTDS
execute sc config nlasvc depend=NSI/RpcSs/TcpIp/Dhcp/Eventlog/DNS/NTDS do CMD (use sc.exe se você estiver executando no PowerShell).
Se você quiser verificar novamente as dependências existentes antes de adicionar DNS e NTDS, use sc qc nlasvc
Eu vi um comportamento semelhante em relação a um servidor do AD de 2008 R2. O que me pegou foi ter mais de um NIC habilitado, mesmo que não estivesse em uso. Depois que eu desativei as NICs não usadas e reiniciei, o problema desapareceu.
O recurso exato do Windows que você está enfrentando aqui é chamado de NLA (Network Location Awareness). Eu não sei o suficiente sobre isso para reivindicar ser um especialista, mas eu sei que há algumas informações interessantes por aí nas intertubes sobre como tudo funciona, ou deveria funcionar.
Depois de instalar um novo controlador de domínio, você pode descobrir que o "WINDOWS FIREWALL" não foi definido corretamente como "DOMAIN: ON". Isso é resultado de padrões de instalação incorretos fornecidos pela Microsoft. Para corrigir isso, limpe as configurações de IP6 DNS na conexão de rede de ":: 0" de volta para automático. Além disso, limpe os encaminhadores IP6 do servidor DNS.