ConfigMgr SCCM Untrusted Forest AD System Discovery Issue

17

Most of complex and multi tiered environments require to perform AD System Discovery across untrusted forests. Recently, I’ve faced an issue with untrusted forest AD system discovery. Using Active Directory Forest Account, I’m able to publish MP details into “System Management” container of untrusted forest. So, name resolution and Fire-Wall ports are fine between both the forests or Domain Controllers.

When I tried to enable Active Directory System Discovery in SCCM 2012,  it was not working. Had a look at “adsysdis.log” and as always log files are very helpful in SCCM 2012. Following were the errors I could see in the discovery process log. ConfigMgr SCCM Untrusted Forest AD System Discovery Issue 1

INFO: Processing search path: ‘LDAP://OU=COMPUTERS,DC=SCCMUAT,DC=ACNCONFIGMGR’.
INFO: Impersonating user [SCCMUAT\SVC_CM12_AD_FOREST] to discover objects.
INFO: Full synchronization requested
ERROR: Failed to bind to ‘LDAP://OU=COMPUTERS,DC=SCCMUAT,DC=ACNCONFIGMGR’ (0x8007054B)
INFO: CADSource::fullSync returning 0x8007054B
INFO: Reverting from impersonated user to default user.
ERROR: Failed to enumerate directory objects in AD container LDAP://OU=COMPUTERS,DC=SCCMUAT,DC=ACNCONFIGMGR

Some more details about the configuration of AD system Discovery. I’ve configured AD system discovery to discover the systems in untrusted forest. As you know, need to provider container path or LDAP query details, I’ve given the LDAP query “LDAP://OU=COMPUTERS,DC=configmgr1,DC=com”. I was getting the following error 0x8007054B and that error translates to  “The specified domain either does not exist or could not be contacted”. Now, what ….

It’s almost clear error message and that means system or site server is not able to find the domain details. How to resolve this? I’m not excellent in Active Directory to be honest. As mentioned at the starting of this post, I don’t have any other external issues with site server forest and untrusted forest . Also, I’m able to publish MP details into untrusted forest Active Directory.

Sitecomp.log came to help me again in this scenario. How? I wanted to find out the way in which MP details are getting published to untrusted forest and how the communication is taking place between site server and untrusted forest. So, in sitecomp.log, I could see the following entries.

Processing forest ConfigMgr1.com.
Publishing account user account configmgr1\SVC_CM12_AD_FOREST will be used
DS Root:DC=configmgr1,DC=com
Searching for the System Management Container.
LDAP://ACNCMRFOR.ConfigMgr1.com/CN=System Management,CN=System,DC=configmgr1,DC=com container exists.

Oh, yes. You could see, it was using the following LDAP query to communicate with untrusted forest.

LDAP://ACNCMRFOR.ConfigMgr1.com/CN=System Management,CN=System,DC=configmgr1,DC=com

After seeing that LDAP query, I could relate that with AD System Discovery configuration. I’ve added the remote forest domain controller name in to LDAP query of AD system Discovery and it started working !!! The LDAP query used is given below.

LDAP://ACNCMRFOR.ConfigMgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com

ConfigMgr SCCM Untrusted Forest AD System Discovery Issue 2

You can get more details in “adsysdis.log” file (details are given below). Remember, site server or local DNS should be able to resolve the names of the systems which are discovered from untrusted forest. Otherwise, the systems which you’ve discovered don’t get appeared in CM 12 console. To  create DDRs  (Data Discovery Record) for all discovered systems, DNS record or name resolution must be in place.

INFO: Search provider = ‘LDAP’
INFO: Domain controller = ‘ACNCMRFOR.configmgr1.com’
INFO: Succeed to cached binding for LDAP://ACNCMRFOR.configmgr1.com/RootDSE
INFO: Include groups option will be ignored during incremental discovery.
INFO: search filter = ‘(&(uSNChanged>=93223)(|(objectCategory=group)(&(objectClass=user)(objectCategory=computer))))’
INFO: ads path = ‘LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com’
INFO: Bound to ‘LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com’
INFO: successfully completed directory search
INFO: AD Discovery under container LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com found 0 objects
INFO: ——– Finished to process search scope (LDAP://ACNCMRFOR.configmgr1.com/OU=COMPUTERS,DC=configmgr1,DC=com) ——–

17 COMMENTS

  1. Thanks a lot for this contribution! I faced exactly the same Problem and was able to fix it using your instructions. Thank you.

  2. Hello,

    Thanks a lot, I faced exactly the same Problem…
    But for me, into my SCCM environment with AD 2012 R2 and SCCM 1606:

    Replace: “OU=COMPUTERS” by “CN=COMPUTERS”
    idem for “USERS” container for Groups and Users discovery methods (LDAP Query)

    Best regards,

  3. So SCCM attempting to run discovery on an untrusted domain. I can connect and resolve server names in both directions, SCCM to untrusted domain, untrusted domain to SCCM. DNS resolution is working. I have done all this and more and still receive “ERROR: Failed to look up DNS forest GUID error = 1355”. I have removed and republished the forest, ensured that the System Management container is re populated with all the correct entries and it is. I have run mplist and mpcert on the DC and those work correctly. I have tried multiple versions of the LDAP string and I can see that it is connecting to the AD which I can browse in the system discovery item so I know the connection is fine but this error 1355 persists and stops the discovery of the items in the container. SCCM 2002 (Hotfix rollup KB4560496). Any help would be appreciated, I have a number of these untrusted domains to add and this is the first!

      • Yes and I can see it resolving to the correct DC in the adsysdis.log. Here are the entries in the log (names replaced to protect the innocent):
        INFO: ——– Starting to process search scope (LDAP://../DC=,DC=) ——–
        INFO: Processing search path: ‘LDAP://../DC=,DC=’.
        INFO: Impersonating user [\SVC_SCCM_CLIENTPUSH] to discover objects.
        INFO: Incremental synchronization requested
        INFO: CADSource::incrementalSync returning 0x00000001
        INFO: New DC DNS name = ‘..’
        INFO: New highest committed USN = ‘7741830’
        INFO: New service object invocation Id = ‘ecd1eb309e8d8344b1051082c25abc00’
        INFO: Search provider = ‘LDAP’
        INFO: Domain controller = ‘..’
        ERROR: Failed to look up DNS forest GUID error = 1355
        INFO: CADSource::fullSync returning 0x80004005
        INFO: Reverting from impersonated user to default user.
        ERROR: Failed to enumerate directory objects in AD container LDAP://../DC=,DC=
        INFO: ——– Finished to process search scope (LDAP://../DC=,DC=) ——–

      • Ah indeed this is strange … This is domain.com dns lookup is failing …it seems … if you enter DC.domain.com instead of domain.com might help … have you already tried this ?

      • Sorry Anoop, this post stripped out some information. Please see below which has a better version of the log details. Yes I have tried it with the DC name as well as just the domain. From the SCCM server I can ping both the DC and domain by IP and name:

        INFO: ——– Starting to process search scope (LDAP://DC_Name.madeup.test/DC=madeup,DC=test) ——–
        INFO: Processing search path: ‘LDAP://DC_Name.madeup.TEST/DC=madeup,DC=TEST’.
        INFO: Impersonating user [madeup\SVC_SCCM_CLIENTPUSH] to discover objects.
        INFO: Incremental synchronization requested
        INFO: CADSource::incrementalSync returning 0x00000001
        INFO: New DC DNS name = ‘DC_Name.madeup.test’
        INFO: New highest committed USN = ‘7741830’
        INFO: New service object invocation Id = ‘ecd1eb309e8d8344b1051082c25abc00’
        INFO: Search provider = ‘LDAP’
        INFO: Domain controller = ‘DC_Name.madeup.test’
        ERROR: Failed to look up DNS forest GUID error = 1355
        INFO: CADSource::fullSync returning 0x80004005
        INFO: Reverting from impersonated user to default user.
        ERROR: Failed to enumerate directory objects in AD container LDAP://DC_Name.madeup.TEST/DC=madeup,DC=TEST
        INFO: ——– Finished to process search scope (LDAP://DC_Name.madeup.test/DC=madeup,DC=test) ——–

      • Hello Sorry I was checking about this https://snipboard.io/pEvGCY.jpg settings \Administration\Overview\Hierarchy Configuration\Active Directory Forests

        If you have tried this I will surely try this. I have seen this resolves some of the discovery issues.

        The following error is kind of generic access denied error – error …but the specific DC might help there also

        INFO: CADSource::fullSync returning 0x80004005
        INFO: Reverting from impersonated user to default user.
        ERROR: Failed to enumerate directory objects in AD container

      • Better version of the log:

        INFO: ——– Starting to process search scope (LDAP://DC Server.madeup.test/DC=madeup,DC=test) ——–
        INFO: Processing search path: ‘LDAP://DC Server.madeup.TEST/DC=madeup,DC=TEST’.
        INFO: Impersonating user [madeup\SVC_SCCM_CLIENTPUSH] to discover objects.
        INFO: Incremental synchronization requested
        INFO: CADSource::incrementalSync returning 0x00000001
        INFO: New DC DNS name = ‘DC Server.madeup.test’
        INFO: New highest committed USN = ‘7741830’
        INFO: New service object invocation Id = ‘ecd1eb309e8d8344b1051082c25abc00’
        INFO: Search provider = ‘LDAP’
        INFO: Domain controller = ‘DC Server.madeup.test’
        ERROR: Failed to look up DNS forest GUID error = 1355
        INFO: CADSource::fullSync returning 0x80004005
        INFO: Reverting from impersonated user to default user.
        ERROR: Failed to enumerate directory objects in AD container LDAP://DC Server.madeup.TEST/DC=madeup,DC=TEST
        INFO: ——– Finished to process search scope (LDAP://DC Server.madeup.test/DC=madeup,DC=test) ——–

      • Yes, that’s exactly as I have it set. I did that today. Yesterday I removed the forest and made sure it cleared out the System Management folder in AD on the untrusted domain, which it did and then today I added it in exactly as you advise here and it repopulated correctly. I am at a bit of a loss, nothing I have found on the internet so far seems to resolve this issue.

  4. Anoop, there is nothing in the event logs on the DC in the untrusted domain. I am wondering if this might be something to do with the DNS server being 2012 R2 in the SCCM domain and the one in the untrusted domain being 2008 R2. Maybe the issue is not with the target domain but the DNS server in the SCCM domain. Every article I have seen say that the recommended steps should fix it but I have literally tried everything. Looks like a MS call will need to be raised. Thanks for your time

    • This might be one of the rare occasion host file comes to rescue.

      Can you try to add this DC server entries into SCCM primary server host file. This can help us to eliminate those complex scenarios with DNS.

      What you think ?

      • I’m a few steps ahead of you there. I have added both the entries for the server and the domain in to the hosts file and can ping not only the DC but all other servers in the untrusted domain by name and IP from the SCCM server, therefore, I assume DNS is working correctly. I can also ping the SCCM server from the untrusted domain by name and IP address, routing has been set to allow this. I just added a hosts entry on the DNS server and the conditional forwarder now automatically resolves the DC but it has made no difference to the discovery. I have a feeling it is going to be something really simple, its going to be a registry that is 1 not 0, but rest assured I will post it if MS manage to solve the issue.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.