|
Hi guys, I haven’t posted anything in response to this thread yet because I didn’t have anything of value to add; I just wanted to thank each of you for answering my question, and for the education your responses provided me. Taking what you said, I was able to go back to the developers, put together a proper effective testing plan that we can complete in a few hours, and they are very pleased with that. We hope to complete the native mode switch on that domain by next weekend.
Thanks again – this was very valuable.
Regards, Mark Creamer
-----Original Message-----
yeap - that's what I meant with the "point of no-return"... Any roll-back procedure for this scenario would likely only be useful for a very short time.
From: deji Agba [mailto:[EMAIL PROTECTED]
Guido, John.
I (personally) don't think the biggest consideration in this "roll-back" plan is whether or not it can be done, or which methodology is more "supported" than the other. In my selfish opinion, the consideration should be what it will break. What it will break depends greatly on the length of time that has transpired between when the Native switch was flipped and when the roll-back trigger is being pulled AND what changes have occurred in the environment since that time For example, since you switched to Native mode, say you have upgraded your EXC 5.5 to 2000 and have your DLs converted to UGs. Then say you have done some fancy nesting that became available to you in Native mode. Say you have installed some ERP applications that have extended the Schema based on its Native status.
Now, regardless of HOW you do your roll-back and what type of convergence occurs, how would one address the new "orphans" that will be created now that Nativity is gone?
However, if Mark's original question - "Although the change is not reversible, we could restore from AD backup and be back where we were" - is along the line of "oh, [EMAIL PROTECTED], It didn't work, let's back out!!", then I completely agree with his line of thinking. But if it is along the line of "oh, yeah, we took a backup last month or 2 months ago before the switch", then I am afraid he may be seriously disappointed. As usual, I've been known to be wrong before.
Sorry about the long rant.
Sincerely,
From: GRILLENMEIER,GUIDO
(HP-Germany,ex1) John - I've also had various discussions about this is likely not the case where "one solution fits all". While I agree it should be technically feasable to take a *healthy* backup of EVERY DC of a domain at roughly the *same* time (at least prior to switching the domain modes), you are getting into the "unsupported" area of things - that's why I said restoring one and re-promoting the others is "most supported". As you mentioned, it's the procedure MS also supports for the forest recovery - although I hope nobody needs to go through this ;-)
I also agree that it's a lot of work, but how much work it really is mostly depends on how the network and sites are setup. You'll certainly not like this approach with a lot of DCs in sites accross slow links (especially in 2k).
/Guido
From: John Reijnders
[mailto:[EMAIL PROTECTED] Interesting discussion ... you're telling that "any other option would be too risky". I've had this discussion with MS before and they (initially) said the exact same thing (you're scaring me Guido ;-) ... However, I'm convinced that restoring every single DC of a domain that was taken at a *healthy* point in time eventually leads to the same situation as restoring a single one and repromoting the rest. It's a matter of convergence ... Eventually the MS guys agreed with me (at least the ones I've discussed this issue with).
The best practice of restoring a single DC from backup and repromoting all others is described in the Forest Recovery white paper. However, in a situation in which you need a Forest Recovery a piece of "magic" has occurred that corrupted your complete forest. Unless you know how and when this corruption entered your AD it is wise to restore a single DC, test this one very thoroughly and then repromote the others, to make sure that you do not reintroduce the corruption. In the case of Mark, the "corruption" would be the switch to native mode, which is made at a specific point in time and can therefore be reverted by using backups from all other DCs. One of the advantages of restoring all DCs from backup is that you do not need to do any seizing of FSMOs, cleanup metadata and that kind of stuff.
Which method to choose is a matter of taste and also depends on your environment. Repromoting every single DC (except 1) is a hell of a job in large environments that have limited bandwidth like we European guys ;-). The install from media option in W2003 reduces the impact of repromotion in W2003 environments, but that's not what Mark is at I presume.
John
|
- [ActiveDir] native mode Creamer, Mark
- RE: [ActiveDir] native mode Joe
- RE: [ActiveDir] native mode John Reijnders
- RE: [ActiveDir] native mode GRILLENMEIER,GUIDO (HP-Germany,ex1)
- RE: [ActiveDir] native mode Mulnick, Al
- RE: [ActiveDir] native mode John Reijnders
- RE: [ActiveDir] native mode GRILLENMEIER,GUIDO (HP-Germany,ex1)
- RE: [ActiveDir] native mode deji Agba
- RE: [ActiveDir] native mode GRILLENMEIER,GUIDO (HP-Germany,ex1)
- RE: [ActiveDir] native mode Creamer, Mark
- RE: [ActiveDir] native mode Jorge de Almeida Pinto
- RE: [ActiveDir] native mode rrutherford
- [ActiveDir] Native Mode Sudhir Kaushal
- RE: [ActiveDir] Native Mode Simon Geary
- RE: [ActiveDir] Native Mode Joe Baguley
- [ActiveDir] Native Mode james . cate
- RE: [ActiveDir] Native Mode Roger Seielstad
- RE: [ActiveDir] Native Mode Craig Cerino
- RE: [ActiveDir] Native Mode Kuhlman, Philip S
- RE: [ActiveDir] Native Mode Rocky Habeeb
