Re: BCP Domain Disaster Recovery..., Which way should i go??!!??

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

I do many disaster recovery configurations and all of my customers are
doing option 1. However, these plans all account for recovering
Exchange as well in the DR site, so it is generally more important to
have an active GC in the DR Site to do regular recovery drills.

Depending on your requirements, it sounds like plan 3 is working for
you. The important thing for you to do regardless of the plan is to do
regular drills. If the drills work, then you can be better prepared
and assured that in an actual disaster you will be covered.

David Bermingham
MCSE, MCSA:Messaging
www.steeleye.com

VFR wrote:
Hello...
I am currently designing a BCP DR plan for our company...
Our IT area is only responsible for providing support for two domains
within a forest of 7 domains.
So essentially, this BCP DR plan does not relate to any of the other
domains..
Physical Infrastructure:
Main site:
- Gigabit backbone connecting server infrastructure.
- 100Mbps to the desktop's
- 1800 clients.
- We have just invested in a dark fibre connection to a remote location
that has 100% connectivity back to our main site. We are using a
passive device (CISCO CourseWave Multiplexer) for routing traffic to
the remote site (remote site is on the same subnet(s) as the main
site).
- Servers and clients are on separate subnets.

Logical Infrastructure:
- 1 root domain with two DC's (not managed by our IT area)
- Exchange infrastructure is also located in the root domain.
- Child Domain1 with DC1 (all FSMO roles / GC / WINS / DNS) and DC2 (GC
/ WINS / DNS / DHCP)
- Child Domain2 with DC1 (all FSMO roles / GC / WINS / DNS) and DC2 (GC
/ WINS / DNS / DHCP)
- Other domains (not managed by our IT area)
- All DC's are running 2003 in 2000 native mode.

We have an external vendor that we have contractual arrangements with
to support all servers and comms infrastructure. For each server we
unfortunately pay significant T&M for the ongoing support of backups /
patching / incident escalation etc.

I have investigated various articles and Microsoft best practice
documentation on DC DR solutions..
It seems that we have three options:
[b]1. A third DC...[/b]
- Build a third DC (for each domain)
- Build the DC's on either separate hardware or on virtual machines.
- Place the hardware hosting the third DC's out at the remote site.

[b]2. A third DC (only switched on every 30 days)[/b]
- Build a third DC (for each domain)
- Build the DC's on either separate hardware or on virtual machines.
- Place the hardware hosting the third DC's out at the remote site.
- Turn off the hardware.
- Switch on the hardware periodically (within the tombstoneLifetime
period / 60 days by days by default)..

[b]3. Use an offsite systemstate backup.[/b]
- Build separate hardware with the same name and IP as DC1 from the
main site. (for each domain)
- Disconnect and switch off the separate hardware.
Major Incident Action:
- Ensure that DC1 (main site) is un-contactable (disconnect link to
main site).
Note: we may need to re-connect a separate link to the root forest
domain to allow continued connectivity to the exchange farm....
- Complete a primary restore of the offsite systemstate backup of DC1
(main site) onto DC1 (at the remote site).
- Run Health checks.
- Get DHCP up and running.
See: hxxp://support.microsoft.com/?id=263532 (cannot seem to find the
2003 equivilent)..

Anyway..
My original preference (and Microsoft's best practice)... is to go
with option 1..
However, after doing a cost benefit analysis, i realised how expensive
option 1 will be..
The expense all came down to the external vendor's ongoing contractual
support costs..
As this is a DR box, not requiring backups etc. and only used in
emergencies, the external vendor was happy to reduce costs
significantly, however, we are still talking about at least $8000AU per
annum..

So, I thought I would investigate other options..

Option 2...
This is great... however there are a few downsides..
1. Objects in the domain may be missing changes since the last
successful replication..
- e.g.: Computer / user account passwords.
- Group memberships etc.
2. Possible complexity when bringing the DC online to re-synchronize /
or DC is unavailable...
- e.g.: support costs could blow out due to investing errors when
bringing the remote DC back online.
- May cause confusion to technical staff completing maintenance on
other domain / forest DC's (errors relating to the remote DC not being
available).
3. Our external vendor will still be charging us ongoing support on the
box for the completion of scheduled re-synchronizations and patching.
(probably about $4000AU per annum)..

Option 3...
At first, when I read hxxp://support.microsoft.com/?id=263532, i
thought.. this is to risky!!...
However, i practiced it in a virtual environment and it worked like a
charm..
Took me less then 20 minutes to get a fresh machine up and running as a
DC from a restored systemstate backup...
The only catch is..
The remote hardware is totally different from the hardware at the main
site..
The only similarity is that both hardware has the same disk
configuration.. (separate disk arrays for NTDS database / log files and
sysvol).
I will be giving option 3 a test sometime next month to more accurately
gauge the required recovery time and related risk.

I am interested if anyone has been in the same situation..
or if anyone has had any experience restoring a "child domain" within a
forest... similar to option 3....

- Have there been any issues with connecting a restored DC to other
domains within the forest?
- Have there been any issues with connecting a restored DC to an
exchange farm in another domain?
- Any tricks to lookout for when completing option 3?
- Any other compelling reasons to go with Option 1 / 2 / 3?

I know this a long post, however, its difficult to condense all the
required info..
I would [b]really[/b] appreciate any help with this.. :)

Thanks in advance,
vfr

.

Relevant Pages

  • Re: running a duplicate SBS server remotely
    ... lookingto have a cloned copy of our SBS server made and kept remotely. ... That's probably not a good plan. ... Invest in good hardware (e.g., ... You could have another DC in a remote office connected via VPN, ...
    (microsoft.public.windows.server.sbs)
  • Re: Same Problem
    ... It's the small black IR transmitter attached to the IR cable.The transmitter part gets affixed to the remote sensor area of the Set Top Box in front of the IR Receiver. ... IR Hardware Not Detected on Vista Ultimate ... It worked fine with COX TV, but when I switched to Verizon FIOS it would not get past the IR Hardware/cable detection problem. ...
    (microsoft.public.windows.mediacenter)
  • Re: Windows Media Centre useless without remote?
    ... can do it change the channel on the SAT receiver. ... I will NEVER need to use the IRB since if I want to PVR something I ... I have to attach a piece of hardware that is useless to me just so I can ... remote controls so why make an IRB manditory? ...
    (microsoft.public.windows.mediacenter)
  • Re: VPN Issue
    ... This really sounds more and more like hardware. ... remote location over RWW, but the server doesn't have outbound Internet? ... SBS is using for Internet - in other words, ...
    (microsoft.public.windows.server.sbs)
  • BCP Domain Disaster Recovery..., Which way should i go??!!??
    ... Our IT area is only responsible for providing support for two domains ... We have just invested in a dark fibre connection to a remote location ... Build the DC's on either separate hardware or on virtual machines. ... we may need to re-connect a separate link to the root forest ...
    (microsoft.public.windows.server.active_directory)