Taking Control of Your Unmanaged PCs with Intune

IT Epidemic Caused by the Pandemic and Supply Chain Disruption

In March 2020, governments across the world instituted “lockdown” orders in response to the COVID-19 pandemic.  Busy city centers and towns were suddenly emptied, and organizations scrambled to accommodate the new situation: remote work.

During this time, supply chains were disrupted across the industry and around the world. But in IT, one of the hardest-hit areas was laptop distribution, to accommodate this new requirement for users to work from home who under any other circumstances would be using a desktop in the company office.  Disruption increased supply even further as the situation in China escalated with lockdowns, but demand did not slow. Gartner noted recently that the pandemic drove the “highest consumer PC demand in 10 years.”

In a hectic rush to distribute devices out to users, a disturbing trend emerged – that is, PCs being owned by the organization, but not managed by the organization.  There was a real threat of business decline which created a sense of urgency, so there often was no time to properly provision the devices with software, domain membership, and policy. 

For many in IT, the established system for preparing devices had on-premises dependencies, such as line of sight to provisioning servers and domain controllers.  But when you’re not working from the on-premises location, that simply isn’t an option.  Laptops were often drop-shipped directly to users without any prior configuration or control by IT, effectively controlled no more than BYOD devices.  It was like the user had just picked up a brand-new laptop from the store.

To properly secure, trust, and manage such devices, admins must take back control. There are several options available to take unmanaged devices into a managed state. This article will focus on native Microsoft 365 tools, with a bias towards a cloud-first position as the end result, guiding you through various scenarios of existing Windows 10 devices currently used by colleagues whose lives you’d like to avoid disrupting too much. 

First, you’ll learn how to get control of these devices.  Second, we’ll review best practices for what to do long-term with those devices you now manage, so you can prepare for scalable deployments consistent with corporate policy, ideally without on-premises dependencies.

Exploring our Options

For our first scenario which is in-use, unmanaged devices, we begin by getting those back fully under Microsoft 365 cloud-based organizational control. Two methods can be executed by the end user remotely, with no need to centrally retrieve devices and with no dependencies on on-premises infrastructure:

• Intune enrolment from Windows 10 Settings
• Intune enrolment with a provisioning package

It’s recommended to use enrolment from Windows 10 Settings, so provisioning packages are covered in this article at a high level only.  Provisioning packages involve the distribution of executables (something we really want to avoid) and other security concerns.  They are best used only by administrators, whereas Windows 10 Settings are ideal for enrolment driven by the end-user.

An Overview of Device Management in Microsoft 365

Conceptually, Microsoft 365 environments have a device state.  At a high level, this is whether or not the device has manageability by the tenant (organization) whose resources it is trying to access – it is managed, or it is unmanaged.  At a lower level, device state can mean how is it managed, or if it is compliant with the specific controls we mandate.

The traditional tool in a Microsoft ecosystem for managed devices is Active Directory (AD).  When AD is joined, a device can retrieve settings related to security and compliance, software, and feedback information about itself to AD or other management systems.  In large enterprises, Configuration Manager is a prevalent choice for managing devices, and while it can be used to manage devices not on a domain, it is generally associated with domain membership too.

Key to these is their dependence on on-premises infrastructure, or cloud IaaS (Infrastructure as a service).  Even though these approaches are good and well-established, you will still face problems around scaling and logistics when gaining control of devices you do not have physical access to, or that currently have no line of sight to that infrastructure.

Looking for a service that will scale better, cost less, and have more flexibility, we come across Intune.  Intune operates over the public internet, with Microsoft managing the infrastructure so you don’t have to.  When a device is enrolled, it’s considered managed, insofar as administrators can now control device configuration and applications, retrieve inventory information, and specify a level of security posture the device must remain in to be compliant.

As well as enrolling into Intune, the devices should also be Azure AD joined.  Unlike on-premises Active Directory, in which domain membership and the ability to apply settings (Group Policy) are fundamentally linked, Azure AD membership and Intune are fundamentally separate.  They just work well together.

While it is possible to enroll only into Intune, there are numerous reasons to also Azure AD join. Not only is it a prerequisite for any silent BitLocker encryption you want to apply it’s also a prerequisite for the Intune Management Extension (IME), which powers the deployment of Win32 apps and PowerShell scripts. 

