If you have been using Microsoft EPM for a while, then spoiler alert: You might also be (unknowingly) affected by this problem.

Locating the problem

I jumped on a users device, where the disk space had mysterially disappeared, and a first glance I couldn’t find out where the disk space had disapeared off to, so I had to fire up treesize to see what was going on.

Looks like the following path was stuffed with MSI Files - More specifically 319GB of MSI Files: C:\Windows\System32\Config\systemprofile\AppData\Local\MDM

After examining a few of the MSI Files, it was clear that it’s an EPM MSI. Examining EPM logs on the device showed that it was stuck in an update loop. It kept failing with error 1603 (Fatal error.) It seems EPM, or more specifically, the CSP/Provider that EPM uses to update the EPM Agent, is not cleaning up after itself. There might also be an underlying issue causing the MSI to fail with 1603, but nevertheless, it should know how to clean up after itself when things go wrong, to avoid this scenario.

I also wanted to check if more users had this problem, so I wrote a remediation / detection script only, to check if that MDM Folder was above 1GB, and if it was, it would return with issue. I also made sure that it would print the total disk space of the folder to the Intune console, to see how bad it really was, and boy it found some really bad ones. In the worst cases there was over 300GB of EPM MSI Files stuck in that folder. Luckily, the issue had only seem to hit a small percentage of their devices so far. But these types of issues can easily snowball very fast, and will impact end-users productivity.

The fix

I’ve already engaged the EPM team at Microsoft, and they are looking into the problem. But while we are waiting for a permanent fix, I’ve written a remediation to clean up the folder. It’s a very simple detection script that simply checks the size of the folder, and if it’s above 1GB in size, it will proceed to remediation, where the remediation script cleans up all the files if the folder.

You can find the scripts here.

You actually also re-use this script and point it to any other folder i.e: temp folders etc. and have them clean it up if it gets above a certain size. In the detection script, adjust the folder variable and also decide how much the threshold (in GB) should be, before it proceeds to clean up the folder. Then in the remediation script, also make sure to adjust that folder accordingly.

The end

I’m sure this bug will be fixed in due time by Microsoft, and luckily it doesn’t seem like the issue is that widespread, otherwise I’m sure a lot more would have come forward by now.

That’s all for now folks. Have an awesome day! :)

After ignoring it long enough, I finally decided to troubleshoot it. Those drivers had to be updated.

So I manually downloaded the installer and launched it… only to be greeted with this:

“This installer is intended to be deployed only on an AMD system. Existing installation as the requirement is not satisfied.”

Unless someone broke into my house and secretly replaced my motherboard and CPU with Intel hardware, something was clearly wrong.

Following the Trail with Process Monitor

I fired up Process Monitor to see what the installer was doing behind the scenes.
Almost immediately, I spotted repeated attempts to launch: C:\Windows\SYSWOW64\cscript.exe

This can only mean 1 thing: VBScript.

The Root Cause

Three months ago, I had removed VBScript support from my device.
At the time, it seemed harmless—another legacy component retired.

It turns out AMD’s chipset installer still uses VBScript-based requirement checks.
With VBScript removed, those checks fail silently, and the installer incorrectly assumes the system is not an AMD platform.

In short: No VBScript → broken detection logic → false hardware error.

Why This Is a Bigger Problem

VBScript is living on borrowed time.

Microsoft has officially announced that:

• VBScript will be deprecated in 2027 - FoD will be disabled by default
• It will later be fully removed from Windows

That means every installer, automation script, and macro that still depends on it, is a future outage waiting to happen.

If you believe no one in your organization relies on VBScript anymore, I dare you to try running this on a test device:

DISM /Online /Remove-Capability /CapabilityName:VBSCRIPT~~~~

1 thing is almost certain: Decades worth of Excel macros will break, and will need to be re-written in Javascript, PowerShell or another language. But if you haven’t started already, it’s time to start communicating widely to your organization that this change is happening, so everyone can prepare accordingly.

The Takeaway

VBScript was released almost 30 years ago. Yet in 2026, it’s still being utilized by application packagers, drivers, excel macros etc.

If your packaging, deployment, or automation workflows still depend on VBScript, now is the time to audit and modernize them—before the platform removes it for you.

See this article from Microsoft regarding VBScript deprecation timelines and next steps: https://techcommunity.microsoft.com/blog/windows-itpro-blog/vbscript-deprecation-timelines-and-next-steps/4148301

I’ve previously done this for customers to patch stubborn devices—for example, when Windows Update is broken or misbehaving. In those scenarios, having a Windows update available through Company Portal can be very useful for troubleshooting purposes.

