Cross Forest Support in ConfigMgr 2012 Part 2: Forest Discovery, Publishing, and Client Push Installation.


Intro –

In the previous ‘simple’ example the assumption was that a very small group of known clients would be managed. Because of this, relying on basic ‘manual’ client installation and location lookup mechanisms (manually specified Lookup MP) could have been an acceptable solution. If the scenario was to shift from a few known clients to many unknown clients then the cross forest configuration story could change slightly to facilitate a more automated client installation method, location look up process, and overall management experience.

Scenario –

For this scenario we will continue to use a non-trusted, well connected DMZ forest as subject matter, however in this example the forest/domain will contains 50+ computers and this number will fluctuate as machines are added to and/or removed from the environment. In order to facilitate the management of the larger and unknown / unpredictable footprint of the clients, adding an automated computer discovery method and client installation method will ease the administrative burden. Additionally while the continued use of a manually specified lookup management point would work for this this example, we will instead look at a new feature to System Center 2012 Configuration Manager allowing for the publishing of Configuration Manager Site data into a non-trusted forests active directory. The clients residing in the non-trusted forest will then be able to resolve site specific data such as Management Point and Boundary information in an automated fashion using this cross-forest published data.

So to summarize, the goal is to

  • Discover the untrusted forest and publish Configuration Manager Site information into the non-trusted forest.
  • Configure AD System Discovery to run against the non-trusted forest.
  • Configure Client Push Installation to work in the non-trusted forest.

 

Configuration Overview –

To complete a configuration that will facilitate the given scenario we will complete the following –

  • Add the non-trusted forest to the Active Directory Forest Hierarchy Configuration Node in the ConfigMgr console. This will discover information about the forest such as sites and subnets and also allow us to further configure publishing to this forest.
  • Publish the ConfigMgr 2012 site information into the remote untrusted AD forest. The Active Directory of the non-trusted forest will require the CM 2007/2012 schema extensions and the System Management container will need to exist prior publishing.
  • Configure System Discovery for the remote forest.
  • Ensure that boundaries have been created that will represent each client in the remote forest and that these boundaries have been added to a configured boundary group.
  • Configure Client Push Installation with an account suitable for client installation in the remote non-trusted forest.
  • Deploy clients and observer site system location.

 

Configuring Forest Discovery and Publishing –

Adding the non-trusted forest, simple configuration.

Adding the non-trusted forest. Ensure an account with permissions to the non-trusted forest is specified.

Select the sites to be published in the non-trusted forest.

Example of cross forest published site and site role information – what we are looking at here is ADUC of the non-trusted non-CM hosting forest – Click Image for a more detailed view.

Finally from the Active Directory Forest node we can see status on both forest discovery of and publisihng to the remote forest – Click Image for a more detailed view.

 

Configuring AD System Discovery –

In order to configure AD System Discovery an entry (or multiple entries) needs to be added to the sites AD System Discovery Properties. Because this is a remote un-trusted forest the Browse button will not display the active directory structure. The LDAP path for the remote forest will need to be entered manually. Additionally an account with the appropriate permissions to the remote forest will need to be specified for the discovery method.

Adding the non-trusted forests LDAP path to the discovery job, ensure that an account with read access to the non-trusted forest is specififred.

Here is what the final configuration for this example may look like – notice that with this configuration the systems from two forests will be discovered.

AD Systems Discovery General Tab.

Adsysdis.log – example of AD System Discovery binding to remote forest path using the specified account – Click Image for a more detailed view.

Post Discovery Console View – I’ve kind of cut out the screen shot but towards the bottom of the Domain column we can see objects from both forests – Click Image for a more detailed view.

 

Configure Client Push Installation –

At this point we have discovered the non-trusted forests, published site information into the forest, and then discovered all system objects in this forest using AD System Discovery. The final piece to this cross-forest management solution is to configure a client installation method. For this example we will use Client Push Installation.

In order to configure client push installation, first ensure that the client installation mechanism is enabled.

Client Push Installation General Tab.

Add an account that has the proper permissions (local administrative) to the computers in the non-trusted forest.

Client Push Installation Accounts Tab.

CCM.Log showing the clinet push installation process – notice that the client push installation account from the non-trusted forest is used to connect ot the administrative share on the target computer.

CCM.LOG found on site server – Click Image for a more detailed view.

Once the client has been installed we can observe in locationservice.log that not only have we resolved the location of multipul Management Points but that the proces has been compelted using the information published in the non-trusted forest. Also if you look closley you will see that of the two discovered MP’s that neither are members of the trusted forest.

LocationServices.log – Click Image for a more detailed view.

Console view of cross forest clients – aint that prety..

Note – Depending on your client approval forest wide settings, you may have to manually approve each client that resides in the non-trusted forest. Refer to this article for more information – TechNet: Security and Privacy for client in Configuration Manager.

Closing –

What I hope to have shown in this article is that through a combination of new and old Configuration Manager features it is entirely possible to manage a group of clients existing in a non-trusted forest without having to deploy infrastructure into that forest. Through the ability to discover the forest, publish site data into the forest, and then automate client deployment to the forest, an automated and self-servicing management story can be crafted.

Stay tuned for the next installment of this blog series in which I will demonstrate the introduction of infrastructure such as MP’s and DP’s into the non-trusted forest. This does increase the complexity of the configuration somewhat, however is not a difficult task and will be necessary in instances where machines residing in the non-trusted forest may not be well connected or where the need to localize client to site system communication is desired.

