Temos um problema em que alguns computadores parecem não estar captando todos os seus GPOs. Ao procurar no editor de gerenciamento de política de grupo, vemos muitos GPOs "x vermelhos" e "arquivo não encontrado" (e que não especificam qual GPO eles são).
Um pouco sobre nosso ambiente, temos 4 controladores de domínio no nível funcional do Server 2008 R2. 2 DCs são Server2k8R2 locais, outros 2 são instâncias externas do AWS EC2 executando o Server 2016.
A execução de "net share" mostra NETLOGON e SYSVOL compartilhados em caminhos DIFERENTES para os 2 DCs 2K8R2 versus os DCs 2K16 (não sei se isso é um problema).
Server2016 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL\sysvol\domain.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL\sysvol
Server 2008 R2 DCs show these paths:
NETLOGON - C:\Windows\SYSVOL_DFSR\sysvol\superior.local\SCRIPTS
SYSVOL - C:\Windows\SYSVOL_DFSR\sysvol
Em todos os casos, C:\Windows\SYSVOL\sysvol está vazio, exceto a pasta domain.local.
A execução de "DCDIAG" mostra falha no teste "SystemLog" para todos os quatro e avisos no teste DFSREvent:
AWSDC01 & AWSDC02:
SystemLog test-
"The Netlogon service encountered a client using RPC signing instead of RPC sealing".
"The Netlogon service denied a vulnerable Netlogon secure channel connection from a machine account.
DFSREvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
"
OnSite-DC1:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
SystemLog test - "An error event occurred. Event ID 0xC2000001. Unexpected failure. Error code 490@01010004"
OnSite-DC2:
DFRSEvent test - "There are warning or error events within the last 24 hours after the SYSVOL has been shared. Failing SYSVOL replication problems may cause problems with group policy"
and
"This computer could not authenticate with \\AWSDC01.domain.local, a Windows domain controller for domain DOMAINNAME, and therefore this computer might deny logon requests. This inability to authenticate might be caused by another computer on the same network using the same name or the password for this computer account is not recognized."
Algumas coisas adicionais a serem observadas:
-Event viewer logs (on on-site DC1 and on-site DC2) under application and services > DFS replication show only information about replication between each other. No mention of replication between the AWS DC's.
- Every hour the on-prem DCs show a DFS error "the dfs replication service is stopping communication with partner {other on-prem DC} for replication group Domain System Volume due to an error. Error 9036.
AWS DC02 only shows error logs regarding DFS replication with on-prem DC02. Same error 9036 "replication service stopping due to an error".
AWS DC01, same thing - only shows logs regarding DFS replication with on-prem DC01. Error 9036 "replication service stopped due to an error".
alguma ideia do que poderia estar acontecendo aqui ou onde procurar a seguir?
Responder1
Os erros sugerem um problema de autenticação, portanto a atualização recente do Kerberos - referenciada por Greg Askew - pode muito bem ser a causa, especialmente se você atualizou recentemente e o problema começou naquele ponto. Se você pensa assim, considere remover essa atualização temporariamente e, quando tudo estiver funcionando novamente, planeje descontinuar os servidores de 2008 o mais rápido possível.
Você poderia tentar esta ferramenta: https://www.microsoft.com/en-us/download/details.aspx?id=30005
Tenho certeza de que já usei outra ferramenta de monitoramento de replicação da MS antes, só não consigo lembrar como ela é chamada agora. Foi uma instalação do MSI, é tudo que me lembro! Talvez fosse apenas o diagnóstico FRS, não o DFRs.
A replicação do AD é altamente dependente do DNS e do tempo sincronizado, portanto, verifique definitivamente toda essa configuração. Você pode comparar tempos com:
net time \\server
Veja se há alguma disparidade - se funciona (ou seja, se não há problema de conexão entre servidores ao executar o comando). Caso contrário, tente sincronizá-los todos a partir da mesma fonte de horário externa, pool.ntp.org, por exemplo.
Para testar o DNS, execute ping em cada servidor fqdn de todos os outros servidores, compare os resultados entre si e com o que você espera. Presumo que você tenha alguma VPN ou roteamento L3 não-nat semelhante entre o local e a AWS. Por exemplo, 192.168.1.10 pode executar ping em 10.0.0.2, ou quaisquer que sejam os IPs 'internos' no local e na AWS (só estou familiarizado com o Azure, então pode não ser o mesmo, perdoe-me se a AWS funcionar de forma diferente de alguma forma).
Você também pode verificar a AWS e o local em sites e serviços do AD, detalhar o NTDS e observar os relacionamentos de replicação. Você pode clicar com o botão direito e replicar, ver se diz (parafraseando) "ok" ou "não consigo" - pode ajudar a diminuir o problema.