In this case, however, this blog post was prompted by the January 2026-01 Out-of-Band (OOB) patch released for Windows 11 by Microsoft. Microsoft decided not to release this update through the normal Windows Update channels, meaning it is not offered via Windows Update for Business (WUfB). This OOB patch contains fixes that may significantly impact users—or even you as an IT admin.

Update 24th of January 2026: The OOB Patch has now been added so you can expedite it via Intune - No reasons to manually package it, but at least now you know how to manually add a patch to company portal :)

What’s in the January 2026-01 OOB patch?

For Windows 11 23H2, the January 2026-01 OOB patch
(KB5077797)
contains the following fixes:

1. [Remote Desktop] Fixed:
   Some users experienced sign-in failures during Remote Desktop connections. This issue affected authentication steps for different Remote Desktop applications on Windows, such as the Windows App.

2. [Power & Battery] Fixed:
   Some devices with Secure Launch enabled restarted instead of shutting down or entering hibernation.

For Windows 11 24H2 and 25H2, only the Remote Desktop issue appears to be relevant; the shutdown issue does not apply. If your users suddenly experience generic authentication errors when connecting to AVD or Windows 365, there’s a good chance this January 2026-01 update is the cause.

How do we offer this patch via Intune?

Short answer: not via WUfB.
We need to package and deploy it manually 🙂

This is because Microsoft did not release it via WufB, only via Microsoft Update catalog.

Packaging and offering the update in Company Portal

It is technically possible to wrap updates for Windows 11 23H2, 24H2, and 25H2 into a single package. However, I don’t recommend this due to the size of the updates.

Instead, we’ll create one Win32 app per Windows 11 version, where applicable. We’ll use requirement rules to ensure the update is only offered to relevant devices. Using a Win32 app also ensures we can take advantage of
Delivery Optimization, provided it’s setup and correctly configured of course.

In the example below, we’ll download the update for Windows 11 23H2, create a PowerShell script to install it, package it, and make it available in Company Portal for our end-users.

Step-by-step

1. Go to the Microsoft Update Catalog and search for the KB number of the patch you want.

2. Click Download and download all relevant files for the update. In the below example we are going with the January 2026-01 OOB Patch for Windows 11 23H2 x64

   

3. Create a PowerShell script to install the update and add the following line (Remember to adjust the name of the .msu file):

   Add-WindowsPackage -Online -PackagePath "$PsScriptRoot\windows11.0-kb5077797-x64_af2b9a9ab390d2081e3e4eb52a2f8b81b5be1d7f.msu"
   

4. Wrap the files using the
   Intune Content Prep Tool
   and generate an .intunewin file.

5. Upload the .intunewin file to Intune as a Win32 app and give it a clear, descriptive name.
   In this example, we’re offering the Windows 11 23H2 January 2026-01 OOB update to Windows 11 23H2 devices.

Win32 app configuration

Install and uninstall command

Install command

PowerShell.exe -ExecutionPolicy Bypass -NoProfile -File Install-WindowsUpdate-23H2_2026-01-OOB.ps1

Uninstall command

dism /online /remove-package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~22631.6494.1.2

It’s otherwise always nice with a logo :) You can find a nice Microsoft logo or you can use the one I’ve stored here

Note:
To find the correct uninstall package name for a specific update, use the following PowerShell command to list installed updates:

Get-WindowsPackage -Online | Where {$_.PackageName -like '*RollupFix*'}

Requirement rule

Use a registry requirement rule to ensure the app is only offered to relevant devices. You can also optionally add a disk space check (2000mb) before offering the update. This will make it easier for debugging purposes, in case of disk space issues, as it will clearly be listed in the intune portal if the disk space check has not passed.

Rule configuration:

• Key path:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
• Value name:
  CurrentBuild
• Requirement type:
  String comparison
• Operator:
  Equals
• Value:
  22631

Notes:

• Windows 11 24H2 → 26100
• Windows 11 25H2 → 26200

Detection rule

Use a registry detection rule to confirm the update is installed.

Rule configuration:

• Key path:
  HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion
• Value name:
  UBR
• Detection method:
  Integer comparison
• Operator:
  Greater than or equal to
• Value:
  6494

Notes:

• Windows 11 24H2 and 25H2 → use value 7627

Reboot behavior

Make sure to carefully configure and observe the reboot behavior.

If you want to nudge users to reboot after installing the update, enable the following option on the Win32 app:

• “Intune will force a mandatory reboot”

Enabling this option unlocks the Restart Grace Period settings on your app assignments. This allows you to notify users and give them multiple reminders before the reboot is enforced.

Important:
Always enable the Restart Grace Period when using
“Intune will force a mandatory reboot”.

If the grace period is not configured, installing the update will result in an immediate and abrupt reboot, which is a very poor user experience.

User Experience

The user can enter company portal and install the app. After installing the app, they will be prompted to reboot, as shown below:

