Reduce Citrix logon times by up to 75%

This post covers several recommendations that increased by logon times by more than 75%, even on non-persistent machines where the user profile is not permanently cached.

♣ What is Interactive Session Time?
♣ My testing environment
♣ Non-optimised image vs optimised image – logon time results
♣ Serialize/StartupDelayInMSec – logon time results
♣ Autologon account/the second logon is quicker – logon time results
♣ UPMEvent – logon time results – Saving the best to last

Citrix Director is great at recording logon times per session and logon averages over periods of time. We can even produce logon reports and show them off to managers or other teams within the organisation to show them how good (or bad) the virtual workspace performs! Though without any effort you’ll likely be wowing everyone for the wrong reasons until you put in the background work to get logon times down to a low number. Citrix unfortunately doesn’t magically make logons quicker than any other desktop.

Many of the logon friendly optimisations and best practices out there today are straight forward and common sense and help to get you started:

  • Keep GPOs at a minimum (don’t be GPO happy).
  • Don’t map tonnes of drives, especially to users who do not need them.
  • Don’t map tonnes of printers. Joe who prints to two printers doesn’t need 13 printers mapped to his machine.
  • Avoid using logon scripts, these are only going to add time to the logon.
  • Move Group Policy settings to Citrix WEM.

There are more, and I’ll cover off some additional ones in this post to really reduce logon times. If you’re interested in some more tips, see http://www.jgspiers.com/citrix-tips-tricks-tweaks-suggestions/

Also, if you’re interested in finding out more about the logon process see http://www.jgspiers.com/digging-in-to-citrix-logon-process/

So you’ve performed all of the above and more, you’re timings tells you that logon times are no longer than 20 seconds. You look at Director and the logon times are double. Why? There is still one recorded metric that:

  1. Not everyone knows what exactly it is and or struggles to understand it.
  2. Takes a bit of work getting the metric value to reduce, although once you know what it does it’s easier to shave the seconds off.

That metric is: Interactive Session Time.

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 the 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 so let me show you how you can almost eliminate Interactive Session times, get overall logon times reduced and get Director logging much more accurate data.

My testing environment

For the following logon tests, I used XenDesktop 7.13, running PVS 7.13 and a 7.13 VDA configured with 2GB RAM and 2vCPU. The VDA runs Windows Server 2016 with no optimisations to start however as you will see later it does become optimised and improves logon times. The Target Device Write-Cache is configured as RAM w/overflow to HDD (which is on SSD storage).

Note: The following configurations can be applied to both Server and Desktop OS in persistent and non-persistent environments. You don’t have to implement all of them, consider each one individually. Logon times will also fluctuate based on factors such as load (busy periods), VDA performance and underlying hardware used.

Non-optimised image vs optimised image – logon time results

I built a brand new Windows Server 2016 VDA streaming from PVS. Nothing else was performed on the image. Logged on three times. The average logon time is 68 seconds. That time has advantages such as being able to go and make coffee or produce a logon time report from Director to show your boss, which probably won’t go down all that well. Add applications, larger profiles, Group Policies in to the mix and more seconds get added.

So I’ve gone and optimised my image using the Server 2016 optimisation script. You know optimising an image brings a great sense of satisfaction, not to mention the average time is now down to 38 seconds! That is 20 seconds shaven off just by optimising the image.  Notice also that the Interactive Session time has been greatly reduced, that is because the image is a lot more leaner and can get a session ready more quickly.

Serialize/StartupDelayInMSec – logon time results

It was blogged about here https://xenappblog.com/2016/optimize-logon-times/. Windows Server 2012 and Windows 8 introduced a startup delay for applications which has a negative effect on Interactive Session times. By disabling this delay we can start the applications immediately, not an issue if you have only a few. On the write-mode PVS/MCS gold image or Citrix App Layering OS Layer, launch RegEdit -> HKEY_USERS -> File -> Load Hive.

Load the default user hive by navigating to C:\Users\Default and double-clicking NTUSER.DAT.

Give the hive a name and click OK.

Within the hive navigate to SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer and create a new key called Serialize.

Create a new DWORD 32-bit value within the Serialize key.

