Why it’s important to keep drivers and BIOS up-to-date

This topic is still not sexy at all to talk about in IT, but it keeps getting more important. Drivers, BIOS and firmware are no longer something you set once when the device is imaged and then forget about. Hardware vendors ship a steady stream of updates, and a big chunk of them are security fixes.

A few reasons why you should care:

• Security: BIOS and firmware vulnerabilities sit below the operating system. That means your EDR, antivirus and most of your other security controls can’t see or stop an attacker who is living in the firmware. Features like Secure Boot, TPM, Kernel DMA protection and virtualization based security all depend on the firmware being in good shape. Keeping the BIOS up-to-date is the only real fix when a vulnerability is found at that level.
• Stability and performance: Many of the “random” issues end-users report, such as bluescreens, docking station issues, Wi-Fi dropping, poor battery life, or devices not waking from sleep, are often fixed by a driver or BIOS update.
• Compatibility: New Windows feature updates, new docking stations and new peripherals sometimes require a minimum driver or BIOS version to work properly.
• Less noise for the service desk: Fewer weird hardware issues means fewer tickets. Simple as that.

Lenovo Commercial Vantage vs. Windows Autopatch driver and firmware updates

Before we jump into the setup, let’s talk about the elephant in the room. Why not just use driver and firmware updates in Windows Autopatch (formerly known as the driver update management in Intune) and call it a day?

Honestly, for a lot of organizations, that’s a perfectly fine option, and it keeps getting better. But there are some differences worth knowing about:

So in short: Windows Autopatch gives you a simpler, more integrated and multi-vendor experience, while Lenovo Commercial Vantage gives you speed and the full catalog. If you have a mixed estate or you just want the least amount of moving parts, Autopatch is a great choice. If you want the latest BIOS and security fixes on your Lenovo devices as quickly as possible, Commercial Vantage is still the way to go.

Don’t let both solutions fight over the same updates. If you go with Commercial Vantage for driver and BIOS updates on your Lenovo devices, I recommend just disabling Driver updates via WufB or Autopatch.

Getting started

Download Lenovo Commercial Vantage

First we need the latest version of the Lenovo Commercial Vantage package. You can find it on Lenovo’s support site here.

The download link is easy to miss. Scroll down past the screenshot of the app, and click the “Version xx.xxxx.xx.x (Application and Deployment Guide)” link to download the zip file:

Once downloaded, extract the zip file to a folder of your choice.

Import the ADMX templates to Intune

Inside the extracted folder, you will find a folder called “Group Policy Settings”. This is where the ADMX template for Commercial Vantage lives, and it’s what we need to import into Intune, so we can control Commercial Vantage with policies. You will find the CommercialVantage.admx file, and the matching .ADML file under the en-US subfolder.

Head on over to Intune -> Devices -> Configuration. Then click the “Import ADMX” tab in the top, and click “Import”.

Select the CommercialVantage.admx file from the “Group Policy Settings” folder, and for the .ADML file, you can find it under the en-US subfolder. Then hit next and create. Wait 1-2 minutes, then hit “Refresh” - The template should show as “Available”. As with any other ADMX import in Intune, it can be a bit sluggish, so be patient with this one.

Upload failed? Import Windows.admx first

If you haven’t imported the Windows ADMX template to Intune before, the upload of the Commercial Vantage template will fail. The status will show as “Upload failed”:

If you click on the status, you will see the error details: “ADMX file referenced not found NamespaceMissing:Microsoft.Policies.Windows. Please upload it first.”

This is because the Commercial Vantage template depends on the Windows ADMX template. To fix it:

1. Delete the failed Commercial Vantage upload (click the three dots on the right -> Delete).
2. Import the Windows.admx file from C:\Windows\PolicyDefinitions, and the matching Windows.adml file from C:\Windows\PolicyDefinitions\en-US.
3. Wait until the Windows template shows as “Available”, then import the Commercial Vantage template again.

Once both templates show as “Available”, you’re ready to move on:

Packaging Lenovo Commercial Vantage as a Win32 app

Now we need to get Commercial Vantage packaged and uploaded to Intune as a Win32 app. Package the entire extracted folder using the Microsoft Win32 Content Prep Tool, with VantageInstaller.exe as the setup file.

You can use below install and uninstall command:

• Install command: VantageInstaller.exe Install -Vantage
• Uninstall command: VantageInstaller.exe Uninstall -Vantage
• Install behavior: System