Comments (16)

  1. Anonymous says:

    Great info. Will be using to plan a deployment in my environment.

  2. Anonymous says:

    Sorry Joachim – I've tried to replicate the issue in my lab by fudging both the connection account and the target LDAP path, but neither produce the same error. Doing some quick research on E_ADS_CANT_CONCERT_DATATYPE produces several results but nothing that stick out. I would consider opening up a case on this if you cannot get yourself get it resolved.

    thanks.

    neilp

  3. Anonymous says:

    Hi, I followed this guide and added a untrusted 2012 forest, but and all connection tests are successful, However when I run the the discovery jobs they all give the samme error:

    Active Directory System Discovery Agent failed to bind to container LDAP://DC=VESSEL1,DC=LOCAL. Error: E_ADS_CANT_CONVERT_DATATYPE.

    Any idea what the problem is?

  4. Anonymous says:

    -edit- Will be using this article to help plan a deployment in my environment.

  5. Anonymous says:

    Thanks for the quick reply. I started a topic of this issue where you can find some more detailed information if you are interested:

    http://www.windows-noob.com/…/index.php

    I though it was caused by a 2012 forest functional level, but when I reinstalled and made all forests and domains 2008R2 level, the same error message appears on two different untrusted domains I created.

  6. Phil Crawford says:

    Great Info. But, what about connection requirements for LDAP to non-trusted forest. Specifically, does the site server in this scenario need LDAP connectivity, including high ports, to the DC's of the non-trusted forest?

    Info in this article is being used to design our multi-forest implementation.

  7. Phil Crawford says:

    Neil,

    What is missing from both the Cross-Forest planning document and from the above example, is the requirement for the site server which is doing discovery to be able to communicate directly to the DCs in the untrusted forest using LDAP. I have been fighting my security team over this. It appears to need both UDP in both directions and TCP with DC-end at 389 plus, in our environment, 49155.

    It would be really nice if I could get this documented at Microsoft. (I have 2 untrusted forests to manage for servers. No problem with discovery on Test but blocked on Dev.)

    It would have been so much simpler for myself had there been discovery VIA the MP/DP server on the domain. ? an extra Communication Point role for this purpose??

  8. Ben says:

    Neil. Thank you for the documentation. What would be your recommendations or best practice to manage the following scenario

    I have 4 DMZ no trust relationship in different forest. I want to have only one site server sitting in my corporate network because it is managing three domains (trusted each other). In each DMZ I have 40 and max 270 clients. Can I manage these DMZ clients by opening ports 80/443/8351to my site server? Do I need PKI cert? If yes, how do I setup? Or do I have to put DP/MP/SUP in each DMZ? I prefer the first option to the second one. I might get new DMZ in the near feature and don’t want to add MPDP for each DMZ created.

    Thank you

    Ben

  9. lance lyons says:

    what happens if the active directory (LDAP) site in the untrusted domain does not resolve in the domain that has configuration manager?  Did you have to manually add DNS A record for the active directory machines or domain controllers?

  10. Lance,

    You would need to use conditional forwarders or secondary zones for the two DNS environments to "talk" to each other for ConfigMgr 2012 to make the LDAP connection.

  11. Ian says:

    Hi Neil,

    Do you know if user policy assigned works with untrusted forests?  We're getting an issue where the account used to download policy is in the untrusted forest, so can't get to the MP.  Is this supported?

    We're investigating, but I think we need to put MPs in the untrusted forests, which could be a problem for us.

  12. Pete says:

    Ian,

    I had similar issue, when the MP tries to talk back to the Site System it can't becuase it has the credentials of untrusted forest. So during the MP installation , under third selection of the MP role "Management Point Connection Account", specify the account that has the rights to the Site database. Once the installation completes, go to the client machine and check "ClientIDManagerStartup.log" log.

    Hopefully this help.

  13. Pete says:

    Matt,

    We have two different forests besides the production, DEV and Test, but they share the same domain name so we couldn't create conditional forwarder. (Dev.xyz.com & Test.xyz.com). To get around this issue, I created stub zone on both sides (Site server forest and untrusted forest) and pushed DNS suffix for other forest via GP. I still cannot do the forest discovery but am able to discover new systems

    LDAP://"IP address of DC"/CN=Computers,DC=Test,DC=xyz,DC=com and specify account in untrusted forest

    Please advise if I should look  into going about this different route or this is ok. Also are you part of the premier team?

    Thanks,

    Pete

  14. Ian says:

    To get user policy and Affinity working in untrusted forests we're placing MPs into those untrusted forests.

    Pete, thanks for the pointer, we're just getting that bit set up now.

    cheers,

    Ian.

  15. Hi Pete,

    Sorry for the delayed response, I just saw this.  Yes, I am ConfigMgr 2007/2012 PFE with MSFT.  Stub zones works as well for establishing resolution between the forests.  In my opinion, zones are more efficient than forwarders and I always recommend using a zone.  Forest discovery is not required to discover new systems in a cross forest scenario.  Forest discovery is only required if you wish to discover sites and subnets of the forest to convert to boundaries for ConfigMgr 2012.  ConfigMgr 2012 just needs the forest relationship defined and System Discovery does all the work after that.  I recently worked with a customer who had a similar issue as you have stated.  I have also seen the verification tool for the accounts fail to validate LDAP, but yet you can still discover resources in the other forest.  You can also freely check and uncheck the forest discovery box on the forest connection and still publish successfully to the other forest, as long as the specified account has rights to publish to the System container in the other forest.  However, if you do not leverage forest discovery for the other forest, you will need to manually create the boundaries for all clients you intend to manage in ConfigMgr 2012.

    Best of luck Pete.

  16. Anonymous says:

    Introduction –
    Up until this point each scenario in this series of articles has detailed the management