Skip to content

Advance Configurations

Enhanced Shell Tracking for Applications in Shell Mode

The new session host server now features improved tracking of applications operating in shell mode.

Examples of such applications include:

  1. Explorer (My PC)
  2. Google Chrome
  3. Batch script-driven app launches

Note

The feature is limited to application delivery in shell mode only and will be controlled by Controller v3.3 or above, but if session host v3.3.0.11119 or above is being delivered with an older v3.2 controller, then it must be configured using registries carefully. Please see the appendix for detailed information.

Configuration to Run Applications with Specific User Credentials

In some deployments, it is required to run applications with specific user privileges.

Starting from HyWorks v3.3, the administrator can configure the application to run as:

  • Logged-in User (Default option)

  • System User

  • Specific User Credentials

The detailed step-by-step process is provided in the application publishing section.

Direct RDP/Console Block

Direct access to virtual desktops can introduce significant security risks and session conflicts. This document outlines a feature restricting direct RDP access via MSTSC or non-Accops clients while allowing users to connect only through authorized Accops endpoints, such as Accops Workspace Client and Hylite.

This feature is integrated with the HyWorks DVM agent. In desktop VMs, the administrator can configure the access block using the following registry settings.

Configurations

All configurations related to direct RDP block features are controlled using registry entries at the following location:

HKLM\SOFTWARE\Accops\DVMAgent

Details of these registry configurations are given below:

  1. DirectRDPBlocked:

    1. Description: Enable this flag to block direct RDP access for normal users.

    2. Flag Value: true or false

    3. Behavior:

      1. When set to true, normal users attempting to connect via RDP (MSTSC) will be logged out of their Desktop session. Access is allowed only through the Accops Workspace Client or Hylite.

      2. Admin Access: Admin users are exempt from this restriction and can connect via direct RDP without being logged out.

  2. DirectRdpAdminBlocked:

    1. Description: When enabled, this flag blocks normal and admin users from taking direct RDP.

    2. Flag Value: true or false

    3. Behavior: If set to true, admins will not be able to initiate a direct RDP session.

  3. DirectConsoleBlocked:

    1. Description: This flag controls console access for all users.

    2. Flag Value: true or false

    3. Behavior: When enabled, normal users will be blocked from accessing the console session.

  4. DirectRdpBlockTimeoutSec:

    1. Description: Admins can configure a timeout period in seconds for logging out users from direct RDP.

    2. Timeout Value: (integer value representing seconds).

    3. Behavior: If a user connects via direct RDP, they will be automatically logged out after the specified time.

  5. DirectRDPVerifyViaVC (Enhanced method added in v3.4-SP2 or later):

    1. Flag Value: 0 or 1

    2. Behavior:

      1. If set to 0, the conventional method of direct RDP blocking is used.

      2. If set to 1, latest and advance method. A virtual channel will be used to verify whether the session was established through the client or direct RDP. If it is direct RDP, the user will be logged out.

  6. ActionOnDirectRDPSession (Enhanced method added in v3.4-SP2 or later):

    1. Description: This flag defines the action taken when a user initiates a direct RDP session.

    2. Flag Value: 0 (default) or 1.

    3. Behavior:

      1. If set to 0, the user will be disconnected from the Desktop if the connection is via direct RDP.

      2. If set to 1, the user will be logged out from the Desktop session if it is a direct RDP connection.

Steps to Configure:

  1. Log in to personal/shared desktops with admin user.

  2. Open the registry editor and set all flags according to your desired configuration in the system settings. Example of configurations:

    1. DirectRDPBlocked: True

    2. DirectRdpAdminBlocked:False

    3. DirectConsoleBlocked: False

    4. DirectRdpBlockTimeoutSec:20

    5. DirectRDPVerifyViaVC:1 (It uses the latest and advanced direct RDP block method.)

    6. ActionOnDirectRDPSession:1 [Logout] (Part of the latest and advanced direct RDP block method.)

  3. Restart the Desktop Agent Service

    1. Open the service management console (services.msc) or use a command line interface.

    2. Locate the Desktop Agent Service.

    3. Restart the service to apply the new configuration.

  4. Try to take direct RDP access of the configured virtual desktop using MSTSC and observe the behavior.

Logs:

  • The following log will be generated for sessions that are logged out by an agent via direct RDP:

    • Agent Log location: C:\Program Files (x86)\Accops\HyWorks Desktop Agent\Logs

    • Sample Log:

      Logging-out direct (Non-Accops) RDP session WTS ID [3] for user domain/username. The direct RDP session is not authorized. Logon-Time (34sec) and Connect-Time (37sec)

Advance RDP Block Method

This is the latest RDP block method introduced in v3.4-SP2; it’s faster and has dependencies on the client and server versions.

