Boaz, what were you going to use to get valid test data if it was never on the same network? More precisely, how will you certify that your test environment is a valid representation of the production environment such that you can use this test to mitigate your risks sufficiently?
I had to laugh out loud for the first one. Although I agree with this idea in principal, I've rarely seen it implemented. Too many places make people admins for the wrong reasons; trust is usually too subjective to propagate in a large, de-centralized organization. In a small shop, the same person(s) you trust with the keys to pick up the mail and pay the bills, often have the trust to administer your Active Directory and buy the right coffee. Personally, I may still classify them as "rogue" for the purposes of this conversation. Dangerous certainly. On 11/17/06, Boaz Galil <[EMAIL PROTECTED]> wrote:
Guido, 1."Friendly administrator" - if you don't trust someone don't make him admin. 2. I really don't like your method, in my opinion changes should be tested on a separate network, test lab, some kind of environment that is similar to the production network but is separate from it. On 11/17/06, [EMAIL PROTECTED] <[EMAIL PROTECTED] > wrote: > > All valid points indeed. > > I prefer to test changes in a lab first using prod like hardware (for > obvious reasons). I therefore avoid the VM approach for those reasons. > > I prefer to implement a change freeze for the duration of any major > changes. If a "rogue" / "friendly" admin makes a mod and disrupts the change > then he/she will be looking on jobserve [or regional equivalent] within the > next few hours :/ > > Your points are valid - I simply thought I'd express another way of > attacking the same 'issue'. > > neil > > ------------------------------ > *From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > *On Behalf Of *Grillenmeier, Guido > *Sent:* 17 November 2006 11:33 > *To:* ActiveDir@mail.activedir.org > *Subject: * RE: [ActiveDir] How to completely isolate a DC? > > > > This is a common procedure, but realize that it will still not > completely isolate replication – *forced* replication will still go > through (i.e. in an out of the 'schema mod' site). You may not do the > forced replication yourself, but if some other "friendly" administrator > chooses to do so in order to troubleshoot something else ( e.g. via > repadmin or replmon), your protection is gone. > > > > As such physical isolation is really your only option if you really want > to isolate a DC. > > > > The Problem: you can't do all updates on a DC that's not connected to a > network (e.g. schema updates don't tend to work since it can't look up > the schema master, even if the role is held on the same machine etc.). > > > > The Solution: there are many, but my favorite is simply to use VMs. You > can then add a couple of DCs as VMs on the same host and potentially move > them to your special site. You can then switch from bridged networking to > host-only networking so that these DCs are completely isolated from the > network but can still communicate between each other. This will allow you to > test that these will still replicate fine after the update. Once the tests > have proven to work fine, you can switch back to bridged networking and > replicate the changes out. > > > > Naturally, you can do the same with physical hardware and a separate > network – it's just so much easier using virtualization technologies. > > > > /Guido > > > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of [EMAIL PROTECTED] > *Sent:* Friday, November 17, 2006 10:20 AM > *To:* ActiveDir@mail.activedir.org > *Subject:* RE: [ActiveDir] How to completely isolate a DC? > > > > In the example of a schema mod, I tend to: > > > > 1. Move the schema master FSMO role holder DC to a 'schema mod' site > > 2. Change the replication schedule for all site links where this site > participates, so that replication is stopped in and out of the schema mod > site > > 3. Make the schema change on the DC in the schema mod site > > 4. Test the change > > 5. Change replication schedules back so that the change propagates to > other sites > > > > Obviously, you need to wrap some processes and procedures around the > above but you get the idea ... :) > > > > neil > ------------------------------ > > *From:* [EMAIL PROTECTED] [mailto: > [EMAIL PROTECTED] *On Behalf Of *Andy Wang > *Sent:* 16 November 2006 20:20 > *To:* ActiveDir@mail.activedir.org > * 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 > > PLEASE READ: The information contained in this email is confidential and > > > intended for the named recipient(s) only. If you are not an intended > > recipient of this email please notify the sender immediately and delete > your > > copy from your system. You must not copy, distribute or take any further > > > action in reliance on it. Email is not a secure method of communication > and > > Nomura International plc ('NIplc') will not, to the extent permitted by > law, > > accept responsibility or liability for (a) the accuracy or completeness > of, > > or (b) the presence of any virus, worm or similar malicious or disabling > > > code in, this message or any attachment(s) to it. If verification of > this > > email is sought then please request a hard copy. Unless otherwise stated > > > this email: (1) is not, and should not be treated or relied upon as, > > investment research; (2) contains views or opinions that are solely > those of > > the author and do not necessarily represent those of NIplc; (3) is > intended > > for informational purposes only and is not a recommendation, > solicitation or > > offer to buy or sell securities or related financial instruments. NIplc > > does not provide investment services to private customers. Authorised > and > > regulated by the Financial Services Authority. Registered in England > > no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St > Martin's-le-Grand, > > London, EC1A 4NP. A member of the Nomura group of companies. > PLEASE READ: The information contained in this email is confidential and > > intended for the named recipient(s) only. If you are not an intended > recipient of this email please notify the sender immediately and delete > your > copy from your system. You must not copy, distribute or take any further > > action in reliance on it. Email is not a secure method of communication > and > Nomura International plc ('NIplc') will not, to the extent permitted by > law, > accept responsibility or liability for (a) the accuracy or completeness > of, > or (b) the presence of any virus, worm or similar malicious or disabling > > code in, this message or any attachment(s) to it. If verification of > this > email is sought then please request a hard copy. Unless otherwise stated > > this email: (1) is not, and should not be treated or relied upon as, > investment research; (2) contains views or opinions that are solely > those of > the author and do not necessarily represent those of NIplc; (3) is > intended > for informational purposes only and is not a recommendation, > solicitation or > offer to buy or sell securities or related financial instruments. NIplc > does not provide investment services to private customers. Authorised > and > regulated by the Financial Services Authority. Registered in England > no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St > Martin's-le-Grand, > London, EC1A 4NP. A member of the Nomura group of companies. > -- regards Boaz Galil.
