Product Documentation

Hot Desktop: A Shared Desktop Environment for Users

May 11, 2015

Hot Desktop combines the convenience of fast user switching with security of Single Sign-on capability through Single Sign-on. Hot Desktop functionality is not installed by default; you can select it during the initial Single Sign-on Plug-in installation process. You can also upgrade existing Single Sign-on Plug-in deployments to use Hot Desktop. Before you can implement Hot Desktop, however, you must configure Hot Desktop according to requirements in your environment and enterprise.

Hot Desktop is supported only on:

  • Microsoft Windows XP Professional, Service Pack 2—32-bit
  • Microsoft Windows XP Embedded

Hot Desktop is not supported on 64-bit operating systems or any server operating systems.

Hot Desktop is not available when Single Sign-on is deployed through Citrix Receiver Updater.

The Single Sign-on Hot Desktop feature allows users to share workstations efficiently and securely. Hot Desktop extends the standard Windows environment by allowing a user to:

  • Quickly authenticate to Windows using the standard GINA interactive logon dialog box
  • Run SSO-enabled applications in the interactive user shell by using the user’s Single Sign-on credentials
  • Log off from the Hot Desktop workstation so that other users can run applications

Summary of Hot Desktop Tasks

Before you can implement Hot Desktop you must:

  • Create a Hot Desktop shared account
  • Create user configurations with specific Hot Desktop-related settings to control the Hot Desktop user experience
  • Define Hot Desktop startup and shutdown behavior, including:
    • Deciding which applications are launched at startup, and which applications use Hot Desktop User or Hot Desktop shared account credentials and permissions
    • Deciding which applications are persistent and run even when users log off (for fast user switching) and which applications terminate when users log off, including your optional cleanup scripts or applications to delete user information from session to session

Perform the following tasks to configure and enable Hot Desktop:

  1. Create a Hot Desktop shared account that is available for each workstation or client device running Hot Desktop.
  2. Decide which of your SSO-enabled applications should run in the Hot Desktop environment.
  3. Decide how applications run in Hot Desktop and configure the Hot Desktop user environment.
  4. Create or modify a user configuration to select Hot Desktop options.
  5. Install the plug-in software with the Hot Desktop feature selected.
  6. Uninstall Hot Desktop if necessary.

Hot Desktop Start Up and Shut Down Process Flow

This process flow describes the events associated with Hot Desktop startup and shutdown. When the workstation or client device starts, it is logged on automatically to the shared account, allowing the device to run in shared desktop mode.

Note: The Hot Desktop shared account remains active at all times. Users do not have the permissions to terminate the shared account.
  1. A Hot Desktop user logs on to the workstation and enters a user name and password or uses a strong authenticator such as a smart card.
  2. When the user is authenticated, the Hot Desktop session starts.
  3. Single Sign-on launches. The plug-in software synchronizes its data with the central store. This ensures that the user has the most current application definitions, password policies, and other plug-in software-related settings.
  4. The session.xml file is read and any applications that you specified to run under the shared account or Hot Desktop User account launch. These applications can be local or remote applications that are published by XenApp. The user accesses the applications to perform job-related tasks.
  5. The Hot Desktop user logs off.
    Note: When users leave a workstation idle, Hot Desktop initiates a session time-out period. Using the Access Management Console, you specify how long a workstation can remain inactive. When the interval is exceeded, Hot Desktop locks the workstation. If additional time passes and the user does not return, Hot Desktop terminates the session.
  6. Hot Desktop leaves applications running or terminates them according to settings in process.xml.
  7. Single Sign-on exits.
  8. Any shutdown scripts specified in session.xml run.
  9. The Hot Desktop session terminates.

Troubleshooting Hot Desktop User Startup

When a user logs on to a computer running Single Sign-on configured for Hot Desktop, it is possible that the startup scripts specified in the session.xml file might run before Single Sign-on Plug-in software has fully launched.

During its startup, Hot Desktop waits 30 seconds for the plug-in software to start before it begins running the startup scripts. After 30 seconds, these startup scripts run, even if the plug-in software is not yet fully launched.

