Configure Automatic Sign-In for a Windows Virtual Machine in VMware Workstation Player

Learn how to configure, test, troubleshoot, and disable automatic Windows sign-in in a VMware Workstation Player virtual machine.

Automatic sign-in makes Windows sign in to a selected account after the guest operating system completes a normal boot or restart. VMware Workstation Player starts or resumes the virtual machine; it does not itself sign in to Windows. The sign-in behavior is configured inside the Windows guest.

This can be convenient for a single-user development VM, training image, or unattended test environment. It also reduces security because anyone who can access the running VM may receive the configured account's desktop.

Understand What Automatic Sign-In Does

A virtual machine is a software computer, and its guest operating system is the operating system installed inside it. The physical computer runs the host operating system and VMware Workstation Player.

VMware action	Windows state	Expected sign-in behavior	Notes
Power on the VM	Windows performs a boot	Automatic sign-in can take place after boot	Windows must reach the normal sign-in process without another prompt
Restart the guest	Windows performs a new boot	Automatic sign-in can take place	This is the primary verification method
Resume a suspended VM	The previous guest session is restored	Windows usually returns to its previous state	A VM suspended while locked may still show the locked screen
Lock or disconnect the guest	The existing session remains locked	Automatic sign-in does not normally run again	Unlocking or changing lock policies is separate
Sleep and wake Windows	The existing session resumes	A sign-in may be required according to Windows sleep settings	This is not equivalent to a full restart

VM encryption or host-side access controls are separate from Windows automatic sign-in. A protected VM may require host credentials or other access before VMware can power it on. Windows automatic sign-in cannot bypass encryption, BitLocker recovery, boot errors, update screens, or recovery prompts.

Prerequisites and Planning

Sign in to the Windows guest and identify the account that should be used.
Know the account's current password. Most password-based automatic-sign-in methods require a password-protected account.
Have local administrator rights in the Windows guest. The graphical and registry methods generally require administrative access, and Autologon may request elevation.
Identify whether the account is a local account, Microsoft account, Active Directory domain account, or work account managed by an organization.
When supported by your VMware edition and VM configuration, create a snapshot or backup before changing authentication settings. A snapshot is a saved point-in-time state that can help recover from unwanted VM changes.

Windows Hello and Passwordless Requirements

Windows Hello includes authentication methods such as PIN, facial recognition, and fingerprint sign-in. On some newer Windows installations, a Windows Hello-only or passwordless sign-in requirement hides the User Accounts automatic-sign-in checkbox.

Open Settings > Accounts > Sign-in options in the guest.
Review the setting that requires Windows Hello sign-in for Microsoft accounts or otherwise removes password-based sign-in.
If your security policy permits password-based automatic sign-in, disable the relevant passwordless requirement.
Close Settings and reopen the User Accounts utility.

Organization-managed devices may enforce this setting through domain policy, security baselines, or endpoint management. In that situation, a local administrator may not be able to restore the checkbox.

Method 1: Configure User Accounts with netplwiz

netplwiz opens the Windows User Accounts utility. control userpasswords2 is an alternate command that opens the same or a closely related interface.

Start the Windows guest and sign in with an administrative account.
Open the Run dialog.
Enter netplwiz and press Enter. If necessary, use control userpasswords2 instead.
Select the account that should sign in automatically. Verify the username and account context carefully.
Clear Users must enter a user name and password to use this computer, when that option is available.
Select Apply or OK.
Enter and confirm the selected account's current password when Windows prompts for it. Do not enter a PIN unless the dialog specifically supports it; this configuration normally uses the account password.
Restart Windows from inside the guest and confirm that the expected account reaches the desktop without a credential screen.

If the checkbox is missing, review Settings > Accounts > Sign-in options as described above, then reopen netplwiz. If policy controls the setting, use the organization's approved authentication process instead of bypassing policy.

Method 2: Use Microsoft Sysinternals Autologon

Sysinternals Autologon is a Microsoft utility for configuring Windows automatic logon. It is useful when the graphical User Accounts option is unavailable or unsuitable.

Download Autologon from a trusted Microsoft Sysinternals source while using a secure connection and validating that the download is genuine.
Choose the executable matching the guest architecture, such as Autologon.exe or Autologon64.exe.
Run the utility in the Windows guest and accept its license terms.
Enter the target username, domain or computer name, and password. For a local account, the computer name or local account context may be appropriate. For a domain account, enter the actual domain.
Select Enable and approve elevation if requested.
Restart the guest to test the result.
To stop automatic sign-in, run Autologon again and select Disable, then test with a full restart.

Autologon stores the credential in a protected Windows configuration mechanism rather than leaving the password as ordinary visible text in the dialog. This improves protection compared with casually writing a password into a script, but it does not make automatic sign-in risk-free. A user with sufficient access to the guest or its files may still be able to attack the stored credential or use the already signed-in session.

Method 3: Configure the Winlogon Registry Values

The registry is Windows' configuration database. The Winlogon component and its registry settings participate in interactive sign-in. Manual registry configuration should be reserved for a specific administrative need because it can store a password and can prevent normal sign-in if values are incorrect.

Before changing the registry, back up the relevant key and, when possible, create a VM snapshot or another verified backup.

Open Registry Editor with administrative rights.
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.
Configure or review these values:

