Windows 11 26H2 is generally available as of September 29, 2026. For most organizations running Windows Autopilot and Microsoft Intune, this is the calmest annual feature update in years: devices on 24H2 or 25H2 get a tiny enablement package and a single restart. But “calm” is not the same as “nothing to do”. There are lifecycle deadlines only weeks away, a new Windows 11 branch (26H1) that cannot take 26H2 at all, features that are now switched on by default for commercial devices, and a reporting stack that simply shows nothing if you have not flipped the right switches.

This post is the practical version: what Windows 11 26H2 actually is, what to do in Intune and Autopilot this week, what to be aware of before you press deploy, and how to report on the rollout so you can prove where every device is. All screenshots are from my own tenant, taken on release day.

If you want the Autopatch ring design and pilot-to-production exit criteria in more depth, I covered that earlier in Windows 11 26H2: Upgrade Paths, Autopatch & Pilot to Production. This post focuses on the GA release itself, Autopilot, Intune policy and reporting.

Windows 11 26H2 at a glance

General availability	September 29, 2026
Build	26300 (10.0.26300.x)
Delivery for 24H2 and 25H2	Enablement package (KB5121794), single restart
Delivery for 23H2 and Windows 10	Full feature update (media-based, several GB)
Windows 11 26H1 devices	Not eligible for 26H2 (different Windows core)
Servicing	36 months for Enterprise and Education, 24 months for Home and Pro
Hardware requirements	Unchanged from Windows 11 (TPM 2.0, UEFI Secure Boot, supported CPU)

Windows 11 24H2, 25H2 and 26H2 share one servicing branch. The code for most 26H2 features has already been delivered to your devices through the monthly cumulative updates, sitting dormant. The enablement package flips the version to 26H2, activates the features that were held back and resets the support clock. That is why Microsoft calls it a “predictable and low-disruption update”, and why app compatibility testing you already did on 24H2 or 25H2 largely carries forward.

Why you should not wait: the lifecycle dates that matter now

The most important reason to act on Windows 11 26H2 this month has nothing to do with new features. It is the support calendar:

• Windows 11 24H2 Home and Pro reaches end of servicing on October 13, 2026. That is two weeks after 26H2 GA. Many small and mid-size businesses run Pro, often on Autopilot devices that shipped from the OEM with 24H2.
• Windows 11 23H2 Enterprise and Education ends on November 11, 2026. These devices need a full feature update, not the enablement package.
• Windows 11 24H2 Enterprise and Education is supported until October 13, 2027, and 25H2 Enterprise and Education until October 11, 2028.

If you have Pro devices on 24H2, 26H2 (or at minimum 25H2) needs to be on them before mid-October. The good news is that the enablement package makes that realistic even on a short timeline.

Step 1: Find out what you actually have

Before you create a single policy, get an honest inventory of Windows versions in the tenant. The quickest view is Devices > Windows > Windows devices with the OS version column visible. Build numbers map to versions like this:

Build	Version	Path to 26H2
10.0.19045	Windows 10 22H2	Full upgrade (hardware permitting)
10.0.22631	Windows 11 23H2	Full feature update
10.0.26100	Windows 11 24H2	Enablement package
10.0.26200	Windows 11 25H2	Enablement package
10.0.26300	Windows 11 26H2	Already there
10.0.28000	Windows 11 26H1	Not eligible, stays on the 26H1 path

My own tenant is a good example of why this matters. It is small, but it already contains three different stories: several 25H2 devices (26200) that will take the enablement package, one 23H2 device (22631) that needs a full upgrade, and one brand-new device on 26H1 (28000) that will never be offered 26H2.

For anything beyond a handful of devices, export the list or pull it with Microsoft Graph PowerShell and group by build:

Connect-MgGraph -Scopes "DeviceManagementManagedDevices.Read.All"

$map = @{ '19045'='Win10 22H2'; '22631'='23H2'; '26100'='24H2'; '26200'='25H2'; '26300'='26H2'; '28000'='26H1' }

Get-MgDeviceManagementManagedDevice -All -Filter "operatingSystem eq 'Windows'" -Property "deviceName,osVersion" |
    Group-Object { ($_.OsVersion -split '\.')[2] } |
    Select-Object @{n='Build';e={$_.Name}}, @{n='Version';e={$map[$_.Name]}}, Count |
    Sort-Object Build

Pay special attention to edition. A 24H2 device on Enterprise has another year of support; the same build on Pro runs out on October 13.

Step 2: Clean up your update rings before you deploy

