Not always…but for many instances, that was the short version! LOL
From: [email protected] [mailto:[email protected]] On Behalf Of Kibble,Tony Sent: Monday, February 08, 2016 4:10 PM To: [email protected] Subject: RE: [NTSysADM] Replicating AD VMs Sent by an external sender ________________________________ This email has an alternate reply address set. ________________________________ Ken Brown Comment Compactor: No, just rebuild new ones. ☺ Tony Kibble From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Brown, Ken F. Sent: 08 February 2016 20:59 To: [email protected]<mailto:[email protected]> Subject: RE: [NTSysADM] Replicating AD VMs 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]> [mailto:[email protected]] On Behalf Of Andrew S. Baker Sent: Monday, February 08, 2016 3:24 PM To: ntsysadm <[email protected]<mailto:[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. ________________________________ DISCLAIMER This material has been checked by us for computer viruses and, although none has been found, we cannot guarantee that it is completely free from such problems and we do not accept liability for loss or damage which may be caused. This message is intended only for use of the individual or entity to whom it is addressed and may contain information which may be privileged and confidential. If you are not the intended recipient you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately via e-mail and delete the message. Thank you. ******************************************************* Travelers Insurance Company Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority in the UK and is regulated by the Central Bank of Ireland for conduct of business rules. Registered in England 1034343. Registered as a branch in Ireland 903382. Travelers Syndicate Management Limited is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Registered in England 03207530. Travelers Underwriting Agency Limited is authorised and regulated by the Financial Conduct Authority. Registered in England 03708247. Travelers Professional Risks Limited is an appointed representative of Travelers Insurance Company Limited which is authorised by the Prudential Regulation Authority and regulated by the Financial Conduct Authority and the Prudential Regulation Authority. Registered in England 05201980 Travelers Management Limited. Registered in England 00972175. The registered offices for all companies listed above is: Exchequer Court, 33 St Mary Axe, London, EC3A 8AG. All other branch offices are available from our websites. travelers.co.uk travelers.ie Issues to: mailto: [email protected]<mailto:[email protected]> ________________________________ This communication, including attachments, is confidential, may be subject to legal privileges, and is intended for the sole use of the addressee. Any use, duplication, disclosure or dissemination of this communication, other than by the addressee, is prohibited. If you have received this communication in error, please notify the sender immediately and delete or destroy this communication and all copies. TRVDiscDefault::1201
