One of the questions that I have had a lot lately, is how we configure Multi forest support in ConfigMgr. 2012. It’s my plan to document a few scenarios in terms of supporting sites, site systems and clients in remote forests. In this first part, I’ll explain how you can support clients in an untrusted forest without installing any remote site systems.
Discover information from the remote forest
To configure support for the remote forest:
- Configure credentials for discovering the “remote forest”.
- Configure Active Directory forest discovery to discover IP ranges and AD sites.
- Configure AD System discovery.
- In the Administrator console, select the Administration Workspace and navigate to Hierarchy Configuration, Active Directory Forests.
- From the ribbon click Add Forest, fill in information about the forest and the discovery account with read permissions to the remote forest.
- Save the new forest information.
- Navigate to Hierarchy Configuration, Discovery Methods and open the properties for Active Directory Forest discovery.
- Enable the forest discovery method, configure the discovery method to discover IP ranges and Active Directory sites. Click OK and start the discovery cycle (for detailed information about the process, check ADForestdisc.log).
Configure Active Directory System Discovery
One of the new features in ConfigMgr. 2012 is the option to configure discovery accounts. In order to discover information about computers in a remote forest, you need to configure an account that has Read permissions in the remote Active Directory.
- Open the Administrator console, select the Administration workspace and navigate to Hierarchy Configuration, Discovery Methods.
- Open the Active Directory System discovery properties
- Click the yellow Icon to create a new Active Directory container.
- Since you do not have any trust, you’ll have to manually type the LDAP path to the objects you want to discover e.g. LDAP://DC=HQ,DC=COM and click OK.
- Click Specify an account and click Set. Type in the remote forest discovery account.
- Finish the configuration, the discovery process will run automatically (you can monitor the process by reading the adsysdis.log)
Client installation
Before you start planning your client installation you need to make a decision on client approval. By default only clients in a trusted forest will be automatically approved which also includes downloading machine policies. You can manually approve each client, implement a PKI solution or configure the site to automatically approve all clients, including those from an untrusted forest. In my example I approve all clients automatically.
- Open the Administrator console, select the Administration workspace and navigate to Site Configuration.
- Select Sites and click Hierarchy settings from the ribbon.
- Select the Client Approval and Conflicting Records tab.
- Click Automatically approve all computers (not recommended) and click OK.
You can install the client using these installation methods:
- A group policy
- Startup script
- Client Push
In my example I used a client push, with these settings:
- Created a Client Push account in the remote forest
- Configured my Client Installation properties like this:
- SMSSITECODE=PS1 SMSMP=CM04.SC2012.Local FSP=CM04,SC2012.Local DNSSUFFIX=SC2012.Local
Client support in an untrusted forest
Clients in untrusted domains will be able to download and apply machine based policies. When needed, the client will use the Network Access Account to connect to the distribution point and download content.
[…] Client support in untrusted forests […]
It works but it’s not supported:
Extract from technet documentation:
Configuration Manager supports clients that are in a different forest from their site’s site server when one of the following is true:
The site system role server is located in the same forest as the client
There is a two-way forest trust between the forest of the client and the forest of the site server
For example, you must place a site system role for a site in the remote forest with a client only when that remote forest does not have a two-way forest trust with the forest of the site server
First of all thanks for all your help….I see your SCCM related posts and replies to questions all the time.
I’ve been able to get Forest Discovery and AD Discovery to work with an untrusted forest fine. I’m having trouble getting publishing to work with the untrusted forest however. The status for publishing for the untrusted forest is blank. The account I’m using to discovery has full control of the system management container as well as the system container in the untrusted forest AD but still no entries are being populated in the system management container.
Is this because I have not installed any site system roles onto machines in the untrusted forest? I wanted to make sure client deployment / management was possible across untrusted forests before I proceeded.
Eric,
Make sure that the account that you’ve used to discover the untrusted forest have Full Permission of the System Management Folder and all Object below. Initiate the full discovery task and you should see object published within Untrusted forest.
The account doesn’t belong to the same forest, so how do you add it to SCCM folder?
Thanks
Makambo,
if you setup discovery for the untrusted Domain you´ll most likely use an account from the target Domain.
So there will be no Problem Setting up Access permissions for the System Management conatainer.
I´ve done so yesterday, everything worked fine.
Hi,
How do I set up configuration manager 2012 across trusted forest in a secure way? Where can i find part2 of your articles?
Thank you so much for your help.
Mk.
[…] […]
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?
Hi
Our sccm is in Domain A and we have another domain B without a Trust. Smb is Not allowed because the fw reason. Is there a option with certificate as scom has?
Tanks for help
Thank you for this post. I was hoping you might be able to tell me if it would be possible to support a scenario where the SCCM server was in Domain A and had clients in the same domain but also client systems in another forest, Domain B with a one-way trust.
Please see the below scenario:
http://i.imgur.com/D0qogGU.png
I have posted about it here but not had any answers regarding my issue:
http://www.myitforum.com/Forums/tm.aspx?m=243380
Would greatly appreciate your advice on whether this is possible.