Archive: Considerations When Deploying IBCM for Configuration Manager (And All the Best Links)

I recently implemented Internet-Based Client Management (IBCM) for System Center Configuration Manager (SCCM) at a client and wanted to share some of the considerations and resources I used while setting it up. If you’re setting up IBCM for the first time, it can be quite challenging – be sure to spend plenty of time on the design to save yourself a headache later. For a simple, complete list of prerequisites for IBCM, check out this post by Justin Chalfant.

First, consider deploying DirectAccess instead of using IBCM through SCCM. This probably isn’t the advice you were expecting to read on an article about deploying IBCM, but the infrastructure requirements for both DirectAccess and IBCM are very similar, and DirectAccess actually provides more functionality than IBCM. There are a number of SCCM features that are not available in IBCM but will work under DirectAccess because it supports outward server-to-client communication. Both solutions require an internal certificate authority, a public DNS record, and external communication routed through your DMZ or reverse proxy solution. Once you deploy DirectAccess, SCCM can actually operate over the Internet fully in HTTP mode since the communication is tunneled though the IPsec protocol used by DirectAccess (no need to double-encrypt your traffic). You also get a bunch of other great features through DirectAccess like offline domain-join, the convenience of ditching your VPN solution, and regular client communication with domain controllers. You can read a very good article (it’s a bit dated, but completely applicable) about managing SCCM clients through DirectAccess on Steve Rachui’s blog post here.

One more alternative you may want to consider is Microsoft Intune. This is a great solution if you have several workstations you want to manage that are not domain-joined or rarely (or never) communicate with the domain. Intune has zero infrastructure requirements, operates completely from the cloud, and doesn’t require certificates or public DNS configuration. You deploy a client with a bundled certificate that ties to your organization in the cloud. Of course, SCCM is much more robust feature-wise than Intune, but it’s worth considering if you don’t have the resources to manage SCCM and/or if you only need to manage patching, software deployment, and antivirus. Here’s the official comparison between both products.

Let’s get back to IBCM. Understand that SCCM management points can communicate with clients in three modes: HTTP, HTTPS, or both. HTTP is the easiest to deploy since it doesn’t require an internal certificate authority and openly communicates with clients on port 80. HTTPS requires certificates to be issued since the communication is encrypted through port 443. Management Points can also accept communication from both HTTP and HTTPS protocols. The management point used for IBCM must operate in HTTPS mode. If you are currently running in HTTP mode like most organizations (Ok, that’s not exactly scientific data), you don’t need to change this. You can leave your internal management point communication over HTTP, and configure your new IBCM management point to communicate over HTTPS.

Let’s talk about how you’re going to route external traffic back into your environment – a huge security consideration. It’s possible to forward traffic from your external DNS address back into your SCCM management point. This will work, but it will also give the outside world a direct route into your datacenter. Therefore, do not use this design. The recommended way to implement IBCM is to deploy an additional management point in a DMZ/perimeter network that will be dedicated to communicating with clients on the Internet. This diagram from System Center Dudes depicts this clearly:

Of course, the challenge that comes with deploying a server in the DMZ is keeping it secure while still allowing required traffic for functionality. This information can be hard to find and is a bit convoluted in the SCCM requirements page on TechNet. This article by Justin Chalfant is by far the best article I have found regarding IBCM port requirements for your DMZ. Your DMZ management point will also need to be domain-joined, which is a somewhat unusual requirement for a DMZ server. You may need to open communication back to its local domain controller to satisfy this requirement. Also, since required RPC communication uses a dynamic port with a large range, you can shorten this range for additional security hardening by following this article.

A common challenge of deploying SCCM in HTTPS mode (required for IBCM) is correctly configuring certificates from your internal certificate authority. Deploying a multi-tier certificate authority is always more secure if you don’t have a CA deployed yet. Configuring certificate templates for use by SCCM servers and clients is actually pretty straightforward, but it does require a moderate understanding of how certificate enrollment works. Here’s an article with step-by-step instructions for the deployment of certificates required by HTTPS mode in SCCM (you can skip the AMT, Mac, and Mobile Device certificates). Luckily, deploying the certificates required for IBCM is the exact same process as deploying certificates required for normal HTTPS client communication. You’re still configuring the same type of Management Point in SCCM- you’re just enabling external communication by adding an external DNS name.

Several guides out there for deploying IBCM fail to mention this next area of consideration: you’re going to need to publish an HTTP CRL distribution point (CDP) for your Internet-based clients to reach externally. This sounds pretty daunting, but it’s simply a place for your clients to check if a certificate they’re using has been revoked by your internal CA. By default, your PKI usually publishes the CRL in Active Directory; you’re just adding another CDP location. Conveniently, you’re already setting up an IIS server for your IBCM Management Point in the DMZ, so this is an ideal location to add a CDP if you don’t have one in place already. CDPs also require port 80, which won’t be in use by SCCM (since it’s using HTTPS port 443). This is as simple as adding a new virtual directory to IIS on the same server, binding port 80 in IIS, and allowing your CA to publish CRL updates to this location. Here’s an awesome guide by Carol Bailey on how to do exactly this. You’ll want to follow the steps to “Automatically Publish the CRL on a Separate Server”. The only thing I would add to that article is that it’s very easy to verify that your CRLs are being published successfully by running “pkiview.msc” on your CA server(s).

I won’t review the actual installation of the Internet-facing management point for IBCM in this post since there are several of those out there already. Here’s a few guides that I’d recommend following for the deployment:

Once you do have IBCM deployed, you will need to configure clients to use the Internet-facing management point when they are unable to find their internal management point. SCCM boundaries work great internally but will not help you with IBCM. You can simply instruct them to use the IBCM management point when external by deploying this VBScript via SCCM or GPO (change mp.contoso.com to your public DNS address for IBCM):

on error resume next

' Create variables.
Dim newInternetBasedManagementPointFQDN
Dim client

newInternetBasedManagementPointFQDN = "mp.contoso.com"

' Create the client COM object.
Set client = CreateObject ("Microsoft.SMS.Client")

' Set the Internet-Based Management Point FQDN by calling the SetCurrentManagementPoint method.
client.SetInternetManagementPointFQDN newInternetBasedManagementPointFQDN

' Clear variables.
Set client = Nothing
Set internetBasedManagementPointFQDN = Nothing

Of course, the fault in this logic is that only clients that communicate internally will receive this deployment. There’s no easy way to push this setting to clients that never get on your internal network unless you have another solution in place. If your users use a VPN to connect to your network, be sure to add the range of IPs used by your VPN solution as an IP range boundary in SCCM to help manage those clients. Of course, the script can always be run manually for the few roaming systems you have out there.

Finally, here are some useful logs to verify that IBCM is working correctly:

Server Logs
- MPcontrol.log – On your IBCM management point, this log will verify that certificates are being used properly for HTTPS, display communication tests against itself, and show that the management point is functioning properly.
Client Logs
- LocationServices.log – This log will verify that your SCCM client is able to find your Internet-facing management point when it is off your domain network.
- ClientIDManagerStartup.log – This log will verify successful use of certificates and communication with your Internet-facing management point.

I hope this post has provided at least a little clarity around what it takes to deploy Internet-Based Client Management in Configuration Manager. Please leave a comment if I can answer any questions.