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 multiple options to achieving 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 to manage these remote systems using Microsoft’s management technologies.
The traditional Virtual Private Network.
Tried and true. Your organization probably already has something like this set up so there’s nothing additional for you to really do.
Traditional VPNs generally 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.
Microsoft’s corporate network connectivity solution. This is similar to a VPN in that it creates a tunnel from the user’s system to the internal network (and vice-versa).
Direct Access is an always on solution that requires no direct user intervention. Direct Access’s main 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.
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.)
Microsoft’s cloud hosted OS and device management system.
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 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 specifically protect anything from the bad guys and you don’t have to account for this traffic in your Internet connectivity solution.
The full Windows Intune agent, although more capable, has not 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. If you are on Windows 7 or 8, there is no built-in OMA-DM agent and the OMA-DM agent in Windows 8.1 is very bare bones.
Delivering everything from the cloud can be 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.
Although the full Intune client agent is relatively feature rich, it lacks the flexibility and power of traditional, full-blown, on-premises management tools like ConfigMgr. The Intune console also lacks many capabilities including rich reporting.
Finally, you are relying on Microsoft’s cloud and Windows Azure for everything. This can be a fantastic thing … until it isn’t.
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.
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).
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.
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.
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, it’s 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.
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.
None, see the notes above.
This is not a technically suitable or sufficient solution for managing remote clients as noted above.
So what’s the answer here for your organizations remote system management needs? Well, that’s up to you and your organization based upon your requirements and capabilities of each of the solutions above. There actually is another option also that I will be exploring in my next post: IBCM using Azure.