Wrapping up

It’s far from ideal to have to offer updates this way, but I’ve received a large number of questions and concerns from customers regarding this January 2026 update. That’s why I felt compelled to write this post and demonstrate a practical approach for manually packaging and offering the update to end users.

By using a Win32 app and making it available in Company Portal, you can treat this update as a fix-on-failure—guiding users to install it only when needed. Of course, you can also push it proactively to all users if many are affected, but in that case, I strongly recommend increasing the restart grace period so users have more than 24 hours to complete the mandatory reboot.

That’s all for now.
Have a great day ahead 🙂

Updates during ESP

Windows Updates during ESP is making a comeback (for the 3rd time), let’s hope this time it goes well, as Microsoft previous attempts of rolling it out hasn’t gone according to plan. The option to disable it in ESP has already been there for a while, but the button hasn’t really done anything as the feature was rolled back.

If you don’t want any updates during ESP, be sure to set this option to “No” in your ESP. Otherwise this functionality will be re-implemented in the January 2026 as pr. comms from Microsoft. Carefully consider the impact of using this feature, as it will most likely significantly increase the enrollment time of your windows devices.

More about this in this blog post from Microsoft

Gradual rollout functionality is back

The gradual rollout functionality was deprecated in October 2025, much to the dismay of a lot of IT Admins. The Gradual rollout functionality was great in many ways, as it allowed the update engine in Intune to carve out smaller groups of devices and offer feature updates in small chunks rather than offering it at the same time to all devices in a group. This allowed IT Admins more leeway in regards to testing and gauging impact of the rollout of a new feature update.

But Microsoft must have received a lot of pushback when they removed this feature, because they have decided to re-implement it. It’s already available today. I wasn’t even aware before a few of my customers reached out to me and asked about it. Looking at “What’s new” pages, it looks like it was just silently re-implemented. I would love to link to a blog post from Microsoft, but as of this date, also after confirming with a few folks from Microsoft, it seems to have been silently implemented again. I’m sure some comms will be sent out soon.

That’s all for now.

Happy new years to everyone :)

UPDATED 25th of February 2026: Microsoft hosted 2 AMA’s that gave us a lot more information about how all of this is going to work. You can find the link for for the December 2025 here and the February 2026 one here

If you manage Windows devices, you might have noticed some alerts about Secure Boot certificates expiring in 2026. This is a common concern, but there’s no need to panic. I’ve noticed some conflicting information about to manage this issue, hence this blog post to clear things up.

What you need to know

• The existing 2011-era certificates (KEK CA 2011, UEFI CA 2011, and Production PCA 2011) are expiring in mid‑2026, which would disrupt Secure Boot security.
• Failing to update the boot certificates could result in the following implications:

1. Lose the ability to install Secure Boot security updates after June 2026.
2. Not trust third-party software signed with new certificates after June 2026.
3. Not receive security fixes for Windows Boot Manager by October 2026.

Source

Deploying the updated Secure Boot certificates

You have several options for deploying the secure boot certificates. The most interesting options are the following:

Option 1 - Automatic rollout via High-confidence buckets

This is the most hands-off approach, but it also requires a bit of faith that your device has been placed into one of Microsoft’s “high-confidence buckets.” If it hasn’t, the device won’t automatically receive the updated Secure Boot certificates. But otherwise note that this option is turned on by default, and is one you have to opt-out of, if you don’t want to be part of the automatic rollout.

Microsoft describes this process as follows:

“Microsoft may automatically include high-confidence device groups in monthly updates based on diagnostic data shared to date, to benefit systems and organizations that cannot share diagnostic data. This step does not require diagnostic data to be enabled.” (Source)

Microsoft hosted an AMA the 10th of December 2025 where they clarified the following:

“A high-confidence device refers to one that Microsoft can reliably identify and update automatically through Windows Update without additional intervention. These devices typically meet criteria such as: Trusted diagnostic data signals confirming the device’s identity and compatibility, Secure Boot enabled and using supported UEFI firmware, Running a supported Windows version that can receive updates and No anomalies in the boot chain or firmware keys that could block the update process.”

There should be no harm in letting Microsoft update devices via this channel, but if you want to opt-out of this option for whatever reason, you can set a policy to opt out using Intune.

Option 2 - Automatic rollout via Microsoft Controlled Feature Rollout (CFR)

By deploying this policy you will participate in a Microsoft-managed rollout also known as Controlled-feature rollout (CFR). This rollout will be fully controlled by Microsoft, and usually CFRs involves a careful and staggered rollout approach based on certain criteria, grouping devices by hardware and firmware, monitoring feedback channels, and pausing if issues appear. In other words: With this option you are also completely in the hands of Microsoft with this one, but it differentiates slightly from the High-Confidence option. Expect the CFR-rollout option to be slower.