Newer versions (v3.4-SP2 or later) will use the following registry configurations:

  • DirectRDPBlocked, DirectRdpAdminBlocked, DirectConsoleBlocked, DirectRdpBlockTimeoutSec, DirectRDPVerifyViaVC (Set as 1 for new method), ActionOnDirectRDPSession (Part of new method: 0 to disconnect and 1 to log out invalid session.)

Supported Versions and Prerequisites:

  • HyWorks Controller: v3.4-SP2 or later

  • HyWorks DVM Tools: 3.4.0.1109 or later

  • HyWorks Session Host: v3.4.1.138 or later

  • AUEM: v3.4.0.370 or later

  • Supported Endpoint (Flavors and Versions):

    • Windows Client: v3.2.8472.328472 or later

    • Linux Client v3.2.9526.329526 or later

Flow of events:

  1. User logs in from authorized Accops end-point > Clicks on desktop icon to request connection information from Controller

  2. The controller provides information to the desktop client. In parallel, the controller informs the agent on the virtual desktop about the upcoming session.

  3. User connects to assigned desktop. Desktop connection gets established.

  4. As soon as the connection is made, the desktop agent confirms the session validity with the client.

  5. If the details of the connected session and client response are found valid, it allows the session to continue. If not, the desktop session is logged out.

Important Points:

  • This is available only in v3.4-SP2 or later.

  • It's faster than the conventional method but has dependencies on end-point type and versions.

  • Having configurable actions on direct desktop sessions.

Default Method

This is an old method available in HyWorks agents (Desktop/ Session Host) from older versions.

Older versions will continue to use the following registry configurations:

  • DirectRDPBlocked, DirectRdpAdminBlocked, DirectConsoleBlocked, DirectRdpBlockTimeoutSec

Newer versions (v3.4-SP2 or later) will use the following registry configurations:

  • DirectRDPBlocked, DirectRdpAdminBlocked, DirectConsoleBlocked, DirectRdpBlockTimeoutSec, DirectRDPVerifyViaVC (Set as 0 for default method), ActionOnDirectRDPSession (Part of new method and will not change behavior unless new method is used.)

Flow of Events:

  1. User logs in from authorized Accops end-point > Clicks on desktop icon to request connection information from Controller

  2. The controller provides information to the desktop client. In parallel, the controller informs the agent on the virtual desktop about the upcoming session.

  3. User connects to assigned desktop. Desktop connection gets established.

  4. The agent validates the connected desktop with the information given by the Controller in step# 2.

  5. If the details of the connected session and information received from the Controller are found valid, it allows the session to continue. If not, the desktop session is logged out.

Important Points

-   With the advance method in use, having incompatible client version may cause sessions to be disconnected or logged out as per configurations.

    -   If the deployment has non supporting clients and versions, it is recommended to use the old method.

-   Direct RDP block is enabled by default in the latest DVM agent using the default method.

-   In some cases, where profile loading or connection takes more time than the configured time limit of direct RDP block, the agent may interrupt the session as a direct RDP connection and may log it out. The cases can be understood from logs and as per the environment.

-   The timeout duration can be increased.

Allow calls from authorized controller(s) only

In some deployments, it is required to block unauthorized access to the session host server.

Starting from HyWorks v3.3, administrators can configure the list of authorized controller IPs to block unauthorized access.

HKEY_LOCAL_MACHINE\SOFTWARE\Accops\Controller\EDC\SESSIONHOST\AuthorizedControllerIPs

Note

  • Default value is set as '*', which means all controllers are open to connect.
  • Replacing '*' with one or more (multi-string) controller IPs results in allowing only those listed controller(s) to communicate with the local Session Host Service.
  • In case, if unauthorized controller try to communicate an error log will come into both agent and controller logs.

Session change event scripts support

In some deployments, executing scripts during session change events is required. This feature is integrated into HyWorks and supports the following six types of session change event notifications.

  1. CONNECT
  2. DISCONNECT
  3. LOCK
  4. LOGOUT
  5. RECONNECT
  6. UNLOCK

Registry Base:

HKEY_LOCAL_MACHINE\SOFTWARE\Accops\DVMAgent\EVENTS

The administrator can configure the session change event by updating the registry entries. Details about the registry key values are as follows:

