There may come a time in your SCCM administration days where some special needs may arise. I had such a case recently. Long story short, in our company, we have a windows domain where no trusts exist with our primary domain where SCCM resides. The problem with that is since there is no visibility in between the two domains, how do you get the servers or workstations managed? This post will describe Installing SCCM DP MP SUP in Untrusted Domain.
- Default settings?
- Such as a default Windows Update setup. Nah, I like to have some degree of control over who does what and when.
- Install a standalone WSUS server?
- Yes, this is a viable option where you can set and forget it. But it probably doesn’t fit with your SCCM setup.
- Install a completely separate SCCM infrastructure?
- Sure this works. But… Do you like doubling all your work? I surely don’t.
- Install a DP in that zone?
- This does indeed work. But… If you want to don’t want agents poking back to your internal primary site, you will need to add components to this. Such as? A Management Point. What if it is a zone with no internet access? How do you get your patches? Install a Software Update Point as a downstream server to your internal WSUS.
Requirements for a DP/MP/SUP in an untrusted domain
The first step, you will need to go over the supported configurations for Configuration Manager. Assuming that you are going for a regular setup such as a Windows 2012/2016 server, there is one thing you need to make sure you have.
All System Center 2012 Configuration Manager site systems must be members of a supported Active Directory domain. This requirement includes site systems that support Internet-based client management in a perimeter network (also known as DMZ, demilitarized zone, and screened subnet).
So, if you are planning any SCCM role type, you will need a functioning Active Directory in that zone. If not, make sure you have that before coming back here.
Next, let’s look at the required firewall ports we need. You will most likely need to have these opened by your firewall administrators. Microsoft has done quite a good job in documenting pretty much all firewall ports that are required for SCCM to work. However, since you are here, I’m guessing you are looking for the TL;DR version.
I am assuming here you are using the default ports.
Management Point <-> Site Server
These ports are required for your new management point to “talk” with your primary site.
|RPC Endpoint Mapper||–||135|
Management Point -> SQL Server
Your management point will also need to be able to communicate with your SQL database. This could either be the same IP as your primary site if both are residing on the same windows server, or the IP of the dedicated SQL server.
|SQL over TCP||–||1433|
Notice that I didn’t include Client -> Management Point. This is because the clients are within the same domain as the new MP you are installing so unless your windows firewall is enabled on the new MP, it won’t be needed.
Site Server -> Distribution Point
This one is essentially used to distribute packages to your DP, amongst other things.
|RPC Endpoint Mapper||135||135|
Site Server <-> Software Update Point
|HTTP||–||80 or 8530|
|HTTPS||–||443 or 8531|
This one is for your site server to communicate with your SUP. Note that you will need either HTTP or HTTPS. You won’t need both. Not sure? One very easy way to find out is by opening the WUAHandler log on any one of your SCCM clients. Look for the keyword:”Existing WUA Managed server”
As you can see, I’m currently set in HTTP. So I’ll keep going that way.
Software Update Point <-> Upstream WSUS Server
|HTTP||–||80 or 8530|
|HTTPS||–||443 or 8531|
You will also need to have some sort of name resolution to your primary site and SQL server. This could either be via DNS with TCP/UDP 53 opened, via host file, etc.
So that’s pretty much it for firewall requirements.
Next? Actual permissions. Obviously, in a typical setup, your primary site server is usually a local windows administrator of the server itself where it’s installed. However, in this case, the primary site server can’t be a local administrator of the new management point since there is no trust. Not a problem. Create a service account on the destination domain (which will essentially be a Network Access Account for that domain) and put it as a local administrator of your new MP.
What about SQL? Well, in my primary domain, we already have a NAA that does all that work. Let’s keep it. I’ll show you how to set it up when we do the installation.
One last piece of information as this one caused us quite a bit of a headache. If your domain has anything above the normal set of hardening rules, you could have a problem. Make sure that your NTLM settings are set up to allow authentication. The traffic will be initiated by your Primary Site -> New MP -> DC to authenticate. If you are denying NTLM traffic, you will most likely need to setup an exception to allow authentication for that new MP.
Installing SCCM DP MP SUP Untrusted Domain – Preparing the Windows Server
Since this will be a DP and SUP, we will need to install WSUS and IIS on the server. Fire up your Powershell console. Head over to Requirements and Recommendations before installing SCCM 2012R2 in the Roles and features section.
Go ahead… I will wait! 😉
Ok, so that’s done. Now let’s install WSUS.
- Select WSUS Services and WID, click Next
- Check Store updates, and set your WSUS location
- Press Install
Now, as you probably know our external SUP will need to communicate with the upstream server. Let’s go ahead and set that up.
Launch your WSUS console which will most likely prompt you to complete the installation.
- Press Run if prompted.
- Press Close when complete.
- When the WSUS Configuration Wizard starts, click Cancel
- Head over to Options and choose Update Source and Proxy Server
- Enter the Server Name of the Upstream server you will be using. Press Ok.
Installation of the SCCM roles
As stated in the documentation, by default, communication between the site server and site systems is bi-directional. The site server initiates communication to configure the site system, and then most site systems connect back to the site server to send status information. Reporting service points and distribution points do not send status information. If you select Require the site server to initiate connections to this site system on the site system properties, after the site system is installed, it will not initiate communication to the site server. Instead, the site server initiates the connections and uses the Site System Installation Account for authentication to the site system server.
How do we implement this? Here’s how.
- Start by browsing to Administration – Site Configuration – right click Servers and Site System Roles and choose Create Site System Server
- Next, enter the FQDN of your new MP (1). Enter the Site Code (2) and finally instead of using the Site Server Account to install, since this server is in our untrusted domain, give him the service account which is local administrator of the server (3)
- In the proxy tab, leave the options default, press Next
- On the System Role Selection, choose Distribution Point, Management Point, and Software Update Point
- On the Distribution point tab, check Install and configure IIS if required by Configuration Manager, press Next
- On the Drive Settings, set your values as per your environment. Press Next
- On the Pull Distribution Point tab, press Next
- On the PXE settings, we will just press Next since we won’t be doing any PXE in that environment
- On the Multicast tab, press Next
- On the Content Validation tab, set your schedule and press Next
- On the Boundary Groups tab, set your boundaries. Press Next
- On the Management Point tab, select HTTP. Press Next
- On the Management Point database, under connection account, press Set and choose your internal NAA account. Press Next
- On the Software Update Point tab, if you are setting up your server on 2012 or 2016, set your option to 8530 or 8531 and press Next.
- Finally, on the Proxy and Account settings, press Next
- Complete the wizard
And if all went well, you should now have a completely functional SCCM infrastructure in your no-trust active directory. As you may have noticed, the SCCM installation portion of this guide stays mostly the same. What changes the most is the requirement part that is tweaked a bit and the accounts we used.
Have you setup any similar infrastructure? If so, feel free to share how you went about to do it.
You can verify the installation in the following logs:
ConfigMgrInstallationPath\Logs\mpMSI.log – Records details of about the management point installation
ConfigMgrInstallationPath\Logs\MPSetup.log.log – Records the management point installation wrapper process
ConfigMgrSetup\Logs\SUPSetup.log -Provides information about the software update point installation. When the software update point installation completes, Installation was successful is written to this log file
ConfigMgrSetup\Logs\WCM.log – Provides information about the software update point configuration and connecting to the WSUS server for subscribed update categories, classifications, and languages
ConfigMgrSetup\Logs\WSUSCtrl.log – Provides information about the configuration, database connectivity, and health of the WSUS server for the site
ConfigMgrSetup\Logs\Wsyncmgr.log – Provides information about the software updates synchronization process
I’m currently going through your instructions on this. I have the MP/DP set up, but having issues with the SUP. I have an internal SUP already installed. The WSUS components are installed on a remote server and the SUP role installed on that server. The internal piece of SCCM SUP is working just fine. Do I use the Primary server as the Upstream server or the remote SUP? From what I’m seeing with logs I’m getting Remote connection failed with exception ‘System.Net.WebException: The request failed with HTTP status 401: Unauthorized. I do have the proper FW rules in place. This error is coming from the WCM.log. What am I doing wrong? The internal SUP was configured for https, but have unchecked the SSL option in SCCM on The SUP role and I’ve removed the SSL check on the proper components in IIS on the WSUS Admin site and restarted IIS. Is there something in the registry I need to change from 8531 back to 8530, and will that fix my communication issue? Any guidance would be great. Thanks.
i agree to Roy. You cant possibly deploy a SCCM roles such as MP/DP/SUP to an untrusted servers. You need to locate the server before you can install these sccm roles by either in the same domain or in trusted domain.
I am able to install MP and SUP roles by following this article but couldn’t install the DP role. It keeps failing with a cause- Distribution Manager does not have sufficient rights to the computer. Am I missing some permission here?
I have implemented a Site System server in an untrusted network. Everything seems to be working fine except one issue. Clients in the untrusted network are trying to use internal WSUS instead of untrusted network WSUS. I know I can overwrite but have some workgroup PC so I can’t do it.
I must be missing something very simple.
How do I get SCCM Client to set the right WSUS server (untrusted network’s ) in “Specify Intranet Microsoft Update service Location” Setting?
You really make it appear so easy along with your presentation but I to find this matter to
be really something which I feel I’d by no means understand.
It sort of feels too complicated and extremely huge for me.
I am having a look forward to your next publish,
I’ll attempt to get the hold of it!
Great article have a question though can you describe how the process go.
when I download Updates (ADR) how the other “Site” get the updates.
Can this solution be good for DMZ ? or there is another way? can you write some words on SUP in DMZ (with RODC).
It wouldn’t change anything for your ADR actually. Let’s say you have another MP/DP in an unsecure zone. When you run your ADR, *if* your package is already synched to that distribution point, it will be distributed accordingly. And yes, you can use this setup in a DMZ, that is actually what I have 🙂
As for the SUP, it’s pretty straightforward. As long as you have the required firewall ports opened as documented here https://docs.microsoft.com/en-us/sccm/core/plan-design/hierarchy/ports (see Software update point), you should be good. As for the SQL portion for the SUS DB, you have 2 choices. Either you use your main database, or you go with the replica route. I prefered option B in my setup.
Hope this helps, and good luck!!!
Great article have a question though, what if you’re configuring WSUS with a shared content share and shared database, is there a way to give permission to the content share without a trust? and allowing everyone access?
Any guidance about issuing this machine MP and DP certs + root trust from a CA, for use with clients in the “trusted” domain?
I have to agree with jason. I have an MP/sup/dp (it’s actually a secondary) on the edge of a untrusted network with no trust. The firewall is open for the clients to talk to the above machine and it works great with just the proper install string (1706) and dns forwarders. Eventually all the untrusted machines will join our domain, but this solution works until then.
Also, this does not go over DNS functioning between the domains either. It seems to assume you can resolve hosts in the untrusted domain. This would not always be the case, especially if the domains are firewalled
It might not be super detailed, but:”You will also need to have some sort of name resolution to your primary site and SQL server. This could either be via DNS with TCP/UDP 53 opened, via host file, etc.”
The problem description here does not fit the solution. The solution presented addresses systems in a segregated network. The fact that these systems are in an untrusted forest is completely irrelevant to the solution that you are proposing because ConfigMgr simply doesn’t care if the systems are in a trusted forest/domain or not.
Hey Jason! I’m glad you decided to chime in since you were a great help while I was troubleshooting this same issue (remember on /r/sccm?) Anyway. A few hours of troubleshooting with Microsoft later, turns out that our problem was the Denying of NTLM trafic.
That is what basically prompted this post. Since I had never found a post documenting this per se, or even mentioning it. I thought it could be a good idea to leave a trace should it ever be needed eventually.
However, ConfigMgr might not care if the systems are in a trusted AD or not, but, being in an untrusted domain does still bring it’s share of challenges. It’s not as simple as when you are installing CM in your “core” domain. There’s quite a few things that you need to keep in mind or not forget. That’s what this is about. In this precise case, I know that there are easier implementations that could have been done, but this was the chosen path for us. But in the end you are right, maybe I could tweak my introduction to the issue a bit! 🙂
ConfigMgr definitely does care, the fact that you need to be able to have accounts which need to authenticate to AD to be able to even run or get the services configured required by configmgr.
You can’t configure a management point without a trust, you can’t have cross forest comms without the correct PKI setup as well. Config mgr needs things to be setup just right!