For some time I’ve been busy configuring Internet Based Client Management (IBCM) at a customer of mine. The infrastructure consists of System Center 2012 Configuration Manager R2 SP1 and has one primary site. One management server was already present for the intranet clients and I wanted to add the necessary means to support IBCM.
The most straightforward method was to add an additional management server which would be occupied with everything related to internet clients.
The general setup can be found here: https://technet.microsoft.com/en-us/library/gg682023.aspx#BKMK_webserver2008_cm2012 and is quite straight forward.
Now the tricky part: How to make sure the infrastructure can be reached from the internet? First of all I needed a public IP adress which I could use for the CNAME eg. sccm.customer.com. Then I needed to add the necessary components in the reverse proxy solution available (in this case: Citrix NetScaler). There I added a virtual server on port 443 configured using Protocol SSL_BRIDGE. This makes sure the connection gets passed through the NetScaler directly to the backend server.
When this was configured deploying software, requesting policies, etc. worked like a charm.
Additionally I wanted to make sure internet client could also use SCCM to check for updates (not directly to Windows Updates).
Therefore some extra configuration was needed:
- Install WSUS on the new management server (sharing the same database as the WSUS that is already present in the Configuration Manager infrastructure.
- Install SUP on the new management server (with SSL enabled + Internet only traffic allowed)
- Configure IIS to use the SSL certificate (additional information here)
- Make sure URL https://sccm.customer.com:8531 can be resolved on the internet ( therefore an additional virtual server can be added to the NetScaler: port 8531 protocol TCP)
Now when a computer is connected to the internet, the SCCM agent will detect that and will replace the existing WSUS URL (eg. http://sccminternal.customer.local:8530) by the one available from the internet (https://sccm.customer.com:8531). One of the places to check this is in registry: HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate. This should point to the internet available FQDN. Also the Locationservices.log should show some information.
When the computer checks for updates it will connect to the published URL to see what updates are missing. Afterwards the deployment of updates will be checked to see what updates are “Actionable” (see UpdatesDeployment.log)
For the download itself the agent will use Windows Update. These downloads are done over HTTP and can be followed in the DataTransferServices.log on the computer.
The user experience is the same. Everything is listed properly in the Software Center
If Windows Update isn’t available then a fallback will happen to http://sccm.customer.com. But because HTTP traffic isn’t redirected through the reverse proxy this will fail. Nevertheless I prefer the direct download from Windows Update as this minimizes bandwidth constraints in the customer infrastructure.
Hope this helps.