01 / SYMPTOM

The servers were up but unregistered

A group of non-persistent Windows Server 2019 targets could boot from PVS, join the network and reach the domain normally. However, they did not register with the Citrix Delivery Controllers during startup. In some restart cycles the broker treated the machines as unavailable before registration could complete.

The clue was the user login. As soon as someone signed in—or an administrator started the Citrix Desktop Service manually—the VDA registered without any further intervention.

02 / EVIDENCE

The registration path was healthy after boot

Checks after startup showed that DNS resolution, domain trust, network connectivity and controller reachability were healthy. The BrokerAgent service was stopped after boot, but a manual start kept it running and registered the VDA without requiring a user login.

KEY OBSERVATION

If the same service starts successfully a few minutes later, the failure is likely related to boot-time sequencing or timeout pressure.

Service state and configuration

Get-Service -Name BrokerAgent

Get-CimInstance Win32_Service -Filter "Name='BrokerAgent'" |
    Select-Object Name, State, StartMode, StartName, PathName

Relevant Service Control Manager events

Get-WinEvent -FilterHashtable @{
    LogName = 'System'
    Id      = 7000, 7001, 7009, 7011
} -MaxEvents 50 | Select-Object TimeCreated, Id, Message

The service ran as NetworkService and depended onLanmanWorkstation. Event evidence pointed to service startup timing rather than a broken VDA installation. Comparable Windows Server 2022 targets were not affected, which further narrowed the problem to the Server 2019 boot path.

03 / FAILED APPROACH

Delayed Start was not suitable for this image

Changing the Citrix Desktop Service to Automatic (Delayed Start) was tested in the platform layer. Although it addressed the same timing theory, the resulting published image was unstable and encountered a blue-screen failure during deployment.

04 / FIX

Give Windows more time to complete service startup

The successful remediation was to increase the Windows Service Control Manager timeout to 120 seconds in the image. The value is expressed in milliseconds and requires a restart before it takes effect.

$parameters = @{
    Path         = 'HKLM:\SYSTEM\CurrentControlSet\Control'
    Name         = 'ServicesPipeTimeout'
    PropertyType = 'DWord'
    Value        = 120000
    Force        = $true
}

New-ItemProperty @parameters
Scope matters.

ServicesPipeTimeout is a system-wide Service Control Manager setting; it is not limited to BrokerAgent.

05 / VALIDATION

The test required no interactive login for the broker service to start

After the updated image was published, we:

  1. Restarted the PVS target without signing in.
  2. Confirmed that BrokerAgent reached the Running state.
  3. Confirmed that the machine registered with the Delivery Controller.
  4. Repeated the reboot test to rule out a one-off successful startup.
  5. Launched a published resource through Citrix Workspace.

The targets subsequently booted and registered without a user session or manual service action.

06

LESSON

A login can hide a boot-time race

When a VDA registers immediately after a user logs in or the service is started manually, but does not register automatically after a reboot, the issue could be related to the Service Control Manager timeout.