Deploying Kiosk devices on modern Windows endpoints can be quite challenging, often leading to issues like start menu glitches, black screens after logon, and autologon failures.
Faced with these challenges, we decided to create our own fully functional, self-deploying Entra ID Joined Autologon device. These devices are designed to launch a specific app immediately after logon and are distributed throughout the building, typically without keyboards or mice attached.
While searching online, I found a post discussing issues with EntraID Joined machines where the Autologon mechanism failed. The problem was that the endpoint was waiting for network connectivity while Windows was already attempting to log in. The author mentioned using a manually created local GPO on their autologon machines. I previously wrote a blog about setting up a local GPO through Intune. Let’s explore and build this setup which initially started as a fun project!
The setup
- Autopilot Self Deploying profile (Entra ID Joined)
- Intune device license
- Hybrid Identity
- Password policy disabled
- Excluded from certain MFA/CA policies
- Disabled Windows Hello for Business
- Disable lockscreen on inactivity
- Skip user status page
Components
The environment is using purely Intune to deploy all the required tools, configs and scripts. The following tools and scripts are being deployed:
- SysInternals Autologon64.exe
- Local GPO & scripts for Delayed logon
- Autologon user configuration
1. Create: Autopilot Self Deploying profile (Entra ID Joined)
A Windows Autopilot self-deploying profile is a configuration that allows devices to be set up with minimal user interaction. This mode is particularly useful for deploying devices as kiosks, digital signage, or shared devices. It automates the process of joining the device to Microsoft Entra ID, enrolling it in Intune, and ensuring all necessary policies, applications, and settings are applied.
The following settings have been configured:

2: Create a (hybrid) identity and assign licenses
Create a new user account that will sync to Entra ID, or directly create a new user account within Entra ID. Ensure you assign the appropriate licenses, with the minimum requirement being an Intune Device License.
3: Environment specific: Disable the password policy
If a user is subject to a password policy, consider excluding them from the policy or ensuring their passwords do not expire. Remember, password policies can vary, and some environments may have distinct policies for On-prem and Entra ID identities.
4: Environment specific: Excluded from certain MFA/CA policies
The user account might be affected by additional MFA or Conditional Access policies, which could prevent them from logging in or accessing certain resources. Ensure you exclude the user from specific conditional access policies if they interfere with the device’s functionality.
5: Intune: Configure the following settings
To guarantee the working of the device, we need to configure additional policies via Intune. I already preconfigured these for you. The following link presents the Settings Catalog format/policy which can be implemented in your environment.

1: Grab the required JSON file here: AutoLogonPC/Windows – Autologon – Lockdown.json at main · j0eyv/AutoLogonPC
2: Navigate to Devices -> Configuration -> Policies -> Click Create -> Click Import Policy
3: Select the downloaded JSON file from step 1. Give it a common name and assign the policy to a device group which contains your autologon/wallboard devices.
Note: After deploying the settings to your devices, you might encounter an error related to the “Daily Recurring Reboot” setting. Despite the reboot occurring as scheduled, the policy still results in an error for some reason.
Optionally, you can skip the User Status Page while enrolling the device/user. Creating a custom OMA-URI policy in Intune allows you to configure settings that aren’t available through the standard Intune interface. Assign the policy to a device group which contains your autologon/wallboard devices.
Navigate to Devices -> Configuration -> Policies -> Click Create -> click New Policy -> Platform: Windows 10 and later -> Profile type: Templates -> Custom.
- Name: skipUserStatusPage
- Description: something common or empty
- OMA-URI: ./Vendor/MSFT/DMClient/Provider/MS DM Server/FirstSyncStatus/SkipUserStatusPage
- Data type: Boolean
- Value: True
To basic stuff has now been created within Intune. The fun part starts here. We will now package and configure the required components in Intune: SysInternals Autologon64.exe, Local GPO & scripts for Delayed logon, Autologon user configuration.
Note: Two of them are pre-configured for you already. You can simply grab the .Intunewin files from my Github or re-create them yourself. All source files are included.
6: NetworkWatcher (Optional)
The NetworkWatcher is designed for devices which have the “Shared Device Profile” configured. This results in removing local cached profiles (and credentials). The machine will then verify the user identity against Entra ID, while the machine is still waiting for network.. Some sort of a timing issue which cannot be prevented in Entra ID/Intune managed devices. This is described in detail in this reddit post. The NetworkWatcher is a Win32App which creates a local GPO (Startup Script). This script runs while starting and waits before continuing.
Note: If you’re not using the “Shared Device Profile” setting in Intune, you can skip this step. However, it does not harm the machine to still implement/include the NetworkWatcher.

