Windows Feature Update Pin Drift: 24H2 Device on 25H2

A managed laptop has an Intune feature update policy that pins Windows 11 24H2. You open winver and it says 25H2. There is no failed install, no pending restart and no alert in the console, so nothing tells you until you check.

This article covers why that happens and how to find out which cause you have. Microsoft doesn’t use the phrase “pin drift”. I use it here for a device that ends up on a different feature update version than the one your policy targets, without any error. Every cause below comes from Microsoft Learn or Microsoft release health. I have not reproduced this on a live tenant, and I flag the places where Microsoft’s documentation stops.

The free Error Code Cheat Sheet covers the loud version of this problem, the feature update that fails with a code. This article is for the quiet version.

Key takeaways

• Microsoft states that feature update policies don’t downgrade devices. A device already on a newer version than the one targeted keeps its current version.
• A second feature update policy for a newer version, including a policy that Windows Autopatch creates, can supersede your 24H2 pin.
• Removing update ring feature deferrals before Windows Update has processed the new policy can expose a device to a feature update you didn’t intend. Learn gives a safe order of operations.
• Switching the co-management Windows Update policies workload to Intune can briefly leave devices updating to a later version than the policy says.
• A pin does not last forever. 24H2 for Home and Pro is past end of servicing, and Learn documents an automatic update for the client-side target version policy once a device is 60 days past end of service.
• Start diagnosis in Intune, not on the device. The Intune Windows feature update report shows the target version and the update state for each device.

What pin drift means

A pin is a feature update policy that targets one Windows version. Microsoft describes feature update policies as a way to “lock devices to a specific Windows release” and says the policy keeps that version enforced “until the policy is changed or removed.”

Pin drift is the gap between that statement and what the device runs. It is not a failed upgrade, it is not a safeguard hold, and it is not a policy that never reached the device. Those cases have their own articles: 25H2 not installing from an Intune feature update policy and 25H2 blocked by a safeguard hold. Here the update succeeded, just not the one you asked for.

Quick Fix checklist

Work these in order on one affected device before you change any policy.

1. Confirm the real version. Run winver, or run systeminfo | findstr /B /C:"OS Name" /B /C:"OS Version". Microsoft’s release information lists build 26100 for 24H2 and build 26200 for 25H2.
2. In the Intune admin center, go to Devices > Windows > Windows updates > Feature updates and list every feature update profile. Look for any profile that targets 25H2 or later, and for profiles named Windows Autopatch - DSS policy - <release name> - Phase <number>.
3. Check which of those profiles the device’s groups are assigned to, including nested and dynamic groups.
4. Open the Windows feature update report for your 24H2 profile and read Update State, Update Substate and Target Version for the device.
5. Open your update ring and confirm Feature update deferral period (days) is 0 and feature updates aren’t paused.
6. If the fleet is co-managed, check whether the Windows Update policies workload moved to Intune recently.
7. Check the edition. If the device is Home or Pro, 24H2 is already past end of servicing.
8. Only then look on the device: the registry key for the client-side target version policy, and the Windows Update log.

The documented causes

Cause 1: the device was already on 25H2

Microsoft’s wording: “Feature update policies don’t downgrade devices. If a device is already running a newer Windows version than the one targeted, the policy doesn’t apply and the device continues running its current version.”

This is the cheapest cause to rule in or out. A policy created after a device reached 25H2 will never move it back. Microsoft also notes that feature update policies don’t apply during Windows Autopilot out-of-box experience (OOBE) and take effect at the first Windows Update scan after provisioning. Learn doesn’t say that a device can pick up a newer version in that window, so I’m treating that as a timing detail to check, not a documented cause.

Microsoft also says devices on 24H2 move to 25H2 with an enablement package, a “small, quick-to-install switch”, because most 25H2 files already exist on 24H2 devices with a recent monthly security update. I read that as one reason this upgrade doesn’t produce the long setup run you would normally notice. That part is my inference, not a Microsoft statement.

