Its still cool and appreciated. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Thursday, October 13, 2005 10:55 AM To: [email protected] Subject: RE: [ActiveDir] Documenting AD
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/ 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/
