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, you don't know what my state is, so it can be brought into a consistent state. 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. 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. 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. 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. 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. 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) 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/
