Skip to content

Advance Configurations

Direct RDP/Console Block

Direct access to virtual desktops can introduce significant security risks and session conflicts. This document outlines a feature that restricts direct RDP access via MSTSC or non-Accops clients, 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 both normal and admin users from connecting directly via RDP.

    2. Flag Value: true or false

    3. Behavior: If set to true, admins cannot 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, the latest and advance method. A virtual channel will be used to verify whether the session was established via the client or directly via RDP. If it is a direct RDP connection, 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 when connecting via direct RDP.

      2. If set to 1, the user will be logged out of the Desktop session when using a direct RDP connection.

Steps to Configure:

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

  2. Open the Registry Editor and set all flags 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 connect to the configured virtual desktop via RDP 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 the 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 the 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 the 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 the client response are valid, the session continues. 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 it depends on the endpoint 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 earlier 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 the authorized Accops endpoint > Clicks on the desktop icon to request connection information from the 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 the assigned desktop. Desktop connection gets established.

  4. The agent validates the connected desktop using the information provided by the Controller in step #2.

  5. If the details of the connected session and the information received from the Controller are found to be valid, the session can 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.

External log Settings

In some deployments, it is required to get user session monitoring for audit purposes; the feature is integrated with HyWorks DVM Agent. Two types of monitoring are available:

  1. User Session Monitoring
  2. Process Monitoring

Registry Base:

HKEY_LOCAL_MACHINE\SOFTWARE\Accops\DVMAgent\ADVANCE SETTINGS\EXTERNAL LOG SETTINGS

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

Key Name Default Value Type Value Range
TrackingType 0 String 0: Disabled
1: User Session Monitoring
2: Process Monitoring
3: Both
IgnoreList C:\Windows\System32* Multi String Processes/folders to be ignored for process tracking
SyslogHost 0.0.0.0 String Syslog server or Accops ARS Server IP address or Hostname
SyslogPort 514 String Syslog server or Accops ARS Server Port number
DumpProcessMonToSyslog False String When set to true, it will start pushing process monitoring logs to the configured syslog server.
DumpUserSessionMonToSyslog False String On setting to true, it will start pushing user session monitoring logs to a configured syslog server.

Allow calls from authorized controller(s) only

In some deployments, blocking unauthorized access to the DVM Agent service is required. The administrator can configure the unauthorized access block by updating the list of authorized controller IPs at (default value: '*').

HKLM\SOFTWARE\Accops\DVMAgent\AuthorizedControllerIPs

Note

- The Default value is set as '*', which means all controllers are open to connecting.

- Replacing '*' with one or more (multi-string) controller IPs allows only those listed controller(s) to communicate with the local DVM Agent Service.

- If an unauthorized controller tries to communicate, an error log will be created in both the DVM Agent and the controller logs.

Graceful Shutdown via Desktop Agent

Problem Statement: With non-persistent VMs, HyWorks initiates the VM shutdown upon user logout. In previous versions, this shutdown was managed through a connector, and in some cases, race conditions where the logout event was not fully processed caused the connector-triggered shutdown to overlap with the logout sequence, leading to user profile corruption.

Enhancement: The shutdown process is now handled by the Desktop Agent instead of the Connector. The Desktop Agent will wait until the user logout is fully complete before initiating a graceful shutdown of the VM. This guarantees consistent behavior and prevents profile corruption issues.

Compatibility and Support

  • Desktop type: Single-session.

  • Desktop Platform: Windows only.

  • Desktop Pool: Non-persistent.

  • Agent Status: Responding.

  • Desktop Agent Version: v3.6.0.1357 (v3.6-SP2)

Important

From HyWorks controller v4.0, all power operations (except Suspend) for any type of pool, configured in the advance tab of the desktop pool, are executed only through the DVM agent.

  • Desktop Agent Version: v4.0.1432 or more

Admin-initiated power operations are not executed through the agent and still follow the connector's previous flow.

Auto Shutdown of Unused Single-session Desktop(s)

The auto-shutdown mechanism for single-session desktops aims to optimize resource usage and reduce unnecessary cloud billing. The enhancement ensures that unused desktops are automatically shut down based on session activity, as reported by the DVM agent.

