two time servers in a network

ITUCIRL
ITUCIRL used Ask the Experts™
on
Hi Experts

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?

Thanks!

Brian
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Systems Engineer
Commented:
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.

link:  http://blogs.technet.com/b/nepapfe/archive/2013/03/01/it-s-simple-time-configuration-in-active-directory.aspx

I would reset the Time Service on the DR DC to the default DC w32time setting.

Reference: https://social.technet.microsoft.com/Forums/windowsserver/en-US/8aeaa277-71a4-4638-96f7-87cd646657a9/time-settings-of-domain-controller

Dan

Dan

Author

Commented:
Thanks Dan

I had actually reset the DR DC (reverted to a VMWare snapshot, so it's back at the default setting.

Would you recommend, in the event of a DR invocation, to then set the DR DC as the PDC?
Or simply write a script to set it as a time server on the domain?

Again, thanks for your advice.
Brian
Dan McFaddenSystems Engineer
Commented:
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.

Dan
Ensure you’re charging the right price for your IT

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden using our free interactive tool and use it to determine the right price for your IT services. Start calculating Now!

Author

Commented:
Thanks so much, Dan

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.

Can you think of any issues with this?

Brian

Commented:
*NO POINTS*

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 discuss this implementation in a previous EE PAQ: http:/Q_28597899.html#a40553961

-saige-
Dan McFaddenSystems Engineer

Commented:
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:

1. move a copy of the current BMR (bare metal restore) backup of the vDCs onto portable media
2. use the vDC backups to restore vDCs in an isolated virtual network instance
2a. no production connectivity
2b. no internet access
3. verify vDCs are functional
4. seize all FSMOs (seizing all FSMOs includes the PDC Emulator role)
5. verify AD functionality
6. in the virtualized DR network...
6a. bring a client OS online (1 for each supported client OS)
6b. bring a new server online (1 for each supported server OS)
7. test basic DR network connectivity

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.

Dan
Dan McFaddenSystems Engineer

Commented:
@it_saige:  thanks for that link!  Just found another item to update in my DR/BCP plan.

Dan

Commented:
Any time Dan.  ;)

-saige-

Author

Commented:
Thanks Dan and Paige!

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!

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial