Thanks for the correction Deano - I can live with being wrong :-)

So the "GC full sync" is not really a synchronization as such (at least from
my understanding of the word).  I still don't understand why the GC would
behave in this way during a full sync.  I mean, why would the GC want to
hang onto domain partition data that it knows is not present in the source
domain?  What's the advantage of that compared to simply wiping everything
and starting from scratch (which is what I thought it did)?

Tony

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Freitag, 30. Januar 2004 19:06
To: AD mailing list (Send)
Subject: RE: [ActiveDir] Contents of GC

As already pointed out, Jorge is suffering from a read-only lingering object
issue.  Deletion of such objects in 2000 remains a painful process but is
now feasible (earlier versions of 2000 AD provided no "on-the-fly" means of
removing these kind of errant objects short of fully de-GCing and re-GCing
all Global Catalog servers).  As a side note, this is (for the most part) a
non-issue on 2003 since support for the bulk removal of lingering objects
(read-only or read-write) was added to the DSA and can be invoked using
REPADMIN /removelingeringobjects (or your own code/script).

Some of the potential solutions recommended thus far will work, some won't.
For example, PAS alterations DO cause a full-sync. but the process is
incremental in nature, i.e. - it does NOT destroy the existing partition
content.  It merely resets its HWV USN representation of the foreign NC and,
essentially, begins re-replicating it from scratch (without removing the
existing content) and, as such, does NOT resolve this issue.

A hotfix was provided (post SP2 I believe) that added support to the 2000
DSA for a new operational attribute (removelingeringobject), this is NOT
equivalent to the 2003 capabilities.  This functionality was later dumped in
a rollup fix and was subsequently incorporated into the later service packs.

As I see it, two solutions exist;

1. Demote all existing GCs, allow the demotion to fully complete, re-promote
previous GCs

NOTE - The demotion process can be accelerated by running the following
command locally on each of the GCs once and ONLY once they become aware of
their GC'less'ness :).  This is ONLY necessary if you're impatient ;) or
operating under some kind of imposed time constraint.  Removal of a
partition (full or partial) occurs incrementally each KCC cycle
(default=every 15 mins.).  ~5000 objects are removed each iteration, the
following command causes the KCC to run 100 times thereby destroying
~500,000 objects.  Simply replace the (1,1,100) with (1,1,<total est. #
objects in all foreign partial NCs / 5000>).  This process requires the 2000
Support Tools.

        a) Run CMD
        b) Enter -
                for /l %a in (1,1,100) do repadmin /kcc
        c) Enter -
                exit

* There are other ways to accelerate this process, I personally like this
one as it tends to be easier to remember and available on just about every
DC (at least in my world).

2. Assuming the necessary hotfix, rollup fix or service packs are installed,
use the "removelingeringobject" operational attribute to destroy the errant
objects as outlined by -

http://support.microsoft.com/default.aspx?scid=kb;en-us;314282

NOTE - I've had intermittent results with this process and find it a little
time consuming and flaky.

Finally, I'm afraid you can't use the REPADMIN /removelingeringobjects
command provided by the Windows 2003 Support Tools as the 2000 DSA doesn't
support the operational attributes and/or processes triggered by this
command.

HTH

Deano

--
Dean Wells
MSEtechnology
* Email: [EMAIL PROTECTED]
http://msetechnology.com



-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tony Murray
Sent: Friday, January 30, 2004 7:35 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC


Eljin

A quicker option would be to make a minor change to the PAS and wait for the
GC full sync to put everything right.  And watch your available nework
bandwidth plummet!

