Reduce Citrix Director Interactive Session Time to as little as 3 seconds

The Interactive Session metric recorded by Citrix Director has always confused those trying to investigate why logon times are so high.

In this post I’ll explain how you can cut Interactive Session time by more than 60% immediately. You can reduce the time to as little as 3 seconds. This allows Citrix Director logon time reporting to become much more accurate.

If you are running VDA 7.14.1+ then you don’t need to do anything to upmEvent.exe as described in this post, however I still recommend you read the post as it is interesting to understand how Director calculates logon times. If you are running versions earlier than 7.14.1 then this post will fully apply to you.

For more logon time reduction tips see http://www.jgspiers.com/citrix-director-reduce-logon-times/

Changes to VDA 7.14.1+ – upmEvent.exe is now run as part of Winlogon:

Since this post was originally created in May 2017, Citrix have since in VDA 7.14.1 and above removed the upmEvent.exe run key and moved it to the Userinit string. It was only when James Kindon reported to me that he wasn’t seeing the run key on VDAs 7.14.1+ (thanks!) that I decided to investigate myself and realised the change.

This change results in upmEvent.exe running much quicker than previous versions because Citrix have allowed Winlogon to run the .exe, moving upmEvent.exe away from the Run registry key. This is an out of the box enhancement.

What is Interactive Session Time?

From https://www.citrix.com/blogs/2016/08/19/interactive-session-of-logon-duration-in-citrix-director-explained/

It is the time taken to handoff keyboard and mouse control to the user after the profile of the user is loaded for a session.

Event ID 2 is initially logged on the VDA shortly after a desktop/application icon is clicked within Receiver client or Receiver for Web. This event triggers the Interactive Session timer which ends once Event 1000 is logged to indicate that the session is ready for use. Event ID 1000 is logged by the Citrix Profile Management service.

So whilst Director records logon times, it is important to understand that this is the time taken from clicking to launch a resource until the machine is actually usable even though the actual logon may have completed some time before that. This produces innacurate results in Director for true logon times.

The Interactive Session time is calculated once Event ID 1000 is logged on the VDA. The faster the UPM Event User Message runs the quicker Event 1000 is logged and the calculation is complete.

So ideally we want upmEvent.exe (or UpmUserMsg.exe for VDAs prior to v7.7) to run once we see that desktop wallpaper as that is when the logon is complete. By default on VDAs before 7.14.1, it instead runs some time after the profile has loaded. In VDA 7.14.1 and above, upmEvent.exe runs at user logon, even before the desktop wallpaper has loaded. This results in more accurate logon times out of the box.

For VDAs earlier than 7.14.1, what is faster than startup applications specified within the Run key? A log on Scheduled Task or specifying upmEvent.exe in the Userinit registry string..

On VDAs earlier than 7.14.1, open your gold image or Citrix App Layering Platform Layer (the Platform Layer should contain your VDA software). Launch RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Delete the Citrix UPM UserMsg string. Finalise the image.

Now using Group Policy, create a new GPO which applies to all users logging on to the VDA.

Within the GPO expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).

On the General tab specify a name. Keep the task running under %LogonDomain%\%LogonUser%. Set Configure for to Windows 7 or the highest available OS.

On the Triggers tab click New.

For Begin the task choose At log on and for Any user. Click OK.

On the Actions tab click New.

Under Action select Start a program. Under Program/script enter “C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe” and beside Add arguments (optional) enter wait. Click OK.

Click OK to finish creating the Scheduled Task. When users log on to a VDA the UPMEvent.exe program launches via Scheduled Task immediately when the desktop shell has loaded.

With UPMevent.exe being started now by the Scheduled Task the average logon time has dropped to 13 seconds. Notice the Interactive Session times are all at 3 seconds, more than 50 seconds lower than a default XenDesktop 7.13 installation I ran my testing on. These results are on a non-persistent VDA which is rebooted between each logon.

Director is logging much truer logon times and our future reports will be much more accurate.

Note: In VDA versions before 7.7, upmEvent.exe was called upmUserMsg.exe.

Alternatively, instead of using a Scheduled Task for VDA 7.13 and below, you could instead move upmEvent.exe to the Userinit string. You can perform this change directly in an App Layer or gold image if using PVS/MCS. This is exactly what Citrix are doing in 7.14.1 and above VDA releases. This string is stored under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

Difference in logon times between VDA 7.13 and VDA 7.16 out-of-box installs:

I’ve done some testing on the difference between Director logon duration recordings from a VDA 7.13 machine which has upmEvent.exe specified under the Run registry key and VDA 7.16 which has upmEvent.exe specified under the Userinit string. These are simple tests, no profile management or such is used.

Testing logons with a VDA 7.13 machine:

Citrix Director recorded times:

  • Logon 1: 32.534sec
  • Logon 2: 31.447sec
  • Logon 3: 31.8sec

Stopwatch recorded times:

  • Logon 1: 18.7sec
  • Logon 2: 17.43sec
  • Logon 3: 17.63sec

Outcome: Director is reporting around 13-15 seconds longer logon times than what I am recording when timing resource launch to reaching the desktop wallpaper.

Testing logons with a VDA 7.16 machine:

Citrix Director recorded times:

  • Logon 1: 21.57sec
  • Logon 2: 20.466sec
  • Logon 3: 21.713sec

