limited access to DR domain controller

May 8, 2009 at 06:15:31
Specs: Windows XP
our server team is building a DR domain controller in our DR enviroment ... the DR network is pretty much isolated from production network. the problem is , the server team will build the exactly same DC in DR with different IP address . my worry is , if in case there is a network connection between the 2 area, the DR dc will communicate with production DC and this will break the production DC and in turn the whole network.
to avoid this i want to make very tight rules in our DR switch . i already have ACL's , please can someone suggest how can i make more strict rules in the switch , so the DR DC cannot communicate to the production DC ever.


See More: limited access to DR domain controller

Report •

May 8, 2009 at 08:06:06
Have you already built redundancy into your present production network? You only mention one DC which indicates you have not.

Have you tried testing a rollover to the DR network? If you brought this DC up on its own with same name, etc it will not work. Your production pcs don't have a trust relationship with the DR DC.

The switch config is the least of your concerns though if you can do vlans that is all you need to do to keep them separate. Each on its own vlan with no common vlan port inbetween.

Report •

May 8, 2009 at 08:17:16
the DR DC is isolated and we are in the initial state of testing with few users and servers within the DR evironment.
our production network does have redundant DC's.

our server team keeps mentioning that the DR DC should not communicate with the production DC. and as per them the only way is to block it between the switch. the DR and prod DC is in different vlan but they can route to each other.

Report •

May 8, 2009 at 08:38:56
If your DR network is indeed isolated from your production network, then you have no worries about the two communicating...........right!?!?

the DR and prod DC is in different vlan but they can route to each other.

So kill that route and you have no worries about the two communicating.

Just an observation for future reference, if you can take the time to capitalize DR, how about using proper capitalization on your sentences. It makes what you're typing SO much easier to read and it just plain old looks professional. Typing without proper punctuation and grammar looks so unprofessional...

Report •

Related Solutions

May 8, 2009 at 09:49:34
I am sorry to say this but your server team doesn't understand Disaster Recovery nor do they seem to be aware of the different levels of disaster recovery.

You will find that when you try a true failover the workstations on the production domain won't be able to talk to the DR servers since you have separate AD and workstation trusts/sids/guids

Here are some basic examples of DR

Level I DR
multiple DC's with GC/DNS [this is a standard MS recommendation stated in all training courses and ms documentation] and dhcp ready to authorize if dhcp server goes down
raided disk subsystems
backups tested and stored off site with rotation scheme

Level II DR
All of the above with an additional large wan pipe to an offsite server room that is accessable to workstations with the flip of a switch. All servers in same Forest/domain with server to server communication /DFS/FRS between them

Level III DR
Image servers taking snapshots of your servers which is then xferred off site to the DR site image server. Same existing hardware at each site and either image per schedule the DR site servers or be prepared to image and flip the switch.

Many permutations are possible depending on what is considered an acceptable time lag for DR.

If you haven't taken care of the level one basics you have no DR possible.

Server based application failover is the largest consideration and the toughest to implement

Report •

Ask Question