I have been thinking about whether the unGC/reGC (as you put it) method
would work.  I think you would have to look very carefully at the
replication topology before doing this.  It might be that even after
unGC-ing a DC and then reGC-ing later you still get all the objects you
don't want.  This can happen if the replication partner for the DC you have
just reGC-ed is a GC from domain A or C (in Jorge's scenario).  In other
words, it is possible that you might pull the information from a source that
still has the stale information.

Tony

---------- Original Message ----------------------------------
Wrom: AFXISHJEXXIMQZUIVOTQNQEMSFDULHPQ
Reply-To: [EMAIL PROTECTED]
Date:  Fri, 30 Jan 2004 01:40:51 -0800

Tony,


An alternative is to do the unGC but the garbage collection only removes
5000 objects per garbage collection cycle unless you use a fast demote vbs
script.
>From the sound of it, it would be best to do the ungc and regc method.
NOTE: don't reGC until all gc objects are removed or life will be bad.
Matter of fact, now that I think about it. You can ungc just that partition
using the new W2k3 repadmin that I am sure of.
If you need data from these objects then you have to do the dump routine
otherwise use new repadmin would be quickest fix.

Signed
one of those Alliance folks

-----Original Message-----
Wrom: QWOYIYZUNNYCGPKYLEJGDGVCJVTLBXFGGM
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Friday, January 30, 2004 12:33 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

Nod. Highly recommend a solution of equal parts perl and adfind. Adfind to
well, find, and perl to control flow and delete.

Note script will take an hour or so to write depending how fancy someone
wants to get and flexible and how much protection. Then log in with an admin
id for a minute or two to run the script and then log back out of the admin
ID. Again that logon/off is via runas /user:domain\adminuser cmd

A really fancy script would do an actual compare of the read/write and read
only partitions and logically ascertain which pieces in the read only
partition only existed in the read only section and then delete them.


  joe



-----Original Message-----
Wrom: EPYOQKEDOTWFAOBUZXUWLSZLKBRNVWWCUF
[mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray
Sent: Friday, January 30, 2004 3:27 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC

Ouch, that looks nasty.  What's funny is that the KB article shows a method
for "many objects", which relies on you having the object GUIDs in a text
file.  The example it gives for obtaining the object GUIDs is to use LDP.
For 10,000 objects?  I think not.  CSVDE or script would be the better
option.

Either way you look at it, this is a fair amount of work.

Tony

---------- Original Message ----------------------------------
Wrom: IVOTQNQEMSFDULHPQQWOYIYZUNNY
Reply-To: [EMAIL PROTECTED]
Date:  Fri, 30 Jan 2004 03:04:38 -0500

I finally remembered!!!

Lingering Objects!

Once I had that I found the KB article quickly enough. Thank Google...


http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314282
<BLOCKED::http://support.microsoft.com/default.aspx?scid=kb;en-us;Q314282>


   joe


  _____

Wrom: CGPKYLEJGDGVCJVTLBXFGGMEPYOQKEDOTW
[mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Thursday, January 29, 2004 9:55 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Contents of GC


Oh what an interesting scenario....

You are an evil person.

The fact that you don't have references to the objects in the main domain
means they will never automatically get updated since that is all GUID/USN
based...

You need to clean out the GC partitions. You can do that by wiping them but
that would be painful. I do believe MS has another process for this but as a
last resort kind of thing. I am barely remembering a conversation with one
of the Alliance PSS guys once that they have a method to delete objects out
of the GC partitions it had something to do with something they fixed in
W2K3 and one of the W2K SP's. I bet Dean would spit this one out in like 10
seconds.

Crap I hate it when I can't remember things like this...

One additional evil test I would try to do is to recreate the object and see
how the GCs handle it. And then delete the object. It shouldn't touch the
existing ones but I would be interested to know what it would do with that
add... Could possibly throw the GCs over the edge because you would be
violating the consistency rules and the GC partitions shouldn't be able to
rename an object name with the GUID like the default partition can...

There is some replication issue thing that can get garbage into the GC that
you can't get back out... It is on the tip of my frontal lobe...

Hmm let me watch ER and think about it... I know I don't know the method to
do the delete, but if I can recall what the original issue is maybe I can
find info about the backdoor fix or search keywords...

  joe


  _____

Wrom: FAOBUZXUWLSZLKBRNVWWCUFPEGAUTFJMVR
[mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida
Pinto
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
*       Fax     : +31-(0)40-2957630
*       Mobile  : +31-(0)6-29067977
*       E-mail  : [EMAIL PROTECTED]
"       < <http://www.logicacmg.com/> 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.



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/

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