WSL2: Administrator Accounts and PowerShell Installation

WSL2 installation errors on administrator accounts typically stem from permission restrictions, missing virtualization features, or PowerShell execution policies blocking the setup script. By ensuring Hyper-V and Virtual Machine Platform roles are enabled, configuring the correct firewall rules, and adjusting script execution permissions, you can resolve most common failure points during the initial configuration phase.

Enabling Required Windows Features

The primary cause of WSL2 installation failures is the absence of core Windows hypervisor components. Even with an administrator account, these features must be explicitly activated before the Linux distribution can initialize. Open PowerShell as Administrator and run the following command to enable both the necessary features:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

After executing these commands, you must restart your computer for the changes to take effect. This step is critical because the kernel modules are loaded at boot time. Without a reboot, subsequent attempts to install a Linux distribution will fail with generic error codes indicating that the subsystem is not ready. If you encounter issues related to networking after this step, refer to our guide on WSL Distribution Networking Only When Version Set to 1 for specific troubleshooting regarding version compatibility and network adapters.

Configuring PowerShell Execution Policies

PowerShell often blocks the installation scripts due to strict execution policies designed to prevent unsigned code from running. This is a frequent source of "Access Denied" or script blocked errors when administrators attempt to run the WSL installer directly from the web or downloaded packages. To resolve this, check your current policy by running:

Get-ExecutionPolicy

If the output is AllSigned, Restricted, or RemoteSigned (depending on your security baseline), you may need to adjust it temporarily for the installation process. Run the following command to set the policy to Bypass for the current session only, which allows the script to run without permanent security changes:

Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass

This scope ensures that the change does not persist across different sessions, maintaining system security while allowing the WSL setup wizard to execute successfully. After the installation completes, you can revert the policy if required by your organization's security standards. For more complex scripting scenarios involving multiple commands within WSL2, see our article on Running Multiple Commands in WSL2/Ubuntu 22.04 with PowerShell.

Resolving Permission and User Account Issues

Administrator accounts sometimes face unique permission hurdles when WSL tries to create default user profiles or mount filesystems. If you receive errors stating that the user cannot access certain directories, it is often due to incorrect ownership settings rather than a lack of administrative rights. Ensure that the Windows Defender Firewall allows inbound connections for the WSL virtual switch. Go to Control Panel > Windows Defender Firewall > Advanced Settings and verify that the "Windows Subsystem for Linux" rule is enabled for both Private and Public networks. Additionally, standard users might struggle with mounting drives, but administrators should generally have full access. However, if you are migrating from a previous WSL1 setup or moving installations between drives, ensure that the underlying ext4 image files are not locked by another process. You can release these locks by stopping all WSL instances using:

wsl --shutdown

Then try reinstalling or updating the distribution. If you have moved your Ubuntu installation from one drive to another, such as from C to D, you may encounter initialization errors. In such cases, consult our detailed fix for Fixing WSL Not Working After Moving Ubuntu from C to D to restore proper path resolution.

Verifying the Installation

Once the features are enabled, policies are adjusted, and permissions are verified, test the installation by launching a distribution. Open PowerShell and type:

wsl --install Ubuntu

If the installation proceeds without error, launch the app from the Start menu to complete the user setup. Create a UNIX username and password, then verify the version by running wsl --version. This should return version 2.x.x.x. If you continue to experience issues despite these steps, check the Windows Event Viewer under Applications and Services Logs > Microsoft > Windows > WSL-Control for detailed error logs that can pinpoint specific service failures.

Frequently Asked Questions

Why does WSL2 fail to start on an administrator account?

The most common reason is that the Virtual Machine Platform feature was not enabled or the system was not restarted after enabling it. Administrative privileges do not bypass the requirement for these core OS components to be active.

Can I use WSL2 with a standard user account instead of admin?

Yes, WSL2 works perfectly with standard user accounts. While administrators can install it globally, individual users can also install distributions via the Microsoft Store. You may need to adjust firewall rules or group policies depending on your environment.

What should I do if PowerShell blocks the WSL installer script?

You should temporarily set the execution policy to Bypass for the current process using Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass. This allows the script to run without changing the global security settings permanently.

How do I troubleshoot networking issues after installing WSL2?

Ensure that the Windows Subsystem for Linux firewall rules are enabled. If you are using WSL1, note that networking behaves differently, so verify your distribution version with wsl --list --verbose.

Is systemd support available for all WSL2 distributions?

Systemd support is now enabled by default in recent versions of Windows 11 and updated Windows 10 builds. If you are on an older build, you may need to manually configure the /etc/wsl.conf file to enable it.