Guest post by Niron Koren, ControlUp CTO Team

This blog post is a short follow-up to my previous entry on Troubleshooting Slow Logons. This updated script includes new logon phases and now covers the entire Citrix XenDesktop logon process, see details below.

HDX Connection Phase

Since my last post about logon duration analysis, we’ve received a lot of great feedback, among them some interesting requests and suggestions. One of these, which was repeated more than others, was to add the XenDesktop Director’s HDX Connection phase (which is a phase that takes place before Windows gets to play its role) to the script.

The updated script now covers the entire logon process, from the moment the user clicks on the published resource until the Desktop is available. The new module works by querying the XenDesktop Monitor service via OData API. The Windows session ID is translated to a XenDesktop SessionKey which is used in the OData API query.

Logon Phases

The following table is the updated “Logon Phases” table, which summarize the logon phases that the script covers. The new phases include HDX Connection and Session Init:

Logon Phase Name Logon Phase Description Start Event End Event
HDX Connection The time taken to complete the steps required in setting up the HDX connection from the client to the VM.[1] Based on OData query, HdxStartDate column. Based on OData query,

HdxEndDate column.

Session Init When a user logs onto the system, the initial Session Manager creates a new instance of itself to configure the new session. The new Smss.exe process starts a Windows subsystem process and Winlogon process for the new session.[2] Log name: Security

Event Id: 4688 (smss.exe start)

Log name: Security

Event Id: 4689 (smss.exe end)

Network Providers A Network Provider is a DLL which is responsible for a certain type of connection protocol [3], On each logon Winlogon notify these Network Providers so they can collect credentials and authenticate the user for their network [4]. Citrix PnSson is a common network provider found on XenApp and XenDesktop VM’s. Log name: Security

Event Id: 4688 (mpnotify.exe start)

Log name: Security

Event Id: 4689

(mpnotify.exe end)

Citrix Profile Management During logon, Citrix UPM copies the users’ registry entries and files from the user store to the local profile folder. If a local profile cache exists, the two sets are synchronized. [5] Log name: Application

Event Id: 10

(User X path to the user store is…)

Log name:

User Profile Service Event Id: 1

(Received user logon notification on session X.)

User Profile During logon, the system loads the user’s profile, and then other system components configure the user’s environment according to the information in the profile [6] Log name:

User Profile Service Event Id: 1

(Received user logon notification on session X.)

Log name:

User Profile Service Event Id: 2

(Finished processing user logon notification on session X.)

Group Policy

See Also

Enforce the domain policy and settings for the user session, in a case of synchronous processing, the user will not see their desktop at logon until user GP processing completes. [7] Log name: GroupPolicy

Event Id: 4001

(Starting user logon Policy processing for X)

Log name: GroupPolicy

Event Id: 8001

(Completed user logon policy processing for X)

GP Scripts Running the logon scripts configured in the relevant GPO’s, in a case of synchronous logon scripts, Windows Explorer does not start until the logon scripts have finished running. [8] Log name: GroupPolicy

Event Id: 4018

(Starting Logon script for X)

Log name: GroupPolicy

Event Id: 5018

(Completed Logon script for X)

Pre-Shell (Userinit) Winlogon runs Userinit.exe, which runs logon scripts, reestablishes network connections, and then starts Explorer.exe, the Windows user interface. [9] On RDSH sessions, Userinit.exe also executes the Appsetup [10] entries such as cmstart.exe which in-turn calls wfshell.exe. Log name: Security

Event Id: 4688

(userinit.exe start)

Log name: Security

Desktop session:

Event Id: 4688

(explorer.exe start)

Published Apps:

Event Id: 4688

(icast.exe start)


* (Only available when running the script via ControlUp)

The interval between the beginning of desktop initialization and the time the desktop became available to the user, also includes the Active Setup Phase. [11] Log name: Security

Event Id: 4688

(explorer.exe start)

ControlUp argument – “Desktop Load Time”

Script download link

Running the script


  • Windows PowerShell 3.0 and above
  • Local administrator privileges (required for querying the local event logs)
  • Read-only administrator role in the relevant XenDesktop site (Even if Full admin rights are present, it is recommended to add Read-only rights as well)
  • Enable the auditing of process tracking via GPO or local security policy (secpol.msc) on all target XenDesktop VDA’s
  • In order to support “older” user sessions it is recommended to increase the Security log size to 50MB or 100MB.
  • Supply Target user session ID as a script parameter
  • Updated Citrix Receiver (on the physical endpoint that initiated the target HDX session)

It’s worth mentioning that it might take a few seconds for XenDesktop to populate the HDX connection times in the Monitor service database.

Perform the following steps to execute the script via PowerShell:

  1. Import the script to the shell using the ‘Import-Module’ command. (e.g. “Import-Module C:\Scripts\AnalyzeXDLogonDurationAnalysis.ps1”)
  2. After importing the module you can call the Get-LogonDurationAnalysis function from the shell, the function accepts 4 parameters:
    1. –UserName: <The name of the user we want to examine>
    2. –UserDomain: <The name of the domain the user is member of>
    3. –HDXSessionId: <The Session ID of the target HDX session>
    4. –CUDesktopLoadTime: <Duration in seconds of the “Desktop Load Time” from ControlUp> [optional]
  3. Example – Get-LogonDurationAnalysis -Username MyUser -UserDomain MyDomain -HDXSessionId 3