There are of course use cases in which automatic logon to the Windows system makes sense. Digital signage devices, kiosks or presentation devices or even servers on which the start of an application is necessary. We can use the Autologon tool from Sysinternals and run it on each target device or define a GPO and assign it to the corresponding systems.
create Grouppolicy (GPO) for Autologin
Let’s assume that we have a Windows server on which an application must always run under the AD user “service.signage”. We create a GPO called “set Autologin user service.signage” in Group Policy Management. We then edit this and enter the following values in the “Computer Configuration > Preferences > Windows Settings > Registry”.
Why put login data in the computer configuration and not the user configuration?
If you configure the login data below the computer configuration, you have the advantage that the login data is already applied at the first start before the login. If you configure the autologin data within the user configuration, it will only be applied to the computer after the first login. So what? No big deal… If you have 40 Windows devices, for example signage devices, you only need to lift them into the Active Directory, restart and wait until the devices have pulled the GPO settings at the first start or after about 60 minutes. OR laboriously log on to all devices once manually…
back to the configuration
- Folder “Autologon” to group the values nicely / clarity.
- Within the “Autologon” folder, create the following four entries
| Wert | Hive | Key Path |
| AutoAdminLogon | HKEY_LOCAL_MACHINE | SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon |
| DefaultDomainName | HKEY_LOCAL_MACHINE | SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon |
| DefaultPassword | HKEY_LOCAL_MACHINE | SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon |
| DefaultUserName | HKEY_LOCAL_MACHINE | SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon |
Group Policy (GPO) Assign Active Directory group
Once the GPO has been created, it must of course be assigned to the corresponding machine. We have two or even three options for this
- Assignment via Active Directory group (AD group)
- Assignment via Active Directory OU (AD-OU)
- or directly via the Active Directory computer account (at least recommended)
Everything has its advantages and disadvantages, but I can say one thing: Often it does not stay with one system and therefore the easiest way to implement and extend it is via the AD group of the AD OU.
In this example, I decided to use the AD group because I want to add more servers or clients with this account via Autologon in the foreseeable future. To do this, I have created an AD group called “clients with autologon service.signage” and assigned the computer accounts “Office01” to the AD group. Of course, the GPO created must also be attached to an OU. In my case, to the “signage devices” OU
Furthermore, it must be ensured that the scope/security filter of the GPO is only applied to the members of the AD group “clients with autologon service.signage”.
- Open the “Delegation” tab of the “advanced” GPO
- Remove the checkmark next to “apply” for Authenticated User
- Add AD group “clients with autologon service.signage” and set apply checkmark
Gruppenrichtlinie auf dem Client anwenden
After all the preparatory work has been done, we must of course ensure that the GPO is applied correctly. Either you notice that the device automatically logs in when you restart it, which is of course the best case scenario. If this does not work due to synchronization latencies (e.g. in large environments), you must take the following steps.
Log on to the device with the final user or admin. account, start a console with “Win+R” > CMD and enter “gpupdate /force”. The computer will now be forced to pull the latest GPOs from the domain controller and apply them. Once the command is complete, you can check the application again with the command “gpresult /r”. After a restart, the client should now log on automatically.
gpupdate /force
gpresult /r
shutdown -r -t 0It is also possible to set the switch within a GPO so that the computers wait for the network before logging on. This ensures that the GPOs can be pulled because the computer is still waiting for the network card. In the past, there have always been problems with some network cards and slow DHCP servers, which is why computers without a network have logged on with the cached credentials.
In the registry you can of course also check that the settings have arrived.
VERY IMPORTANT! Never lose your nerve and check the Windows log files if in doubt. GPUPDATE and GPRESULT are also very helpful for troubleshooting.