Citrix® VDA Unregistered: Troubleshooting for CVAD and DaaS

In Citrix Virtual Apps and Desktops (CVAD) and Citrix DaaS, a VDA that shows Unregistered won't get any sessions brokered to it. Registration is Kerberos-based and mutual, so Citrix's own docs call time synchronization and domain membership issues "unforgiving" (Citrix docs: VDA registration). A reboot may bring it back, but it won't tell you why it dropped. Read the reason the broker recorded, then work down the stack in order.

How VDA registration works (short version)

A VDA reads a list of Controllers (on-premises) or Cloud Connectors (DaaS) called ListOfDDCs. If the list has several entries, it tries them in random order. You can set it four ways: Citrix policy (stored under HKLM\Software\Policies\Citrix\VirtualDesktopAgent), the registry (HKLM\Software\Citrix\VirtualDesktopAgent\ListOfDDCs), the legacy AD OU method, or MCS, which injects the list into Personality.ini. Citrix recommends GPO for the initial registration. After that, auto-update (on by default) caches the list on the VDA, and each Controller checks the site database every 90 minutes for changes (Citrix docs).

Two consequences matter when you troubleshoot:

• Registration is Kerberos mutual authentication over two channels, VDA to Controller and Controller to VDA. That is why you can't put a load balancer VIP in ListOfDDCs (Citrix docs).
• The registration port is TCP 80 by default (Citrix docs: Install VDAs). The WebSocket option needs only TLS 443 from the VDA to the Controller. The docs cover it for MCS-provisioned, AD-joined VDAs (CVAD, DaaS), and 2407 added enrollment tokens for non-MCS VDAs (2407 What's new).

Step 1: Read the deregistration reason

Before you touch the VDA, ask the broker why it dropped it. On a Controller, or in DaaS from the Remote PowerShell SDK after Get-XdAuthentication (don't install that SDK on a Cloud Connector, per the DaaS SDK docs), run:

$u = Get-BrokerMachine -RegistrationState Unregistered -MaxRecordCount 10000 |
     Where-Object { $_.PowerState -ne 'Off' }

$u | Select-Object MachineName, CatalogName, DesktopGroupName, PowerState,
     InMaintenanceMode, FaultState, LastDeregistrationReason,
     LastDeregistrationTime, AgentVersion |
     Sort-Object LastDeregistrationTime -Descending | Format-Table -AutoSize

# One machine or a pattern?
$u | Group-Object LastDeregistrationReason | Sort-Object Count -Descending |
     Select-Object Count, Name

RegistrationState can be Unregistered, Initializing, Registered or AgentError. LastDeregistrationReason and LastDeregistrationTime are standard properties (Citrix SDK: Get-BrokerMachine). In the console, Studio's Search node has Registration State, Last Registration Failure and Fault State columns (Citrix docs). Director's Filters > Machines view has a Failure Reason column with recommended actions (Citrix docs).

Map the reason to a layer. The meanings below come from Director's failure-reason reference (Citrix docs):

AgentRequested isn't in Director's table. As the name says, the deregistration came from the VDA side, so start with the VDA's Application log.

Step 2: Check the Controller's Broker Service events

The Citrix Broker Service logs to the Application log on each Controller. Citrix documents these registration events (Citrix Broker Service events):

• 1030: VDA properties incomplete; the servicePrincipalName is missing or incorrect.
• 1033: DNS failed to resolve the VDA, so the broker falls back to NetBIOS. 1036 means that fallback failed too and the registration was rejected.
• 1039: the broker couldn't contact the VDA. Check that the VDA's firewall allows connections from the Controller.
• 1047: the VDA's agent version is too old. 1050: registration limit reached. 1051: contradictory identity (SID) in the request.

Get-WinEvent -FilterHashtable @{ LogName='Application'; ProviderName='Citrix Broker Service';
  Id=1030,1033,1036,1039,1047,1050,1051 } -MaxEvents 50

The throttling events (1031, 1034 and so on) mean the broker is suppressing repeats, so one event can stand for many VDAs. Get-WinEvent and its hash-table keys are documented on Microsoft Learn.

Step 3: Confirm the VDA knows the right Controllers

On the VDA:

reg query "HKLM\Software\Policies\Citrix\VirtualDesktopAgent" /v ListOfDDCs
reg query "HKLM\Software\Citrix\VirtualDesktopAgent" /v ListOfDDCs

Check for these, per the VDA registration docs:

• Use FQDNs separated by spaces. Don't use IPs (unless you also maintain ListOfSIDs) or a VIP, and don't rely on CNAMEs, which auto-update replaced. Invalid entries delay startup registration.
• A stale GPO that still lists decommissioned Controllers will override what you set at install time, because policy has the higher priority.
• Controller groups in parentheses need the "Enable auto update of Controllers" policy prohibited.
• If an entry can't be found, the agent can fall back to an AD-wide search, which can hammer domain controllers. DisableDdcWildcardNameLookup (DWORD, non-zero) turns that fallback off.

The auto-update cache sits in a SYSTEM-only location (find it with the WMI query in the docs). Don't edit it.

Step 4: Time, Kerberos and the machine account

Check the clock on the VDA and on the Controller:

w32tm /query /status
w32tm /resync

Kerberos rejects timestamps outside the "Maximum tolerance for computer clock synchronization", which is 5 minutes in the Default Domain Policy (Microsoft Learn). The w32tm options are in the Windows Time tools reference.

Then check the machine account:

Test-ComputerSecureChannel -Verbose      # $true = healthy
Test-ComputerSecureChannel -Repair       # only after you understand why it broke
setspn -L <VDAHOSTNAME>                  # HOST/ SPNs present?

Test-ComputerSecureChannel is for domain members and uses Netlogon (Microsoft Learn). setspn -L lists a computer's registered SPNs (Microsoft Learn). For DNS, run nslookup from the Controller against the VDA's FQDN and its IP, and from the VDA against every Controller. Citrix's guidance for AgentAddressResolutionFailed is to make sure the VDA's name and IP in DNS are accurate (Citrix docs).

Step 5: Ports and firewalls

Test-NetConnection -ComputerName ddc01.corp.example -Port 80    # or 443 for WebSocket VDAs

(Microsoft Learn: Test-NetConnection). Remember that registration runs both ways: event 1039 on the Controller means the VDA's firewall is blocking the Controller. The VDA installer opens the ports by default. If someone changed the port, check it under Programs and Features > Change > Customize Virtual Delivery Agent Settings (Citrix docs).

In DaaS, a custom VDA port must be set on every Cloud Connector with XaXdCloudProxy.exe -VdaPort and HighAvailabilityService.exe -VdaPort <port> -ConfigureFirewall, and match on every VDA. Verify it with netsh http show urlacl and the "Citrix XaXdProxy" and "Citrix Broker Service (TCP-In)" firewall rules (DaaS docs).

Step 6: Restart the Desktop Service and watch it register

Restart-Service -Name BrokerAgent   # the Desktop Service; Citrix's Cloud Health Check calls it "BrokerAgent"

Director's guidance for several reasons is to restart the Desktop service and confirm in the VDA's Application event log which Controllers it tried (Citrix docs). If the VDA re-registers and then drops again, the restart only hid the cause. Go back to Steps 3–5.

Step 7: Versions and functional levels

A catalog's functional level sets the minimum VDA version. Machines with an older VDA in that catalog can't register (Citrix docs). Check this after every catalog or image update. Compare AgentVersion with the catalog's minimum. For EmptyRegistrationRequest or MissingAgentVersion, Director points to a corrupt VDA install, and the answer is a repair or reinstall.

Step 8 (DaaS): Check the Cloud Connectors first

If many VDAs in one resource location go unregistered at once, suspect the Connectors first. The Resource Locations page shows Connector health. Citrix now points to DaaS Infrastructure Monitoring for Connector metrics and alerts (Citrix Cloud docs). On the Connector itself, look for these events (Citrix Cloud docs):

• 10002: unable to connect to the messaging service.
• 10004 / 10103: ClockOutOfSyncError. Fix the time and the UTC time zone.
• 10005 / 10006: the hourly connectivity check failed.

Logs are in C:\ProgramData\Citrix\WorkspaceCloud\Logs. VDAs need a valid Connector address in the same resource location (DaaS docs).

Step 9: Let the health tools confirm it

• Cloud Health Check checks domain membership, communication port, service status, Windows firewall, Controller communication, time sync and registration status. It can auto-fix some of these, for example a secure-channel repair, restarting the BrokerAgent service or running w32tm (Citrix docs). Run it from a domain-joined machine, not a Connector.
• In DaaS, Studio > Search > Run Health Check needs VDA 2109+ and only works on registered VDAs (Citrix docs). Run it on a healthy machine from the same catalog for comparison.
• Citrix Scout runs the same VDA registration checks on-premises (Citrix docs). Citrix Health Assistant is the standalone tool for unregistered VDAs, documented in CTX207624. The product docs refer deeper cases to CTX136668.

FAQ

What does "Unregistered" mean in Citrix Studio?

The machine failed to register within the expected period, or its registration was rejected (Citrix docs). It's powered on but can't take sessions.

What does "Contact lost" mean on an unregistered VDA?

ContactLost means the Controller lost its connection to the VDA, often through a network disruption. Check that the Broker Service and Desktop Service are running, the Controller list, and connectivity (Citrix docs).

Why is my Citrix VDA unregistered after a reboot?

Usually something the machine gets at boot is wrong: an image or GPO with stale ListOfDDCs, clock drift, or a catalog functional level the image's VDA doesn't meet. Note also that auto-update's persistent cache isn't kept with Citrix Provisioning server-side cache, so those machines fall back to the initial method every boot (Citrix docs).

What port does Citrix VDA registration use?

TCP 80 by default (configurable), or TLS 443 only when you use WebSocket registration (Citrix docs).

Want a second pair of eyes?

If unregistered VDAs keep coming back, look upstream: GPOs, image hygiene, Connector health and version drift. The Sessionwright assessment reviews your Citrix site end to end, read-only, and an expert reviews the report before you get it. Sessionwright for Citrix is read-only by default, and any change it proposes is approved by you and logged (security model). For the wider sweep, see our Citrix health check checklist.

Sources

• Citrix docs: VDA registration
• Citrix docs: Install VDAs (CVAD) and Install VDAs (DaaS)
• Citrix docs: WebSocket communication between VDA and Delivery Controller (CVAD, DaaS); CVAD 2407 What's new
• Citrix SDK: Get-BrokerMachine; DaaS Remote PowerShell SDK
• Citrix docs: Machine actions and columns; Director failure reasons; Director: Troubleshoot machines
• Citrix docs: Citrix Broker Service events
• Citrix docs: VDA versions and functional levels
• Citrix Cloud docs: Cloud Connector technical details; Connector advanced health checks (deprecated)
• Citrix docs: Cloud Health Check; Troubleshoot VDA registration (Run Health Check); Citrix Scout
• Citrix Knowledge Center (referenced by the docs above): CTX136668, CTX207624
• Microsoft Learn: Maximum tolerance for computer clock synchronization; Windows Time tools (w32tm); Test-ComputerSecureChannel; Setspn; Test-NetConnection; Get-WinEvent