The install command makes sure Lenovo Commercial Vantage is installed in system context, together with the relevant add-ons it needs.

Detection rule

For detection, we will use a custom detection script. Philip Jorgensen has made a great detection script for Commercial Vantage, which you can download from his GitHub: Detect-CommercialVantage.ps1.

Make sure to adjust the version in the top of the script, so it matches the version of Commercial Vantage you are deploying. Otherwise the detection will either fail, or Intune will think an old version is good enough. Remember to update it every time you package a new version.

Upload the script under “Detection rules” -> “Use a custom detection script”, and assign the app to your Lenovo devices.

Use an Intune filter on the assignment, such as (device.manufacturer -eq "LENOVO"), so you can assign to your existing device groups without the app landing on non-Lenovo devices.

Deploying baseline policies from Intune

Now for the fun part. Let’s create a new configuration profile: Intune -> Devices -> Configuration -> Create -> New policy. Select “Windows 10 and later” as platform, “Templates” as profile type, and then “Imported Administrative templates”. Give the policy a nice name like “Lenovo Commercial Vantage Update Settings”, and hit next.

Under Computer Configuration -> Commercial Vantage you will find all the Commercial Vantage settings, organized in folders. The ones we are interested in are under “Device” and “EULA”.

Device -> System update

Company name: Optional, but a nice touch. This is the company name shown in the System update dialogs, so the end-user can see the updates are coming from their own IT department.

Device -> System update -> Auto update

This is where the magic happens. You will find all the auto update settings in this folder:

These are the settings I recommend configuring:

“Auto update”: Set this to “Enabled”. This turns on automatic updates in Commercial Vantage, so updates are installed without the user having to open the app and click “Check for updates”.

“Configure Auto system update”: Set this to “Enabled” and select all the categories under both critical and recommended updates (application, driver, BIOS, firmware and others), unless you want to filter something out. This controls which types of updates auto update installs. If you leave it not configured, it follows whatever is set in “Configure System update”.

“Defer update”: Controls how many times the end-user can defer installing updates (“Defer Limit”, between 1 and 99), and how many minutes there are between each deferral (“Defer Time”). In the example below, the user can defer 3 times, 90 minutes each.

“Reboot delay time”: The number of minutes the user has before the device restarts, after updates that require a restart have been installed (Lenovo calls these “Reboot Type 5” updates). This is the countdown you will see in the restart notification in the end user experience section below. I use 45 minutes in the example below.

“Schedule the day for Auto update”: Select which days auto update should run. You have two options: enter specific days of the month in the “Day(s)” field (for example 1;15 or LastDay), or use “Frequency” together with the days of the week. For example, selecting “All” under Frequency and “Monday” under Day of the Week runs auto update every Monday. Combine it with “Schedule the time for Auto update” if you want to control the time of day as well.

“Show Pre-Install Notification”: Set this to “Enabled”. Updates are then downloaded in the background first, and the user gets a notification before any of them are installed. This is the “New updates are ready to install” prompt you will see in the end user experience section below. If you leave it not configured, some updates (the ones that don’t need a restart) are installed silently, and the user is only prompted for the ones that do.

EULA

“Accept EULA automatically”: Set this to “Enabled”. This accepts the Lenovo End User License Agreement and privacy statement on behalf of the end-user, so they don’t have to agree to it the first time they launch Commercial Vantage.

Change these settings based on your testing and your org’s needs. The “Defer update”, “Reboot delay time” and “Show Pre-Install Notification” settings are the ones that will have the biggest impact on the end-user experience, so they are good candidates to adjust per deployment ring.

Finally, assign the policy to your Lenovo devices. Just like with the app, use a device filter such as (device.manufacturer -eq "LENOVO") if you are assigning to groups that also contain devices from other vendors.

End user experience

So what does this look like for the end-user? When Commercial Vantage has found updates that are ready to install, the user gets a prompt listing the updates, in this case a BIOS update and a battery firmware update. The user can choose to “Install and restart”, or cancel and do it later. Notice the text asking the user to leave the device on and plugged in, which is important for BIOS and firmware updates.

If the user opens Lenovo Commercial Vantage while the updates are being installed, they can follow the progress under My device -> System update:

Once the updates are installed, the user gets a restart notification with a countdown. They can either click “Restart now”, or let the countdown run out, and the device restarts on its own.

The restart prompt only has a “Restart now” button, with no option to postpone it. Make sure your users know this is coming, so nobody loses unsaved work when the countdown runs out.