Give the value a name of StartupDelayInMSec and a data value of 0x0.

Click File -> Unload Hive.

Click Yes. Finalise the image.

Note: You could have done this through Group Policy, but since it applies to all users we want to reduce the need for Group Policy processing and extra logon processing.

The results of this optimisation show logon time averages down to 27 seconds. An 11 second drop. Remember that each logon here is on a non-persistent machine. The machine is restarted between each logon so as to mimic a first-time session logon (post restart) to VDA where no profile is cached. These current logon times look a lot better and are good for a first-time logon after VDA restart.

Autologon account/the second logon is quicker – logon time results

When a VDA restarts as part of scheduled reboots for example or when non-persistent desktops reboot to reset, the first logon is generally always the longest. So I thought of the idea to use an auto-logon account to be the guinea pig and be the one who first logs on when a VDA restarts. This works well particularly in server OS since the autologon account when it logs off doesn’t trigger any sort of restart to the VDA.

You can use Autologon as pointed out by Chris in the comments. This tool easily configures an autologon account and encrypts the password. https://technet.microsoft.com/en-us/sysinternals/autologon.aspx

When launching autologon, enter the credentials to your autologon account and click Enable.

Click OK. The Winlogon Registry Key will be configured with DefaultUsername/DefaultDomainName string values and so on however the DefaultPassword will not be present and is encrypted.

Restart the VDA. If autologon does not work the first time run through the Autologon tool again and it should work on second attempt.

You can now configure the logoff procedure as described below.

For an alternative method of autologon (this section includes the autologoff procedure):

Open the gold PVS/MCS image again or the OS Layer (Citrix App Layering). On the C:\ drive, create a batch file and call it something like AutoLogon.bat.Within the batch file, enter the following:

Now open RegEdit and navigate to HKLM\SOFTWARE\Microsoft\Windows NT\CurrrentVersion\Winlogon.

Set the AutoAdminLogon value to 1.

Set DefaultDomainName to your domain name as below.

Set DefaultUserName to a user account (service account) which has rights to log on to each VDA. This user account should be secured with a strong password and be a Domain User only. If this DefaultUserName REG_SZ string does not exist, create it.

Set DefaultPassword to the password of the autologon account. Click OK.

Right-click the Winlogon key and select Permissions.

Click Add. Search and add the autologon account.

Give Full Control permissions. This allows the autologon account to delete the DefaultPassword string after each logon. Finalise the image.

Now using Group Policy, create a GPO which is filtered to the autologon account as below. Edit the Group Policy obejct.

Expand User Configuration -> Preferences -> Control Panel Settings -> Scheduled Tasks -> New -> Scheduled Task (At least Windows 7).

Under General specify a name. Specify Run only when user is logged on and run the task under the autologon account. For Configure for choose Windows 7 or the highest possible OS.

On the Triggers tab click New.

For Begin the task choose At log on. Check Specific user or group and select the autologon account. Click OK.

On the Actions tab click New.

For Action choose Start a program. Under Program/script enter the path of your batch file which resides on the gold image. Click OK.

Your scheduled task is now created.

Now when the VDA boots up, an autologon occurs. The Scheduled Task runs a batch file which deletes the DefaultPassword string immediately for security and then logs off. The machine is then ready for real user logons.

As a result, the average logon time has dropped to 20 seconds. A 7 second drop. Interactive Session times are a lot lower than when we started these optimisations, over a 40 reduction!

UPMEvent – logon time results – Saving the best to last

If you had implemented what I am about to show you first, you probably could have cut Interactive Session time by more than 60% immediately.

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

So ideally we want the UPMEvent.exe to run once we see that desktop wallpaper screen as that is when the logon is complete. By default, it instead runs some time after the profile has loaded.

The StartupDelayInMSec key added earlier simply speeds up when run keys (startup applications) are started. Hence why the Interactive Session time is decreased becaue UPMEvent.exe is started quicker since we removed the startup delay.

So what is faster than startup applications specified within run? A log on Scheduled Task.

Open your gold image or Citrix App Layering Platform Layer (the Platform Layer should contain your VDA). 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. Now UPMEvent.exe will be run by the Scheduled Task immediately when the desktop shell has loaded.

