VMWare could impact Windows services that depend upon the Windows Time Service for maintaining time synchronization across systems. Apparently the proper way to keep the guest time synced is to use the VMWare TimerSync and not the default Windows Timer Sync. If the system was to become out of sync by more than 5 minutes let’s say then Kerberos could be a problem. This could impact user access or Timer jobs performing tasks. So if a customer has not configured this correctly then there could be problems. The solution however is an easy workaround described below.
* VMware Time Sync and Windows Time Service
http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=1318
“The most accurate way to keep guest operating system time synchronized with real time is to use the VMware Tools time synchronization function. You should not use the Windows Time service or other form of clock synchronization meant for physical machines to set the time in the guest operating system.”
The risk of having the USN Rollback effect.
If the virtual machine is switched off with “Don’t Save Changes”, or the host is turned off in an uncontrolled manner (power failure) …
This DC doesn’t save its latest changes.
But the replication USN numbers were incremented, and all other DCs have already learnt about this on their High Watermark vectors.
The DC has jumped backwards in time (lost the latest USN changes), and Replication Dampening will avoid to re-replicate these lost changes again. (All DCs think it has already got them)
Likely to happen (as “Don’t Save Changes” can be the default), difficult to detect, and more difficult to fix …
How to detect and recover from a USN rollback in Windows Server 2003 http://support.microsoft.com/?id=875495
