NTP GPO - Workstations Not Listening

[Madman_Lorenzo]

Hello everyone,

 

Have a strange issue here which has worked at another school perfectly. Just doesn't seem to work out here and trying to figure out why.

 

These are the only settings applied in the policy:

 

Didn't seem to horrid a prospect for workstations to check in with that pool every hour. But nothing is and times are still wacky. RSOP shows workstations "get" it, they just don't "pay attention" kinda!

 

The only clue I have is if I look to a workstation that should get this setting, I see the Time server (in Date and Time) as one of our local DCs. I would HOPE though that this DC would "take" the policy (it is applied at the very top level.)

 

Not sure where else to check for mischief and non-compliance, anyone have any hints or good ideas on where to start looking?

 

Thanks much everybody.

Edited June 23, 2022 by Madman_Lorenzo

[MatthewL]

Firstly your clients should be communicating with for example your DC as the time source and then the DC communicating externally.

 

It may not work as the NTP protocol may be blocked outbound on the firewall so I would look at that.

[jthompson]

Leave your clients to sync their clock to a DC. If you have more than one DC, have one sync with an Internet NTP source. The other DC(s) just syncs with the first. If your DC is a VM, it might be getting its clock governed by the host. I know that in Hyper-V you can elect to not have the guest clock governed by the host, to avoid having any clock drift on the host end up right across your domain.

[Madman_Lorenzo]

Thanks much everyone. Ok I think I'm getting there on the principles of it, but I'm still lost as to what we're doing here. Un-picking things here we have inherited, and it looks like a LOT of options have been "explored" in the past.

 

Firstly, just to try and get an easy* option, can I set a top-level policy to just have all clients look to the Smoothwall box to be NTP server? If anyone's done that, are the settings any different to the below?

 

 

Having of course configured the options in Smoothie to be NTP server, and make it available on the LAN, which I *think* I've done right here:

 

 

I think this should work, however I'm worried (or rather I just don't know) if then any current DCs will just "take" this setting and not be trying to argue with each other/with the Smoothwall box over who is rightful NTP server and send everything bonkers.

 

