Using Client Push Installation on UNTRUSTED FOREST systems with ConfigMgr 2012

Last week my post was about using the Client Push Installation on WORKGROUP systems and this week my post will be a sort of follow-up on that. This week my post will be about using the Client Push Installation on UNTRUSTED FOREST systems. The method of last week will also work on UNTRUSTED FOREST systems, but the nice thing about ConfigMgr 2012 is that there are now better options for UNTRUSTED FOREST systems! The systems and domain(s) of the UNTRUSTED FOREST can be discovered AND to make it even better, it is even possible to write information to the Active Directory!

Prerequisites

Before it is possible to use the Client Push Installation on UNTRUSTED FOREST systems, there are a few things to keep in mind. The following points are a prerequisite and, besides the Active Directory Forest and the Active Directory System Discovery, they are not further explained in this post:

  • The FQDN of the Management Point system can be resolved on the UNTRUSTED FOREST systems.
  • The UNTRUSTED FOREST can be resolved on the site server (and domain).
  • The Active Directory of the UNTRUSTED FOREST is extended.
  • The Client Push Installation Account has administrative rights.
  • The UNTRUSTED FOREST is added as an Active Directory Forest.
  • The Active Directory System Discovery is enabled to find the UNTRUSTED FOREST systems.

Pre-configuration

Normally I leave the prerequisites for what they are, but in this case it all stands-or-falls with the configuration of the Active Directory Forest and the Active Directory System Discovery. So I will first show in two steps how to pre-configure the Active Directory Forest and the Active Directory System Discovery, before I will show how to configure the Client Push Installation.

The first step is to add the UNTRUSTED FOREST as a Active Directory Forest, so it can also write the site information to that Active Directory, and that can be done by following the next steps:

  • ADFPropNavigate to Administration > Overview > Hierarchy Configuration > Active Directory Forests.
  • In the Home tab, click Add Forest and the Add Forest –popup will show.
  • On the General tab, fill in with Domain suffix <aDomainSuffix>, select Use a specific account and Set <aAccount>.
    • Note: <aAccount> needs to have the appropriate security rights to write to the System Management container in the Active Directory of the UNTRUSTED FOREST.
  • On the Publishing tab, select <aSite> and click OK.

The second step is to configure the Active Directory System Discovery, so it can discover the systems from the UNTRUSTED FOREST, and that can be done by following the next steps:

  • ADSD_ADContNavigate to Administration > Overview > Hierarchy Information > Discovery Methods and select Active Directory System Discovery.
  • In the Home tab, click Properties and the Active Directory System Discovery Properties will show.
  • On the General tab, click <YellowStar> and the Active Directory Container popup will show.
  • Fill in with Path <aLDAPPath>, select Specify an account, Set <aAccount> and click OK.
    • Note: <aAccount> needs to have the appropriate security rights to discover objects in the Active Directory of the UNTRUSTED FOREST.

Configuration

Now let’s start with the real configuration! After doing all the discoveries it is possible to configure the Client Push Installation for UNTRUSTED FOREST systems. The configuration of the Client Push Installation is actually the easiest part this post. To configure Client Push Installation for UNTRUSTED FOREST systems follow the next steps:

  • CPIP_AccoNavigate to Administration > Overview > Site Configuration > Sites and select the site.
  • In the Home tab, click Settings > Client Installation Settings > Client Push Installation and the Client Push Installation Properties will show.
  • On the Accounts tab, click <YellowStar> > New Account and the Windows user Account popup will show.
  • Fill in with User name <DOMAINNAME>\<USERNAME> with the corresponding password in the appropriate fields and click OK.

Results

After the configuration is done it is time to take a look at the results. The best place to look at the results is still the CCM.log, but as I showed that last week already I will now show a snippet of the ccmsetup.log. This log shows that it successfully retrieves information from the Active Directory during the client installation. After the installation was successful the client will show up in the console as an active client with as Domain <DOMAINNAME>.CCMSetupLogHTSystem

