Domain Time off for some members
-
@JaredBusch I think we are agreeing, but not saying the same things.
The host was set to itself as the time source, but was off by at least several hours. But that might have been several hours and 6 minutes, which when it made it all the way down into the VM meant that the hours were corrected, but not the 6 minutes? I don't know and I am grasping at straws here.
Either way, it is now set to NTP time. I still don't understand how windows could switch back and fourth between two time sources in a domain setting, especially considering how much of AD is dependent on good time keeping.
-
@Donahue said in Domain Time off for some members:
@JaredBusch I think we are agreeing, but not saying the same things.
The host was set to itself as the time source, but was off by at least several hours. But that might have been several hours and 6 minutes, which when it made it all the way down into the VM meant that the hours were corrected, but not the 6 minutes? I don't know and I am grasping at straws here.
Either way, it is now set to NTP time. I still don't understand how windows could switch back and fourth between two time sources in a domain setting, especially considering how much of AD is dependent on good time keeping.
Do the logs tell you what source it's changing to match?
-
@Dashrender said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
@JaredBusch I think we are agreeing, but not saying the same things.
The host was set to itself as the time source, but was off by at least several hours. But that might have been several hours and 6 minutes, which when it made it all the way down into the VM meant that the hours were corrected, but not the 6 minutes? I don't know and I am grasping at straws here.
Either way, it is now set to NTP time. I still don't understand how windows could switch back and fourth between two time sources in a domain setting, especially considering how much of AD is dependent on good time keeping.
Do the logs tell you what source it's changing to match?
No, and I can't figure out if I can turn on verbose logging for this event. Maybe there is a better tool than event viewer?
-
@Donahue said in Domain Time off for some members:
@JaredBusch I think we are agreeing, but not saying the same things.
The host was set to itself as the time source, but was off by at least several hours. But that might have been several hours and 6 minutes, which when it made it all the way down into the VM meant that the hours were corrected, but not the 6 minutes? I don't know and I am grasping at straws here.
Either way, it is now set to NTP time. I still don't understand how windows could switch back and fourth between two time sources in a domain setting, especially considering how much of AD is dependent on good time keeping.
We are certianly not saying the same things.
You first side the time was off by hours, but the guest was flipping only 6 minutes.
Then you finally stated that the host timezone was off.
Timezone being not set correctly is only a display issue to the meat sack looking at it.
The UTC time is the UTC time.
Now if the UTC time was no correct by hours that is different. But that is not what you stated.
-
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
@JaredBusch I think we are agreeing, but not saying the same things.
The host was set to itself as the time source, but was off by at least several hours. But that might have been several hours and 6 minutes, which when it made it all the way down into the VM meant that the hours were corrected, but not the 6 minutes? I don't know and I am grasping at straws here.
Either way, it is now set to NTP time. I still don't understand how windows could switch back and fourth between two time sources in a domain setting, especially considering how much of AD is dependent on good time keeping.
We are certianly not saying the same things.
You first side the time was off by hours, but the guest was flipping only 6 minutes.
Then you finally stated that the host timezone was off.
Timezone being not set correctly is only a display issue to the meat sack looking at it.
The UTC time is the UTC time.
Now if the UTC time was no correct by hours that is different. But that is not what you stated.
perhaps you are correct, unfortunately I didnt pay enough attention to know for sure how far off the host time was.
The problem is still occurring however.
-
does anyone know a better tool that I can use to find out what is triggering this to happen?
-
I think I may have found the cause. I looked into event 4616 under the security log. I can see a consistent pattern of three records repeating over and over again. The first thing is that VMWare tools was setting the clock ahead 6 minutes. Then a little later, svchost was setting it back, and then resetting it again. Then a little later VMWare tools would set it ahead again and the pattern repeats.
-
Ah yes, competing time sources.
-
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
-
If your hardware supports it (Dell PE gear with IDRAC for instance) you could have it syncing with an NTP source as well.
-
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
Any mention of a bug in VMWare tools about this?
-
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
-
@Dashrender said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
Any mention of a bug in VMWare tools about this?
Not much https://kb.vmware.com/s/article/1318?srcvmw_so_vex_pgrev_242=
-
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
I didn't think Windows ever did that in a domain environment? I thought it always got it from the PDC emulator.....
-
@Dashrender said in Domain Time off for some members:
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
I didn't think Windows ever did that in a domain environment? I thought it always got it from the PDC emulator.....
In a VM it does get overwritten a lot by the hypervisor Host Clock.
-
@dbeato said in Domain Time off for some members:
@Dashrender said in Domain Time off for some members:
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
I didn't think Windows ever did that in a domain environment? I thought it always got it from the PDC emulator.....
In a VM it does get overwritten a lot by the hypervisor Host Clock.
Why would that be? I ask this especially in the case where the integration software has been specifically set to disable time syncing with the host.
-
@Dashrender said in Domain Time off for some members:
k this especially in the case where the integration software has been specifically set to disable time syncing with the host.
https://blogs.msdn.microsoft.com/virtual_pc_guy/2010/11/19/time-synchronization-in-hyper-v/
-
@JaredBusch said in Domain Time off for some members:
@Donahue said in Domain Time off for some members:
found it. It was the individual time for that ESXi member. It was running on it's own time, neither host time or any NTP. It was off by the 6 minutes. So for some reason, VMWare was syncing this setting with the host's ESXi clock, not the hardware clock, even though the settings disallow that.
How do you know the VMware tools was doing the sync?. As I said in my earlier post if windows goes and tries to get the hardware clock no matter what your tool says for heartbeat or times are pretty station it’s going to get the Clock from the host.
look at the picture I posted above. It was vmtoolsd.exe that was causing it to jump forward and svchost.exe that was correcting it. I found this under event 4616
