Ports Required for a Site System in DMZ in Configuration Manager


I’m often setting up a site system (MP/DP/SUP) in a DMZ for internet based client management or for managing machines in the DMZ.

One of the more common questions around this scenario are the ports required between the Site Server (Internal) and the Site System (DMZ).

All the ports for Configuration Manager 2012 are documented on TechNet here: https://technet.microsoft.com/en-us/library/hh427328.aspx but I will list the ports for a site system in the DMZ that host the following roles: management point, distribution point, software update point.

Use PortQryUI to perform the port checks: http://www.microsoft.com/en-us/download/details.aspx?id=24009

Minimizing the Risk:

When working with site system in a DMZ taking connections from the internet you want to reduce the amount of traffic that’s initiated from the site system in the DMZ to the site server.

By default, site systems initiate connections to the site server to transfer data, which can be a security risk when the connection initiation is from an untrusted network to the trusted network. When site systems accept connections from the Internet or reside in an untrusted forest, configure the site system option Require the site server to initiate connections to this site system so that after the installation of the site system and any site system roles, all connections are initiated from the trusted network.

This option can be found in the wizard when you are setting up the new site system:


Ports Required:

When using the “Require the site server to initiate connections to this site system” option for the site system, you will only need the following ports opened:

  • Site Server (Internal) --> Site System (DMZ)
    • Ports: TCP/UDP Port 135
    • Protocol: RPC Endpoint Mapper
    • Reason: Used for initiating WMI connections from the site server to the site system

  • Site Server (Internal) --> Site System (DMZ)
    • Ports: TCP Ports 49152 – 65535
    • Protocol: RPC
    • Reason: Used for WMI connections from the site server to the site system

  • Site Server (Internal) --> Site System (DMZ)
    • Ports: TCP Port 445
    • Protocol: Server Message Block
    • Reason: Used for the site server to push content to the distribution point

  • Site Server (Internal) --> Site System (DMZ)
    • Ports: TCP Port (80 or 443 or 8530 or 8531) – it depends on the port you configure WSUS to use on the Site System in the DMZ
    • Protocol: HTTP or HTTPS
    • Reason: Used by the site server’s WSUS Configuration Component to connect to the WSUS server on the site system to configure the upstream server

  • Site System (DMZ) --> Software Update Point (Internal)
    • Ports: TCP Port (80 or 443 or 8530 or 8531) – it depends on the port you configure WSUS to use on the software update point (Internal)
    • Protocol: HTTP or HTTPS
    • Reason: Used by the site systems (DMZ) server to sync it’s WSUS catalog with the Software Update Point (Internal) WSUS catalog
  • Site System (DMZ) --> SQL Server (Internal)
    • Ports: TCP 1433 (Default unless SQL using custom port)
    • Protocol: SQL over TCP
    • Reason: Used for the management point in the DMZ to hit the site database (If the site server is not hosting the site database you will need to create to rule to the appropriate server) to receive information
  • Site System (Management Point - DMZ) --> Domain Controller (Internal)
    • Ports: TCP/UDP 135, TCP 389, TCP 3268-3269, TCP 49152 – 65535
    • Protocol: RPC Endpoint Mapper, LDAP, LDAP SSL, Global Catalog LDAP, Global Catalog LDAP SSL, RPC
    • Reason: Allows the management point (DMZ) to authenticate to active directory so it can connect to the site database server using its computer account.
    • Exception: If you use a domain user account for the management point connection account rather than the computer account of the management point (See screenshot), authentication can fallback to use NTLM rather than Kerberos if ports to an internal domain controller are not open. In this scenario, the site system would not need any ports open to an internal domain controllers.


Additional Information:

Configuration Manager requires each site system to be a member of an Active Directory domain so you cannot install a site system in a DMZ if the server is not joined to a domain.

You can install a site system in an untrusted domain. However, the site systems forest does not trust the forest the site server is in user based deployments are not supported. When no trust exists, only computer policies are supported.

More information about untrusted scenarios can be found here: https://technet.microsoft.com/en-us/library/dd8eb74e-3490-446e-b328-e67f3e85c779#Plan_Com_X_Forest

Disclaimer: The information on this site is provided "AS IS" with no warranties, confers no rights, and is not supported by the authors or Microsoft Corporation. Use of any included script samples are subject to the terms specified in the Terms of Use