Value	Purpose
`AutoAdminLogon`	Set to `1` to enable automatic logon; set to `0` to disable it.
`DefaultUserName`	The account name Windows should use.
`DefaultPassword`	The account password. This is sensitive credential data and should not be added casually.
`DefaultDomainName`	The domain or computer context for the account.

Account context matters:

Windows account type	Username format	Domain or computer value	Common configuration issue
Local account	A local username	The VM's computer name, or the local context expected by Windows	Using a domain name causes Windows to search for the wrong account
Active Directory domain account	The domain username	The actual Active Directory domain	The VM may lack network access to a domain controller, or policy may prohibit automatic logon
Microsoft account	The account's Windows-recognized sign-in name, often an email-style name	The format expected by the Windows build	An incorrect account-name format or passwordless settings can prevent logon
Work or school account	The organization-provided sign-in name	The organization's account context	Management policy may disable or overwrite automatic logon

Do not use manual password storage unless there is a clear administrative requirement and the associated risk is accepted. To reverse the registry configuration, set AutoAdminLogon to 0 and remove the stored credential values, especially DefaultPassword. Then restart Windows and verify that manual sign-in is required.

Compare the Configuration Methods

Method	Best use case	Administrative access needed	Credential storage approach	Advantages	Limitations	How to disable
User Accounts utility	Simple local configuration	Usually required	Windows manages the resulting automatic-logon settings	Fast and graphical	Checkbox may be hidden or policy-controlled	Run `netplwiz` and re-enable the password requirement
Sysinternals Autologon	When the graphical option is unavailable	Usually required	Protected Windows credential storage managed by the utility	Clear enable and disable workflow	Still exposes the session after boot and depends on compatible account settings	Open Autologon and select Disable
Registry	Specific administrative or scripted configuration	Required	May store `DefaultPassword` in the registry	Direct and automatable	Highest configuration and credential-handling risk	Set `AutoAdminLogon` to `0` and remove stored values

Start and Test the VM in VMware Workstation Player

In VMware Workstation Player, select the Windows VM and choose the normal power-on or start action. For basic startup guidance, see Starting a Virtual Machine.
Observe the guest display. VMware powering on the VM is complete before Windows necessarily finishes booting.
Allow Windows to complete boot processing. Automatic sign-in should select the configured account and load its desktop.
Use a full Windows restart for testing. Do not treat pause, suspend, or resume as proof that automatic sign-in works.
If the VM is intended for unattended use, test at least one restart after a Windows update and confirm that no update, recovery, encryption, or first-run prompt blocks the desktop.

A suspended VM often returns to the prior guest session. If Windows was locked when the VM was suspended, resuming may show the locked screen and require the account's normal unlock method. Automatic logon normally occurs during a new boot, not each time the VM resumes.

Security and Operational Considerations

Anyone with access to the running VM can use the automatically signed-in account, including its files, applications, network access, and saved sessions.
Stored automatic-logon credentials are a risk on shared hosts, portable computers, training labs, and VMs containing sensitive information.
Prefer a standard, least-privilege account. Avoid automatic sign-in for privileged administrator accounts or production systems unless there is an explicit security decision.
Protect the host account, restrict physical and remote access, and use full-disk encryption where appropriate.
Consider VM encryption and access controls separately from Windows sign-in. A secured host and protected VM files reduce the chance of offline access.
Domain policy, security baselines, and endpoint-management tools may disable or overwrite automatic-logon settings.

Troubleshooting

Symptom	Likely cause	Recommended fix
The checkbox is not visible in `netplwiz`	Windows Hello-only sign-in is enabled, policy controls the device, or the build presents the option differently	Review Settings > Accounts > Sign-in options, disable the relevant passwordless requirement if allowed, and reopen the utility. Contact the administrator if policy-managed.
Windows still shows a password prompt after restart	The password changed, the setup password was incorrect, the wrong account context was selected, or policy disabled automatic logon	Reconfigure with the current password, verify the account and domain or computer name, and check organizational policy.
The VM returns to a locked screen after resume	The guest was suspended while locked, or Windows requires sign-in after sleep	Unlock the guest or review Windows lock and sleep settings. Test with a full reboot.
Local automatic sign-in works but domain sign-in fails	The domain is wrong, a domain controller is unavailable, or domain policy blocks automatic or cached interactive logon	Validate the username and domain, confirm network availability at boot, and consult domain administrators.
A Microsoft account does not sign in automatically	The username format is wrong, passwordless settings conflict, or the saved password is outdated	Confirm the Windows-recognized username and current password, then review Windows Hello settings or use Autologon where appropriate.
The VM starts but does not reach the desktop	Windows is waiting for an update, recovery screen, BitLocker recovery key, boot repair, or driver intervention; the VM may also require host-side access	Resolve the pre-sign-in condition first. Automatic sign-in cannot bypass boot security, recovery, encryption, or guest errors.

Verification and Rollback

After configuration, perform a full Windows restart and confirm that the expected account is signed in. Check that the correct profile, desktop applications, network access, and startup tasks are available. If unattended operation matters, repeat the test after a maintenance or update restart.

To restore manual sign-in, use netplwiz to re-enable the user-name-and-password requirement, use Sysinternals Autologon and select Disable, or set AutoAdminLogon to 0 and remove stored registry credential values. Restart the guest and confirm that Windows displays its normal credential screen.