I built a separate single-domain forest (like production) with a different name. Used Quest's fastlane migrator to migrate all the old NT4 accounts to both our new production AD and the testlab. We aren't big enough to warrant an isolated subnet, so there is physical connectivity between the testlab and production. I have separate instances of E2K3, SQL, and our main LOB app running in both forests with no adverse interaction. Our testlab is built on MDSN ( a great bargain, BTW) and our development staff codes and tests in the testlab before any changes are made in production. So far it has worked pretty well for us. The developers occasionally complain about the speed of some of the machines, but I just tell them to buy me new ones and I'll set them up for them. :-) If done properly, you should not experience any conflicts between the two forests.
********************** Charlie Kaiser MCSE, CCNA Systems Engineer Essex Credit / Brickwalk 510 595 5083 ********************** > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Taylor, Michael > Sent: Tuesday, July 05, 2005 1:59 PM > To: [email protected] > Subject: RE: [ActiveDir] Patching Strategy on DC's > > Great advice Charlie, thanks. > > So for your test lab did you just setup a test domain? Is there any > risk of the test servers such as Exchange, SQL, etc. interfering with > the production domain? > > Sorry if that's a stupid question. I'm just getting started with this > server administration stuff and I'm trying to learn all I > can! Thanks. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Charlie Kaiser > Sent: Tuesday, July 05, 2005 2:12 PM > To: [email protected] > Subject: RE: [ActiveDir] Patching Strategy on DC's > > I run a small shop (~40 servers) and I have a testlab set up. A couple > of DCs, a mail server, a few other things. Built from old desktops and > VMs. I migrated all our user accounts into that lab when I > built our AD, > so it was synched at the beginning, but is now out of synch. > That's OK, > it helps when I need to test some moves or adds. Bottom line > is that our > testlab roughly mirrors our production domain. Same schema extensions, > same OU structure, similar GPs. > I patch the testlab with the current patches, then run some basic > testing (logins, check event logs, force replication, perform some > management activities like user MACs and things like that depending on > the patches). I'll usually let the patches spin for a couple > of days and > a couple of reboots. Then pull some full backups and patch my > production > domain in a 3-group sequence I've developed that starts with > infrastructure, then application servers, then file-related > servers over > a period of 3 days. I also file change control documentation on the > patches and the servers being patched. > Rick also made a very good point. I usually wait at least a week and > watch the patchmanagement list and a couple of others to see if people > are reporting problems. Nothing like leveraging your test > environment... > :-) > A working test lab is critical. If for no other reason than to be able > to tell your boss "gee; it worked fine in the test lab!" :-) > My upgrades > and migrations so far have run flawlessly because I've been > able to make > all my mistakes in the test lab. I'm the only one who sees what went > wrong... > > ********************** > Charlie Kaiser > MCSE, CCNA > Systems Engineer > Essex Credit / Brickwalk > 510 595 5083 > ********************** > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Taylor, > > Michael > > Sent: Tuesday, July 05, 2005 12:28 PM > > To: [email protected] > > Subject: RE: [ActiveDir] Patching Strategy on DC's > > > > I've been wondering about this same thing. I was just recently > > promoted to server administrator of about 30 servers. What > would be > > the easiest way to make sure a patch doesn't interfere with > Exchange, > > SQL, IIS, etc? > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > Rick Kingslan > > Sent: Tuesday, July 05, 2005 12:52 PM > > To: [email protected] > > Subject: RE: [ActiveDir] Patching Strategy on DC's > > > > How about: (and maybe not in this order) > > > > 1) Install a test environment - test patches before implementation > > 2) Patch half after compatibility and performance, then patch the > > others within 48 hrs. (less, if you're feeling comfortable or the > > patch is of a very critical and high risk category) > > 3) Get a complete system state backup of all DCs before > applying any > > patches. > > > > A couple thoughts - and to expand upon my earlier comment. > > > > Security IS Risk Management - plain and simple. Don't > patch quickly > > just for the sake of patching because Microsoft releases a > fix. Look > > closely at the details of the patch - specifically the Technical > > sections. Determine what RISK this vulnerability poses to your > > environment. If it has to do with Alerter on your DCs, but > you have > > the Alerter service off and Disabled, then it poses less of a risk > > than, say > > - RPC which will allow remote execution if exploited. > > > > However, at the time you need to take into account that there is a > > real potential that the application of any un-tested patch > WILL cause > > disruption of normal operations. Thereby, you need to approach any > > patching with the give and take of applying a patch because it is > > necessary and critical, with that of the possibility of disruption. > > Analyze the risk of either action, and act accordingly. > > > > Rick > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Murray Wall > > Sent: Tuesday, July 05, 2005 12:31 PM > > To: [email protected] > > Subject: [ActiveDir] Patching Strategy on DC's > > > > I have a question about a patching strategy for Domain > controllers. > > We have a single forest single domain, 4 dc's, when patching for > > security patches should we do all the DC's at once, or do > half of them > > > or should we introduce a test lab or lastly a latent replicated > > production site with a dc in it? Thoughts and approaches > appreciated! > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/List.aspx > > List FAQ : http://www.activedir.org/ListFAQ.aspx > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
