This article describes Windows registry entries that control detailed behavior of the XenDesktop 5 broker service. The broker service is one of the components that comprise a XenDesktop Desktop Delivery Controller (DDC) installation.
This article relates specifically to the XenDesktop 5 broker service, for earlier versions of XenDesktop, or for settings relating to the Virtual Desktop Agent (VDA), refer to CTX117446 -Registry Key Entries Used by XenDesktop.
Settings described in this article can be modified using the Windows Registry Editor (regedit).
Refer to the Disclaimer at the end of this article before using Registry Editor.
The common root of the registry entries listed in this article isHKEY_LOCAL_MACHINE\Software\Citrix
These entries can be used to control the detailed behavior of the broker service running on the local machine.
All listed settings can also be controlled using values delivered by GPO; this might typically be used to apply common settings to all broker services in a site. Settings that GPO delivers appear under a local root ofHKEY_LOCAL_MACHINE\Software\Policies\Citrix
Setting tha GPO defines takes precedence over any value of the same setting defined under the local registry root (HKEY_LOCAL_MACHINE\Software\Citrix). This overriding occurs on a per-setting basis so that some settings can be defined locally and others through GPO if desired.
Note: Do not change the values of the registry entries used for GPO delivered settings using Registry Editor.
The following table lists various registry entries that control the overall behaviour of the XenDesktop 5 broker service. On a cleanly installed DDC these registry entries do not exist. When any given entry is not found, the specified default value is used.
Default DWORD values are shown in decimal. Note however that Registry Editor defaults to displaying and editing DWORD values in Hexadecimal; ensure that Registry Editor is switched to Decimal entry if using values shown in the following table:
Maximum time allowed for registration sequence of a single VDA to complete. If the registration fails to complete within this time, the VDAs partial registration is discarded by the DDC.
Period after which a session launch request that causes a power-managed Virtual Machine (VM) to be started, but where the VM does not subsequently register with a DDC, is considered to have failed.
See also settings MaxSessionEstablishmentTimeSecs and ExtraSpinUpTimeSecs; the timeout defined by these runs concurrently with that of MaxLaunchRegistrationDelaySec.
Period after which a power-managed VM started by the broker service, but which does not subsequently register with a DDC, is shutdown.
This timeout applies irrespective of the reason for the startup, which might be to satisfy a launch request, maintain idle pool levels, or have been administrator requested through the SDK.
Controls both the interval and timeouts used for the keep-alive pings from the VDA.
This value is sent from the DDC to VDA and causes the VDA to ping the DDC at an interval half that of the time specified by this setting. By default the DDC will consider contact to have been lost, and discard the VDAs registration if no ping is received within the full time specified (that is, the timeout is double the ping interval).
The maximum period over which no ping is received before contact is considered to have been lost can be controlled independently of the VDA ping interval itself using the MaxHeartbeatIntervalMs setting.
The default timeout is 10 minutes (with a corresponding ping internal of 5 minutes).
Note: Prior to XenDesktop 5 Service Pack 1 the default timeout and ping interval were 1 minutes, and 30 seconds, respectively.
Defines the maximum period between receipt of two pings from a VDA by the DDC before contact is considered to have been lost and the VDAs registration discarded. By default, where this setting is not specified, the value of the HeartbeatPeriodMs setting is used.
If specified, this value must be at least half that of the current HeartbeatPeriodMs value, otherwise the HeartbeatPeriodMs value overrides this setting.
This setting does not change the frequency at which a VDA sends out pings to a DDC.
Allows the DDC to accept registrations from VDAs in a different Active Directory forest to that containing the DDC itself. In this situation, the VDA must be authenticated using NTLM rather than the more secure Kerberos protocol, thus this feature is disabled by default.
Note: Multiple forest VDA registration support requires additional configuration changes as described in
Set to 1 to enable cross-forest registration support.
Maximum number of VDA registrations (both hard and soft) that a given DDC will accept.
If set, overrides the configuration from Web Interface for the maximum time allowed before a launch is aborted if a connection from an endpoint client is not received.
Time after which a session launch is assumed to have failed by the DDC if no active session has been established on the target machine, or if a disconnected session has not returned to the active state following a reconnect operation.
See also the settings ExtraSpinUpTimeSecs and MaxLaunchRegistrationDelaySec.
Additional time to allow for session establishment if the target power-managed VM must be started as part of a session launch.
This value is added to that specified by MaxSessionEstablishmentTimeSecs.
Indicates whether the ability to connect to an active desktop session from a different client is disabled. By default it is possible to connect to an active session from a different client without first disconnecting the session from the original client.
This setting does not apply to application sessions.
Set to 1 to disable reconnections to active session.
Maximum time the DDC waits for a session disconnect to occur after a disconnect request has been issued.
Controls automatic placement of power-managed VMs into maintenance mode following repeated failures to register with a DDC.
If a VM is started-up by the broker service but fails to register after the period defined by the MaxRegistrationDelayMin setting (default 20 minutes), it is shutdown again.
The MaxFailedRegistrationsAllowed value defines the maximum number of times that this start-up, registration failure, shut down cycle is allowed to repeat before a subsequent registration failure causes the VM to be automatically placed into maintenance mode.
The default value of 2 means that if the VM fails to register 3 times in succession, it will be automatically placed into maintenance mode.
Setting MaxFailedRegistrationsAllowed to a negative value (0xFFFFFFFF) disables this behavior and prevents VMs from ever being automatically placed into maintenance mode.
Maximum elapsed time over which an SQL command batch can be retried when database connectivity appears to have been lost.
This determines the maximum period that the broker service reports state PendingFailure through the SDK before transitioning to Failed.
Period after which cached Active Directory user/group account or machine name details are routinely refreshed where the Security Accounts Manager (SAM) name (domain\account) of the cached entity has been successfully obtained.
Period after which a new attempt is made to refresh cached Active Directory user/group account or machine name details following a failed attempt to obtain the SAM name (domain\account) of the cached entity.
The cache might thus contain either no SAM name or a potentially out of date name during this period.
The default refresh period after a failure is 1 hour.
Time for which completed power-managed VM power action entries are retained in the database before being purged.
Time for which connection log entries are retained in the database before being purged.
Time for which hypervisor alert records are retained in the database before being purged.
Globally Unique Identifier (GUID) of an Active Directory security group object to be used as the Controllers security group instead of the default one in the site Organizational Unit (OU).
CTX138738 -Registry Key Entries Used by XenDesktop 7.x
Caution! Using Registry Editor incorrectly can cause serious problems that might require you to reinstall your operating system. Citrix cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk. Be sure to back up the registry before you edit it.
Open a ticket online for technical assistance with troubleshooting, break-fix requests, and other product issues.
WithCustomer Success Services, you can chat with a Technical Support agent about simple issues, rather than open a case.
Get called back by an engineer for assistance with troubleshooting complex issues.
Search for an answer or post a question to members of the Citrix Discussions community.