Cause 2: another feature update policy targets a newer version

Learn says each feature update policy targets one Windows version, a device in several policies can be eligible for several updates, and “Windows Update offers only one feature update to a device at a time and always selects the latest applicable version.” In the Intune report states, a device that is targeted by another deployment with newer content gets a Service Cancelled substate, because the older content is superseded.

Windows Autopatch matters here. Autopatch creates one feature update policy per release phase, named Windows Autopatch - DSS policy - <release name> - Phase <number>. If a device sits in an Autopatch group with a release that targets 25H2 and also in a group with your own 24H2 policy, the 25H2 policy can win.

Microsoft’s documentation isn’t consistent on conflicts. The failures report lists a DeploymentConflict alert with the text “Device is in more than one deployment of the same update type. Only the first deployment assigned is effective.” The policy evaluation page says the latest applicable version is selected. I can’t tell you from Learn which rule governs every case, so don’t rely on either. Make sure only one feature update policy applies to each device.

Cause 3: update ring deferrals were removed before the policy was processed

When you create or change Intune Windows update policies, the details go to the Windows Update service. Microsoft says that evaluation “typically completes within 10 minutes, but in some cases can take longer.” It then warns that if a device scans after a deferral is removed but before Windows Update finishes processing the feature update policy, “the device might be offered a feature update you didn’t intend to deploy.”

So the order matters. Learn’s sequence is: create the feature update policy and assign it, wait, confirm the devices show OfferReady in the Windows feature updates report, and only then set Feature update deferral period (days) to 0 in the update ring.

Cause 4: a co-management workload switch

For co-managed devices, Learn says a newly configured Windows Update policies workload moved to Intune can lead to “devices updating to a later feature update version than is configured in the policy” during a temporary delay. The documented prevention is to create the feature update policy first, assign it, wait until devices show OfferReady or a later state, and only then switch the workload in Configuration Manager.

Cause 5: the pinned version reached end of servicing

This is the cause I would check first on any fleet that includes Home or Pro devices, because it is date-driven and nobody triggers it.

Microsoft’s Windows 11 release information shows 24H2 as “End of updates” for Home, Pro, Pro Education and Pro for Workstations, and lists 2027-10-12 for Enterprise, Education, IoT Enterprise and Enterprise multi-session. The Windows 11 Home and Pro lifecycle page lists 24H2 with an end date of 10/14/2026. The Enterprise and Education lifecycle page lists 10/13/2027.

For the client-side Select the target feature update version policy, Learn says: “If you don’t update this before the device reaches end of service, the device will automatically be updated once it’s 60 days past end of service for its edition.” By my arithmetic, 60 days after 10/14/2026 is mid-December 2026. Microsoft doesn’t publish that date, so verify it against your own edition before you plan around it.

I could not find Learn text that says the Intune feature update policy behaves the same way. What Learn does say about Intune is narrower. The policy list shows Not supported when “Support for the feature update has expired and it no longer deploys to devices,” and the report defines the Service Cancelled substate as an end of service reached for the selected content. Learn doesn’t say what the device does next. Treat a 24H2 pin on a Home or Pro device as a pin that Microsoft no longer services, and plan to move it.

One more trap: the support end date shown next to each profile in Intune “is for the Enterprise and Education editions of Windows.” A Pro device can be past end of servicing while the profile still looks fine.

How to diagnose it

In Intune

The Intune report data arrives in two ways. Service-side data from Windows Update typically arrives in less than an hour. Client-side data refreshes every eight hours and only exists if you configured data collection. A device with no client-side data can look quieter than it is.

1. Go to Reports > Windows Updates, open the Windows Feature Update Report, choose your 24H2 profile and select Generate report.
2. Read Update State, Update Substate, Last Event Time and Target Version for the device. A Service Cancelled substate means Windows Update cancelled the offer, either because end of service was reached or because newer content from another deployment superseded it.
3. Go to Devices > Monitor > Feature update failures and look at the alerts for the profile. The ones relevant here are DeploymentConflict, PolicyConflict, PolicyConflictDeferral, PolicyConflictPause, VersionMismatch, EndOfService and EndOfServiceApproaching.