This situation is most likely to occur during the user's initial logon (also known as first-time user), where the Single Sign-on administrator identified a list of applications requiring logon credential registration or required answers for security questions. The sequence in this case is:

  1. The user logs on to the computer or client device running the plug-in software and a prompt appears for the user to register logon credentials for the listed applications or register answers to security questions.
  2. While performing these tasks, the 30 seconds pass and Hot Desktop startup scripts run. A series of windows might open and close, depending on the applications specified in the session.xml startup scripts.
  3. User frustration might result as the computer keeps moving focus to the startup script windows.
  4. When the startup scripts are completed, an error message appears. The error is similar to “One or more errors occurred. Please consult the Event log for more information.”

While this behavior might cause user frustration, it does not damage the user's data, work environment, or Single Sign-on.

Advise users not to register their logon credentials and security question answers until the error message appears. Users can then close the error message and complete the enrollment and registration process.

Following the error message and registration, if any application specified in session.xml does not open, advise the user to log off and then log back on to the account. This restarts any Hot Desktop startup scripts, which run uninterrupted because registration is complete and not delaying the process.

Creating a Hot Desktop Shared Account

You must create a Hot Desktop shared account for the client devices or workstations on which Hot Desktop will run. This shared account can be a domain account or a local account on the device. When you install Hot Desktop on the client device, you provide credentials for the shared account. When the device or workstation starts, it is logged on automatically to the shared account, allowing it to run in the Hot Desktop shared workstation mode.

User sessions run “on top” of the shared account Windows session (users cannot make changes to the shared account unless you allow them to). Users start a Hot Desktop session by typing their Windows domain credentials. In a Hot Desktop environment, a user’s Windows account is referred to as the Hot Desktop User.

Organizing Hot Desktop Users

If you plan to deploy Hot Desktop, you might want to set up your user environment first. For example, you might group Hot Desktop users under one or more Active Directory organizational units or groups. Also, you can organize users who are Hot Desktop users and also use their own workstations into multiple groups (and prioritize these groups).

This enables you to apply Hot Desktop settings, application definitions, password policies, and other user configuration information to multiple Hot Desktop users in those organizational units.

Restricting User Rights

Because the Hot Desktop device is shared by all Hot Desktop users, it may be necessary to restrict permissions and set them to a minimum required to use their assigned applications. For example, Hot Desktop users should not have the right to shut down the device. Restrict this right to members of the Administrators group.

Hot Desktop, Smart Cards, and Key Recovery

Note: Select the Smart Card Certificate user configuration Data Protection option if users use smart cards in the Hot Desktop environment.

If you deploy Hot Desktop in an environment where users log on with smart cards, do not select Prompt user to enter the previous password as the only key recovery and data protection method for those users. Users in such an environment cannot enter the correct previous password and, consequently, are locked out of the system. To avoid this problem, select the key recovery option for automatic key management or make question-based authentication available as an option.

Guidelines for the Hot Desktop Shared Account

Follow these guidelines to create a shared account:

  • Ensure that the account does not belong to the local or domain Administrators group.
  • The shared account can be a local or domain account. Any privileges available to the shared account are available to the Hot Desktop User only for those applications you specify. That is, you can specify those applications that launch with Hot Desktop shared account credentials and those that launch with the user’s Windows domain credentials.
  • The Hot Desktop installation process verifies the logon name and domain of the shared account. When you create this account, ensure that you select the Password never expires option. Do not use expired credentials.
  • Ensure that the account has limited privileges. Limit permissions to Hot Desktop use only.
  • Specify the domain name to which the workstation belongs using the domain’s NetBIOS name and not the fully qualified domain name (FQDN). If you are using a local account, specify the host name of the device.
  • As a best practice, name the shared account “Hot Desktop.” This ensures that users see the message “Logoff Hot Desktop” when they log off. If you give the shared account a cryptic name, users see the name as they log off and might get confused. If you have more than one group of Hot Desktop Users, you can name each shared account accordingly; for example, “Hot Desktop Marketing,” “Hot Desktop Accounting,” and so on.

