Link to home
Start Free TrialLog in
Avatar of luke_brannon
luke_brannonFlag for United States of America

asked on

Disable Automatic Daylight Savings across entire domain (GPO)

We run a server application that has undesirable results when using the option in Windows that automatically adjusts time based on daylight savings rules. The only problem is that the server must do a time sync with the domain because of the critical role time plays in domain operations, so I can't just disable daylight savings on this one server because when it syncs it will always be incorrect by one hour.

This server application is important enough that I would like to disable daylight savings in the entire domain. So far, I've tried to push out a GPO that modifies the following registry entries:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\DisableAutoDaylightTimeSet (set value to 1)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\DynamicDaylightTimeDisabled (set value to 1)

I've verified that the GPO is being applied through gpresult, and I checked to make sure that the registry entries are being successfully modified, and they ARE. I've tried applying these registry keys one at a time, and together. This is not effectively disabling the option, though.

All of my servers are Windows Server 2008 R2, and my client test machine is Windows 7 Ultimate x86.

I would really like to disable daylight savings, and remove the option from Windows. I will definitely settle on just disabling DST, though.

I've attached a screenshot of the GPO on the server and a screenshot of my test client PC's registry.

Has anyone implemented this in their domain? Any suggestions on what I can try next?
Avatar of kevinhsieh
Flag of United States of America image

Why don't you just deselect the DST adjustment on the server? Windows time is distributed and stored as UTC, which is independent of the time zone. The time zone and DST information is for display purposes. Most Windows events and such use UTC for storage, though some things may record "time". I have some servers running an application that requires setting the timezone to GMT (effectively UTC), so those servers are at UTC, and the rest of my servers in the datacenter run on PST/PDT without any issues. Time sync and domain operations are fine. The only issue if for the people when we look at events on the GMT servers, and we need to "translate" the recorded time to local time.
Avatar of luke_brannon


That is basically what I am doing right now. The server is set for Eastern Time Zone with Daylight Savings off. The client PC is by default set as Eastern with DST on, and it's one hour fast. I think your approach would probably work with a time zone issue, but not with DST.
Is the clock on the server displaying the "correct" time? It should not. It should be 1 hour behind, because it should show EST, not EDT. Is the server a domain controller? Are there other domain controllers? The domain controller with the PDC emulator FMSO role should get time from an external timesource, such as the Internet. Everything else in the domain will get correct UTC time from that, and then will adjust the display bases upon the timezone and DST settings.

My guess is that your server has the PDC emulator role, and that you set it so that the time it displays is what matches your watch, but everything is in fact wrong because the time displayed doesn't match the actual time for the timezone. The PCs are then getting their time from the server, but since the time on the server is 1 hour off, they are displaying time 1 hour off as well.
Here's a bit more information for you:

The software that requires daylight savings to be turned off is server software for radio station automation. The radio automation server is connected to our business network on one NIC (10.0.0.x) and the automation network on another NIC (10.10.10.x).

We only have one domain controller. This domain controller actually receives its time from the radio automation server (the radio automation server is connected to a piece of hardware that does a time sync with ABC Radio Networks). So, the radio automation server is essentially providing time for the entire domain. The time sync chain looks like this:  Radio Automation Server--->Domain Controller--->Domain Computers.

Here's the issue: I can't set an "incorrect" time on the radio automation server. Whatever I set on this server is exactly what is pushed to our radio station automation machines. If the server says its 1:00pm, that's exactly what the radio automation machines will say. They don't use windows for time syncing; they do all of the time syncing through the radio automation software.

That is why it seemed that just disabling DST would be the easiest way to fix all of this.

This is a horribly frustrating mess.
In reality it should be showing the UTC time not the local time. I work with RBFS and Cesium Beam FS on a daily basis, where I work if the clock is off by 1/100th of a second it is useless.  The radio automation server should be converting from UTC to local time. Unfortunately a broadcast that originates in the Pacific Time Zone and is broadcast from Eastern Time Zone, the time will have advanced 1 hour in the Eastern Time Zone 3 hours before all of the time zones time differences are synced. Radio programming should be based on UTC and not local time.