Key Name Name Value Type Meaning
EVENTS EnableForAdmins FALSE String Set this flag as True to enable the execution of Session Change Events scripts for Admin users, too.
================ ========================== ============================ ==== =========
EVENTS\CONNECT IS ENABLED FALSE String Set this flag to True to enable Connect Event script execution.
EVENTS\CONNECT SYSTEM_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Connect_System.bat String The script executes batch commands in the System context of the Connect event.
EVENTS\CONNECT USER_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Connect_User.bat String The script executes batch commands in the User context of the Connect event.
================ ========================== ============================ ==== =========
EVENTS\DISCONNECT IS ENABLED FALSE String Set this flag to True to enable the Disconnect Event script execution.
EVENTS\DISCONNECT SYSTEM_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Disconnect_System.bat String The script executes batch commands in the System context during the Disconnect event.
EVENTS\DISCONNECT USER_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Disconnect_User.bat String The script is used to execute batch commands in the User context during the Disconnect event.
================ ========================== ============================ ==== =========
EVENTS\LOCK ISENABLED FALSE String Set this flag to True to enable Lock Event script execution.
EVENTS\LOCK SYSTEM_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Lock_System.bat String The script executes batch commands in the System context while the Lock event is active.
EVENTS\LOCK USER_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Lock_User.bat String The script executes batch commands in the User context while the Lock event is active.
================ ========================== ============================ ==== =========
EVENTS\LOGOUT IS ENABLED FALSE String Set this flag to True to enable the Logout Event script execution.
EVENTS\LOGOUT SYSTEM_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Logout_System.bat String The script executes batch commands in the system context during the login event.
EVENTS\LOGOUT ExecutePreLogoutScriptInSystemContext FALSE String The script will be executed in the system context before logout.
EVENTS\LOGOUT ExecutePreLogoutScriptInUserContext FALSE String The script will be executed in the user context before logout.
================ ========================== ============================ ==== =========
EVENTS\RECONNECT IS ENABLED FALSE String Set this flag to True to enable the Reconnect Event script execution.
EVENTS\RECONNECT SYSTEM_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Reconnect_System.bat String The script executes batch commands in the System context of the Reconnect event.
EVENTS\RECONNECT USER_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Reconnect_User.bat String The script executes batch commands in the User context during the Reconnect event.
================ ========================== ============================ ==== =========
EVENTS\UNLOCK IS ENABLED FALSE String Set this flag to True to enable Unlock Event script execution.
EVENTS\UNLOCK SYSTEM_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Unlock_System.bat String The script executes batch commands in the System context during the Unlock event.
EVENTS\UNLOCK USER_CONTEXT_SCRIPT_PATH C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\Unlock_User.bat String The script is used to execute batch commands in the User context of the Unlock event.
================ ========================== ============================ ==== =========

The scripts can be updated for other custom usage. Scripts root folder:

C:\Program Files (x86)\Accops\HyWorks Desktop Agent\scripts\

Note

- HyWorks only provides a platform for executing scripts on different system events. The scripts have to be generated according to the requirements.

- HyWorks v3.4 or later has the integrated DVM agent (Lite), so the same set of registry keys (from the DVM agent) and scripts are used.

Pre-Post Scripts for AppLauncher (Linux Only)

HyWorks v3.3 or later allows pre- and post-script execution during application/desktop launches, which means these scripts will be executed before the application or desktop launches, as some deployments may need pre- and post-cleanup.

The scripts can be updated at the location (folder):

/etc/edcdvm/linuxDVM/scripts/

Available scripts names:

  • AppLauncherPostScript.sh
  • AppLauncherPreScript.sh

Note

  • The scripts are only placeholders and the administrators have to provide scripts as per the requirements.

HyShell

HyShell is a desktop customization utility integrated with the HyWorks Session Host Server. Its main goal is to publish and manage desktop shortcuts on user session desktops from the session host server.

HyShell exclusively manages the desktop shortcuts it creates and does not oversee public shortcuts installed by the administrator.

Purpose

HyShell is designed to publish shortcuts for applications (virtual) that are assigned to users, meaning the users are authorized to use them. This allows for a more streamlined experience, as users do not need to see a long list of irrelevant applications. For instance, if a session host server has 50 different applications installed, a typical user may only use 5. Displaying all 50 applications would be confusing, so instead, the user is only shown the 5 applications that are useful to them. This approach is applied to all users, which is how HyShell optimizes the shared hosted desktop experience.

How does HyShell work?

The operation of HyShell is straightforward. When a user connects to a shared hosted desktop using an appropriate endpoint from HyWorks or HyLite, HyShell is activated. It initiates communication with the Controller to retrieve a list of applications associated with the current session host server assigned to the user. HyShell then generates desktop shortcuts for all applications assigned to the user and removes any shortcuts not assigned to them.

Session Host Server Components

The following are the components of the session host server:

AppLauncher: Once the user logs in via the client, AppLauncher executes the HyShell script to customize the desktop. This script can set application access, create desktop shortcuts, and add start menu links.

HyShell: HyShell operates in a user context, allowing it to gather specific user details such as the user's desktop path, start menu path, and user session ID (WtsId), among others. After collecting this basic information, it will call the Session Host API that is made available for HyShell tasks.

