In most cases people have configured their User, System or Group discovery correctly by adding an LDAP path that SCCM will start discovering from.

Could be an OU [LDAP://OU=Computers,DC=Domain,DC=Local] or even the domain root [LDAP://DC=Domain,DC=Local].

“But, but! We are missing several objects and they seem to be residing on one or more of the child domains!”

Fear not! SCCM have logs, and logs will always help us when we are in dire need of guidance.. Browse through:

  • adsgdis.log (Group Discovery)
  • adsysdis.log (System Discovery)
  • adusrdis.log (User Discovery)

Somewhere in these logs you will find what might be the culprit causing problems. Most commonly it can be 2 things:

  1. You haven’t defined the child domain LDAP path in your Discovery, you might think that because you have Discovery running on the parent domain your child domains will be covered by that.. It won’t. You need to insert child domain LDAP paths for the type of discovery you want to run.
  2. Rights, permissions, access… Call it what you want, it can quickly turn into a troublesome solution for the administrator. By default SCCM uses the server computer account, and if you want to keep on using that you need to make sure the computer account have read rights to the child domain. Otherwise you can specify a discovery account when you add the child domain LDAP path within the specific Discovery you want to run(Must ofc also have read rights).

In most cases the 2 above mentioned situations will be what you are seeing in regard to the blog title, can ofc. be other things.. But who knows.

Ill be back..