No meu caso, meu host ainda está sob o controle do vCenter de produção, e não sozinho ou como membro de um datacenter diferente do vCenter. Isso fez com que o vCenter estivesse distribuindo MACs diferentes para as VMs
Temos um servidor VMware ESX 5.5 separado que usamos como ambiente de teste, onde replicamos máquinas de produção. Ele executa VMs replicadas em um vSwitch que é fisicamente separado da rede de produção. No mês passado, usamos o Veeam para copiar as VMs para o servidor e simular a produção, com o objetivo de atualizar o AD de 2008R2 para 2012R2. Isso funcionou muito bem e, por isso, atualizamos a produção com o mínimo de problemas. Eu devo dizer que no mês passado, este ambiente de teste não tinha acesso à internet, então o teste foi imperfeito dessa maneira menor, mas nos serviu bem de qualquer maneira.
Este mês, introduzimos uma conexão à Internet em uma linha de modem a cabo completamente separada para a vLan de simulação no servidor ESX de teste, para que pudéssemos fazer mais testes (para a atualização de um aplicativo que usa serviços IIS e SQL) ver conectividade real de clientes que vêm através da Internet. Então, eu repliquei servidores lidando com DC's, DNS, Serviços de Certificados, IIS e SQL e até mesmo com a Diretiva de Rede, embora eu não ache que isso aconteça aqui. A conexão com a Internet funciona, mas agora vejo que por cerca de uma hora ou mais depois de replicar as VMs da produção, a localização da rede muda de lss.local para Public. Além disso, em momento algum o servidor IIS de teste é capaz de exibir um site, e vejo que as relações de confiança de domínio estão quebradas e a recriação falha sempre. O Reconhecimento de local de rede define os locais em Público e os define manualmente (via política local) como Particular. Eles podem consultar o DNS com sucesso, e estou bastante frustrado quanto ao motivo pelo qual a introdução de uma conexão com a Internet quebraria todos os NLAs e todos os canais seguros, onde ele não se comportaria assim quando a Internet não tivesse presença. Enquanto isso, os servidores em produção continuam felizes, então não me preocupo com a contaminação cruzada.
Portanto, em resumo, todos esses problemas surgem agora da presença de uma nova rota on-line OU da replicação de um domínio AD 2012R2 recém-atualizado. Eu suspeito que o NLA tem uma mão no problema aqui. Onde você começaria a procurar identificar a causa da mudança na localização da rede?
No meu caso, meu host ainda está sob o controle do vCenter de produção, e não sozinho ou como membro de um datacenter diferente do vCenter. Isso fez com que o vCenter estivesse distribuindo MACs diferentes para as VMs