Freigeben über

Cross Forest Support in ConfigMgr 2012 Part 1: Simple Management

  • Artikel

Cross Forest support in Configuration Manager is a topic often discussed, can be confusing, and has changed considerably with the introduction of 2012 Configuration Manager. While each environment may have its own needs based on environmental configuration, there are some ‘Hard’ technical requirements that must be followed in order to achieve cross forest management of clients, site systems, etc. Fear not, there are many supported configurations that can be used to support cross forest clients. Understanding the reasons to use a specific configuration, technical requirements for each configuration, and configuration steps should help clear up confusion around cross forest support and also arm you with the information you need to select the proper configuration for your environment.

I will be breaking this subject down into four separate blog posting.

  • Introduction to Blog Series. I will also include in this first posting Scenario 1 - Simple Management of a few cross forest clients.
  • Scenario 2 – More complex management of a larger number of cross forest clients (introduce discovery and cross forest client push installations).
  • Scenario 3 - Introducing the placement of ConfigMgr infrastructure (MP, DP) in the cross forest environment.
  • Scenario 4 – Child site placement (Child Primary or Secondary) in the cross forest environment.

With each of these blog postings I intend to demystify the technical requirements of cross forest communication. I will do so using a series of examples starting at what may be the most simple configuration working up to more complex configurations. For each example or scenario I will detail why you may choose the specific configuration, the configuration steps needed to achieve cross forest management, and will also include gotchas, tips, logging, etc.. As already mentioned I will be focusing on four specific scenarios throughout this series of articles.

  • Simple management of a small group of cross forest clients – this will involve no object discovery, no added infrastructure, and manual client deployment.
  • More complex yet still simple management of a larger collection of cross forest clients – this will involve cross forest site publishing, cross forest system discovery, automated client installation, however will not add any additional infrastructure into the remote untrusted forest.
  • Cross Forest with added Infrastructure – here we will be adding into the remote forest ConfigMgr infrastructure such as a Management Point and Distribution Point.
  • Child Sites placed in the remote forest – finally we will look a more complex configuration which will be placing a full site in the remote forest. Note – this will require a two way forest trust (more on that in a later posting).

 

Cross Forest Technical Requirements –

Before getting started with the cross forest examples, let’s examine the technical requirements or rules that have been put in place for the support of cross forest communication. In addition to technical limitations and rules I will include in this list a few of the items used to support cross forest client management. So think of this list as laying the ground work or terminology for the remainder of these blog postings.

  • Inner-site Communication (site to site communication) exists in the form of both File Based Replication (SMB Port 445) and Database Replication (TCP/IP port 4022 by default).
  • In order to install and configure a child site (primary or secondary), the child site server must be located in the same forest as the parent site or reside in a forest that contains a two way trust with the forest of the parent (CAS or primary).
  • Site System Roles (MP, DP, etc.) with the exception of the Out of Band Service Point and the Application Catalog Web Service Point can be deployed in an untrusted forest.
  • The SLP functionality as known in ConfigMgr 2007 is now performed by a Management Point. In this blog I will refer to this as the Lookup Management Point.
  • Most of these items were taken from this TechNet article – please refer to the article for more information - Planning for Communications in Configuration Manager .

 

Scenario 1 Simple: Cross Forest Management of Clients with no added infrastructure.

Scenario -

The first scenario is what I would consider the most simple (both in implementation and impact). In this scenario you may have a small group of known clients residing in a non-trusted domain. Because the clients are known there may be no need for discovery of any sort. These clients may either be well connected (network connectivity) to a cross forest distribution point, or content distribution is of no concern.

A practical example of this scenario may include a DMZ forest that contains less than ten clients. Each of these ten clients is well connected to the cross forest ConfigMgr infrastructure so network utilization between the clients and ConfigMgr MP’s / DP’s is not of concern. Because the number of clients is relatively small and no additional clients will be introduced to the environment it may also be practical to manually install the Configuration Manager agent. A lookup MP will be specified at client installation time which will handle location services.

 

Configuration -

Given this scenario, the steps needed in order to manage this small group of clients with a cross forest located 2012 Configuration Manager site are as follows –

  • Ensure that the Configuration Manager environment is running and that at least one Management Point has been installed.
  • Configure a Network Access account on the site of the Configuration Manager environment.
  • Ensure that the remote forest clients (DMZ in this case) are represented with a Boundary and that the Boundary is configured within a Boundary Group.
  • Manually Install the Configuration Manager Client on the cross forest located computers specifying the Lookup Management Point (Screen Shot 1 Below). This can be done with a script, GPO, or manually.
  • Note on Location Lookup - This could be done through specifying a Lookup Management point at installation time (as seen in this example), or by publishing site information to the remote forests active directory, DNS, or WINS. We will explore some of these other options during some of the ‘more complex’ examples to come.

Given this configuration, once the client has been installed, the lookup management point will be queried for the location of all available management points, one of these will be selected based on a set of criteria (subject for another post), policy will be applied to the CM client, and proper management will commence. Very simple, however also limiting in respects to automated discovery / installation, and overall management experience.

 

Example Information -

Client Installation with Lookup Management Point Specification – ccmsetup.exe SMSMP=TWOSYS2012CM01

After client installation the Location Service Log showing the acknowledgement of the lookup MP.

Notice that the lookup MP is referred to as SMSSLP in registry (HKLM\Software\Microsoft\CCM).

Finally in LocationServices.log we can see that the list of MP’s has been returned from the lookup MP.

 

 

Client Approval –

Be aware, the default behavior of Configuration is to only auto approve clients residing in a trusted domain. So by default, in the configuration describe in this posting, each cross forest client will require manual approval.  

Example of client requiring manual approval.

This approval behavior can be changed to auto approve all clients, however this configuration is not recommended. For more information see this article – Security and Privacy for Client in Configuration Manager .

 

 

Closing –

To close, there are many technical requirements that need to be taken into consideration before approaching cross-forest client management. During this initial posting of this multi-article series we have discussed the hard technical requirements that will need to be considered and have also looked at a very simple example detailing simple management of a small amount of cross forest clients. Stay tuned for the next installment of this series in which I will dig deeper into cross forest client management introducing a more complex cross forest management scenario.

Comments

  • Anonymous
    January 01, 2003
    Hello Neil, I found your article(s), but I got a bit confused in a sense that it was my understanding that the site servers in a ConfigMgr hierarchy should be in the same domain and that some roles can be in an other domain (trusted or not).  In this article you mention that site servers have to be in the same forest, so in my understanding this would mean that the site servers can be in different domains in the same forest. Is there some information to be found that states what is supported by Microsoft? Thanks in advance for you answer. Best regards, Robin

  • Anonymous
    January 01, 2003
    thanks

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Thanks for your reply in the technet, the articles  will be helpful to me

  • Anonymous
    May 21, 2014
    Pingback from Notes from TechEd 2014 | IT Consultant Everyday Notes

  • Anonymous
    May 21, 2014
    Pingback from Notes from TechEd 2014 | IT Consultant Everyday Notes

  • Anonymous
    September 09, 2015
    The comment has been removed