With UPMEvent.exe being ran now by the Scheduled Task the average logon time has dropped to 13 seconds. A further 7 second drop. Notice the Interactive Session times are all at 3 seconds, more than 50 seconds lower than when we first started. Director is logging true logon times and our future reports will be much more accurate.

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


23 Comments

  • Jeremy Saunders

    May 6, 2017

    Outstanding article George. And there are so many other things too. I do all this accept for the Autologon task. I’ll give that a try.

    I find that a Scheduled Task that runs at startup to start each app (process), such as winword.exe, etc, loads the executable and libraries into memory/cache, and then terminate each process, speeds up launching of the published apps (and logon times) after a reboot.

    Cheers,
    Jeremy

    Reply
    • George Spiers

      May 6, 2017

      Thanks Jeremy. Yes, definitely solid advice to start main applications up as you say. All part of a good machine preparation process.

      Reply
    • Jeremy McAtee

      July 7, 2017

      hey Jeremy, do you have specific settings in your scheduled task you could share?

      Reply
      • George Spiers

        July 7, 2017

        If you want my two-cents, I’m running a script similar to the below:

        start notepad.exe
        timeout /t 1
        start iexplore.exe
        timeout /t 1
        start C:\”Program Files (x86)”\”Microsoft Office”\Office16\WINWORD.exe
        timeout /t 1
        start C:\”Program Files (x86)”\”Microsoft Office”\Office16\EXCEL.exe
        timeout /t 1
        start C:\”Program Files (x86)”\”Microsoft Office”\Office16\POWERPNT.exe
        timeout /t 1
        start C:\”Program Files (x86)”\Adobe\”Acrobat Reader DC”\Reader\AcroRd32.exe
        timeout /t 3
        taskkill /IM notepad.exe
        timeout /t 1
        taskkill /IM iexplore.exe
        timeout /t 1
        taskkill /IM WINWORD.exe
        timeout /t 1
        taskkill /IM EXCEL.exe
        timeout /t 1
        taskkill /IM POWERPNT.exe
        timeout /t 1
        taskkill /IM AcroRd32.exe

        I’ve reached out to Jeremy and alerted him to your comment so you should hopefully hear something soon.

        Reply
      • Jeremy Saunders

        July 7, 2017

        Hey Jeremy,
        I’ve written a PowerShell script that runs as a standard Computer Startup Scheduled Task as the System account. The script references an XML file that holds a list of all the processes, wait times, sub processes to also terminate, etc. If you e-mail me at jeremy@jhouseconsulting.com I will be happy to supply it.
        Cheers, Jeremy

        Reply
  • Chris

    May 8, 2017

    Hi George,
    Great article, i’ll definitely be looking to implement some of these soon.
    Regarding autologon, Sysinternals have a tool that encrypts the password so deleting it wouldn’t be necessary
    https://technet.microsoft.com/en-us/sysinternals/autologon.aspx

    In my experience, the first time it is run doesn’t always work but a second run through directly after the first does.

    Chris

    Reply
  • LUIS

    May 8, 2017

    Thank you George
    — Jorge

    Reply
  • Mark

    June 17, 2017

    Thank you George for sharing this article – I have been scratching my head with finding a easy to implement solution for my XA7.6 VDAs which get rebooted using a script and the first user who logs on always takes a long time and also the CPM also seems to be failing. This is only casuing an issue for the first user only.

    I tested the steps in my lab but I used the Autorun utility instead of the batch file method and i am somewhat confused as to whether I should just have Call logoff in the batch file? I tried this and even used Shutdown.exe /l but when I restart the VDA the user autologons but for some reason the logoff is not happening. I followed exactly the same steps as in your article.

    Thanks
    -Mark

    Reply
    • George Spiers

      June 17, 2017

      Hi Mark
      You don’t need the batch file at all. In your scheduled task, under Program/Script type logoff

      Reply
      • Mark

        June 19, 2017

        Hi George,
        Thank you for your prompt reply. I tried it but for some reason it doesn’t seem to log off. Just curious I take it I do not need to configure the Winlogon Key and Permissions etc when using the Autlogon tool?

        I deleted the GPP policy and recreated it but for some reason it is not applying. My Lab DC is WS2008R2 and the Test VDA is 2012R2 could this be the reason it is not working?

        Reply
  • George Spiers

    June 19, 2017

    No you won’t need to configure permissions and it will just be a standard domain user account you use. Should also not make any difference the OS versions you use. When the autologon account logs on, look at the scheduled task run result code.

    Reply
  • Mark

    June 20, 2017

    I tested it by creating a task schedule in the VDA and it works perfectly, but using the GPO the settings do not seem to be taking affect – but the concept is working so I will do some troubleshooting of my Lab AD and try and get it to work.

    Just wanted to touch on Jeremy’s point about starting up applications as part of the logon process. Do I simply add all the office apps such as Winword, Excel, Powerpoint etc as triggers and place the logoff at the end. But will that work because the apps will be forcefully closed at log off. Would that be okay?

    Reply
    • George Spiers

      June 20, 2017

      A do a bit of testing should be performed yourself to visually see how applications behave after their processes are terminated. Don’t use the logoff task to kill the processes but rather use taskkill and then logoff afterwards. I’ve not encountered any issues with doing this.

      Reply
      • Mark

        June 22, 2017

        Thank you for the Taskkill tip. I will do some testing with it as I am quite new to XenApp7.
        I haven’t been able to get the logoff to work using the GPP settings. Not sure why it is not working. Could it be, when using the Autologon utility it requires a different GPO configuration? I can run the scheduler in the VDA but that is not going to be ideal to bake it in the image.

        Reply
        • George Spiers

          June 22, 2017

          No the GPO either using batch file to logoff or explicitly specifying a logoff switch in the Scheduled Task is all that is requried. You need to determine why it is not applying.

          Reply
  • Kevin Kutzera

    July 6, 2017

    This is remarkable work. I’ve moved forward with a new XD 7.14 deployment using a Windows 10 Enterprise that has been highly optimized (lots of services off, lots of bloatware removed). Very satisfying to see 9 second logon in Director! Interactive Session went from 48 seconds to 3!~
    The only challenge is that the actual time from “click on the icon” to useable desktop is about 40 seconds. Now this is within acceptable range for our goals here, but I’m curious if there’s any other steps I could take to align Director with actual login? I’ve implemented everything listed in this document except the Autologon process . WEM is wonderful by the way! So the logon process spends about 30 of the 40 seconds at the Window Welcome wheel, then about 10 seconds at the splash screen for WEM. Again this is great, but just wondered about the Directory Reporting which I understand is based on certain events occurring. This is a completely new system , not yet in production, so I have the luxury of full control including server reboots, and recreating catalogs (we’re using MCS). There’s currently only 3 vms in the catalog I’m testing. Hosted on XenServer, shared iSCSI storage is SSD based, on a 10GB connection. UPM Profiles with test uers’s profile nearly non-existant. No AV installed yet.

    I might setup a process monitor to capture the logon process, see what’s going on.
    Thanks
    Kevin

    Reply
    • George Spiers

      July 6, 2017

      30-40 seconds is too long to be sat at Welcome to Windows. Try disabling the Citrix Telemetry Service and see if that has any improvements, remove as much UWP apps as possible, remove as much Active Setup registry keys as possible. Even see if the same symptoms exist on a standard Windows 10 machine with nothing else performed, then gradually apply optimisations and changes whilst continuing to track logon times. Also as you say Procmon would be a good tool to see what is going on.

      Reply
      • Kevin

        July 7, 2017

        Thanks George!

        Reply
  • Ryan

    July 6, 2017

    When trying to run the scheduled task to run upmevent, the scheduled task fails for my users with an “access denied” error, but it runs fine for my admin account which of course is an admin on the image. Any ideas?

    Reply
    • George Spiers

      July 6, 2017

      Did you check “run with highest privileges” when creating the task? If so, uncheck that. If you haven’t checked it, what’s the scheduled task run result code and what OS? As a logged in user who fails, try manually browsing and running upmevent.exe.

      Reply
      • Ryan

        July 7, 2017

        I believe this actually turned out to be AV related. Once I added upmevent.exe as an exception it appears to be working now.

        Reply

Leave a Reply