I'm not sure if this started with upgrade to SP2, but there are 2 OU's that are clearly not being searched for system groups that had previously been working fine. I can add a new group in a child domain and it searches fine. There is one OU that is searching in parent domain correctly. I have tried removing the containers that are not searching properly ("ou not working 1" and "ou not working 2" and adding on a container that they both are inside of ("ou not working")and it still does not search that OU at all. Any ideas where to start looking for answers? OU=working --> searches child containersOU=not working--> OU=not working 1; OU=not working 2Thanks.

Here is the next section of the log with OU names changed after adding the computers container:The Schedule token value in the site control file is 004659C000100018. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)Incremental synchronization is disabled. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)Optional attributes count = 0 SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)!!!!Valid AD container 0: LDAP://OU=Older,DC=Domain,DC=COM SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)!!!!Valid AD container 1: LDAP://OU=NewChild 2008,DC=child,DC=Domain,DC=COM SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)!!!!Valid AD container 2: LDAP://CN=COMPUTERS,DC=Domain,DC=COM SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)Configuration data have changed. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)Starting the data discovery. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/29/2009 11:29:17 AM 4960 (0x1360)

OK - I also just verified that the ADSys.log shows the OU as a valid container that is not listed in ADSysGrp.log. Does it matter if there are spaces in the OU name? Why would it matter in the system group discovery, but not the system discovery?More details to add:we have one site server running SCCM 2007 SP2 R2 on Server 2003 SP2 with R2I just verified that the last time the AD system group discovery ran was the night before I upgraded SCCM 2007 SP1 R2 to SP2.Anything else that can lead to a solution would be appreciated! Thanks.

Do you have the recursive and include groups checked?

The child domain is reporting back fine. The problem I see is one of the OU's in our parent domain. It was reporting back fine before I installed SP2 for SCCM, but now it skips over this OU (named "domain 2008"). I have tried deleting it from the list and re-adding it, and I have tried adding the OU's I have listed under the domain 2008 OU for home office and remote sites. None of these steps will work. Again, the child domain is reporting back fine. Both the OU in the child domain and the OU not reporting have spaces in the name, so I don't think it is the space in the name causing an issue. I am using a cutsom LDAP query using the browse button in the New Active Directory Container window when I add the OU.

Could you post the names of the OUs to be discovered here (without changing or replacing names)? You can also have a look at the site control file to see if the OUs to be discovered are listed there.

OK. Here is text from the site control file directly. The containers not getting searched are "Home Office" and "Remote Sites" inside the "VFB 2008" OU. If I delete those from the configuration window and add "VFB 2008" and check recursive, then I get same results. System Group discovery skips over these containers.BEGIN_PROPERTY_LIST <Start On Master Site Control File Changes> <"Component","SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT|SCCM"> END_PROPERTY_LIST BEGIN_PROPERTY_LIST <AD Containers> <LDAP://OU=VFB,DC=VAFB,DC=COM> <0> <1> <LDAP://OU=EBCA 2008,DC=EBCA,DC=VAFB,DC=COM> <0> <1> <LDAP://OU=REMOTE SITES,OU=VFB 2008,DC=VAFB,DC=COM> <0> <1> <LDAP://OU=HOME OFFICE,OU=VFB 2008,DC=VAFB,DC=COM> <0> <1> <LDAP://CN=COMPUTERS,DC=VAFB,DC=COM> <0> <1> END_PROPERTY_LISTHere is excerpt from ADSysGrp.log for discovery:** Service Thread is starting ** SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:53 PM 6128 (0x17F0)INFO: Component setting of ACTIVE was specified in the site control file. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)INFO: Removing redundant containers and validating them... SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)The Run Count value in the site control file is 11. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)The Schedule token value in the site control file is 004659C000100018. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)Incremental synchronization is disabled. SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)Optional attributes count = 0 SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)!!!!Valid AD container 0: LDAP://OU=VFB,DC=VAFB,DC=COM SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)!!!!Valid AD container 1: LDAP://OU=EBCA 2008,DC=EBCA,DC=VAFB,DC=COM SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)!!!!Valid AD container 2: LDAP://CN=COMPUTERS,DC=VAFB,DC=COM SMS_AD_SYSTEM_GROUP_DISCOVERY_AGENT 12/30/2009 4:29:54 PM 6128 (0x17F0)

I opened a ticket with Microsoft and they found it was a known bug with SP2 system group discovery. When 2 OU's have similar names then only the first OU will be discovered. Subsequent OU's are skipped. I was able to remove the VFB OU and as soon as I did the VFB 2008 OU was discovered appropriately. They are working on a hotfix now that is in testing, so open up a case with them if you see this same problem.Thanks again for all your help!

Looking at adsysdis.log, here is what I see that indicates an issue: When recursive is checked - I see 12 Valid AD Containers with LDAP path listed - I see discovered objects from the first LDAP search above. None from the "redundant containers" When recursive is not checked - I see 15 Valid AD Containers. Message in Log File: Info: Removing redundant containers and validating them. The Site Control File (sitectrl.ct0) appears to change according to whether recursive is selected or not. Currently, with recursive not selected, I see 15 LDAP searchs in the file. Is there something else I should look at?