Install cmdlet: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -File .\Install-Startupscript.ps1
Uninstall cmdlet: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -File .\Uninstall-Startupscript.ps1




Finally, Assign the application to a device group containing your autologon/wallboard devices.
7: SysInternals Autologon64.exe
Autologon64.exe is a utility from the Sysinternals suite that simplifies the configuration of Windows’ built-in autologon feature. Instead of requiring a user to manually enter their username and password at each login, Autologon64.exe allows you to set these credentials to be automatically used by Windows to log in the specified user. This can be done manually through out the registry. While using the Autologon tool from SysInternals, the credentials are encrypted and stored in the Local Security Authority Subsystem Service (LSASS).
- IntuneWin file: AutoLogonPC/AutologonTool/Autologon.intunewin at main · j0eyv/AutoLogonPC
- Install file: AutoLogonPC/AutologonTool/Autologon.ps1 at main · j0eyv/AutoLogonPC
- Uninstall file: AutoLogonPC/AutologonTool/UninstallAutologon.ps1 at main · j0eyv/AutoLogonPC
Note: Uninstall does not disable the autologon mechanism!

Install command: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -File .\Autologon.ps1
Uninstall command: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -File .\UninstallAutologon.ps1





Finally, Assign the application to a device group containing your autologon/wallboard devices.
8: AutologinUser configuration (custom)
The last piece we need manages the autologon setup in Windows OS using the SysInternals Autologon tool. You’ll need to adjust the setup file to fit your specific requirements before we can package it into an IntuneWin file.
You are required to change the $username and $password field. The username should be the FQDN (user@domain.com) from the identity created in one of the first steps.
Note: The script, which is packaged into an IntuneWin file, contains the password in plain text. Unfortunately, I couldn’t find a more secure way to store it. If you choose to use this approach, ensure you manage the identity carefully by granting it minimal permissions and restricting access to only the necessary resources.
# Define the parameters for the user which will be used to log in (change these)
$username = "User@domain.com"
$domain = "azuread"
$password = "SETPASSWORDHERE"
Modify the parameters and save the file. Next, we’ll proceed with creating the IntuneWin file. Since this process is likely familiar to everyone, I won’t go through all the steps in detail. The screenshot below illustrates the necessary actions. Keep in mind that the locations of your source files may vary.
After finishing, you can take the AutologonUser.intunewin file and upload it to Intune while setting up a Win32 App.


Install command: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -File .\AutologonUser.ps1
Uninstall command: %SystemRoot%\sysnative\WindowsPowerShell\v1.0\powershell.exe -executionpolicy Bypass -File .\AutologonUserDisable.ps1



HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon


Finally, Assign the application to a device group containing your autologon/wallboard devices.
Result
At this point you’ll have a Intune managed Windows device which automatically logs on into the operating system. It still does not start your desired application/tool automatically. There are many ways to do this. The best one for your situation it totally up to you. This can be either one of these options:
- Startup folder: Place the executable/shortcut/start-up script here.
- For all users:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
- For current user:
C:\Users\<Username>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
- For all users:
- RUN key: Create an entry in the registry
- For all users: HKLM\
Software\Microsoft\Windows\CurrentVersion\Run
- For current user:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run
- For all users: HKLM\
- Intune policy: Search for this policy in the settings catalog. ADMX_Logon Policy CSP
- For all users: Run these programs at user logon (Device)
- For current user: Run these programs at user logon (User)
- Nikolonsky script: Intune based script which runs as a scheduled task after logon
The method you choose depends on your specific scenario. Your requirements may differ, so you might need a different approach.
Hi, nice post but the json-file => https://github.com/j0eyv/AutoLogonPC/blob/main/Windows%20-%20Autologon%20-%20Lockdown.json
doesn’t exists (anymore)
Sorry, repo was set to private. Its available now.