I'm new to IT support and troubleshooting Docker Desktop on a managed Windows device. When the user starts Docker Desktop as administrator, it fails with a WSL error while importing the docker-desktop distribution:
"Logon failure: the user has not been granted the requested logon type at this computer."
The reported error is Wsl/Service/RegisterDistro/CreateVm/HCS/0x80070569. I found suggestions to grant "Log on as a service" or add NT VIRTUAL MACHINEVIRTUAL MACHINES in Local Security Policy, but those accounts do not appear when I try to add them. Only built-in accounts are available. The device is managed through Intune, although I have not found an obvious restriction in the security baseline or account protection policies.
I have already tried wsl --shutdown and restarting WSL, but the problem remains. What should I check next, and how can I determine whether a local security policy, domain policy, or Intune configuration is causing this?
3 Answers
This usually points to Windows user-rights or virtualization policy rather than a damaged WSL installation. Check Local Security Policy under Local Policies → User Rights Assignment, especially “Log on as a service” and “Log on as a batch job.” Also verify that the account or required virtual-machine service identities have not been denied the relevant logon rights.
On a managed computer, a domain GPO or Intune policy can overwrite local settings. If the permissions cannot be added or disappear after a policy refresh, compare the effective policy and involve whoever manages the device. Starting Docker as administrator alone will not bypass an enforced policy.
Since the computer is managed through Intune, check the applied Endpoint Security, security baseline, device restriction, and administrative template policies rather than focusing only on the local security console. WSL2 and Docker Desktop need to create and start a lightweight virtual machine, so virtualization-related restrictions or user-rights assignments can produce this exact HCS 0x80070569 error.
Generate the effective policy results and review the Windows event logs around the failure. If an Intune or domain policy is enforcing the setting, the fix has to be made centrally; changing Local Security Policy will either be blocked or overwritten.
The “NT VIRTUAL MACHINEVIRTUAL MACHINES” entry is a built-in virtual-machine identity, not normally a regular user you sign in with. If it is missing from the account picker, do not assume adding the affected employee manually is the correct fix. Confirm that the Windows virtualization components, Hyper-V-related services, and WSL features are enabled, then have the device administrator verify the effective security policy and whether WSL is intentionally blocked.
If the machine allows it, a scheduled task or service configured with the correct rights may be a workaround, but that still requires permission to create and run it. It is better to identify the policy applying the restriction first.