Welcome to the last in this series of four articles examining cross forest support in 2012 Configuration Manager. In the previous three postings I have examined configuration options for client management across a non-trusted forest. To recap, the following scenarios or configurations have been discussed.
- Scenario 1 – Simple management of a small amount of know clients residing in a non-trusted forest.
- Scenario 2 – More complex management of a larger number of unknown clients residing in a non-trusted forest. This article introduces cross forest discovery, publishing, and client push installation.
- Scenario 3 – Introduces the placement of Configuration Manager Infrastructure (MP, DP) in a non-trusted forest.
In this final and brief article I will examine the cross forest placement of a Configuration Manager site (Primary or Secondary). This process is very similar, almost identical to deploying a child site in the same forest as the parent. Because of this I will not go into deep detail on site deployment; this will be a short post. There are however a few items worth pointing out, and I do want to ensure that this series on cross forest management has come full circle.
Why deploy a cross forest site -
Why install a site into a forest other than the on hosting the CAS or Primary site? In my opinion, the reasons for doing so would be the same reasons that would justify the introduction of an additional site (primary or secondary) into a Configuration Manager Hierarchy spanning only one forest. Some of these reasons may include (just to name a few)
- Client counts of greater than 100,000 (Primary)
- Requirement to control the upward flow of client and site communication (Secondary)
- Rich Content Routing capabilities (Secondary)
Check out the following article for more information that will aid in determining if additional sites are needed in you Configuration Manager deployment - Planning for Sites and Hierarchies in Configuration Manager .
Technical Requirements -
So what are the technical requirements for the placement of a child site in a separate forest? Beyond the obvious, Name Resolution, Port Connectivity, Windows preparation, we will also need to ensure that a two way trust which supports Kerberos authentication exists between the two forests. Once the standard prerequisites have been accounted for, and a two way trust has been created, there are no additional cross forest configuration steps that need to be taken before installing the cross forest site.
Creating the two way trust –
I will not go into detail on creating a two way trust (this is not ASK PFE PLAT 🙂 – but do check out the blog), for examples sake here’s a screen shot of the process beginning.
New Trust Wizard
Installing the Cross Forest site –
At this point we have a box in the remote forest prepared for a site server installation, DNS resolution works, port connectivity is ok, and a two way trust has been created between the two forests. We can now install the cross forest site.
In this example I will be installing a secondary site into my newly trusted forest. Refer to the following TechNet article for detailed steps on deploying sites – Install Sites and create a Hierarchy for Configuration Manger.
Adding the secondary site (click image for better view) -
Configuration of Secondary Site (click image for a better view) -
Hierarchy Manager lights up with site deployment action (hman.log), click image for a better view -
Finally observer the new cross forest secondary site (click image for a better view) -
Additional Items to Consider -
Once a site has been added to the remote forest (or even before site placement) there are a few operations items that can be configured.
- Cross Forest Discover
- Cross Forest Publishing
- Cross Forest AD object discovery
- Client push installation in the trusted forest (configured from the secondary or primary placed in the trusted forest)
Each of these has been detailed in part two of this series.
In this post we see that installing a cross forest Configuration Manager site is almost identical to installing an additional site within the same forest as the CAS or Primary. The only additional requirement is that a two way trust which supports Kerberos authentication must be present between the two forests. This posting rounds out my discussion on the supported cross forest configurations in 2012 Configuration Manager. I hope this information and the included examples have been helpful.