Supported Release

  • HyWorks Controller: v3.6-HF1.1 or later.

  • DVM Tools: v3.6.0.1357 or later.

Workflow

The auto-shutdown feature operates using the following workflows:

  • Desktop Agent reports real-time session status (active/disconnected/none).

  • HyWorks Controller stores and continuously monitors this session data.

  • A background thread runs periodically to evaluate whether shutdown criteria are met.

  • If all required checks pass, the VM is shut down by the HyWorks Controller.

Shutdown Criteria - Required Conditions

# Criteria Requirement
1 Desktop Type Must belong to a single-session desktop pool.
2 VM Status Must be in a powered-on state.
3 Powered-On Duration Must be powered on for longer than the configured threshold (Desktop powered-on time before auto-shutdown).
4 No Active Session Duration No active session for longer than the configured threshold (Auto VM Shutdown If VM Has No User Session Since In Min).
5 Operating System Must be running a Windows OS.
Not supported with Linux Desktops for v3.6 releases.
6 DVM Agent Version Must be greater than v3.6.0.1357.
7 Sysprep Status Sysprep is not required, has not been completed, or the status is unavailable.
8 Snapshot Status Snapshot is not required, completed, or the status is not available.
9 Disk Encryption Status Disk encryption is not required, is not completed, or the status is unavailable.
10 AVD Session Host Status AVD registration is not required, completed, or the status is not available.
11 Pool Type Eligibility HyLabs Single-session Desktops, HyWorks Single-session Desktops, or both, based on configuration.
Additional Recommendations

  1. Active Session Monitoring is recommended: The auto-shutdown mechanism relies on accurate real-time session data from the DVM Agent. Incorrect or missing session data may prevent VMs from shutting down.

  2. HyLite environments require VM Scale Booster: In HyLite deployments, session dismissal information does not reach the HyWorks Controller directly. VM Scale Booster is required to ensure proper session tracking and auto shutdown.

Configurations for Auto Shutdown

The auto shutdown feature can be enabled or disabled in HyWorks Controller Advanced Settings.

Management Console > Settings > General > Advance Settings > Tags Filter - AutoShutdown: All relevant configurations will be displayed.

Configuration Description Possible Values
Auto shutdown type Enables or disables auto shutdown and defines which desktops are eligible (HyLabs, HyWorks, or both). 0: (Default) Feature Disabled
1: HyLabs and HyWorks single-session desktops
2: HyLabs single-session desktops only
3: HyWorks single-session desktops only
Desktop powered on time before auto shutdown Minimum time (in minutes) a single-session desktop must remain powered on before it becomes eligible for auto shutdown. Time in minutes
Default: 60
Auto VM shutdown if the VM has no user session since Minimum time (in minutes) since the last user session before the VM becomes eligible for auto shutdown. Time in minutes
Default: 60
Auto shutdown interval Interval (in seconds) at which the background thread checks session status for eligible desktops. Time in seconds
Default: 600

Once the above configurations are applied, HyWorks Controller will automatically shut down eligible VMs that remain powered on beyond the configured duration and have no active user sessions.

Live (Usable) IP Address Detection

By default, HyWorks uses the IP address provided by the Provider (or Connector) to communicate with the desktop agent. In some cases (especially with Nutanix), it has been observed that the Connector caches the IP address assigned to the VM and then reports multiple IP addresses for the VM, with one stale and the other current.

The default mechanism in HyWorks is to pick any IP address and communicate with the desktop agent, but if the selected IP address is stale (cached), the agent status will become unreachable, affecting multiple functions, including connection failures.

In such cases, this advance feature can be enabled from HyWorks Controller - Advance Settings:

Management Console > Settings > General > Advance Settings > Filter multiple IP addresses by calling Desktop Agent: Default false, and can be set to True to enable this feature.

How this works:

  1. Once the setting "Filter multiple IP addresses by calling Desktop Agent" is enabled.

  2. The Controller, while setting up the IP address for the VM, checks all reported IPs for the VMs.

    1. If a single IP address is there, it will be set.

    2. If multiple IP addresses are reported, the controller creates a thread to call the DVM agent for each IP address.

      1. It will set the first IP address that responds, ignoring the others, thereby avoiding the problem of setting an invalid IP address.

