small correction: it's not the USNs that are increased => it the version number
and as far as I understand it, an object won't inherit an attribut until it's "used" the first time - so only attributes which are populated for an object will have a version number in the first place. maybe Brett can confirm this. As such, a previously unused attribute can't be auth. restored (unless you eliminate all occurences in the domain/forest - which is equal to a domain/forest recovery) /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Tuesday, August 17, 2004 12:32 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] w2k authoritative restore Guido, thanks for post reply full recovery of the domain is what i have fallen back to - was looking for a sanity check on this issue of authoritative (or not so as it seems ) restore is it a fair qu to ask though how the directory service resolves this issue of replication of attribute data that is blank (but which should have a higher USN by virtue of the authoritative restore) and that which has been populated but has a lower USN does it somehow use a system of a null USN for an attribute that has no data and which can be overwritten ?? GT ----- Original Message ----- From: "Grillenmeier, Guido" Date: Tue, 17 Aug 2004 11:57:32 +0200 To: Subject: RE: [ActiveDir] w2k authoritative restore > sounds like you need a forest (or full domain) recovery if you screw > up with the ADC... - how many DCs per domain do you have? > > btw - the logic of "merging" data gets a new touch when you auth. > restore groups in Win2003: once you're at 2003 forest-functional-level > (LVR enabled) and you wish to restore group authoritatively, you'll > also find members that were added to the group after the backup will > re-populate into the auth-restored group, since with LVR the members > are replicated separately as well... In this case, I usually preferr > this "merge" feature, as this will guarantee you to get the group back > to a most up to date state (unless a specific script, virus, stupid > admin or whatever process accidentally populated all your groups with > garbage > data...) > > /Guido > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > [EMAIL PROTECTED] > Sent: Monday, August 16, 2004 8:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [ActiveDir] w2k authoritative restore > > Auth restore will auth restore attributes that _exist_ in the backup > as they were at the time of backup, but not auth restore attributes > that didn't exist. Ergo it kind of works as a merge of old attributes > that were set and new attributes that were set post backup. > > ... So is the CA data perhaps in attributes that are not set on the > backup objects? > > Further like we merge the attributes that are auth restored over any > existing ones, we also merge in objects as well. So a new object post > backup will not get "auth restored" (i.e. the closes thing woudl be to > delete the new object) > > Just grasping at straws, don't know much specifics about CA or ADC. > > Cheers, > Brett Shirley (msft) > AD Developer > > On Mon, 16 Aug 2004 [EMAIL PROTECTED] wrote: > > > dear all, sorry to "bomb" the list with queries, but was hoping to > > get > > > a heads up on this issue of authoritative restore subsequent to a > > directory modification using ADC > > > > we are testing the procedure of rollback of a domain that has been > > modified using an ADC connection agreement > > > > i have a backup set taken prior to the processing of the ADC CA and > > can confirm the successful restore of a DC to the prior state. (no > > email address in the user objects no CA objects etc) > > > > despite the fact that this data is restored authoritatively as soon > > as > > > the restored DC is attached to the network with its DS started the > > data prior to the CA processing is overwritten with the data from an > > another server > > > > have followed what seems to be a simple process of auth restore; > > > > 1. boot into DS restore > > 2. restore system state and c: using the original location / always > > overwrite 3. restart 4. boot into DS restore mode 5. run ntdsutil / > > authoritative restore / restore database > > > > my first thought was that the ADC has created that many chages that > > the default version increment of auth restore (7000000) is not > > enough for the restored DC to have higher USN than the server that > > is left online > > > > have tried auth restore with the verinc value of 10000000 but still > > the old data gets overwritten > > > > any clues ?? > > > > GT > > > > > > > > > > > > List info : http://www.activedir.org/mail_list.htm > > List FAQ : http://www.activedir.org/list_faq.htm > > List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