Feature update policies and update rings work together, and the combination is where most “why is nothing happening?” tickets come from. Microsoft’s guidance is clear: when you use a feature update policy, set the feature update deferral period in the update ring that targets the same devices to 0 days. The feature update policy then controls which version the device gets and when. A ring that still defers feature updates can block or delay the version you are trying to deliver, and the device will report PolicyConflictDeferral in the failure report.

While you are in the rings, check three more things:

• Paused rings. A ring that was paused during an incident and never resumed will stop 26H2 as effectively as a deferral (PolicyConflictPause).
• Windows 10 leftovers. Rings and policies named for Windows 10 often still carry old settings. Windows 10 reached end of support on October 14, 2025, and any remaining devices need an upgrade plan or ESU.
• Conflicting GPOs. On hybrid or co-managed devices, a WSUS or deferral GPO that still applies will fight the MDM policy. Confirm the Windows Update workload sits with Intune.

Step 3: Create the Windows 11 26H2 feature update policy

Go to Devices > Windows > Windows updates > Feature updates. On release day the tab already shows Autopatch update readiness tiles, and in my tenant a yellow banner that we will come back to in the reporting section. The Create menu now offers both a classic Feature Update Policy and an Autopatch multi-phase release.

Choose Feature Update Policy. Windows 11, version 26H2 is already the default in the Feature update to deploy list, alongside 25H2, 24H2 and 23H2. Note that 26H1 is not in the list: it is not a feature update target, it is a separate branch for specific new hardware.

Settings I recommend for the first wave:

• Name: something that tells the next admin what it is, for example WIN-FU-26H2-Pilot.
• Required vs. optional: use Make available to users as a required update for managed rollout. The optional setting is useful for a self-service early adopter group, but you give up control of timing.
• Rollout options: As soon as possible for the pilot, Gradually for broad. Gradual rollout spreads offers across groups and days, which protects your network and your service desk.
• Assignments: device groups, not user groups. Start with IT, then a pilot of 5 to 10 percent across hardware models and departments, then broad.

Two behaviors to keep in mind. First, a feature update policy is also a “stay here” instruction: devices targeted by an existing 24H2 or 25H2 policy will not move to 26H2 until you change or replace that policy. Search for old feature update policies before you wonder why nothing happens. Second, a device should be in exactly one feature update policy. If it lands in two, the failure report shows DeploymentConflict and only the first assigned deployment is effective. Use exclusions to keep pilot and broad groups mutually exclusive.

If you use Windows Autopatch, create an Autopatch multi-phase release instead and let the Test, First, Fast and Broad rings stagger 26H2 for you. Plan any group changes first: you cannot edit an Autopatch group while a feature update release is in progress for it.

What to do if you use Windows Autopilot

Autopilot does not install a new Windows version. It provisions whatever image the OEM put on the device, whether that is 24H2, 25H2 or eventually 26H2. What happens after enrollment is controlled by your update policies. That leads to a few concrete tasks.

Make sure new devices land in the 26H2 policy on day one

New hardware arriving this quarter will mostly ship with 24H2 or 25H2. If your broad 26H2 policy targets a static group that nobody updates, every new Autopilot device will be one version behind from its first boot, and new Pro devices on 24H2 are two weeks from end of servicing. Target the policy at the same dynamic or device preparation device group your Autopilot devices land in, for example a dynamic group on the Autopilot ZTDID attribute:

(device.devicePhysicalIDs -any (_ -startsWith "[ZTDId]"))

For Autopilot device preparation, the device group you configure in the device preparation policy works the same way. Because the eKB is only a restart, new devices move to 26H2 shortly after the user has signed in, without a long upgrade experience.

Know what happens during OOBE

The Enrollment Status Page setting Install Windows quality updates (might restart the device) installs the monthly quality update during OOBE. It does not install the 26H2 feature update, so your ESP timing does not change. The version move happens after provisioning, driven by the feature update policy. If you have customers or users who expect “the latest Windows” out of the box, that is the expectation to set.

Look at device association for Autopilot device preparation

Windows 11 26H2 brings device association for Windows Autopilot device preparation. It lets you identify trusted corporate devices before enrollment, which enables device-targeted policies, automatic corporate enrollment and more customization during OOBE. That closes one of the biggest gaps between device preparation and classic Autopilot profiles. It sits under Devices > Windows > Enrollment, right above the device preparation policies.

Decide on Windows Backup and Restore