For this option to work you need to ensure you are sending required or optional diagnostic data to Microsoft. If you are already using WufB or Autopatch you probably already are doing it, but know that in March 2025 Autopatch revoked the policy they deploy by default to do this on your behalf (Ref: MC996580). If you want to be sure, you can craft your own policy and apply to devices in scope. Look for the “Allow Telemetry” setting in the settings catalog. Source

If you want to let Microsoft managed the rollout via the CFR process, search for “Secure Boot” in the settings catalog to find the relevant policies.

Option 3 - Self-managed rollout using Intune policies

If you want to manage the rollout of the secure boot certificates yourself, search for “Secure Boot” in the settings catalog to find the relevant policies.

This option can be highly desirable if you want to be in complete control yourself, as this allows you to roll this policy out in your own rings/waves. This option also doesn’t require for you to send diagnostic data to Microsoft.

NOTE: There is a known issue where this policy can fail with an error code 65000 - It is due to be fixed by February 27 2026 (Source). In the meantime, you can apply the corresponding registry key instead, using a PowerShell script. You can download it from my github here

Monitoring for updated certificates

Microsoft released a new report in Intune to monitor for the updated certificates. You can find it by navigating to the following blade: Reports > Windows Quality Updates > Reports > Secure Boot Status

Wrapping up

Microsoft is already working with OEM’s to push out BIOS Updates, where the updated certificates are present. So if you are already keeping your BIOS Up-to-date in your org, chances are, you already received the updated certificates. You can find articles from Dell and HP about how they are adressing things from their end. They are already updating the certificates from their end via BIOS Updates on newer models.

If your devices are in an air-gapped environment or with limited network connectivity, you will have to update these certificates manually. See this article for more information.

The full Microsoft guidance is available in this article

Plenty of scripts online suggest you need to handle this certificate update yourself. For most organizations, that’s not the case. Microsoft will take care of it or you can choose to take matters into your own hands with new easy-to-deploy intune policies. If you’re running hardware from major OEMs like Dell, HP, or Lenovo and keeping them updated, you’re likely already covered to a certain extent. Also, this is issue is also present on servers, so make sure to prepare accordingly for your servers as well.

Hopefully this clears up the confusion and saves you from chasing unnecessary “DIY fixes.”.

Thanks for reading — and have an awesome day :)

I helped configure Intel AMT in a retail environment some years back, but that was before any cloud functionality existed, so we maintained an Excel sheet with the IPs, users, and passwords for each workstation. That was fun (not really…). Over the years, the tools to configure Intel AMT have had many names and variations: Intel ACU, Intel SCS, and Intel EMA. Don’t be surprised if you hear about those. Many companies already purchase vPro-capable devices, but they’re not using the functionality. Some might also have a split estate where some devices are vPro-capable and others are not.

But let’s pause for a second and look at what Intel vPro and Intel AMT actually are:

• A business-centric PC platform providing enhanced hardware-based security, remote manageability, and business-grade performance.
• Remote Management (Intel® AMT): Allows IT staff to remotely monitor, diagnose, and resolve issues on computers—regardless of their location or whether the operating system is running. For the server people out there, think of this like a miniature version of HPE iLO or Dell iDRAC.
• Hardware-Enhanced Security: Provides multilayered security features built into the hardware to protect against malware, safeguard user credentials, and secure data—even at the firmware level.

In other words: if organizations had these capabilities when the CrowdStrike debacle ensued, they would have been much better off recovering their devices remotely.

I exchanged a few emails and calls with the good folks at Intel supporting this new Intel vPro portal. They helped me set up my tenant and troubleshoot a few issues I encountered.
Let’s take a look at how to configure Intel AMT with these new tools from Microsoft and Intel, while also gaining some insight into the direction this product is heading in the near future.

Configuring Intel vPro with Intune integration

Microsoft recently announced Intel vPro Portal integration in Intune. Released on September 15, 2025, for Intune service release 2509, this feature allows you to integrate your Intune tenant with the Intel vPro portal.

This automatically provisions your Intel vPro tenant as well.

Some quick gotchas regarding the Intel vPro portal:

1. Save your passphrase. The passphrase adds an extra layer of security to your user account and should not be confused with your login password. I highly recommend ticking the box “Store passphrase in browser” when signing in to avoid retyping it repeatedly.
2. By signing up for Entra ID integration, you eliminate the need to use passwords when signing in to the portal. Users you onboard to the Intel vPro portal should only use their passphrase. In the future, we’ll also get the option to completely disable passphrases.
3. If you want to provide access to someone else, you can manually create their user account in the vPro portal under User Management. In the future, we’ll get an option that allows automatic user provisioning in the Intel vPro portal based on Entra ID groups.
4. Currently, it’s only possible to provision devices in what’s referred to as Client Control Mode (CCM). If you want to remotely take over a device via the portal, the end user will need to provide a code to the IT Admin—similar to Quick Assist or Remote Help. However, in the near future, we’ll get the option to provision devices in Admin Control Mode (ACM) with this new portal. This mode is ideal for factory areas, retail spaces, or kiosk environments where unattended access is required, as the device has no user. Devices in ACM allow IT to take control without requiring user consent.

