How can we help?
You are here:
Print

Kiosk / Assigned-Access Auto-Launch

Overview

This test case validates the zTC’s ability to function as a single-purpose kiosk device. This is essential for scenarios where a thin client should only provide access to one specific application or virtual desktop, such as a patient check-in station, a library catalog terminal, a point-of-sale system, or a manufacturing floor interface.

The test ensures an administrator can use zMAN to lock down the device, force a specific VDI session to launch automatically on boot, and ensure the session attempts to reconnect if the connection is dropped, all while preventing user access to the underlying SnapOS desktop and settings.

zTC/zMAN Configuration

This is a management-centric task, so the configuration is performed entirely within zMAN Director.

  1. Create a Kiosk Application Policy:
    • Log into the zMAN Director UI.
    • Navigate to Device Settings -> Applications.
    • Click ADD APP GROUP to create a new application policy.
    • Give the policy a descriptive name, such as Kiosk-Mode-VMware-Only.
    • In the application list, uncheck every application except for the single VDI client you want to run in kiosk mode (e.g., leave only VMWare Workspace checked).
    • Save the application group.
    • Apply the policy to the device
  2. Create an Auto-Launching VDI Profile:
    • Navigate to Device Settings -> Profiles.
    • Click ADD PROFILE to create a new connection profile for your VDI environment (VMware profile, Reminna profile .Auto launch is not supported for Citrix)
    • Configure the standard connection details (Name, Protocol, Host/IP).
    • Save the profile.
    • Click Apply on saved profile.
    • Check the Apply the profile as autologin option and apply to the device.
    • From zMAN, issue a Reboot command to the device to force it to apply the new configuration.

3rd Party Setup (VDI Environment)

No special VDI server configuration is needed for this test. A stable and accessible virtual desktop or application published via Citrix, VMware, or AVD is sufficient.

Execution

  1. Observe Device Boot: After the zTC reboots, watch its startup sequence.
  2. Test OS Lockdown: Once the VDI session is launched and running in full-screen mode, attempt to escape the kiosk environment.
    • Try common keyboard shortcuts like Alt+Tab, Ctrl+Alt+Del, Alt+F4, and the Windows key.
    • Attempt to move the mouse cursor to the edges of the screen to reveal any hidden toolbars or menus.
  3. Test Auto-Reconnect:
    • From your VDI management console (e.g., Citrix Director, VMware Horizon Administrator), locate the kiosk device’s active session.
    • Use the administrative tool to forcibly disconnect the session. Do not log off the session, as this is a different action.
    • Observe the behavior of the zTC screen after the session is terminated from the server side.

Verification

  • Auto-Launch (Pass/Fail):
    • PASS: After booting up, the zTC device completely bypasses the standard SnapOS desktop and launches directly into the full-screen VDI client specified in the zMAN profile.
    • FAIL: The device boots to the standard SnapOS desktop with multiple icons, requiring a user to manually click to start the VDI session.
  • OS Lockdown (Pass/Fail):
    • PASS: The user is completely contained within the VDI session. All keyboard shortcuts that could be used to exit or switch applications are disabled. It is impossible to access the SnapOS Start menu, desktop, or any local configuration utilities.
    • FAIL: The user can successfully minimize, resize, or close the VDI client window, which exposes the underlying SnapOS desktop and allows them to launch other applications.
  • Auto-Reconnect (Pass/Fail):
    • PASS: After the session is administratively disconnected, the zTC client immediately detects the dropped connection and enters a reconnect loop. It continuously tries to re-establish the session until it is successful, without requiring any user interaction.
    • FAIL: When the session is disconnected, the VDI client closes and drops the user back to an error screen or the (supposedly hidden) local desktop. The device sits idle and requires a manual relaunch or a reboot to reconnect.
Was this article helpful?
0 out Of 5 Stars
5 Stars 0%
4 Stars 0%
3 Stars 0%
2 Stars 0%
1 Stars 0%
5
How can we improve this article?
Please submit the reason for your vote so that we can improve the article.
Table of Contents
Top