Nice to have: Battery and warranty information in WMI

This has nothing to do with drivers and BIOS, but it’s worth a mention while you are in the Commercial Vantage policies anyway. Commercial Vantage can write battery and warranty information to WMI, in the root\Lenovo namespace. That’s really nice for custom reporting and monitoring, for instance with a remediation script, a custom compliance rule, or by collecting it into Log Analytics.

“Write battery information to WMI table” (Device -> Device settings -> Power): Set this to “Enabled”, and configure how often the battery information should be written:

• Schedule type: 0 = daily, 1 = weekly, 2 = monthly
• Schedule day: Set to 0 if the schedule type is daily. For weekly, use 0-6 (0 = Sunday, 1 = Monday and so on). For monthly, use 1-31, or -1 for the last day of the month
• Schedule time: The time of day in HH:mm:ss format, for example 10:00:00

In the example below, the battery information is written every Monday at 10:00.

“Write warranty information to WMI table” (Device -> Warranty): Set this to “Enabled”.

Once the policy has applied and Commercial Vantage has written the information, you can query it with PowerShell:

# Battery information - the same information you see in the Commercial Vantage app
Get-CimInstance -Namespace root\Lenovo -ClassName Lenovo_Battery | Format-List *

# Warranty information
Get-CimInstance -Namespace root\Lenovo -ClassName Lenovo_WarrantyInformation |
    Select-Object SerialNumber, Product, StartDate, EndDate, LastUpdateTime

# Details of each warranty purchased for the device
Get-CimInstance -Namespace root\Lenovo -ClassName Lenovo_WarrantyElement | Format-List *

If the classes are not there yet, give it some time. The battery information is only written on the schedule you configured, and the classes are only created once Commercial Vantage has written the information for the first time.

You can find more details about the WMI classes in Lenovo’s Commercial Vantage configuration guide.

If you want to take the warranty information a step further, and get it into a Log Analytics workspace for reporting across all your devices, check out this blog post by Mattias Melkersen: Operationalize Lenovo devices in an Intune only environment. It shows an example of how to build a Log Analytics workspace and ingest the data. Thanks to Mattias for sharing it with the community.

Final words

I hope you found this walkthrough useful. Just like with Dell Command Update, there are pros and cons to using the vendor’s own tool compared to just using Windows Autopatch for drivers and firmware. The Windows Update experience is more integrated and works across all your hardware vendors, but if you use Lenovo Commercial Vantage, you will get BIOS updates, security fixes and driver updates on your Lenovo devices much faster.

A big thanks to Philip Jorgensen and Mattias Melkersen for sharing their work with the community. If you are managing Lenovo devices, Philip’s GitHub repository and Mattias’ post on operationalizing Lenovo devices in an Intune only environment are both well worth a look.

That’s all folks :)

Why this matters

When you are managing a modern endpoint estate, software inventory is about more than just knowing what is installed. It is also about knowing whether the right version is deployed, whether devices are healthy, and whether upcoming policy changes or feature updates may require action.

The Microsoft EPM agent is no exception. If you want to validate rollout progress, confirm the version on a device, or help support teams troubleshoot a policy issue, having the agent version in your inventory is incredibly useful.

Remediation to write EPM Versioning to installed apps

You can use Intune’s remediation system to continuously write the EPM version information to the installed apps on the device. When you do this, it makes sure the “Discovered apps” functionality in Intune can also inventory the agent version, whilst also adding support for your own 3rd party SAM systems such as Snow Inventory or similar.

You can find the remediation I wrote on my GitHub here

Assign to “All devices” and have it run daily. Make sure to tick “Run script in 64-bit PowerShell”.

Once you have it running, this is what it’s going to look like in your installed apps on your endpoints:

In Intune you will see it under discovered apps:

Wrapping up

Back when we were rolling out EPM at one of my customers, an early adopter, the EPM team would keep asking us for the client version during debugging sessions, and we had to go chase it in the registry every time. Hence this script. It’s a small thing, but it did reveal quite a few devices stuck on an old version, which the EPM team then helped us get fixed. We did of course ask for the version to be written to “Installed apps” natively, but they had their reasons for not doing it at the time.

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

I also wrote about this earlier this year in the context of the broader VBScript deprecation story: When Removing VBScript Breaks Your AMD Chipset Driver

Microsoft has also published a useful detection-focused article on monitoring for VBScript usage: VBScript deprecation: Detection strategies for Windows - Windows IT Pro Blog

