Share via

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

  • Article

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

  • Anonymous
    January 01, 2003
    Great info. Will be using to plan a deployment in my environment.

  • Anonymous
    January 01, 2003
    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

  • Anonymous
    January 01, 2003
    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?

  • Anonymous
    January 01, 2003
    -edit- Will be using this article to help plan a deployment in my environment.

  • Anonymous
    January 01, 2003
    Thanks for the quick reply. I started a topic of this issue where you can find some more detailed information if you are interested: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.

  • Anonymous
    February 28, 2013
    The comment has been removed

  • Anonymous
    April 01, 2013
    The comment has been removed

  • Anonymous
    April 19, 2013
    The comment has been removed

  • Anonymous
    June 03, 2013
    The comment has been removed

  • Anonymous
    June 22, 2013
    The comment has been removed

  • Anonymous
    July 12, 2013
    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.

  • Anonymous
    July 16, 2013
    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.

  • Anonymous
    July 16, 2013
    The comment has been removed

  • Anonymous
    July 24, 2013
    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.

  • Anonymous
    July 24, 2013
    The comment has been removed

  • Anonymous
    September 09, 2014
    Introduction -
    Up until this point each scenario in this series of articles has detailed the management