Windows NTP

Mishra

I decided to try and understand Windows NTP a little more last week. I did succeed in increasing my knowledge, but found a lot of bumps along the way.

I blogged about it here. Cale Pantke

Take a look toward the end of the article for the unsolved questions.

I can't get the article to copy/paste so you will have to go to the site.

cjthedj45

Mishra wrote: »

I decided to try and understand Windows NTP a little more last week. I did succeed in increasing my knowledge, but found a lot of bumps along the way.

I blogged about it here. Cale Pantke

Take a look toward the end of the article for the unsolved questions.

I can't get the article to copy/paste so you will have to go to the site.

Hi Mishra,

I had to set up NTP in my company a few months ago using the cisco core routers as the primary time source on the network and everything synching back to them. It was a bit of headache to set up and your article would have been useful back then. In the end it turned out to be a group policy setting that was preventing the Domain controllers synching with the cores. The artice is good for a quick overveiw though.

Mishra

cjthedj45 wrote: »

Hi Mishra,

I had to set up NTP in my company a few months ago using the cisco core routers as the primary time source on the network and everything synching back to them. It was a bit of headache to set up and your article would have been useful back then. In the end it turned out to be a group policy setting that was preventing the Domain controllers synching with the cores. The artice is good for a quick overveiw though.

Cool, I'm glad it did something for you.

I want to call Microsoft and ask them questions about these phantom answers.

Devilsbane

Mishra wrote: »

I want to call Microsoft and ask them questions about these phantom answers.

You can never get an answer from Microsoft, just transferred.

tiersten

Devilsbane wrote: »

You can never get an answer from Microsoft, just transferred.

Depends on what level your service contract is with Microsoft. They've done special hotfixes for us before.

Mishra

Devilsbane wrote: »

You can never get an answer from Microsoft, just transferred.

I've had good experiences for their one time paid support with Microsoft.

Claymoore

You need to dig deeper into the AD FSMO roles and understand the services provided by the PDC emulator. One of these services is time synchronization, which means the DC holding the PDC emulator role is your master time server. The DCs will sync with the PDC emulator, and the rest of the computers will synchronize to a DC when they authenticate. AD relies on kerberos for authentication and kerberos tickets use the system time when calculating their hashes, so if the sytem time is off too far (I think it can be off by 10 minutes by default, but you can configure the value) then kerberos and AD will not work. The time does not have to match the rest of the world, it just has to be the same within the domain. Windows will use time.microsoft.com as an external time source by default, so your PDC emulator DC will sync with Microsoft's public time server, your other DCs will sync with the PDC, and your workstations will sync with the DC. There is nothing else you need to configure.

You only need to start messing with time server commands if you are trying to synchronize clocks that are not in a domain. You can also configure other devices - such as routers or alternative operating systems - to synchronize to the PDC emulator by using that DC as the NTP server in those configurations. The only other time you would need to change the Windows time server is if you move the PDC emulator role to another DC.

Introduction to Administering the Windows Time Service: Windows Time Service

Devilsbane

@claymoore With the default configuration it is 5 minute time difference for Kerberos authentication, but otherwise your post looks great. Don't know why I didn't remember this, just took an AD class last semester.

@Mishra By default, your Forest root domain controller (the first one installed) will have all of your FSMO roles. It would only change if you manually transferred the role to a different DC.

Mishra

Claymoore wrote: »

You need to dig deeper into the AD FSMO roles and understand the services provided by the PDC emulator. One of these services is time synchronization, which means the DC holding the PDC emulator role is your master time server. The DCs will sync with the PDC emulator, and the rest of the computers will synchronize to a DC when they authenticate. AD relies on kerberos for authentication and kerberos tickets use the system time when calculating their hashes, so if the sytem time is off too far (I think it can be off by 10 minutes by default, but you can configure the value) then kerberos and AD will not work. The time does not have to match the rest of the world, it just has to be the same within the domain. Windows will use time.microsoft.com as an external time source by default, so your PDC emulator DC will sync with Microsoft's public time server, your other DCs will sync with the PDC, and your workstations will sync with the DC. There is nothing else you need to configure.

You only need to start messing with time server commands if you are trying to synchronize clocks that are not in a domain. You can also configure other devices - such as routers or alternative operating systems - to synchronize to the PDC emulator by using that DC as the NTP server in those configurations. The only other time you would need to change the Windows time server is if you move the PDC emulator role to another DC.

Introduction to Administering the Windows Time Service: Windows Time Service

Yeah, I documented most of what you said in my blog post.

The post was because in my environment, we have changed our AD controllers to talk to another time source. And actually digging into the time services of Windows has proven to be a hassle to understand. Some of the questions I had are reported in the bottom of my blog post.

Claymoore

Then I'll answer the rest of your questions.