In 26H2, Windows settings backup is enabled by default for eligible commercial devices, and the first sign-in restore experience now also supports Microsoft Entra hybrid joined devices, Cloud PCs and multi-user environments. For device refresh with Autopilot this is genuinely useful: the user signs in on the new device and gets settings and their Microsoft Store app list back. Administrator-configured policies are still honored, so if your organization has decided against it, make that decision explicit with the Windows Backup and Restore enrollment setting and the settings catalog, rather than relying on a default that just changed.

Plan for 26H1 hardware

Windows 11 26H1 ships on specific new devices and runs on a different Windows core. Microsoft states that these devices cannot update to 26H2. For Autopilot this means you will enroll a growing number of devices with build 28000 that are newer than 26H2 by build number but are not “on 26H2”. Check anything that makes decisions based on OS version:

• Compliance policies that use Valid operating system builds ranges, for example 10.0.26100 to 10.0.26300. A 28000 device falls outside and becomes noncompliant, which with Conditional Access means blocked.
• Dynamic groups and assignment filters on deviceOSVersion or osVersion that use startsWith “10.0.26”.
• Reports and dashboards that calculate “on latest version” by comparing strings.

Reset, wipe and reimaging

Autopilot Reset and a local wipe reinstall from the device’s current OS, so a device that has taken 26H2 stays on 26H2. If you still maintain a corporate image for reimaging before Autopilot, update it to 26H2 media so reimaged devices do not start their life on a version that is about to go out of support.

What to be aware of in Windows 11 26H2

Most of these changes are good news. They are listed here because each of them can surprise a user, a script or a service desk if you did not know it was coming.

Features that are now on by default for commercial devices

Some features were delivered earlier through monthly updates but held back on commercial devices by temporary enterprise feature control. 26H2 enables them by default: Windows settings backup, app-specific actions from the taskbar, and a set of File Explorer enhancements. Tell your service desk and update end-user documentation before the pilot, not after. Also resist using the AllowTemporaryEnterpriseFeatureControl policy to force dormant features on across production: it bypasses exactly the controlled validation that the enablement model gives you.

WMIC is gone

The WMI command-line tool (WMIC) is removed and is no longer available as a Feature on Demand on 24H2 and later. Search your Intune remediations, platform scripts, Win32 app install commands and detection scripts for wmic and replace it with Get-CimInstance. A detection script that silently fails will make a Win32 app show as “not installed” and trigger reinstall loops.

# Old
wmic bios get serialnumber
# New
(Get-CimInstance -ClassName Win32_BIOS).SerialNumber

Cross-signed drivers lose default trust

Windows changes how the kernel trusts third-party drivers. Default trust for the old cross-signed driver program is removed. Drivers from the Windows Hardware Compatibility Program and an allow list of trusted legacy drivers are still allowed. Windows audits driver compatibility for at least 100 hours and three restarts before enforcement kicks in, which is exactly the kind of delayed impact that slips past a two-day pilot. Include devices with old scanners, label printers, VPN clients, dongles and specialist lab or production hardware in your pilot, and keep them there long enough.

Hotpatch is on by default for eligible devices

My tenant shows an Hotpatch Enablement banner on the Windows updates page: eligible devices receive hotpatch updates automatically, unless you configured hotpatch yourself in a quality update policy or opt out. That fits well with 26H2, since a feature update restart moves the device to a new baseline and hotpatch keeps restarts down afterwards. Just make sure your change process knows that “patched” no longer always means “restarted”.

New security capabilities are off until you turn them on

Several of the most interesting 26H2 features for Intune admins are available but not enabled. They are worth a proof of concept once the rollout is stable:

• Administrator protection: just-in-time elevation with profile separation instead of standing admin rights. Enable with Intune or Group Policy, and test together with Endpoint Privilege Management if you use it.
• Built-in Sysmon: System Monitor is now part of Windows, logs to the Windows Event Log and supports your own configuration files. No more packaging Sysmon as a Win32 app.
• Smart App Control can be turned on or off without a clean install.
• Passkey plugin credential managers and Windows Hello Enhanced Sign-in Security with supported external fingerprint readers.
• Post-quantum cryptography APIs (ML-KEM and ML-DSA) in CNG and .NET.
• A more secure batch file processing mode that prevents batch files from changing during execution, useful for Application Control for Business policy authors.

Recovery features to configure deliberately

