I have found myself in an odd situation.
I have a development network of 15 Windows 2012 R2 servers on a HyperV virtualisation server. There are two AD controllers for the single domain, and 13 servers linked to the domain. This set up had worked perfectly fine for months.
Recently I moved home and the virtualisation server ended up being off for a prolonged period of time (a month).
Since I have fired the virtualisation server back up, I have had nothing but issues - the main one of which is that the non-domain-controller servers are not updating their domain administrator account password from the AD controllers.
I have changed the password (several times now) on the AD controllers but none of the non-domain-controllers reflect this update - they continue to use the domain administrator password from before the virtualisation server was turned off.
It has now been a week since I last changed the password on the AD controllers, a sync should definitely have happened by now.
All servers have static IP allocations from the network DHCP server (non-AD based). All servers can ping each other and the AD controllers, all servers can RDP to each other and the AD controllers. In all real terms, the network connection and virtual network is all working.
Can anyone shed any light? Is there anything I can do to force a sync?
So, I have resolved this after coming to so many blanks.
It turns out that there was an external change that I was not aware of - the house move coincided with a new internet connection and thus a new router. The new router seems to be providing IPv6 details via DHCP even though IPv6 is disabled in its DHCP settings.
Even though each and every server was configured correctly with IPv4 IP addresses and had proper IPv4 DNS settings for the AD controllers, they were defaulting to the provided IPv6 DNS settings and ignoring the IPv4 DNS settings - this put them out of contact with the AD controllers.
Disabling IPv6 on the affected servers immediately caused each server to pop up a "Windows needs your updated credentials, please lock this session and log in with your latest credentials" dialog, and the server does indeed now have the latest AD administrator credentials available and rejects the old credentials.
Job done. Remember folks, watch out for third party systems which are not doing what they suggest they are doing. IPv6 coming into play on the network was the issue here, without any suggestion that that was the issue.