1. You are correct when you state Group Policy settings (represented locally in the \Policies registry key) take precedence over whatever is set in the other registry keys. Group Policy wouldn't have much use as a management tool if it didn't.
2. W32tm and Net Time do the same thing, but Net Time is an old command whose functionality has been replaced by W32tm. Use W32tm if you are using an OS written in the last 10 years.
3. Some group policy settings are refreshed in the background while others can only be refreshed in the foreground - either when the computer is restarted or the user logs on. Time settings are probably a foreground refresh, so somebody can change something temporarily only to have it change when the computer reboots.
4. A Windows 2008 domain works the same as a 2003 domain. The PDC emulator is still the master time server.

I disagree with your opinion that the time service was horribly coded. It works perfectly right out of the box. Because you didn't completely understand the time hierarchy before you started running W32tm commands throughout your domain doesn't mean Microsoft doesn't know how to code a time service. If you understood how Windows synchronizes time in a domain you would have known that you only need to configure a root time server on the PDC emulator (if time.windows.com wasn't good enough for you) and the rest of the domain would have converged on its own.

Mishra

Then I'll answer the rest of your questions.

1. You are correct when you state Group Policy settings (represented locally in the \Policies registry key) take precedence over whatever is set in the other registry keys. Group Policy wouldn't have much use as a management tool if it didn't.

Why use multiple registry keys for 1 function. There should be one place where you set your NTP server, and the CLI functions should represent that setting. If I push a time server through group policy, I should be able to use whatever CLI command to see that server has changed. Putting them in multiple places is bad coding. +1 for opinion of bad coding.

1. W32tm and Net Time do the same thing, but Net Time is an old command whose functionality has been replaced by W32tm. Use W32tm if you are using an OS written in the last 10 years.

They don't do the same thing. Net Time works the SNTP protocol that was used in the past, w32tm works NTP that was recently put in 2003. You can have both configured at the same time. If I set SNTP through net time, nothing changes on the w32tm side. Which means there are 2 different ways to manage time... They should have removed net time, and used w32tm for program both protocols since there is still a need for SNTP (look up Clockwatch). +2 for bad coding

1. Some group policy settings are refreshed in the background while others can only be refreshed in the foreground - either when the computer is restarted or the user logs on. Time settings are probably a foreground refresh, so somebody can change something temporarily only to have it change when the computer reboots.

I'm not sure what this addressed.

1. A Windows 2008 domain works the same as a 2003 domain. The PDC emulator is still the master time server.

In my post, doing it on 2008 was just a reminder for me. I wanted to check to see if net time was still available and other things.

I disagree with your opinion that the time service was horribly coded. It works perfectly right out of the box. Because you didn't completely understand the time hierarchy before you started running W32tm commands throughout your domain doesn't mean Microsoft doesn't know how to code a time service. If you understood how Windows synchronizes time in a domain you would have known that you only need to configure a root time server on the PDC emulator (if time.windows.com wasn't good enough for you) and the rest of the domain would have converged on its own.

There was also the registry key/multiple protocol issue that I found (+3). Also, a multi-homed domain controller acts incorrectly at times with NTP and there are no commands that seem to be able to change which interface NTP talks through (+4). Why I believe it is coded wrong is because they added NTP without correctly cleaning out SNTP which made for very confusing commands/registry keys.

And when have I ever made it seem like I don't understand time hierarchy. Our environment uses GPS's to record it's time throughout the domain because it doesn't have a connection to the internet. Both domain controllers are configured so there is not a single point of failure. So even in an environment that has internet access, I would still want all of my domain controllers configured the same instead of having just the PDC emulator being the only server that propagates time.

Claymoore

Why use multiple registry keys for 1 function. There should be one place where you set your NTP server, and the CLI functions should represent that setting. If I push a time server through group policy, I should be able to use whatever CLI command to see that server has changed. Putting them in multiple places is bad coding. +1 for opinion of bad coding.

Group Policy writes to separate keys for a reason. I doubt you have had the pleasure of working with System Policies in the NT days, but those wrote to the registry directly. If you configured a setting and then later disabled it, the value would remain in the registry. This tattooing of the registry was a major source of headaches, but at least you only had one system policy to deal with. Group Policies could have multiple settings at different layers so there needed to be a way to reliably enable, disable, or otherwise configure settings and - equally important - undo those settings when the group policy changed. Thus the /Policies key was born to represent the registry settings from the resultant set of policies. GP Preferences do write to the registry directly instead of the /Policies key, but for a different reason and with different ways to manage the settings.


They don't do the same thing. Net Time works the SNTP protocol that was used in the past, w32tm works NTP that was recently put in 2003. You can have both configured at the same time. If I set SNTP through net time, nothing changes on the w32tm side. Which means there are 2 different ways to manage time... They should have removed net time, and used w32tm for program both protocols since there is still a need for SNTP (look up Clockwatch). +2 for bad coding

Microsoft introduced new commands and new functionality with a new version of Windows - a disturbing trend that continues to this day. Worse yet, they allowed for backwards compatibility so old scripts could continue to function. We should start writing angry letters.

I'm not sure what this addressed.

