Microsoft has confirmed the next annual feature update, Windows 11, version 26H2, and the headline for IT is a familiar one: this is an enablement package (eKB), not a full OS swap. If you have been through the 24H2 to 25H2 cycle, the playbook is almost identical – but there are a couple of new wrinkles worth planning around. This post walks through the supported upgrade paths, how you drive it with Windows Autopatch and Intune, and how to actually track the rollout from pilot to production.
What 26H2 actually is
26H2 shares the same servicing branch as 24H2 and 25H2. That means for devices already on those versions, the upgrade is delivered as a tiny enablement package – around 174 KB – that simply flips the version and build number (build 26300) after a single restart. No multi-gigabyte download, no long offline phase, no feature-update reboot marathon. The new capabilities ship continuously through monthly cumulative updates and are switched on by the eKB.
Microsoft frames it as “a predictable, low-disruption update experience for organizations and IT professionals,” and from a deployment standpoint that is exactly what it is – an update ring approval rather than a migration project. Expect general availability in the fall of 2026, in line with previous H2 releases.
Upgrade paths – know your starting point
The delivery method depends entirely on the version a device is sitting on today:
Windows 11 24H2 / 25H2 – direct eKB upgrade. ~174 KB, one restart. This is the easy 95% for most managed fleets.
Windows 11 23H2 and older – different servicing branch, so no eKB. These need the full feature-update media path (~6.5 GB download and the full upgrade experience).
The 26H1 caveat – 26H1 sits on a separate Windows core branch and does not roll forward to 26H2 via the standard enablement path. If you have any 26H1 (specialized/insider) devices, plan a different route for them.
Windows 10 – no shortcut here. These are full upgrades (or, frankly, replacements) and should already be on your end-of-support migration plan.
Upgrade paths to 26H2 depend on the version a device sits on today.
Action before fall: run an inventory split by OS version now. Anything not already on 24H2/25H2 is your long-tail – get those onto a current branch first so 26H2 becomes a one-restart eKB rather than a 6.5 GB project.
Driving it with Windows Autopatch
If you are on Autopatch, 26H2 is close to trivial to approve – it appears in the feature update flow like any other release, and because the payload is tiny, distribution can complete in a day rather than weeks.
The mechanics you already rely on still apply. Autopatch groups split your estate into deployment rings – Test, First, Fast, and Last. If you do not define extra rings, Test acts as your pilot and Last as production. Releases flow sequentially through the rings, and Autopatch monitors device telemetry the whole way – if failure or compatibility signals spike, it can automatically pause progression to the next ring.
Pilot: keep Test/First small but representative – mix hardware models, key line-of-business apps, and a few power users who will actually report friction.
Soak time: because the eKB is so small, the temptation is to rush. Resist it – the value of a pilot is the soak window, not the download time. Give each ring a real bake period to surface app and driver issues.
Safety net: you retain Pause, Resume, and Rollback for feature updates directly from Intune if a ring goes sideways.
Not on Autopatch? The same model is available with Intune Feature Update profiles plus Update Rings – you target 26H2 as the feature update version and stagger deferrals/rings manually. You lose the automatic ring progression and telemetry-driven pause, but the staged approach is the same.
Autopatch rings, the telemetry safety net, and what to watch as you promote from pilot to production.
Tracking pilot to production
This is where most rollouts get loose. “We deployed it” is not the same as “we can prove the estate moved.” Here is the reporting stack I lean on:
Reports > Windows Autopatch – the two Autopatch reports give you ring-level rollout status and quality/feature update health. This is your primary “where is each ring” view.
Reports > Device management > Windows Updates – the feature update report and readiness reporting validate which devices are eligible and which are blocked, before and during the push.
Email notifications – make sure your Autopatch admin contacts are current so you actually receive the proactive alerts rather than discovering issues in a dashboard.
A simple version-count KQL/report – track devices reporting build 26300 over time as your single “percentage on 26H2” number for management. Watch the curve per ring, not just the total.
Define your exit criteria before you start: e.g. pilot ring at >95% success with zero unresolved Sev-1 app issues for X days before releasing the next ring. Let the telemetry and your soak window – not the trivial download size – gate each promotion.
Support lifecycle
The usual split applies: Enterprise, Education, IoT Enterprise and Enterprise multi-session get 36 months of support, while Home, Pro, Pro Education and Pro for Workstations get 24 months (support running to roughly October 2028). Factor that into whether 26H2 is a “move now” or a “this fall” decision for each ring.
A short pre-flight checklist
Inventory by OS version – identify anything not on 24H2/25H2.
Get the long-tail (23H2 and older, Windows 10) onto a current branch first.
Flag any 26H1 devices for a separate path.
Confirm Autopatch groups / Intune feature update profiles and rings are sane.
Verify Autopatch admin contacts and reporting access.
Write down your per-ring exit criteria and soak windows.
Bottom line: 26H2 is an approval, not a migration – for the devices that are on a current branch. Spend your effort on the long-tail and on a disciplined pilot-to-production cadence, and the eKB itself will be the least interesting part of the project.
You manage a fleet of corporate iPhones through Microsoft Intune. Enrollment is automated through Apple Business Manager (ABM), apps deploy silently through the Volume Purchase Program (VPP), and users never see an App Store login. Then one day, your service desk starts getting tickets:
“Sign in to iTunes Store. Sign in to allow Contoso A/S to manage and install apps.”
A handful of devices show the prompt at first. A few days later, dozens. Users tap Cancel, the dialog disappears, and a few hours later it reappears. Some users sign in with personal Apple IDs to make it go away, which is exactly what you do not want on a corporate device.
This is one of those issues that looks like an Apple ID, ABM, or enrollment problem – but almost never is. In every case I have worked, the root cause was the same: somewhere in the tenant, an app was added as an iOS Store App when it should have been added as an iOS Volume Purchase Program app. This post walks through why those two app types behave so differently, how to confirm which one is causing the prompt, and how to fix the issue across a large device estate without disrupting users.
Why iOS Devices Ask for an Apple ID in the First Place
Intune offers several iOS app types in the admin center. Two of them install the same app from the same App Store listing, but they have completely different licensing and installation behavior:
iOS Store App – A direct link to a public App Store listing. The app installs into the user’s iCloud account. The device must be signed in to the App Store with a personal or managed Apple ID for the install to complete. There is no concept of device-based licensing.
iOS Volume Purchase Program app (VPP) – An app license that your organization owns through Apple Business Manager. With Device licensing, the license is assigned to the device itself – no Apple ID is required on the device for the install. The app simply appears.
The two app types look almost identical in the admin center. Both can point to the same App Store URL. Both can be assigned as Required, Available, or Uninstall. The difference is invisible until a device tries to install the app and discovers it has no Apple ID signed in.
When an iOS Store App is assigned as Required to a supervised device with no Apple ID, iOS does what it is told – it prompts the user to sign in so the install can proceed. That is the prompt your users are seeing.
Why You May Not Have Seen This Before
A fresh ABM enrollment with VPP apps assigned through Device licensing never triggers an Apple ID prompt because no app on the device needs one. The issue surfaces when somebody adds the same app a second time – as an iOS Store App – usually because they pasted the App Store URL into the wrong “Add app” wizard. The VPP version may still be present, but the iOS Store App duplicate is now competing for the same slot on the device, and only one of them can win.
How to Confirm This Is Your Issue
Before you start changing assignments, confirm the diagnosis. Three quick checks usually settle it.
Check 1: List All iOS Apps with Required Assignments
In the Intune admin center, go to Apps > iOS/iPadOS and filter the list. Look at every app where the App type column shows iOS store app. For each one, open the app and check Properties > Assignments.
Any iOS Store App with a Required assignment is a candidate for the prompt. iOS Store Apps assigned only as Available or Uninstall do not trigger the prompt – they sit quietly in the company portal or only act when the user actively removes the app.
Check 2: Cross-Reference with VPP
For each suspect iOS Store App, search for a VPP version of the same app. The naming will be similar but not identical – the VPP version typically shows the publisher and a different icon variant. If both versions exist, the iOS Store App is almost certainly redundant.
Check 3: Look at the Audit Log
Intune’s audit log will tell you exactly when each app was added and by which admin account. Go to Tenant administration > Audit logs and filter on the Mobile App category. Search for the app name and check the Create entries. In one recent case, an admin had bulk-added a dozen iOS Store App duplicates within a 20-minute window – clearly someone working through a list using the wrong wizard.
If checks 1 and 2 confirm the duplication and check 3 confirms when it happened, you have your root cause.
Why You Cannot Just Delete the iOS Store App
The natural reaction is to delete the iOS Store App duplicate and be done with it. Resist that urge until you have a rollout plan, because three things can go wrong:
Users still see the prompt until iOS finishes its install queue. iOS does not automatically discard a pending install when its source is removed. The user has to Cancel the prompt at least once – sometimes more than once – before the MDM channel processes the change.
Required and available install intent on a managed device is sticky. If the VPP version is not already assigned and licensed at the device level, removing the iOS Store App leaves users with no app at all.
Filters and groups can overlap in non-obvious ways. If the iOS Store App is assigned to a broad group and the VPP version is assigned to a different broad group, deleting one may pull the app from devices that should still have it.
The safe sequence is: assign the VPP version with Device licensing first, validate on a single device, then remove the iOS Store App.
The Pilot Approach: Validate on One Device Using Assignment Filters
Before you touch a production assignment, prove the fix on one device. Intune’s Assignment Filters make this clean.
Step 1: Create a Single-Device Filter
In the Intune admin center, go to Tenant administration > Filters > Create.
Platform: iOS/iPadOS
Name: Something obvious like Pilot-iPhone-XYZ123-only
Rule syntax:
(device.deviceName -eq "XYZ123")
Replace XYZ123 with the actual device name from Devices > iOS/iPadOS devices. Use Edit in advanced mode if you prefer to write the rule directly.
Step 2: Exclude the Pilot Device from the iOS Store App Assignment
Open the problematic iOS Store App in Intune. Go to Properties > Assignments > Edit. On the existing Required assignment, click Filter and set:
Filter mode: Exclude
Filter:Pilot-iPhone-XYZ123-only
This tells Intune to apply the iOS Store App’s Required assignment to everyone except the pilot device. The pilot device is now isolated from the prompt – existing prompts may still need to be dismissed once, but no new ones will queue.
Step 3: Assign the VPP Version with Device Licensing to the Pilot Device
Open the VPP version of the same app. If it does not yet have a Required assignment to the same target group, create one:
Assignment type: Required
Group: The same group the iOS Store App was assigned to
License type: Device
Filter:Pilot-iPhone-XYZ123-only
Filter mode: Include
This is the inverse of Step 2 – the VPP assignment now applies only to the pilot device. The rest of your estate still gets the (about to be removed) iOS Store App version; the pilot device gets the VPP version with a device-bound license.
Step 4: Have the Pilot User Dismiss the Prompt and Sync
Walk the pilot user through these exact steps:
When the iTunes sign-in prompt appears, tap Cancel.
Open Settings > General > VPN & Device Management > the MDM profile.
Tap Sync to force a check-in.
Within a minute or two, the VPP version of the app installs silently. No Apple ID prompt. The app shows the small organisation marker indicating it was installed by MDM.
If the install fails or the prompt comes back, stop and investigate before going further – usually the cause is a missing VPP license assignment or an expired VPP token (more on tokens below).
Rolling Out the Fix to the Rest of the Estate
Once the pilot is green, the rollout is mechanical. For each affected app:
On the VPP version, remove the Pilot-XYZ123-only filter so the Required + Device-licensing assignment applies to the full target group.
On the iOS Store App version, remove the existing Required assignment entirely. Do this before deleting the app to avoid an Intune sync that might re-prompt users.
Delete the iOS Store App entirely once no devices reference it. This also makes sure nobody re-uses it accidentally later.
If you have several apps to fix, work through them one at a time. iOS handles MDM commands serially, so a batch change can produce more prompts than you would expect.
What Users Should Expect
Communicate clearly to end users before you flip the assignment. A short email along these lines works well:
Over the next 24 hours, you may see a sign-in prompt on your work iPhone asking you to log in to iTunes or the App Store. Please tap Cancel. Do not enter any Apple ID. The app you are missing will install automatically within a few minutes after you cancel the prompt.
The behaviour is non-obvious: iOS only processes the next MDM command after the current prompt is dismissed. Until the user taps Cancel, the device is effectively stuck waiting for the user.
Cleanup: Filters, Duplicates, and Audit Trail
After the rollout is complete, do not leave the scaffolding in place:
Delete the pilot assignment filter (Pilot-iPhone-XYZ123-only) so it does not get reused accidentally.
Confirm both iOS Store App duplicates are deleted – keeping them around “just in case” invites the same mistake again next quarter.
Document what happened in your change log so future admins know the difference between iOS Store App and VPP and which to use.
Run a tenant-wide review of remaining iOS Store Apps. Any iOS Store App with only Uninstall or Available (without enrollment) assignments is safe. Any iOS Store App with a Required assignment to a device group should be evaluated.
A Quick Reference: iOS Store App vs VPP at a Glance
Aspect
iOS Store App
iOS VPP App (Device licensing)
Source
Public App Store URL
Apple Business Manager (purchased)
Requires Apple ID on device
Yes
No
Required-install on supervised devices
Triggers iTunes sign-in prompt
Installs silently
License consumed
None tracked by MDM
One per device
Revoke license
Not possible
Yes, from Intune
Update behavior
Same as App Store
Same as App Store
Cost
Free apps only (in practice)
Free and paid apps
Recommended for managed iOS
No
Yes
The short version: on a corporate-owned iOS device managed through Apple Business Manager, VPP with Device licensing is the only app type that should appear as Required for first-party and approved third-party apps.
How to Prevent This from Happening Again
The root cause is almost always procedural – an admin selected the wrong app type from the Intune wizard. A few controls reduce the chance of recurrence:
Document the standard. Add a one-line rule to your Intune operations doc: “All Required iOS apps must be added as iOS Volume Purchase Program apps. iOS Store Apps may only be used for Available or Uninstall assignments.”
Restrict app creation with RBAC. Use scope tags and Intune’s role-based access control to limit app creation to a small group of admins who know the difference. The principle of least privilege applies to MDM tenants too.
Use audit log alerts. Microsoft Graph + a small Logic App can email you whenever a new iOS Store App is created. Quick to set up, quick to react.
Check the VPP token expiry. A frequent secondary cause is an expired VPP token. When a token expires, Intune cannot create or renew Device licenses, and admins reach for “iOS Store App” as a workaround that turns into a permanent footgun. Renew the token annually and set a calendar reminder a month in advance.
Healthy VPP Token Practices
A VPP token has a 12-month validity. When it is close to expiry, Intune shows a banner in the Tenant administration > Connectors and tokens > Apple VPP Tokens view. After expiry:
Existing licensed apps continue to function.
New licenses cannot be assigned.
Token renewal requires a new .vpptoken file from Apple Business Manager.
If your token has just been renewed and apps are stuck in Failed state, revoke and re-assign licenses one app at a time. Bulk re-assignment occasionally fails for individual apps, and the only way to clear the failed state is a manual revoke + reassign cycle.
Troubleshooting: When the Prompt Will Not Go Away
If you have applied the fix and a specific device is still prompting, work through these in order:
Has the user tapped Cancel at least once? iOS sometimes queues multiple install commands – the user may need to dismiss two or three prompts before the queue drains.
Force a sync. From the device: Settings > General > VPN & Device Management > MDM profile > Sync. From Intune: Devices > select device > Sync.
Confirm the device is licensed for the VPP version. Open the VPP app in Intune > Device install status. The device should be listed with Installed or Pending. If it is Not applicable, the assignment is not reaching the device – check group membership and filters.
Check the VPP token health.Tenant administration > Connectors and tokens > Apple VPP Tokens. If the token shows any warning, address that first.
Reboot the device. Last resort, but occasionally clears a stuck MDM channel.
If you have exhausted these, look at the device’s Managed Apps report. An app that should be VPP-licensed but appears under iOS Store App lineage indicates the old assignment is still active somewhere – usually a forgotten filter or a duplicate group assignment.
FAQ
Will users lose any data when I switch from iOS Store App to VPP?
No. The App Store install and the VPP install are the same app binary from the same listing. Local data and settings are preserved across the transition because iOS treats them as the same bundle ID.
Do I need a managed Apple ID for VPP with Device licensing?
No. Device licensing is the entire point – the license is bound to the device hardware identity, not to any Apple ID. The device can have no Apple ID signed in at all, and VPP apps will still install.
Can I keep using iOS Store Apps for some apps?
For apps you want to make optionally available to users through the Company Portal, yes – assign them as Available. For Required deployment to corporate-owned devices, no. Switch them to VPP.
What about iPadOS devices?
The same rules apply. iPadOS uses the same MDM commands and the same VPP licensing model as iOS. If you have iPads in the same affected group, they will exhibit the same prompt behaviour and be fixed by the same approach.
My VPP token was renewed by someone else and now apps are failing – is this related?
It can be. A token renewal sometimes leaves individual app licenses in a Failed state until they are re-assigned. This is a separate issue from the iOS Store App vs VPP problem, but you may encounter both at once if the same admin tried to “work around” the failed VPP state by adding iOS Store App versions. Treat the VPP licensing failures as a separate workstream once the prompt is gone.
Summary
If iOS devices managed by Microsoft Intune are showing an iTunes or App Store sign-in prompt, do not start with Apple ID configuration, ABM enrollment, or DEP profiles. Start with your app inventory. Look for iOS Store Apps with Required assignments that overlap with VPP versions of the same app. Fix one device first using assignment filters, then roll the change out to the rest of the estate, and finish by deleting the iOS Store App duplicates entirely.
The technical fix is simple. The harder part is preventing the next admin from making the same selection in the same wizard – so document the standard, restrict who can add apps, and keep your VPP token healthy. Your users will never see another iTunes prompt, and your service desk will get its mornings back.
Microsoft officially retired Classic Teams on July 1, 2025, and the client is no longer functional. Despite this, many organizations still have remnants of Classic Teams scattered across their Windows device estate. This is not just a cosmetic issue. Classic Teams no longer receives security updates, the per-user installation model wastes disk space, leftover shortcuts confuse users, and end-of-life software can put you out of compliance. If you have been putting off the cleanup, now is the time to remove Classic Teams from your environment.
In this post I am sharing three PowerShell scripts that handle different scenarios, from a one-off standalone removal to a fully automated Intune Proactive Remediations approach.
Why You Need to Remove Classic Teams
Even though Classic Teams stopped working months ago, there are real reasons to actively remove it rather than just leaving it behind:
Security – Classic Teams no longer receives security updates, leaving a potential attack surface on your endpoints
Disk space – The per-user installation model means Classic Teams can consume hundreds of megabytes per user profile on a device
User confusion – Leftover shortcuts and autorun entries can confuse users, especially when New Teams is already deployed
Compliance – Many organizations have policies requiring the removal of end-of-life software from managed devices
Clean device state – Leftover registry entries and autorun configurations can interfere with New Teams or cause unexpected behavior
What Gets Removed
All three scripts target the same Classic Teams components:
Teams Machine-Wide Installer – The MSI-based installer typically deployed via SCCM, GPO, or during OS deployment
Per-user Teams installations – Classic Teams installed itself per-user under %LocalAppData%\Microsoft\Teams for each profile on the device
Autorun registry entries – Both HKLM and per-user Run keys that launch Classic Teams at logon
Desktop and Start Menu shortcuts – Leftover .lnk files pointing to the old Teams client
Teams Installer folder – The C:\Program Files (x86)\Teams Installer directory
Option 1: Remove Classic Teams with a Standalone Script
If you need to remove Classic Teams from a smaller number of devices, or want to run the cleanup through SCCM, ConfigMgr, GPO, or manually, use the standalone removal script. It handles the complete removal process in a single run: stops Teams processes, uninstalls the Machine-Wide Installer via msiexec, iterates through all user profiles to remove per-user installations, cleans up registry entries and shortcuts, and validates the result.
The script creates a log file at C:\Windows\Logs\Remove-ClassicTeams.log for troubleshooting.
Option 2: Remove Classic Teams with Intune Proactive Remediations
For organizations managing devices through Microsoft Intune, the preferred approach is to use Proactive Remediations (now called Remediations in the Intune admin center). This gives you a detection script that identifies non-compliant devices and a remediation script that automatically cleans them up.
Detection Script
The detection script checks whether you still need to remove Classic Teams by scanning all common locations. If any remnant is found, it exits with code 1 (non-compliant), which triggers the remediation script. If the device is clean, it exits with code 0 (compliant).
Teams Machine-Wide Installer in both 32-bit and 64-bit uninstall registry keys
Classic Teams folder, Teams.exe, and Update.exe in each user profile
Teams desktop shortcuts across all profiles
HKLM Run entry for Teams
Remediation Script
When the detection script flags a device as non-compliant, the remediation script will remove Classic Teams and perform the full cleanup. It goes further than the standalone script by also cleaning Start Menu and Startup folder shortcuts, loading offline user registry hives to remove per-user Run entries, and removing the Teams Installer folder from Program Files.
After remediation, the script runs its own validation. If all remnants are successfully removed, it exits with code 0. If anything remains, it exits with code 1, which Intune will flag for review.
Give it a name, for example: Remove Classic Microsoft Teams
Upload Detect-ClassicTeams.ps1 as the detection script
Upload Remediate-ClassicTeams.ps1 as the remediation script
Set Run this script using the logged-on credentials to No (runs as SYSTEM)
Set Run script in 64-bit PowerShell to Yes
Assign the remediation to a device group – start with a pilot group before targeting all devices
Set the schedule – daily is recommended until the bulk of devices are cleaned up, then reduce to weekly
Logging
All three scripts write detailed logs to C:\Windows\Logs:
Remove-ClassicTeams.log
Detect-ClassicTeams.log
Remediate-ClassicTeams.log
Each log entry includes a timestamp, severity level (INFO, WARN, ERROR), and a descriptive message, making it easy to verify that the scripts successfully remove Classic Teams. This makes it straightforward to troubleshoot any issues through Intune device diagnostics or by reviewing the log files directly.
Summary: Remove Classic Teams the Right Way
Cleaning up Classic Microsoft Teams is a necessary task for any organization that has migrated to New Teams. Whether you run the standalone script through your existing deployment tools or leverage Intune Proactive Remediations for automated, ongoing compliance, these scripts give you a reliable way to get it done.
If you manage Windows devices in any kind of enterprise environment, the Secure Boot certificate expiry is a deadline you really do not want to sleep on. The Microsoft certificates that have been the foundation of UEFI Secure Boot since Windows 8 are reaching the end of their lifetime in 2026, and the clock is ticking. The first wave of expirations begins in June 2026, and if your fleet is not ready by then, devices will start losing the ability to receive boot-level security updates and to trust software signed with new certificates.
The reason this matters is not just calendar housekeeping. The whole reason we are rotating these certificates in the first place is the BlackLotus UEFI bootkit (CVE-2023-24932), a piece of malware that can survive an OS reinstall and even bypass Secure Boot itself. The 2023 certificate set is the long term answer, and you need every Windows device in your environment trusting it before the old certificates roll off.
In this post I want to walk through what BlackLotus actually is, what is happening with the Secure Boot certificates, how the two are connected (but not the same thing), and what you can practically do about it today using Intune, PowerShell, and the great work that several Microsoft MVPs have already shared with the community.
A Quick Refresher on BlackLotus
BlackLotus is a UEFI bootkit that exploits CVE-2023-24932, a vulnerability in the Windows boot manager. What makes it particularly nasty is that it loads before Windows does, which means it sits underneath every traditional security control you have in the operating system. Antivirus, EDR, even a clean reinstall of Windows will not necessarily get rid of it, because the malicious code lives in the boot path that Secure Boot is supposed to protect.
Microsoft addressed CVE-2023-24932 with a multi-phase rollout that started back in 2023 and is still in progress today. The fix is not just a patch you install. It involves updating the bootloader, revoking the trust of the vulnerable boot manager, and ultimately replacing the certificates that Secure Boot uses to decide what is allowed to run. That last part is the piece we are dealing with right now.
The Secure Boot Certificate Expiry: What Is Actually Going Away in 2026
There are three Microsoft certificates from 2011 that are baked into firmware on basically every Windows device shipped in the last decade. Here is the short version of what is going away and when:
Microsoft Corporation KEK CA 2011 – the Key Enrollment Key authority. Expires June 2026.
Microsoft Corporation UEFI CA 2011 – signs third party UEFI components and option ROMs. Expires June 2026.
Microsoft Windows Production PCA 2011 – signs the Windows boot manager itself. Expires October 2026.
The replacements are the 2023 certificate set: Microsoft Corporation KEK CA 2023, Microsoft UEFI CA 2023, and Windows UEFI CA 2023. These are the certificates Microsoft is using going forward to sign boot components, and they are also the ones that carry the BlackLotus mitigations.
How BlackLotus and the Certificate Expiry Are Connected, but Not the Same Thing
This is the part I see people mixing up the most, so it is worth being precise. BlackLotus and the certificate expiry are two different problems that share a single solution.
BlackLotus (CVE-2023-24932) is a security vulnerability. It exists because the old boot manager can be tricked into running malicious code. The fix is to revoke trust in the vulnerable boot manager and replace it with a new one signed by a new certificate.
The 2026 certificate expiry is a lifecycle event. The 2011 certificates were always going to expire eventually. June 2026 is simply when their validity runs out.
Where they meet is the 2023 certificate set. Microsoft is using this rotation as the opportunity to also roll out the BlackLotus mitigations at the same time. So when you update a device to trust the 2023 certificates, you are doing two things in one go: you are getting it ready for life after the 2011 certificates expire, and you are closing the BlackLotus attack path.
If you do nothing, the consequences are not the same on both sides either. A device that never gets the 2023 certificates will still boot after June 2026. It just will not be able to install future Secure Boot updates, will not trust new third party UEFI components, and will remain exposed to BlackLotus style attacks. That is not a place you want to be.
How to Fix It
The good news is that the actual remediation is mostly registry plumbing. Microsoft ships the certificate update logic inside the cumulative update, and you opt a device in to receiving the new certificates by setting a value under HKLM\SYSTEM\CurrentControlSet\Control\Secureboot. Specifically, the AvailableUpdates DWORD controls which steps are applied. The current recommended value is 0x5944, which performs the full sequence: it adds the 2023 KEK to KEK, adds the 2023 DB entries, updates the boot manager, and updates DBX. After the registry value is set, the Microsoft\Windows\PI\Secure-Boot-Update scheduled task is what actually does the work, usually across one or more reboots.
At a high level the process for any device looks like this:
Make sure the device is fully patched. Anything earlier than the July 2024 cumulative update is not going to do you any favors.
Confirm that diagnostic data is set to at least Required, because the certificate update flow uses it.
Set AvailableUpdates to 0x5944 under the Secureboot key.
Trigger the Secure-Boot-Update scheduled task (or wait for it to run on schedule).
Reboot. Sometimes more than once. Verify by checking the UEFICA2023Status registry value, which should eventually read Updated.
Validate by querying the actual Secure Boot databases with PowerShell to confirm the 2023 certificates are present.
The cleanest way to do this at scale is with Intune Remediations. You build a detection script that reports back whether a device already has the 2023 certificates installed, and a remediation script that sets the registry values and kicks off the scheduled task. That gives you a single dashboard view of your whole fleet and lets you target the long tail of devices that need a nudge.
Things That Will Trip You Up
OEM firmware. Some older devices will need a UEFI/BIOS update from the manufacturer before they can accept the 2023 certificates. If you have a fleet that is more than four or five years old, plan on doing a firmware audit as part of this project.
Diagnostic data. If telemetry is set to Off (Security on Enterprise), the certificate update flow will not run. You need at least Required.
Dual boot and custom signed bootloaders. If you are running anything that depends on the 2011 UEFI CA (some Linux distributions, some hardware vendors’ utilities), test before you push the update broadly.
Virtual machines. Hyper-V Generation 2 VMs and Azure VMs are also affected. Do not forget the server side of the house.
Monitor first, remediate second. Microsoft’s recommended approach is to start with a monitor-only Intune Remediation that just reports status, so you understand the scope of the problem before you start changing anything.
Reference Articles From the Community
I am far from the first person to write about this, and several Microsoft MVPs have already done excellent deep dives that are well worth your time. If you are about to start this project, read these first:
If you would rather start from working code than write your own from scratch, several community members have published their detection and remediation scripts on GitHub. Always read through any script before deploying it in your environment, but these are good starting points:
ThomasMarcussen/SecureBoot_2026_UpdateScripts_v1.0 – my own toolkit. Four scripts: a readiness detection script, a remediation script that applies the registry and telemetry settings, a CSV reporting script, and an OEM firmware readiness check. Designed to be deployed via Intune Remediations or Configuration Manager.
markorr321/Secure-Boot – Detection, remediation, and throttle bypass scripts for Intune, with a focus on enterprise wide compliance and the BlackLotus mitigation.
The 2026 Secure Boot certificate rotation is one of those rare projects that touches every Windows device in your environment, including the ones nobody has thought about in years. It is also one of those projects that is going to be infinitely easier if you start now than if you wait until May 2026 and try to do it under pressure. The combination of Intune Remediations, the registry-based opt-in flow, and the great scripts already shared by the community means there is no real reason to put it off.
Start with monitoring so you know what you are dealing with, fix any firmware and telemetry prerequisites, and then roll out the remediation in waves. Closing the door on BlackLotus is a nice bonus on top of staying ahead of the certificate expiry, and your future self (and your security team) will thank you.
Introduction: The Challenge of Managing Microsoft Teams Rooms
Microsoft Teams Rooms (MTR) are purpose-built devices that bring seamless Teams meetings into physical conference rooms. However, if you’re an IT admin or consultant trying to manage these devices with Microsoft Intune, you may have already hit a major wall: you can’t deploy standard applications like Win32 or MSI packages.
In this post, I’ll walk you through:
Why app deployment fails on MTRs
How to use Intune Proactive Remediation Scripts to install apps anyway
A real-world script-based workaround you can implement today
This article is especially useful for IT administrators, Microsoft 365 consultants, and organizations managing MTR on Windows devices using Microsoft Intune.
What Are Microsoft Teams Rooms (MTR) Devices?
Microsoft Teams Rooms are specialized endpoints running Windows or Android, designed to facilitate video conferencing in meeting spaces.
This article focuses on MTR on Windows, which:
Boots into a kiosk-like shell
Uses a locked-down local user account (usually “Skype”)
Automatically launches the Teams Rooms app
Is managed differently from typical Windows endpoints
Why Are MTRs So Locked Down?
Because they’re designed to do one thing very well: run meetings reliably and securely. That means:
Minimal background processes
No user distractions
Reduced vulnerability footprint
Unfortunately, this also means limited support for app deployment using traditional Microsoft Intune methods.
Why Standard App Deployment Doesn’t Work on MTR
Let’s quickly review how app deployment in Intune normally works:
You upload a Win32 or MSI app
Intune pushes it to the device
The app installs silently in the background
But MTRs are a special case:
Issue
Description
Kiosk Shell
MTR devices run a locked-down shell that prevents user interaction.
Limited Admin Access
The logged-in “Skype” user doesn’t have full local admin rights.
Silent Installs Often Fail
Even SYSTEM-context installs can hang or fail silently.
Win32 App Deployment Not Supported
MTRs are excluded from full app deployment via Intune.
TL;DR: Intune treats MTRs like they’re manageable—but for apps, they’re basically off-limits.
What Can You Manage on MTR with Intune?
Feature
MTR Support?
Enroll in Intune
✅ Yes
Configuration Profiles (Wi-Fi, Certificates)
✅ Yes
Compliance Policies
✅ Yes
PowerShell Scripts
⚠️ Limited
Win32/MSI App Deployment
❌ Not Supported
Store App Deployment
❌ Not Supported
Remediation Scripts
✅ Yes — this is our workaround!
The Workaround: Use Proactive Remediation Scripts
What Are Proactive Remediations in Intune?
Proactive Remediations are part of Endpoint Analytics in Microsoft Intune. They allow you to:
Detect issues on endpoints (e.g., missing apps or settings)
Run scripts in the SYSTEM context to remediate them
And because these scripts run as SYSTEM, they can bypass the user restrictions imposed by the MTR shell. That’s the secret sauce here.
Step-by-Step: Deploy Apps to MTR Devices Using Remediation Scripts
Step 1: Choose an Application
Pick an application with a silent installer. Examples include:
Zoom Rooms Plugin
Custom certificate tools
Remote support agents
Pro tip: Avoid apps that require UI interaction or restart the system.
Step 2: Host the Installer
Since you can’t upload Win32 apps, host the installer externally:
Azure Blob Storage with SAS token
SharePoint Online
A secure HTTPS server
Step 3: Write the Detection Script
This script checks whether the app is already installed.
For complex applications, consider a manual install window, or coordinate with the OEM.
Alternatives to Intune Remediation Scripts
Method
Notes
Manual Deployment
Good for one-off fixes
OEM Management Tools
Logitech Sync, Poly Lens, etc.
Group Policy
Works for Hybrid AAD Join MTRs
Teams Pro Management
Useful for Teams config, not apps
Conclusion: MTR App Deployment is Possible—With the Right Tools
Deploying applications to Microsoft Teams Rooms using Intune isn’t supported natively—but that doesn’t mean it’s impossible. With a bit of scripting and smart use of Proactive Remediation, you can achieve automated, scalable, and relatively safe application installs.
This method:
Uses supported Intune features (Endpoint Analytics)
Microsoft is offering clients an updated Intune Connector for Active Directory and this connector is what Intune will be using starting from Intune 2501. This connector uses Windows Autopilot to deploy devices that are Microsoft Entra hybrid joined.
The updated version of the connector aims to enhance security and will be using a Managed Service Account (MSA) instead of a SYSTEM account. Customers currently using the old version of the Intune Connector for Active Directory (that uses the local SYSTEM account) should know that this connector will no longer have support, starting in late June 2025.
Therefore, it’s important to start planning for the update because once support ends, enrollments from the old connector build will no longer be acceptable.
Key Features of the Intune Connector
The main role of the Intune Connector for Active Directory is to join computers to an on-premises domain and add them to an organizational unit (OU) allowing for central management and policies.
The Intune Connector also places joined computers within a specific OU, something that helps establish granular control over device configurations and settings. Furthermore, customers will also benefit from hybrid enrollment of devices which offers the convenience of device management by both on-premises AD and Intune.
The Intune Connector plays a key role in leveraging Windows Autopilot to set up and deploy devices. And for all those already using Autopilot, they will know that this feature will have a huge impact in making life easier for customers by simplifying deployment processes.
In addition to all the above, the Intune Connector ensures that the policies defined in both AD and Intune continue to enforce, thus offering compliance and consistency.
Why Switch to Managed Service Accounts?
As the new version of the Intune Connector for Active Directory makes the change to using Managed Service Accounts, it’s important to understand why they are important. The use of MSAs will enable the new connector to follow least privilege principles and thereby strengthen security.
With MSAs, clients enjoy managed domain accounts that have automatic password management. They are also generally permissible with privileges to perform their duties. With such measures in place, there is a reduction in the risk of compromise, intentional or otherwise.
You can only use standalone MSAs on one domain-joined machine and can thus only access resources within that domain. MSAs can easily and securely run services on a computer while simultaneously maintaining the capability to connect to network resources as a specific user principal. When taking all of this into account, it’s not difficult to see why Microsoft views the use of MSAs as better for the Intune Connector moving forward.
Securing The Future
The security update to the Intune Connector for Active Directory fits in seamlessly with Microsoft’s Secure Future Initiative. Microsoft is uniquely ideal within the tech industry to play a key role in safeguarding the future for all its clients.
As such, the tech giant is taking a comprehensive approach to cybersecurity with a key focus on certain areas that are critical to enhancing security across the board. There continues to be substantial progress in these areas:
identity and secret protection
Updates to Entra ID and Microsoft Account (MSA) are live for both public and U.S government clouds to generate, store, and automatically rotate access token signing keys using the Azure Managed Hardware Security Module (HSM) service.
Microsoft has continued to drive broad adoption of its standard identity SDKs, which provide consistent validation of security tokens. As a result, we now see this standardized validation covering more than 73% of tokens issued by Microsoft Entra ID for Microsoft owned applications.
Tenant Protection and Isolation of Production Systems
A full iteration of app lifecycle management for all production and productivity tenants has been performed. This has resulted in the elimination of 730,000 unused apps. Additionally, because of the elimination of 5.75 million inactive tenants, the potential cyberattack surface has become significantly smaller.
Not only that, but a new system to streamline the creation of testing and experimentation tenants with secure defaults is available. It also enforces a strict lifetime management.
Protect networks
More than 99% of physical assets on the production network record in a central inventory system. This enriches asset inventory with ownership and firmware compliance tracking. Virtual networks with backend connectivity are isolated from the Microsoft corporate network, as well. They are additionally subject to complete security reviews to reduce lateral movement.
With the expansion of platform capabilities such as Admin Rules to ease the network isolation of platform as a service (PaaS) resources such as Azure Storage, SQL, Cosmos DB, and Key Vault, Microsoft has made it easier for customers to secure their own deployments.
Protection of engineering systems
We are now experiencing more consistent, efficient, and trustworthy deployments because 85% of production build pipelines for the commercial cloud are now using centrally governed pipeline templates.
Other notable changes include shortening the lifespan of Personal Access Tokens to seven days, disabling Secure Shell (SSH) protocol access for all Microsoft internal engineering repos, and massively reducing the number of elevated roles with access to engineering systems.
Moreover, proof of presence checks for critical chokepoints in software development code flow are now available.
THREAT DETECTION AND MONITORING
A lot of progress continues toward the goal of pushing all Microsoft production infrastructure and services to adopt standard libraries for security audit logs. Additional efforts include those to emit relevant telemetry and to retain logs for a minimum of two years.
A good example is the establishment of central management and a two-year retention period for identity infrastructure security audit logs, including all security audit events throughout the lifecycle of current signing keys. Add to this the fact, that no less than 99% of network devices now have enablement with centralized security log collection and retention.
Accelerate response and remediation
We can now observe improved time to mitigate for critical cloud vulnerabilities because of the recent process updates across Microsoft. Customers will also appreciate the greater transparency provided by the publishing of critical cloud vulnerabilities as common vulnerability and exposures (CVEs). This is especially helpful even when there are no direct customer action requirements.
In addition to this, the establishment of the Customer Security Management Office (CSMO) will go a long way to improve public messaging and customer engagement for security incidents.
Required Permissions
As we look at the new version of the Intune Connector for Active Directory, one of the key areas that can help us distinguish this new connector from its previous version is doing a comparison of account permissions:
Create Computer Object Rights (required for hybrid Autopilot scenario)
Unlimited if connector is on the same machine as domain controller. Delegation is required if connector is not on the domain controller.
Explicit delegation required
Pre-requisites
As with any product or application, there are certain requirements that all customers intending to use the Intune Connector for Active Directory will need to meet. So, before proceeding with the set up of the new Intune Connector, you need to verify that you can meet all the pre-requisites. These requirements include:
The computer you’re installing Intune Connector for Active Directory to must be running Windows Server 2016 or later.
You should also verify that you have .NET Framework version 4.7.2 or later installed.
To facilitate communication with Microsoft’s Intune service, the server hosting the Intune Connector should have internet access.
The Intune Connector will need standard domain client access to domain controllers.
Customers must verify that they have a Microsoft Entra account with Intune Service Administrator permissions, as this is a requirement to download and manage the connector.
Also needed will be a domain account with local administrator privileges and the ability to create msDS-ManagedServiceAccount objects.
Verify that the Windows Server configuration aligns with the Desktop Experience and, for versions 2019 or earlier, install the Microsoft Edge browser manually before connector setup.
The Microsoft Entra account should have an Intune license assigned to it.
For those that will be using Hybrid Azure AD Join, they should check that it’s configured via Azure AD Connect tool.
Lastly, the Intune Connector machine must have the appropriate delegated permissions to create computer objects in the target OU.
Setting Up The Connector
To setup the new Intune Connector for Active Directory, you need to start by uninstalling the existing connector. You can do this by uninstalling from the Settings app on Windows and then, uninstalling using the ODJConnectorBootstrapper.exe (select Uninstall). With that done, you can download the connector build from Intune and then perform the installation (as described in detail in my previous blog).
Configuring organizational units (OUs) for domain join
Customers should be aware that by default MSAs won’t have access to create computer objects in any Organizational Unit (OU). Thus, if you intend to use a custom OU for domain join, you’ll need to update the ODJConnectorEnrollmentWiazard.exe.config file. Fortunately, this is something you can do before or after connector enrollment:
Update ODJConnectorEnrollmentWizard.exe.config:
Default location is “C:\Program Files\Microsoft Intune\ODJConnector\ODJConnectorEnrollmentWizard”
Add all the OUs required in OrganizationalUnitsUsedForOfflineDomainJoin
OU name should be the distinguished name.
You need to be aware that the MSA is only granted access to the OUs configured in this file (and the default Computer’s container). This means that if any OUs are removed from this list, completing the rest of the steps will revoke access.
Open ODJConnectorEnrollmentWizard (or restart it if it was open) and select the “Configure Managed Service Account” button.
If successful, a pop up will appear showing success.
Using the Intune Connector with multiple domains
For those who are already using the connector with more than one domain, they will be able to use the new connector by setting up a separate server per domain and installing a separate connector build for each domain.
Configuring the connector
Customers should install the Intune Connector for Active Directory on each of the domains that they want to use for domain join. In case a second account redundancy is required, customers must install the connector on a different server (in the same domain).
Go through the connector configuration steps meticulously and verify that everything has been done correctly. Also check that the MSA has the appropriate permissions on the desired OUs.
Verify that all connectors are present in the in the Microsoft Intune admin center (Devices > Enrollment > Windows > under Windows Autopilot, select Intune Connector for Active Directory) and that the version is greater than 6.2501.2000.5.
Configure Domain Join profile
Follow the steps given below.
Start by creating a domain join profile for each domain that you want to use for hybrid joining devices during Autopilot.
Target the domain join profile to the appropriate device groups.
Wrap Up
The Intune Connector for Active Directory provides an essential tool for managing hybrid devices in an Intune environment. With its many available features, customers will get centralized management capabilities for their environments thus allowing businesses to operate more efficiently.
But, with security having been a big concern for many, Microsoft has made the switch to using a Managed Service Account instead of a SYSTEM account. This action has effectively tightened security in customers’ environments. Going forward, the previous version of the Intune Connector will no longer be supported. Therefore, if you are yet to download and set up the new Intune Connector for Active Directory, the sooner you do the better.
As hackers get more daring and attacks more sophisticated, organizations need to continuously look at how they can enhance their security protocols. Concerning statistics show that the cost of cybercrime, already well into the trillions, could surpass $23 trillion by 2027.
Faced with the reality that cybercrime is unquestionably on the rise, a proactive approach is now necessary to lessen the risk of attack. One of the best ways to achieve that is by utilizing the indicators that Microsoft Defender for Endpoint has.
By using these, IT admins can preemptively block malicious entities and prevent them from accessing the organization’s resources. With this in mind, the focus for this blog will be to provide you with detailed information concerning indicators.
Explaining Microsoft Defender for EndpointIndicators
Indicators provide IT administrators with certain data that can help identify individuals with nefarious intentions. This data can enable organizations to pinpoint malicious IP addresses, untrusted certificates, suspicious URLs, and more. Moreover, an organization can then set up its indicators accordingly thereby enabling a proactive approach to dealing with threats.
In Microsoft Defender for Endpoint, the indicators operate by applying specific rules to endpoint devices. These rules will use predetermined criteria to govern whether or not devices allow or block certain types of activity. A good example of this would be blocking all traffic to and from IP addresses that have been determined to be carrying out malicious activities.
Importance of Indicators
Indicators play a major role in improving organizational security by enabling businesses to take a proactive approach and block malicious actors before they can do any damage. And if an incident does occur, indicators will help you to quickly identify threats and implement a swift response. Additionally, using indicators allows you to customize your security to effectively meet the specific needs of your organization.
These tools are invaluable for intercepting attacks. Once it has been determined that an attack is ongoing, the malicious entities can be immediately blocked therefore limiting the impact from affecting the entire organization.
Types of Indicators with Microsoft Defender for Endpoint
In this section, we’re going to look at four types of indicators that Microsoft Defender for Endpoint supports. These indicators are essential for responding to different threats.
IP ADDRESS INDICATORS
This type is used for preventing access to IP addresses suspected of malicious activities. Once a specific IP address has been determined, an action is implemented that blocks all devices within an organization from connecting to that IP address. To do this, you need to navigate to Microsoft 365 Defender portal > Settings > Indicators. Next, you’ll need to add a new indicator and then select IP Address. With this done, you can now set up the action as Block and specify devices affected.
URL AND DOMAIN INDICATORS
These indicators are used to block access to malicious domains and phishing sites. After you’ve specified the URL concerned, you can then implement an action blocking all devices within your organization from connecting to that particular URL. Microsoft Defender for DNS is recommended if you want to have DNS-level protection.
FILE HASH INDICATORS
These will enable you to block access to known malicious files based on their hash (MD5, SHA-1, or SHA-256). You can use Advanced Hunting in Microsoft Defender or third-party threat intelligence sources to get the necessary file hashes.
CERTIFICATE INDICATORS
With this fourth type, you can block executables signed by untrusted certificates.
How to Set Up Microsoft Defender for Endpoint Indicators
The process of setting up indicators is not an overly complicated one. You start by navigating to the Microsoft 365 Defender portal where you need to sign in with your administrator account. Following this, you can then begin creating an indicator.
CREATION PROCESS
Head over to Settings > Indicators.
Click on Add Indicator.
Select the type of indicator required.
Provide the necessary information:
Indicator Type: IP Address, URL, File Hash, or Certificate.
Action: Block or Allow
Scope: Specify which devices/groups will be affected by the action to be performed.
Expiration Date: Provide an expiration date for temporary indicators (this is optional).
Description: For documentation purposes, a description will be required.
COMPLETING THE PROCESS
After you’ve completed the creation process, you can click Create to save the indicator. You’ll also have the capability to monitor the indicator’s impact by taking advantage of Reports and Advanced Hunting. Advanced Hunting offers a powerful, query-based tool that helps you track threats and evaluate how effectively the indicators are working. Hunting works best if you use filters to get more specific results, as well as if you save and reuse queries during the monitoring processes.
Using Indicators Effectively
Like most other apps and services, you can’t set up indicators once and forget about them. You need to constantly review them and update them when necessary so your security remains strong.
As already mentioned, some indicators are temporary and so you need to remember to set expiration dates for these so that you avoid cluttering your environment. Not only that, but you should ensure that indicators are targeting the specific devices or groups they are created for.
Furthermore, IT admins should continuously evaluate the information obtained from Advanced Hunting and reports so that they are always aware of whether or not the indicators are performing to expectations. And then to enhance your security posture even more, you can combine indicators with Conditional Access policies for better results.
Wrap up
The staggering figures that we hear being thrown around when discussing cybercrime are almost beyond belief. But, the reports about cybercrime provide a lot of insights that enable organizations to take the necessary steps to improve their security. Leveraging the indicators available in Microsoft Defender for Endpoint goes a long way in securing your network and reducing the risk of attack. If applied correctly and used as recommended, indicators can be some of the best tools in an organization’s cybersecurity arsenal.
Windows Autopilot is a set of technologies that is built to simplify the process of deploying, setting up, and configuring new devices. By using this technology, users can avoid going through the traditional imaging process and save countless productive hours.
However, Autopilot is not without its faults. One of the more common instances of running into problems occurs when using Managed Installer policies with Win32 app deployment during the Autopilot device preparation phase. As an issue that can cause quite a headache, this blog will help you better understand this problem as well as provide you with solutions for addressing it.
Windows Autopilot Explained
Windows Autopilot gives organizations a solution that eliminates the challenges that come with building, maintaining, and generally applying custom images. IT admins can use this service to set up new desktops to join pre-existing configuration groups and apply profiles to the desktops. What this does is give users the opportunity to access fully functional desktops from their first login.
Importance of Managed Installer Policies
Managed Installer policies are useful for dictating which applications can be installed on your organization’s devices. Once enabled, Managed Installer uses a special rule collection in AppLocker to designate binaries. These are trusted by your organization as an authorized source for application installation.
The problem IT admins will run into is that currently Windows Autopilot device preparation doesn’t guarantee the delivery of the Managed Installer policy before trying to install Win32 apps. Because of this, you may end up with deployment failures during the App Installation phase of Autopilot.
INVESTIGATING THE PROBLEM
A regular deployment scenario follows a series of steps that begins with the launch of the Autopilot Device Preparation process. Following this, Win32 apps are then scheduled for installation as part of the device preparation policy.
At this point, the Managed Installer policy won’t yet have been installed. The reason why you may see the Win32 app installations failing is because the policy is set up to block apps from unverified sources.
WHAT TO EXPECT With Windows Autopilot
One of the things you can expect to see because of this issue is the Autopilot deployment process stopping at the app installation phase. You will also get error messages showing application deployment failures. Another thing to expect is that deployment reports will show failed Win32 app installations. Lastly, end-users may receive incomplete or improperly configured devices.
How has Microsoft addressed the issue?
Microsoft is fully aware of the issue at hand and has offered some recommendations that provide a temporary solution. IT admins can start by removing Win32 apps from all Autopilot device preparation policies.
Also, devices should be left to complete Autopilot and reach the desktop. Furthermore, Win32 apps and Managed Installer policies need to be applied after the user gets to the desktop.
In October 2024, Microsoft announced service release 2410 that introduced some new changes that will see Win32 and Microsoft Store apps being automatically skipped during device preparation and instead continuing to the desktop. To implement these solutions, you’ll need to follow the steps below:
AUDIT YOUR EXISTING Windows AUTOPILOT DEVICE PREPARATION POLICIES
For this process, organizations need to identify all device preparation policies configured in Intune. You’ll also need to verify any Win32 apps included in these policies. With all this done, make sure to document these apps as well as their purpose.
REMOVE WIN32 APPS FROM DEVICE PREPARATION POLICIES
Navigate to Microsoft Intune and edit your existing device preparation policies. Then, proceed to remove all Win32 apps from these policies. Once these tasks are complete, save and apply the updated policies.
MONITOR DEPLOYMENT STATUS
Use the updated policies to deploy your devices. You can track the progress of this process using the Autopilot Deployment Report. Make sure that you check that devices reach the desktop without app installation failures.
DEPLOY WIN32 APPS POST-ENROLLMENT
Once a device has reached the desktop, you can reassign your Win32 apps to deploy. You’ll need to use Required or Available for enrolled devices deployment settings in Intune. The success of app installation can be monitored using Intune’s reporting tools.
Alternative Options
In addition to the recommendations by Microsoft, there are other options that organizations can consider to address the above-mentioned issue. These include:
PRE-STAGE CRITICAL APPLICATIONS
One thing that organizations can consider doing is pre-staging key apps that are required to be on the device at deployment. This can be done using offline methods such as:
Injecting apps into the Windows image using tools like OSDCloud or Configuration Manager.
App deployment using PowerShell scripts post-Autopilot.
CONDITIONAL ACCESS AND APP PROTECTION POLICIES
If your organization is worried about security, then using Conditional Access policies will help block access to corporate resources until the necessary apps have been installed. An example of this would be enforcing Conditional Access policies to ensure that non-compliant devices are prevented from accessing the organization’s resources.
Optimize Enrollment Status Page (ESP) Configuration
The Enrollment Status Page plays a key role in controlling app deployment during Windows Autopilot. This is done by dividing the deployment into several stages, thus allowing you to prioritize the apps you consider more important.
USER VS DEVICE ASSIGNMENTS
With device-based deployments, there is a greater likelihood of encountering problems with Managed Installer policies. Because of this, it’s worth considering changing your app deployment from device-based to user-based assignments.
PILOT AND TEST NEW CONFIGURATIONS
Before rolling out new deployment configurations to the entire organization, it’s always wise to test them on a small pilot group. Doing it this way gives you the opportunity to identify problems and address them early.
Monitoring and Troubleshooting
The availability of Autopilot Deployment Reports in Microsoft will provide organizations with key information concerning the deployment process. This allows them to evaluate skipped apps, failed deployments, and device readiness status.
Additionally, organizations should also use Intune Diagnostics and Event Viewer to analyze deployment logs. By evaluating these logs, IT admins can pinpoint specific app failures and then determine whether they’re related to the Managed Installer policy.
If all else fails and your deployment issues are still yet to be resolved, you’ll have the option of reaching out to Microsoft Support for any help you need. Alternatively, engaging with the Intune community on X may yield assistance from those who have dealt with the issues you may be confronting.
Wrap Up
Windows Autopilot offers organizations a powerful tool to help simplify the process of deploying and setting up devices. Processes are made simpler and faster, thus helping businesses operate more efficiently. And although there may be issues with Wind32 app deployment during device preparation, there are ways to deal with it.
But, in addition to the workaround, we can look forward to Microsoft developing a more permanent solution to this challenge. Updates are sure to be forthcoming and we will be keeping an eye on what Autopilot will bring us next.
New features and updates are paramount to improving the functionality of the various devices and applications that businesses use. This is necessary, especially if companies expect high levels of performance. It’s also essential as the tasks that we deal with grow more complex.
Not only do companies want to maintain performance but they also need tech companies to address any existing issues. As a result, organizations like Microsoft will offer many new features. These updates are for services like Microsoft Intune and Windows 365.
Because of the updates, released in 2024, overall user experiences will greatly improve. Let’s discuss the recent additions and explore how they might help elevate, simplify, and improve your business operations.
Improvements to Microsoft Intune
2024 has been a year with a lot of innovation from Microsoft across its various products and services. Plenty of this effort prioritizes Microsoft Intune improvements, bringing us features such as:
New capabilities for Windows Autopilot
Windows Autopilot is a service that makes the device deployment process faster and less complex. Companies benefit immensely from Autopilot’s ability to do away with the labor-intensive process previously necessary to provision new devices. And, Microsoft has additional service improvements to share.
Earlier this year, an announcement introduced an exciting new release – device preparation. This brilliant new innovation will enable the accommodation of more devices and delivery of more efficient results. Moreover, it will allow for the provisioning of cloud instances such as Windows 365.
Still, Microsoft ensures customers that the original, existing Windows Autopilot architecture is still in place. Because of this, you still have access to all your favorite features. IT admins can now enjoy a faster and simpler addition of groups to devices. This is due to enrollment time grouping, which replaces dynamic grouping. This creates a process that assigns app policies and scripts to devices more efficiently.
NEW SECURITY BASELINE
A key reason for updating devices and applications is to strengthen security and address vulnerabilities. Companies want to make sure that their security measures can stay ahead of the methods being employed by cybercriminals.
Hence the introduction of an update to the Microsoft Defender for Endpoint security baseline. These one-click collections of policies can be applied to devices (and device groups) in Intune. They also provide you with a way to configure all your organization’s devices with the same security policies.
Setting up your security measures in this way makes it’s easier to maintain the same security levels across the entire enterprise. This particular update offers a much better way of implementing the configuration recommendations made by the Microsoft Defender for Endpoint team. Furthermore, because it’s based on the Windows unified settings platform, you also get:
Quicker turnaround for updates.
Improved reporting, including per-setting status reports.
Assignment filter support.
Improved UI.
Consistent names across Intune.
Platform single sign-on (SSO) has arrived for macOS device enrollment
Signing in to multiple applications and websites using different credentials can be a tedious task. It can also be difficult for many people to keep up with all their sign-in information and passwords. This is why Platform Single Sign On (SSO) is a wonderful solution for streamlining the authentication process.
Because of how local account credentials synchronize with an individual’s IdP, one will only need to log in once. Platform SSO can help your company improve its security posture and enhance productivity.
Owing to the integration of SSI with Apple’s Secure Enclave technology, your organization can enable phishing-resistant, hardware-bound, passwordless authentication on Mac through Intune. In addition to better security, end-users can enjoy a less complex and faster out-of-the-box experience. This is possible because all they’ll need to set up their devices are their Entra ID passwords.
End-users also get to work more efficiently. This SSO experience, unique to Intune, enables them to sign in to their Outlook, Teams, and other Microsoft 365 apps simultaneously.
Installation of macOS apps on demand via Intune
Microsoft has done plenty of work to develop systems that can provide more capable Mac management. Intune has made providing IT admins and end-users a better, more efficient platform one of its key objectives. And one of the main reasons they’ve been able to achieve that is by leveraging feedback from customers.
Of note among the latest developments, are options that admins can provide to users for downloading unmanaged applications. These specifically apply in PKG and DMG format via the Intune Company Portal app.
Furthermore, to reduce the reliance on line-of-business app workflow or third-party tools to deploy optional applications, Intune added the “available” assignment type to the well-known “required” type. As one of the most requested features by Mac device administrators, this should be a well-received development as it will help both end-users and admins save time.
Expanded support for Microsoft Managed Home Screen
Microsoft Managed Home Screen (MHS) is an enterprise launcher application that enables IT admins to customize their devices and restrict the capabilities that a user can access. If you configure in multi-kiosk mode in Intune, MHS launches automatically as the default home screen on the device. This customizable launcher serves as a key tool for IT admins to better manage devices. It also ensures that users are performing at the expected levels.
As organizations provide users with increasingly more powerful devices, they need to make sure that business operations improve accordingly. The availability of Managed Home Screen is expanding from just user-less kiosks or shared devices to corporate-owned, fully managed devices associated with a specific user as well. As a result, this means capabilities are will extend to a wider range of use cases and applications.
BitLocker RECOVERY KEY
Having access to a BitLocker recovery key allows you to unlock an Intune-enrolled PC if you have the misfortune of forgetting your sign-in password and getting locked out. The stored recovery key is accessible from the Intune Company Portal website. It’s also accessible in the Intune Company Portal app.
Without this key, users would typically need to contact the Help Desk for assistance. As one can imagine, it’s easy to see why this option is better. It offers greater support to users while lightening the load on IT professionals.
Going forward, this update will enable end-users to access their BitLocker recovery key directly from the Company Portal website. Because of this, your organization can expect to benefit from a more intuitive and streamlined path to recovery.
This should also help improve productivity because end-users won’t need to wait for the delays that sometimes occur while waiting for IT support to assist them. And with IT having this task taken care of for them, they will have more time to dedicate to more productive endeavors.
CORPORATE IDENTIFIERS
This feature aims to verify that corporate devices are labeled as corporate-owned as soon as they enroll. It does so by adding their corporate identifiers ahead of time in the Microsoft Intune admin center.
For businesses, corporate device management provides you with more capabilities than that for personal devices. This new change will help organizations restrict the application of the corporate-owned devices label only to authorized devices.
Adding corporate identifiers to Intune requires you to upload a file of corporate identifiers in the admin center or enter each identifier separately. Also important to note is the fact that you don’t need to add corporate identifiers for all deployments. During enrollment, Intune automatically assigns corporate-owned status to devices that join to Microsoft Entra via:
Device enrollment manager account (all platforms)
An Apple device enrollment program such as Apple School Manager, Apple Business Manager, or Apple Configurator (iOS/iPadOS only)
Windows Autopilot
Co-management with Microsoft Intune and group policy (GPO)
Azure Virtual Desktop
Automatic mobile device management (MDM) enrollment via provisioning package
Knox Mobile Enrollment
Android Enterprise management:
Corporate-owned devices with work profile.
Fully managed devices.
Dedicated devices.
Android Open Source Project (AOSP) management:
Corporate-owned user-associated devices
Corporate-owned userless devices
Google Zero Touch
Windows 365 Cloud PC security baseline updates
From the new, additional features and updates to Microsoft Intune, it’s clear to see that increasing efficiency matters. Strengthening security is also of utmost importance. And the same applies here.
Configuring security settings can often be a complex, time-consuming task that few will enjoy especially if you are still a novice. These deployed policy templates with Intune aim to establish Microsoft Security–recommended settings are central to the security strategies employed by Intune.
To ensure that you get the most from these measures, Intune has set it up such that these baselines can be tailored to your unique needs. Additionally, this particular update requires you to manually update your customizations, if any, from the previous baseline. This baseline, which comes highly recommended, will also give you:
Faster deployment of baseline version updates
Improved user interface and reporting experience (such as per-setting status reports)
More consistent naming across the Intune portal
Elimination of setting “tattooing”
Ability to use assignment filters for profiles
New updates and features for Windows 365
Similar to Microsoft Intune, Windows 365 has also introduced several updates to the Cloud PC service. Some of these include:
ADDITIONS TO DEVICE MANAGEMENT CAPABILITIES
Update
What it offers
Windows 11 Cloud PCs now support EN-NZ
As of September 2024, Windows 11 Cloud PCs now support EN-NZ.
Support for symmetric NAT with RDP Shortpath
The goal is to develop an RDP Short path in Windows 365 such that it can support setting up an indirect UDP connection using Traversal Using Relays around NAT (TURN) for symmetric NAT. Most are probably aware that TURN is a widely accepted standard for device-to-device networking for low latency, high-throughput data transmission.
Uni-directional clipboard support is now generally available
With service release 2407 in July 2024, came the release of uni-directional clipboard support into general availability.
Closing port 3389 by default for newly provisioned and reprovisioned Cloud PCs
Going forward, expect to find the inbound port 3389 closed by default. This update has come about as a means to further safeguard your Windows 365 environment.
Chroma subsampling default change to 4:2:0
This change has been made to help reduce monitor support issues. The Windows 365 service will now default to the chroma subsampling at 4:2:0. instead of the previous 4:4:4.
Windows 365 Boot and Windows 365 Switch now support battery status redirection
In a move that should be welcomed by users, Windows 365 Boot and Windows 365 Switch will now offer support for battery status redirection. Therefore, you can now view your local PCs battery status on a Cloud PC.
Upgrade Windows 365 licenses in Microsoft admin center
All clients with Modern Microsoft Cloud Agreements can now upgrade their existing Windows 365 licenses in the Microsoft Admin Center.
New Windows 365 Cloud PC images available in the gallery
As of May 2024, you can now access new Cloud PC gallery images for Windows 10 and Windows 11. These improved images have harmonized optimizations with Windows 365 apps images for better policy management: Win 10 Enterprise Cloud PC: 21H2, 22H2,Win 11 Enterprise Cloud PC: 21H2, 22H2, 23H2
Manage redirections for Cloud PCs on iOS/iPadOS devices
The Intune admin center can now be used to handle redirections for iOS/iPadOS users who access their Cloud PCs using Microsoft Remote Desktop and Windows App.
DEVICE SECURITY UPDATES
Update
What it offers
Session lock experience configuration for single sign-on
This new update offers clients the ability to configure the remote session lock experience when single sign-on (SSO) is enabled between the default disconnect behavior and showing the remote lock screen. Enabling SSO allows you to use passwordless authentication and third-party Identity Providers that federate with Microsoft Entra ID to sign in to your Cloud PC. This tool offers an SSO experience when authenticating to the Cloud PC and inside the session when accessing Microsoft Entra ID-based apps and websites.
Windows 365 support for Microsoft Purview Customer Key
Windows 365 clients are also being given a feature that supports the encryption of Cloud PCs by setting up Microsoft Purview Customer Key.
Customer Lockbox
With service release 2407 is new Windows 365 Government support for Microsoft Purview Customer Lockbox. The Customer Lockbox prevents Microsoft from accessing your content without explicit approval. This feature gets you integrated into the approval workflow process that Microsoft uses thereby restricting access to your content only to authorized requests.
Single sign-on Windows 365 clients authentication change
Single sign-on for Windows 365 is switching to the use of the Windows Cloud Login Entra ID cloud app for Windows authentication. This change will begin with the Windows and Web clients.
FQDNs removed from requirement list
Several of the required FQDNs have in the past been moved to the *.infra.windows365.microsoft.com wildcard FQDN. This move reduces the initial configuration requirements and the change rate of connectivity requirements. As of May 2024, the old FQDNs have been removed from the requirement list.
Microsoft Purview Data Loss Prevention
In March 2024 (service release 2403), it was announced that Microsoft Purview Data Loss Prevention (DLP) will now support Windows 365 Enterprise. Getting access to DLP means that you can now monitor the actions that are being taken on items you’ve determined to be sensitive. Moreover, this also helps you block unintentional sharing of these items. As soon as you onboard devices into the Microsoft Purview solutions, data concerning what users are doing with sensitive items becomes available in activity explorer.
Windows 365 Boot shared mode supports FIDO
This change can help your business strengthen the security of your Windows 365 environment. Because Windows 365 Boot shared mode now supports FIDO, enterprises can leverage hardened authentication measures that minimize the risk of successful attacks.
MONITOR AND TROUBLESHOOT
Update
What it offers
New Intune report and device action for Windows enrollment attestation (public preview)
The device status attestation report gives you information about devices that have either Completed, Failed,or Not started enrollment attestation. With the new device attestation status report in Microsoft Intune, you can find out if a device has attested and enrolled securely while being hardware-backed.
Cloud PC utilization report for Windows 365 Government
The Cloud PC utilization report offers you a useful tool for monitoring and optimizing Cloud PC usage in your organization. You can glean from it information such as how much time users are spending on their Cloud PCs or when they last connected. As of June 2024, support for this feature is now available to Windows 365 Government.
Cloud PC size recommendations report
This Cloud PC recommendations report is now out of preview and generally available. The report is an AI-powered feature that enables administrators to determine the correct size for Cloud PCs. By assessing data such as end-user Cloud PC usage patterns, platform level resource utilization data, and performance needs, you can work out the best Cloud PC configuration for your users.
Cloud PCs that aren’t available report
Generally available as of May 2024 (service release 2404). Simplifies the task for admins by helping them identify Cloud PCs that may be currently unavailable. The report will give you information concerning conditions up to 5 to 15 minutes ago. As a result, you could potentially find Cloud PCs in the report that have already recovered.
Improvements to Cloud PC connection quality report
Several upgrades to the Cloud PC connection quality report became generally available in March. The improvements that you can look forward to include: A more comprehensive view of the overall performance of your Cloud PCs.A more detailed view of devices when they are in a state of poor performance due to high round trip times.Tenant level visibility to most recent/current for:Round Trip Time.Bandwidth.Connection Time.UDP Utilization.Connection specific detail on client IP and associated CPC Gateway.Filters for all columns.
Alerts for Windows 365 Frontline maximum concurrent Cloud PCs
Windows 365 administrators will be getting even more information to help them better manage their Cloud PC environments. With this update, admins receive alerts notifying them when the maximum concurrent Cloud PCs are active for Windows 365 Frontline subscriptions.
Device action data kept for 90 days
You get to view actions performed within the last 90 days. To access this information, navigate to the Overview page for individual Cloud PCs.
UPDATES TO WINDOWS 365 BOOT
Update
What it offers
Shared and dedicated Windows 365 Boot device
Using Windows 365 Boot, admins can configure Windows 11 physical devices so that users can: Avoid signing in to their physical device.Sign in directly to their Windows 365 Cloud PC on their physical device. To add to the flexibility, Windows 365 Boot now supports both dedicated and shared PC scenarios.
Windows 365 Boot sign-in page customization
Another update for Windows 365 Boot is the availability of sign-in page customization. Previously in preview, this feature became generally available in February.
Windows 365 Boot fail fast notifications
Adding to the previous new updates is fail fast notifications. Beginning in February as well, Windows 365 Boot detection and notification of network or application setup issues transitioned to general availability.
Management of local PC settings
The last update for February allowed for changes regarding the management of local PC settings. Going forward, users will be able to manage local PC settings through their Windows 365 Boot Cloud PC.
Wrap up
Ensuring that your IT environment is operating at peak efficiency is a goal that every company should have. Optimizing the functions of applications and devices is integral to maintaining elevated productivity levels. This is why one cannot overstate the importance of the new features and updates. It’s why we regularly see them from Microsoft Intune and Windows 365.
Not only do they keep your business running smoothly. They constantly address any issues that may arise. As a business, your needs change as the operating environment evolves. Therefore, there is a need for services like Intune and the Cloud PC that can keep up with those changes.
As 2024 is drawing to a close, we can start to look back at the features that have been added to Microsoft Intune and Windows 365. These upgrades have enhanced the user experience, strengthened security measures, and enabled users to operate more efficiently.
As such, it will be exciting to look at what Microsoft could potentially add to these platforms in 2025. Businesses will be interested in seeing what Microsoft has on the horizon. They will also be eager to see what will improve these platforms even further while simultaneously addressing some common concerns they may have.
With this in mind, in this article, we’ll be going over the information Microsoft has released concerning features scheduled to be released in 2025.
What does 2025 hold for Intune?
Microsoft Intune: Managed device attestation for iOS/iPadOS and macOS device enrollment and ADE
When we consider the threat landscape that organizations constantly have to deal with, it’s easy to see why there is a great need for continually improving security measures. Hence why bringing ACME and managed device attestation support for eligible Apple devices to GA is a great move on Intune’s part. It should enable you to have better control over the verification processes of various devices.
Included in this update are device enrollment and ADE enrollments, notably AC2. Admins should note that this will apply to new enrollments with device enrollment (BYOD) and new enrollments with ADE or Apple Configurator tool. We can expect to see the rollout of this feature beginning in April 2025.
Microsoft Intune: Windows enrollment attestation
Staying with the same theme of enhancing security measures, businesses will also be getting this feature beginning in March 2025. You can expect to have physical devices attested at enrollment and enrollment credentials storage in the hardware of the device.
This can provide administrators with an extra bit of convenience. It will allow them to view device attestations in the new Device attestation status report. Additionally, they can force attestation from that report when necessary.
Microsoft Intune: Enhanced device inventory for Windows devices
Few things can increase work efficiency the way that easily having access to all the information you need when you need it can. This is what businesses will be getting when this service is rolled out in February 2025 enabling them to obtain more inventory information about their Windows devices. You get to specify which device properties you need to collect as well as from which devices. With this, you can view that information for your devices.
Microsoft Intune: Hardware-backed attestation – enhanced for Windows 11
This feature, which will be coming to you in January 2025, seeks to improve the Windows compliance policy. You should expect an improvement in device health due to the addition of five additional hardware attestation settings. These settings are specific to Windows 11 using advanced platform security features. The latter will include features such as firmware protection, virtualization-based security, Memory Integrity and Access Protection, and Early Launch Antimalware protection.
Microsoft Intune: macOS Platform SSO Support
Intune is constantly looking for ways to enhance the user experience for customers that use the macOS platform. To this end, features like this one in particular will give you better security and increase convenience. With the release planned for January 2025, customers should soon be able to log in on a managed Mac using their Entra ID password.
Microsoft Intune: Multiple managed accounts
Adding to the convenience that the upcoming Intune features will bring is this feature. As of January 2025, Microsoft plans on enabling users to use a single device with multiple company accounts to access company information through specific managed applications.
Microsoft Intune: Enrollment time grouping for Android Enterprise Corporate devices
Enrollment time grouping (ETG) for Android Enterprise Corporate devices is a feature that will help targeted apps and policies reach devices faster thus minimizing delays common with device setup. The rollout is slated for January 2025.
AI to boost the capabilities of the Cloud PC
Businesses cannot deny the immense potential that AI can offer them. This technology has vast applications that can positively impact business operations at just about every level. It’s therefore no surprise that Windows 365 is working on taking advantage of AI to improve the user experience for Cloud PC users. Already, Windows 365 can use AI to provide you with Cloud PC resizing recommendations that can help minimize costs and increase efficiency.
Windows 365 does this and more by leveraging AI to evaluate Cloud PC deployment and utilization. With this information in hand, companies can better plan their Cloud PC environments thus maximizing the value of their investment. These tailored, AI-powered insights will help you avoid several issues including:
Complex purchase discussions – when you lack specific information, your organization could spend vast amounts of time bogged down in discussions with vendors trying to figure out what’s most suitable for your needs.
Low productivity levels – if your environment operates with incorrect configurations, employees cannot perform at optimum levels and their output will be lower than it should be.
Fluctuations in usage and license churn – any discrepancies between your purchased licenses and actual use may cause irregular usage patterns which in turn negatively impacts cost management.
Wrap up
The various development teams at Microsoft appreciate the need to keep expanding the capabilities of the products and services they offer. As the modern work environment evolves, so too should the tools available to us. Companies need technologies that empower their employees, strengthen their security, and inspire business innovation.
Fortunately, the new features and capabilities that Microsoft Intune and Windows 365 are working on promise to deliver. Customers can plan excitedly for the future knowing that their platforms of choice will keep them ahead of the curve.
