RE: [ActiveDir] Contents of GC

[joe]

Title: Message

It shouldn't Roger. An auth restore simply cranks the USN's. Since the objects don't exist in the domain, the USN wouldn't come into play.

 

  joe

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
Sent: Thursday, January 29, 2004 11:51 AM
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Contents of GC

You restored the entire domain, but didn't mark it authoritative, correct?

 

I wonder if that would have made a difference - again, its just a stab.

 

--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.

-----Original Message-----
From: Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 11:32 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

I tested the situation I described earlier (see below) and the findings are as expected:

I restored DOM_B using the backup without the 10000 objects.

Everything is in sync again.

 

When I do an AD search (in DOM_A or DOM_C) for the 10000 objects (all begin with the name TEST) I get 10000 results

 

When I do an AD search (in DOM_B) for the 10000 objects (all begin with the name TEST) I get 0 results.

 

THUS: how to get those objects out of the GC data? ;-(

 

Regards,

JORGE

 

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
Sent: Thursday, January 29, 2004 16:10
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Contents of GC

You're right - I was missing that. Can you do an auth restore of the parent (such as an OU)? Not sure if that would do it or not, however.

 

It seems like the issue is what type of garbage/orphan collection process exists in the GCs, I don't have an answer. Maybe Darren or someone else has an idea?

 

Roger

--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.

-----Original Message-----
From: Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 9:04 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

I think you're missing something. The backup that was used does not contain those 10000 objects, and there is no other backup to use. That's why I wonder what will happen with the objects in the GC data

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
Sent: Thursday, January 29, 2004 14:50
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Contents of GC

Because they'll have the same GUID, they're really the same object. Since they have higher USNs due to the authoritative restore, they'll be updated with the information from the restore - thereby bringing your forest back into sync.

 

 

--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.

-----Original Message-----
From: Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 8:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

HI Roger,

 

I thought about that one. The increase of the USNs of the domain data will exceed the USNs of the GC data on the other DCs. BUT, what happens to those 10000 objects in the GC data that were never tombstoned? If I'm correct they will remain in the GC data because they were never tombstoned (deleted) in the domain partition.

 

Regards,

 

Jorge

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad
Sent: Thursday, January 29, 2004 14:22
To: '[EMAIL PROTECTED]'
Subject: RE: [ActiveDir] Contents of GC

Then what you need to do is perform an authoritative restore from T1 into Dom_B. That's *exactly* why the authoritative restore concept exists.

 

 

--------------------------------------------------------------
Roger D. Seielstad - MTS MCSE MS-MVP
Sr. Systems Administrator
Inovis Inc.

-----Original Message-----
From: Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 8:17 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

Hi,

 

This may seem strange, but the restore of the "lost objects" is not the highest priority. The highest priority is to get the forest in sync again concerning all naming contexts

 

Just for the example: the only available backup is T1. No other backup available!

 

Regards,

JORGE

---

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adams, Kenneth W (Ken)
Sent: Thursday, January 29, 2004 14:06
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

Have you tried performing an authoritative restore of DOM_B using a backup from T3?  That should restore all objects to the domain and still keep the GCs in sync.

 

 

Kenneth W. (Ken) Adams, MCSA, MCSE

-----Original Message-----
From: Jorge de Almeida Pinto [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 29, 2004 7:56 AM
To: [EMAIL PROTECTED]
Subject: [ActiveDir] Contents of GC

Hi Everyone,

The following situation....

THE FOLLOWING ENVIRONMENT IS AN EXAMPLE:
* 1 forest with 3 domains (W2K Native Mode)
        * DOM_A is forest root
        * DOM_B is a child domain of DOM_A
        * DOM_C is a child domain of DOM_A
* Each domain has 5 DCs
* Each DC = GC

On
T=0     : all DCs/GCs are in sync
T=1     : backup made of all DCs in forest (system state)
T=2     : addition of 10000 objects to DOM_B
T=3     : all DCs/GCs are in sync again (all GCs in DOM_A & DOM_C contain the 10000 objects from DOM_B)
T=4     : some time later
T=5     : ALL DCs in DOM_B crash or dy or whatever (don't function anymore)
T=6     : Restore all DCs in DOM_B from the backup made in T=1

After the restore is finished al DCs from DOM_B boot and are OK again

SITUATION:
All GCs from DOM_A & DOM_C contain information about the 10000 objects from DOM_B. These objects reside in the GC data but the domain data (DOM_B) does not even know of the existance of those objects because all DCs have been restored. The GC data is newer than the domain data.

How to deal with?
SOLUTION 1: (I know this one works, but with a forest containing a lot of DCs/GCs I'd rather not do this)
* Demote all GCs in the forest? (wait until all GCs are fully demoted)
* Promote all DCs to GC again

SOLUTION 2: (I hope something like this works)
Is it possible to say:
* Tell all GCs to remove the read-only naming context of DOM_B and rebuild it again (is REPADMIN able to do this?)

SOLUTION 3:(I hope something like this works)
Is it possible to say:
* Tell all GCs to check the read-only naming context of DOM_B against the DCs of DOM_B and remove all objects from the GC data that do not exist in DOM_B

SOLUTION 4:
Something else?????

I hope someone can answer this

Thanx in advance!

Regards,
Jorge

Does somebody know how or which tool is able to check if a certain object is stored in de read-only naming context (of a certain domain) of the GC?

Environment:
* W2K3
* 3 domains
* 1 DC per domain
* Each DC = GC
* No Exchange

Met vriendelijke groet / Kind regards,

Jorge de Almeida Pinto
Microsoft Infrastructure Consultant
__________________________________________

<<...OLE_Obj...>>

LogicaCMG Nederland B.V. (BU SD/AT)
Division Industry, Distribution and Transport (ID&T)
Kennedyplein 248, 5611 ZT, Eindhoven
.       Postbus 7089
        5605 JB Eindhoven
(       Tel             : +31-(0)40-2957777
2       Fax     : +31-(0)40-2957630
(       Mobile  : +31-(0)6-29067977
*       E-mail  : [EMAIL PROTECTED]
"       <http://www.logicacmg.com/> - Solutions that matter -

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.