Comments (18)
  1. Anonymous says:

    Overview: I often find myself talking to customers about the requirements to setup Internet-Based Client

  2. Chris Mullins says:

    This is a ridiculously handy post. I’ve had arguments with Firewalls admins in the past about making these exceptions in their policy, requesting proof, the threshold for which seems to vary from admin to admin. Now I can just point them to this page.

  3. Anonymous says:

    You don’t show any connection from the Site System Server in the DMZ , specifically the MP role, back to the Primary Site Server. Are there not ports that need to be opened from the DMZ hosting the MP to the Primary Site Server if you check the aforementioned
    box you referenced above?

  4. I listed the ports for the MP to SQL right in the post.

  5. Anonymous says:

    What if SQL isn’t installed locally to the Primary Site Server?

    1. Then the SQL ports would be the site system SQL is installed on.

  6. As shown in the blog: Site System (DMZ) –> SQL Server (Internal) The port goes to the SQL server.

  7. Anonymous says:

    For ease of discussion lets say all of my site system roles are installed on my Primary Site Server. In this scenaris, you are stating that the only ports that need to be open from the DMZ to the Primary Site Server are 1433 for SQL, and the appropriate
    port for Software Updates (8531 in this case). That’s it?

  8. Yes, assuming you check the box shown in the screen shot to require site server to initiate communication.

  9. Anonymous says:

    Huh! Interesting. Thank you so much Justin. Just seems too simple 🙂 Thank you also for the quick responses.

  10. prashant says:

    What if i set up sql replica in dmz for dmz based site system. Do i still.require to open ports from dmz to internal server??

  11. prashant says:

    So what if I don’t want to open any connection from DMZ to Internal server..i read in few blogs that 1 sided connection should suffice the requirement.

  12. Chris says:

    I am trying to sort out a similar situation with an SCCM server in the customer’s DMZ, which is a Management Point, Distribution Point and Software Update Point, but is part of the internal primary SCCM site.

    The problem is that the clients in the DMZ ignore the Software Update Point in the DMZ (boundaries don’t control designation of Software Update Points) and get configured, by the local policy created by the SCCM agent, to point to the internal Software Update
    Point server for WSUS scanning, but ports 8530 and 8531 are not open between the DMZ and the internal network, so the scanning fails as the DMZ clients cannot contact the internal Software Update Point.

    My understanding was that the inability to direct different SCCM clients within a primary site to different Software Update Points, using boundaries or any other method, is a known limitation, and is the reason why Microsoft tell customers to only deploy one
    Software Update Point per SCCM site.

    However, this article seems to talk about putting a second (not the internal) Software Update Point within the DMZ, within the same SCCM site as the internal network and another internal Software Update Point, and only allowing ports 8530 and 8531 between the
    DMZ SCCM Software Update Point and the internal SCCM Software Update Point and not having to open up ports 8530 and 8531 between the internal Software Update Point and every DMZ client.

    Can you clarify if the scenario described in the paragraph above is possible and, if so, whether there are any key configurations required in order to make this work, and how this works?


  13. Steph says:

    Morning all,

    So I am starting to look into this as well. To all of you who have done this successfully, do you all have an Active Directory in your DMZ(s)? I think you don’t have any other choices right?

    Also, what’s the necessity to have a SUP in the DMZ? Is it to have a WSUS instance to be used by clients in the DMZ, instead of having them trying to reach the WSUS internally? I’m guessing that would be it.


  14. Hi Steph, Yes the DMZ site system will need to part of a domain. It can be an untrusted domain though. For the SUP, you will need to install WSUS ahead of time.

  15. Sharath Chandra says:

    Well documented. This will help us to justify the port requirement used by SCCM site components.

  16. Orlando says:

    Hi, thanks for the post.
    I have one site primary site with a primary SUP. In the DMZ I have a RODC, a DP,MP and SUP.
    I can get all the DP features working such as application delivery but I cannot get the DMZ clients to fail over to the DMZ SUP.
    It gets a timeout error as the FW blocks connections to the internal SUP.
    I’ve checked that the error is in the retry codes both on the site server and clients but still no failover.
    Has anyone manage a successful failover to a DMZ isolated SUP?

Comments are closed.

Skip to main content