Windows Kiosk troubleshooting

Possible Causes:

• The kiosk AccountName entered inside the policy is incorrect.
• The user’s display name shown in the log-in window is entered as the kiosk AccountName instead of the Microsoft email address in the case where the local user is linked with a Microsoft account.

Solution:

• For local user accounts not linked with Microsoft Account, the user’s display name, which is displayed in the windows log-in page has to be entered as the kiosk AccountName inside the kiosk policy.
• For local user accounts linked with Microsoft Account, the Microsoft email address has to be entered as the kiosk AccountName inside the kiosk policy instead of the user’s display name.

Possible Cause:

• The user would not have signed out of the local user account prior to pushing the policy.

Solution:

• Either restarting the device or signing out and signing back into the same local user account will solve the problem.

Possible Cause:

• The user wouldn’t have restarted the device and would’ve simply switched to another user account. The issue would’ve occurred when the user tried to switch back to the local user account from another user.

Solution:

• Restarting/Powering off the device will solve the issue and the local user will start running normally again.

Possible Cause:

• The user stays in the login screen for a while after exiting kiosk mode.

Solution:

• Logging in to another user account or restarting the device will solve the issue.

“We weren’t able to start your app. Press “Ctrl + Alt + Del” to sign out of your contact your system admin. For more info, search online for error code: 0x8027025b”.

Possible Causes:

• The app which was set to run in kiosk mode is not installed inside the local user account.
• App version of the app set to run in kiosk mode is different from the app version of the app pushed via the kiosk policy.

Solution:

• Installing the correct version of the kiosk application (same as the one pushed from the portal) inside the local user account will solve the problem.

Possible Causes:

• App which was set to run in kiosk mode is not installed inside the local user account.
• The version of the app set to run in kiosk mode is different from the app version pushed via the kiosk policy.

Solution:

• Installing the correct version of the application (same as the one pushed from the portal) inside the local user account will solve the problem.

Possible Cause:

• A store app (UWP application) can only be added to a single app kiosk if it follows the assigned access/above the lock guidelines.
  A blue screen appears when a single app kiosk is set up with an app that does not follow the guidelines.

Solution:

• Press Ctrl+Alt+Dlt to circumvent the blue screen and exit kiosk mode. Check whether the store app follows the guidelines before implementing a single-app kiosk:
  1. Create a local user account on the device to set up Assigned Access.
  2. Log into that local account and install the required store app.
  3. Sign out from that local account and log back into the admin account.
  4. Navigate to Settings > Accounts > Family & other users > Set up a kiosk > Assigned access.
  5. Click Get started and select the Choose an existing account option.
  6. Select the previously created local user.

  The list of store applications that can be successfully added to the kiosk account will be listed on the choose a kiosk app page. If the store app fails to be listed, it does not follow the required Assigned Access guidelines.

“This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator.” An error message appears when the system attempts to run an application in kiosk mode.

Possible Causes:

• Restrictions configured in the Windows Registry or Group Policy can restrain the programs from running successfully.
• Applications might not run as expected if the corresponding app dependencies or packages are not added in the kiosk lockdown policy associated with the device.

Solutions:

You may perform either of the below steps from the device end to remove any restriction that might be keeping the applications from running successfully:

• Fix the Windows Registry by deleting the key DisallowRun. If a key called DisallowRun is added to the Windows Registry, you can restrict the programs from running successfully. To remove this key:
  1. On the Windows Start menu, click Run.
  2. Type regedit and click OK.
  3. Once the Registry Editor window opens, locate the path \HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\
  4. Select and delete the DisallowRun key.
• Fix the Group Policy by removing the restriction Don’t run specified Windows applications. Applications can be kept from running successfully if the restriction Don’t run specified Windows application is enabled in the Group Policy.
  1. On the Windows Start menu, click Run.
  2. Type gpedit.msc and click OK.
  3. Once the Group Policy Editor appears, expand User Configuration > Administrative Templates and select System.
  4. Open the Don’t run specified Windows applications policy and set it to Not Configured.
