Up until this point each scenario in this series of articles has detailed the management of ‘well connected’ clients. In other words changes have been introduced into existing infrastructure in order to facilitate untrusted, cross-forest client management; however no additional infrastructure has been added. This approach may work well in situations such as that where clients are located in a well-connected DMZ forest. In all practicality though, situations will arise in which either cross forest targeted clients are not well connected, for some other reason client / site system communication needs to be localized, or when Kerberos authentication must be used to facilitate client approval. In this third posting to the Cross Forest support in Configuration Manager Blog series I will be discussing the placement of remote site systems in an untrusted forest. Specifically I will detail the placement of a Management Point and Distribution Point in the non-trusted forest.
Whereas the previous two examples (example 1 and example 2) have assumed a well-connected DMZ located forest, in this scenario we will shift to a completely different situation. The scenario for this example is that your organization (Houston based) has recently partnered with a new organization. The partner organization has a single physical site that resides in Tokyo and contains 900 computers. There exists a separate AD forest for both ends of the partnership. At this time a trust will not be created between the two organizations. The new partner organization is impressed with the client management solution that your organization is using and would like to introduce all Tokyo located computers into the Configuration Manager environment ASAP.
The challenge here is that with 900 remote clients the need for remote infrastructure (Distribution Point at minimum) is fairly probable. Utilizing some of the Configuration Manager features such as Operating System Deployment, Application Management, and Software Updates, the localization of this content to these clients can become very important.
Configuration Overview –
In order to prepare the remote forest to receive a remote site system and then ultimately host clients, some or all of the following actions will need to take place. Many of these were covered in article 2 of this series, for theses I will refer back to the original article. It is also important to note that these steps may not necessarily occur in this order, for instance client installation or deployment needs to be a well thought out and coordinated effort. Based on what will work best for your environment, may determine at what point AD System Discovery is enabled for the untrusted forest (if ever). If you have doubts about what will work best for your environment please consult with a Premier Field Engineer or other experienced party.
High Level Steps:
- Enable Forest Discover (Refer to Article 2)
- Configure Site Publishing for the non-trusted forest. This is optional however can offer a more flexible administrative experience (Refer to Article 2).
- Ensure boundary and boundary groups have been configured for the remote forest.
- Create a Site System Server in the Remote Forest.
- Add the desired site system roles to the site server.
- Configure AD System Discovery (Refer to Article 2).
- Configure Client Push Installation (Refer to Article 2).
Creating the Site System Server and Deploying the DP / MP –
I will not detail each step required to deploy a Management Point nor Distribution Point. Needless to say, the host computer in the non-trusted forest will need to be prepared for each role that will be installed. Refer to the following article on the Windows side configuration needed for each role.
Prepare the Windows Environment for Configuration Manager – http://technet.microsoft.com/en-us/library/gg712264.aspx
What I will highlight is any unique configuration that is needed when deploying infrastructure to a non-trusted forest.
To start we need to initiate the Create Site System Wizard
Adding the new Site System Server
On the General page of the wizard two configurations will need to be accounted for.
- Require the site server to initiate connections to this site system needs to be selected. More information on this setting – Security and Privacy for Site Administration in Configuration Manager.
- Secondly specify an account that will be used to install the site system components. This would be an account that has administrative rights on the cross forest site server.
Create Site System Wizard with two configurations necisary for non-trusted forest communication.
Select the roles to be installed on the remote site system. Each role can be installed into the non-trusted forest with the exception of the Out of band service point and the Application Catalog Web Service Point. For the most part this process is identical to installing the role in a trusted forest. Because of this I will not walk through each step for each role rather call out only those that have configuration specific to the non-trusted forest scenario.
For information on configuring each role refer to this article – Install and Configure site System Roles for Configuration Manager – http://technet.microsoft.com/en-us/library/hh272770.aspx
Select both the Distribution Point role and the Management Point role.
In order for the Managent Point to fuction in a non trusted forest ensure that an account has been specified with the apropriate access to the Configuration Manager database.
Configure Management Point database connection account
If this step is missed you will see the following logging in mpcontrol.log – “’logon failed. The logon is from an untrusted domain and cannot be used with Windows authentication”
Mpcontrol.log – looks bad.
When configured, mpcontrol.log will return the following –
Mpcontrol.log – looks good.
Finally, if the Configuration Manager site is configured to publish to the non-trusted forest, we can observer the published MP’s from both forests.
ADUC in the non-trusted forest
Important Note – ensure that each site system regardless of forest membership has a unique NetBIOS name. If duplicate site systems names are configure content distribution will potentially fail with the following error logged to distmgr.log:
ERROR DPConnection::ConnectWMI() – Failed to connect to <insert server> error = 0x800706ba
Client Discovery and Client Installation –
At this point, when client installation (ccmsetup.exe) is executed, the client binaries will be downloaded from the new DP/MP that has been introduced into the site and clients will use this DP/MP for policy request, content access, and many other activities. As mentioned before client installation will need to be a coordinated effort. A simple configuration at this point would be to configure AD System Discovery for the non-trusted forest, and once completed let Client Push installation handle client deployment. This was detailed in my previous article.
A quick bit on client approval –
If you recall, in the previous two examples in which the non-trusted forest did not contain a management point, after client installation the client remained in an unapproved state (assuming the default approval settings of “Automatically approve computers in trusted domains” has not been changed). With the configuration as shown in this example the presence of an MP in the non-trusted forest allows for the auto approval of clients residing in the non-trusted forest (again, assuming the hierarchy settings have not been changed from their defaults).
During this article I have detailed the deployment of a Remote Site Server into a non-trusted forest. This type of site configuration can be beneficial when there exists a need to localize content or client traffic. This example, along with the examples provided in the previous two postings in this series, provide three different examples of managing client in a non-trusted forest. This concludes all discussion based on untrusted forests. In the next and final posting to this series we will go all the way and discuss what it takes to add a child site (primary or secondary) into a separate forest.