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.
