thanks Brett for the confirmation and clarification > If we set meta-data elements for all attributes for unset attributes > just to get "a delete" of the attribute to win (remember there are 100s > of unset attributes) you could experience like 5k+ bloat per object. > > Administrators would be very unhappy about that.
agreed, but Administrators also don't like not be able to restore something to a "known" version. I guess a viable solution could be to figure out the most critital of the "100s of unset attributes" and pre-populate them with NULL or some other meaningless data at the time of creation of "normal" admin objects (i.e. users, groups, computers, contacts etc., but not config items like site-links etc.). These settings could be removed right afterwards, but the versioning of the attribute remains - this could allow you to get the best of both worlds. A tedious job though... /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, August 18, 2004 3:29 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] w2k authoritative restore Well, first GT, below I think you're thinking of version numbers, not USNs like Guido said. Both are used in replication, but for different purposes. USNs are strictly used for determining _what to replicate_, never _what wins in a replication conflict_. Replication conflicts are decided by version numbers + other junk if version numbers are equal. With version numbers (which is what gets bumped when you auth restore, not USNs*), a unset attribute has none, and as such loses to any other change with "a set version number". * USNs may change, but they're not "bumped" up by a large amount they're just incremented from "the last max USN" (simplification). The meta-data attribute for an AD object (you can see through repadmin /showobjmeta (or in older repadmin use just /showmeta)), is a sparse format, meaning we only set meta-data "rows"** for attributes set on the object. ** they're not really DB rows, but in repadmin they come out as rows in a table. When we auth restore we only bump versions on attributes represented in the meta-data this is why you get the merge behavior, if an attribute was never set before backup then the no version will lose to even a version 1 attribute set post backup. If we set meta-data elements for all attributes for unset attributes just to get "a delete" of the attribute to win (remember there are 100s of unset attributes) you could experience like 5k+ bloat per object. Administrators would be very unhappy about that. Well, that scratches the surface enough, I hope? I think this is probably all documented in the Win2k Distributed System's Guide, if you've the patience to read an 1600 page volume like that. Cheers, Brett Shirley (msft) (I guess today) the auth restore dev On Wed, 18 Aug 2004 [EMAIL PROTECTED] wrote: > Guido, i appreciate this is going into what seem to be the "murky > depths" of AD but would you be able to expand on this concept of > "version number" - it must relate somehow to replication which i > thought to be based on USN's ? > > GT > > ----- Original Message ----- > From: "Grillenmeier, Guido" <[EMAIL PROTECTED]> > Date: Tue, 17 Aug 2004 17:35:37 +0200 > To: <[EMAIL PROTECTED]> > Subject: RE: [ActiveDir] w2k authoritative restore > > Re: small correction: it's not the USNs that are increased => it the > version > Re: number > Re: > Re: and as far as I understand it, an object won't inherit an attribut > until > Re: it's "used" the first time - so only attributes which are > populated for > Re: an object will have a version number in the first place. > Re: > Re: maybe Brett can confirm this. > Re: > Re: As such, a previously unused attribute can't be auth. restored > (unless > Re: you eliminate all occurences in the domain/forest - which is equal > to a > Re: domain/forest recovery) > Re: > Re: /Guido > Re: > Re: -----Original Message----- > Re: From: [EMAIL PROTECTED] > Re: [mailto:[EMAIL PROTECTED] On Behalf Of > Re: [EMAIL PROTECTED] > Re: Sent: Tuesday, August 17, 2004 12:32 PM > Re: To: [EMAIL PROTECTED] > Re: Subject: RE: [ActiveDir] w2k authoritative restore > Re: > Re: Guido, thanks for post reply > Re: > Re: full recovery of the domain is what i have fallen back to - > Re: > Re: was looking for a sanity check on this issue of authoritative (or > not so > Re: as it seems ) restore > Re: > Re: is it a fair qu to ask though how the directory service resolves > this > Re: issue of replication of attribute data that is blank (but which > should > Re: have a higher USN by virtue of the authoritative restore) and that > which > Re: has been populated but has a lower USN > Re: > Re: does it somehow use a system of a null USN for an attribute that > has no > Re: data and which can be overwritten ?? > Re: > Re: GT > Re: > Re: ----- Original Message ----- > Re: From: "Grillenmeier, Guido" > Re: Date: Tue, 17 Aug 2004 11:57:32 +0200 > Re: To: > Re: Subject: RE: [ActiveDir] w2k authoritative restore > Re: > Re: > sounds like you need a forest (or full domain) recovery if you > screw > Re: > up with the ADC... - how many DCs per domain do you have? > Re: > > Re: > btw - the logic of "merging" data gets a new touch when you auth. > Re: > restore groups in Win2003: once you're at 2003 > forest-functional-level > Re: > Re: > (LVR enabled) and you wish to restore group authoritatively, > you'll > Re: > also find members that were added to the group after the backup > will > Re: > re-populate into the auth-restored group, since with LVR the > members > Re: > are replicated separately as well... In this case, I usually > preferr > Re: > this "merge" feature, as this will guarantee you to get the > group back > Re: > Re: > to a most up to date state (unless a specific script, virus, > stupid > Re: > admin or whatever process accidentally populated all your groups > with > Re: > garbage > Re: > data...) > Re: > > Re: > /Guido > Re: > > Re: > -----Original Message----- > Re: > From: [EMAIL PROTECTED] > Re: > [mailto:[EMAIL PROTECTED] On Behalf Of > Re: > [EMAIL PROTECTED] > Re: > Sent: Monday, August 16, 2004 8:25 PM > Re: > To: [EMAIL PROTECTED] > Re: > Subject: Re: [ActiveDir] w2k authoritative restore > Re: > > Re: > Auth restore will auth restore attributes that _exist_ in the > backup > Re: > as they were at the time of backup, but not auth restore > attributes > Re: > that didn't exist. Ergo it kind of works as a merge of old > attributes > Re: > that were set and new attributes that were set post backup. > Re: > > Re: > ... So is the CA data perhaps in attributes that are not set on > the > Re: > backup objects? > Re: > > Re: > Further like we merge the attributes that are auth restored over > any > Re: > existing ones, we also merge in objects as well. So a new object > post > Re: > backup will not get "auth restored" (i.e. the closes thing woudl > be to > Re: > Re: > delete the new object) > Re: > > Re: > Just grasping at straws, don't know much specifics about CA or ADC. > Re: > > Re: > Cheers, > Re: > Brett Shirley (msft) > Re: > AD Developer > Re: > > Re: > On Mon, 16 Aug 2004 [EMAIL PROTECTED] wrote: > Re: > > Re: > > dear all, sorry to "bomb" the list with queries, but was > hoping to > Re: > > get > Re: > > Re: > > a heads up on this issue of authoritative restore subsequent > to a > Re: > > directory modification using ADC > Re: > > > Re: > > we are testing the procedure of rollback of a domain that has > been > Re: > > modified using an ADC connection agreement > Re: > > > Re: > > i have a backup set taken prior to the processing of the ADC > CA and > Re: > > can confirm the successful restore of a DC to the prior state. > (no > Re: > > email address in the user objects no CA objects etc) > Re: > > > Re: > > despite the fact that this data is restored authoritatively as > soon > Re: > > as > Re: > > Re: > > the restored DC is attached to the network with its DS started > the > Re: > > data prior to the CA processing is overwritten with the data > from an > Re: > Re: > > another server > Re: > > > Re: > > have followed what seems to be a simple process of auth > restore; > Re: > > > Re: > > 1. boot into DS restore > Re: > > 2. restore system state and c: using the original location / > always > Re: > > overwrite 3. restart 4. boot into DS restore mode 5. run > ntdsutil / > Re: > > authoritative restore / restore database > Re: > > > Re: > > my first thought was that the ADC has created that many chages > that > Re: > > the default version increment of auth restore (7000000) is not > Re: > > enough for the restored DC to have higher USN than the server > that > Re: > > is left online > Re: > > > Re: > > have tried auth restore with the verinc value of 10000000 but > still > Re: > > the old data gets overwritten > Re: > > > Re: > > any clues ?? > Re: > > > Re: > > GT > Re: > > > Re: > > > Re: > > > Re: > > > Re: > > > Re: > > List info : http://www.activedir.org/mail_list.htm > Re: > > List FAQ : http://www.activedir.org/list_faq.htm > Re: > > List archive: > Re: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > Re: > > > Re: > > Re: > List info : http://www.activedir.org/mail_list.htm > Re: > List FAQ : http://www.activedir.org/list_faq.htm > Re: > List archive: > Re: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > Re: > > Re: > > Re: > List info : http://www.activedir.org/mail_list.htm > Re: > List FAQ : http://www.activedir.org/list_faq.htm > Re: > List archive: > Re: http://www.mail-archive.com/activedir%40mail.activedir.org/ > Re: List info : http://www.activedir.org/mail_list.htm > Re: List FAQ : http://www.activedir.org/list_faq.htm > Re: List archive: > Re: http://www.mail-archive.com/activedir%40mail.activedir.org/ > Re: > Re: > Re: List info : http://www.activedir.org/mail_list.htm > Re: List FAQ : http://www.activedir.org/list_faq.htm > Re: 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/