NOTE: If you’ve signed up for Entra ID integration, make sure the “Email” attribute is populated for the users you’re trying to onboard. Otherwise, SSO will not work, and you’ll see an error message in the Intel vPro portal when signing in. Intel is working on migrating to using the UPN instead of the Email attribute, as it’s common for admin accounts to have a blank email field in Entra.

Onboarding devices to vPro

Onboarding devices to Intel vPro is super simple in the new setup flow:

1. Configure an endpoint group or use the default endpoint group—each endpoint group requires its own onboarding package/application.
2. On the right-hand side, open the dropdown menu under Actions and select Download agent files.

1. Download both files and create an Intune package using the Intune Content Prep Tool. Do not rename the files, and keep both files in the same folder when creating the .intunewin file.
2. Finally, upload the app to Intune as a Win32 app. The default install/uninstall commands are prepopulated, and you can use the default MSI detection method as well.

I created a PowerShell script based on some Intel-sample scripts, you can use as a custom requirement script, that ensures only targeting Intel vPro-capable devices. This will prevent devices that are not vPro capable to be onboarded in the Intel vPro portal. You can download the script from my github here. When you create the Win32 app, under the requirement section, you can add a script requirement.

Output data type: Integer - Operator: Equals - Value: 1

Once the package is ready, you can start rolling it out to your vPro-ready devices. As always, test on a few devices first before rolling it out broadly. Also consider how you group your devices into Endpoint Groups. Endpoint Groups are important if you want to limit who can perform remote actions and take control of devices—assigning specific endpoint groups to specific IT admins.

Once the package is installed, the device will automatically onboard itself into the Intel vPro portal.

If everything works correctly, you will now be able to remotely power on, powercycle and remotely access the device amongst other things.

Onboarding and troubleshooting tips

There can be various causes to lack of connectivity to Cira, so here is a few tips/tricks to make sure the device will always be able to connect:

1. Ensure BIOS and Intel Management Engine drivers are fully up to date. If you’re running a very old version, it’s likely vulnerable and may not work correctly. Always stay up to date with drivers and BIOS updates from your OEM.
2. Make sure your device is vPro-capable. It’s possible to onboard devices that aren’t vPro-capable, but they’ll never connect. The Intel Management and Security app in Windows will also look empty, since either vPro is not supported or Intel MEBx is disabled in BIOS.
3. Ensure the device is connected via Ethernet or Wi-Fi. However, be aware that 802.1x connections (certificate-based authentication) are currently not supported. Support for this will be added later.
4. If your device is hibernating or gone to sleep, it’s likely you will not be able to connect to the device remotely or perform any power actions. This is partially due to the fact that we want to prevent powering on devices that is in a bag, to prevent overheating. If you are managing a factory floor or kiosk devices, I recommend disabling sleep to retain connectivity towards AMT.
5. If your device isn’t connecting, check the following:
   • Verify Intel MEBx is enabled in the BIOS. If you’ve previously modified it, you might need to unprovision it. Most OEMs ship devices in an unprovisioned state, allowing them to seamlessly onboard once the package is deployed.
   • Open the Intel Management and Security app on the device and check the status. It should look similar to the examples below if everything is working as expected.

In the vPro portal, it should show “Cira Connected” and “Power On” with green indicators once it’s onboarded, as shown below:

Final words

Intel AMT has historically been a pain to configure, manage, and maintain—but with this new portal and the integration with Intune and Entra, things are really starting to look good. Intel AMT and the remote capabilities it provides can be a huge help in scenarios where the OS isn’t booting, allowing IT to take control remotely of the device even when it’s offline. The unattended access feature will also be a great alternative to TeamViewer or other remote support tools once it’s released.

If you are already using Intel EMA, you will find that this new portal is missing a lot of features. Intel EMA is a self-hosted appliance in Azure that’s been around for a few years, but I can only surmise that due to complexity and low adoption rates, Intel is pivoting towards this new cloud portal to make adoption and onboarding a breeze for IT Admins. So think of this new Intel vPro portal as version 1.0, with many more things to come.

With this new portal and integration, we now have a streamlined and simple approach to onboarding and configuring devices for Intel vPro and AMT—which is awesome!