Point-in-time restore can roll a PC back to a recent restore point, including apps, settings and personal files. Quick machine recovery can run a one-time remediation scan, but stays off on domain-joined or enterprise-managed devices unless you enable it. Both are useful for the service desk, and both should be decisions in your baseline rather than something you discover during an incident. The new policy-based removal of preinstalled Microsoft apps also accepts additional MSIX or APPX package family names, which may let you retire a removal script or two.

What users will notice

The redesigned Start menu with a scrollable All section, category and grid views, a taskbar that can move to the top, left or right and a smaller taskbar option, File Explorer and Windows Search improvements, Multi-App Camera, and fewer restarts because Windows Update bundles eligible updates with the monthly security update. None of these need a policy on day one, but a short “what’s new” note to users saves tickets.

Reporting on Windows 11 26H2 in Intune

A rollout you cannot measure is a rollout you cannot finish. Intune has good built-in reporting for feature updates, but it depends on prerequisites that many tenants, including my own, do not have turned on.

Prerequisite: turn on Windows data

Go to Tenant administration > Connectors and tokens > Windows data and enable Enable features that require Windows diagnostic data in processor configuration. For the readiness and compatibility reports, also enable Windows license verification, which confirms you own eligible Windows Enterprise licensing. Devices must send at least Required diagnostic data, and the feature update wizard itself reminds you to enable Windows health monitoring with the Windows Update scope to get detailed device states and errors.

This is a tenant-wide decision with a privacy dimension, so involve whoever owns data processing in your organization. But if it stays off, you are deploying 26H2 blind. This is what the Windows Autopatch feature update report looks like without it:

Service-side data from Windows Update usually arrives within an hour. Client-side data is processed in batches and refreshes about every eight hours, and only after you configure data collection. Turn it on at least a few days before the pilot so you have a baseline.

Before the rollout: readiness and compatibility risks

Go to Reports > Windows updates > Reports. Six reports live here:

• Windows Feature Update Device Readiness Report: pick Windows 11 26H2 as target OS and get per-device readiness with system requirement, app, driver and other issues. Run it before you assign the broad policy.
• Windows Feature Update Compatibility Risks Report: the same data turned around, grouped by app and driver, so you can see which single driver blocks 40 devices.
• Windows Update Distribution Report: how many devices are on each quality update level. Useful because a device far behind on cumulative updates is also a device that tends to struggle with feature updates.

For 24H2 and 25H2 devices the readiness report should be mostly green, as they already run the shared code base. The real value is on 23H2 and Windows 10 devices, which take a full upgrade, and in finding devices that fail Windows 11 hardware requirements.

During the rollout: feature update report and failures

The Windows Feature Update Report (Reports > Windows updates > Reports) shows status per policy. Select your 26H2 policy, generate the report and filter by update status. Each device moves through states such as Offer received, Download start, Install complete, Restart required and finally Update installed. For an enablement package the whole journey is short, so devices stuck in Restart required for days tell you that users are not restarting, not that the update is broken.

The Feature update failures report (Devices > Monitor) is where you troubleshoot. These alerts are the ones I see most in real 26H2-style rollouts:

Alert	What it means	What to do
PolicyConflictDeferral	An update ring defers feature updates	Set feature deferral to 0 days on the ring
PolicyConflictPause	Updates are paused on the device	Resume the ring or remove the pause GPO
DeploymentConflict	Device is in more than one feature update policy	Fix group membership and exclusions
SafeguardHold	Microsoft is holding the update for a known issue	Look up the hold ID on Windows release health
IncompatibleServicingChannel	Device is on an Insider or preview channel	Move it to the retail (GA) channel
DeviceRegistrationInvalidGlobalDeviceId	Device cannot register with Windows Update	Make sure the Microsoft Account Sign-In Assistant service is not disabled
EndOfServiceApproaching	The current version is close to end of servicing	Prioritize these devices, typically 24H2 Pro and 23H2

The MSA service one deserves a special mention: many hardening baselines disable the Microsoft Account Sign-In Assistant to block consumer accounts, and that silently breaks Windows Update deployment service registration. Block consumer accounts with the account policy instead and leave the service running.

Proving the result: version counts over time

Management rarely asks “what is the update substate of device 4711”. They ask “how many are done”. Three ways to answer that:

• Windows devices export or the Graph PowerShell snippet from step 1, run weekly and saved. Simple and works without any prerequisites.
• Windows Autopatch reports if you deploy with Autopatch: feature update status per Autopatch group and ring.
• Windows Update for Business reports in Log Analytics for trend lines and custom dashboards.

With Windows Update for Business reports enabled, a simple KQL query gives you the current version distribution across the fleet:

