Remote Systems Management in Configuration Manager

Managing remote systems, i.e., those not directly connected to your internal network, is a challenge best not overlooked for multiple reasons including security. With Microsoft System Center Configuration Manager (ConfigMgr) and Microsoft Intune, you have numerous options to achieve this. Note that all of these, of course, require an active Internet connection on the client as there’s no magic, universal Ethernet so that is something that could be said for each of these.

The below summarizes the different approaches organizations use or may consider managing these remote systems using Microsoft’s management technologies.

[ms_alert icon=”fa-pencil” background_color=”#00274c” text_color=”#f5f5f5″ border_width=”0″ border_radius=”2″ box_shadow=”no” dismissable=”no” class=”” id=””]Updated 22 September 2018.[/ms_alert]

VPN

The traditional Virtual Private Network.

Pros

Tried and true. Your organization probably already has something like this setup, so there’s nothing additional for you to do really.

Cons

Traditional VPNs often require user intervention to initiate the connection as well as to provide user-based credentials to authenticate. Thus, you are very much at the mercy of the user for when and how long management of the system can occur. This also generally requires additional software loaded on the system.

Direct Access

Microsoft’s corporate network connectivity solution. Direct Access is similar to a VPN in that it creates a tunnel from the user’s system to the internal network (and vice-versa).

Pros

Direct Access is an always-on solution that requires no direct user intervention. Direct Access’s primary role in life is extending the internal services of a network including management of Internet-connected systems in a secure and controlled manner.

Direct Access creates a tunnel between the OS and the internal network whenever connectivity is available using industry standard protocols including IPv6 and IPSEC. Traffic can be allowed or blocked on a very granular level and authentication is done using certificates or Kerberos for domain joined systems.

Cons

Many networking groups and people do not trust Microsoft solutions and thus either do not know about Direct Access or would never consider using Direct Access. Direct Access also requires a limited amount of IPv6 support and infrastructure which often scares both network and Windows admins alike.

Previous versions of Direct Access had some limitations that caused folks to steer away from it or not be able to implement it at all; e.g., two consecutive public IPv4 addresses, certificate only based authentication, the need for UAG to provide granular traffic control and ACLs. (These three limitations, among others, were done away with starting with Windows Server 2012.)

Intune (stand-alone)

Microsoft’s cloud-hosted OS and device management system.

Pros

No on-premises infrastructure is required. Additionally, Intune supports mobile device management (MDM) — including iOS and Android — and mobile application management (MAM) on these platforms. Intune also supports managing Windows 8.1+ systems using the built-in OMA-DM agent or Windows 7+ systems using a full Intune agent (which at this time, for certain functions, is generally more capable and feature-rich than the built-in OMA-DM agent).

One benefit often overlooked is that the managed systems and clients do not ever communicate with anything in your on-premises infrastructure — this means you don’t have to explicitly protect anything from the bad guys and you don’t have to account for this traffic in your Internet connectivity solution.

Cons

The full Windows Intune agent, although more capable, it has not been improved in many years and to my knowledge will not be instead deferring to the built-in OMA-DM agent as it improves with each new release of Windows 10. The full Intune agent lacks the flexibility and power of traditional, full-blown, on-premises management tools like ConfigMgr though. However, if you wish to manage Windows 7 or 8, the full Intune agent is the best choice as there is no built-in OMA-DM agent in Windows 7 and the OMA-DM agent in Windows 8.1 is very bare bones.

Intune MDM management of Windows 10 heavily (almost exclusively) depends on the capabilities of the [OMA-DM] management agent built-in to Windows 10. Depending on your desires and requirements, this generally falls (far) short of expectations and the capabilities of ConfigMgr. This last statement is, of course, my biased opinion but is generally shared by most. As initially noted though, things change fast and each version of Windows 10 continues to add more and more capabilities that Intune can take advantage of.

Intune itself also lacks many capabilities including rich reporting.

Delivering everything from the cloud can become expensive and of course relies exclusively on the Internet; this latter point is, of course, obvious and a baseline assumption for this post for remote systems but for on-premises systems this adds time and additional bandwidth use that you would not typically have to account for. The bandwidth usage and time can be limited using BITS and BranchCache, but some will always be required.

Finally, you are relying on Microsoft’s cloud and Windows Azure for everything. This can be a fantastic thing … until it isn’t.

[ms_panel title=”Deprecated” title_color=”#f5f5f5″ border_color=”#00274c” title_background_color=”#00274c” border_radius=”2″ class=”” id=””]Intune Hybrid is now a deprecated feature set and should not be considered for any new deployments. Additionally, any existing deployment of Intune hybrid should be migrated to Intune stand-alone. See Move from Hybrid Mobile Device Management to Intune on Azure for the official announcement and information. I’ve left this section in this post for completeness and information.[/ms_panel]

Intune (hybrid)

This is the same cloud OS hosted device management systems as in the previous item but integrated with ConfigMgr. In this “mode” all MDM administration (including managing Windows 8.1+ systems using the built-in OMA-DM agent) is performed using the ConfigMgr console.

Pros

This mode of Intune unifies Windows and device management into a single management console: the ConfigMgr management console. Additionally, it requires no additional on-premises infrastructure to add the MDM capabilities and communication with mobile devices is done via the Microsoft cloud (exactly like Intune Stand-alone in the previous item).

Cons

Windows systems managed by the full Intune agent are not managed from ConfigMgr. Intune in the hybrid mode is only for MDM. Although this includes managing Windows 8.1+ systems using the built-in OMA-Agent, as noted in the previous item, the OMA-DM agent in Windows is currently not as full-featured and IMO is only suitable for small-businesses and BYOD scenarios and then only for Windows 10 as the Windows 8.1 OMA-DM agent is all but useless.

Thus, if you need feature-rich management of remote Windows systems and have ConfigMgr, Intune hybrid is not a good fit.

Do note that you can actually still install the full Windows Intune agent when Intune is in hybrid mode. As noted previously, Intune hybrid is for MDM only though (the option in Intune to enable hybrid is actually called the “MDM Authority” which clearly indicates this). Thus, the management of Windows systems using the full-agent is unchanged by integrating Intune with ConfigMgr. You would manage these systems exactly as you would with Intune stand-alone using the Intune web console. This results in two management consoles to manage your Windows systems: one for on-premises systems, the ConfigMgr console, and one for remote systems, the Intune console. This also results in two different and separate sets of management and reporting capabilities for these systems. I don’t think I would ever recommend that anyone should do this, but it is technically possible.

ConfigMgr + Internet-Based Client Management (IBCM)

IBCM is a built-in feature set of ConfigMgr. It enables ConfigMgr to directly manage remote systems using nearly the full set of capabilities in ConfigMgr.

Pros

From an administrative perspective, most everything remains exactly the same — you manage remote systems the same way that you do on-premises systems. You must account for possible slow connection speeds or metered connections, but nothing as far as the actual administration of these systems changes — its seamless management of them.

Cons

IBCM typically requires additional infrastructure in the form of Internet exposed systems. This can be done using a reverse proxy or by placing additional site systems in whatever form of internet exposed DMZ your organization uses. This also implies that all client traffic must reach ConfigMgr directly via your organization’s Internet connection meaning that you now have to protect the systems and traffic from the bad guys as well as account for the additional traffic on your Internet circuits.

IBCM also requires Public Key Infrastructure (PKI) certificates for the Internet-facing site systems and for the clients. This latter equates to a unique certificate issued to each and every client that will connect remotely. These don’t explicitly have to be from an internal PKI, but it will be quite expensive and logistically difficult to manage these if you aren’t using an internal PKI.

The fact that PKI certificates are used isn’t really the detractor here; the detractor here is setting up and maintaining the PKI infrastructure. Neither of these is truly difficult if you know what you are doing, but it is quite easy to mess up a PKI deployment and adversely affect other things in the environment if you don’t know what you are doing. PKI does also add some a small amount of additional overhead and complexity to the environment and all tolled, it ends up scarring most folks.

[ms_alert icon=”fa-pencil” background_color=”#00274c” text_color=”#f5f5f5″ border_width=”0″ border_radius=”2″ box_shadow=”no” dismissable=”no” class=”” id=””]Updated 12 February 2018: Added ConfigMgr + Internet-Based Client Management (IBCM) from the Cloud section.[/ms_alert]

ConfigMgr + Internet-Based Client Management (IBCM) from the Cloud

A variation of using IBCM with on-premises infrastructure is hosting the required, Internet-facing site system(s) in a virtual machine within one of the cloud providers. This is technically valid and doable assuming that the Internet managed clients can reach the site system and the site system can fully communicate with the site server.

Pros

Similar to moving any on-premises infrastructure component to a public cloud, cost and maintenance overhead are the main driving factors here.

From a security perspective, not only are you offloading your infrastructure to the public cloud, but you are also offloading the security overhead of the client connections originating from the Internet. With all of the different threats and players attempting to exploit anything and everything on the Internet, not having to manage or monitor the additional traffic, connections, and internal endpoints is certainly a significant advantage to hosting anything in a public cloud.

Cons

The costs involved are recurring and variable depending upon your cloud provider’s pricing model; they will most likely include the cost of an IaaS based virtual machine, storage, and egress traffic from the cloud to the clients as well as to your on-premises site server (assuming it is still on-premises).

A direct connection from an on-premises site server to a site system in a public cloud can be expensive or limited in capability.

You still have to manage and maintain the virtual machine and the operating system running on the virtual machine.

ConfigMgr + Cloud Distribution Point

This item is only included here for completeness as it is not a technically suitable or sufficient solution for managing remote clients. ConfigMgr clients must be able to communicate with a management point (MP) to retrieve their policies; i.e., the instructions on what they are supposed to do. Distribution points (DPs) only provide the files for applications, packages, updates, etc. which are collectively and generically known as content. DPs do not provide policy. Thus, without being able to communicate with an MP, the client agent is completely orphaned and unmanaged.

You could combine this with an IBCM based MP and then the solution is mostly sufficient. In this case though, the IBCM section above still fully applies and thus ConfigMgr + Cloud DP is really just a variation of the ConfigMgr + IBCM solution. Also, note that Cloud DPs do have some smaller short-comings like not being able to distribute third-party updates which is why I say this is mostly sufficient as you may end up having an IBCM based DP for this anyway.

[ms_alert icon=”fa-pencil” background_color=”#00274c” text_color=”#f5f5f5″ border_width=”0″ border_radius=”2″ box_shadow=”no” dismissable=”no” class=”” id=””]Update: The inability for Cloud DPs to host third-party updates was removed in ConfigMgr CB 1702.[/ms_alert]

Pros

None, see the notes above.

Cons

This is not a technically suitable or sufficient solution for managing remote clients as noted above.

[ms_alert icon=”fa-pencil” background_color=”#00274c” text_color=”#f5f5f5″ border_width=”0″ border_radius=”2″ box_shadow=”no” dismissable=”no” class=”” id=””]Updated 12 February 2018: Added ConfigMgr + Cloud Management Gateway (CMG) section[/ms_alert]

ConfigMgr + Cloud Management Gateway (CMG)

The CMG capability was added in ConfigMgr Current Branch 1610. Ultimately, CMG is an extension of IBCM. The main difference is that instead of hosting the necessary additional required components and infrastructure yourself on-premises, these requirements are offloaded to a service in Microsoft Azure. Essentially, this Azure service (which is hosted on a managed Azure IaaS virtual machine) proxies MP and SUP traffic to and from managed clients on the Internet to your site. A Cloud DP is also required to deliver content other than Microsoft updates.

A server authentication certificate for the Azure service is still required along with a management certificate for Azure itself.

Client authentication is handled using the same PKI based certificates as in IBCM or using a token issued by Azure AD if the clients are either Azure AD registered or Azure AD domain joined.

Pros

The primary advantage with a CMG implementation is removing the hassle of implementing and maintaining any on-premises infrastructure; this includes eliminating any required networking and security configuration or coordination and any on-going maintenance of these.

From a security perspective, not only are you offloading your infrastructure to Azure, but you are also offloading the security overhead of the client connections originating from the Internet. With all of the different threats and players attempting to exploit anything and everything on the Internet, not having to manage or monitor the additional traffic, connections, and internal endpoints is certainly a significant advantage with CMG.

Because CMG is a managed service, you do not have to maintain or manage the virtual machine(s) hosting it in Azure — you just pay for and use them.

Cons

Because CMG is a service((CMG is an Azure specific service and cannot be hosted in any other cloud.)), you will pay for it monthly. This includes a base cost for the IaaS virtual machine as well as outbound traffic from Azure. Because this outbound cost is variable, your costs will also be variable and not predictable before you start using the CMG. Depending on your organization and the costs associated with setting up and maintaining the additional infrastructure, security, and networking for a standard IBCM deployment though, the cost for a CMG could be cheaper. Don’t make the mistake of assuming that on-premises infrastructure, security, and networking is free — it’s not. There are always initial and on-going costs with on-premises infrastructure even if you don’t see or account for them explicitly.

CMG still requires PKI certificates or Azure AD registered or Azure AD domain joined systems.

CMG doesn’t support everything. Most notably, task sequence support is missing.

[ms_alert icon=”fa-pencil” background_color=”#00274c” text_color=”#f5f5f5″ border_width=”0″ border_radius=”2″ box_shadow=”no” dismissable=”no” class=”” id=””]Updated 22 September 2018 to include Co-Management[/ms_alert]

Co-Management

Co-management = Win 10 management by both [stand-alone] Intune and ConfigMgr. Basically, it’s dual or shared management of Win 10 systems that allows the strengths of both solutions to be used simultaneously. Co-management in and of itself is not a solution for managing Internet-connected Windows 10 systems. Yes, Intune does that (as discussed above), but some management experiences in Intune fall far short of what many customers expect; e.g., Windows Update management which is done by Windows Update for Business in Intune.

Co-management, by the book, requires a ConfigMgr Cloud Management Gateway. This does enable full management of Internet-connected systems by ConfigMgr (also as noted above). At a purely technical level, this is explicitly required for co-management, but the documentation does more or less state that it is something that is part of co-management.

Pros

The same as given above for Intune and CMG.

Cons

More or less the same as given above for Intune and CMG. Additional complexity by having two simultaneous management systems could also be considered a detractor here though.

Conclusion

So what’s the answer here for your organization’s remote system management needs? Well, that’s up to you and your organization based on your requirements and capabilities of each of the solutions above.