While these can also be achieved with hybrid Azure AD join, Azure AD join alone is more viable when your devices do not yet have any management control, and therefore no means of establishing connections to domain controllers.  Intune enrollment occurs automatically at the time of Azure Active Directory join for users with Azure Active Directory Premium P1 and who are scoped to Intune from Azure AD’s mobility settings. 

There is an important point to note for dealing with our existing unmanaged devices going through either enrollment process mentioned above.  Although the device becomes joined to Azure AD, the local account your users have been using until now will still exist and can be used.  The initial benefit to this is that data loss risk is reduced – there’s no having to manage moving apps and documents to a new profile (unless you want to), in which case the user can simply sign in to Windows 10 at the logon page with their Azure AD credentials. 

However, you should be planning to move the user away from the local account as soon as possible, ideally reprovisioning the devices to remove security and compliance concerns such as unmanaged software that may be lingering on the device. We’ll go into that in more detail later in the article.

Enrolment from Windows 10 Settings

This method of self-enrolment sees your users enter their Azure AD credentials into a Windows 10 Settings app menu, and then, BOOM! They are Azure AD joined and managed by Intune.  The specific Settings page can be found in Settings > Accounts > Access work or school:

The user then chooses Connect and Join this device to Azure Active Directory:

Authentication happens with the standard web-based Azure AD modern authentication window, so you can enforce Conditional Access and multi-factor authentication too.  The user is asked to confirm the join, after which, the device is good to go:

At this point, the device is Azure AD joined and Intune enrolled, but there are some important things to consider with this approach. Intune will regard workgroup only devices enrolled with this method as personal devices, and mark them as such under Intune’s ownership attribute. 

Consequently, you must configure Intune’s enrolment restrictions to allow personal Windows 10 devices.  The risk is that users may also enrol PCs you do not want them to enrol, and if assigned policies and apps, you force them onto a device you’d rather not have them on. 

One way to approach this is by creating a second enrolment restriction with a higher priority, only assigned to the users who need to do this:

Enrolment with a Provisioning Package

Provisioning packages are created by administrators using Windows Configuration Designer (WCD), available in the Microsoft Store.  They offer a one-click executable that can do several provisioning tasks.  In our case, we can easily Azure AD join and Intune enrol without having to hop through different settings. 

Additionally, the package is authorized to perform this action with a bulk enrolment token, so the user does not need to authenticate which further speeds up the process.  Intune regards any devices enrolled with provisioning packages as corporate, so you do not need to change your enrolment restrictions if you block personal PCs.  Devices can also be renamed following your naming convention, which is also useful for dynamic group membership.

For the reasons outlined above, there certainly are security risks associated with distributing provisioning packages – essentially, you are enabling users to enrol any device without authentication or vetting.  Therefore, your best option is to use Windows 10 Settings enrolment. 

Summary of non-disruptive approaches for existing devices

For a more comprehensive review of the two approaches, the following matrix explains how they differ in various aspects:

Quick Wins After Enrolment

With both methods, the user remains a local administrator, which we know is not ideal.  With Intune, however, we can fix that.  For Windows 20H2 or later, we can replace local administrators with a list of named users (or SIDs) using the LocalUsersAndGroups setting.  Or, for earlier versions, we can use the ConfigureGroupMembership setting.  The advantage of the first method is we can update it at a later date, rather than replace it. With the latter, a policy is ‘tattooed’ and cannot be changed. 

At the time of an Azure AD join, the local administrators’ group (Administrators) is updated to include the Azure AD roles global administrators, and Azure AD joined device local administrators. Using the policies, we can limit it to only them, removing all other local users. Or, you could combine it with the setting Accounts/Users to create another local admin, though you probably don’t want to do that as it would result in the same password across devices.  Unfortunately, there is not yet a first-party LAPS for Azure AD joined devices.

To further secure and control devices, you should consider deploying BitLocker policies to silently encrypt the device.  As a result of Azure AD joining the devices rather than Intune enrolling them, the recovery key will be stored against the device object in Azure AD.  Additionally, you can leverage Win32 app deployments and PowerShell scripts to roll out your supported endpoint security software, or uninstall applications you explicitly do not want on devices; be they Store or typical Win32 apps.

You’ll also want to set up a Windows Update for Business policy (managed in Intune under the page Windows 10 update rings) to update devices as soon as possible. Because up until this point, we know the device was unmanaged and is probably dangerously out of date.  A second advantage to this is the enablement of more features, such as the LocalUsersAndGroups setting, which will apply when the outdated computers reach Windows 10 version 20H2 or greater.