Microsoft time is always in UTC the displayed time is simply an offset from UTC.
Ok, so what settings should I set on my automation server and domain controller? Right now they are all set to Eastern Time Zone with DST disabled. I guess I'm just a bit confused on the exact settings you are suggesting.

EDIT: I tried setting both server time zones to UTC, but unless I disable DST on my domain computers, they are still incorrect by one hour when they sync.
Avatar of Imran Saeed
Imran Saeed
Flag of Malaysia image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
The software that requires daylight savings to be turned off is server software for radio station automation.

We are a TV Station, NBC Affiliate. We also run automation, our case,...from NVersion.  The solution is already provided by the automation vendor.

1. They include a physical Timesync card in at least one of the devices/machines.  The rest of the involved devices (also from NVersion) sync their time to the machine with the Time Card.  In our old previous automation they just put a card in every machine.   The Time Cards are physically attached to a GPS "House Clock" via a physical cable.

2.  Do Not (let me say it again,...Do Not,...) make any of the automation machines a Domain Member.  They need to live in their "own little world".

Now if you are a TV News Station the story gets worse.  Our Newsroom Control System is time critical as well since it controls and "times" the live news broadcasts and feeds the Teleprompter.  The main servers for that are Linux so Active Directory is irrelavant but the workstations must be Domain Members and the Producer's machine is where the show is timed.  So I did two things:

1. Sync the DCs time to the same Device used by the NVersion Automation,...this is done through Windows functionality,..not a Time Card,...more on that below.  That gets it "close" but Windows Time syncing can still be off by a few minutes because so many of the "syncs" will fail, allowing the clock to drift.  Then I put a Time Card in the Producer's workstation to locked it to the House Clock,...since the DCs and the workstation are always within a few minutes of each other everything keeps working (Active Directory doesn't require it to be exact,...close is "good enough")

2. Do not put Time Cards in the DCs (I already tried that).  The software for the Cards will disable the Windows Time Service which disabled the PDC FSMO Role causing the DC's to believe that the DC with the PDC Role is missing.  The make matters worse the DST change is already applied in the House Clock,...but it is also applied in Windows, the last DST change cause my DCs to jump two hours ahead instead of one hour. This put them out of sync with all the Domain Members by one hour which caused all time syncing to fail across the whole system.  In the process of trying to reconfigure the Time Cards to correct that, one DC lost the Time Data and caused it to jump the clock to January 1, 1980.  This caused the Exchange Server to blow its brains out and the Exchange Database went into "Dirty Shutdown".  The only solution ended up being to yank out the Time Cards,..get the PDC Role working again,...and a $250 support call to Microsoft to get the Exchange back up.

Removing the DST Setting was not a solution.  When DST happens the House Clock would jump the DCS ahead or back an hour,...but that then puts them one hour off from all the members (because they don't have Time Cards) and when the time is that far off the members just stop syncing  time with the DCs.  So you either have to put Time Cards in every machine in the building (impossible because the House Clock can't handle that many) or you have to manually run around the building and and change the time on all the machine so they match the DC "new" time and syncing will start working again.
Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
BTW, do you use Outlook? If you do, calendar items with any system not on your exact same DST offset will display wrong. For example, if someone out of the organization sends you an invite for something during DST, you will see the wrong time in Outlook. Calendar events synced between Outlook and Android/iPhone/BlackBerry would display a 1 hour difference for anything during DST. Be prepared for some weirdness with your other systems.

I just couldn't get everything to work the way you were suggesting. If you could provide some more exact detail on how I need to do this, I may be able to set it up the way you were discussing. I'd really love to do it the way you suggested, I am just at a loss when it comes down to really implementing it.
One other solution led me in the right direction, but I had to do more research to come up with a final, working solution.