asked on
two time servers in a network
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
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
Windows Server 2008Windows NetworkingNetworking
Last Comment
ITUCIRL
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
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
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
*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-
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-
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
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
@it_saige: thanks for that link! Just found another item to update in my DR/BCP plan.
Dan
Dan
Any time Dan. ;)
-saige-
-saige-
ASKER
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!
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!
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