UCClient
| where TimeGenerated > ago(2d)
| summarize arg_max(TimeGenerated, *) by AzureADDeviceId
| summarize Devices = count() by OSVersion
| order by Devices desc

Pin it to an Azure workbook, add a line per week and you have the burn-down chart for the 26H2 project. Define your exit criteria up front, for example 95 percent of active devices on 26H2 within 30 days of broad deployment, with the remaining devices individually explained (offline, safeguard hold, 26H1 hardware, pending replacement).

A realistic Windows 11 26H2 rollout plan

For a typical Intune and Autopilot tenant, this is the plan I would run:

1. Week 0 (now): turn on Windows data and license verification. Inventory versions and editions. Fix ring deferrals, pauses and old feature update policies. Search scripts for WMIC.
2. Week 0 to 1: run the device readiness and compatibility risks reports for 26H2. Deploy 26H2 as soon as possible to IT devices.
3. Week 1: pilot group across all hardware models, including devices with legacy drivers. Prioritize 24H2 Pro devices because of the October 13 deadline.
4. Week 2 to 4: broad deployment with gradual rollout. Add the Autopilot device group so new hardware follows automatically. Start the full upgrade for 23H2 Enterprise devices, which end on November 11.
5. Week 4 onwards: work the failure report, chase the long tail, and start proof of concepts for Administrator protection, built-in Sysmon and point-in-time restore.

Windows 11 26H2 checklist for Intune and Autopilot

• Inventory builds and editions; identify 24H2 Pro (Oct 13, 2026) and 23H2 Enterprise (Nov 11, 2026).
• Set feature update deferral to 0 days on rings that share devices with feature update policies.
• Replace or retarget existing 24H2 and 25H2 feature update policies.
• Create a 26H2 feature update policy: IT, pilot, broad, with mutually exclusive groups.
• Include your Autopilot or device preparation device group in the broad assignment.
• Handle 26H1 (build 28000) devices in compliance ranges, dynamic groups and filters.
• Decide explicitly on Windows settings backup and restore.
• Remove WMIC from scripts and detection rules.
• Keep legacy-driver devices in the pilot for more than 100 hours and three restarts.
• Enable Windows data and Windows license verification for reporting.
• Run readiness and compatibility risk reports before broad deployment.
• Track Feature update failures and version counts weekly until exit criteria are met.

Frequently asked questions

Is Windows 11 26H2 a full upgrade?

Not for devices on Windows 11 24H2 or 25H2. They receive an enablement package (KB5121794) that activates 26H2 with a single restart. Devices on 23H2 or Windows 10 need a full feature update.

Does Windows Autopilot install Windows 11 26H2 during setup?

No. Autopilot provisions the OS version that is on the device. The Enrollment Status Page can install quality updates during OOBE, but the move to 26H2 happens after provisioning through your feature update policy or Autopatch release.

Can Windows 11 26H1 devices upgrade to 26H2?

No. 26H1 runs on a different Windows core and is not on the 24H2, 25H2 and 26H2 servicing branch. Microsoft will offer those devices their own future upgrade path.

Why are my Intune Windows update reports empty?

Most often because the Windows data connector is off. Enable features that require Windows diagnostic data in processor configuration and, for readiness reports, Windows license verification under Tenant administration > Connectors and tokens > Windows data. Then allow time for data to arrive.

How long is Windows 11 26H2 supported?

As an annual H2 release, 26H2 gets 36 months of servicing for Enterprise and Education and 24 months for Home and Pro, counted from GA.

Wrapping up

Windows 11 26H2 is the kind of release that rewards preparation over heroics. The update itself is a restart. The work is in the plumbing around it: rings that do not fight your feature update policy, Autopilot devices that are targeted from their first check-in, compliance rules that understand 26H1, scripts that do not depend on WMIC, and reporting that is switched on before you need it. Get those right this week and the October 13 deadline for 24H2 Pro becomes a non-event.

References

• What’s new in Windows 11, version 26H2 for IT pros (Microsoft Learn)
• An IT pro’s guide to Windows 11, version 26H2 (Windows IT Pro Blog)
• Releasing Windows 11, version 26H2 to the Release Preview Channel (Windows Insider Blog)
• Reports for Windows feature update policies (Microsoft Learn)
• Device association for Windows Autopilot device preparation (Microsoft Learn)
• Windows 11 Enterprise and Education lifecycle (Microsoft Learn)
• Windows release health
• Windows 11 26H2: Upgrade Paths, Autopatch & Pilot to Production