There are plenty of articles that explain what TAP is and its use cases. Here are the official docs from Microsoft.

You’ll also find many blog posts about TAP. Some are great, while others lack detail or contain outdated information. TAP and Autopilot enrollments has evolved in the past year, which is why I wanted to share an updated perspective. I’ve also spoken with Microsoft internally about the current user experience.

So what’s the fuss about?

Autopilot enrollment and (un)expected reboots

This has been known in the community for years, but here’s a quick recap:

• During Autopilot enrollment, if a reboot occurs, the cached user token is lost. This forces the user to sign in again, often with additional MFA prompts/Sign-in, before they can set up Windows Hello for Business (WHfB).
• Common policies that cause reboots include Windows Update, Security Baseline, Device Control policies, and AppLocker. Rudy Ooms has a great post explaining how to pinpoint which policies triggered a reboot—read it here. Alternatively you can also check out these docs from Microsoft
• A known workaround is assigning reboot-causing apps or policies to user groups instead of device groups. For apps, you can also disable mandatory reboots.

This helps, but avoiding reboots entirely has side effects:

1. Device Health Attestation (DHA): Requires a reboot to check compliance items like BitLocker, Secure Boot, and Code Integrity. Without it, the device shows as non-compliant.
   
2. Security features: Device Guard and Virtualization-Based Security (VBS) need a reboot to activate. These are included by default in the Security Baseline.
3. User-based targeting: Assigning to users instead of devices can cause apps and policies to follow users onto shared or secondary devices, which isn’t always desirable.

Enrolling an Autopilot device with TAP – with reboots

Here’s where things get messy. If a TAP is used and the Autopilot process includes reboots, some odd behavior appears.

The flow looks like this:
A) User starts Autopilot enrollment with TAP
B) Device reboots in the device setup phase

C) After reboot, the login screen shows “Other user” with a “Sign in” button. The user must press the button twice before the TAP prompt (web sign-in) appears. Alternatively, they can use Sign-in options → globe.

Some blogs and videos show this as normal. But it’s not—it’s poor user experience. This should be treated as a bug. Let’s call it Problem #1.

D) After enrollment finishes, the user sets up Windows Hello. Problem solved? Not really. But the user is now on the desktop.
E) When the device is locked, after the user is on the desktop, the same issue from step C reappears. Also, Clicking the PIN button as a sign in option for some reason shows “Username” and “PIN”.

The user can unlock the device either by using TAP again or by entering UPN + PIN from Windows Hello enrollment. This is Problem #2.

I raised this with someone at Microsoft. They were aware of the workaround (assigning reboot-causing apps/policies to users), but advised against relying on it since reboots can never be fully eliminated. Future platform changes could introduce new reboots at any point.

What surprised me was their explanation of Problem #2: The user actually didn’t sign in with windows hello, even when it’s configured in this scenario, so it is not active, which explains the odd sign-in screen after device has been locked.

Other experts I’ve communicated with, otherwise often deal with this by targeting reboot-causing apps/policies to users. For DHA compliance, they add a grace period and schedule a forced reboot later.

Alternative workaround: To ESP or not to ESP

One customer I work with is reluctant to change their targeting strategy in Intune. They want to keep all core policies and core apps assigned to devices. They’ve also logged a support ticket with Microsoft, but as I told them, this may take months—and Microsoft may not even classify it as a bug.

So is there another short-term option/workaround?

Turn off the ESP.

This feels counterintuitive. The Enrollment Status Page (ESP) is designed to make sure all core policies and core apps are in place before the user reaches the desktop. But if you disable ESP, here’s what happens:
a) User signs in with TAP

b) Within 30–60 seconds, they’re taken to WHfB enrollment

c) After WHfB enrollment, they land directly on the desktop—without Problems #1 and #2.

From the user’s perspective, this is fantastic. They can start working almost immediately.

From IT and Security’s perspective, not so much—because no apps or policies are present once the user hits the desktop

Applications: Critical apps can be installed via PowerShell (Intune platform scripts). These run before Win32 or LoB apps. It’s not elegant, but it works reliably.

Policies: In testing, most policies applied within 1–2 minutes after hitting the desktop. The only major issue is users who open Edge too soon will get extra sign-in prompts, while certificates and WiFi Profiles will also be slightly delayed.

Compliance and security: For DHA checks like BitLocker, you’ll need a reboot later. To force a reboot at some point, we have several options, which includes:
a) Marking an app in Intune with “Intune will force a mandatory reboot.” Just remember to configure the restart grace period so users get a warning instead of an abrupt restart.

b) An alternative option is to use a PowerShell script (run as current user) that prompts the user to reboot within X amount of minutes. If they click “No,” the final reboot won’t run. This is just a PoC, to provide some inspiration. You can find it here here.

Can be assigned as a platform script in current-user context like so:

It should look like this for the end user:

Of course I’m otherwise sure the community can find more creative ways to nudge the user to perform a reboot

Final words

Reboots during Autopilot have always been a pain point, but we’ve learned to work around them—either by assigning policies/apps to users or by documenting the behavior in onboarding guides so users aren’t confused by extra sign-ins.

The bigger issue today is how TAP + Web Sign-in behaves during an autopilot enrollment with reboots. That flow really needs attention.

Disabling ESP is a drastic workaround and won’t suit everyone—for example, if you use third-party AV or have many app dependencies. I usually recommend keeping ESP as light as possible, but sometimes you can’t avoid adding a few apps in the ESP due to requirements from the business.

I hope this helped. Have an awesome day :)

Editor’s note 9.8.2025:
This capability has been delayed by a couple of months to help ensure delivery of the best possible experience. You can start configuring the new setting on the Enrollment Status Page (ESP), but you won’t see the new user interface yet. We’ll update this post with a revised timeline as soon as it’s available.

Source

In the Intune service release for August 2025, we’re getting some great new additions, which you can read about here.

The big change in this update is the return of Windows quality updates (not feature updates!) during Autopilot enrollment—and they will be enabled by default. You can read the full announcement here. Some of you might remember the previous attempt to roll this out didn’t go so well, as it was enabled by default without an option to turn it off. This time, we finally have the ability to disable it if needed.

It all sounds great—updates during ESP. We all want our devices to be updated, right? Well, not always. It depends. The main problem with Windows updates being delivered during Autopilot enrollment has always been the extended enrollment time. Depending on the device’s patch level, and the network speed, you might add another 20–30 minutes to the process, which can be significant if you already have several apps blocking your ESP.

Be sure to consider the impact before enabling this feature, and test it first on a few devices to gauge the average increase in enrollment time.

Disabling Updates in the ESP

If you don’t want this feature, you’ll need to go to your ESP (Enrollment Status Page) settings and disable it. By default, it will be turned on.

Note: If you don’t see this option in your ESP settings yet, it’s because the feature is still rolling out globally.

Final Thoughts

A great addition in the future would be a conditional rule that allows IT admins to enable updates during ESP only if the OS patch level is below a certain build number. The current alternative is to use enrollment restrictions, which block devices from enrolling when they’re below a required patch level. However, this forces the user (or IT) to manually update the device—usually by pressing Shift+F10 → control update or similar—before it can be enrolled. Not exactly the best user experience.

For now, though, this is still a very welcome change that has been highly requested for a long time. It’s nice to see it finally here. 🙂

If you suddenly face an issue where your users are complaining they cannot launch Teams or the new outlook client because of a Webview2 error, right after a finished autopilot enrollment, then read on.

What is WebView2

WebView2 is a web control from Microsoft that lets developers embed web content (HTML, CSS, JavaScript) into their desktop applications. It’s built on the same Microsoft Edge (Chromium) rendering engine, so apps can display modern web experiences without relying on the old Internet Explorer–based WebBrowser control. WebView2 is installed and updated with Microsoft Edge.

The new outlook and teams clients relies on this component to work correctly. What if webview is missing or outdated? Then you will probably face the below error (There are a few variations of this error, but this is one of them)

Why is it happening

I’m working with 1 customer where they get devices delivered from the OEM with an ancient Edge version, causing this problem. Microsoft says it’s an OEM issue and the OEM says it’s a Microsoft issue. In the meantime, if you download a Windows 11 24H2 ISO, we can mount the ISO and open the install.wim with 7zip we can take a peak at the Edge version by navigating to ..\1\Program Files (x86)\Microsoft\Edge\Application: 122.0.2365.106

For good measure, I also fired up a VM and installed Windows to check the Edge version, using the same ISO and the version is the same.

If we look up the date of Edge version 122.0.2365.106 it’s basically from the stoneage: Version 122.0.2365.106: March 21, 2024 (Source)

And that’s the cause of our issue, the Edge version is simply too old and WebView2 is built-in to Edge. So preferably we need to get it updated before the user lands on the desktop and opens teams or outlook. Based on some testing, Edge should otherwise update itself within 30 minutes after hitting the desktop, but the users that launch teams or new outlook before that, will face the error.

NOTE: On further inspection, I found that the Edge version has actually been updated to a much newer version in the latest ISO available from July 2025 (as of this date), and in that ISO, is actually a newer Edge version. But it will probably take a while for OEMs to update to this version

The workaround

We can trigger an Edge update by using the following PowerShell command (source):

Start-Process -FilePath "C:\Program Files (x86)\Microsoft\EdgeUpdate\MicrosoftEdgeUpdate.exe" -argumentlist "/silent /install appguid={56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}&appname=Microsoft%20Edge&needsadmin=True"