The dependency is easy to miss because slmgr.vbs has been around for ages, but it is still common in scripts, runbooks, task sequences, you name it.

Why this matters now

Microsoft’s current guidance is straightforward:

• VBScript remains available during the transition phase, but it is no longer the preferred method.
• It will no longer be enabled by default in upcoming Windows releases - Can be enabled with a FoD (Feature on Demand)
• Eventually, it will be removed from future Windows releases.

Any workflow depending on slmgr.vbs should be identified, tested, and migrated before the environment reaches the final removal stage.

The Windows activation replacement

The recommended replacement for common activation automation is the OSLicense module in PowerShell.

The mapping is pretty clean for the most common actions:

This gives you a supported path without relying on a deprecated scripting host.

Example

# Activate Windows online
Invoke-OSLicense -ActivateOnline

# Install product key
Invoke-OSLicense -InstallProductKey "FCKGW-RHQQ2-YXRKT-8TG6W-2B7Q8"

# Review license status
Get-OSLicenseInfo

Check support before you migrate

Before rolling this out broadly, confirm the target device supports the OSLicense module. Install the latest September 2026 patch, to make sure it’s supported (Look for builds 26100.9278, 26200.9278 or higher)

• Windows 11: requires the appropriate servicing update, such as the August 27, 2026 Preview (KB5120998) or later
• Windows Server: availability is planned for the next major Windows Server release, with previews available for early validation in some builds

Inventory your scripts, confirm the supported Windows builds in your estate, and test the new scripts before rolling out broadly.

What to look for in your environment

A lot of activation automation hides in plain sight.

Search for these references:

• slmgr.vbs
• cscript
• wscript
• .vbs files
• runbooks or task sequences that call activation commands
• custom scripts that parse activation output or use legacy VBScript wrappers

This type of dependency often exists in:

• Intune device remediation logic
• helpdesk or service desk automation
• software distribution workflows
• provisioning and post-provisioning tasks
• MDT and SCCM in general (Yes… big time)

If you use Microsoft Defender for Endpoint, you can use this advanced hunting rule to audit VBScript usage

/ VBScript usage - script host execution and .vbs/.vbe file activity
// Timeframe: last 30 days
let lookback = 30d;
DeviceProcessEvents
| where Timestamp > ago(lookback)
| where FileName in~ ("wscript.exe", "cscript.exe")
| where ProcessCommandLine has_any (".vbs", ".vbe")
    or ProcessCommandLine contains "//E:vbscript"
| project Timestamp, DeviceName, AccountName,
    FileName, ProcessCommandLine,
    InitiatingProcessFileName, InitiatingProcessCommandLine,
    FolderPath
| sort by Timestamp desc

Final takeaway

For activation automation, the replacement path is already available in PowerShell for your Windows 11 clients, as long as your devices is running the latest OS Build from September 2026 or onwards (Nobody rolls out preview patches anyway..).

If you still have some device activation automation based on VBScript in your environment, now is the time to test the OSLicense module and migrate it before VBScript support will be removed.

For the full Microsoft guidance in regards to VBScript deprecation, see the following links:

• Keep Windows activation automation working with PowerShell
• VBScript deprecation: Detection strategies for Windows - Windows IT Pro Blog
• VBScript deprecation: Timelines and next steps
• OSLicense PowerShell reference

I’ve been sitting on this for a while, since we have been talking at great length with the product group about this some time ago. Since the cat is finally out of the bag, let’s dive into it.

Remote Help Unattended Access

Microsoft has released Unattended access for Remote Help, but if you ask me, it’s with a twist. It’s not as “Unattended” as you might come to believe. The functionality released is more like a Cloud RDP functionality. When the IT Admin initiates an unattended access session, it will kick the other user off as shown in the screenshot above.

In other words: What is referred to in some circles as “Session Shadowing” is not supported, and last time we spoke to the product group, this will never be supported. Specifically, this means the following scenarios cannot be supported:

• Common Kiosk Scenarios where there is no primary user but an application is running in the current user context
• Information screens or similar
• Factory areas w. Autologon scenarios

The key thing here is probably the autologon scenarios. A lot of companies still rely on this functionality. And while I can understand from a security perspective why Microsoft has decided not to support this scenario, it’s still a bit disappointing to see that they at least don’t want to hand over that control to the IT Admins, i.e: Give us a toggle to enable “Complete unattended” or “Session Shadowing” but only on select devices, using a policy or similar.