Stopwatch recorded times:

  • Logon 1: 25.47sec
  • Logon 2: 25.26sec
  • Logon 3: 26.22sec

Outcome: Director is reporting around 4-5 seconds shorter logon times than what I am recording when timing resource launch to reaching the desktop wallpaper.

As you can see, with upmEvent.exe running as part of Winlogon, Director is recording a logon time shorter than what the stopwatch is. The stopwatch time is the time taken to click on the desktop resource in Receiver for Web to first seeing the desktop wallpaper. This means that Director on average is recording a logon time 4-5 seconds before the user actually sees a desktop wallpaper.


22 Comments

  • Sommerers

    May 3, 2017

    Do you know if a GPO Scheduled task is faster than a WEM task? I assume it would be but figured I’d inquire.

    Reply
    • George Spiers

      May 3, 2017

      I’ll bet that a Scheduled Task is faster than WEM – give it a shot?

      Reply
      • Sommerers

        May 3, 2017

        I’m toying with this right now, but so far the results from WEM aren’t impressive. I still need to do an assignment order test to see if that makes any differences. I did also test with a GPO Scheduled Task but didn’t get as low of a result as you did, but I believe this is due to my configuration. If someone else is noticing the same you can go into the eventlog and under “Applications and Services\Microsoft\Windows\TaskScheduler\Operational” you can validate that the UPMEvent triggers in the first 3 seconds of logon. I did have a question about the GPO Schedule. By default the Priority is set to 7 for the task if we could somehow bump it to 4 would this improve the interactive Session more? I really don’t know what the metrics would looks like and if this would really help align the login time more. I was just looking up something and started wondering what would happen.

        Reply
        • George Spiers

          May 3, 2017

          The priority can be changed by editing the scheduled tasks XML file within SYSVOL. Setting a priority of 6 didn’t have a big effect on the logon times. Some times were lower and others higher.

          Also see http://www.jgspiers.com/citrix-director-reduce-logon-times/ for some more logon improvement tips. I used these to help get the times down to 3 seconds.

          Reply
  • Sommerers

    May 3, 2017

    I think there is a typo at “%LogonDomain%\LogonUser%” it looks like you are missing a “%”.

    Reply
    • George Spiers

      May 3, 2017

      Yes it is a typo, thanks. Corrected!

      Reply
  • pzario

    May 3, 2017

    when i set Scheduled task , interactive session increase to 2x time ?
    normal : 5 sec
    with ur option : 10-12 sec

    Reply
    • George Spiers

      May 3, 2017

      That is not normal. Do you have the Scheduled Task set to run at log on? To be honest, if you are already getting 5 second Interactive Session Time then you are OK.
      This will more help people whose current times are above the 20+ mark.

      Reply
  • James

    May 4, 2017

    awesome! bit of typo in the schedule task creation – need to specify the full path to the .exe 🙂

    “C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe”

    Reply
    • George Spiers

      May 4, 2017

      The Scheduled Task doesn’t require .exe to be filled in, atleast for me it didn’t. Did you have to specify it?

      Reply
      • James

        May 4, 2017

        I did in both the environments i put it into today – without the .exe i got a “not found” error in task scheduler – epic results though, this has been a nuisance for a long time so well played 🙂

        Reply
        • George Spiers

          May 4, 2017

          Thanks James.

          Reply
  • Kai Guettner

    May 4, 2017

    So does this actually reduce the login time, or just the representation of it in Director?

    Reply
  • ourgeisinger

    July 12, 2017

    Check the event log for the UPMID. Use the time as a starting point in Procmon to go back in time for the amount of time shown in Director for the interactive session.

    Reply
  • Dustin

    January 10, 2018

    Does this allow the user to get to work on the desktop quicker or is it just about making director show a lower interactive session? I have a customer getting 23 second interactive session time consistently on Non Persistent VDI with no UPM in play.

    Reply
    • George Spiers

      January 10, 2018

      Optimisations allow the user to get to work quicker. Creating a lean, well controlled image. The post is designed to straighten out the logon time reports that show in Director. For optimising an image and some tips on reducing logon times see http://www.jgspiers.com/citrix-director-reduce-logon-times

      Reply
  • Dimitris

    January 17, 2018

    I performed this change but now on director I get “the logon duration data for the current session is not available”

    Reply
    • George Spiers

      January 17, 2018

      That to me would indicate that upmEvent.exe did not run, and Event ID 1000 was not generated. Check the Scheduled Task to see why it is not running.

      Reply
  • Steve Elgan

    February 1, 2018

    In my environment it’s almost as if it just ignores the interactive session piece all together in the calculation. Without this change director shows about 43 seconds which is really close to my stop watch time. With this change, director shows the login anywhere from 12-16 seconds but my stop watch is still closer to 40. I think this is due to using mandatory profiles with RES layered on top. I have WEM installed for optimizations but none of the user settings. I almost want to test that out to see if it’s faster with WEM vs RES for the user personalization stuff.

    Reply
    • George Spiers

      February 1, 2018

      If Director is accurate enough then I’d go for that. Not sure how it is reporting 12-16 seconds though if you probably don’t even see the desktop wallpaper by then.

      Reply
  • Anonymous

    February 6, 2018

    I’m seeing interactive times as high as 1100 seconds for some users.

    Reply

Leave a Reply