Hi Guido, I have not tested what you mention. In the example I used I know which objects are the "poltergeists" and therefore I also know what their parent OU is. In a real situation I probably will not know which objects will be poltergeists. I think the problem with this is that deleting the parent OU probably also means: move other valid objects first to another OU, document linked GPOs, document admin delegation, etc.. This solution may solve one problem, but I think it will also cause other "points of attention"
Regards, Jorge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Monday, February 02, 2004 09:39 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Contents of GC Jorge, are all of these stale objects in the same (or few) OU(s)? If so, I wonder what would happen, when you now delete these "empty" OUs on a DC of DOM_B (if they're not really empty, it may be worth to move whatever objects it contains to a different OU first)? This change will obviously replicate to the GCs, so that the "stale" objects on the GC will lose their Parent OU... I believe what should happen now, is that the GC moves the "stale" objects to the LostAndFound container which is usually used to catch these types of "orphaned" objects => this will change the USN of these objects, just like on a "living object"... However, now you've got a situation where the GC wants to replicate the changes back to DOM_B, but can't as DOM_B only has _outbound_ connection objects to any GC (of another domain) out there => so called "Poltergeists" ;-) After you've now forced this wacky situation, it would be worth to check if this is good enough for "Repadmin /removelingeringobjects" to get going... /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jorge de Almeida Pinto Sent: Montag, 2. Februar 2004 08:49 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Contents of GC Hi, I just created one new object in DOM_B with the same name as one of the old objects that still exists in de GC data of DCs in DOM_A. It is not nice what happens then....;-((( When searching for people in AD the newly created user is shown. The old object is rename to CN=<NAME>[]\CNF:<GUID> because of a conflict in the GC data. The event viewer shows: ID 1226: "The following object was created on a remote domain controller with an object name that already exists on the local domain controller. " blabla.. I tried the following also "Repadmin /removelingeringobjects" to see if it was possible to delete de old objects from the GC data "Repadmin /delete" to see if it was possible to delete the read-only naming context from the GC and have it rebuild it again afterwards At the moment I think the only solution is to unGC all GCs, wait until GCs are demoted and then promote all DCs back to GC. This is not nice, but I think the only solution! Jorge -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eljin B. Brown Sent: Friday, January 30, 2004 10:41 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Contents of GC 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----- From: [EMAIL PROTECTED] [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----- From: [EMAIL PROTECTED] [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/ 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/ 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/