Wrapping up

This was just a short blog post to inform you all about this. A lot of my customers have been waiting patiently for this feature to release, since it’s been on the roadmap for so long. But of course, now that the cat is out of the bag, if you still need Session Shadowing in your remote support product, I guess you need to hang on to your TeamViewer or whatever you are using today for now.

P.S: I’m going to give this old blog post about Intel vPro some love very soon. This feature is so overlooked. Unattended access in Intel vPro is already released, amongst lots of other features.

That’s all… have a nice day :)

• 5-6 October 2026: Experts Live Saudi Arabia, where I will be delivering an EPM session.
• 13-15 October 2026: NIC26 Oslo, where I will be delivering an Intune Suite session.

When I started blogging more than 2 years ago, my initial goal was always to provide content through blogging - simple, to the point, with no fuss. But I’ve always had a dream of breaking out as a speaker on the big stages. I love presenting, I love being on stage, and I find it relaxing in a strange way, like it’s where I’m supposed to be. Delivering that awesome session that leaves people with something genuinely useful they can take back and use in their environment straight away, but with a few funny comments or remarks along the way to keep people engaged and attentive.

This year, things are definitely starting to kick off for me. I’ve already had several speaking engagements, and I’m starting to feel that I’m slowly becoming an established contributor in the endpoint management community, even though I’m not an MVP (yet - we will see :))

I’m incredibly grateful to everyone who took a chance on me in my early days by accepting my session submissions, even though they didn’t know who I was. I’m not going to lie, it’s been rough at times, with so many rejections over the years. It’s super difficult to break onto the major stage, especially when you don’t hold MVP status, because people don’t really know you that well. And of course, if you’re the organizer of a major event - especially one where people have to pay to get in - you pick the most established speakers.

So what is the future of this blog, if I’m going to spend more time on speaking engagements?

I’m going to continue blogging, of course. I just need to strike a new balance between helping my customers whilst also blogging and speaking on the side. I still enjoy blogging, don’t get me wrong, but in super busy times I find myself with a lot of drafts and no blog posts, as my days can become quite chaotic at times. So in the future, I will try and structure my days a bit better so I have dedicated time for blogging every other week or so.

That’s all for now, and I hope to see you out there :)

This change was made so Microsoft would be compliant with the EU’s Digital Markets Act (DMA). If a device’s region is set to an EU country, chances are you have been getting these additional SSO prompts ever since. Most of you reading this who have seen them probably find them rather annoying. It wasn’t really SSO anymore, more like MSO (Multiple-Sign On)? Ok, I just made that up right now, but you get what I mean.

I can’t count the number of support tickets I logged on behalf of my customers back in 2024, mainly for shared-device scenarios. It was a bit of a mess. Some of it got fixed, but other scenarios were just “working as designed”.

Some 2½ years later, enterprise administrators finally get a policy option to suppress the SSO prompt. To quote the Microsoft docs:

“For managed enterprise environments, some organizations wanted additional flexibility to manage the SSO prompt experience on devices where their organizations already manage sign-in policies and trust relationships. To support those scenarios, we’ve developed a registry-based control that lets IT administrators automatically accept SSO permissions on eligible managed Windows devices.”

Source: Microsoft Learn

Policy to suppress the SSO prompt

Microsoft recently published a blog post about the new policy option that allows you to suppress the SSO prompt. You can read it here.

The short version:

• Starting with the July 2026 patch for Windows 11 24H2 and 25H2, we can now suppress the SSO prompt
• It can be deployed via GPO or as a registry key using a PowerShell script:

Registry path: HKLM\SOFTWARE\Policies\Microsoft\Windows\AAD
Value: AutoAcceptSsoPermission (DWORD) = 1

There is currently no Intune Settings Catalog option to set this policy as of this date - I previously mentioned a settings catalog option, but it turned out it was an incorrect policy space that was not related. See the official docs for this setting here - You can also find a remediation to set it using Intune from my Intune github repo.

Wrapping up

These SSO prompts have certainly been an annoyance over the years, and they seemed so redundant. Microsoft also received a fair bit of slack when they started rolling it out, but what a lot of people seemed to miss back then was that this was a necessary step for Microsoft to become compliant with EU guidelines.

It’s nice that we finally have an option to suppress it in enterprise environments, and I guess this will be one of those “core” policies that ends up deployed in most environments.

That’s all for now, have a great day :)

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 :)