System Center Configuration Manager in a Cloud Era

System Center Configuration Manager in a Cloud Era

System Center Configuration Manager (SCCM) has long been the industry leading platform for managing devices within an organisations environment.Focused primarily on workstations (desktops and laptops), it is also quite at home managing servers as well across inventory, application deployment, patching, operating system deployment, endpoint security and compliance management. With the introduction of Intune for Mobile Device Management (MDM), Configuration Manager (ConfigMgr) was extended to work in a hybrid mode to help give a single pane of glass management experience across both on-premises full fat windows devices and the usually off network mobile devices. With the ever evolving current branch model of Configuration Manager, some of the recent new features introduced are focusing on integrating more with Azure and helping to introduce even better management for remotely connected devices and leveraging Cloud based services.

Written by

on

17 Aug 2017

Going Cloudy…

With the release of Configuration Manager 1706, we see a refinement and introduction of the following features:

• Cloud Management Gateway
• Cloud Management (Azure Active Directory Discovery)
• Operations Management Suite Connector
• Upgrade Readiness Connector
• Windows Store for Business

And not that it’s new, there is also the Cloud Distribution Points feature that rounds off the feature set.The two main ones of interest, for myself anyway, are the Cloud Management and Cloud Management Gateway.

Cloud Management and Azure Active Directory

Cloud Management allows you to connect ConfigMgr to your Azure Active Directory (AAD) subscription. This then allows you to discover all users within the subscription.
Regardless, whether an account was created on-premises in Windows Server Active Directory (WSAD) or natively, in the Cloud in AAD, ConfigMgr can now discover all of your user accounts, no matter their location. Discovering accounts is one thing, but what use are they (other than from a metric and reporting capacity). Well… that’s where the Cloud Management Gateway comes into play. 

Cloud Management Gateway

The Cloud Management Gateway (CMG) was first introduced in release 1606 as a way to potentially replace the Internet Based Client Management (IBCM) role.
While the IBCM requires you to deploy the role to a server within your environment, open up ports to route traffic through your firewall and secure your ConfigMgr infrastructure using PKI, the CMG’s aim was to simplify this by utilising Azure to host the client connection point and have communications flow to the ConfigMgr site via SSL, without having to open ports and route traffic back through via a specific edge address. 

Just to re-iterate; ConfigMgr must be able to talk out to the CMG via port 443, but there does not need to be any ports open inbound.

 With the 1706 release, we gained some new features for the CMG, specifically the ability to utilise those accounts we’ve just discovered from AAD.This opens up a whole new scenario where a non-domain joined device can be registered to AAD and then can authenticate to the CMG without the need for certificates.Think of it this way, a new user starts (or an existing user with a broken device) who gets a new device directly from the a shop. This device has not been configured by IT, is fresh out the box as it came from the manufacturer. They turn it on, follow the Out-Of-Box (OOB) experience and logon using their e-mail address (which should be their AAD Logon). Once the ConfigMgr client is installed (how that gets installed is another topic) then it can authenticate to the ConfigMgr environment using the AAD credentials and policy and software applied to the device to get it ready for use within your organisation, without IT needing to spend time manually setup the device! 

So what does this look like?

At the simplest layer, adding a CMG will provision a Cloud Service in Azure based medium size Virtual Machines (VM) (2 cores, 3.5Gb Ram). This can be 1 or more scale instances, but for High Availability, 2 should be the minimum and then scale out from there (via the ConfigMgr console) depending on the number of clients you need to support. This Azure Cloud Service isn’t joined to your internal domain in any way and is designed to be hands off in terms of management. ConfigMgr will handle the service deployment and (re)creation of the VM’s as needed. The principal is the same for the Cloud Distribution Points (CDP), except they utilise an extra small instance size (Shared CPU, 768Mb RAM).   It’s worth calling out that at present Cloud services are deployed using the Azure Service Management (ASM) model, sometime referred to classic Azure, not the newer Azure Resource Manager (ARM) model. While doing initial testing against the various machine types, how they were domain joined (or not) and the user source (Cloud native or Sync’d) the following observations were made:  

Before you start clicking away, here are some of the things you’ll need to prep ready in advance:

• Enough rights in Azure AD to create applications ConfigMgr needs to read the data for discovery
• A management certificate uploaded to Azure and provided to ConfigMgr to allow it perform tasks (Create AAD apps, create CMG & CDP cloud services)
• Public DNS (cname) records for the CMG & CDP that clients will connect to that point back to the azure .cloudapp.net addresses.
• A couple of public certificates which match the DNS names for the CMG & CDP
• “Potentially” a PKI environment within your domain

So what does this give me?

We now have a really cool solution to manage both domain joined clients that roam away from on-premises to internet connected and non-domain joined (but Azure AD Joined) devices sat anywhere with an Internet connection.

Along with the Cloud Distribution Point, we have a solution to manage discovery (Inventory), management (Policy & Compliance), application deployment and patching of devices wherever they are without having to expose the internal ConfigMgr environment to the internet or manage that routing/access in.

While the features are the latest production release, there are still preview features and will still receive feature updates to help further close the gap of unsupported features, as below:

The following features in Configuration Manager are currently unsupported for Cloud management gateway:

• Client deployment
• Automatic site assignment
• User policies
• User targeted apps via the Application catalogue
• Full operating system deployment (OSD)
• Remote tools
• Wake on LAN
• Mac, Linux, and UNIX clients
• Azure Resource Manager
• Peer cache

Plan for Cloud Management Gateway

Plan to use a Cloud Distribution Point

Configure Azure AD Discovery

Keep Up To Date – Join The Mailing List

Subscribe

The team are here to help

If there are any questions and want to learn more about PowerON’s services or Solutions, please get in touch and a member of the team will be in touch shortly. 

• PowerON, Stanley Harrison House, York, YO23 1DE
• 0800 3029280
• info@poweronplatforms.com

Contact PowerON