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/
