FWIW - If I am not mistaken, the KCC removal rate of objects in the GC is actually 500 under Windows 2000. However, I believe that SP4 for Windows 2000 also provides the rapid removal of GC objects such as is provided in Windows Server 2003.
Regards, Aric -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Saturday, January 31, 2004 3:03 PM To: AD mailing list (Send) Subject: RE: [ActiveDir] Contents of GC I have a former student (a PSS tech.) looking into the very same thing and received a voicemail/email last night outlining precisely the behavior you reference. The Microsoft definition of a lingering object (in my opinion and this instance) is too strict and an unnecessarily "guarded" (my two pence at least) and also explains the less than 100% track record I've experienced with this *feature*. Advancing the clock and/or reducing the TSL are NOT (in most cases) viable options, thus we appear to be left with few plausible approaches. The implementation of this feature bewilders me especially when contrasted against the equivalent 2003 behaviors, I'll do some digging and see what turns up. Regarding the /unhost switch, I wasn't aware that this is supported against a 2000 DSA?? With regard to 2003, the behavior when destroying partitions has been altered. The objects are still removed in batches of 5000 but the iterations are no longer bound to the KCC cycle ... they are simply a continuous low priority task. The "for-in-do" loop I outlined is useful within the context of the original question (and may or may not continue to be of use if the /unhost switch is supported ... it depends on the resulting behavior which I've not tested against 2000). Deano -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Turin, Vladimir Sent: Saturday, January 31, 2004 12:17 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Contents of GC I did some tests and looks like method #2 (removelingeringobject) won't work in described case. Apparently MS guys are checking that object is not just "lingering" - it has to be also created more than tombstone lifetime in the past. I tried both repadmin and rootDSE attribute ways - no avail. DSA does not consider those objects "lingering". Toooo smart. There is another reason why this method is not ideal - if you think not only about objects created later than backup was made, but also about modifications... In later case removing stale objects is not enough. Example - some UG membership which could have replicated to GCs, but is different in the backups of primary replica. So looks like method #1 is the only option - re-populating all the partial replicas. Speaking about #1. Eljin mentioned that repadmin has a way how to repopulate just single partial replica from a GC. Is that "/unhost" option you are talking about? I tried it on 2003 - works perfect. Only caveat - kcc may chime in too soon and re-create the replica while "bad" GCs are still around. Need to disable kcc first. Also it seemed to me that /unhost removes all the objects synchronously. So pushing kcc is not really required. Vladimir -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Friday, January 30, 2004 9:06 PM 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;Q31428 2> 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/ 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/
