Microsoft has quietly pushed Windows 11, version 25H2 (Build 26200.5074) into the Release Preview channel — and unlike many headline OS releases, this one arrives as a lightweight enablement package (eKB) that flips features already staged on devices rather than replacing the whole operating-system image.
Windows 11, version 25H2 is delivered as an enablement package (eKB) that activates feature code Microsoft has been quietly shipping inside regular monthly cumulative updates. That means devices running Windows 11 version 24H2 that have kept up with monthly updates will already carry the binary code for many 25H2 features in a disabled state; installing the eKB merely turns those features on and completes the upgrade with a single restart. The net effect for most machines is an upgrade experience more like a monthly patch than a large, multi‑gigabyte feature swap.
The 25H2 release emphasizes security hardening, lifecycle clarity, and IT controls rather than massive UI changes. Notable changes surfaced in the Release Preview announcement include the removal of legacy components (PowerShell 2.0 and WMIC) and a new policy-driven option for removing pre‑installed Microsoft Store apps on Enterprise and Education devices via Group Policy or MDM CSP. Microsoft has also confirmed the practical servicing implications: 24H2 and 25H2 share a shared servicing branch, and the eKB approach resets support timelines (Enterprise/Education editions move to a 36‑month servicing window; Pro and Home editions resume a 24‑month window from release).
The upgrade model makes mass adoption easier, but it also places a premium on proactive discovery and remediation. Treat the Release Preview build as the start of formal validation: prioritize discovery of WMIC and PowerShell v2 dependencies, test the new app‑removal policy under your imaging and OOBE workflows, and confirm your update pipelines can reliably deliver (and, if needed, remove) the enablement package. With the right preparation, the transition to 25H2 should be fast, secure, and — crucially — reversible during your validation window.
Source: TechPowerUp Windows 11 25H2 Preview Arrives as Lightweight Enablement Package
Overview
Windows 11, version 25H2 is delivered as an enablement package (eKB) that activates feature code Microsoft has been quietly shipping inside regular monthly cumulative updates. That means devices running Windows 11 version 24H2 that have kept up with monthly updates will already carry the binary code for many 25H2 features in a disabled state; installing the eKB merely turns those features on and completes the upgrade with a single restart. The net effect for most machines is an upgrade experience more like a monthly patch than a large, multi‑gigabyte feature swap.The 25H2 release emphasizes security hardening, lifecycle clarity, and IT controls rather than massive UI changes. Notable changes surfaced in the Release Preview announcement include the removal of legacy components (PowerShell 2.0 and WMIC) and a new policy-driven option for removing pre‑installed Microsoft Store apps on Enterprise and Education devices via Group Policy or MDM CSP. Microsoft has also confirmed the practical servicing implications: 24H2 and 25H2 share a shared servicing branch, and the eKB approach resets support timelines (Enterprise/Education editions move to a 36‑month servicing window; Pro and Home editions resume a 24‑month window from release).
Background: the enablement‑package model and shared servicing
What an enablement package is (and why Microsoft uses it)
An enablement package is essentially a master switch — a tiny update that flips on features already delivered inside cumulative updates but kept dormant. The benefits in practice:- Minimal downtime: upgrades typically require a single restart rather than lengthy file replacement and migration.
- Smaller network footprint: no multi‑gigabyte feature ISO needs to be pushed to every endpoint that already received monthly patches.
- Faster adoption: IT can move fleets to the new version quickly, and users see less disruption.
- Controlled rollouts: features can be staged, tested, and held behind the eKB until the organization is ready.
Shared servicing branch: what it means operationally
Because 24H2 and 25H2 live on the same servicing branch, monthly quality updates (LCUs and SSUs) apply to both versions. Practically, this means:- Administrators focus validation work on feature activation behavior rather than full binary compatibility testing for every OS component.
- Monthly security fixes reach both versions uniformly, simplifying patch pipelines.
- Organizations that are current on cumulative updates are already carrying much of the 25H2 code—they only need the eKB to enable it.
What’s new in 25H2 (high‑impact changes for IT)
Removals and deprecations: PowerShell 2.0 and WMIC
25H2 explicitly removes or disables legacy components that Microsoft had deprecated earlier:- PowerShell 2.0 (PSv2): the legacy PowerShell engine that was deprecated years ago is being removed from shipping images. Systems that explicitly invoke PSv2 (for example via commands that include
-Version 2) may fail to summon the legacy engine and will instead run the default Windows PowerShell host (commonly PowerShell 5.1) or physical PowerShell 7 if configured. Most modern scripts will run under PowerShell 5.1 or 7.x, but administrators still running legacy automation that explicitly requires PSv2 must update those scripts or maintain a workaround. - WMIC (wmic.exe): the Windows Management Instrumentation command‑line tool has been deprecated and moved toward being disabled/removed. Microsoft recommends migrating scripts and tools that use
wmicto PowerShell CIM/WMI cmdlets, which are far more scriptable and maintainable.
Admin controls: policy‑based removal of default Microsoft Store apps
Windows 11, version 25H2 introduces a policy (via Group Policy and MDM CSP) that lets administrators remove select Microsoft Store apps from Enterprise and Education devices. Key points:- The setting is targeted at Enterprise and Education editions; consumer/Home devices are not covered by this policy.
- The policy is device‑level and intended for prevention of provisioning and/or removal of those Microsoft Store apps across the device.
- Administrators can enable the policy in Group Policy or via MDM (Intune) by using the new “Remove Default Microsoft Store packages” policy and select apps from a curated list. Once applied and the policy processes, the selected apps should be removed for the device and visible in event logs.
- Independent testing by tooling vendors shows early caveats: in some scenarios the policy prevents provisioning for new users rather than fully wiping all traces for existing user profiles. Administrators should test behavior on their imaging and provisioning flows before broad rollout.
The technical mechanics: how 25H2 upgrades will look in the field
Staging, flag flipping, and the single‑restart upgrade
- Microsoft ships new feature code inside monthly updates in a disabled state. That code sits on disk but does not alter behavior until a feature flag is toggled.
- The eKB changes the activation flags to Enabled. After installing the eKB, a single restart completes the activation and the machine reports the new version.
- For devices not already on 24H2, the eKB path may not be available; earlier versions require a full feature update (an OS swap or larger package) before the eKB mechanism can flip features upward.
Distribution channels and enterprise delivery
25H2 via eKB will be available through Microsoft’s typical delivery channels for commercial customers, including:- Windows Update / Windows Update for Business (seeker experience for Insiders and staged rollouts).
- Windows Server Update Services (WSUS) and management tooling where supported; administrators should validate WSUS product/classification selection to ensure the enablement package is visible in their console.
- Microsoft Endpoint Manager / Intune and deployment options that manage feature update exposure.
- ISOs and other images for offline installs or clean deployments will be offered via Insider resources and later general‑availability channels.
Operational implications and risks — an honest assessment
Strengths and operational wins
- Low friction upgrades: the eKB model reduces user downtime significantly and simplifies mass adoption.
- Faster security baseline: shipping code into monthly LCUs allows Microsoft to harden and deliver fixes continuously while keeping feature activation controllable.
- Reduced package churn: less bandwidth and faster deployments for enterprises with large fleets.
- Tighter control: the policy to remove default Microsoft Store apps gives admins a first‑party way to cut provisioning noise at OOBE and user sign‑in.
Concrete risks and compatibility headaches
- Legacy automation breakage: removing PSv2 and WMIC will break scripts, scheduled tasks, installers, and vendor agents that explicitly rely on those binaries. These breakages often surface only under real work loads.
- Staged code surprises: because new feature code sits on systems disabled for months, a later activation may reveal interactions with third‑party drivers or security agents that were not obvious during routine patch testing.
- Management tool nuance: WSUS/UUP/SCCM behaviors historically vary for enablement packages. In some environments the small eKB may not be obvious in the console or may be treated differently than traditional feature updates.
- Partial app removal artifacts: early reports indicate that policy‑based app removal can leave behind UI remnants (dead tiles or shortcuts) or may behave differently for existing vs new users. This requires validation of imaging and OOBE flows.
What IT teams should do right now — practical checklist and playbook
The change to a shared servicing branch and the deployment of 25H2 as an eKB makes careful, prioritized validation essential. Below is a practical, ordered playbook for IT teams.- Start with a targeted pilot:
- Enroll a small, representative set of machines (including laptops, desktops, and virtual images) in the Release Preview channel and install Build 26200.5074 to gauge impact.
- Inventory automation and tooling:
- Search for calls to
wmic.exeandpowershell -version 2across Group Policy scripts, SCCM packages, scheduled tasks, logon scripts, monitoring rules, and vendor agents. - Example PowerShell snippet to scan files and scripts:
Code:Get-ChildItem -Path 'C:\' -Include *.ps1,*.bat,*.cmd,*.vbs -Recurse -ErrorAction SilentlyContinue | Select-String -Pattern 'wmic|powershell.*-version\s*2' -SimpleMatch | Select-Object Path, LineNumber, Line - Scan scheduled tasks:
Code:Get-ScheduledTask | ForEach-Object { $_.Actions | Where-Object { $_.Execute -match 'wmic|powershell.*-version\s*2' } | Select-Object @{n='Task';e={$_.TaskName}}, Execute } - Migrate scripts and tooling:
- Replace WMIC usage with PowerShell CIM/WMI equivalents. Example conversions:
- WMIC:
wmic logicaldisk get name,size,freespace
PowerShell:Get-CimInstance Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace - WMIC:
wmic process where name='notepad.exe' get processid
PowerShell:Get-CimInstance Win32_Process -Filter "Name='notepad.exe'" | Select-Object ProcessId - For PSv2 reliance, test scripts under PowerShell 5.1 first; then validate against PowerShell 7 for cross‑platform modernization.
- Validate vendor agents:
- Contact third‑party vendors for compatibility statements and updated builds if their software invokes WMIC or relies on PSv2. Test vendor agents' behavior on the preview build.
- Test the app‑removal policy in a controlled lab image:
- Enable the “Remove Default Microsoft Store packages from the system” Group Policy/MDM CSP for Enterprise devices and validate both the provisioning behavior and the after‑effects across user accounts and OOBE.
- Check event logs for AppxDeployment‑Server operational entries and the expected Event ID indicating removal.
- Confirm distribution mechanics:
- For WSUS/SCCM environments, verify product and classification selections for Windows 11 and ensure your Software Update Point is configured for the new releases. Watch for UUP nuances where the enablement package may be composed inside larger UUP payloads.
- Plan rollout rings:
- Use phased rings (pilot → broad pilot → targeted deployment → full production) and keep rollback/restore steps ready, including uninstall steps for eKBs or standard feature‑update rollback procedures.
- Prepare rollback and recovery:
- Understand how to uninstall the enablement package in your management tooling (Intune, DISM, PowerShell Remove‑WindowsPackage, or Windows Update > View update history > Uninstall updates) and test rollback within your configured rollback window.
- Communicate with users:
- Inform stakeholders of the change, highlight that downtime is minimal (usually a single restart), and call out any likely user‑visible changes (removed apps, replaced behaviors).
- Monitor telemetry and logs post‑deployment:
- Track Windows update event channels, AppxDeployment logs, and endpoint monitoring for regressions.
Security analysis: gains and residual attack surface
Removing legacy tooling such as PowerShell 2.0 and WMIC reduces known attack avenues. Both have been used by threat actors for reconnaissance, lateral movement, and enabling persistence because they are signed, present on systems, and often allowed by default.- Immediate security gain: removing these utilities reduces living‑off‑the‑land (LoL) options for adversaries. This is meaningful for endpoint protection maturity.
- Longer‑term benefit: fewer legacy features mean the Windows attack surface is smaller and easier to harden.
- Residual risk: attackers adapt. Removing one LoL binary forces adversaries to use alternatives (PowerShell 7, WMI APIs directly, or other signed tools). Detection, policy controls, and behavior analytics must continue to evolve.
Developer and vendor impact
Software vendors and internal application teams must treat this release as a compatibility checkpoint:- Validate installers and prerequisites: some older installers attempted to enable or rely on PSv2 during setup. These installers may fail on 25H2 images.
- Eliminate direct calls to WMIC: replace with PowerShell CIM/WMI calls or programmatic WMI usage.
- Ship updates: vendors should publish guidance and updated agent versions that avoid legacy invocations.
- Update documentation: clarify supported platforms and remove references to legacy runtime requirements.
Practical examples: migration snippets and admin commands
- Replace WMIC disk query:
Code:# WMIC: wmic logicaldisk get name,size,freespace Get-CimInstance -ClassName Win32_LogicalDisk | Select-Object DeviceID,Size,FreeSpace - Replace WMIC process lookup:
Code:# WMIC: wmic process where name='notepad.exe' get processid Get-CimInstance -ClassName Win32_Process -Filter "Name='notepad.exe'" | Select-Object ProcessId - Search file system for legacy usages (example):
Code:# Finds occurrences of 'wmic' or explicit PowerShell v2 invocations in scripts Get-ChildItem -Path 'C:\Scripts','\\fileserver\share\scripts' -Include *.ps1,*.bat,*.cmd -Recurse -ErrorAction SilentlyContinue | Select-String -Pattern 'wmic|powershell.*-version\s*2' -SimpleMatch | Group-Object Path | Select-Object Name, Count - List scheduled tasks that may call legacy binaries (basic approach):
Code:Get-ScheduledTask | ForEach-Object { $task = $_ $task.Actions | Where-Object { $_.Execute -match 'wmic|powershell.*-version\s*2' } | ForEach-Object { [PSCustomObject]@{Task=$task.TaskName; Action=$_.Execute} } }
Quick checklist (one‑page summary for busy admins)
- Inventory: find WMIC/PSv2 references across scripts and agents.
- Test: install Build 26200.5074 in Release Preview on a pilot group.
- Migrate: replace WMIC calls and remove explicit PSv2 invocations.
- Validate: test vendor agents, imaging, OOBE, and provisioning with app‑removal policy enabled.
- Distribution: confirm WSUS/UUP/ConfigMgr/Intune visibility and deployment path.
- Rollback plan: verify removal/uninstall procedures for eKB in your management tooling.
- Monitor: check AppxDeployment logs and update telemetry post‑activation.
Conclusion
Windows 11, version 25H2 is not a dramatic visual overhaul — it’s a pragmatic, security‑focused iteration delivered as an enablement package that favors operational efficiency. For administrators, that combination of low user disruption and a refreshed servicing clock is a net positive, but the practical work is in the detail: auditing legacy automation, validating vendor compatibility, and testing policy changes around store app provisioning.The upgrade model makes mass adoption easier, but it also places a premium on proactive discovery and remediation. Treat the Release Preview build as the start of formal validation: prioritize discovery of WMIC and PowerShell v2 dependencies, test the new app‑removal policy under your imaging and OOBE workflows, and confirm your update pipelines can reliably deliver (and, if needed, remove) the enablement package. With the right preparation, the transition to 25H2 should be fast, secure, and — crucially — reversible during your validation window.
Source: TechPowerUp Windows 11 25H2 Preview Arrives as Lightweight Enablement Package
