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.


60 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
        • Ronnie Pedersen

          November 16, 2017

          Hi George (and others), and thank your for the helpfull article.

          I now have a working setup for our persistent W2016 Xenapp 7.15 VDA’s, but even though the most common applications are loaded and later taskkilled, it doesn’t seem like there is a noticable improvement in load speed, for new users.

          In other words, even though I log into a “prepared” desktop, there is still a very noticable speed difference between the first and second run of any given app.

          Am I expecting to much, or should I be able to get “first run” application load times on a desktop where the autologon has run (with app startup) comparable to regular “second run” times, on a Desktop where there has been no prep?

          No, I haven’t collected any hard metrics, and am only working on feel. So there may in fact be a measurable improvement – even though the WOW factor isn’t present 🙂

          Reply
          • Ronnie Pedersen

            November 16, 2017

            Non-persistent VDA of course…

          • George Spiers

            November 16, 2017

            Hey, do you mean published Citrix apps or applications within a shared desktop i.e. Chrome, Office etc.?
            For published apps, have a look at session prelaunch http://www.jgspiers.com/citrix-application-session-prelaunch/

          • Ronnie Pedersen

            November 17, 2017

            I’m talking apps within a shared desktop, Chome, IE, Office and so in, installed directly on the golde image.

          • George Spiers

            November 17, 2017

            I wouldn’t spend too much time on those as personally I’ve not had any noticeable gains. I prefer to spend more time reducing logon speeds.

      • 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
    • Mikael

      September 7, 2017

      Mind providing the way you have removed Win10 bloatware and managed to keep the start menu intact with search functions etc working?

      Reply
      • Kevin Kutzera

        September 8, 2017

        A scripts I found on the Internet. I will submit more details early next week. I didn’t save search functionality, but I know the script can be modified to leave that alone. Start menu works but is mostly blank. We provide the user’s with the approved applications as desktop shortcuts.

        Reply
      • Kevin Kutzera

        September 11, 2017

        Hello,
        So I found the specific script I used. Carl Luberti shared his work with a Powershell script named ConfigAsVDI.ps1. It’s rather extensive and per his recommendations you should review what it does carefully. You also need to make sure you’re using the correct Enterprise build of Windows 10. Several other people have shared their scripts that all do similar things removing software that cannot be conventionally uninstalled.
        Personally I think WEM (vs. AD Group Policies) was the most significant performance improvement. It would be valuable to test a single Windows 10 setup in the two different environments.
        Regards
        Kevin

        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
  • Pingback: Image Optimization Analysis – Citrix XenApp | James Kindon

  • Jan Goormans

    October 3, 2017

    Top article. We use Ivanti Environment Manager. Would it be better to implement the UPMEvent.exe scheduled task at logon through Appsense?

    Reply
    • George Spiers

      October 3, 2017

      Thanks. I would pick the method which runs quickest after the shell has loaded.

      Reply
  • Glenn Jacobsen

    October 11, 2017

    Hey George

    We are an Application Service Provider providing a Citrix solution for our customers. We have a broad range of applications installed, not only a barebones installation.

    Our logon time is 37 seconds, where the Interactive Session is on average 32 seconds, mainly due to the first logon, but around 20-23 seconds for every consecutive user.

    Do you think we could reduce this to 10 seconds based on your optimizations?

    Reply
    • George Spiers

      October 11, 2017

      Hi Glenn. Can’t say fully that it will reduce as much as 10 seconds because all environments are different and GPOs, Profile loading and so on have impacts on the Interactive Session Time. I would bet there is some reduction. There is only one way to find out. Perform the optimisations in your testing environment and report back with results?

      Reply
  • mike

    October 12, 2017

    Hello George,
    The scheduled task configured with group policy preferences should be visible in task scheduler, right? For some reason the change does not seem to work for me and when troubleshooting I’m not able to see the task? Using Window Server 2012 R2

    Reply
    • George Spiers

      October 12, 2017

      That’s correct. Sounds like the policy isn’t applying. Run a GP Result or RSOP when logged in to confirm if it is.

      Reply
  • Matheen

    November 9, 2017

    Hi, Excellent post,
    Do you have any article or reference on how to improve graphics performance with in the session? I have 7.15 LTSR with 2008 R2 VDA performing poorly over VPN connection. Users using standard application feel the interface is bit clunky
    Tried setting up default policy (citrix policy) but it is not helping.

    Reply
    • George Spiers

      November 9, 2017

      Did you have a look at policy templates to get started such as the Optimized for WAN template? They are good starting points. For 2008 R2 you have to use Legacy Graphics Mode.

      Reply
  • Mike

    November 13, 2017

    Hi there,
    I am trying to improve the logon performance for a non-persistent WIn7 64bit Enterprise built using Citrix App Layering. Since this Image is for call center users I have decided not to use User Profile Management. I have opted for a reboot after logoff option. Each time when a user logs freshly it is taking about 60 secs to being able to start using it.

    I have disabled the Active Setup using the Citrix App Layering Optimiser which is part of the tools but hasn’t made much of a difference. The Image has been optimized for VDI using a script for Win7 from VMware View but I am using it in XenDesktop. I have not tried the AutoLogon option within the Optimizer. (Has any one tried it?)

    Anyone got any ideas as to how I could improve the logon times.

    Reply
    • George Spiers

      November 13, 2017

      Have you Citrix Director configured? If so, look at the logon statistics to see what exactly is taking the time. It could be Group Policy, Logon Tasks, profile loading etc. Have you moved UPMEvent to a Scheduled Task? Have you looked at WEM? http://www.jgspiers.com/citrix-workspace-environment-manager/

      Reply
  • Mike

    November 13, 2017

    Thank you for the reminder on getting Director configured. Mine is a test lab and I didn’t install Director as yet it was in the back of my mind .. So I got it working and I am getting 49 sec logon duration timing. GPOs are taking 5 sec, Profile load is 2 sec and Interactive session is showing as between 29 to sometimes up to 35 sec. I have got the WEM setup but not configured any policies as yet.

    The actual timings starting by clicking on the Storefront Launch using a split stopwatch timings is as follow:

    Windows – 8.5 secs
    Preparing your Desktop – 17 sec
    Start Menu – 25 sec

    Active Setup has been disabled by deleting the stubs in registry,

    Not sure why the interactive delay is so long when in actual fact there is no UPM/Network Mandatory profile in use. The use case is for call center users and they only need to run a few local apps (layered) and the others are WEB url shortcuts. No user personalization.

    I know the first time a user profile is created it takes longer than subsequent logons. My aim is to ensure have the least amount of network dependency in order launch the session and to simplify DR.

    Reply
    • George Spiers

      November 13, 2017

      What is “Start Menu”? Is that a policy? It’s too long. Also normally I find that Interactive Session time can be reduced by tuning the OS. I know you already have performed optimisations, but I like to use various sources and not just a single script for VMware View. Also, if you are using PVS then use cache method “Cache on RAM with overflow to HDD”. If you are using MCS make use of I/O Optmisations.

      Reply
  • Mike

    November 13, 2017

    I think there seems to be a problem with my layer which has the optimizations.

    I checked the registry settings by disabling the locked down GPOs and found that the Active Setup stubs for things like Windows Mail are still being created. I know the reason “Preparing your desktop” is taking a lot of time is because of the Active Setup.

    I have created a separate layer in which I have run the Win7 Optimization script and deleted the Active setup stubs using the Unidesk Optimizer but I ran these optimizations on a non-domain joined packaging VM.

    Since I am using Citrix XenDesktop MCS should I be running all the optimization on my Platform Layer?

    Reply
    • George Spiers

      November 13, 2017

      I usually recommend performing all possible optimisations in the Platform Layer. This means nothing will overwrite it, since that Layer gets the highest priority.

      Reply
  • Mike

    November 13, 2017

    Thank you for your quick reply. I will create a new version of the MCS Platform layer which in the case of XenDesktop is a domain joined layer. I am a bit confused as to how I should apply the optimizations because there is no Sysprep being run.

    Should I start with the Optimizer tool found in the Windows\Setup folder? Can you please recommend what is the best way to do it correctly considering I am using App Layering to build the pooled desktop image.

    Reply
    • George Spiers

      November 13, 2017

      Yes the Platform Layer is the domain joined layer. You pick tools of your choice. Citrix Optimizer, VMware Optimization Tool and so on. Look at what each optimisation is going to to and achieve, determine if you need an optimisation and if so include it in the Platform Layer. Once you have finalised the Platform Layer you push the complete image out to MCS for distribution. There is no need for sysprep because here you have multiple XenDesktop VMs all working of a single fully configured Gold Image. Sysprep used to be required for the old Unidesk solutions.

      Reply
  • Mike

    November 13, 2017

    I have just spun up a new Platform Layer, and the Citrix VDA is already installed in it from the previous layer. I think I will first start with using the built in Optimiser (ver 5.3) and see how it performs. I wish to also select the Autologon option so should I run Optimizer batch file on the packaging VM without joining it to the domain?

    Reply
    • George Spiers

      November 14, 2017

      Don’t use “Optimize.hta” from C:\Windows\Setup\Scripts. Instead use the Citrix Optimizer – https://support.citrix.com/article/CTX224676 – Also your Platform Layer has to be joined to the domain, and if you wish to use autologon then follow the steps from this blog post.

      Reply
      • Mike

        November 14, 2017

        I was actually wondering if in v4.x the “Optimize.hta” and its output batch file customizations.cmd is even being used at build time? I know in v2.9 the unattend.xml used to run the different batch files at boot time. I created a new Platform layer yesterday using the Optimizer.hta and only added the Autologon settings but haven’t got round to testing the image. I will report back later today.

        The point Victor made about having some issues with using the Autologon method in this blog post for VDI use. What I was thinking is if I was to follow the below steps for creating the Platform Layer would it not achieve the same goal. The image should get primed with the user account and it should speed up the new user logons for a non-persistent desktop which flushes the state at log off. What are your thoughts on this?

        1. Install the VDA
        2. Join the Domain
        3. Log on as a  network user (this can be the autologon account) and “don’t” delete the user profile.
        4. Reboot
        5. Finalize

        Reply
        • George Spiers

          November 14, 2017

          No App Layering does not use Customizations.cmd during the finalisation of layers or when publishing a layer. You have to run it manually, but I recommend exploring other tools such as the Citrix Optimiser to perform your optimisations on the Platform Layer. Your process would work but I still found that when the image was published out, the first logon always took longest, so I used autologon to get around that. Note that autologon for me was configured manually via RegEdits and not by using Optimize.hta.

          Reply
  • Victor O

    November 14, 2017

    Thank you very much for this post! I’ve implemented much of it with great success, but I’ve encountered an odd issue that I would appreciate your input on.

    One of my implementations is the AutoLogon. I implemented this on a non-persistent environment, and the default reboot-after-use behaviour. Everything is fine for most VMs most of the time. Unfortunately, some VMs reboot after the AutoLogon account logs off, and keep cycling through re-initializing and autologon for minutes or hours. Eventually, they’ll stop that behaviour and sit at the logon screen as an available VM. I checked flags of a problematic VM, and the AutoLogon account is resulting in WillShutDownAfterUse being True.

    Should the AutoLogon tweak on non-persistent reboot-after-use VMs work (like 90% of the time in my environment)? If so, any ideas why it seems to be misbehaving ~10% of the time?

    Thank you.

    Reply
    • George Spiers

      November 14, 2017

      I wouldn’t normally have advised to use autologon for VDI machines and I wouldn’t have expected it to work at all due to the behaviour of a machine rebooting after logoff. At the same time though I’m wondering if the 10% are rebooting because they had registered with a Delivery Controller which sent the restart power action to the VDA once the autologon account had logged off. Is it possible you can configure the “Citrix Desktop Service” service to “Automatic (Delayed Start)” on the VDAs and see if autologon works for all desktops after? My thinking is that we want to get autologon to do its piece before the VDA registers with a Delivery Controller. I might be wrong and it might restart regardless of registration state. In that case it’s best not using it for VDI.

      Reply
      • Victor O

        November 15, 2017

        I had thought it odd when it worked during my testing, but just went with it because it improved logon times. I’ll give your suggestion a shot and let you know how it goes. Thank you.

        Reply
  • Mike

    November 16, 2017

    Yes, I am of the same opinion as you George. I started to look at it for VDI because I had used it in Unidesk 2.x but now since v4.x i believe it has been deprecated.

    While on the topic of log on performance improvements, I wanted to get your thoughts on the correct steps for creating a Citrix MCS platform layer and adding the Citrix Optimizer settings followed by joining it to the domain followed by a log on using a domain account and a reboot. This process should create all the first logon files on the OS. Then delete the network account profile and finalize. But I am not too sure whether the packaging VM must be disjointed from the domain before finalizing the Platform layer using local admin. The reason why I ask is that is how I had created my platform layer previously because it requires to be joined to the domain. Could do with your thoughts.

    Reply
    • George Spiers

      November 16, 2017

      Hi Mike. To create Platform Layer follow these steps:

      1. Install VDA
      2. Join Platform Layer to domain
      3. Run Citrix optimisations
      4. Log on to Platform Layer as a domain joined account, log off, remove profile from Platform Layer
      5. Perform final reboot of Packaging Machine
      5. Finalise Platform Layer

      Platform Layer remains joined to the domain.

      Reply
  • MIke

    November 17, 2017

    Thanks George. I will give it a try and report back.

    Reply
  • Nate W

    November 17, 2017

    I’ve tried to follow the UPMevent part of this for my Windows 10 VDI desktops. I removed it from the registry, have a GPO that runs UPMEvent.exe, have checked on the task scheduler to see if it is there and runs but no information gets recorded on Director about the login time and it doesn’t seem to improve the login. Right now with a bare bones test user I am at 33-40 seconds. I’m not sure what I am doing wrong…

    Reply
    • George Spiers

      November 18, 2017

      The reason you aren’t getting login time stats in Director is because UPMEvent is not running, even though your scheduled task is running. Double check the scheduled task configuration and when UPMEvent does run, you will get a “Desktop Ready” event log (ID 1000).

      Reply

Leave a Reply