How Microsoft uses Intune internally to manage Windows devices

Introduction

These are my notes about a session I’ve attended at Microsoft Ignite 2019, you can review the recording for this session here.

This session was delivered by Seth Malcolm, part of a team of Program Managers responsible for Intune showcasing at Microsoft (CSEO) and the session was created to allow us to get an inside view of how Microsoft is managing it’s Windows devices with Intune and how it’s migrating existing ConfigMgr domain joined devices to Intune only.

Looking at the numbers

In the slide below you can see that currently there are a large number (420,000) of Intune managed devices (phones, tablets, pcs) and that’s because people (135,000 users at Microsoft) have multiple devices. There are 40,000 devices that are managed in the cloud (Azure Active Directory Domain Joined) but there are a whopping 240,000 domain joined devices (ConfigMgr c0-managed domain joined devices).

Next, Seth started talking about the over complexity of on premise activities such as GPO settings, which require a lot of admin work versus the simplicity of one place to do all activities in the Intune console, so it makes sense to move to the cloud.

As part of the migration towards modern management, they are moving to a wireless first, internet first environment by decommissioning private corporate networks within Microsoft. The main sites (head office) will still retain the corporate network but the 500 or so branch sites will have it removed altogether.

I’m assuming here that there are no proxies involved in these WiFi networks as those can post challenges (and road-blocks) for Windows Hello and Windows AutoPilot.

Also, he referred to server retirements for example ConfigMgr servers being retired as more services move to the cloud.

Speaking of ConfigMgr, here’s how a typical organization that is using co-management looks like, the interface to the cloud is the Cloud Management Gateway.

Moving to modern management in phases

In order to complete the move to fully modern managed, Microsoft started with a Proof of concept of approximately 1% of devices, and these early adopters were already inside the IT Group or the very people engineering changes in Intune.

This was done because there isn’t a direct parity between what was called System Center and Microsoft Intune in a lot of cases. Microsoft had to determine how devices reacted to MDM settings versus the way it used to be done with Group Policy Objects.

The Foundational phase is where Microsoft has been working in the last 12 months or so to try and identify and understand all the 1500 group policies, who created them, where did they come from, were they for example from some small pilot 7 years ago.

Next the Transition to full modern phase is where Windows AutoPilot comes in, and Microsoft has been working in the last few weeks with OEMs, basically when a user gets a new PC it will already be Windows AutoPilot enabled and they’ll be modern managed and Azure AD joined.

The interesting quote at the end of this migration is when all the legacy hardware gets replaced with Windows AutoPilot hardware in approx 3 years that the ConfigMgr infrastructure will be decommissioned. I’ve asked the Microsoft Product Group to comment on that.

Foundational Components

The majority of work in this migration to fully managed is with these foundational components (the second phase of the overall migration to fully modern managed).

This involved installing Microsoft Defender ATP (Advanced Threat Protection) to control applications and that’s how they control which applications can or can’t run on devices inside the Microsoft network and right now they are using a Blacklist concept, and will decide going forward if it meets the needs in the future.

Next was setting up policy, for example MDM settings within Intune. Rather than trying to convert the existing GPO settings to MDM security baselines they started from scratch and imported the baselines directly in Intune and then looked at what their security team required, and made changes to the baseline based on those requirements.

There are tools out there to ease this such as MMAT (MDM Migration Analysis Tool ), which basically allows you to monitor the policy on ConfigMgr managed devices that are joined to your domain and translate it to Intune MDM settings. You can download that tool from GitHub here. What they found with this tool is that again they had policies that they didn’t know where they came from, perhaps they were too restrictive in the past and this activity was a great way of cleaning up these old settings.

You’ll need a test environment as part of this migration so that you can test policy changes and see how it translates in a modern managed environment. For some of the settings that they found were missing, they could create custom URI’s in Intune. What they did find was that there are some device settings that don’t unset themselves when the device is removed from modern management to a different management agent due for example to device settings remaining in the registry.

Windows Update for Business

The next logical step is to remove your on-premise WSUS infrastructure for delivering updates and instead move to Windows Update for Business. And of course they want a reduction in bandwidth utilization using Delivery Optimization using a peer to peer sharing protocol that lets devices share updates in the same region so that not all devices are downloading them from the Internet at the same time. This is just another way to provide updates that still let’s you have some control.

Windows AutoPilot

This is the mechanism that they are using to roll out their modern management initiative. AutoPilot provides the out of box experience (OOBE) customized for your corporate users. Microsoft in the past uses a standard image but companies in factory or retail may have customized images. Customized images take time and effort to maintain, Windows AutoPilot cuts out this effort by delivering a standardized image with custom OOBE settings.

There are now three user experiences that Windows AutoPilot can manage.

  • White glove deployment
  • Kiosk Mode (setup for kiosks or signs, very little user interaction)
  • User driven (small number of steps, in 10 minutes they are done)

The first experience is where the local IT group can make sure that all certificates, applications and changes are installed on the device prior to handing the computer over to the end-user. You can read more about that functionality here.

https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/white-glove

End user driven AutoPilot means the end user simply enters their keyboard settings and location, and then authenticate with their MFA credentials and within minutes are able to use their device.

Lessons learned

  • Moving to modern management with Intune and Azure Active Directory is a process. Start with a small pilot to learn about the issues you may face.
  • Security group management using Azure Active Directory can be challenging. Establish processes for manually managing these groups and account for impact during planning as self service is challenging.
  • Intune Management extensions are only supported on devices that are Azure Active Directory Joined (AADJ) and Intune managed. See https://docs.microsoft.com/en-us/intune/apps/intune-management-extension
  • While co-management is a safety net in between on premise and cloud managed, consider the impact of managing both systems at the same time.

that’s it

cheers !

niall

 

This entry was posted in Intune, Windows AutoPilot. Bookmark the permalink.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.