For the purposes of your test, you can follow Guido's suggestion about creating a DC in a VM and breaking it off from the hive for further testing. That would give you a point in time clone. If you really wanted to get slick about it, you *could* create them in VM's and just shut them down, and copy them to another machine in an isolated replica of your production phys network site. Then you don't have to go through cleaning the virtualized dc's out of the fabric.
Trying to contain that kind of change is not likely. And since you only want to mitigate what breaks, you want to recreate your environment as closely as possible knowing that there's a delta between reality and your actual test. But you'll have the added advantage of knowing that you didn't blow production to the ends of the earth finding out that this change couldn't be isolated. Using this approach you would have the complete DIT and security principals from that point in time wihtout question and if you had the other layers of the stack you could really make a dent in your risk/mitigation scenario. Often enough to make it worthwhile to put it into production and feel reasonably assured that you've done the due diligence and that nothing of importance will break because of the change. Al On 11/17/06, Andy Wang <[EMAIL PROTECTED]> wrote:
Yes, I did not make any change yet on production environment. I only test it on my testing lab with couple of VMs. I agree with Guido that lab is never _exactly_ the same as production. That is why I want to make the change on "one site / one DC" fist. Client in that site will affected by the change first since they will authenticate against that DC. This will give us best testing result. Thanks! Andy On 11/17/06, Laura A. Robinson <[EMAIL PROTECTED]> wrote: > > From the sound of things, he didn't actually raise it at all yet; he > implemented some other change to see if replication was successfully > prevented by his repadmin approach. (not that you're wrong, just that I > don't think he's even encountered that yet) > > Now, in answer to the original question, here's the thing- the only way > you can permanently prevent any change you make on your "victim" DC from > propagating is to never let it replicate after you've made that change. Some > changes can be overwritten by subsequent changes, but unless you've got a > whole lot of backups and a whole lot of time on your hands, you're never > really rolling back a change once it's made. In respect to your victim > DC, this means that if you didn't want the change to propagate, you'd have > to bring that bad boy down, kill it and restore from backup or just rebuild > and repromote it. Since that's the case, why not just unplug the DC from the > rest of the network while you make your change and plug it back in once > you've verified success? > > Having said the above, there's another consideration here- given the > item in question that you want to "test out", you're really not giving it > much of a test. See, if you raise the FL with that DC disconnected from the > rest of the network and everything looks fine, that's great, but you won't > *really* know that nothing got "broken" until you reinsert the DC into the > replication topology and the change replicates out and oops, lookie there, > that machine stuck in the corner is broken now. There's no way for you to > discover that until your change has propagated, so isolating the DC on which > you raise the FL really isn't buying you any margin of safety. > > And finally, having babbled about all that stuff, there are lots of > checks that happen under the covers when you raise FLs, so it's pretty hard > to raise the FL when, for example, there's still an NT BDC floating around > somewhere, and as Jorge mentioned, you won't even be able to do it > successfully without being able to contact the appropriate role-holder. I > can't even think of any network of which I'm aware where raising FL actually > "broke" anything. Rather, the potential problems with raising functional > level prematurely usually become obvious at a later time when somebody > attempts to do something like introduce an NT BDC into the environment and > can't because the FLs are too high. And honestly, I don't even know anybody > who has done that except to test whether the stuff we say about functional > levels is true. :-) > > So what's my point? I don't know. Okay, kidding. My point is, if you > really want to "test" this change, you need to build out a lab that is > reflective of your production environment and test there, because testing > your change on a single production DC is no change at all. > > Make sense? > > Probably not; I'm very babbly today. Not to be confused with being > boobier. Deji is the boob; I'm the babbler. > > Laura > > ------------------------------ > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Almeida Pinto, Jorge > de > *Sent:* Friday, November 17, 2006 2:03 PM > *To:* [email protected] > *Subject:* RE: [ActiveDir] How to completely isolate a DC? > > did you raise it on the "DC WITH the PDC FSMO role" or just a DC? > > raising the DFL --> contacts the PDC FSMO > raising the FFL --> contacts the schema master FSMO > > jorge > > > ------------------------------ > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Andy Wang > *Sent:* Friday, November 17, 2006 17:38 > *To:* [email protected] > *Subject:* Re: [ActiveDir] How to completely isolate a DC? > > The change is to raise domain functional from Windows 2000 native to > Windows 2003 mode. > > As I understand, once I raised domain function level, the ntMixedDomain > attribute will be changed along with other functions (like domain controller > rename,user password support on the InetOrgPerson objectClass, etc). > > I want to test it on a isolated production DC first. Just in case > something happened, we can shutdown this DC without impact the whole domain. > Other than physical isolation or put a firewall in front of the DC, is there > any way to do it? > > Thanks! > > Andy > > > > On 11/17/06, joe <[EMAIL PROTECTED]> wrote: > > > > What exactly did you change and how did you change it? > > > > -- > > O'Reilly Active Directory Third Edition - > > http://www.joeware.net/win/ad3e.htm > > > > > > > > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto: > > [EMAIL PROTECTED] *On Behalf Of *Andy Wang > > *Sent:* Thursday, November 16, 2006 3:20 PM > > *To:* [email protected] > > *Subject:* [ActiveDir] How to completely isolate a DC? > > > > I need to make a change across our domain. My plan is to make the > > change on one DC and test it, then roll out to other 50 DCs. > > > > I tried to temporarily disable outbound replication of Active > > Directory with repadmin by doing this: > > > > repadmin /options +DISABLE_OUTBOUND_REPL > > > > To my surprise, the change I made still replicated to other DCs > > immediately. > > > > So how can I isolate a DC and make sure the change I made not > > replicate to other DCs? > > > > Thanks for your help! > > > > Andy > > > > > > This e-mail and any attachment is for authorised use by the intended > recipient(s) only. It may contain proprietary material, confidential > information and/or be subject to legal privilege. It should not be copied, > disclosed to, retained or used by, any other party. If you are not an > intended recipient then please promptly delete this e-mail and any > attachment and all copies and inform the sender. Thank you. > > -- > No virus found in this incoming message. > Checked by AVG Free Edition. > > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > >
