Did you know Autopatch creates those defined rings as static Entra groups? It then handles dynamic assignment when devices are registered.

But let’s back up a bit. What is Autopatch in the first place?

What is Windows Autopatch

Windows Autopatch is Microsoft’s managed update service. It takes most patching overhead off IT teams. It is cloud-based and automates updates for Windows and other Microsoft software such as Edge, Microsoft Office, and anything supported by the Windows Update engine.

When Autopatch is enabled in your tenant and you create new “Autopatch groups,” it automatically creates the relevant policies for Windows patching, feature updates, Edge, Office, and more. That saves IT admins from a manual click-a-thon.

I still meet a lot of customers who are skeptical of Autopatch. What many people miss is that WUfB (Windows Update for Business) was merged into Autopatch a while back. If you spend a lot of time in the Intune admin console, you have probably noticed things moved around. That is mostly due to Autopatch maturing over the past few years.

Getting started with Autopatch

To start configuring Autopatch, you need an Entra group for device onboarding. This can be static or dynamic. Also be sure to review the pre-reqs for Autopatch in the documentation. Navigate to Tenant Administration > Autopatch groups and click “Create” to start creating your autopatch group.

Give it a nice name and click Next.

The name you give your Autopatch group will be appended to all of the auto-generated policies and Entra groups.

Now for the important bits. First, add the Entra group that will onboard devices into your Autopatch setup. I recommend a dynamic group so you do not have to maintain it manually.

I recommend against using cloud-synced groups from SCCM collections where possible. Try to work within the parameters of Entra dynamic groups to keep your setup simple. SCCM cloud sync makes things unnecessarily complicated and slow.

Click “Add Deployment ring” for each ring you want. Five rings is a good starting point. Then adjust each ring percentage to control how many devices land in each ring. In my screenshot, the split is 5%, 15%, 20%, 30%, and 30%. That gives a balanced distribution in later rings while keeping enough volume early to catch noise sooner.

Once you are happy, click Next.

The Test and Last rings are not populated automatically. An IT admin must populate them manually through the “Autopatch group membership” blade in Intune. The Test ring is commonly used by device team personnel to validate changes before Ring 1. Ring Last can be used for devices that need a longer deadline or grace period before reboot enforcement.

In the update types section, I recommend disabling feature updates. If you enable them here, Autopatch creates a “feature update anchor policy.” That is an “Immediate Start” policy for the selected version, which can force immediate updates on devices that are not already up-to-date based on the version you specify in the autopatch policy. To control feature updates properly, use the Autopatch multi-phase feature update rollout.

Also, do not select Driver Updates if you are already managing driver updates with the OEM’s own solution, i.e., Dell Command | Update, HPIA, or Lenovo System Update.

If you do decide to enable driver updates, keep in mind that Deadline and Grace Periods also apply to driver updates released via Autopatch, and is shared jointly with the quality updates.

Click Next again.

In the next blade, you can choose which rings get Edge Beta and Edge Stable. Edge Beta for Ring Test is the default. Just be prepared for occasional browser weirdness, since you will receive features before the masses.

Click Next again.

In the next section, you set timing for when quality updates are delivered to each ring. Before changing anything, make sure you understand these concepts:

Tuning these timers to your risk profile is extremely important. If you work in defense, security, or similar sectors, keep values as low as possible. Still leave enough room in later rings to absorb noise found early. Defaults are fine for many organizations, but if possible, lower deferral and raise grace. Many users reboot early anyway. That approach gives users flexibility while reducing exposure time. As always, there are trade-offs.

When you are done, click Next. Apply any scope tags if relevant, and then click Next and Finish.

Using Autopatch rings for your own benefit

Once set up, Autopatch starts registering devices from the Entra group you assigned. Almost immediately after creating the Autopatch group, you will see Entra groups for each ring.

That is super valuable when you need to roll out a new policy, app, script, and so on. You can reuse those same rings for your own deployments.

If you create multiple Autopatch groups, they are consolidated under these groups: Modern Workplace Devices-Windows Autopatch-Test, Modern Workplace Devices-Windows Autopatch-First, Modern Workplace Devices-Windows Autopatch-Fast, and Modern Workplace Devices-Windows Autopatch-Broad. You can use these too, but the device split can be uneven between First and Fast.

Manually changing devices to different rings

Once devices start registering, Autopatch will distribute them dynamically based on the percentages you configured. If you want to move specific devices, for example into Ring Test, Fast, or any other ring, go to Tenant Administration > Autopatch Groups > Autopatch Group Memberships.

Search for the device, select it, click “Assign ring,” and choose the ring you want it in.

