Windows
View all Worklets
WindowsWindows

Disable PowerShell V2 on Win10

Disables PowerShell version 2.0 on Windows 10 endpoints to prevent attackers from bypassing security controls

Worklet Details

What the PowerShell V2 Disabler does

This Automox Worklet™ removes PowerShell version 2.0 from Windows 10 endpoints by disabling the MicrosoftWindowsPowerShellV2Root Windows optional feature. PowerShell v2 is a legacy scripting engine that ships with Windows but lacks the security features present in PowerShell 5.0 and later versions.

The Worklet uses the Disable-WindowsOptionalFeature cmdlet to remove the PowerShell v2 engine. By targeting the V2Root feature, it removes both the base PowerShell v2 engine and its dependencies. This prevents the -Version 2 parameter from being used to downgrade PowerShell sessions.

Windows 10 includes PowerShell v2 for backward compatibility with older scripts, but modern PowerShell (version 5.0+) handles most legacy scripts without issues. The performance and security benefits of removing v2 outweigh the minimal compatibility concerns in most environments.

Why disable PowerShell version 2.0

Attackers deliberately use PowerShell v2 to evade detection. The legacy engine lacks script block logging, module logging, and Antimalware Scan Interface (AMSI) integration. Running powershell.exe -version 2 creates a session where malicious scripts execute without generating detailed logs or triggering antivirus scans.

Red team tools and penetration testing frameworks commonly include PowerShell v2 downgrade techniques. Removing the legacy engine forces attackers to use modern PowerShell, where their activities generate logs and trigger security controls. This significantly improves detection capabilities for PowerShell-based attacks.

CIS Benchmarks and DISA STIGs recommend disabling PowerShell v2 as a security hardening measure. The Australian Signals Directorate includes PowerShell v2 removal in their Essential Eight mitigation strategies. Constrained language mode and other modern PowerShell security features only protect endpoints when the legacy engine is unavailable.

How PowerShell v2 removal works

  1. Evaluation phase: The Worklet first verifies the endpoint runs Windows 10 by checking the OS version (10.0.*). It then uses Get-WindowsOptionalFeature to check if MicrosoftWindowsPowerShellV2 is enabled or disabled. If the feature state is not 'Disabled', the endpoint requires remediation.

  2. Remediation phase: The Worklet runs Disable-WindowsOptionalFeature targeting MicrosoftWindowsPowerShellV2Root. The Root feature removes the entire PowerShell v2 stack. If the operation fails, the Worklet directs administrators to check the DISM log at %WINDIR%\Logs\Dism\dism.log for troubleshooting details.

PowerShell v2 removal requirements

  • Windows 10 (any edition)

  • PowerShell 5.0 or later

  • Administrative privileges to modify Windows features

  • No legacy scripts that explicitly require PowerShell v2 engine

Expected PowerShell security state after remediation

After remediation, attempts to start PowerShell with the -Version 2 parameter fail with an error indicating the feature is not installed. All PowerShell sessions run in the current engine version (5.1 or later on Windows 10), with full security logging and AMSI protection enabled. You can verify this change through the Automox Activity Log or by checking the endpoint configuration directly.

You can verify the removal by running Get-WindowsOptionalFeature -Online -FeatureName MicrosoftWindowsPowerShellV2 and confirming the state shows 'Disabled'. Alternatively, run powershell.exe -version 2 and verify it fails to start. Script block logging and module logging continue to capture all PowerShell activity for security monitoring.

How to validate disable powershell v2 on win10 changes

  1. Run this Worklet on a pilot Windows endpoint and review evaluation output for disable powershell v2 on win10.

  2. Confirm Automox activity logs show successful completion and exit code 0.

  3. Verify endpoint state using checks aligned to evaluation script logic, such as Write-Output, Get-WindowsOptionalFeature.

  4. Validate remediation effects from script operations such as Write-Output, Get-WindowsOptionalFeature, Disable-WindowsOptionalFeature, then rerun evaluation for compliance.

View in app
evalutation image
remediation image

Consider Worklets your easy button

What's a Worklet?

A Worklet is an automation script, written in Bash or PowerShell, designed for seamless execution on endpoints – at scale – within the Automox platform. Worklet automation scripts perform configuration, remediation, and the installation or removal of applications and settings across Windows, macOS, and Linux.

do more with worklets