Time for a little up-leveling (especially after the super-long proxy server post).  Based on a recent Twitter conversation, I think it’s worth talking about a couple of higher-level topics.  First, what are the goals for Windows Autopilot.  And then, what high-level scenarios does Windows Autopilot support?  (Yes, the word “scenario” is exceedingly overused, but in this particular context I want to stay at the 1000-foot level, so I’m not talking about feature-level scenarios, just more “what are possible” scenarios.)

What are the goals for Windows Autopilot?

When I originally wrote the initial Windows Autopilot overview page, it was a combination of marketing content (hey, I was in marketing for five years, so give me a break) and feature overview.  But when you boil it down and convert it into casual conversation, I would simplify it some:

• Windows Autopilot eliminates traditional imaging.  Instead of managing images and drivers, you instead use what’s provided by the OEM on the device.
• Windows Autopilot is simple enough to enable end users to deploy the device themselves, without any IT interaction.  The goal is a half-page set of instructions:  Get the device out of the box, plug it in, turn it on, connect it to Wi-Fi, and type in your e-mail address and password, then sit back and wait while the device is provisioned.
• Windows Autopilot ensures devices are ready for productive use at the end of the process.  The main job here is to keep the user from accessing the desktop until it’s reasonably ready – if you try to early and things aren’t yet configured or working, users are frustrated and call the helpdesk, so we want a more controlled experience.  You need to know when the process is done.  But the management tools (Intune, ConfigMgr, etc.) also play into this: each device should be configured appropriately based on the user’s unique requirements, job role, location, etc.
• Windows Autopilot should enable devices to be easily reset (e.g. something is broken and you want to get the device back to a clean state) or repurposed (e.g. you want one user to hand the device off to another user).

Behind the scenes, Windows Autopilot uses a device registration process that links devices to organizations (via links to Azure AD), and a configuration profile mechanism that tells Windows how the device should behave when it starts up.  (For those of you who are familiar with non-Windows platforms, this should sound fairly familiar, as similar concepts exist for iOS, Android, etc.)

But you shouldn’t think of Windows Autopilot as something that requires being “all in” on the cloud.  It certainly requires some level of cloud attachment, but if you goal is to otherwise use Windows exactly the same way you do today (with AD, GPOs, file shares, ConfigMgr, etc.), you can do that.  There are a number of customers that look at this as an opportunity to completely reimagine their entire environment, and a significant number that look at something in between – best of both worlds.

What high-level scenarios are possible?

It’s interesting that many of the requirements we have heard from customers aren’t just small tweaks to their existing processes.  Instead, they are scenarios that are impossible for them to do today.  Imagine some of these:

• “We want to ship devices directly from the OEM (or a reseller/distributors) to our employees – IT should never touch them.”
• “We want to be able to deploy devices from anywhere – employees should not need to come into the office or connect to our corporate network.”
• “We want to be able to reset devices from anywhere – things don’t conveniently go wrong only when devices are on the corporate network.”

And you can probably see how products and features are being created or evolving to support these scenarios – lots of building blocks that, when put together in various combinations, enable new things.  Think about how much harder this would be without Azure Active Directory, OneDrive for Business, Microsoft Intune, Configuration Manager (things like the Cloud Management Gateway/Cloud DP), Office 365, Delivery Optimization, etc.

When it comes to Windows Autopilot, there are a few main pieces that are used (with others that can be added on as appropriate).  So let’s walk through those.

The first scenario that Windows Autopilot supported was Azure AD Join for identity/authentication, and Intune for provisioning and ongoing deployment.  That is a “cloud native” solution; all it needs is an internet connection.  Windows Autopilot performs the initial “bootstrapping” process, joining the device to Azure AD and enrolling in Intune with a very simple process for users.

When it was originally released with Windows 10 1703, there were challenges:  We hadn’t yet added the Enrollment Status Page, which many customers requested (for reasons discussed previously), and Intune didn’t yet have many of the features that it has today, like the ability to install Win32 apps of any kind, run PowerShell scripts, apply Group Policy settings via Administrative Templates, apply security baselines, etc.  So we’ve come a long way since then.

