I skimmed all the emails in this chain. I don’t recall any specific roles (other than FSMO’s mentioned) that would require the exact same named DC to come online at the DR site (perhaps I missed that). Perhaps applications are hard-coded to a specific DC name and/or custom certificates installed on those DC’s are involved?
If there are roles on those DC’s that would need to be recovered – that could
very well be a significant factor in the need to do the DR recovery in this
fashion (I’m thinking ‘roles’ like certificates, RMS, ADFS, ADSYNC, FIM, file
shares beside SYSVOL, etc). {although, in my point of view, those roles should
never ever ever be installed on DC’s – but smaller shops may need to do that
for fiscal reasons}
Other roles (or features) like DHCP, WINS are easy to fail over.
I guess…the question is can you test what you are building? Not without
ensuring the “DR” copies cannot talk to any other DC. If you can’t test it –
you won’t actually know if it will work when the time comes – and what is the
impact to your business if that happens? As long as you can test what is being
built and it meets your needs, you should be good to go.
As someone else mentioned, in an actual DR situation – and don’t assume you
will be available - someone else with less knowledge of your specific
environment and replication methods may need to be involved with getting the
domain functional again. If they need to get assistance (From Microsoft,
Vmware, SAN vendor, etc) – how long will that take to get the support folks up
to speed with a non-standard configuration so the recovery can begin?
That risk is something that needs to be evaluated and taken into consideration.
Good luck!
My point of view is to create those DC’s and let them replicate via normal AD
replication – but the DC’s I’m responsible for do not have roles like
certificates, RMS, ADFS, ADSYNC, FIM etc running on them. They do have DHCP
and (gasp) WINS – and recovery of DHCP and WINS is trivial (assuming backups).
{although with Win2012, DHCP has the capability of true redundancy…but I
haven’t gotten that far yet but we are looking at that}.
If there are apps that are hard-coded to DC names – renaming a DC could be a
viable alternative.
In fact, we test this annually (across multiple forests…don’t ask!). I have a
‘test’ forest and we recover DHCP,WINS,replication from the “test1” site to the
“test2” site – seizing FSMO roles, moving DHCP roles (via backups), etc. The
steps are all documented. In fact, I bring production DHCP backups into the
lab to ensure they work; we use the same process when DC’s are upgraded in the
field that run DHCP so the steps we use are well documented/tested multiple
times per year in production for upgrades.
As I primarily was the architect and author of the DR environments and
documentation – I am not the person who does the actual testing of the recovery
steps. I do take notes and update the documentation as required so that the
steps are documented such that the author/architect (me) is not required to
actually implement the steps in a time of crisis! (new people on the team are
the lucky testers! ☺ )
We also do “application DR” tests (not “AD/DC recovery”) where we take copies
of VM/DC’s into an ISOLATED network environment {seize roles, etc}; primarily
so that applications that need to test their DR capabilities can do so with
minimal changes to their configuration (which they’d have to do when moving
between datacenters {primarily DNS} – but all their service accounts, SPN’s,
etc all work without more changes). {And those copied DC’s are destroyed each
time}
From: [email protected] [mailto:[email protected]] On
Behalf Of Andrew S. Baker
Sent: Monday, February 08, 2016 3:24 PM
To: ntsysadm <[email protected]>
Subject: Re: [NTSysADM] Replicating AD VMs
Sent by an external sender
________________________________
This email has an alternate reply address set.
________________________________
>>
This isn't about subverting or replacing AD replication, but about DR recovery
of a DC. <<
So, what you're saying is that you'd prefer to rely upon a barely supported
configuration -- vs a fully supported configuration -- at a time when you are
already under stress to get back to a fully functional state in your computing
environment?!?
Alrighty then...
Regards,
ASB
http://XeeMe.com/AndrewBaker<http://xeeme.com/AndrewBaker>
Providing Expert Technology Consulting Services for the SMB market…
GPG: 1AF3 EEC3 7C3C E88E B0EF 4319 8F28 A483 A182 EF3A
On Mon, Feb 8, 2016 at 11:07 AM, Michael Leone
<[email protected]<mailto:[email protected]>> wrote:
On Fri, Feb 5, 2016 at 4:41 PM, Brian Desmond
<[email protected]<mailto:[email protected]>> wrote:
> Regardless of the virtualization safeguards probably mitigating risk, I
> still come back to the original question which is why subvert a system which
> has its own replication mechanism (AD) with the vmWare alternative? Perhaps
> there’s a detail I’m missing here but that’s where this breaks down for me.
This isn't about subverting or replacing AD replication, but about DR
recovery of a DC. If a DC at a site becomes unavailable (such as for
broken physical connectivity to the site), this way the same DC comes
back online, at a reachable site (but with the same IP subnets). You
haven't done anything with AD replication, except rely on it to find
the DC when it comes back online, and sync with it. Effectively, you
are using AD replication exactly as it's supposed to work -
re-establish replication when the DC connectivity comes back online.
What you're bypassing is a rebuild of a destroyed DC, and bypassing
the need to clean up AD of the old DC, before building a new DC.
<<attachment: winmail.dat>>