21 thoughts on “Using Client Push Installation on UNTRUSTED FOREST systems with ConfigMgr 2012”

  1. Great article. The only question i have is… Does the untrusted site need to have the Schema extended?

    Reply
  2. Thanks for the reply. I ask this due to the console complaining that it was not able to create items in the System Management Container.

    See error below

    Configuration Manager cannot create the object “cn=SMS-MP-SITECODE-Servername.Domain” in Active Directory (Domain).

    Reply
  3. Thanks for the great article..
    Is the referenced account ‘SVCCONFIGMGR_ADFA’ in the above example an Enterprise admin created at the forest level? if so, how this would have admin rights in the sub-domains?

    Thanks,
    Vasim

    Reply
  4. Peter,

    Is the FOREST DISCOVERY actually a requirement which we can not push the clients unless it is there , Or we enable the forest discovery just to do a better job. What I am asking is can we enable the client push to another forest without turning the FOREST discovery , or its not possible ?

    Reply
  5. Hi Peter,
    When trying to do Client push on the cross forest discovered object, SCCM is only trying the first client install account (from CCM.log) and fails with error unable to access target machine……
    In theory it should try all the account configured for client push in the order listed?

    Any suggestions?
    Thanks.

    Reply
  6. Hi Peter,

    Thank you for these very helpful posts.

    I am in the middle of setting up a similar scenario, however, we are installing a site system within the untrusted domain to act as the MP, DP and SUP.

    We are using Configuration Manager 2012 R2 SP1 with a Primary on our internal domain. The primary site server is running Windows 2008 R2 and the CM database is also installed locally. The forest disovery to the untrusted domain is working fine and the devices in the untrusted domain are listed within the Configuration Manager console (we have a one-way trust where the external (DMZ) domain trusts internal). We can resolve hostnames OK between the domains and the schema in the untrusted domain has been extended.

    I have opened the ports per technet article: https://blogs.technet.microsoft.com/jchalfant/ports-required-for-a-site-system-in-dmz-in-configuration-manager/

    I am having issues however, with the Management Point role on the site server in the external domain. I can install the role OK, however, the MP does not communicate back with the SQL server on the primary on the internal domain. The following errors appear in the MP_GetAuth.log:

    MPDB ERROR – CONNECTION PARAMETERS
    SQL Server Name : xxx
    SQL Database Name : CM_V01
    Integrated Auth : True
    MPDB ERROR – EXTENDED INFORMATION
    MPDB Method : Init()
    MPDB Method HRESULT : 0x80004005
    Error Description : null
    OLEDB IID : null
    ProgID : null
    MPDB ERROR – INFORMATION FROM DRIVER
    null

    And this error in the MP_Status.log

    MPDB ERROR – CONNECTION PARAMETERS
    SQL Server Name : xxx
    SQL Database Name : CM_V01
    Integrated Auth : True
    MPDB ERROR – EXTENDED INFORMATION
    MPDB Method : Init()
    MPDB Method HRESULT : 0x80004005
    Error Description : Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.
    OLEDB IID : {0C733A8B-2A1C-11CE-ADE5-00AA0044773D}
    ProgID : Microsoft SQL Server Native Client 11.0
    MPDB ERROR – INFORMATION FROM DRIVER
    SQL Server Name : xxx
    Native Error no. : 18452
    Error State : 1
    Class (Severity) : 14
    Line number in SP : 1

    We implemented the following workaround as recommended by Microsoft: https://support.microsoft.com/en-gb/help/2689646/system-center-2012-configuration-manager-incorrectly-uses-the-site-sys

    Would be grateful if you had any suggestions?

    Thanks

    Reply
  7. Hi Peter,
    Great article, but I am on the first step.
    I want to access machines in another forest.

    So my question is:
    1. How do I get my SCCM server to authenticate machines in another forest.
    2. Do I create a stub zone in the local forest as well as the client forest

    Reply
  8. Hi Peter,
    I have followed this article, however the clients are coming back with a grey question mark on them. They are unable to see published applications or software updates. The control panel applet only displays machine policy and user policy in the actions tab. All the rest are missing. Do you know what could be the issue?

    Reply
  9. Falcon, it’s because by default, clients in untrusted domains are not automatically approved in SCCM. Right click and Approve (in bulk as well) or change the default under Administration–>Site Configuration–>Sites–>Hierarchy Settings in the top banner–> Client Approval and Conflicting records tab

    It’s a security risk to approve all client regardless of the trust relationship. Use at you own discretion.

    Reply

Leave a Reply to peter Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.