BTW, yes the scratch the forest and start over, usually people don't auth restore, they just make sure the rolled back forest, doesn't replicate with the corrupted forest. This is the normal forest restore procedure.
Note: Because AD tries to replicate with deleted NTDS Settings objects, you have to make sure all the other DC's computer accounts are deleted, this fails auth so that they can't replicate. IIRC, ntdsutil from sp1 does delete the DC computer accounts, where as win2k3 RTM and before does not. Cheers, BrettSh On Wed, 21 Jun 2006, Brett Shirley wrote: > > This should give you a list of any other classes using non-standard naming > attributes. Send us the output. > > Cheers, > BrettSh > > FindNonStdNamingAtts.cmd: > @echo off > rem Somewhat brute force, should claim one non-standard naming > rem attribute msTapi-uid, but this provides a sort of yes, the > rem the command is working feedback. > rem > rem When the command is done, you should see one or more lines > rem like this printed: > rem tempo.txt:8654: 1> rDNAttID: msTAPI-uid > rem > rem So for to see the class that requires say this msTAPI-uid, > rem you can open up the tempo.txt file and goto line 8654 to > rem see the class it is associated with. This is hacky. > > [Ed. BrettSh: note my email editor wrapped these lines, this is > basically 2 line script, you have to have win2k3 repadmin.exe and > findstr.exe.] > > repadmin /showattr . ncobj:schema: /onelevel > /filter:"(name=*)" /atts:objectClass,name,rdnattid,ldapDisplayName > > tempo.txt > > findstr /snic:"rDNAttID" tempo.txt | findstr > /veic:"lDAPDisplayName: rDNAttID" | findstr /veic:"rDNAttID: ou" | findstr > /veic:"rDNAttID: cn" | findstr /veic:"rDNAttID: o" | findstr > /veic:"rDNAttID: dc" | findstr /veic:"rDNAttID: l" | findstr > /veic:"rDNAttID: c" | findstr /veic:"rDNAttID: uid" | findstr > /veic:"rDNAttID: st" | findstr /veic:"rDNAttID: street" | findstr > /veic:"rDNAttID: street" > > > > > On Wed, 21 Jun 2006, Joshua Coffman wrote: > > > Thanks again for your help. I appreciate your feedback and expertise on the > > subject. > > > > You are correct, this is a test of a bare-metal restore of the entire > > domain, where I bring in tapes from offsite and restore a single DC to a > > completely disconnected machine (on identical hardware). In this worst-case > > scenario, the plan was to restore a single DC, perform metadata cleanup, > > and rebuild and dcpromo new replicas. I was under the impression that in > > order to restore the entire database from scratch, you had to mark the > > SYSVOL as primary, and perform an authoritative restore: restore database. > > Are you saying you just restore from tape, mark SYSVOL as primary, skip the > > auth restore commands in NTDSUTIL, and just perform the metadata cleanup > > functions, clean DNS, etc. and you are good to go? If this is correct, it > > would be a much cleaner/faster process, because we wouldn't have to be > > updating USNs on a half-million objects. > > > > It makes sense that it would not have to be authoritative, if all replica > > DC's were going to be new, but I (probably mistakenly) thought that the > > authoritative restore was a required step. > > > > Thanks!Josh > > > > > > Subject: RE: Re: [ActiveDir] Errors During Authoritative RestoreDate: Wed, > > 21 Jun 2006 08:48:25 +0100From: [EMAIL PROTECTED]: > > [email protected] > > > > > > > > glad Brett picked up on analysing the different errors you were getting - > > I've not seen these before. > > > > curious to hear what type of issue you are testing to recover from? From > > what you write, I gather you are testing to restore your production domain > > to another (hopefully physically separated) test-system. I.e. you are > > testing a full recovery of your AD domain or forest - is this correct? > > > > If so, authorititative restore of the AD DB is not the right approach > > anyways. The restore database option gives the false impression of doing a > > full recovery of AD - it bears more risks than value and likely this is why > > it was removed from Longhorn. In a distributed multi-master database such > > as AD, auth. restoring the partition of one DC will never completely > > overwrite the same partition of the other DCs: although you might be lucky > > and think you have fully recovered, any additional objects or new > > attributes added to existing objects in the respective AD partition after > > you performed the backup will replicate back to the restored DC. > > > > The correct way to fully restore AD is to restore only a single instance of > > the DB (i.e. a single DC) and re-build / re-promote all the other DCs. > > Instead of performing an auth. restore of the DB, you'd just restore it > > non-authoritatively and do a metadata cleanup of all the other DCs on the > > restored DC to ensure it is the only one representing your domain (you > > would mark SysVol as primary during the restore process). There are a few > > more steps to perform to ensure that the recovered DC doesn't replicate any > > data from other existing DCs in your environment - all of these are > > described in the (fairly old) AD Forest Recovery Whitepaper which pretty > > much also applies for full recovery of a single domain: > > http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=3EDA5A79-C99B-4DF9-823C-933FEBA08CFE > > > > It's a little more complex in a multi-domain environment as you also have > > to take care of the partitions of your domain on GCs in other domains - if > > you're goal is to also fully restore the config partition, you're talking > > about a full forest restore anyways (which would roughtly use the same > > approach - restoring a single DC of every domain - then re-promoting all > > other DCs). > > > > Although LH backup and recovery procedures are not fully finalized yet, for > > full AD recovery the process would still roughly be the same as described > > above (mind you there are big changes to the built-in backup-tool - and > > recovery of a DC to different HW should now also be a valid option). The > > main change with LH that will strongly influence time and risk for a > > domain/forest level restore is the fact that you will not have as many > > writeable DCs in your environment. Even if you are strongly distributed > > geographically, the goal will be to only host writeable DCs in your > > datacenters and make all the other DCs in your environment read-only. As > > the name implies, the Read-Only DCs (RODC) do not allow any originating > > writes on them and will never replicate anything back to a writeable DC - > > this way there is less work involved to ensure a consistent status of AD > > during the recovery. Not saying you won't also have to re-promote the > > RODCs, but you certainly have less writable DCs to worry about and can > > possible leave the RODCs running during the recovery process (we'll have to > > see about this). I have good hopes that this will increase the overall > > recovery-speed of AD in large distributed deployments. > > > > /Guido > > > > > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joshua > > CoffmanSent: Dienstag, 20. Juni 2006 21:33To: [EMAIL PROTECTED]: RE: Re: > > [ActiveDir] Errors During Authoritative Restore > > Thanks Brett, I appreciate your assistance on this. Yes, there are tons of > > schema mods. In the domain throwing the majority of the errors, these mods > > were performed using an LDIF file, during the installation of a 3rd party > > Identity Management Application. I do not know if there have been LDAP > > naming attributes added or not. If you can send a query to verify, I would > > be happy to run it.I knew that Restore Database is the "last resort" > > method, but that is what we wanted to test. We do have multiple DCs > > replicating across multiple geographic sites, so this scenario is unlikely, > > unless there were some sort of catastrophic corruption that took place. In > > the future, if "restore database" is unavailable, what will be used in its > > place if you need to do a bare metal authoritative restore of the entire > > AD? It will take a while to run the tools you requested against the AD, > > because it is a production system. I cannot run them directly in the PROD > > environment, so I would have to pull a mirrored drive from the prod DC, and > > pop it into an offline server. This could take a while for the required > > approvals. Thanks again for your help!Josh > > > > > Date: Tue, 20 Jun 2006 10:09:58 -0700> From: [EMAIL PROTECTED]> To: > > > [email protected]> Subject: Re: [ActiveDir] Errors During > > > Authoritative Restore> > Do you have any schema extensions applied? Do > > > you know if those schemas> added any LDAP naming attributes? If the 2nd > > > question doesn't make sense> to you, I'll figure out a way you can query > > > this, and send it to us.> > Aside, it is generally not recommended to run > > > "restore database". In fact> this command was removed from Longhorn.> > > > > If you decide to retry that scenario again, I can suggest some> > > > intermediate steps that would be good to know. i.e.> > 1. Before running > > > auth restore, be interesting to know the results of an> esentutl /k > > > ntds.dit (checksum the database).> > 2. After auth restore, it would be > > > good to know if the database is> logically consistent from ESE's > > > perspective (do this via "esentutl /g> ntds.dit").> > 3. Also after we > > > know it is logically consistent from AD's perspective (do> this via, > > > exact command line provided:> ntdsutil "sem data anal" "go" "q" "q"> > > > > Cheers,> BrettSh [msft]> Ex-Building 7 Garage Door Operator> > > On Tue, > > > 20 Jun 2006, Joshua Coffman wrote:> > > I have a few questions for you AD > > > gurus out there! :)> >> > I just ran through a Disaster Recovery test of > > > two of our ADs and I> > have a few questions which have come up as a > > > result of the test.> > > > Configuration Notes:> > These boxes are > > > Windows 2003, SP1.> > The domains were originally Windows 2000 domains.> > > > >> > The following errors pop up on one of the domain controllers > > > during> > the restore.> >> > "Could not display the attribute type for > > > the object with DNT> > 831424.Error: failed to get dn of dnt 831424" This > > > occurs many times> > throughout the restore.> >> > NOTE: This is during > > > a complete restore, e.g. "authoritative restore:> > restore database" I > > > also see a few of these.> >> > "There was an error parsing the GUID from > > > the file on line: 1981" (Not> > to many of these, maybe four or five)> >> > > > > Additionally, with SP1, LDIF files are created to restore back-links.> > > > > The file that restores the user/group back-links imports successfully.> > > > > The file that restores the configuration back-links fails. (sorry, I> > > > > do not have the error handy)> >> > The authoritative restore says it > > > completed successfully, and after I> > go through metadata cleanup and > > > FSMO seizure, the box starts up> > without any errors, and AD throws no > > > errors on startup.> >> > I was wondering if anyone can tell me what > > > these errors mean? What> > are their ramifications? How can the errors be > > > resolved.> > > > Thanks,> > > > Josh> > List info : > > > http://www.activedir.org/List.aspx> List FAQ : > > > http://www.activedir.org/ListFAQ.aspx> List archive: > > > http://www.activedir.org/ml/threads.aspx > > List info : http://www.activedir.org/List.aspx > List FAQ : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.activedir.org/ml/threads.aspx > List info : http://www.activedir.org/List.aspx List FAQ : http://www.activedir.org/ListFAQ.aspx List archive: http://www.activedir.org/ml/threads.aspx