• To troubleshoot with Windows Event Viewer logs, type eventvwr.msc on the Windows Start menu and press Enter. Locate the following paths in the console tree to identify the cause of the issue:
  1. Application and Services Logs\Microsoft\Windows\AppLocker – To check whether the file or packaged app is allowed or blocked.
  2. Applications and Services Logs\Microsoft\Windows\AssignedAccess\Operational – To troubleshoot kiosk mode issues.
  3. Application and Services Logs\Microsoft\Windows\AppXDeployment-Server\Microsoft-Windows-AppXDeploymentServer/Operational – To identify missing packages.
  4. Applications and Services logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider/Admin – To diagnose any device management issues by MDM Server.

Or

Apps showcase inconsistent behavior in kiosk mode. The apps work fine when certain packages are allowlisted using the Blocklist/Allowlist policy. However, the app stops working when the Blocklist/Allowlist policy is removed or when the device restarts.

Possible Cause:

Some applications require dependent applications running in the background for the app to function as intended. When the app is launched, dependencies are also triggered. However, if the dependencies are not included in the kiosk policy, the app may not work as expected.

Solution:

The dependent applications that need to run in the background should be added as Desktop apps.

In single-app kiosk mode: “This operation has been cancelled due to restrictions in effect on this computer. Please contact your system administrator.”

In multi-app kiosk mode: “This app has been blocked by your system administrator. Contact your system administrator for more info.”

Possible Cause:

Apps are configured as startup apps on the Windows device but not included in kiosk mode during policy deployment.

Solution:

If setting up startup apps on the Windows device, ensure that they are also added to the kiosk mode during the kiosk policy deployment.

“This app has been blocked by your system administrator. Contact your system administrator for more information.”

Possible Cause:

The problem occurs when a Windows device has apps set to launch automatically, yet these apps weren’t included in the multi-app kiosk policy.

Solution:

You can solve this issue by disabling the startup apps from the device end or by adding the blocked dependencies to the multi-app kiosk policy.

Follow the steps given below to toggle off all the applications in the Startup section on your device before applying the kiosk policy:

1. On the device end, navigate to Settings > Apps > Startup.
2. Toggle off all the listed apps.

Or

Login to the device using the administrator account, then retrieve the event logs to identify the dependency packages being blocked. Once identified, include these packages in the multi-app kiosk policy. Follow the steps given below to do the same:

1. Locate the blocked dependency packages from the event logs:
1. Launch Event Viewer and proceed to Applications and Services Logs > Microsoft > Windows > AppLocker > EXE and DLL.
2. Select the ‘Save All Events As’ option and store the events file in any of the provided formats (e.g., .evtx or .txt). The blocked dependency packages, along with their locations, will be listed in this file.
2. Incorporate the blocked dependency packages into the multi-app kiosk policy:
1. Login to the Hexnode UEM console.
2. Access the previously configured multi-app kiosk policy under the Policies tab.
3. Navigate to Kiosk Lockdown > Windows Kiosk Lockdown > Multi App.
4. Press the ‘+‘ button and choose Desktop Apps.
5. Enter the App name and Location/Path of the previously identified dependency packages and click Add.
   
6. Click Done.
7. Click Save to re-apply the policy.

Following the configuration of the multi-app kiosk policy, despite adding a desktop by specifying its name and path on the device, the designated space for the app within the kiosk desktop remains empty.

Possible Cause:

This issue arises when the app specified in the kiosk policy is supported at the user level, and you attempt to apply the kiosk to another user account. If the app is located in the App Data folder or within a user-specific directory, it won’t be accessible to other user accounts.

Solution:

To resolve this issue, ensure that the app is accessible on the kiosk user account before applying the policy. Or follow the provided steps to allow it for all user accounts:

1. Right-click on the app in the start menu.
2. Select More > Open file location.
3. This will lead you to the shortcut file of the app, which is typically located in either the App Data folder or a user-specific folder.
4. Copy the shortcut file path.
5. Paste the shortcut file path into the following location:
   C:\ProgramData\Microsoft\Windows\Start Menu\Programs
6. Once completed, re-apply the kiosk policy to ensure the changes take effect.