Cross Forest Support in ConfigMgr 2012 Part 3: Deploying Site Server / Site Systems in an Untrusted Forest.

Introduction -

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.

 

Scenario –

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 - https://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 - https://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).

 

Conclusion -

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.

Comments

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  thanks

• Anonymous
  January 01, 2003
  Mitchawkes, if I understand your question correctly, while you cannot specify an MP for client communication within a site, clients will use the MP residing in their forest by default. NP

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  The comment has been removed

• Anonymous
  January 01, 2003
  awesome post, thanks for sharing.

• Anonymous
  November 14, 2012
  Hi, Great article really got me started in the right direction for what we were after. One question though: I have configured configmgr primary site in forest A and it works fine, it has SQL separate to the site server. I have setup a secondary site server as a management and distribution point in untrusted forest B. This worked fine, I can deploy agents to other servers in both forests and I have full forest discovery. The issue I have is the fact that the SQL server is reporting: SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. [CLIENT: IP Here]. Using Netlogon I can see that the primary site server in forest A (With the SQL server) is trying to pass authentication from the secondary site server in forest B and failing. The Site System properties shows that the account is from forest B, but the Management Point SQL connection properties are using the SQL access account from forest A. Can you please give any guidance on where I have gone wrong please? Thanks.

• Anonymous
  January 18, 2013
  The comment has been removed

• Anonymous
  January 23, 2013
  Hello and thank you for this article But I have a question. The use of role management point is it possible in this case, knowing that you can not force the SCCM agents to use a specific MP in same primary site, for a remote physical site, located in a separate forest ? Regards MP

• Anonymous
  January 24, 2013
  Neil, Ah cool ! Thank you for your response ! MP

• Anonymous
  January 25, 2013
  Hello, Just another question. How to manage the single network access account declared in the primary site (Forest A), for the distribution point located in Forest B Approved or not? Regards, Mitchawkes

• Anonymous
  February 19, 2013
  @Frank V: I have similar issues - have you been able to resolve this error?

• Anonymous
  April 22, 2013
  Great article, I just have one question. How should access to the MP should be setup? I keep getting the '’logon failed. The logon is from an untrusted domain and cannot be used with Windows authentication' error. Should I create a login on the SQL Server using SQL Authentication ? I'd like to see some more details on this. Thanks :)

• Anonymous
  May 05, 2013
  Hi Neil We want to deploy SCCM 2012 for our 10 different clients. So that's means we have 10 different forest across different locations. What will be the best possible solution have them connected with our Data Centre SCCM 2012 Primary site? Thanks Faisal

• Anonymous
  November 14, 2013
  Hi Neil, Thank you for excellent descriptions. Can you please reply “no official note” from scenario 3: • Supported by CSS   • Non Microsoft best practises I need to add this information to my planning documentation for future reviews, when SCCM supportability reviews or RAP’s are going to be held. My customer IT-Sec do not allow any trusts between AD’s. Still one Operational Management platform is requirement. /thanks for help and guidance. markkuh

• Anonymous
  October 22, 2014
  The comment has been removed

• Anonymous
  December 09, 2014
  As per Marc Comment below: Can you please shed some light on how to get the access acount authenicated with SQL. Dont you think we would need the one way trust atleast?
  
  
  Great article, I just have one question. How should access to the MP should be setup? I keep getting the '’logon failed. The logon is from an untrusted domain and cannot be used with Windows authentication' error. Should I create a login on the SQL Server using SQL Authentication ?
  
  I'd like to see some more details on this.
  
  Thanks :)
  

• Anonymous
  January 08, 2015
  Hi Faisal,
  
  It sounds like you are wanting to deploy SCCM to manage un-trusted machines, so ideally you want to build SCCM so that it is multi tenant aware.
  
  I would personally recommend treating each client as an 'Internet Based Client' that connect to your management points that are accessible via the internet (a reverse proxy of sorts.
  
  This will give some limitations, but you would still be able to deploy software, asset intelligence etc. You wont be able to use AD discovery, but could rollout your client using a powershell script or group policy.
  
  Thanks
  
  Paul

• Anonymous
  January 15, 2015
  The comment has been removed

• Anonymous
  March 13, 2015
  Hi.
  
  If we want to manage the clients in the untrusted domain with SCCM2102, do we have to extend the untrusted domain schema for SCCM?
  
  thx

• Anonymous
  April 14, 2015
  Hi,
  
  Technet (https://technet.microsoft.com/fr-fr/library/gg682077.aspx) says to not position MP across a slow link from their primary site (a PRI site support 10 mp), and that a secondary site support a single MP.
  
  So what's the best way to manage ~15 remote clients which are in an untrusted forest ?
  
  Thanks,
  
  Nicolas
  

• Anonymous
  November 19, 2015
  The comment has been removed

• Anonymous
  November 20, 2015
  Just to update the previous post. I solved the problem. The issue was caused by a Firewall Issue. The Firewall as blocking the RPC Traffic.
  
  Best Regards

• Anonymous
  March 09, 2016
  Hi Guys
  
  Just thought I’d add an important point that was hindering my communication between the forests, everything was working except the WMI communication, for us it was only functional one way based on the trust we have in place. In our case the Site server domain trusted the remote forest’s domain. The site server required port 88 opened up to the DC’s in the other forest. This is in addition to the documented SCCM required DC LDAP communication.
  
  Thought I should mention it somewhere as there is absolutely no mention of this fix anywhere on the internet.
  

• Anonymous
  March 23, 2016
  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).
  
  Please note that this behaviour was broken in SCCM 2012 R2 SP1 CU1 (SCCM 2012 SP2 CU1) and its fixed again in SCCM 2012 R2 SP1 CU2 (SCCM 2012 SP2 CU2). So, as always, I would recommend to install latest updates on regular interval.

• Anonymous
  April 14, 2016
  Hi, It seems the behaviour that Bindusar Kushwaha talking about still broken in (SCCM 2012 SP2 CU2), the client still not get automatic aproval even the MP is deployed in a non-trusted forest.
  
  
  Can you guys give un update on this metter?
  
  Thank you,
  
  "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).
  
  Please note that this behaviour was broken in SCCM 2012 R2 SP1 CU1 (SCCM 2012 SP2 CU1) and its fixed again in SCCM 2012 R2 SP1 CU2 (SCCM 2012 SP2 CU2). So, as always, I would recommend to install latest updates on regular interval."