This scenario has some typical use cases:

• Certain populations of users who never come into a corporate office – often information workers performing independent, self-directed roles, or even technicians or drivers.  Really, anyone who would struggle to connect to the corporate network could be a candidate.
• Organizations that want to do a clean start.  After 20+ years, sometimes the only way to get rid of the accumulated layers of complexity is to start from scratch.
• Schools.  They don’t have the manpower to manage on-prem infrastructure and don’t want complexity.
• Startups.  If you started a new company today, you wouldn’t say “let’s set up a bunch of servers.”  Instead, you would pick from available cloud services to provide the capabilities you need.

This is a variation on the previous scenario, adding ConfigMgr into the mix.  Yes, ConfigMgr can manage Azure AD-joined devices, and cooperatively manage devices through co-management with Intune, where you choose which workloads are managed by Intune and which are managed by ConfigMgr.  (See this blog for more around that.)  Intune pushes out the ConfigMgr client (agent), which ideally can leverage a Cloud Management Gateway to support management over the internet.

Why would you want to do this?  Typically, because of the organization’s significant investment in ConfigMgr (it’s been around for 25 years, and has a huge list of features).  Think about how hard that would be to migrate – apps, OS updates, desired configuration, inventory, etc.  So don’t – continue to use it.

Now, I’d like to say that there’s a great level of integration between Windows Autopilot and ConfigMgr.  Since the first days of Windows Autopilot, I’ve dreamed of the ability have Windows Autopilot join the device to AD or AAD, enroll the device in Intune, push the ConfigMgr client, and then run a ConfigMgr task sequence to finish provisioning the device.  We’re not quite there yet, but it is on the roadmap.  It will work, but it requires either some patience (wait for the client to install, report inventory and discovery info, wait for collection updates, poll for new policies, etc.) or some careful configuration and tweaking.  Making it faster and easier is on the roadmap. 

Of course after we released Windows Autopilot with support for Azure AD in Windows 10 1703, the first question was “when will you support Active Directory.”  That support came with Windows 10 1809.  The process is a little different than with Azure AD.  Instead of joining the device to Azure AD which triggers the Intune enrollment, Windows Autopilot actually enrolls the device in Intune first, and then gets Intune to help join the device to Active Directory (leveraging an offline domain join process that has been around for years, and that doesn’t require inherently insecure things like putting usernames and passwords into unattend.xml files – if we built something like that today, it would never be approved for release).

Now while I said “join Active Directory,” you’ll actually see this scenario in the documentation described as “Hybrid Azure AD Join.”  You may have heard me complain about that name (it’s confusing), but here’s a simple explanation:  After the device joins AD, the device object gets synced into AAD (typically using AAD Connect), and once that happens, the Active Directory user is also able to get an Azure AD user token, which has various benefits (e.g. single sign-on).  But most importantly, it allows the user to communicate with Intune.

So what are the typical use cases for this?  Pretty much any not covered in the Azure AD use cases above (although those with ConfigMgr would use the next one).  It’s the de facto mechanism for customers who aren’t looking to make the jump to an Azure AD Join world.  (I would argue that more customers should consider this – mainly as a way to start clean – but the appetite for doing this definitely varies.)

The one missing piece in this scenario:  While we can complete the Active Directory join process over the internet (using ODJ), we can’t yet do the full process over the internet.  We need line of sight to a domain controller for one main reason: The Active Directory user needs to contact a domain controller in order to sign on for the first time.  This is something we’re working on; we should have more to share at Ignite later this year.

Again, this is a variation on the previous scenario, just adding ConfigMgr into the mix.  Intune can install the ConfigMgr agent, putting the device in a co-managed state.  And it has the same ConfigMgr integration challenges, as well as the same over-the-internet AD join restrictions as the previous scenario.  We’re working on those.

And before you ask, yes, you can install the ConfigMgr agent in other ways (startup script, client push, etc.) – just keep in mind that eventually you’ll want this whole process to work from anyway, so it might be better to let Intune do it.

Just a nice, short post…