We have a couple of options for deploying this with Intune, but I have found the easiest and fastest way is to deploy it as a PowerShell script from Intune (Platform script). PowerShell scripts run before Win32 apps during the autopilot enrollment process. I created a PowerShell script to check for the Edge version and it’s below a certain version, we will update it, otherwise no actions is performed. You can find the script in my github here. Assign it like so:

Final thoughts

Hopefully this issue should go away very soon as it seems like Microsoft already released new ISOs where a much newer version of Edge is included, so I guess it’s just a matter of time. In the meantime, we just need to make sure Edge is updated before the user hits the desktop. You can deploy it as a PowerShell script or Win32 app. Alternatively if you use products like Patch My PC or Robopack you can subsribe to Edge and get it as a Win32 app as well.

That’s all for now. Have a nice day :)

Quick Machine Recovery (QMR)

Quick Machine Recovery (QMR) aims to reduce downtime when devices encounter critical issues. Instead of lengthy reimaging or rebuild processes, QMR allows devices to quickly recover to a clean and ready state — often within minutes. This is especially valuable for IT teams managing large device fleets or remote workers. What’s even cooler is that Microsoft is looking to build automatic remediation for common OS Boot failures, that makes it easy to guide end-users to fix common issues that could cause a No boot scenario. It’s still in preview, but this technology looks very promising.

Did someone say Crowdstrike? Also, a lot of companies are paying extra for Intel vPro devices, but very few is actually taking advantage of Intel AMT - why is that? Probably best left for a different blog post.

Rest assured, I think it’s great and sorely needed that Microsoft is entering this space.

👉 Learn more about Quick Machine Recovery

Local Administrator Protection

Local administrator accounts have long been a target for attackers. Local Administrator Protection introduces built-in controls that help safeguard these accounts, reducing the risk of privilege escalation and lateral movement during attacks. This feature integrates with existing identity and access management strategies to provide a stronger security posture.

👉 See how Microsoft is protecting local admin accounts

A New PC Migration Experience

Migrating to a new Windows 11 device is about to become far simpler. The New PC Migration experience helps users transfer settings, apps, and data with minimal friction, reducing the setup time and confusion that often comes with getting a new PC. This feature will integrate with Microsoft cloud services to offer a seamless handoff between old and new devices.

👉 Explore Microsoft’s vision for easier PC migrations

Smarter Start Menu Pins with PinGeneration="1"

Windows 11 is introducing a one-time pinned apps experience for the Start menu. With PinGeneration="1" you will be able to make pinned apps, unpinnable by the end-user, allowing the user to freely customize their own taskbar, even though IT deployed a taskbar policy. For those of you that has been in the game for a while, you probably also remember the plethora of tools that could pin apps to the taskbar, but that suddenly stopped working after a windows udpate. Gone are the days where we need to rely on PowerShell wizardry to apply a one-time configuration to the taskbar.

👉 More details about that here

New Copilot + Search Enhancements

Microsoft is re-inventing the Copilot experience in Windows 11, making it even more powerful by integrating it deeper into the Search functionality. This means faster, smarter results — whether you’re querying your PC, files, settings, or the web. Copilot is becoming a true AI assistant that helps you get things done more intuitively. Of course they have also increased the security of Windows Recall that made its rounds through the media some time ago. For starters, it’s now no longer enabled by default, and the Recall bits are protected by Windows Hello and is now encrypted.

👉 Meet Windows Copilot

Honorary mention

There is a screenshot of a new policy making the rounds on social media, where we can enable a policy to easily remove built-in apps in Windows. If I had a nickel for each Debloater script there exist online, well.. you know what I mean. This is still only on the rumor mill, so take this with a grain of salt for now.

I still know some companies are stuck running autopilot but gets devices delivered with consumer-grade windows images, where software like Mcafee and other 3rd party apps are pre-installed. I don’t think this policy will automatically remove 3rd party software like Mcafee and other junk, but it’s a step in the right direction.

Either way, If Microsoft delivers on this policy, then Microsoft is truly delivering on a request that’s been out there for years, almost ever since Windows 10 was released.

Final Thoughts

These features reflect Microsoft’s continued investment in security, manageability, and user experience. Whether you’re an IT admin preparing for deployment or a user eager for smarter tools, Windows 11’s future looks promising. If you ask me what is my favourite upcoming feature, I’d probably have to pick between QMR and the new experience for creating a start menu / pinned taskbar.

How many of these will be present in Windows 25H2 that’s due to be released later this year, I don’t know. For all intents and purposes, it looks like Windows 11 25H2 is a minor update that can be enabled through an enablement package if you are already running Windows 11 24H2. I guess we will have to wait and see :)