Microsoft’s quiet pruning of Windows’ optional components has accelerated into a visible change in how the operating system presents and manages
what stays and what goes, and the consequences go far beyond a few removed checkboxes in Settings. Over the past two years Microsoft has moved from deprecation notices to actual removals and delivery-model changes — decommissioning legacy runtimes, stripping seldom-used inbox apps, and reclassifying certain capabilities as
Features on Demand. For IT teams, endpoint defenders, and power users this means new opportunities (smaller images, fewer attack surfaces) and new risks (broken scripts, incompatible workflows, unexpected behavior after upgrades). This article unpacks the recent removals, explains the operational mechanics administrators need to know, weighs benefits against risks, and gives practical, step-by-step guidance to prepare your estate for a future in which Windows optional features are more actively curated by Microsoft.
Background / Overview
Microsoft has offered optional Windows features for decades: small components that ship in the image or are available as installable payloads and can be enabled or disabled by administrators. Historically these have ranged from small utilities (WordPad, Notepad historically) and legacy runtimes (PowerShell 2.0, VBScript) to modern infra utilities surfaced as “Optional features” in Settings or the classic “Turn Windows features on or off” dialog.
In recent releases Microsoft has done several related things at once:
- Moved some historically external tools into the OS as optional features serviced by Windows Update (for example, Sysmon in recent Insider flights).
- Marked older apps or runtimes as deprecated and then removed them from the installed image during upgrade.
- Clarified that Features on Demand payloads are delivered through Windows Update, meaning removing a feature removes its payload from disk and reinstallation requires network access.
- Increased enforcement around security-driven removals (for example, deprecating VBScript and removing low-security components).
These moves are not randomly targeted; they’re part of a sustained effort to reduce attack surface, simplify servicing, and align Windows with modern enterprise expectations about manageability and platform hygiene.
What Microsoft has removed (and why it matters)
WordPad, Cortana, Tips — from preinstalled to decommissioned
Microsoft signalled that several legacy inbox apps would be deprecated and removed as part of ongoing cleanup. WordPad — a nearly three-decade-old basic rich-text editor that became an Optional Feature in recent Windows 10 Insider builds — was explicitly marked deprecated and removed from the installed image when devices upgraded to certain Windows 11 feature updates. The same lifecycle applied to some consumer-facing utilities like Cortana and the Tips app, which moved from being preinstalled experiences to either deprecated components or optional removals during upgrades.
Why it matters:
- Users who relied on WordPad as a lightweight offline editor must install an alternative (Notepad, a modern text editor, or a third-party word processor).
- Enterprises that used WordPad in OOBE or managed help flows may need to adjust documentation and golden images.
Location History — turning an API off
Microsoft removed the Location History feature — an API that persisted 24 hours of device location history for certain services — as part of a controlled feature rollout. The removal means the corresponding Settings toggles are gone and local location history is no longer stored by the OS in the same way.
Why it matters:
- Privacy-conscious administrators may welcome the reduction in locally-held sensitive telemetry.
- Apps that relied on local device Location History APIs will need to adjust to the change or request the data directly from different services.
PowerShell 2.0 and other legacy runtimes
PowerShell 2.0 — a legacy runtime introduced in the Windows 7 era and long deprecated — was removed from the image in recent servicing cycles. Microsoft has encouraged customers to move to PowerShell 5.1 or PowerShell 7.x. Similarly, Microsoft announced staged deprecation of VBScript: first making it an on-demand feature, then disabling it by default, and planning eventual removal.
Why it matters:
- Older scripts and appliances that still call PowerShell 2.0 or rely on VBScript behavior will break on upgraded machines unless rewritten or otherwise accommodated.
- Security teams generally welcome the removal; these older runtimes are common attack vectors and maintenance liabilities.
The policy-driven angle: Europe and regulatory drivers
Microsoft’s decisions around removability have also been influenced by regulatory regimes. Where regulations require software choice — for instance, making alternative browsers or services available in the EEA — Microsoft has been compelled to make features removable or configurable. That creates a precedent where components may be offered as optional remove-able pieces to comply with legal regimes while still being tightly managed elsewhere.
Why it matters:
- Regulatory obligations can accelerate Microsoft’s willingness to separate components from the installed image.
- Enterprises operating across regions must track local availability and removability differences.
The operational model: how optional features are now delivered and removed
Understanding the plumbing behind “Optional features” is essential for any IT pro.
- Features on Demand (FOD): Many optional features live as Features on Demand — payloads that are not kept in the installed image but are downloaded from Windows Update when enabled. Removing such a feature frees disk space but means reinstallation requires connectivity to Windows Update (or a local WSUS/WSUS Offline cache).
- Controlled Feature Rollout (CFR): Microsoft uses staged rollouts to gate features. Installing the same build on two test machines may expose different sets of optional features based on CFR gating.
- Settings / Optional features UI: The Settings app shows Installed features and available Features so users and admins can add or remove without command line.
- DISM and PowerShell: Command-line administration remains the authoritative method for scripting and automation:
- Dism /Online /Get-Features
- Dism /Online /Enable-Feature /FeatureName:<name>
- Enable-WindowsOptionalFeature /Online -FeatureName <name>
- Get-WindowsOptionalFeature -Online
- Servicing via Windows Update: When an optional feature is updated, Microsoft can deliver updates via Windows Update. When features are removed from the image at upgrade time, the upgrade flow may automatically uninstall the component.
Practical consequence:
- Removing an optional feature often removes its payload from disk, shrinking the image but requiring network access to restore it. For offline imaging and gold images, administrators must include or cache required payloads.
Benefits — why Microsoft and many admins approve of this trimming
- Reduced attack surface: Legacy runtimes and seldom-used utilities are common vectors for exploitation. Removing them reduces the platform’s exposure.
- Smaller images and fresher baselines: Removing unused payloads saves disk space and simplifies images for cloud and device builders.
- Better lifecycle control: Features on Demand with Windows Update servicing reduces version drift for optional components (and for components Microsoft chooses to bring under the Update channel).
- Explicit admin control: By making components optional and visible in Settings/PowerShell, Microsoft improves clarity about what’s installed and what’s supported.
- Encourages modernization: Removing old runtimes nudges organizations toward supported tooling (PowerShell 7.x, modern APIs) and better security practices.
Risks and unintended consequences — where the pruning can hurt
- Broken legacy scripts and automation: Anything that depends on a runtime that’s now removed (PowerShell 2.0, VBScript) will fail. Rewriting scripts at scale is not trivial.
- Unexpected behavior after upgrades: If an optional component is removed automatically by an upgrade, users and field engineers may face missing functionality without obvious cause.
- Offline or air-gapped environments: When payloads are removed from the image, reinstalling them requires connectivity or explicit caching; disconnected environments can lose the ability to re-add features easily.
- Third-party software compat issues: Some vendors ship or rely on Windows features being present; removing them without vendor coordination risks breaking support contracts and production systems.
- Perception vs reality on “security”: Removing a component reduces risk but does not eliminate the need for defense-in-depth; administrators should not assume a removed feature eliminates all related threats.
Practical, step-by-step guidance for IT and security teams
If you manage Windows endpoints at scale, treat the feature removals like a planned platform change. This checklist helps you take practical steps to adapt.
1. Audit your estate for optional-feature usage
- Run inventory scripts that query for installed optional features:
- Use Get-WindowsOptionalFeature -Online in PowerShell on representative machines.
- Use Dism /Online /Get-Features to enumerate available and enabled features.
- Look for evidence of:
- Legacy runtime usage (VBScript-centric processes, old PowerShell versions).
- Inbox apps used in support or user workflows (WordPad, Tips, Cortana).
- Prioritize findings by how many devices rely on the feature and by risk impact.
2. Identify hard dependencies and vendor impacts
- Engage vendors: Ask ISV and line-of-business app owners whether their software demands a given runtime or optional component.
- Flag appliances or imaging tools that expect a feature to be present.
3. Build test plans and pilots
1.) Create a small pilot group that mirrors production: a mix of heavy users, task workers, and admin machines.
2.) Upgrade a controlled pilot to a Windows release that removes the feature to see actual impact.
3.) Validate key workflows: sign-on flows, scripted installs, imaging, and OOBE experiences.
4. Prepare fallbacks and replacements
- For WordPad or other removed apps: standardize on a supported app (Notepad, Notepad++, Office/LibreOffice) and deploy via policy.
- For legacy scripting: convert PowerShell 2.0 scripts to PowerShell 7.x or reimplement logic in supported languages. Where conversion is not immediately possible, contain execution to managed legacy hosts or containers.
- For offline environments: build and retain offline branch-cached FOD payloads or local WSUS repositories to preserve the ability to re-add features.
5. Update imaging and deployment pipelines
- If your golden images relied on an optional feature, ensure:
- The image is recreated with the feature included if necessary, or
- Install steps in provisioning pipelines re-enable the feature from an internal repository.
- For cloud VM images and Azure images, decide whether to include or exclude features based on performance and security posture.
6. Governance: policies, logging, alerts
- Add rules that detect removal of critical optional components during upgrade and alert support teams.
- Standardize test automation that checks for presence of required features as part of device health checks.
7. Communication and documentation
- Communicate changes to end users: explain that WordPad or a setting was removed and provide alternatives.
- Update runbooks and playbooks to account for removed components.
Technical nuance and edge cases administrators must test
- Reinstallation behavior: Removing a feature that is FOD will drop payloads; an attempt to re-enable will trigger a download from Windows Update or WSUS — test this behavior on machines that use WSUS and on those that are fully offline.
- Driver or service conflicts: For components that install services or drivers (Sysmon, for instance, when added as an in-box optional feature), ensure that previously-installed third-party copies are uninstalled to avoid driver/service conflicts.
- Event log and telemetry parity: When Microsoft brings community tools into the OS as optional features (Sysmon being added as an illustrative example), validate that event IDs, fields, and channels remain compatible with your SIEM parsing rules.
- Registry, permissions, and GPO differences: Some features change registry keys or system defaults when removed; ensure group policies and configuration management are aligned.
Security and compliance implications
Removing legacy runtimes and inbox applications lowers the attack surface, but it is not a silver bullet.
- Compliance benefits: Fewer installed legacy components means a smaller validated surface to scan and secure for compliance standards.
- Data protection: Removing features like local Location History reduces the amount of sensitive information stored on endpoints; review retention policies and update privacy notices accordingly.
- Incident response: If your response playbooks expected certain logs or behaviors from a component that’s removed, you must update playbooks and detection engineering accordingly.
Takeaway: Removal helps but requires corresponding updates to detection, logging, and governance.
Examples and real-world scenarios
Scenario A — legacy imaging for manufacturing kiosks
A manufacturer keeps a fleet of kiosk devices that run a legacy app requiring VBScript-hosted automation. Upgrading those devices to a Windows build that disables VBScript by default or removes it entirely breaks the kiosks. The correct path:
- Identify the devices via inventory.
- Keep them on a validated branch with long-term servicing, or
- Containerize the legacy app in an environment where VBScript is still available, or
- Recode the automation to a supported platform.
Scenario B — security team enabling Sysmon natively
An enterprise security team pilots the new in-box Sysmon optional feature to simplify deployment. They must:
- Uninstall existing standalone Sysmon on pilot machines to avoid conflict.
- Validate that the in-box feature writes events to the same channel and that the SIEM parsers ingest fields unchanged.
- Design a plan for global rollout that includes tuning configurations to avoid log bloat and ingestion costs.
Scenario C — disconnected government/VPNed endpoints
A government office uses air-gapped devices that rely on certain optional features. Removal of feature payloads forces an inability to re-add components. The mitigation:
- Keep an internally sourced, WSUS-hosted copy of the feature payloads or use an internal package repository to restore features after removal.
Recommendations — a concise playbook for the next 90 days
- Inventory now: run inventory scripts and identify optional-feature dependencies across your estate.
- Pilot upgrades: pick a controlled set of machines and test the upgrade path that removes or changes optional features.
- Vendor outreach: ask critical ISVs about support for removed or deprecated features.
- Update detection and logging: revise SIEM rules and playbooks for any change to telemetry sources.
- Prepare caching: for offline environments, prepare WSUS or offline payloads for Features on Demand.
- Plan script modernization: allocate sprint work to modernize legacy scripts and migrate to supported run-times.
- Communicate to stakeholders: end users, support teams, and procurement should all be informed and given remediation paths.
Final analysis — balancing Microsoft’s maintenance strategy with organizational resilience
Microsoft’s trimming of optional Windows features reflects a trade-off: cleaner, smaller, and more secure platforms, but also a faster-moving baseline that can destabilize legacy-dependent environments. For many organizations this is positive — fewer attack vectors, simplified servicing, and a clearer path toward modern tooling. For others, especially enterprises with long-tail legacy apps, the pace and scope of removals can impose meaningful technical debt to resolve.
The sensible middle path is deliberate preparation: treat feature removals like a platform upgrade of equivalent importance. Inventory, vendor coordination, pilot testing, and robust rollback or remediation options are not optional — they are essential. When done thoughtfully, the net outcome is improved security posture, modernized tooling, and simplified Windows life‑cycle management. When skipped, these removals risk surprises that ripple from helpdesks to production systems.
Microsoft will continue to iterate on which components are delivered as features, which are external, and which get the axe. Administrators who accept that change as a constant and built their processes to detect, test, and adapt will convert risk into opportunity: leaner endpoints, more predictable updates, and clearer operating assumptions across the fleet.
In short: don’t treat “optional feature removed” as a small checkbox change. Treat it as a managed platform change — inventory first, test second, communicate third, and automate the remediation path so your devices and users are never caught off guard.
Source: Neowin
https://www.neowin.net/news/microsoft-is-removing-an-optional-windows-feature/