Keep in mind that all settings and apps must be assigned to Azure AD groups (or all users/devices).  Consider how you’re going to build those groups, ideally based on dynamic queries.

Another benefit of Intune managed devices is the reporting on discovered applications, powered by the Intune Management Extension that’s deployed to them.  This is where you’ll find the discovered applications page on the devices inventories software.  This capability is not perfect, however, and it doesn’t take long to find areas in which it lacks.  Ideally, you want to start fresh, and ensure only the apps you deploy are on there.

Longer-term planning

What you need to start thinking about now is getting these devices into a state where they have no unsupported software, are secured according to your organization’s standards.  Although you can deploy apps and settings by just getting Azure AD joined and Intune enrolled, you must be confident that all inappropriate software is removed, that users are now authenticating with their Azure AD account, and there is no “baggage” leftover from the duration the device went unmanaged.

The above concern leads us to provisioning, or reprovisioning, Windows 10 devices with Autopilot. Autopilot can be described as a bootstrapping solution.  While it does not image a device (it must have Windows 10 Pro/Enterprise already installed) it does initiate the automated provisioning of devices. 

On a first-time boot, the user authenticates against the tenant to which the device is Autopilot registered (more on this shortly,) and the Autopilot applies the automation settings you have specified – domain join type, MDM enrollment, language and region, acceptance of terms and conditions, etc:

Autopilot then passes things off to the MDM solution, Intune, which presents the user with an enrollment status page (ESP), which tracks the progress of deployed apps and settings.  The user is then presented with the desktop, and they can now get to work:

To bring your devices into the Autopilot registered state, they need to have their hardware hash registered against the tenant.  This is a globally unique identifier for the device based on the various serial numbers of its hardware components.  When Windows 10 boots for the very first time in what’s called the out-of-box experience (OOBE), it connects to the cloud, sees if it has an Autopilot profile in a tenant, retrieves it, and is now ready for provisioning. 

The hardware hashes operate best when injected into your tenant directly from the vendor. You purchase devices, they’re registered as Autopilot devices, and then you can distribute them directly to users. 

But what about all the existing devices you have just taken management of, and now have to fully secure and reprovision?  Well, you can generate and upload a CSV of the required information with PowerShell, but that doesn’t scale particularly well.  For Windows 10 PCs enrolled in Intune, you can easily register these as Autopilot devices – a simple check box in the Autopilot deployment profile takes care of that:

For your now-managed existing devices, there are two services you should consider that will make users’ lives easier when you reprovision: Edge sync and OneDrive for Business.  With Chromium-based Edge, you can deploy policies from Intune to synchronize user accounts and data to the cloud, so when the time comes to start on a fresh system, they don’t lose important resources such as bookmarks and history. 

OneDrive for Business offers a similar solution called Known Folder Move (KFM).  KFM, (sometimes called folder backup), synchronizes the Documents, Desktop, and Pictures libraries to the cloud, protecting against data loss.  For more information about configuring this with Intune, you can read about it with Edge sync covered here, and KFM here.

If you wipe a device remotely from Intune (which can even be performed as a bulk operation) or otherwise get it back to the OOBE, you can now really leverage Autopilot.  With a well-implemented Autopilot system, you could be in an excellent place for rapidly deploying new devices or redeploying existing devices, ensuring that your company PCs never find themselves in an unmanaged state again.

For your Intune managed devices, you’ll want to accompany the reprovisioning plan with communication campaigns to your users. You should detail the ‘what,’ ‘why,’ and ‘when,’ and make sure to include the aforementioned sync of Known Folder Move and Edge by having users sign into those services for confirmation.  Once your user’s device returns to the OOBE screen, it will provision in an organizationally appropriate state, and the user can quickly get back into action.

Conclusion

While this article may help you regain control of these devices with Intune, and perhaps you have a better long-term action plan for those devices you’re now managing, you should still think about how you will protect yourself, your users, and the organization against this type of unmanaged situation in the future. Unsettling as the thought may be, there’s no way of knowing if another pandemic-driven state of lockdowns and remote work mandates may happen again.  Therefore, you have a responsibility to ensure that under such circumstances, you’ll be prepared for scalable deployments consistent with corporate policy, delivering new devices straight from the supplier to the user, to keep the business ticking.