two time servers in a network

We have 3 domain controllers in our environment, two in our production site, and one in our DR site. The "primary" domain controller is in our prod environment, and serves as the time server.

As part of DR testing, we break the link between the two sites, and bring up replicated VMs.

When i tried adding client PCs to this DR environment, i noticed that the time was an hour wrong (I think this may have been due to the image being created during Daylight Savings Time, and being deployed after.

Anyway, I got around this by making the DC out there a time server. This worked perfectly. So, what i'm wondering is, can i leave this server as a time server, or will this cause issues with the primary Prod DC when the environments are re-linked?

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

The best practice is to have the DC that holds the domain PDC Emulator Role, to be the DC that syncs its time to an external NTP service. In a multi-domain forest, the server in the root with the PDC Role, should sync to an enternal (off-box) service. Any child-domain PDC Role holders will try to sync up with the root PDC Role holder or a DC in the root domain.

Here is a reference article about the Windows Time Service in a domain.

In the event of a situation that required you to activate your DR plan, I would assume that your DCs in your main datacenter are offline or unavailable on the network. Your first task would be to get onto a DR Domain Controller and seize ownership of all 5 FSMOs in AD. At this point you would reconfigure the server with the PDC Role to be an authoritative Time Server.

The IT Service Excellence Tool Kit has best practices to keep your clients happy and business booming. Inside, you’ll find everything you need to increase client satisfaction and retention, become more competitive, and increase your overall success.

Yes, in the event of an actual invocation, this would be the scenario.

For testing, we do break the link, so the PDC is unavailable, so what i'm thinking i could do is:

1) Break the link
2) Take a snapshot of the DR DC.
3) ensure no connectivity between sites
4) Take ownership of all FSMOs, and then make a PDC
5) post-testing, restore the snapshot taken in 2
6) Re-link the two sites.

To prevent requiring a manual change when you implement your DR and seize the ROLES (or to "future-proof" your existing environment), I would recommend that you create a Group Policy that handles the implementation of the time service for you.

It handles the implementation by only affecting the server that holds the PDCe FSMO role.

I'm not a fan of the breaking of the production network in your process. In steps 5 and 6, you will run the risk of introducing 2 DCs that have been offline for a relatively long time... hours if no days. This can have a negative effect on your AD infrastructure.

I use a somewhat similar process but I use an isolated VM network and the snapshots:

Here there is no net effect of a production network interruption. Any processes that require the DR site (AD replication, SQL Server replication/log shipping, content sync, block level data replication, etc.) to be online continue to function.

When breaking the DR site connectivity, you essentially are breaking your production network since DR is part of that structure.

We've always used this process to test DR. The Prod environment would still have a DC that is the PDC, and will just see the DR DC as being off the air for 2/3 days.

The DR DC is restored back to as it was at the start of the first day of testing, in a powered off state, so after i restore the link between sites, i power it up, so it's just as if it was taken off air.

I do like the sound of minimising manual intervention a lá Paige's solution! Maybe a project for later this year!