Session Host: Session host exposes an endpoint for HyShell to accept user-related data and execute the following tasks:

  1. Run HyShellServerPreScript.ps1 script: This script contains Power Shell code to perform some operations that are required before creating the desktop shortcuts.
  2. Get the Application list and its details from the local DB and Controller for the specified user.
  3. Try to create desktop icons and start menu links for user applications.

Enabling HyShell

To enable HyShell, the following configurations are required:

  1. Configuring applications for getting published for shared hosted desktop (in HyShell)

    1. Login into the HyWorks Controller Management console with administrator rights.
    2. In the Add/ Edit application wizard click the Additional Settings screen:
      1. Under the Access Settings section, select the following options:
        1. Create Desktop Shortcut > On shared hosted desktops.
        2. Pin Application to Start Menu > On shared hosted desktops.
    3. Enable the above-mentioned options for all applications that require shortcuts to be created on a shared hosted desktop.

Note

HyShell will create shortcuts for the virtual applications published on HyWorks it will include:

  • Applications are published in HyWorks and enabled for shortcut creation on shared hosted desktops.
  • Applications that are installed and published from the current server on which the user has got connection.

  1. Enable HyShell on Session Host Server

    1. Windows Session Host Server: Enable HyShell from Registry Editor Follow the below steps to enable HyShell on the session host server (Windows).

      1. Connect to the session host server remotely using user credentials having administrator privileges.

      2. Open Registry editor (Open Run prompt, type 'regedit', and press enter key).

      3. In the Registry Editor, navigate to the following location:

        HKEY_LOCAL_MACHINE\SOFTWARE\Accops\Controller\EDC\SESSIONHOST

      4. Create or update the following registry values:

        1. Type: string
        2. Name: IsDesktopCustomizationEnabled
        3. Value: True

      5. Save the registry value and exit the registry editor.

      6. Restart the HyWorks Session Host Agent service.

    2. Linux Session Host Server: Enable HyShell in the configuration file and follow the steps below to activate HyShell on the session host server (Linux):

      1. Connect to Linux SHD server via SSH Client(if SSH enabled) or console session

      2. Open HyShell configuration file, command:

        sudo vi /etc/edcdvm/linuxDVM/hyShell/hyshell.config

      3. Set the value for IS_HYSHELL_ENABLED to 1.

      4. If any user is added in EXCLUDE_USERS_LIST, then the desktop restriction is not applicable for EXCLUDE_USERS_LIST

      5. Restart the DVM Agent Service, by using the following command, sudo systemctl restart edcdvm

      6. Linux SHD is now enabled with HyShell.

Pre-Post Scripts for HyShell

HyWorks v3.3 or later now allows pre- and batch script execution while executing HyShell as well, which means before launching HyShell these scripts will get executed as some deployment needs some kind of per-post cleanups as well.

Windows Session Host

PowerShell Scripts: These scripts can be used by the admin to enable any customization as per user/client requirements. E.g. pushing specific policies before and after HyShell execution. HyShell executes in the user context and launches HyShell, the other 2 scripts are executed in the service context. mentioned below:

The scripts can be updated at (folder):

C:\Program Files (x86)\Accops\HyWorks\SessionHost\HyShellScripts\

Available Scripts names:

  1. HyShellLauncherScript.ps1 : It will be launched by AppLauncher. So runs in the user context and launches HyShell. HyWorks admin can add their own customization code in this file which needs to execute in user context.

  2. HyShellServerPreScript.ps1: This script will be executed in the service context before creating shortcuts on the desktop. Should contain a set of commands that need to be executed before creating shortcuts and the current user doesn’t have permission, such situations can be executed in the service context.

  3. HyShellServerPostScript.ps1: This script will be executed in the service context after the creation of shortcuts on the desktop. Should contain a set of commands that need to execute after creating shortcuts and the current user doesn’t have permission, such situations can be executed in the service context.

Linux Session Host

The scripts can be updated at (folder):

/etc/edcdvm/linuxDVM/hyshell/

Available Scripts names:

  1. HyShellLauncherPreScript.sh: This script will be executed in the user context before creating shortcuts on the desktop. Should contain a set of commands that need to execute before creating shortcuts.

  2. HyShellServerPreScript.sh: This script will be executed in the service context before creating shortcuts on the desktop. Should contain a set of commands that need to be executed before creating shortcuts and the current user doesn’t have permission, such situations can be executed in the service context.

  3. HyShellLauncherPostScript.sh: This script will be executed in the user context after creating shortcuts on the desktop. Should contain a set of commands that need to be executed before creating shortcuts.

  4. HyShellServerPostScript.sh: This script will be executed in the service context after the creation of shortcuts on the desktop. Should contain a set of commands that need to be executed after creating shortcuts and the current user doesn’t have permission, such situations can be executed in the service context.