Consulting can often be an entertaining and mystifying experience. Recently, I was asked an interesting question: “What are the best practices for Windows 11?” So like many people I googled it. We found this gem from Microsoft. It’s a nice start, but it’s basically enroll it in Intune, do Windows Autopatch, and Windows Update for Business. Yeah there are other things, but it doesn’t really get us where we’re trying to go. I started to poll other great MVPs like Adam Gross, Steve Weiner, and others to get their thoughts.
Today, we are starting part one of our 3 part series on best practices for Windows 11. We’re going to cover onboarding, but we will first give you a bit of an introduction to the series overall. We have a small matrix that covers our core concepts. We’re not going to deep dive into many of them, but we will be focusing on scratching the surface. In the coming months, we will be focusing on many of the areas in these articles. A small disclaimer: I am by no means saying you need to implement every one of these items, but I am saying you should look/evaluate them. If they fit your needs, git er dun!
In part one, we cover onboarding. We will cover:
- Enrollment Status Page (ESP)
- Windows Autopilot
- Windows Automatic Device Enrollment
- Debloating and Image Strategy
- Device Join Strategy
- Securing Intune Enrollments with MFA
- The TL:DR
Our overall matrix can be seen below:
| Onboarding | Security | User Experience |
| Windows Autopilot (All of its flavors), Automated Enrollment, Device Management (Intune), Enrollment Status Page (ESP), Debloating/Image Strategy, Entra Join | Windows Autopatch, Microsoft Defender for Endpoint (or other EDR), App Control, BitLocker, Device Compliance, Security Baseline for Windows 10, Edge Baseline, Office 365 Security Baseline, LAPS, EPM, Personal Data Encryption (PDE), Cloud PKI Solution (Cloud PKI or SCEPman), App Patch Management Solution (Patch My PC, Enterprise App Repository, Liquit,etc), Device Control | Windows Hello for Business, OneDrive KFM/other settings, Edge Best Practice Configuration, Intune Management, Digital Employee Experience (EdgeDX), Delivery Optimization, 3rd party ADMX integration and CSPs, User Password Solution via Browser Plugin/Desktop Client (e.g. 1Password, Dashlane, Keeper, etc), SSPR, Office 365 Cloud Policies, Cloud Kerberos Trust for On-Prem Resource Authentication, Universal Print |
Subsequent parts can be found below:
Now, we also have a new article on using passkeys and temporary access passwords for a better out-of-box experience here.
Now, that we covered what the different aspects are to these best practices, let’s start part one: onboarding!
Enrollment Status Page (ESP)
The ESP is the user-facing technology around Windows Autopilot controlling what users actually see/are presented with during the enrollment. The ESP communicates the different aspects of provisioning to ensure people know what is happening and when its happening.
It doesn’t require Windows Autopilot and is an organic part of OOBE (Out of Box Experience) on Windows 10/11. We simply create the ESP profile inside Microsoft Intune to customize exactly what we want people to see. It’s backed by the EnrollmentStatusTracking configuration service provider (CSP) and FirstSyncStatus CSP. Some of those settings are:
- The ability to hide the ESP altogether to users.
- Display an error after provisioning has been ongoing for X minutes.
- Enabling log collection and diagnostic page for users.
- Only show ESP during OOBE.
- Blocking device use until all apps and profiles are installed.
- Allow user to reset device if an error occurs.
- Let the user proceed to use the device if an error occurs.
- Blocking device use until required apps are installed.
- Fail Autopilot if selected blocking apps fail to install.
My strong opinions on leveraging ESP is to show it, block access only for specific important apps e.g. Office 365, your EDR, Adobe, etc., and empower self-service as best you can. People often overthink ESP, which actually hurts your user experience and creates more headaches than its worth. Remember, ESP is a user experience piece of the provisioning process. Make sure it’s actually useful.
The ESP will monitor and communicate the 3 phases of provisioning during OOBE/Autopilot:
- Device preparation (Device ESP)
- Secures your hardware (TPM key attestation and validation with Entra ID and Entra ID sends the Entra ID join token to the device)
- Joins the organization’s network (Entra ID join token is used to do the Entra join)
- MDM enrollment
- Device setup (Device ESP)
- Security policies
- Certificate profiles
- Network connection (includes VPN and Wi-Fi profiles)
- Apps
- Account setup (User ESP)
- User security policies
- User certificate profiles
- User-assigned network connections
- User-assigned apps
Windows Autopilot
Windows Autopilot is a large topic overall. When we consider onboarding of devices, Windows Autopilot is the gold standard. It delivers a great onboarding experience for users and offers many different options based on your needs.
First, we will discuss the 3 phases of provisioning you will encounter in Windows Autopilot:
Let’s discuss the many flavors in Autopilot:
- Windows Autopilot user-driven mode
- Windows Autopilot for pre-provisioned deployment
- Windows Autopilot self-deploying mode
- Windows Autopilot for existing devices
- Windows Autopilot Reset
Windows Autopilot User-Driven Mode
Windows Autopilot user-driven mode is one of the most recognizable options. Basically, it’s where the device is delivered to an end user from OEM, they power it on, and sign in to their Entra account. The device will automatically enroll (we’ll cover how later on). The tasks that can happen with this mode are:
- Entra Join
- Enrollment in Intune (or other MDM)
- App installs
- Applying of device config policies
- Compliance checking
- Enrollment Status Page
In User-Driven Mode, we will see two phases:
- Device ESP: Windows configuration, device-assigned apps and policies are applied.
- User ESP: user-assigned apps and policies are assigned.
In Hybrid-join mode, which is not widely considered to be a best practice we do have a few differences:
- user signs in with AD credentials during the User ESP phase
- On-Prem domain join occurs early in the deployment phase
Check out the Microsoft video on its user experience below, and can also be found here:
Overall, the main reason people shouldn’t use user-driven mode is it is much slower because you have to go through two phases. Our next mode “pre-provisioned mode” is THE best practice for Windows Autopilot.
Windows Autopilot for Pre-Provisioned Deployment
As I just mentioned, this is your best practice for Windows Autopilot. We can automate the device configuration on a device coming from your IT department, OEM, or a reseller. We mentioned earlier that the timing on user-driven mode can take a swhile.
With pre-provisioned deployment, the IT department, OEM, or reseller handles the Device ESP phase, which only makes the user need to deal with the User ESP phase. It’s known as the “technician flow.” We will also see a portion of the Device ESP phase rerun to check for any changes to apps/profiles. Microsoft calls this the “user flow” phase. The main issue you run into is if your OEM/reseller runs into problems with the technician flow, it will need to go to the IT department to be prepped.
Windows Autopilot Self-Deploying Mode
Windows Autopilot self-deploying mode is designed for kiosk and shared device deployments. A few of its characteristics:
- Cannot assign users
- Only supports Entra join
- Very simple and minimal interactions are needed because you don’t assign it to users (just localization and network connection)
Specifically, these are the tasks that will happen:
- Entra join
- Enrolls into Intune
- Device-assigned apps are installed
- Device-assigned policies are installed
- Compliance checks
Once done, you can just sign in with Entra credentials and go!
Windows Autopilot for Existing Devices
When we want to leverage Autopilot for devices that already exist, we have limited options. Autopilot cannot reimage devices, so we get a bit creative. Windows Autopilot leverages Microsoft Configuration Manager (ConfigMgr) task sequences for OS reinstalls or upgrades.
ConfigMgr can even pre-install autopilot profiles via JSON. This automates the importing of the device and assignments usually needed in Intune. The JSON method doesn’t work with self-deployed or pre-provisioning as a FYI. If the device is already in Autopilot, that takes precedence over JSON. Some of the reasons people will use this method are:
- Using stock that wasn’t originally in Autopilot
- Migrating from AD-joined to Entra Join
- Migrating from Hybrid-joined to Entra Join
- Repairing busted devices (BSOD, etc.)
- Custom Windows images
- Windows 8 –> 11 upgrades
Note: Personal device enrollment restrictions will block this method.
Windows Autopilot Reset
Even though it’s not part of best practices etc., I like mentioning Windows Autopilot Reset because it’s a great aspect of Windows Autopilot we should be aware of. We can only do it with Entra Join devices, which is the best practice anyways.
Windows Autopilot Reset will return an autopilot device back to a fresh slate where a new user can login and GO! The device is inaccessible until it has completed that process, which includes a device sync. A fun fact is a hybrid-joined device requires a full device wipe, which includes potentially up to a 24-hour grace period before the device is ready to be used again.
Let’s quickly cover what Windows Autopilot Reset destroys and what it keeps:
| What Autopilot Reset TERMINATES | What Autopilot Reset SAVES |
| The primary user is removed. Personal files, apps, and settings are removed. Device original settings are reapplied. Region, language, and keyboard are reset to their original settings. | Entra Join Intune enrollment Wireless connection details Provisioning packages previously installed Any provisioning packages on a USB prior to the reset Entra device membership Intune enrollment information SCEP certificates |
You do have a few requirements:
- Entra-joined
- Intune-managed
- WinRE (Windows Recovery Environment) is correctly configured and enabled.
- Local reset must be started by a local admin.
- Admin with the Intune Service Administrator role is needed for a remote reset.
You can see how easy it is to initiate the reset from Intune:
Considerations with Windows Autopilot and Device Enrollment Restrictions
Something to consider as some people are now enforcing more restrictive blocks on personal Windows devices in Intune. If you choose to block personal devices, these methods are considered to be corporate device enrollments:
- Device enrolled with a device enrollment manager account.
- Device enrolled through Autopilot
- Autopilot-registered device enrolled through settings if it isn’t MDM enrollment-only
- Bulk provisioning enrollment
- GPO enrollment (device or user context)
Enrollments done through Automatic MDM enrollment with Entra join during OOBE or through the Settings App will get blocked. One other example are “Add Work Account” enrollments or MDM enrollment-only via Settings.
Windows Automatic Device Enrollment
Windows Automatic Device Enrollment is relatively simple, but very powerful. The idea is you go into the mobility section in Entra. Inside there, we have an Intune app, where we can configure automatic device enrollment.
You should in production set a user scope of “All.” Basically, this will map the MDM terms of service URL, discovery URL, and compliance URL to your domain. When a user login in during OOBE with their Entra ID, it automagically pulls these URLs. The URLs will power the Entra join journey to automatically enroll your device in Intune.
It’s important to note that this requires Entra P1/P2 licenses, which most people should have. The typical expectation is most companies will be on Windows Premium or M365 E3 at a minimum (as they’re needed for Intune). Alternatively, you can do it via autodiscovery here, but I am not covering that today.
You might be wondering what these 3 URLs are, so let me tell you:
- MDM terms of use URL: MDM terms of use endpoint. It displays terms of service to users before enrolling their devices. The terms of use text tells you what policies will be enforced.
- MDM discovery URL: The enrollment endpoint used to enroll devices in endpoint management.
- MDM compliance URL: The compliance endpoint of the MDM service. If a user is denied access to a resource because of compliance, it will provide a link to the compliance URL. Users can navigate to this URL to understand why their device is considered non-compliant. It also helps guide the user on how they can remediate the issue themselves to get back into compliance.
Debloating and Imaging Strategy for Devices
An area of some contention today is debloating devices. In a perfect world, we will do something like Lenovo offers today. Otherwise, I’ve been working with a basic debloating script for a while like this you can see below. The overall goal is to evaluate what stuff you don’t actually want and test/iterate to achieve your desired outcome.
In Windows 11, I’ve found you can run into some undesirable outcomes like losing Notepad or other apps that you actually care about. It’s recommended to determine what is actually garbage and act accordingly if this is the strategy you choose to go with:
# Define the whitelist of appx packages to keep installed
$WhiteListedApps = @(
"Microsoft.DesktopAppInstaller",
"Microsoft.Messaging",
"Microsoft.MSPaint",
"Microsoft.Windows.Photos",
"Microsoft.StorePurchaseApp",
"Microsoft.MicrosoftOfficeHub",
"Microsoft.MicrosoftStickyNotes",
"Microsoft.WindowsAlarms",
"Microsoft.WindowsCalculator",
"Microsoft.WindowsCommunicationsApps", # Mail, Calendar etc
"Microsoft.WindowsSoundRecorder",
"Microsoft.WindowsStore",
"DellInc.DellCommandUpdate",
"Microsoft.ScreenSketch",
"Microsoft.HEIFImageExtension",
"Microsoft.VP9VideoExtensions",
"Microsoft.WebMediaExtensions",
"Microsoft.WebpImageExtension",
"Microsoft.WindowsCamera",
"Microsoft.Office.OneNote"
)
# Define the log file path
$LogFilePath = "C:\temp\appremoval.log"
# Function to log messages
function Write-Log {
param([string]$Message)
Add-Content -Path $LogFilePath -Value $Message
}
# Function to remove packages
function Remove-Package {
param([string]$Name, [string]$FullName, [bool]$IsProvisioned)
try {
if ($IsProvisioned) {
Write-Host "Removing AppxProvisioningPackage: $Name"
Remove-AppxProvisionedPackage -PackageName $FullName -Online -ErrorAction Stop
Write-Log "Removed AppxProvisioningPackage: $Name"
} else {
Write-Host "Removing AppxPackage: $Name"
Remove-AppxPackage -Package $FullName -AllUsers -PreserveApplicationData -ErrorAction Stop
Write-Log "Removed AppxPackage: $Name"
}
Write-Host "Removed successfully."
} catch {
Write-Host "Failed to remove ${Name}: $($_)"
Write-Log "Failed to remove ${Name}: $($_)"
}
}
# Remove non-whitelisted AppxPackages
$InstalledPackages = Get-AppxPackage -AllUsers
foreach ($Package in $InstalledPackages) {
if ($Package.Name -notin $WhiteListedApps) {
Remove-Package -Name $Package.Name -FullName $Package.PackageFullName -IsProvisioned $false
} else {
Write-Host "Skipping whitelisted app: $($Package.Name)"
Write-Log "Skipped whitelisted app: $($Package.Name)"
}
}
# Remove non-whitelisted AppxProvisioningPackages
$ProvisionedPackages = Get-AppxProvisionedPackage -Online
foreach ($Package in $ProvisionedPackages) {
if ($Package.DisplayName -notin $WhiteListedApps) {
Remove-Package -Name $Package.DisplayName -FullName $Package.PackageName -IsProvisioned $true
} else {
Write-Host "Skipping whitelisted provisioning app: $($Package.DisplayName)"
Write-Log "Skipped whitelisted provisioning app: $($Package.DisplayName)"
}
}
# Attempt to remove stubborn system apps
$systemApps = @(
"Microsoft.BingWeather",
"Microsoft.GetHelp"
# Add other stubborn system apps here
)
foreach ($app in $systemApps) {
$package = Get-AppxPackage -Name $app -AllUsers
if ($package) {
try {
Remove-AppxPackage -Package $package.PackageFullName -AllUsers
Write-Host "Removed system app: $app"
Write-Log "Removed system app: $app"
} catch {
Write-Host "Failed to remove system app: ${app}: $($_)"
Write-Log "Failed to remove system app: ${app}: $($_)"
}
}
}
Write-Host "App and provisioning package removal process completed."
Write-Log "App and provisioning package removal process completed."The best practice/expectation is that you are using Windows Autopilot and working with your OEMs to deliver a clean image that doesn’t have a ton of the vendor garbage that makes us sad and our PCs even sadder. I’ve worked with Dell and Lenovo and they’re pretty good about giving you a clean image. Ideally, they will also provide a clean image that you can use to flash your existing stock like devices you will prep with SysPrep or ConfigMgr.
Lenovo for example has a few options they provide one with a clean image and one with a custom image where you can request specific apps.
Device Join Strategy
One of the things that has had varying levels of criticism is Microsoft’s hard line against hybrid-joined devices now. The feelings from people are completely understandable. People are comfortable with concepts like vanilla Kerberos, group policies, and the rest of the hybrid party time.
The new and rapidly established best practice is transforming to Entra-joined devices throughout your entire fleet. It’s not an easy thing to achieve overall, but it is a desired outcome. My typical recommendations when you move to Intune is a multi-step approach (which means you would start in Hybrid and eventually get to Entra join):
- Start by enrolling devices and implementing BitLocker, Windows Hello, and Windows Autopatch and let it bake for a while.
- Take your current imaging process and migrate it to the cloud with Intune apps, scripts, etc.
- Start shifting your GPOs to the cloud (I will cover this in later episodes of this series, so I won’t go too deep there).
- Once you have loosened the grip of your domain, you can start evaluating/testing Entra join coupled with technology like Cloud Kerberos Trust to extend the Kerberos capabilities you get with domain join today to Entra-joined devices. (Trying to overall not spoil the other sections).
In general, the device join strategy for any organization isn’t just DO IT NOW!! it’s being pragmatic and understanding the world you actually live in. Once you have a good understanding of how the real world works, you can start building a strategy to move to Entra join. At a minimum, you should be thinking about a PoC as it’s the future.
Securing Intune Enrollments with MFA
One item that is very important is requiring MFA for all Intune enrollments, which I wanted to cover real quick.
We focus on two options:
- Microsoft Intune (MFA is enforced with enrollment and each time they sign into the Company Portal and will also impact the Setup Assistant)
- Microsoft Intune Enrollment (this will only enforce during device enrollment and the first time the Company Portal is launched)
Conceptually it’s easy to enforce:
- We target all users
- We scope it to your app of choice (one of the two options above)
- Leverage “Grant” to require MFA and compliant devices
- Enforce it everytime
This is one of the best ways to keep attackers out of your environment and is an overall best practice.
Let’s Summarize Windows Onboarding Best Practices
All things being equal, my best practices are subjective, and they either will work for you or they won’t (based on your org’s needs). To sum it up, this is what I recommend:
- Implement Automated Enrollment
- Configure ESP so that it actually helps you vs. creating more work and headaches.
- USE AUTOPILOT
- Ideally leverage pre-provisioned autopilot
- If you have kiosks, use self-deploying autopilot.
- Prep your existing stock, but do your research on the JSON security risks/challenges.
- Make your vendors do the heavy lifting.
- Secure enrollments with MFA
- Entra Join is a journey and not a sledge hammer.
- Work smarter not harder.
Overall, don’t let anyone tell you what actually works for you. Let the data set you free and build a strategy that is cohesive with how your organization functions. Some things make sense, but others might not. We’ll talk soon when we start covering some security best practices in Windows 11!
2 thoughts on “Windows 11 Best Practices Part One: Onboarding”
Pingback: Intune Newsletter - 10th May 2024 - Andrew Taylor
Very good article. Looking forward to the next one.