Microsoft has pushed a new Beta Channel release to Windows Insiders today:
Windows 11 Insider Preview Build 26220.8062 (KB 5079458) — a broadly scoped cumulative that mixes administrative tooling changes, a security-focused driver policy pilot, setup and recovery refinements, and a handful of usability experiments that continue Microsoft’s staged, enablement‑package approach for the Windows 11 25H2 wave. (
blogs.windows.com)
Background
Microsoft is distributing this update as part of the Beta Channel’s ongoing flighting for Windows 11, version
25H2, delivered via enablement package semantics rather than a full rebase for devices already on 24H2. That model lets Microsoft flip features on gradually while using Controlled Feature Rollout telemetry to step changes into a subset of Insiders before broadening deployment. For enterprise and IT teams the net effect remains: expect incremental changes that may alter group policy, Intune behavior, driver trust, and user OOBE experiences. (
blogs.windows.com)
This build surfaces several items of interest to IT administrators and security teams — most notably a dynamic extension of the
Remove Default Microsoft Store packages Group Policy and a kernel policy pilot that removes default trust for legacy cross‑signed kernel drivers while preferring drivers validated through the
Windows Hardware Compatibility Program (WHCP). Microsoft has placed the driver change into
audit mode to reduce immediate disruption, but the implications are significant and worth unpacking below. (
blogs.windows.com)
What shipped in Build 26220.8062 (high level)
- A dynamic app removal list has been added to the Group Policy setting Remove Default Microsoft Store packages from the system, enabling administrators to specify additional Package Family Names (PFNs) for MSIX/APPX apps to be prevented from provisioning. Intune CSP support lags the preview and OMA‑URI validation for multi‑entry ADMX text fields remains a limitation. (blogs.windows.com)
- The Windows Setup (OOBE) flow now provides a clearer, explicit option to choose a custom user folder name on the Device Name page during first‑boot setup. If skipped, Windows continues to use the default folder name. (blogs.windows.com)
- A kernel driver trust change: Windows will remove default trust for older cross‑signed kernel drivers and prefer drivers issued via WHCP; Microsoft is running a 100‑hour / 3‑reboot audit window to confirm compatibility before turning enforcement on. A driver block toast and remediation guidance are shown when enforcement detects incompatible drivers. (blogs.windows.com)
- Point‑in‑time restore received UX and messaging updates: administrators launching the restore tool will now see a UAC‑guarded settings dialog to change defaults, a list of available restore points, a recommended “plug into power” message in WinRE, and the OS version now shown in a four‑part format. (blogs.windows.com)
- Usability experiments and smaller updates: Drag Tray has been renamed to Drop Tray and moved from Nearby Sharing to System > Multitasking; Pen settings get minor refinements (a new “Same as Copilot key” option); context‑menu refinements in File Explorer have been temporarily paused while Microsoft reworks them; a stray sfc/scannow error has been removed. (blogs.windows.com)
Deep dive: Policy‑based removal of preinstalled Microsoft Store apps
What changed
The existing Group Policy setting that admins have used to manage preinstalled Microsoft Store apps —
Remove Default Microsoft Store packages from the system — now supports a
dynamic multi‑entry list where admins can add Package Family Names (PFNs) for apps they want to prevent from provisioning. Microsoft shows the concrete PowerShell hint for finding a PFN (for example,
Get-AppxPackage *Notepad* | Select-Object PackageFamilyName) and documents the Group Policy path. (
blogs.windows.com)
Why this matters for IT teams
- It replaces many one‑off scripting approaches with a managed policy surface that prevents apps from being provisioned on new user profiles, simplifies fleet standardization, and reduces the need for per‑device PowerShell remediation. This is particularly important for organizations that need to minimize consumer‑oriented app footprints on corporate endpoints.
- The policy is scoped to Enterprise and Education SKUs in the current rollout—Windows 11 Pro is not guaranteed to see parity at the same time—so admins should validate expectations across their device estate. Many community guides and admin write‑ups already recommend testing locally with Group Policy before attempting broad Intune deployments.
Important limitations and the Intune story
Microsoft’s blog states the dynamic list is
currently not available in the corresponding Intune CSP in the Windows Insider Preview (WIP) stage; Intune Settings Catalog support is expected later. Additionally, Microsoft flags an important technical constraint:
OMA‑URI cannot validate multi‑entry ADMX multi‑Text policies, which means administrators who rely on OMA‑URI to configure such policies may receive limited validation feedback — the configuration must be performed and validated through the Settings Catalog in Intune or Group Policy while testing. This is not a theoretical quirk; in practice it affects how you automate and test deployment at scale. (
blogs.windows.com)
Practical guidance for deployment
- Use Local Group Policy to test behavior on a representative device before attempting Intune or GPO rollouts.
- Collect PFNs using PowerShell (
Get-AppxPackage -AllUsers or the specific Get-AppxPackage *appname* | Select-Object PackageFamilyName) and store them in your change control repository.
- Where Intune is required, monitor the Settings Catalog for the new entry and use targeted pilot groups when the Intune CSP becomes available. In the interim, avoid OMA‑URI multi‑entry constructs that cannot be validated. (blogs.windows.com)
Deep dive: Kernel driver trust change — risk, mitigation, and timeline
What Microsoft is changing
Historically the Windows kernel allowed 3rd‑party kernel drivers that were signed under older cross‑signed root programs. Microsoft is
removing default trust for cross‑signed drivers and pivoting to the
Windows Hardware Compatibility Program (WHCP) as the default trust path for third‑party kernel drivers. To prevent immediate breakage, Microsoft is enabling the change in
audit mode for a minimum of
100 hours and three reboots; if telemetry shows the drivers loaded are compatible with the policy, enforcement will be enabled. If incompatibilities are observed, the system remains in audit mode. (
blogs.windows.com)
Why this matters now
- Kernel drivers are a major attack surface. Moving away from legacy cross‑signed trust reduces the risk of malicious or poorly vetted kernel drivers running at ring‑0. WHCP requires additional vetting, compatibility testing, and (in many workflows) automated scanning that raises the bar for driver quality. Microsoft and partner programs have been steering partners toward WHCP and stricter validation for some time.
- The switch can, however, impact older or niche hardware whose vendors have not migrated to WHCP signing. For devices that rely on cross‑signed drivers that are still functionally required, admins could see drivers blocked in enforcement mode. Microsoft recognizes that and uses the audit window to detect and measure impact before flipping enforcement. (blogs.windows.com)
Practical risks and mitigations
- Inventory first: build a driver inventory across your estate using tools such as driver query, WMI/PowerShell querying, or your existing endpoint management inventory reporting (SCCM/Intune). Focus on kernel‑mode drivers (print filters, antivirus drivers, virtualization, networking/filter drivers).
- Test the audit behavior: enroll a lab or pilot group into the Beta Channel or simulate the build’s policies to observe the system’s audit logs/telemetry. Microsoft’s messaging indicates a driver block toast will be shown when enforcement is active; capture and analyze those events during pilot testing. (blogs.windows.com)
- Vendor engagement: reach out to hardware and ISV vendors for WHCP guidance, and encourage driver updates or attestation submissions if required. Microsoft’s partner and driver‑submission tooling has tightened rule sets in recent months; run InfVerif and HLK where practical to validate driver packages prior to deployment.
Recommended timeline for IT
- Immediately gather a driver inventory and classify vendors by WHCP readiness.
- Run pilot testing with the new Beta build in a small, controlled ring for at least the 100‑hour audit period while monitoring events.
- Coordinate vendor remediation plans for drivers that show compatibility warnings or blocks.
- Delay broad enforcement rollouts until vendor fixes and imaging processes are confirmed. (blogs.windows.com)
Setup and recovery improvements: user folder naming and point‑in‑time restore UX
Custom user folder name in OOBE
A modest but meaningful change for those who image devices or manage OOBE experiences: Windows Setup now surfaces a
user folder naming option on the Device Name page during initial setup. This gives hands‑on techs and end users an explicit place to choose the local profile folder name (e.g., to avoid unusually long or non‑compliant usernames that break scripts). If the step is skipped, Windows falls back to the normal default folder naming behavior. This change simplifies support cases where scripts or legacy apps expect predictable profile paths. (
blogs.windows.com)
Tip: enforce standard Windows name constraints in your provisioning documentation; the setup dialog will not override naming rules. (
blogs.windows.com)
Point‑in‑time restore: admin settings and WinRE messaging
Point‑in‑time restore — Microsoft’s step beyond System Restore — now presents a
UAC‑guarded settings dialog to local admins when launched, surfaces a
list of available restore points, and updates WinRE messaging to recommend plugging the device into power during restores. It also shows the OS version using a four‑part format (major.minor.build.revision), which aids clarity when restoring machines across servicing branches. For helpdesk workflows and automation, the expanded visibility will reduce accidental misrestores and make restore targeting easier. (
blogs.windows.com)
Usability experiments and small‑but‑useful changes
Drag Tray renamed to Drop Tray
Microsoft has
renamed the Drag Tray to Drop Tray and moved its toggle from Settings > Nearby Sharing into
System > Multitasking. Functionally this continues Microsoft’s experiment with a top‑screen drop target for drag‑and‑drop file sharing, but the reclassification signals the feature is moving from “sharing” semantics toward windowing/multitasking behavior, which may affect discoverability for support staff. Previous coverage of the Drag Tray shows the feature is already useful for multi‑file sharing and app discovery when dragging files. (
blogs.windows.com)
Pen settings and the Copilot key
Pen tail button behavior receives a small addition: a new option called
“Same as Copilot key” allows the pen tail to launch the same app bound to the Copilot key. For pen‑centric workflows — surface devices, digitizer tablets, and signature capture scenarios — this provides a consistent one‑button launch pattern for Microsoft’s Copilot integrations or other Copilot-bound actions. (
blogs.windows.com)
File Explorer context menu rollout paused
Microsoft says it has
stopped the rollout of context‑menu refinements to work on further improvements. If you saw changes last week and relied on them for workflows, expect that Microsoft will reintroduce a revised implementation in a future flight. This rollback demonstrates Microsoft’s willingness to iterate after early feedback. (
blogs.windows.com)
Operational guidance for administrators and security teams
Validate the Beta build and plan rollout rings
- Treat Beta Channel builds like early pre‑production candidates: use isolated pilot rings for imaging and driver testing. Don’t assume parity across Pro/Ent/Edu SKUs for new policies (the app removal policy is explicitly Enterprise/Education scoped now). (blogs.windows.com)
- For imaging pipelines and provisioning automation, confirm whether your task sequences, imaging scripts, or management agents reference user profile paths or rely on specific inbox Store apps. The new user folder option and app removal policy can both change assumptions baked into imaging templates. (blogs.windows.com)
Intune and automation: wait for Settings Catalog parity
- If your organization automates configuration with Intune, hold off on wholesale CSP/Oma‑URI rollouts for this feature until Intune’s Settings Catalog offers the new multi‑entry field. OMA‑URI cannot validate ADMX multi‑text entries, so OMA‑URI approaches risk misconfiguration without the Settings Catalog validation path. Microsoft’s blog explicitly calls this out as a known limitation for WIP. (blogs.windows.com)
Driver policy: inventory, vendor engagement, and fallback paths
- Create a prioritized remediation plan for kernel drivers that are cross‑signed but not WHCP‑ready. For business‑critical drivers, coordinate with vendors to obtain WHCP/attestation‑signed updates. If vendor updates are not forthcoming, consider isolation or replacement strategies (e.g., virtualizing the workload, moving to a supported hardware model, or leveraging kernel mitigation workarounds where safe).
Logging and incident playbooks
- Monitor System and Application event logs for driver‑related audit entries during the 100‑hour window; collect crash and stop‑error reports from pilot machines. Prepare playbooks to roll back the feature (or pause the Insider toggle for pilot machines) if essential drivers are blocked. (blogs.windows.com)
Security and compliance analysis
Strengths
- The driver policy move represents a meaningful hardening of Windows’ kernel trust model. By defaulting to WHCP and removing legacy cross‑sign trust, Microsoft reduces the attack surface and raises the bar for kernel‑level malware and vulnerable drivers. The audit window is a pragmatic approach to reduce collateral damage. (blogs.windows.com)
- Centralizing app removal into a managed Group Policy (and eventually an Intune Settings Catalog policy) will significantly reduce ad‑hoc removal scripts, lowering management overhead and making compliance with device baselines more repeatable.
Potential weaknesses and risks
- Vendor inertia is the short‑term risk. Smaller ISVs and OEMs that haven’t migrated driver signing processes to WHCP may leave devices in a limbo where critical drivers fail — particularly in specialized environments using bespoke hardware. The complexity of driver certification tools (InfVerif, HLK) and the partner enrollment process adds friction.
- Intune CSP lag and OMA‑URI validation gaps create an automation gap that could lead to configuration drift or silent misconfigurations if admins try to force the new policy via unsupported MDM paths. This will be most visible in large, heterogeneous fleets where the Settings Catalog entry isn’t yet present. (blogs.windows.com)
- Controlled Feature Rollout means feature availability will be inconsistent across devices; this complicates helpdesk troubleshooting when two otherwise identical machines behave differently because one has a feature enabled by the toggle and the other does not. Document the state of the toggle and pilot rings in your support knowledgebase. (blogs.windows.com)
Checklist: What I recommend you do in the next 30–90 days
- Inventory: Export a complete driver and inbox Store app inventory from representative devices (PowerShell + endpoint management). Use
Get-AppxPackage -AllUsers to enumerate PFNs where needed.
- Pilot: Create a small Beta pilot ring that includes imaging, AV, VPN, printing, and virtualization use cases. Run the 100‑hour audit window and monitor logs for driver audit entries and block notifications. (blogs.windows.com)
- Vendor outreach: For any kernel drivers showing audit failures or compatibility warnings, open support cases with vendors and request WHCP/attestation‑signed packages. Track remediation timelines.
- Intune readiness: Do not deploy the dynamic app removal policy via OMA‑URI multi‑entry constructs. Wait for Settings Catalog support or validate via local Group Policy until Intune CSP is available in production. (blogs.windows.com)
- Update documentation: Amend imaging and support runbooks to note the new OOBE user folder selection and the location of the Drop Tray toggle (System > Multitasking). (blogs.windows.com)
What this flight tells us about Microsoft’s direction
This Beta build reinforces three clear priorities in Microsoft’s roadmap for Windows 11:
- Security hardening at the kernel level. Driver signing and WHCP emphasis show a continued push to reduce low‑level attack surfaces and raise the cost of shipping kernel code without rigorous vetting. The audit‑then‑enforce pattern indicates Microsoft is attempting to balance security with operational continuity. (blogs.windows.com)
- Administrative control and enterprise policy improvements. The dynamic app removal list and the push to give admin teams policy‑first controls over provisioning reflects a response to years of enterprise demand for deterministic baselines without brittle scripting workarounds.
- Iterative UX experiments with careful rollback. Changes such as Drag Tray → Drop Tray, pen tail options, and paused File Explorer context menu rollouts show that Microsoft is experimenting with discoverability and workflow optimizations — but they are prepared to pause and rework when feedback or telemetry demands it. (blogs.windows.com)
Final verdict: Who should care most, and why
- Enterprise security teams and platform owners should prioritize driver inventory and vendor engagement now. The WHCP‑centric trust model marks a structural change that could affect devices with legacy kernel drivers. (blogs.windows.com)
- Systems management and Intune teams should track the Settings Catalog rollout and plan to migrate from script‑based removal of Store apps to the managed policy once Intune CSP support lands. Avoid OMA‑URI multi‑entry attempts that can’t be validated. (blogs.windows.com)
- Helpdesk and support engineers should update knowledge base articles for the new OOBE user folder option, the Drop Tray location change, and temporary fluctuations in File Explorer context menu behavior. (blogs.windows.com)
- Power users and Insiders should expect modest UX tweaks (pen behavior, Drop Tray) and continue to share feedback via Feedback Hub as Microsoft refines these experiments. (blogs.windows.com)
Conclusion
Build 26220.8062 is a noteworthy Beta Channel release because it couples
administrative tooling improvements with a
security‑centric driver policy trial — two changes that will materially affect how organizations manage Windows fleets. The dynamic app removal list promises to simplify debloating and provisioning control, but the current Intune and OMA‑URI validation gaps mean administrators must test and stage changes carefully. The kernel trust policy is the most consequential change: Microsoft has chosen an audit‑first approach to limit disruption, but this is a clear signal that WHCP is the path forward for kernel code that intends to run on modern Windows devices.
If you manage Windows images or critical endpoint drivers, start with a driver inventory, schedule a controlled pilot of this Beta build, and engage vendors early. For configuration teams, wait for native Intune Settings Catalog support before automating the new app removal list broadly. Above all, treat this flight as a preview of how Microsoft will push more security and admin control deeper into the platform — and plan accordingly. (
blogs.windows.com)
Source: Microsoft - Windows Insiders Blog
Announcing Windows 11 Insider Preview Build 26220.8062 (Beta Channel)