In this post I provide information that can be used to assist with the design of a ConfigMgr 2012 infrastructure to manage Internet-based clients.
Security must be taken into consideration when designing your ConfigMgr infrastructure. Although PKI is used for authentication and encryption, the clients will be connecting to your on-premises ConfigMgr server(s) from a vast and unsecured public network: the Internet.
Before you start working on supporting Internet clients, you may want to verify that you'll be able to accomplish your goals.
Client Features Supported
Client Features Not Supported
![]()
![]()
![]()
Security must be taken into consideration when designing your ConfigMgr infrastructure. Although PKI is used for authentication and encryption, the clients will be connecting to your on-premises ConfigMgr server(s) from a vast and unsecured public network: the Internet.
Before you start working on supporting Internet clients, you may want to verify that you'll be able to accomplish your goals.
Client Features Supported
- Inventory
- Software distribution
- Software updates
- Software metering
Client Features Not Supported
- Client deployment over the Internet, such as client push and software update-based client deployment.
- Automatic site assignment.
- Network Access Protection (NAP).
- Wake-on-LAN.
- Roaming (clients non-deterministically select a site system regardless of bandwidth or location)
- Operating system deployment (but you can deploy task sequences that do not deploy an operating system)
- Remote control.
- Out of band management.
- Software deployment to users unless the Internet-based Management Point (MP) can authenticate the user in Active Directory Domain Services by using Windows authentication (and an Active Directory trust).
Site System Roles Supported
- Management Point
- Distribution Point
- Fallback Status Point
- Software Update Point
Placement of ConfigMgr Servers
There are different ways to place your ConfigMgr servers to support Internet clients. Where you place them depends on the level of security you are required or willing to implement. In all scenarios below, the site system servers supporting intranet clients were removed from the graphics for clarity.
The external firewall allows incoming HTTPS traffic to the site system servers supporting Internet clients (HTTP for traffic going to Fallback Status Point). See this Microsoft article to determine what ports need to be open in the internal firewall for ConfigMgr-related traffic, and this article for Active Directory traffic.
Note that you can avoid opening the SQL port for communication between the Management Point in the DMZ and the SQL server hosting the ConfigMgr database if you place a replica of the site database on the Management Point system (but you must allow the traffic of the site server publishing the database replica).
When deploying site systems in an untrusted network, such as the DMZ, select the Require the site server to initiate connections to this site system option so the site systems don't initiate connections to your trusted network. Note that a Site System Installation Accountis needed to deploy the site system.
DMZ Servers in a different Active Directory Forest
If Forest B trusts Forest A, then user policies are also supported. The internal firewall would allow the one-way AD Trust traffic through, as well as communication between the ConfigMgr site server in the Intranet and the site system servers in the DMZ.
DMZ Servers in the same Active Directory Forest
This scenario is similar to the first one, with the main difference being that the site system servers in the DMZ belong to the same AD Forest as the primary site server in the intranet. To protect domain controllers from being accessed from an untrusted network (by the ConfigMgr servers in the DMZ), a Read-Only Domain Controller (RODC) is placed in the DMZ (internal firewall must allow DC replication traffic from the intranet to the DMZ).
No ConfigMgr Servers in the DMZ
In this scenario the site systems supporting Internet clients are in the Intranet (except the Fallback Status Point), and their services are published to the Internet via a Web Proxy such as Microsoft ISA or Forefront Threat Management Gateway using SSL Bridging or Tunneling (SSL Bridging is recommended as it is more secure). The site systems in the intranet can be configured to support only Internet clients or both Internet and intranet clients.
Fallback Status Point
The Fallback Status Point (FSP) requires special consideration because you can have multiple FSPs in a ConfigMgr site (such as one in the Intranet and one in the DMZ) but a ConfigMgr client only talks to one (the one that it talks to when the client is installed).
If your ConfigMgr site supports clients when they are connected to the intranet or Internet, they'll attempt to talk to the same initial FSP regardless of their location. In my opinion, if I have to choose, I prefer that they can talk to it from the Internet, otherwise if there are issues with the client we have no way to gather troubleshooting information unless we have access to the client system. If you have Internet clients that never connect to the intranet then you could setup an independent ConfigMgr infrastructure in the DMZ with its own FSP.
SCCM