Requirements for Applications Used with Hot Desktop

Applications that you use in a Hot Desktop environment must meet the following requirements:

  • Applications that require user credentials must be defined for use with Single Sign-on in application definitions and user configurations.
  • Applications that are launched by the shared account must be able to run in the Windows interactive environment. In this scenario, the applications (and the Hot Desktop users) must have access to the user profiles, network shares, and other resources associated with the shared account.
  • Applications must shut down cleanly when sent the request to do so. Hot Desktop terminates applications using procedures similar to a log off from a Windows interactive session. Graceful application termination is particularly important in a Hot Desktop environment because the application might be used many times before the workstation or client device is shut down.
  • Any application that must save sensitive data in the user’s profile or needs access to the user’s profile for settings should run as the Hot Desktop User account. Applications that can share “community” configuration information can run as a shared account. Administrators can use a session shutdown script specified in the session.xml file to ensure that user-specific files are removed at the end of each session.
Important: If you want Single Sign-on to submit credentials in a Hot Desktop environment for terminal emulators that store information in the HKEY_CURRENT_USER registry hive, you must run these applications as the Hot Desktop User account. Specify terminal emulators to run as the Hot Desktop User account in the ShellExecute section of the process.xml file. To run a terminal emulator at session start up, specify it in the start script section of the session.xml file. Terminal emulators must run as the Hot Desktop User account in the start script.

Controlling How Applications Behave for Hot Desktop Users

Single Sign-on makes two files available to control the behavior of applications in a Hot Desktop environment: session.xml and process.xml.

Important: You cannot specify that a process runs as the Hot Desktop shared account in the session.xml file and then specify it to run as the Hot Desktop User in the process.xml file. Entries in the session.xml file override any entries you make under the <shellexecute_processes> element in the process.xml file.

Before you begin:

  • To log on to the workstation or user device for administrative purposes (for example, to edit the process.xml file), hold down the SHIFT key during the Windows startup process. For more information about bypassing the Windows autologon process, visit the Microsoft Web site.
  • When running Hot Desktop session.xml, password expiration scripts, or any other scripts, executable files, or batch files from within a Hot Desktop User session, the following environment variables are not supported: APPDATA, HOMEDRIVE, HOMEPATH, HOMESHARE, and LOGONSERVER. If any of the unsupported variables are used, the script, application, or executable file might fail to run. To avoid this problem, applications should not access unsupported environment variables while running in a Hot Desktop User session.
  • You must instruct users to shut down applications that are specified as persistent processes. For example, if a user launches a persistent process, creates a file, and leaves the file open when exiting the Hot Desktop session, the next user who logs on can see the contents of the file.
    Important: Instruct users to always shut down sensitive applications that are defined as persistent before they end their Hot Desktop sessions.

    When you define an application as persistent in process.xml and specify it in a start script in session.xml, the number of application instances might increase if users do not terminate new application instances during a Hot Desktop session. To prevent this from occurring, limit the number of instances by creating a script or wrapper application that launches the application. You can also modify the application itself to ensure that only one instance is running at any given time.

  • Applications launched from a command prompt run as the Hot Desktop shared account even if they are specified as the Hot Desktop User account. To launch applications from a command prompt as the Hot Desktop User, you must specify the command prompt in the <shellexecute_processes> section of the process.xml file. Also, if the command prompt is running as the shared account and the file type association (such as *.txt) is defined in the process.xml file <shellexecute_processes> section, if the user runs a file with a .txt extension, the application launches as the Hot Desktop User.
  • Persistent applications that use the 8.3 file format must use the 8.3 format in the path of the executable when specified in process.xml.
  • While the XML tags and formatting in process.xml file are case-sensitive, the paths and executable names are not.
  • If your users are running SAP Logon for Windows (saplogon.exe), it must run as the Hot Desktop User. In the process.xml file, specify saplogon.exe under the <shellexecute_processes> tag.