> this would seem to contradict the concept of authoritative restore ?
 
that's because of everyone's notion of what you EXPECT an auth. restore to do and how it is being promised in trainings etc. => "Auth. Restore" will allow you to turn back the hands of time...
 
But once you dig into it and understand what the Auth. Restore really does (as you say, it "only" increases the version number of existing attributes that it knows of in the database), you find that it doesn't really work as you might expect - I've had my share of troubles with restoring users and their groups in other parts of the forest...  Tough to restore links to objects if these links aren't contained in the domain backup you're just restoring (e.g. when a user is a member in Universal Groups or Local Groups in other domains).
Check out the following KB for details on this: http://support.microsoft.com/?id=840001
 
The CAs and the eMail addresses in your case are just another example => neither version number of the eMail attribute of your users had been set, nor were the CA objects existent before you backed up the domain / forest (if I remember correctly, the CA objects are stored in the config NC => so if you really wanted to get rid of them via backup/restore, you'd have to do a forest restore --- I would much suggest to go for manual cleanup instead...).  Same for the eMail attributes, which are easily cleaned via a script.
 
/Guido


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Tuesday, August 17, 2004 11:50 AM
To: [EMAIL PROTECTED]
Subject: Re: [ActiveDir] w2k authoritative restore

Brett, thanks for post reply

ADC - ex2k3 active directory connector

CA - is connection agreement defined within ADC

> ... So is the CA data perhaps in attributes that are not set on the backup
> objects? - YES

"Ergo it kind of works as a merge of old attributes that were set and new attributes that were set post backup. "

do i read this right in that the authoritative restore allows data to be replicated back from a DC ?? - don't see how this can work unless of course an attribute that has no data in it has a null USN (as on my restored backup set ?) which is not incremented by the authoritative restore command, and which is therefore overwritten by another server which has some data in it

this would seem to contradict the concept of authoritative restore ?

Thanks

GT


> do i read your post correctly in that the attribute data that is being (in my view incorrectly) replicated back is

----- Original Message -----
From: [EMAIL PROTECTED]
Date: Mon, 16 Aug 2004 11:25:05 -0700 (PDT)
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 c loses 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 authoritati vely 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 d ata 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/

Reply via email to