The failures report covers devices that have attempted to install an update. A device that quietly succeeded in installing 25H2 may not appear there, so a clean failures report doesn’t prove your pin held.

Learn defines VersionMismatch as “Device is on a version of Windows that wasn’t intended by Windows Update” and recommends you “confirm whether the device is on the intended version.”

On the device

Learn describes feature update policies as using cloud-based update orchestration, and I found no documented registry value for them. Look for the client-side competitors instead. The Group Policy setting Select the target Feature Update version lives under Computer Configuration > Administrative Templates > Windows Components > Windows Update > Manage updates offered from Windows Update, and its registry key is Software\Policies\Microsoft\Windows\WindowsUpdate. The MDM equivalents are the ProductVersion and TargetReleaseVersion settings in the Update CSP.

# Read-only. Not executed for this article.
Get-ItemProperty -Path 'HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate'

I did not verify the exact registry value names under that key, so the command lists everything and you look for target version values. Microsoft documents a related trap: if the client-side policy names a version older than the current one, or an invalid value, the device “won’t receive any feature updates until the policy is updated.” That blocks updates rather than causing drift, but it tells you the client policy and your Intune policy disagree.

To read the update scan history, merge the Windows Update trace files:

# Read-only. Not executed for this article.
Get-WindowsUpdateLog -LogPath "$env:TEMP\WindowsUpdate.log"

Learn describes this cmdlet as merging the .etl files into a single WindowsUpdate.log. Microsoft doesn’t publish a list of log strings that identify a feature update offer, so I’m not going to give you one.

The fix

1. Decide whether 24H2 is still the right target. For Home and Pro devices it is not, because 24H2 has passed end of servicing. For Enterprise and Education, 24H2 is serviced until October 2027. My recommendation: retarget Home and Pro groups to 25H2 now and keep a 24H2 pin only where you have a documented compatibility reason and an end date.
2. If the device already moved to 25H2, retarget the policy to match. The policy can’t pull it back. Learn describes an update ring setting, Set feature update uninstall period (2 - 60 days), but doesn’t say whether it applies to a 24H2 to 25H2 enablement package upgrade, and I couldn’t verify that. Test rollback on one device before you promise it to anyone.
3. Leave exactly one feature update policy per device. Remove the device’s group from any other feature update profile, including Autopatch-created ones, or exclude it. Learn’s remediation for DeploymentConflict is “Remove the device from any deployments that shouldn’t apply.”
4. Fix the order of operations. If you are moving from update ring deferrals to feature update policies, follow Learn’s sequence: policy first, wait for OfferReady, then set the deferral to 0.
5. For co-managed fleets, create and assign the policy before you switch the Windows Update policies workload, and check the report before you move the slider.
6. Remove stale client-side target version policy (Group Policy or CSP) where the pin now belongs to Intune.
7. Recheck after the next scan. Use the Windows feature update report, since the client data refreshes every eight hours.

If the drift has already caused a failed or rolled-back upgrade, the Error Code Cheat Sheet has a section on feature upgrade and Windows Setup error codes.

What not to waste time on

• Update ring deferrals as the cause of an early upgrade. Learn says leftover deferrals can delay or block feature updates. They don’t pull a 25H2 upgrade forward. The risk is the moment you remove them.
• The ring setting “Upgrade Windows 10 devices to Latest Windows 11 release”. Learn describes it as applying to eligible Windows 10 devices. A device already on 24H2 is not affected.
• Pausing as a pin. Learn says pausing feature updates in update rings expires after 35 days, while a feature update policy stays until you change or remove it.
• Repairing Windows Update. Nothing is broken. The device is doing what a policy told it to do.

Scenarios

Prevention