You stated that people changed settings only to have them revert back because of group policy.

In my post, doing it on 2008 was just a reminder for me. I wanted to check to see if net time was still available and other things.

Well, there you go. Cross that one off the list.

There was also the registry key/multiple protocol issue that I found (+3). Also, a multi-homed domain controller acts incorrectly at times with NTP and there are no commands that seem to be able to change which interface NTP talks through (+4). Why I believe it is coded wrong is because they added NTP without correctly cleaning out SNTP which made for very confusing commands/registry keys.

Multiple registry keys noted above. Multi-homed DCs present other challenges, and I don't really want to know why you are multi-homing your DCs.

And when have I ever made it seem like I don't understand time hierarchy. Our environment uses GPS's to record it's time throughout the domain because it doesn't have a connection to the internet. Both domain controllers are configured so there is not a single point of failure. So even in an environment that has internet access, I would still want all of my domain controllers configured the same instead of having just the PDC emulator being the only server that propagates time.

You're the one that said you had questions. If you had done a little research on your own you would have answered them. I didn't tell you any secrets, all this information is available in technet.

The PDC Emulator is an FSMO role, and the S stands for Single. All the FSMO roles represent single points of failure. You need to understand the FSMO roles to know how to identify, plan for, and recover from those failures. If your PDC Emulator goes down, time drift won't likely be the first thing you notice.

Did you configure both DCs to the same time source and create another single point of failure? If you used separate time sources, what happens if they don't agree? What if one can't be contacted? The time stamps in AD replication notices are far more sensitive than kerberos tickets. Set the time source on the PDC Emulator and let Windows take care of the rest. It doesn't even matter if the time is synchronized to the rest of the world (although your users will appreciate it), it just has to be the same within the domain.

Configuring each DC separately may work in your little network, but that would wreak havok in a domain with hundreds of DCs and tens of thousands of workstations. Meanwhile, the out-of-the-box settings would handle that environment flawlessly.

Mishra

"If you had done a little research on your own you would have answered them."

I did do the research and I well understand FSMO roles. If you still don't understand that then this conversation is going no where. Thanks for the debate.

tiersten

Mishra wrote: »

They don't do the same thing. Net Time works the SNTP protocol that was used in the past, w32tm works NTP that was recently put in 2003. You can have both configured at the same time. If I set SNTP through net time, nothing changes on the w32tm side. Which means there are 2 different ways to manage time... They should have removed net time, and used w32tm for program both protocols since there is still a need for SNTP (look up Clockwatch). +2 for bad coding

Altering or removing APIs or interfaces without warning especially when they're likely to be used in an enterprise environment will get you lynched. If you have to do so then it has to be for an extremely good reason with no other recourse.

Backwards compatibility is a big thing. You can't turn around and just tell people that no, you're going to have to rework your legacy applications or scripts because we've decided that we don't want this API or interface any more. People will complain loudly and they won't accept the fact that Microsoft did the change to make the code cleaner. They'll just see that Windows 2015 totally broke their barcode generator software from the developer that emigrated to the south pole along with the source that they've been using with no problems at all for the last 20 years. Windows 2015 sucks! I'm staying with Windows 95!

Microsoft have removed functionality like Win16 support on 64 bit systems but if it really is the essential for you to run dinosaur 16 bit apps then you'll have to accept the fact you're stuck with 32 bit Windows.

Read The Old New Thing blog if you're interested in this sort of thing.

Mishra

tiersten wrote: »

Altering or removing APIs or interfaces without warning especially when they're likely to be used in an enterprise environment will get you lynched. If you have to do so then it has to be for an extremely good reason with no other recourse.

Backwards compatibility is a big thing. You can't turn around and just tell people that no, you're going to have to rework your legacy applications or scripts because we've decided that we don't want this API or interface any more. People will complain loudly and they won't accept the fact that Microsoft did the change to make the code cleaner. They'll just see that Windows 2015 totally broke their barcode generator software from the developer that emigrated to the south pole along with the source that they've been using with no problems at all for the last 20 years. Windows 2015 sucks! I'm staying with Windows 95!

Microsoft have removed functionality like Win16 support on 64 bit systems but if it really is the essential for you to run dinosaur 16 bit apps then you'll have to accept the fact you're stuck with 32 bit Windows.

Read The Old New Thing blog if you're interested in this sort of thing.

Yeah I can definitely agree sometimes with that.

I still believe that other decisions could be made. One is of course to just take the entire protocol/application out of there and announce that it changes in a new operating system. It has been done before just like how they took out ntbackup, msconfig (2000), MS-CHAPv1 and IPX.

Another option, in this scenario, would be to wrap both SNTP and NTP into the w32tm command. And just use net time as an alias for a w32tm command. That way you retain all of the CLI structure but remove the confusion. Which is really what I was referring to in my article. I didn't expect them to remove SNTP but simply clean it up to make it less confusing.

I'm just one that likes to think of better options. I'm an outside the box kind of guy.