(Also did specifically check none of the DCs, all being VMs, are getting any time settings form the hosts they've all got that option un-ticked.)

 

Thanks everyone helping me through this!

Edited June 24, 2022 by Madman_Lorenzo

[Madman_Lorenzo]

Ok, having read around this does look to be a little more complex than I thought, but I may just have a grasp on it. Please put me right if not though!

 

So, in principle, I think you just need to let the AD defaults do the work rather than try and batter the domain and all servers/workstations into submission.

 

AD wants to get members to look to the PDC to be NTP server. Group Policy (weapon of choice to deploy these settings) will need one policy for the PDC and another policy for everything that's not the PDC. PDC of course gets setting to look to and sync with NTP servers out there in the world, everything else looks to the PDC. Setting the WMI filter as follows means you'll be applying the policy to the single PDC which will be Big Ben for the network:

 

SELECT * FROM Win32_ComputerSystem WHERE DomainRole = 5

 

And for all the rest of the domain members, we'll need a second WMI filter to NOT catch the PDC but catch everything else, and this'll be:

 

SELECT * FROM Win32_ComputerSystem WHERE DomainRole <> 5

 

Of course, if your AD is structured in such a way that you wouldn't have clients and non-PDC servers hitting each other then you'd technically not need those I guess.

 

I should IMAGINE from then on I set the NTP server to be the LAN NIC of my Smoothwall box. The rest of the settings I think I can work out, primarily nicked the info from the two following pages:

 

https://kimconnect.com/set-ntp-on-primary-domain-controller/

 

https://kimconnect.com/gpo-to-set-ntp-on-domain-joined-computers-and-servers/

 

Sounding sane-er?

 

Thanks again everyone.

[Koldov]

Might be overcomplicating things...?

 

You need to find out what the current situation is with the DCs and the clients (I believe domain clients and other DCs just get their time natively without any other setting changes needed once the advertising authority DC is set - PDC Emulator/FMSO - by default).

 

Run from CMD

 

w32tm /query /source

 

or

 

w32tm /query /peers

 

On everything to find out where they're getting their time from.

 

Check your DCs for the settings (GPO):

 

Computer Configuration > Policies > Administrative Templates > System > Windows Time Service

 

or Regedit for:

 

HKEY_LOCAL_MACHINE\SYSTEM\ControlSet\Services \W32Time\...

 

Especially the Key

 

...TimeProviders\NtpServer\Enabled 1

 

I did mine many years ago through the registry on the main DC as that was the first 'How To' guide I found (and I wasn't confident with GPO).

 

Make sure it isn't hitting the firewall.

 

EDIT: Sorry, just seen your last post...

Edited June 24, 2022 by Koldov

[jthompson]

IME, best to let the Windows domain get on with managing itself for the most part. I've found this blogpost helpful in the past. I should think you can get away without needing to use any GPO for this at all, and just manually configuring the Internet time source on DC that has the PDC role.

 

https://blogs.msmvps.com/acefekay/2014/04/26/configuring-the-windows-time-service/

[Madman_Lorenzo]

IME, best to let the Windows domain get on with managing itself for the most part. I've found this blogpost helpful in the past. I should think you can get away without needing to use any GPO for this at all, and just manually configuring the Internet time source on DC that has the PDC role.

 

https://blogs.msmvps.com/acefekay/2014/04/26/configuring-the-windows-time-service/

 

Thanks for that. I'll admit I checked it out and it confused me slightly more than before.

 

Ok the principle I'm taking away from this is that if and so long as the PDC has the correct time if no other setting at all is set in Group Policy then all clients should eventually get the correct time. From the clock on the PDC. Hopefully that part is at least correct. I haven't worked to this principle currently but at least if this one fundamental thing is right then I can start somewhere.

 

Second thing I'm trying to do is set my Smoothie box as NTP server, with the IP of the local LAN interface being the IP I should imagine we'd set as the NTP server address in any policies we'd be writing. With that in mind I'd assume the following would be ok, but which currently doesn't seem to work:

 

WMI Filter on this one to apply to PDC only:

(blanked out internal NIC IP of Smoothie)

 

"Enable Windows NTP Client policy" set to "enabled" and "Enable Windows NTP Server" also enabled.

 

 

WMI filter on this one to apply to non-PDCs only:

 

"Enable Windows NTP Client policy" set to "enabled" and "Enable Windows NTP Server" also enabled here too.

 

 

Time now 2 mins out on the PDC vs clients, running gpupdate /force on clients doesn't bring time into line, w32tm /resync /rediscover on clients gives an error "The computer did not resync because no time data was available" and I'm starting to get a little lost now.

 

Thanks any/everyone for sticking with me on this.

Edited June 24, 2022 by Madman_Lorenzo

[jthompson]

Check the output of

w32tm /query /source

on clients and DC's. Clients should all show a DC, DC's that aren't PDC should show the PDC, and PDC should show an external source (e.g. time.windows.com).

 

The following command will also show the time difference to some external source. In this example, it's time.windows.com.

w32tm /stripchart /computer:time.windows.com /samples:3 /dataonly

 

Restarting the Windows Time service on a client should be enough to start it syncing with whatever it's source is. Note that it won't necessarily correct instantly in one go. For larger, munites-long differences, the clock will adjust in a series of progressively smaller jumps over a period.

 

From what I remember of that article, you should be able to achieve what you're after just by using w32tm commands, without needing any Group Policy at all.

 

If your DC(s) are virtualised, you may want to disable any host clock sync in the VM settings. In Hyper-V, at least, that'll ride roughshod over DC's w32tm sources, such that the Hyper-V host will be setting the DC's clock regardless, and then everything else syncing from that. By disabling that clock sync between host and VM, the DC is free to have it's time set from an NTP source.

[Madman_Lorenzo]

You folks have all been wonderful thanks much for the help.

 

Got in this morning to all clients and servers HAPPILY on BST, time perfect across the domain to the second.

 

Delighted, cheers lots.

[aac]

If you notice any further issues after leaving it for a while look into secure time which was a new feature in Windows 10 caused us issues a couple of years back with machines randomly being exactly 2 days behind...

[KK20]

It is also good to read up on how a client corrects its time. It doesnt just instantly change, it does it in increments. This is important if you have laptops with iffy batteries.