RE: [ActiveDir] Another new joeware tool - GCChk

[Robbie Allen]

Don't even get me started on medial searches, which in my mind was one of the glaring deficiencies with W2K AD compared to the other LDAP-based directories I'm familiar (e.g., iPlanet/SunOne/Java whatever).  With W2K, you might as well not even try them.  Horrible performance.  In a 50k object domain I've seen medial searches tack on another 10 seconds to the query time (compared to the same query but remove the leading star).  Allowing users to configure tuple indexes in W2K3 is fine, but IMO tuple indexing should be the norm for common attributes.   Sync'ing objects to another directory for the sole purpose of finding conflict objects sounds like an overcomplicated solution to me.  How about if MS just flagged conflict objects as being in conflict via some attribute :-?  Telling people to install ADAM and download the AD/ADAM synchronizer is going to sound too much like work to do something as (conceptually) simple as finding conflict objects.   Joe, here are the types of objects I consider to be "bad": - conflict objects - lingering objects - objects w/o guids - objects in the LostAndFound container - user objects w/dup SIDs - user objects w/dup UPNs   Then there are a bunch of data maintenance related things I consider "not optimal": - missing subnet objects (requires parsing the system event log on DCs) - sites with no subnets (or site links) - computer objects for Windows 2000 and higher computers that have a password age of 6 months or more - groups with no members - GPOs that aren't linked - etc.   I'm sure there are many others people can think of.   Robbie Allen http://www.rallenhome.com/ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Monday, July 12, 2004 10:03 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Another new joeware tool - GCChk > Hmm I can't think of a single way that is more efficient to get that info... Worse yet that is a medial search and I'm betting > no one has set their cn index to be a tuple index.   Whether this is of interest or not would be related to the # of times the search is run. The more often you plain on doing said search, the easier this is to justify. It should be noted, however, that tuple indexes are one of the most expensive types in AD. A string of length N would yield N-2 index entries where N>=3..   > 3. Have some sort of sinking tool that just watched for those objects and when it found them, synced them to another > directory and you could just pull them out of there.   This statement comes with the assumption that all CNF’s are consistently found on all dsa’s throughout the forest as if this is not true, looking at one DSA’s CNF’s does not mean you know the CNF’s found on another DSA. I think time has told us that this is an unfair assumption. (think lingering objects) If you did want to do this, however, I think this is a good ADAM usage scenario. Use the new AD syncher tool up on www.microsoft.com/adam (currently beta) and do it against ADAM. Light weight, and zero incremental cost on top of the server it sits on. You can also medial substring index it up in ADAM and eat the pef there, probably not a big deal given usage of this dsa.   For the timeout problem, have you tried to use a paged search, and just keep requesting the next page as you get the one before it (despite amt of time the page took to deliver)? Does that help the timeout problem at all?     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, July 12, 2004 8:11 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Another new joeware tool - GCChk   Hmm I can't think of a single way that is more efficient to get that info... Worse yet that is a medial search and I'm betting no one has set their cn index to be a tuple index.   The only things I can think of are   1. Use a standard LDAP query and crank the timeout value through the roof (-t option in adfind).   2. Have a program that keeps track of USN's when it does its searches so that it can have the last USN that was in place when it did its last search. That would drammatically limit the number of objects. However if you pointed at a new DC or had to rebuild the DC or the first time you ran it it would have to start at the beginning anyway.   3. Have some sort of sinking tool that just watched for those objects and when it found them, synced them to another directory and you could just pull them out of there.     Kind of would be interesting to have a "bad" things service that watched for "bad" things in the directory and would flag them out when it found them. These objects would be good things to flag, what else could be flagged? Objects w/o GUIDs? What else?       From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robbie Allen Sent: Sunday, July 11, 2004 9:56 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Another new joeware tool - GCChk Looks interesting, I'll check it out.   On a somewhat related topic, I've always wanted an "efficient" tool for finding conflict objects.  Most domains I've looked at have more than a few hanging around; especially computer objects.  The problem is the only way I know of to find conflict objects is to use a terribly inefficient search filter like (cn=*\0ACNF:*).  This can easily timeout in large domains.  But other than the name, I'm not aware of any other way an object is tagged as being in conflict.   Robbie Allen http://www.rallenhome.com/   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, July 11, 2004 5:14 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Another new joeware tool - GCChk Ok, those of you who have been following Todd's recent adventures may have come to the same conclusion I did that it would be nice to have a tool that could check a GC and see if it has lingering objects on it.   Well I threw together something quick and dirty this afternoon that should do that. It is not extremely efficient in how it does the work but should theoretically work. I didn't test with lingering objects but I did test with renames and deletes with a slow replication link to the GC and it always found the objects that were different on the GC partial NC than in the full NC on the proper DCs.   Basically you tell the program to check a specific GC. It will then enumerate the partitions and find the nearest (per normal nearest methodology) DC for each partial NC and then enumerate every object in every NC (getys DN and objectGUID) and do a lookup of that object against the proper DC. If it does not find the exact DN, it will then do a objectguid search in case the object was renamed, moved, or deleted and that hasn't replicated to the GC yet. If it finds the object, it will display the new DN and the whenChanged timestamp. Note that by default you must be an Admin to find/display objects that have been deleted so if you aren't an admin you will not know the whole story if it finds objects on the GC that it can't locate on the DCs. Note though, the first pass could be with a normal userid and if you have objects it can't find you could rerun as an admin or check deleted objects yourself. Oh one thing to note that if the object has been moved to another domain then this won't find it either, I didn't feel it was worth trying to chase in that case because that requires a GC and the GC just told me where it thought it was at and I looked there...   In order to really check a forest you will need to check at least two GCs. This is because the tool will not check the default NC of the GC you select. So if you have say 5 domains in your forest named joe.com, child1.joe.com,child2.joe.com,child3.joe.com,and child4.joe.com running the tool against a GC for joe.com would check all of the children domains but not joe.com. Running against one of the children domains would check joe.com and all but that one child domain.   If you find issues with this tool, let me know. If you find lingering objects with it I WOULD LOVE to hear about that. I can then say for sure that someone has used it and found lingering objects.   Here is a sample run showing it finding some deleted objects... Note that once the replication occurred to the GC, the deleted objects would no longer show up in the report.     [Sun 07/11/2004 16:28:57.36] F:\DEV\cpp\GCChk>gcchk -gc 2k3dc10   GCChk V01.00.00cpp Joe Richards ([EMAIL PROTECTED]) July 2004   Collecting NCs from partitions container... Locating DCs for other NCs... NC: DC=joe,DC=com -- 2k3dc01.joe.com Skipping local NC DC=child1,DC=joe,DC=com Comparing DC=joe,DC=com .....   Objects Checked  : 524 Object Issues    : 0 Objects Not Found: 0   The command completed successfully.   [Sun 07/11/2004 16:30:11.65] F:\DEV\cpp\GCChk>adfind -b ou=admodundeletetest,ou=testou,dc=joe,dc=com  -f "(&(objectcategory=computer))"  -dsq  |admod -del   AdMod V01.00.00cpp Joe Richards ([EMAIL PROTECTED]) July 2004   DN Count: 5 Using server: 2k3dc01.joe.com Deleting specified objects...    DN: cn=undel-a1,ou=admodundeletetest,ou=testou,dc=joe,dc=com...    DN: cn=undel-a2,ou=admodundeletetest,ou=testou,dc=joe,dc=com...    DN: cn=undel-a3,ou=admodundeletetest,ou=testou,dc=joe,dc=com...    DN: cn=undel-a4,ou=admodundeletetest,ou=testou,dc=joe,dc=com...    DN: cn=undel-a5,ou=admodundeletetest,ou=testou,dc=joe,dc=com...   The command completed successfully   [Sun 07/11/2004 16:30:16.49] F:\DEV\cpp\GCChk>gcchk -gc 2k3dc10   GCChk V01.00.00cpp Joe Richards ([EMAIL PROTECTED]) July 2004   Collecting NCs from partitions container... Locating DCs for other NCs... NC: DC=joe,DC=com -- 2k3dc01.joe.com Skipping local NC DC=child1,DC=joe,DC=com Comparing DC=joe,DC=com .... ERROR: GC DN for object not found:    CN=undel-a1,OU=AdModUndeleteTest,OU=TestOU,DC=joe,DC=com -- {DB12BE55-CDAC-4C06-A9FB-280CF445AE73}     Found this:       CN=undel-a1\0ADEL:db12be55-cdac-4c06-a9fb-280cf445ae73,CN=Deleted Objects,DC=joe,DC=com -- 20040711203016.0Z   ERROR: GC DN for object not found:    CN=undel-a2,OU=AdModUndeleteTest,OU=TestOU,DC=joe,DC=com -- {3DA8AB38-D8A5-40F0-8CC2-13A43BAD59B7}     Found this:       CN=undel-a2\0ADEL:3da8ab38-d8a5-40f0-8cc2-13a43bad59b7,CN=Deleted Objects,DC=joe,DC=com -- 20040711203016.0Z   ERROR: GC DN for object not found:    CN=undel-a3,OU=AdModUndeleteTest,OU=TestOU,DC=joe,DC=com -- {66C49F17-064B-41A3-8E60-10E3DBF1C1C0}     Found this:       CN=undel-a3\0ADEL:66c49f17-064b-41a3-8e60-10e3dbf1c1c0,CN=Deleted Objects,DC=joe,DC=com -- 20040711203016.0Z   ERROR: GC DN for object not found:    CN=undel-a4,OU=AdModUndeleteTest,OU=TestOU,DC=joe,DC=com -- {735CDAAF-1D21-4264-BB84-8C64B05F6247}     Found this:       CN=undel-a4\0ADEL:735cdaaf-1d21-4264-bb84-8c64b05f6247,CN=Deleted Objects,DC=joe,DC=com -- 20040711203016.0Z   ERROR: GC DN for object not found:    CN=undel-a5,OU=AdModUndeleteTest,OU=TestOU,DC=joe,DC=com -- {EA628CDB-069A-4993-B7BB-FCA6DD206F8B}     Found this:       CN=undel-a5\0ADEL:ea628cdb-069a-4993-b7bb-fca6dd206f8b,CN=Deleted Objects,DC=joe,DC=com -- 20040711203016.0Z .   Objects Checked  : 524 Object Issues    : 5 Objects Not Found: 0   The command completed successfully.   [Sun 07/11/2004 16:30:19.65]