@scottalanmiller said in Estación de trabajo con 10 segundos de atraso en el reloj: @dbeato said in Estación de trabajo con 10 segundos de atraso en el reloj: @scottalanmiller said in Estación de trabajo con 10 segundos de atraso en el reloj: Anyone know what the normal variance on Windows boxes is when not using a local time source? How close in seconds would we even expect a site to be able to be? You can have it up to 5 minutes from the Domain Controller Servers time. No DCs. No AD. Gotcha, I am still trying to see what is the issue. 10 seconds is almost unnoticeable. What is the purpose?

@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

I would prefer the phones to go out to 0.us.pool.ntp.org and 1.us.pool.ntp.org for all of their time sync issues but they appear to be having some issue. Of which I am unable to determine what that could be with the error provided.

@ccwtech said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @dbeato said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @ccwtech said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @dbeato said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @ccwtech said in Computers not syncing with Domain Controller. Is my GPO blocking it?: Computers in a domain are not syncing time with the Domain Controller (Hyper-V). They are all set to the local CMOS clock. I had to restrict the ability for local users to change time by themselves. Is the GP that I created preventing the computers from syncing to the domain? The time can be in different zones and not affect connectivity to the domain as long as it is 5 minutes from the DC time via UTC. Now I would really make the computers to just point to the DC as their NTP Server instead of anything else. I thought they did by default in a domain. They should but it is not enforced. What do I need to do to enforce it? Or point them to the DC to use? @ccwtech said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @dbeato said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @ccwtech said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @dbeato said in Computers not syncing with Domain Controller. Is my GPO blocking it?: @ccwtech said in Computers not syncing with Domain Controller. Is my GPO blocking it?: Computers in a domain are not syncing time with the Domain Controller (Hyper-V). They are all set to the local CMOS clock. I had to restrict the ability for local users to change time by themselves. Is the GP that I created preventing the computers from syncing to the domain? The time can be in different zones and not affect connectivity to the domain as long as it is 5 minutes from the DC time via UTC. Now I would really make the computers to just point to the DC as their NTP Server instead of anything else. I thought they did by default in a domain. They should but it is not enforced. What do I need to do to enforce it? Or point them to the DC to use? Enforce the time source on the DC https://blogs.technet.microsoft.com/nepapfe/2013/03/01/its-simple-time-configuration-in-active-directory/ For clients look at this one https://www.altaro.com/hyper-v/configuring-time-synchronization-for-all-computers-in-windows-domain/

@gjacobse said in Domain Computers: Clock Sync: DC4 is a virtual machine. changes to it are likely over rode by the Hypervisor or physical hardware that were wrong. By updating the physical hardware, and then running w32tm /resync the time updated. The issue will resurface again as the BIOS is losing time and will be pulled again wrongly on the host. Have you tried not syncing the time of the VM through the Hypervisor and turning of Time Synchronization for this DC?

@jt1001001 said in Unable to get time to sync on Server 2012 R2 DC: are any of your time services running under a domain accoutn instead of Local Service? Sounds like a service does not have permission to update the time Windows Time is set to run under "Local Service" (not local system account)

FreeBSD does have getent.

@frodooftheshire said in XenServer7 time sync DC/PDC emulator: @coliver I configurd XEN to pull time from us.pool.ntp.org, and I guess I'll just go into the primary DC and tell W32time to sync with the same server I'm trying to recall but @JaredBusch has had issues with the US NTP pool. He may be able to comment further. Otherwise this should work fine.

@DustinB3403 said: It's up and working, since I forced a time sync, but I'm curious as to why it fell out in the first place. It happens, NTP is pretty unstable.

@bbiAngie said: @lhatsynot said: @bbiAngie said: Yea that is what I followed and it didn't work. 45 minutes later I realized this is because this is an isolated stack of switches that is not plugged into the domain yet..... Hard to get a time when they cant talk with the ntp server!! facepalm Glad you got it sorted out eventually. You really have to love those moments when you are starting to get really frustrated then 30 seconds later you think "Oh my, I am a f-in idiot." I worry if I don't have at least one of those a day, lol.

I see.

Looks like the issue is with NTP dæmons, not with NTP clients. So in the SMB, very few people would be impacted. Running internal NTP is uncommon until you are relatively large.