I shot this off w/o much forethought, the /d is fairly AD replication oriented, and clearly not a complete picture.
People have pointed out lots of other stuff, schema, trusts, etc ... good thread. Cheers, -BrettSh [msft] This posting is provided "AS IS" with no warranties, and confers no rights. On Thu, 13 Oct 2005, Brett Shirley wrote: > > There is an undocumented switch "/d" in dcdiag that spills out a bunch of > quasi formated output for the forest. Useful for collecting most of the > forest info at once, I've had PSS send me the output, when diagnosing > customer issues. > > This is basically debugging (/d) information off the internal view of your > forest that dcdiag builds when it runs, and as such it is likely to change > or expand at any time. > > Cheers, > -BrettSh [msft] > > This posting is provided "AS IS" with no warranties, and confers no > rights. > > > On Thu, 13 Oct 2005, Almeida Pinto, Jorge de wrote: > > > What could be interesting is just having the information, not how it is > > presented. For the documentation of the site and replication topology (and > > of course others like OUs structure, members of powerfll groups, etc.) you > > could use something like ADFIND. OK, the presentation of it may not be the > > most beautifull for documentation but it could be used > > > > my EUR 0,00000002 > > > > Cheers, > > > > Jorge > > > > ADFIND: http://www.joeware.net/win/free/tools/adfind.htm > > determine sites: > > adfind -config -f "(objectClass=site)" -dn > > determine subnets and associated subnets: > > adfind -config -f "(objectClass=subnet)" distinguishedname siteobject > > determine properties of the intersite transports > > adfind -config -f "(objectClass=interSiteTransport)" > > determine site links and associated sites: > > adfind -config -f "(objectClass=sitelink)" distinguishedname sitelist > > determine all Site link bridges and its properties > > adfind -config -f "(objectClass=siteLinkBridge)" > > determine all NTDS Site Settings objects for each site and its properties > > adfind -config -f "(objectClass=nTDSSiteSettings)" > > determine all NTDS Settings objects for each DC and its properties > > adfind -config -f "(objectClass=nTDSDSA)" > > determine all replication connections and its properties > > adfind -config -f "(objectClass=nTDSConnection)" > > > > ________________________________ > > > > From: [EMAIL PROTECTED] on behalf of Peter Johnson > > Sent: Thu 10/13/2005 11:36 AM > > To: [email protected] > > Subject: RE: [ActiveDir] Documenting AD > > > > > > > > Also you IP subnets to Site Mappings need to be documented. I.E. a list > > of all IP subnets and what site in Active Directory Sites and services > > they belong to. > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Rocky Habeeb > > Sent: 12 October 2005 18:27 > > To: [email protected] > > Subject: RE: [ActiveDir] Documenting AD > > > > [Brett] >> "spending time working on AD > Replication, AD > > backup/restore" > > Did you create ASR and will a DC who "masters changes" (per joe's > > comments) and who goes down and has to be rebuilt via ASR have the USN > > rollback problems you guys are talking about? > > > > [Hint] "Keep it simple." Some of us cannot follow all of this because > > you guys are so far out there, we couldn't track you even with the > > Hubble telescope. > > > > Just tell me my ASRs are OK > > > > RH > > ________________________________________________________________________ > > _______ > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of > > [EMAIL PROTECTED] > > Sent: Wednesday, October 12, 2005 11:42 AM > > To: [email protected] > > Subject: RE: [ActiveDir] Documenting AD > > > > > > Additional components: > > ================= > > Schema > > Database > > Administrative support model > > Domain controller spec > > DC/GC placement > > Exchange topology and design > > DNS design (zone type, placement etc etc) > > SYSVOL/FRS > > DFS > > > > Administration: > > =========== > > User and group admin and tools > > DC admin/support and tools > > Forest admin and ownership > > GPO admin and tools > > > > I'll stop there and let others chime in... > > > > neil > > > > ___________________________ > > Neil Ruston > > Global Technology Infrastructure > > Nomura International plc > > > > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Tim Sutton > > Sent: 12 October 2005 16:28 > > To: [email protected] > > Subject: [ActiveDir] Documenting AD > > > > Hey all, > > > > Being the local bod with AD knowledge at work I've been "volunteered" > > the job of documenting our domain (possibly more than one if this goes > > well). Whilst being a good little job it has already caused me a few > > problems, mainly just how much detail to put in, so I thought I'd ask > > for some pearls of wisdom from you guys. What do you lot do? How do you > > go about it? etc > > > > so far I'm thinking along these lines: > > - a general AD layout diagram detailing the OU structure - Visio will be > > the weapon of choice I think > > - list all GPO's, where they're linked to and what they do etc > > - a breakdown of sites and their links > > - a breakdown of replication settings > > - listing of service accounts with descriptions and reasons for > > existence (maybe?) > > - trusts between any other domains > > - detail FSMO roles > > > > ... and that's kinda where I run out of ideas lol > > > > what do you'll reckon? Have I missed or gone overboard on anything? > > > > if I've got the time I'd like to try and script as much of this as > > possible, but if anyone knows of something that does some / all of this, > > please let me know before I kill myself scripting all night :D lol > > > > Cheers :) > > > > > > For Troup Bywaters + Anders > > > > Tim Sutton > > > > T: +44 (0) 113 243 2241 > > F: +44 (0) 113 242 4024 > > E: [EMAIL PROTECTED] > > W: www.TBandA.com > > > > Eastgate House > > 10 Eastgate > > Leeds > > LS2 7JL > > Office Location Map > > > > -----Original Message----- > > From: David Adner [mailto:[EMAIL PROTECTED] > > Sent: 06 May 2005 20:21 > > To: [email protected] > > Subject: RE: [ActiveDir] best practice? (aka: USN rollback discussion > > and why it's a bad idea to image DC's for recovery purposes) > > > > Since no one referenced them during this thread... For a bit more detail > > on the subject, check these out. > > > > How to detect and recover from a USN rollback in Windows Server 2003 > > http://support.microsoft.com/?kbid=875495 > > > > How to detect and recover from a USN rollback in Windows 2000 Server > > http://support.microsoft.com/?kbid=885875 > > > > > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley > > > Sent: Thursday, May 05, 2005 13:19 > > > To: [email protected] > > > Subject: RE: [ActiveDir] best practice? > > > > > > > > > I don't really have serious time to answer this right now ... > > > so for now, you're going to have to trust me, it's not just a little > > > bad you can recover from it with X, it is _really_ bad to do an image > > > based restore, and hard to restore normality afterwards ... > > > > > > I'll prop a portion of a slide deck later on, where I show to the > > > backup vendors how the inconsistency is introduced ... > > > but I don't know if it will make sense w/o my delivery. It is also a > > > bit simplified. joe is close below, some comments inline, in joe's > > > mail, as it's the closest so far to understanding why this is bad ... > > > > > > BTW, clean and dirty AD DB have _nothing_ to do with this. > > > clean/dirty is an ESE / JET Blue level concept, this is an entirely AD > > > > > Logical issue. > > > Nothing prevents an ESE database from being imaged. The AD has a > > > design decision that prevents image based restores. > > > > > > I don't play XBox or any computer games really. I know that sounds > > > weird, that a computer geek would not play video games, but I met a > > > girl at a party the other day who is a huge FPS player, so I think the > > > > > world somehow balances out in that respect. How could that compare to > > > > > the relaxing sense of accomplishment of working out paticularly > > > cunning methods of compressing replication metadata ... I mean really? > > > > > Same goes for hair maintanence tasks. > > > > > > On Thu, 5 May 2005, joe wrote: > > > > > > > I am actually waiting for Brett or ~Eric to respond to your post as > > > > well. I am positive they could give you a bulleted list of > > > things that > > > > you as well as the rest of us are completely unaware of > > > that will go > > > > pear shaped both because they have seen things like that or > > > just know > > > > it from familiarity with the code paths involved. > > > > > > > > AD will not do a complete reload of the DB on its own, that > > > was an NT4 > > > > thing that occurred if the change log rolled. All gone now. > > > > > > > > Do some searching on DSA IDs/GUIDs and Invocation > > > IDs/GUIDS. A DSA ID > > > > is the GUID for the DC itself[1], it doesn't change for the life of > > > > the DC from my understanding. The invocation GUID[2] changes on > > > > restores, again to flag, hey new DB, > > > > > > [BrettSh] It's not a new DB so much, as a new logical stream of > > > changes to the distributed system ... > > > > > > > ... you don't know what my state is, so it can be brought into a > > > > consistent state. > > > > > > [BrettSh] Don't like the term "consistent state" here. I also don't > > > like how we're talking about the DB ... I know all the AD repl docs, > > > talked about it as a new database GUID, but that was poor taste ... > > > there is a subtle but key difference between > > > > > > [local] database consistency, and > > > distributed system consistency. > > > > > > It's the later we're worried about. +The later requires multiple > > > nodes / DCs to have followed all the rules.+ Most of the rules are > > > coded into the way AD behaves, when possible. Thou shalt not image > > > restore, is unfortunately not coded, and hard to be defensible against > > > > > ... well, without sacraficing availability ... but lets not get into > > > that trade-off right now. > > > > > > > You should find hits on invocation id with topics of replication > > > > consistency, usn polling, AD restores, etc as it is key to > > > all of them > > > > though it has been awhile since I went searching for that stuff. > > > > Something I have read on a couple of occasions but can't > > > say I agree > > > > with is that allegedly the DSA ID and invocation id are identical > > > > unless a restore has occurred. I don't think I have EVER seen them > > > > identical so I don't know where that info came from. I am noting it > > > > simply because I recall seeing documentation to that effect > > > in the past. > > > > > > [BrettSh] They should've been the same until the first restore ... > > > there is a bug somewhere, that no one bothered to iron out. > > > > > > BTW, we also change the InvocationID when we _re_-host an Application > > > Directory Partition ... I'll leave the discussion of why to your > > > imagination. > > > > > > Oh and since IFM is like throwing AD Restore and dcpromo into a > > > blender for 30 seconds, IFM based dcpromo sort of changes the > > > InvocationID. > > > You'll notice the invocationID of the DC you took the original backup > > > from in the retired DSA signature of the newly dcpromo'd DC. > > > > > > > > > > > Really try to find detailed info on how replication works. > > > High USN is > > > > just the tip of the iceberg, there is a lot of underlying > > > details but > > > > I understand where the misconceptions can come in, a lot of the > > > > documentation out there in the public realm simplifies the > > > crap out of > > > > this stuff with analogies and very high level details without ever > > > > indicating that it is really quite more involved than that. > > > This can > > > > burn you when you start making decisions based on those > > > simplified examples. > > > > > > > > If you really want to get into it, start fishing through > > > the platform > > > > sdk > > > > Ds* API calls. I would especially recommend the > > > > DsGetDCInfo/DsGetDcInfo2 functions and out of those the ones > > > > concerning DS_REPL_NEIGHBOR structures which gives a feeling of how > > > > much info there is involved with replication and consistency. > > > > > > > > While it may be possible to force the invocationid to > > > change after the > > > > image restore, I am not aware of a method other than doing > > > a proper DB > > > > restore. It could be as simple as tapping that attribute in the > > > > nTDSDSA object but I certainly would NOT be willing to test that in > > > > production even if it worked great in the lab. > > > > > > [BrettSh] > > > > > > Plausible Proposal #1: (please see big warning below) > > > _Technically_, yes if you trigger an Invocation ID change after > > > you lay down the image, _AND THIS IS THE KEY_ ... before the DC > > > talks to any other DCs, and takes any new changes to the > > database. > > > > > > This is one of those rules that all the nodes must > > follow, > > > and if you use an AD based backup/restore program, the > > > appropriate logic will be triggered, and the rules for > > > distributed consistency upheld. > > > > > > _Even_ booting the DC, may institute a change, that causes > > > distributed system inconsistency. Obviously, tapping the object > > > from LDAP is not an option, you have to do it from DSRM. > > > Unfortunately, I've forgotten to tell you how you can trigger a > > > invocation ID change from DSRM ... > > > > > > In short don't go there. These are not the droids you're looking for. > > > > > > > > > > > Certainly, do not image DCs and use that as a recovery > > > mechanism. The > > > > one way to do that, IMO, would involve snap shooting and > > > rolling back > > > > all DCs in a forest at the same time. I don't see how this could > > > > effectively be done in the real world on real hardware. I visualize > > > > possibilities with virtualization software, but that would > > > require a > > > > lot of testing and work to get there and some how guarantee > > > that the > > > > snapshot was done at the exact time for all images. > > > > > > [BrettSh] > > > > > > Plausible Proposal #2: (please see the big warning below) > > > _Technically_, this will work too. Requires all DCs to be off > > at > > > the same time when you take the image based back ups (I > > > think). Requires all the existing DCs to be turned off before > > > you restart the first restored image. I think that is all that > > > is required ... but I'm not sure ... I don't care enough to try > > > to give anyone > > > > > > Plausible Proposal #3: (please see the big warning below) > > > Of course a single DC forest can be image based restored as > > well, > > > though ... you're more likely to get SIDs reissued, and have old > > > wacky ACLs in this case, b/c IIRC we invalidate the present RID > > > pool on restore. This can be mitigated by booting the DC, and > > > before creating any security principals, booting the next rid > > up, > > > can't remember how that is done off the top of my head though > > ... > > > > > > > > > > > If you have done this in production already, I would > > > recommend going > > > > back to what Brett said and doing a verification of your DB > > > on all of your DCs. > > > > > > [BrettSh] Jeez, I really hope no one is in this state, it can be quite > > > > > disturbing to iron out. > > > > > > > Again, Brett is someone who knows about the AD DB. Don't let his > > > > sometimes grouchy demeanor throw you off. He may get difficult at > > > > times but he is almost always trying to help, he just has > > > interesting > > > > ways of expressing it on occasion. He has actually been > > > extremely nice > > > > on this list compared to some other notes I have seen from him. > > > > > > [BrettSh] I thought I was being nice ... wow, it's going to suck, when > > > > > someone actually annoys me. ;) > > > > > > > Basically I say the same about him > > > > that I have often said about myself; don't mistake the > > > quality of the > > > > delivery for the quality of the information. :o) > > > > > > [BrettSh] > > > > > > So first let me divulge, that I am not in fact the Garage Door > > > Operator for building 7, in fact I am a developer/programmer (we're > > > call Software Development Engineers at Microsoft) in Windows, ON > > > Active Directory. > > > Before my recent move to the ESE development, I worked on the AD > > > Replication development for ~5.5 years, spending time working on AD > > > Replication, AD backup/restore, a small bit in AD Schema/Database > > > stuff, AD tools, and even dabbling in DcPromo off and on when required > > > > > for those years. Quite frankly I'm the one who has dealt with almost > > > all the areas affected by a bad image based backup/restore, and the > > > parts that make a good backup/restore possible. I'm uniquely > > > qualified to say: > > > Image based backup/restores are not supported for AD. > > > > > > So we had this customer who wanted to use SAN based hot split on Win2k > > > > > AD (which is even more unsupported, as they didn't shutdown all the > > > DCs, like Plausible Proposal #2 above), after explaining that they'd > > > have to shutdown all DCs, and them agreeing (though I doubted they'd > > > actually do that, it's amazing what customers will do when they think > > > they understand better than you) and then they agreed for restore, > > > they'd take ALL the DCs back to the same backup time, at the same > > > time, and working out this complicated set of steps they would need, I > > > > > pointed out this: > > > > > > --- begin quote --- > > > I can't confirm if you will fail ..., but that set of steps if > > > correctly followed will not cause forest corruption due to USN > > > rollback. Honestly, it isn.t worrying about this once PSS guided > > > transition that worries me, following those types of steps once isn't > > > hard . it is someone not understanding why each of the parts of the > > > technique were required, and later trying it again, and not getting it > > > > > right. In general customers may not truly understand the system's > > > requirements, EVEN after they say they do (b/c they believe they do, > > > no one intentionally hoses their domain, but somehow it happens) so > > > it's just easier to say "no mirror splits on unsupported SANs" > > > --- end quote --- > > > > > > So .... > > > > > > Warning! Warning! Danger Will Robinson! Danger! > > > > > > So the same goes for all 3 proposals above ... while technically you > > > could work out the exact set of steps required, it is likely to be an > > > error prone manual process ... will the next guy who maintains the > > > corp infrastructure understand it all ... will you miss a step ... if > > > you have lots of DCs in branches, how do you know one won't be missed > > > ... you're playing with fire ... and the slightest tweaks can change > > > the answer substantially, for instance auth restore for proposal #1 > > > must be done after triggering the invocation ID to change, which would > > > > > require a reboot ... even me with all my knowledge, wouldn't implement > > > > > such a mechanism in a live corporate deployment ... it's subtle, and > > > it is not worth the risk. > > > > > > Friends don't let friends use image based backups of AD. > > > > > > Cheers, > > > -Brett [msft] > > > I'm just kidding, I just made all the above up, I really am just the > > > Building 7 Garage Door Operator ... > > > > > > > > > > > > > > joe > > > > > > > > > > > > > > > > [1] It is the objectGUID attribute of the ntdsdsa object(aka NTDS > > > > Settings object). > > > > [2] It is the invocationID attribute of the ntdsdsa object. > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Bahta > > > > Nathaniel V Contr NASIC/SCNA > > > > Sent: Thursday, May 05, 2005 10:22 AM > > > > To: [email protected] > > > > Subject: RE: [ActiveDir] best practice? > > > > > > > > Joe, > > > > > > > > I appreciate you indulging me in detail. I was just > > > curious on what > > > > the consequences may be of imaging and restoring DC's. We > > > are always > > > > evaluating and re-evaluating DR methods and techniques, and > > > this was > > > > the latest hot topic. I thought AD pushed changes up to a > > > > pre-determined amount and then it would just replicate the whole > > > > database if the number of changes were too great. I am not sure of > > > > the in-depth implications of restoring imaged DC's but I know the > > > > difference between a clean and dirty AD DB and it sounds as > > > though the > > > > metadata cleanup and synchronization is not meant to happen > > > with an AD > > > > unaware application such as ghost. Perhaps an application > > > that could > > > > stabilize an old DC with the new AD DB would be something > > > that would > > > > have to be looked at. Or maybe an image of a member server and a > > > > dcpromo is the easiest way to recover a DC. I have > > > intentions on working smarter, not harder, but that does not forgo my > > > lust for understanding right from wrong. > > > > > > > > Thanks again for the rebuttal. It always helps to hear things from > > > > all perspectives to get a better look at the big picture. > > > > > > > > Nathaniel > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of joe > > > > Sent: Wednesday, May 04, 2005 2:36 PM > > > > To: [email protected] > > > > Subject: RE: [ActiveDir] best practice? > > > > > > > > I'm not Brett[1] but wanted to just say something really > > > quick here. > > > > > > > > Well a couple of things actually. > > > > > > > > 1. When it comes to AD Database consistency and > > > replication. Brett is > > > > someone I would tend to listen to very carefully. I may not > > > understand > > > > what he is trying to say but I will try like heck to understand it. > > > > Rough around the edges though he may be, he knows a lot > > > about the guts > > > > of the AD DB and Replication. Keep in mind he wrote some of > > > the most > > > > "brilliant" parts of repadmin[2]. > > > > > > > > 2. When you image and recover the image you are bypassing > > > any and all > > > > logic associated with a directory DB recovery. I.E. You aren't > > > > restoring the database through the very specific DS > > > Backup/Restore API > > > > so you don't get the cool things that it does like renaming the > > > > Database GUID aka invocation ID which effectively tells all > > > of the other partners there is a "different" > > > > database out here that needs to be fully updated. > > > > > > > > I haven't fully thought out the implications of that but one thing > > > > right off the bat is the thought that all DCs maintain high water > > > > vectors for all databases so they know where they are at for > > > > replication. This isn't just kept on the DC in question, > > > this is kept > > > > all over so I could see serious possibilities of issues there. > > > > Additionally think of a change that mastered on that database and > > > > replicated out. How do you get it back if the DB is rolled back and > > > > all of the other DCs already think that DB has that info > > > since it was mastered there? > > > > > > > > You get ~Eric, Dean, and Brett thinking about it and I expect you > > > > could find all sorts of horrible things that this can do to you. > > > > > > > > I think the idea that a DC can be restored from an image like that > > > > because it is "sort" of like restoring the DB is flawed at the very > > > > best. You don't have a full comprehension of what is being > > > done in the > > > > backend to support that restore. If it were that simple, > > > why do you need a backup api at all? > > > > Mirror the DIT and zip it and there is your backup... It > > > doesn't work > > > > that way. > > > > > > > > As Brett indicated... Bad mojo... Heck I will go further, > > > positively evil. > > > > You could damage your AD in ways that you (and it) has no > > > clue about > > > > and only later run into it when you are trying to figure > > > out niggling > > > > consistency issues in applications that act odd some of the time. > > > > > > > > > > > > joe > > > > > > > > > > > > > > > > [1] And I couldn't play him on TV either, Brett stores a > > > good portion > > > > of his height in his hair and I store mine in my legs. > > > > > > > > [2] His words when I met him in person at an MVP summit. He > > > was quite > > > > excited to talk about that portion of the code... > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Bahta > > > > Nathaniel V Contr NASIC/SCNA > > > > Sent: Wednesday, May 04, 2005 1:59 PM > > > > To: [email protected] > > > > Subject: RE: [ActiveDir] best practice? > > > > > > > > Brett, > > > > > > > > What is your basis for not being able to restore a DC from > > > a image? > > > > If the DC has an old copy of the directory data, it will check its > > > > USN's and update its copy. What could cause havok if anything? We > > > > are about to institute this very same concept here to turn > > > DR into a > > > > 10 minute process when it comes to operating system > > > recovery. We will > > > > image the servers monthly and restore from said image whenever one > > > > crashes. What could cause a problem by restoring a DC, it will be > > > > timestamped to be old and AD will synchronize it with the > > > rest of the domain. > > > > > > > > Please elaborate on your basis for comment. > > > > > > > > Nathaniel Bahta > > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > Brett Shirley > > > > Sent: Wednesday, May 04, 2005 11:47 AM > > > > To: [email protected] > > > > Subject: RE: [ActiveDir] best practice? > > > > > > > > jlc, > > > > > > > > You can't restore a single DC via an image based backup, > > > either. It > > > > is not supported, it is not allowed ... it is bad mojo. > > > > > > > > Well, it wouldn't cause issues if the forest had ONLY that one DC > > > > (seems unlikely the case), or for a multi-DC forest, you'd have to > > > > shutdown all the DCs in the forest at the same time, when > > > you took your backup images. > > > > And then on restore, restore them all at the same time. > > > Basically a > > > > pretty infeasible suggestion. > > > > > > > > Cheers, > > > > -Brett Shirley [msft] > > > > > > > > This posting is provided "AS IS" with no warranties, and > > > confers no rights. > > > > > > > > > > > > On Wed, 4 May 2005, Joseph L. Casale wrote: > > > > > > > > > Exactly, I do it for DR purposes, the old one dies - I reimage it > > > > > and put it back out there. > > > > > No poblem... > > > > > jlc > > > > > > > > > > -----Original Message----- > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of > > > Phil Renouf > > > > > Sent: Wednesday, May 04, 2005 7:01 AM > > > > > To: [email protected] > > > > > Subject: Re: [ActiveDir] best practice? > > > > > > > > > > On 5/4/05, John Shukovsky Jr > > > <[EMAIL PROTECTED]> wrote: > > > > > > BUT....as for DC's. I do "image" dc's using Symantec Livestate > > > > > > Recovery ( formerly PowerQuest V2i ). It works wonderfully. I > > > > > > primarily use for backups. I have not had to recover a > > > server in > > > > > > production ( and hope I do not have to ) but I have in lab 10+ > > > > > > times > > > > > and servers are as clean as ever. > > > > > > You should take a look. > > > > > > > > > > When Brett mentioned imaging DCs being a bad idea and to > > > never ever > > > > > do it I believe that he was meaning don't Image a DC and > > > try to use > > > > > that Image to build other new DCs and just trying to > > > change the SID > > > > > like you would for a desktop. Bad idea! > > > > > > > > > > Phil > > > > > 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/ > > > > > > > > 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/ > > > > > > > > Groupshield 6.0 - Troup Bywaters & Anders Privilege and Confidentiality > > Notice This email and any attachments to it are intended only for the > > party to whom they are addressed. They may contain privileged and / or > > confidential information. If you have received this transmission in > > error please notify the sender immediately and delete any digital copies > > and destroy any paper copies. Thank you. > > > > 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/ > > > > > > > > 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. > > > > 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/ > > > > > > > > > > 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. > > 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/