• Keep one owner for feature update policy per device group, and name profiles with the target version.
• Put the end-of-servicing date for each pinned version in your change calendar. For client-side pins, use Microsoft’s documented 60-day window as the outer limit.
• Make the Windows feature update report part of the post-change check, not just the assignment screen.
• If Autopatch manages part of the tenant, list its DSS policies next to yours before you assign anything.
• Use winver or systeminfo on a pilot device after every policy change. A report can say one thing while the device runs another.

Methodology

• I read Microsoft Learn pages on feature update policies, update rings, reports, the Update CSP, Windows Update for Business Group Policy, Windows Autopatch feature updates, Windows 11 release information and the Windows 11 lifecycle pages. Retrieved 2026-11-03.
• The lead was a public X post describing a device that is told to stay on 24H2 and runs 25H2 with no errors. I used it only as the scenario. Every cause, command and fix above comes from a Microsoft page cited below.
• I did not reproduce this on a tenant and I did not run either PowerShell command. Both are read-only.
• Items I could not verify are called out in the text: Intune policy behavior at end of servicing, which conflict rule applies to overlapping policies, rollback of a 25H2 enablement package upgrade, and the registry value names under the Windows Update policy key.

FAQ

Does an Intune feature update policy roll a device back to 24H2?

No. Microsoft says feature update policies don’t downgrade devices, and a device on a newer version keeps it. To change the target for that device, retarget the policy to the version it runs.

Why did a 24H2 device get 25H2 with no error?

Windows 11 24H2 devices update to 25H2 through an enablement package, so a successful update can look uneventful. The usual documented causes are a second policy for a newer version, a deferral removed before the policy was processed, a co-management switch, or a pinned version past end of servicing.

Is 24H2 still supported?

For Enterprise and Education, Microsoft lists 24H2 with end of updates on 2027-10-12. For Home, Pro, Pro Education and Pro for Workstations, the release information page shows 24H2 as “End of updates”.

Does Windows force an update when the pinned version reaches end of service?

For the client-side target version policy, Microsoft says the device is automatically updated once it’s 60 days past end of service for its edition. I could not find the same statement for the Intune feature update policy, so don’t assume either way.

Where do I see which version Intune is targeting for a device?

In the Windows feature update report, the Target Version column shows the update being targeted on the device. Select the policy, generate the report, then compare it with what winver shows.

Sources

All retrieved 2026-11-03 (America/Denver).

• Configure Windows Feature Update Policies, Microsoft Learn: no downgrade, policy lasts until changed or removed, policy evaluation, deferral transition order, co-management warning, support column.
• Manage Windows Feature Updates, Microsoft Learn: lock devices to a release, update ring interaction, behavior during Autopilot OOBE.
• Reports for Windows Feature Update Policies, Microsoft Learn: Target Version column, Service Cancelled substate, alert types, data latency.
• Update Rings Policy Settings, Microsoft Learn: feature update deferral period, Windows 10 upgrade setting, uninstall period.
• Configure Windows Update client policies via Group Policy, Microsoft Learn: target feature update version policy and the 60-days-past-end-of-service behavior.
• Update Policy CSP, Microsoft Learn: ProductVersion, TargetReleaseVersion, registry key path.
• Windows feature updates overview for Windows Autopatch, Microsoft Learn: DSS policy naming per release phase.
• Windows 11 release information, Microsoft Learn: end of updates dates and build numbers for 24H2 and 25H2.
• Windows 11 Home and Pro lifecycle, Microsoft Learn: 24H2 end date for Home and Pro.
• Windows 11 Enterprise and Education lifecycle, Microsoft Learn: 24H2 end date for Enterprise and Education.
• What’s new in Windows 11, version 25H2 for IT pros, Microsoft Learn: enablement package from 24H2.
• What version of Windows am I running?, Microsoft Learn: winver and systeminfo commands.
• Get-WindowsUpdateLog, Microsoft Learn: merges Windows Update .etl files, -LogPath parameter.