The Autopatch Group Memberships blade is also where you can exclude devices from Autopatch. You can also review “Not registered” devices, which shows devices that failed registration. Common reasons include unmet prerequisites such as “Windows update workload not swung over” or “Devices must be managed by Intune or Co-mgmt.”

The end

Remember to also build a multi-phase feature update rollout for your target version. It is straightforward and works well in phases.

Final word of advice: factor in delivery timing when testing policies, apps, or other major changes against Autopatch rings. After Autopilot enrollment, a device may take 10-30 minutes to register with Autopatch, depending on your environment. So if you are testing something that normally lands during ESP, targeting Autopatch rings will not fully test the new-device deployment scenario.

That’s all for now. Hope you found it useful. Have an awesome day :)

It’s been almost 2 months since the individual known as “Nightmare-Eclipse” (aka “Chaotic Eclipse”) released 6 zero-day exploits, and I’ve been closely monitoring the debacle as it unfolds. On one side you have a disgruntled security researcher who firmly believes Microsoft has wronged him, and on the other you have Microsoft taking a no-BS approach, saying normal protocol wasn’t followed and that making the source code for all of these exploits publicly available was ruthless and irresponsible. They even went so far as to ban the GitHub repo where all of the source code was initially hosted.

You can read more about the details here - the events are still unfolding, and I don’t think we’ve seen the last of it yet. Microsoft released a blog post 2 days ago (as of today’s date) in which they clearly distance themselves from the kerfuffle, and according to them the security researcher is 100% to blame. You can read Microsoft’s response here.

Be that as it may, what about the BitLocker exploit dubbed “Yellowkey”?

What is the YellowKey exploit

The YellowKey exploit is a BitLocker bypass attack that allows an attacker with physical access to a device to gain access to the data on a hard drive, even though it’s encrypted with BitLocker. Mechanically, it involves placing specially crafted ‘FsTx’ files on a USB drive or EFI partition, rebooting into WinRE, and triggering a shell by holding down the CTRL key. It bypasses TPM-only BitLocker in particular, and the critical constraint is physical access — it cannot be abused remotely.

So it’s not great — in fact, I’d go so far as to say it’s pretty bad. One of the main features of BitLocker is data-theft protection in case a device gets stolen.

It’s worth noting that this vulnerability only affects Windows 11 24H2 and higher. It does not affect earlier versions of Windows 11 or Windows 10 — Windows 10 is in the clear due to differences in how it configures WinRE.

Don’t forget your servers: the client side isn’t the whole story. Microsoft’s MSRC advisory lists the canonical affected products as Windows 11 24H2, 25H2 and 26H1 (x64), plus Windows Server 2025, including Server Core. Windows Server 2022 was thrown around as affected when the PoC first dropped, but it’s not in Microsoft’s official scope, so treat that as unconfirmed.

So what can we do about it?

Mitigation using Intune

Microsoft has released a PowerShell script as an interim fix that mitigates the attack until an official patch is released through normal channels. You can find it in their security update report for this incident here. The fix is relatively simple: mount the WinRE partition and remove the Autofstx.exe executable.

The PowerShell script can be deployed through Intune as a platform script, but there is no detection or logging mechanism, so if it fails you won’t know why. I recommend heading over to James Vincent’s blog post about this and grabbing his remediation scripts instead. You can find his blog post here.

Download both the detection and the remediation script.

Logging: Both the detection and remediation scripts log to the IntuneManagementExtension folder under C:\ProgramData\Microsoft\IntuneManagementExtension\Logs, so you’ll have something to check if a run fails.

Once downloaded, I also recommend you create a new device filter in Intune so you can target devices running Windows 11 24H2 or Windows 11 25H2. In Intune, navigate to Devices > Assignment Filters and create a new filter. Set the property to “osVersion”, the operator to “starts with”, and the value to “10.0.26100”, then add an “or” rule with a second “osVersion” / “starts with” / “10.0.26200”. It should end up looking like this: (device.osVersion -startsWith "10.0.26100") or (device.osVersion -startsWith "10.0.26200")

Now head over to Intune > Scripts and Remediations and click “Create”. Give it a nice name, e.g. “YellowKey mitigation”. Then add both the detection and the remediation script. Make sure to set “Run script in 64-bit PowerShell” to “Yes”. Click Next, apply scope tags if required, then hit Next again. Now for the important bit: I recommend you assign it to a few devices to test first, before starting the broad rollout. If you are already using Autopatch, you will already have these rings — just search for “Autopatch” and you should find the corresponding Autopatch Entra groups matching your rings.

Adjust the “Schedule” so it only runs every 7 days or similar. There is no reason to have it run daily. Then make sure to apply the Windows 11 24H2 or higher filter you created earlier.

You are now ready to start deploying to a test and an early ring. Once you are happy with the results, you can gradually continue the rollout by adding your remaining rings. Alternatively, if you don’t really care about testing and just want to deploy the mitigation to everyone immediately, you can deploy to “All Devices” with the Windows 11 24H2 or higher filter.

That’s it for now

I hope you found it useful.

Remember: only deploy to Windows 11 24H2 or higher (and Server 2025), or you’ll most likely see an error when trying to remediate, such as REAGENTC.EXE: Operation failed: c142011c / REAGENTC.EXE: An error has occurred.

I’ve used this approach at two customers already with great results. We got a few errors in the beginning because we forgot to add the device filter, so Windows 10 and earlier versions of Windows 11 devices were targeted as well.

Have an awesome day ahead :)

The TL;DR version:

• Mass-wipe commands were sent using Microsoft Intune to all Windows-based devices
• Servers were also impacted - But not using Intune
• In total, around 200,000 devices, including servers, laptops, desktops and mobile devices were affected

A compromised admin account (presumably a Global Admin, but we don’t know yet) was the culprit. Over the past several years, there’s been a strong push for reducing the amount of Global Admins, Conditional access policies and phish-resistant MFA for these accounts. Hell, phish-resistant MFA should be implemented for everyone, but Global Admins should definitely be the first in line.

One thing I noticed during the week the incident unfolded, was a seemingly knee-jerk reaction to enable MAA because that would prevent incidents like these. But would it? Let’s find out.

Multi-Admin Approval overview

Multi-Admin Approval (MAA) is a relatively new feature from Microsoft Intune that adds an extra approval layer for high-impact actions such as Device Wipe and Device Delete. Microsoft is also adding more device actions and policy types, for now it supports a few different policy types, such as modifying applications, running scripts or modifying a role. But the majority will probably look at enabling MAA for the following device actions: Delete, Retire and Wipe

When you create any of these MAA policy types, it is a tenant-wide policy. Scope tags are not supported, and scoping a MAA-Policy only to certain devices or users is also not supported for now. When you create the MAA policy, you will need to assign an EntraID Group of who can approve requests and then it will need to be approved by another admin before the policy actually is in effect. Note that even Global Admins cannot approve their own MAA requests. Once the request is approved by another admin, you will have to navigate back to the MAA Pane in Intune and finally click “Complete request”. The approach is the same for the other MAA actions, let’s break it down.

How it works in practice

Let’s run through a scenario where an admin wants to delete a device. In this example we will have 2 admins. Admin 1 is Bob and Admin 2 is Rachel.

1. Bob initiates a device wipe towards a device from Intune. Since there is an MAA-Policy deployed, it will need to be approved by a 2nd admin, and Bob will need to provide a justification included in the request.
2. Rachel approves the request from the MAA Requests pane in Intune. Rachel also needs to provide an approval reason.
3. Bob then has to go to the same Multi-Admin Approval pane, click his request, and finally hit the “Complete request” button to actually initiate that wipe. Bob will have to do this within 3 days after the approval was given, otherwise it will expire.

If the action expires before clicking “complete request”, Bob will have to initiate a new wipe request and get it approved again.

It’s important to underline that the action doesn’t automatically complete once it’s approved, the requesting admin will have to go to click that “Complete request” button to finalize the action, so essentially a 3-step process. There is also no built-in notification system, so admins are not currently notified in any way when an approval request is sent to the portal or when a request is approved. It is possible to create your own notification tooling, e.g., Power Automate or an Azure Logic App to send notifications via email or to a Teams channel.

NOTE: Based on learnings from the field, I’ve found it can take between 15-30 minutes for MAA to actually process the request. Example: If you press “complete request” to delete or wipe a device, it doesn’t immediately process.

What it protects against

I want to be clear: this does NOT protect against a compromised Global Administrator (GA) account. In various posts I found on LinkedIn and Reddit, it was frequently misconstrued that by simply implementing MAA, you were protected against these mass-wipe attacks, but this is not the case if the compromised account is a GA. When you obtain GA you have full administrative rights in the tenant. The GA will be able to simply delete the MAA policy or create separate admin accounts to approve their own MAA requests. Alternatively, an overprivileged app registration can also tamper with these settings, which is an additional blind spot that many companies are unaware of.

However, and to be clear, MAA does protect against the following:

• Accidental device wipe/deletion
• The disgruntled employee scenario: On their last day at work, the individual could initiate mass-wipes before heading out the door.
• Singular compromised Intune Administrator or similar (Think Custom RBAC Roles in Intune)

A few gotchas

1. MAA does not protect against a Compromised GA Account
2. If you are using 3rd party or custom-written tools to process intune device deletions or wipes, they will most likely stop working after implementing an MAA policy, e.g., a custom-written PowerShell script or tools like IntuneOffboarding.
3. When deleting devices using a script, you need to put a justification for the deletion request in the header when using Remove-MgDeviceManagementManagedDevice or use one of the new Graph cmdlets for managing approval requests (source). I also found a new tool from a fella named Mark Orr who wrote a PowerShell module for handling all aspects of MAA, you should check it out here
4. Before implementing MAA, I would strongly recommend reviewing your processes for using actions like wipe and delete. They tie heavily into the device lifecycle process. It can heavily impact the daily operations in an IT ServiceDesk or an IT team that is managing devices in a multi-region company.
5. Currently there is no option to assign an MAA Policy to a given set of devices or limit to specific scope tags or groups, it’s an all or nothing switch. If you decide to enable MAA in your tenant, be sure to communicate to all stakeholders in advance.
6. Processing an action like Delete or Wipe is not immediate - Be patient :)
7. If using Custom-RBAC Roles with Groups via PIM, sometimes the MAA pane doesn’t show all devices/requests - This can confuse support personnel. As a rule of thumb, wait 15 minutes after activating the group-based PIM role, and then reopen the Intune tab, to avoid this problem.

Rounding off

There are definitely pros and cons for using MAA, and it needs to be well thought out before just blindly enabling it, since it can heavily affect your device lifecycle process, whilst there is also no option to scope an MAA Policy to just a group of test devices or test users, so it’s an all or nothing switch. MAA in its current shape and form, as of this date, is extremely rigid. It’s still very early days, and I’m sure Microsoft will give it some love over the coming months.

That’s all for now, I hope you found it useful. :)

What I hear consistently across customers and enterprises is not surprising: more new hires—especially developers—are choosing macOS over Windows when they start a job.

Why developers prefer macOS

Common feedback from developers is straightforward: “macOS is easier and faster. Everything just works and I can do what I need without restrictions.” That perception is driving platform choice for many technical hires.

Many organizations apply heavy security controls on Windows devices, which can push employees toward macOS. At the same time, those same organizations often apply far fewer controls to macOS devices. This creates an uneven security posture across the estate.

I see a few root causes:

• Tooling gaps: IT teams often lack out-of-the-box tools to manage features such as application control and local administrator rights for both platforms. Third-party solutions are frequently required.
• Process shortcomings: exemption and approval workflows are often slow or poorly defined, which encourages workarounds
• Knowledge gap: Many IT admins in Windows-first organizations have limited macOS experience. When macOS is introduced as a platform option, training is often missing, and admins are expected to manage it like Windows. Teams need to build basic macOS skills before they can run advanced security controls.
• Leadership awareness: Decision makers needs to be aware of all of the above, when introducing macOS as a platform choice into their estate.

A real-world example

One of my good friends whose also a developer, switched jobs, and joined a large bank in Denmark recently. He was given a Windows device with no administrator rights. While that policy aligns with security best practices, it created productivity friction: requests for temporary admin access took three to four weeks to process.

The workaround? The team provided a Mac mini with root privileges, that could be accessed remotely, where he could do his “actual” work, while outlook/teams was to be used on his Windows laptop. He could do everything he wanted on the mac mini, since he had root access, while still being able to access the same network and files as on the Windows device, effectively bypassing the controlled Windows environment. In the end, he just chose a macOS Laptop as his main working device, where he also have root access.

Recommendations

To address this imbalance, organizations should consider:

• Raising knowledge and awareness of macOS management+security in the IT team managing devices
• Streamline the developer onboarding experience for Windows, so it’s similar to macOS
• Be realistic about things like Security Baselines and CIS Baselines for Windows: User productivity and Security needs to be balanced.
• Consider acquiring a cross-platform PAM Solution for Endpoints that works both for macOS and Windows for managing local administrator/root access.

Conclusion

The tension between developer productivity and enterprise security on windows is real. Rather than letting platform preference drive shadow IT, organizations should close the management gap between Windows and macOS—so that developers can be productive without creating unmanaged security risks.

macOS is definitely here to stay in the enterprise world, and adoption is growing rapidly as time progresses. When examining the hardware alone, specifically looking at the new macOS M5 chips, they have a major advantage over Windows-based offerings currently in the same space. ARM for Windows is slowly becoming a thing, but as of this date, Qualcomms chips is already falling behind from a performance perspective when compared to Apple. And we did not even cover the whole ARM-application and driver perspective for Windows yet, which is a huge problem for many orgs that prevents wide adoption

That’s all for now, have an awesome day :)

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.

Monitoring for updated certificates

Intune

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

Defender

If you have Defender with E5, you can also monitor for the certificates in Defender, with the added benefit you also get servers here.

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!