Supported Versions

  • HyWorks Controller v3.6 or above.

Pre-Post OS Customization Batch Scripts

In some deployments, it is required to run scripts before OS customization (SysPrep or HyPrep). The feature is integrated with HyWorks v3.3.

Two types of customization scripts are supported here:

  1. Pre-customization [Pre_Customization_System.bat]

  2. Post-customization [Post_Customization_System.bat]

Path:

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

Post Reset Computer Domain Trust Batch Script

In some deployments, it is required to run scripts after the broken domain trust is reset; this feature is integrated into HyWorks. The path of the script is as follows:

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

Note

HyWorks only provides a platform for executing scripts in response to various system events. The scripts have to be generated as per requirements.

Suspending Processes in Disconnected Sessions

HyWorks Session Host Server and HyWorks DVM Agent (v3.3-R2 or later) can be configured to suspend the process in disconnected sessions. The feature helps free up CPU resources in disconnected sessions, allowing other users on the system to benefit from the available CPU.

How does it work

  • On session disconnection, the session host server/DVM agent will suspend processes.
  • On session reconnection, suspended processes will be resumed.

Configurations to Suspend Processes on Session Disconnection

To enable process suspending:

  1. Open the registry editor with administrator privileges.

  2. Update registry settings, as mentioned below:

    • Registry Location: HKEY_LOCAL_MACHINE\SOFTWARE\Accops\DVMAgent\SUSPEND PROCESS
    • Registry Name/ Type: Enable (String).
    • Registry Value: Set as True to enable process suspending/ Set as False to disable process suspending.

  3. Save registry settings.

  4. Open services with administrator privileges.

  5. Locate Accops HyWorks Desktop Agent service and restart.

Advance Configurations

The following additional registry configurations are available, which can be used to enable process suspending for specific users/ processes only:

  • exclude_users: To exclude suspension of processes for a particular user. Provide a list of users in comma-separated format, for example, user1.demo,user2.demo,user3.demo. Use this option to enable process suspension for all users except a few.

  • exclude_processes: Provided processes will not get suspended. Provide a list of processes in comma-separated format, for example: notepad, write,mspaint. Use this option to enable process suspension for all processes except a few.

Note

Some critical system processes are already added into the exclude processes list and should not be removed for smooth operations.

  • include_users: The Suspend process will work only for the provided list of users. All other users will be exempted. Use this option to enable process suspension for specific users only.

  • include_processes: Only provided processes will get suspended; all other processes will be exempted. Use this option to enable process suspension for specific processes only.

Important

For any registry changes, DVM agent service needs to be restarted for changes to take effect.

vTPM-Aware VM Deployment

Overview

HyWorks v4.0 or later supports deployment of virtual machines from Golden Masters (GM) with Virtual Trusted Platform Module (vTPM) enabled. When vTPM is configured on a GM, HyWorks ensures that cloned VMs are deployed only on compatible hosts.

Prerequisites

  • Golden Master with vTPM enabled.

  • Connector Supported for vTPM Aware Cloning: VMware only.

    • vCenter with ESXi hosts with TPM support enabled.

    Note

    HyWorks does not check for vTPM compatibility while cloning for other providers than VMware. It may clone the vTPM connfigurations as it is but if destination host does not have compatible vTPM configurations, VM may have issues.

  • Supported TPM version.

  • Hosts properly registered with HyWorks.

Deployment Workflow

  1. HyWorks checks whether vTPM is enabled on the selected Golden Master.

  2. If vTPM is disabled, standard host selection is applied.

  3. If vTPM is enabled, host selection is restricted to TPM-capable hosts.

  4. HyWorks validates host capability using:

    • HostSystem.Capability.tpmSupported

    • HostSystem.Capability.tpmVersion

  5. Non-compliant hosts are excluded.

  6. The virtual machine is deployed on a validated host with vTPM enabled.

Limitations

  • vTPM-enabled VMs can be deployed only on TPM-supported hosts.

  • Migration is limited to compatible hosts.

  • Cross-cluster deployment requires uniform TPM support.

Summary

HyWorks enforces vTPM-aware host selection to ensure secure and reliable deployment of virtual machines from vTPM-enabled Golden Masters.