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.
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
Configuration Overview -
To complete a configuration that will facilitate the given scenario we will complete the following -
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.
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.