In Windows 10 / 8.1 the logon screen by default displays the account of the last user logged in (If the user password is not set, this user will be automatically logged on, even if autologon is not enabled.) However, it is possible to display all user accounts on the login screen in Windows 10.
To make Windows 10 / 8.1 display all accounts, change the value of Enabled key to 1 in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch. You can do it either in RegEdit, Reg Add command or Set-ItemProperty PowerShell cmdlet:
Reg Add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch /v Enabled /t REG_DWORD /d 1 /f
Set-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch' -Name Enabled -Value 1
However, the system automatically resets the value of the Enabled parameter to 0 at each logon. In order to always change the value to 1, it’s easier to create a new task in the Task Scheduler that will run at user logon.
The Scheduler task must run one of the commands shown above. You can create this task manually using taskschd.msc graphic console. But it seems to me that it is much easier to create a Scheduler task using PowerShell. In our case, the commands to create a new task may be as follows:
$Trigger= New-ScheduledTaskTrigger -AtLogOn
$User= "NT AUTHORITY\SYSTEM"
$Action= New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch -Name Enabled -Value 1"
Register-ScheduledTask -TaskName "UserSwitch_Enable" -Trigger $Trigger -User $User -Action $Action -RunLevel Highest –Force
Make sure that the task appeared in Windows Task Scheduler (taskschd.msc).
Log off and then log on again. The task must start automatically and change the value of Enabled registry parameter to 1. Check the current value of the parameter. As you can see, it is 1:
get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch' -Name Enabled
After the next restart, all user accounts will be displayed on Windows 10 or 8 logon screen instead of the last one.
If you want all user accounts to be displayed on all domain computers, it’s better to distribute the Scheduler task using Group Policy Preferences (you can see an example of how to create a similar task in the article How to Configure a Screensaver Using GPO).
13 comments
Mine displays all of the accounts by default. How come?
This is absurd. If this is actually the setting- which has taken an hour of googling to find- to show all the local users on the login screen, the fact that it has to be set and then a timed script created to keep it set is… nucking futs. What a hate joke of an OS.
Arf! This is not about local account, but this tuto is about domain account. When you have severals doamain users on the same domain computer, its interresting to show all users account on the start menu.
By default, they have to choose “other user” and type both their ID and password. So with this method, they just have to click on appropriate username and type password.
For information, this doesn’t work. Scheduled task is working on all users, the reg value switch from 0 to 1 at startup for all users but on startup screen, only last user logged appear.
Not working. MS probably killed it in an update.
You have to change the permissions of the userswitch reg key : change the owner to Admin group and enable full control of the key for Admin and disable the write permission for SYSTEM. This is working since Windows 8.
@Roland – not an adminstrator but often end up having to do deskside support. How do I do what you suggested?
Try to run this powershell script as admin :
## Taken from P/Invoke.NET with minor adjustments.
$Definition = @’
using System;
using System.Runtime.InteropServices;
public class AdjPriv {
[DllImport(“advapi32.dll”, ExactSpelling = true, SetLastError = true)]
internal static extern bool AdjustTokenPrivileges(IntPtr htok, bool disall,
ref TokPriv1Luid newst, int len, IntPtr prev, IntPtr rele);
[DllImport(“advapi32.dll”, ExactSpelling = true, SetLastError = true)]
internal static extern bool OpenProcessToken(IntPtr h, int acc, ref IntPtr phtok);
[DllImport(“advapi32.dll”, SetLastError = true)]
internal static extern bool LookupPrivilegeValue(string host, string name,
ref long pluid);
[StructLayout(LayoutKind.Sequential, Pack = 1)]
internal struct TokPriv1Luid {
public int Count;
public long Luid;
public int Attr;
}
internal const int SE_PRIVILEGE_ENABLED = 0x00000002;
internal const int TOKEN_QUERY = 0x00000008;
internal const int TOKEN_ADJUST_PRIVILEGES = 0x00000020;
public static bool EnablePrivilege(long processHandle, string privilege) {
bool retVal;
TokPriv1Luid tp;
IntPtr hproc = new IntPtr(processHandle);
IntPtr htok = IntPtr.Zero;
retVal = OpenProcessToken(hproc, TOKEN_ADJUST_PRIVILEGES | TOKEN_QUERY,
ref htok);
tp.Count = 1;
tp.Luid = 0;
tp.Attr = SE_PRIVILEGE_ENABLED;
retVal = LookupPrivilegeValue(null, privilege, ref tp.Luid);
retVal = AdjustTokenPrivileges(htok, false, ref tp, 0, IntPtr.Zero,
IntPtr.Zero);
return retVal;
}
}
‘@
# Take ownership privilege
$ProcessHandle = (Get-Process -id $pid).Handle
$type = Add-Type $definition -PassThru
for ($i=1; $i -le 10;$i++){
$status=$type[0]::EnablePrivilege($processHandle, “SeTakeOwnershipPrivilege”)
if ($status){break}
if ($i -eq 10){read-host “Unable to take ownership privilege”;exit}
start-sleep 1|out-null
}
#
$keypath=”SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\UserSwitch”
#
# Get localized admin group name
$admin=(get-wmiobject win32_group| Where-Object {$_.sid -eq “s-1-5-32-544”}).name
# Change Owner to the local Administrators group
$regKey = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey(“$keypath”, “ReadWriteSubTree”, “TakeOwnership”)
$regACL = $regKey.GetAccessControl()
$regACL.SetOwner([System.Security.Principal.NTAccount]”$admin”)
$regKey.SetAccessControl($regACL)
# Change Permissions for the local Administrators group
$regKey = [Microsoft.Win32.Registry]::LocalMachine.OpenSubKey(“$keypath”, “ReadWriteSubTree”, “ChangePermissions”)
$regACL = $regKey.GetAccessControl()
$regRule = New-Object System.Security.AccessControl.RegistryAccessRule (“$admin”,”FullControl”,”ContainerInherit”,”None”,”Allow”)
$regACL.SetAccessRule($regRule)
# Change Permissions for System
$regRule = New-Object System.Security.AccessControl.RegistryAccessRule (“SYSTEM”,”SetValue”,”ContainerInherit”,”None”,”Deny”)
$regACL.SetAccessRule($regRule)
$regKey.SetAccessControl($regACL)
New-ItemProperty -Path “HKLM:\$keyPath” -Name “Enabled” -Value 1 -PropertyType DWORD -Force |out-null
You need to run this as admin since admin privilege is required to get ownership of the userswitch key owned by the system account.
Thank you, Roland! I may have it fixed, after making some changes to the group policy. If not, this topic is bookmarked. 🙂
is this working on domain users i did everything and still the users not showing at startup.
Hi Laura M, Can you explain what group policy changes you made to fix this?
Hi Nate. i actually followed the instructions I found on this site (first reply to the topic):
https://social.technet.microsoft.com/Forums/en-US/2ab569f5-ec46-4f54-a544-42504589d920/windows-10-logon-screen-retain-previously-logged-domain-users?forum=win10itprosetup
Please be aware that I am *not* a sysadmin. I am just a regular user who ends up having to try and play deskside support, so there may well be things I am making more diffiucult than they need to be. 🙁
Things I did notice-
1. The users I added didn’t actually show on the list on the list until after they logged in the first time.
2. When they did log in the first time, i found that it didn’t work if anyone else was currently logged in (it has to go through the set up for each user, and have them set a PIN). So, since their name wasn’t on the list, I had them select Other user. Then I had them click “Sign in options” and click the globe icon. Assuming that the ids were created using their email addresses, I had them enter that and followed prompts from there.
That’s what worked for me, but your experience may be different.
This (userswitch) was working for me until 1903 update. Now the reg values are correct, but some users (without passwords) are automatically logged in on start up.