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