I have a Server 2012 R2 machine acting as a domain controller in a test environment.
It had to be restarted, and now, when attempting to log in as the domain administrator, I get the error message: there is a time and/or date difference between the client and server.
I first assumed that the BIOS battery might need to be replaced, so I restarted the computer and checked the date in the BIOS. The date was set to 4/26/2099.
I replaced the battery, set the date, and then tried to log into the server again. I got the same message, so I checked the date in the BIOS again and the date is again set to 4/26/2099.
I tried changing it again, but it keeps getting changed when Windows Server boots. I removed the hard drive and installed windows on another hard drive on this computer and it is keeping the time in the BIOS just fine, but when I put the hard drive with this Server 2012 DC into another computer, it does the same thing. The BIOS date gets set to 4/26/2099 and I am unable to log in.
I can attach the hard drive to a Hyper-V virtual machine and boot from there. I am able to log in with no errors and the date is set correctly.
What could be causing Server 2012 to set the BIOS clock?
Best Answer
Well, that's what it does. Linux does it too, but yes, your OS can and will set the real-time clock to match what it thinks the time is.
Regarding fixing this mess, what you need to do to correct the time on the server is login to the server with a local administrator account, and set the time to the proper time. Since it's a domain controller, you'll need to use the Directory Services Restore Mode to log in when domain authentication isn't working. Setting the clock properly should update the BIOS clock to the proper time, or close enough to allow you to log in with domain credentials.
Having said that, I'm honestly not sure I would. Seems like setting the clock back from such a big differential is likely to mess up the domain (which, in fact, is the very reason there's a maximum offset that will auto-correct in the first place), so I'd probably just treat this as a failed domain controller and purge it from Active Directory appropriately.
You should also consider setting your machines to sync to a reliable NTP time source, so this doesn't happen the next time a CMOS battery goes bad. You can, and should even do it by GPO - set your PDC emulator to sync with an external NTP source, and have all your domain computers sync from it (or sync up your domain controllers to the PDC emulator, and have machines sync from their local domain controller, depending on your network size).