Disable PowerShell V2 on Win10

What the PowerShell v2 disabler does

This Automox Worklet™ disables the legacy PowerShell v2 engine on Windows 10 endpoints by turning off the MicrosoftWindowsPowerShellV2Root Windows optional feature. The engine ships with Windows for backward compatibility with scripts written before 2009, but the Windows installation also includes PowerShell 5.1, which runs the same script set on every supported Windows 10 build. Removing v2 collapses the engine surface back to a single, instrumented runtime.

The Worklet calls Disable-WindowsOptionalFeature with -FeatureName MicrosoftWindowsPowerShellV2Root, which is the parent feature that owns both the v2 engine and the underlying CLR 2.0 runtime hook. Disabling the Root feature blocks the powershell.exe -Version 2 command line and prevents any host process from launching the older engine through the System.Management.Automation namespace. The change is persistent across reboots and survives Windows quality updates.

PowerShell 5.1 handles the legacy script syntax the v2 engine was kept around for, so the compatibility cost in most production fleets is minimal. The evaluation script gates on [System.Environment]::OSVersion.Version matching 10.0.* before touching the feature, which covers Windows 10, Windows 11, and Server 2016 or later in the same code path; anything older (Windows 7, 8.1, Server 2012 R2) writes Unsupported Windows Version and exits 0 without changes.

Why remove the PowerShell v2 engine

PowerShell v2 is a deliberate evasion path, not a dormant compatibility shim. The v2 engine predates Antimalware Scan Interface (AMSI), script block logging, module logging, transcription, and constrained language mode. An attacker who already has code execution can run powershell.exe -Version 2 to spawn a session where in-memory script content is never inspected by AMSI and never written to the Microsoft-Windows-PowerShell/Operational event log (event IDs 4103 and 4104). Offensive toolkits like Empire, Nishang, and PowerSploit historically used this downgrade as their first action on a Windows host, and modern red-team playbooks still reach for it when newer engines log too aggressively.

CIS Microsoft Windows 10 Benchmark control 18.10.7 calls for the v2 engine to be disabled, and DISA STIGs for Windows 10 and Server 2016 carry the same finding. The Australian Signals Directorate Essential Eight mitigation strategies list PowerShell v2 removal as a control under application hardening. This Worklet calls Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root on every endpoint that reports the feature in any state other than Disabled. Windows still considers the v2 engine an optional feature rather than a deprecated component, so the policy has to assert its removal rather than rely on a vendor end-of-life path.

How PowerShell v2 enforcement works

1. Evaluation phase: The Worklet first matches [System.Environment]::OSVersion.Version against 10.0.* to confirm the endpoint is Windows 10 and exits 0 on anything else so non-applicable endpoints stay compliant. It then runs Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 and reads the .State property. A state of Disabled exits 0 with Compliant; any other state (Enabled, EnablePending, or DisablePending after a half-applied change) exits 1 and flags the endpoint for remediation.

2. Remediation phase: The remediation script re-checks the feature state and, if it is anything other than Disabled, runs Disable-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2Root inside a try/catch. Targeting the Root feature instead of MicrosoftWindowsPowerShellV2 alone removes the v2 engine binaries and the CLR 2.0 runtime registration in one DISM transaction. On failure, the Worklet writes an error pointing administrators to %WINDIR%\Logs\Dism\dism.log and exits 1; on success it writes Successfully disabled PowerShellV2 and exits 0.

PowerShell v2 removal requirements

• Endpoints reporting an OS version matching 10.0.* (Windows 10, Windows 11, and Server 2016 or later); the script writes Unsupported Windows Version and exits 0 on Windows 7, 8.1, and Server 2012 R2 without modifying them

• PowerShell 5.0 or later available in the runtime path so Get-WindowsOptionalFeature and Disable-WindowsOptionalFeature resolve to the Dism PowerShell module

• Administrative privileges on the endpoint; the Automox agent runs as SYSTEM by default and already satisfies this

• No production scripts that explicitly require the v2 engine via #requires -version 2.0 or powershell.exe -Version 2; inventory these before broad deployment

• Disk space and a clean DISM image on the endpoint; corrupt component stores will surface in %WINDIR%\Logs\Dism\dism.log and require a DISM /Online /Cleanup-Image /RestoreHealth pass before the feature change succeeds

Expected PowerShell engine state after remediation

After remediation, Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 reports a State of Disabled, and the parallel MicrosoftWindowsPowerShellV2Root feature reports the same. Launching powershell.exe -Version 2 returns an error stating that PowerShell 2.0 could not be started because the required engine is not installed. Every PowerShell session on the endpoint runs in the 5.1 engine instead, which means script block logging (event ID 4104) and module logging (event ID 4103) capture the script content sent to the runtime, AMSI inspects in-memory script and command-line payloads, and constrained language mode is honored when enforced by policy.

Validate at scale by querying the Microsoft-Windows-PowerShell/Operational event log for event ID 400 entries with HostVersion set to 2.0 across the fleet; a zero count after remediation confirms no host process is still downgrading. For per-endpoint spot-checks, run Get-WindowsOptionalFeature -Online | Where-Object FeatureName -like 'MicrosoftWindowsPowerShellV2*' and confirm both features show Disabled. Pair this Worklet with policies that enable PowerShell script block logging and module logging so the logging surface restored by removing v2 actually captures the data you now expect.