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).
- Keep close control of Group Policy incuding monitoring – https://jgspiers.com/audit-group-policy-changes/
- 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 https://jgspiers.com/citrix-tips-tricks-tweaks-suggestions/
Also, if you’re interested in finding out more about the logon process see https://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:
- Not everyone knows what exactly it is and or struggles to understand it.
- 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?
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:
call reg delete "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon" /v "DefaultPassword" /f call logoff
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
Note: This really only applies now to VDA 7.15 and below. Citrix made a change in 7.16 that allows upmEvent.exe to run quickly out of the box. To read more visit https://jgspiers.com/reduce-citrix-director-interactive-session-time/
For VDA 7.15 and below:
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 because UPMEvent.exe is started quicker since we removed the startup delay.
So what is faster than startup applications specified within run? Removing the upmEvent.exe run key and moving it to the Userinit string as described in https://jgspiers.com/reduce-citrix-director-interactive-session-time/
What else 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.
Jeremy Saunders
May 6, 2017Outstanding 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
George Spiers
May 6, 2017Thanks Jeremy. Yes, definitely solid advice to start main applications up as you say. All part of a good machine preparation process.
Anonymous
June 26, 2023Finally after 6 years I got around to publishing my process 🙂
https://www.jhouseconsulting.com/2023/06/27/cold-starting-andor-hydrating-your-applications-to-improve-their-startup-times-2352
Graham Mason
September 6, 2023Loving this process – Thanks Jhouse !!
Jeremy McAtee
July 7, 2017hey Jeremy, do you have specific settings in your scheduled task you could share?
George Spiers
July 7, 2017If 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.
Ronnie Pedersen
November 16, 2017Hi 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 🙂
Ronnie Pedersen
November 16, 2017Non-persistent VDA of course…
George Spiers
November 16, 2017Hey, 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 https://jgspiers.com/citrix-application-session-prelaunch/
Ronnie Pedersen
November 17, 2017I’m talking apps within a shared desktop, Chome, IE, Office and so in, installed directly on the golde image.
George Spiers
November 17, 2017I 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.
Graham
October 4, 2022does this same logic apply today – ie Edge/Office365 ?
Jeremy Saunders
July 7, 2017Hey 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
Alex G.
December 21, 2017Thanks – this is great. You don’t have any script available for 2012 R2 though?
Also, since the Serialize/StartupDelayinMSec value is stored in HKLM/Software, do we really need to change the default profile?
Chris
May 8, 2017Hi 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
George Spiers
May 8, 2017Thanks Chris, will check it out!
Jeremy Saunders
May 9, 2017Great point Chris! I’m modifying the script here instead of using the Sysinternals tool: http://andyarismendi.blogspot.com.au/2011/10/powershell-set-secureautologon.html
Cheers,
Jeremy
LUIS
May 8, 2017Thank you George
— Jorge
Mark
June 17, 2017Thank 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
George Spiers
June 17, 2017Hi Mark
You don’t need the batch file at all. In your scheduled task, under Program/Script type logoff
Mark
June 19, 2017Hi 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?
George Spiers
June 19, 2017No 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.
Mark
June 20, 2017I 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?
George Spiers
June 20, 2017A 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.
Mark
June 22, 2017Thank 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.
George Spiers
June 22, 2017No 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.
Kevin Kutzera
July 6, 2017This 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
George Spiers
July 6, 201730-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.
Kevin
July 7, 2017Thanks George!
Mikael
September 7, 2017Mind providing the way you have removed Win10 bloatware and managed to keep the start menu intact with search functions etc working?
Kevin Kutzera
September 8, 2017A 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.
Kevin Kutzera
September 11, 2017Hello,
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
Ryan
July 6, 2017When 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?
George Spiers
July 6, 2017Did 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.
Ryan
July 7, 2017I believe this actually turned out to be AV related. Once I added upmevent.exe as an exception it appears to be working now.
Pingback: Image Optimization Analysis – Citrix XenApp | James Kindon
Jan Goormans
October 3, 2017Top article. We use Ivanti Environment Manager. Would it be better to implement the UPMEvent.exe scheduled task at logon through Appsense?
George Spiers
October 3, 2017Thanks. I would pick the method which runs quickest after the shell has loaded.
Glenn Jacobsen
October 11, 2017Hey 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?
George Spiers
October 11, 2017Hi 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?
mike
October 12, 2017Hello 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
George Spiers
October 12, 2017That’s correct. Sounds like the policy isn’t applying. Run a GP Result or RSOP when logged in to confirm if it is.
Matheen
November 9, 2017Hi, 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.
George Spiers
November 9, 2017Did 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.
Mike
November 13, 2017Hi 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.
George Spiers
November 13, 2017Have 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? https://jgspiers.com/citrix-workspace-environment-manager/
Mike
November 13, 2017Thank 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.
George Spiers
November 13, 2017What 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.
Mike
November 13, 2017I 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?
George Spiers
November 13, 2017I usually recommend performing all possible optimisations in the Platform Layer. This means nothing will overwrite it, since that Layer gets the highest priority.
Mike
November 13, 2017Thank 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.
George Spiers
November 13, 2017Yes 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.
Mike
November 13, 2017I 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?
George Spiers
November 14, 2017Don’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.
Mike
November 14, 2017I 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
George Spiers
November 14, 2017No 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.
Victor O
November 14, 2017Thank 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.
George Spiers
November 14, 2017I 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.
Victor O
November 15, 2017I 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.
Victor O
November 23, 2017I tried your suggestion, but even setting to Automatic/Delayed seemed to be running before the AutoLogon got in there – perhaps something else was inducing a start.
So, I set the service to Disabled on the Master image, and I Enable/Start the service during the logout call on the AutoLogon user. The issue has not re-appeared on the updated images. It seems like a viable method to use AutoLogon to optimize a random image.
George Spiers
November 23, 2017Sounds like a viable method indeed. Nice one!
Mike
November 16, 2017Yes, 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.
George Spiers
November 16, 2017Hi 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.
MIke
November 17, 2017Thanks George. I will give it a try and report back.
Nate W
November 17, 2017I’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…
George Spiers
November 18, 2017The 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).
Mike
November 18, 2017Hi George,
I followed the steps and it works great perfectly. Thank you so much for putting on the right track!
I tested the Citrix optimiser and VMware optimization tools but what I don’t quite like about the canned optimizations scripts almost always I have users complain about how plain and bland their Windows 7 VDI desktops look. The problem is with the settings for Visual Effects :
For Best Performance.
reg ADD “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects” /v VisualFXSetting /t REG_DWORD /d 0x2 /f
For Custom which means no visual enhancements.
reg ADD “HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects” /v VisualFXSetting /t REG_DWORD /d 0x3 /f
I would like to set the default profile for all uses to be either set to Best Performance or custom but with have the “Use visual styles on windows and buttons” option enabled.
I have tried everything but failed to configure this setting for all users when using the optimization script. I will be grateful if you can shed any light on how to script the reg settings into either a batch or powershell script.
Thanks!
George Spiers
November 19, 2017Hi Mike
There is no point running a script and/or optisization tools that add registry entries to HKCU. Reason being is that the HKCU hive used to add these optimisations will be on the account you are running the optimisations from. So it will be only affect that account and no other account.
When you want to apply optimisations to all users I prefer to use Citrix Workspace Environment Management or else on a layer such as when using App Layering, load NTUSER.DAT from C:\Users\Default and create the optmisations in there. That means all users will receive them when they log on.
Using a template machine, set the visual effects to custom and then uncheck/check the effects you want/don’t want. Then grab the value of “UserPreferencesMask” under “HKCU\Control Panel\Desktop”.
You then want to make sure this UserPreferencesMask binary value is created for all users via WEM/GPO or else by using the NTUSER.dat method. You also want to make sure VisualEffects is set to 0x3 using the same methods.
Mike
November 20, 2017At the moment I am trying to get my first Citrix App Layering v4.4 Win7 Image for a call centre use case working with just local user profiles and I have gotten stuck with this one issue.
Thank you for your tip on how to pipe the HKCU settings into NTUSER.DAT. I am doing the same thing but what I am seeing is when I load the default profile hive the settings are all registered. But when I logon as a new user in the packaging VM the Visual effect is very inconsistent most times it is set for Best Performance (like the Win2k8). The UserPreferences Binary value I have in my reg script is 9012038010000000 but it changes to 9e3e078012000000 and as a result it reverts it “Let Windows choose what’s best for my computer”.
Ideally I would have liked to use the Citrix Optimiser tool but for some reason it sets it to Best Performance making the desktop very bland. If anyone knows how to reliably apply the “Use visual styles on windows and buttons” to all users either using a script or GPP I would like to hear from them.
I think I will have apply the settings using GPP and see if it is consistently applied and later I can spend more time in getting the optimization script to apply all the settings for Visual Effects correctly.
Matheen
November 20, 2017Hi,
I have windows 2008 r2 VDA on 7.15 VDA. It is taking around 30+ seconds to login. The bulk of the time (12 seconds) has taken for “Preparing for Desktop” (HSD) and preparing for application for Published Application. The interactive session in Director is showing as 18 sec.
I followed the article and it has not made any difference on the logon duration (not sure if your article is more for 2012 and above)
Is there anything you can suggest to bring logon duration down?
George Spiers
November 20, 2017There are several recommendations:
Optimisations including disabling all unneeded Services, Scheduled Tasks, removing Active Setup keys and so on.
If using PVS, make sure you are using RAM Cache with overflow to HDD. Also assign 2GB to RAM cache.
If using PVS, use 1GB NICs and above
If using MCS, make sure you are using XenApp/XenDesktop 7.9+ to make use of RAM cache
Use flash storage for HDD Overflow disks
If using App Layering, take care when using Elastic Layers as they add to logon time
Run UPMEvent.exe as a Scheduled Task rather than a Starup Program
If you can, size the VMs with vCPU and RAM appropriately
Check logon profiles are not too large. Use a user profile solution like Citrix Profile Management to stream the profile rather than cache, and keep the profile light
Use folder redirection
Refer to here for more tips: https://jgspiers.com/citrix-tips-tricks-tweaks-suggestions/
If all the above fails, maybe 2012 R2 is simply faster.
Mike
November 23, 2017Hi George, I finally managed to get the Visual Effects working in the App Layer, but I must say the only way I was able to get it to work is by creating the “UserPreferencesMask” settings in the default profile manually as what you suggested. I was trying to use a batch script method to create the default profile HKU values but it just didn’t work reliably for new users.
I have just tested the new image with the optimization layer which includes the visual effects so all good but I seem to have run into another problem. Director is measuring the logon time as below:
VM start =11 sec
GPO =0.47 (it is failing to load the settings)
Profile Load = 1 sec (using local profile)
Interactive session =4 sec
I am a bit confused as to what is taking the 11 sec for VM start. Although, it is a non-persistent pool and set to reboot at log off but there are surplus powered on VMs in the pool (3 VMs).
I haven’t gotten around to troubleshoot why the GPO settings are no longer being applied after updating the catalog with the newly created image. The VM’s are in the same OU as before. Any pointers?
George Spiers
November 23, 2017Is the time on the 3 VMs in sync with Domain Controller to receive GPOs?
Have you actually logged on to one of the VMs and checked that GPOs have not applied?
Mike
November 23, 2017Yes the time appears to be correct and when I log on to the VMs it doesn’t pull the background from the netlogon share (I am going to copy the image locally later) and the Start Menu is all unlocked and I did a quick check by running GPUPDATE /FORCE logged in as a user but that did not seem to update the GPO. I will do some troubleshooting today.
You know in v2.9 we had the option of loading the GPO into the image but now I am not sure how we can do that in v4.x is there a settings or a method you know off. I would like to bake the GPOs when the MCS creates the VMs.
George Spiers
November 23, 2017When you are creating your Platform Layer you can move the machine to an OU of your choice so it receives all the computer related GPOs.
Mike
November 23, 2017Thanks, now that I have the optimized app layer figured out I will now transfer the settings into the Platform layer and test if it improves the performance and reliability.
George Spiers
November 23, 2017Good luck 🙂
Mike
November 24, 2017I managed to troubleshoot the reason why the GPO settings were not applying. I ran the GPRESULT /R and found in the Computer settings the Domain Name was CITRXale002 and the Domain Level as NT4. Under the user settings the Domain Name was the same as the actual NetBIOS name of my Domain. The name CITRXale002 would have come from the packaging machine of a layer. Although the machine is joined to the domain and logged in as a network user but the Computer Name is wrong as far as the Active Directory registration is concerned. So I suspect there is some corruption of the layer(s) in the image.
Secondly, I came across another issue relating to the VDA registration with the DDCs. The VMs are erratically unregistering or not registering. The network trace is indicating the VDA are doing a tcp-reset. I am not sure what is causing it but I wanted to ask you if whether disabling the firewall profiles would interfere with the VDA communications with the DDCs because when I installed the VDA I had the firewall profiles ON and chose the Automatic option during the installation.
George Spiers
November 24, 2017There should be no firewall issues. The fact it registers in the first place would indicate this is not a firewall issue. It is likely caused by whatever is causing GPOs to fail also. I would recreate your Platform Layer and join it to the domain at the beginning of layer creation, and keep it joined to the domain. MCS should then create identity disks which allow the VMs to receive different unique identities.
Mike
November 26, 2017Hi George, I finally got round to create a new domain joined platform layer with the optimizations.
I published the new image with the newly created platform layer but the image update failed with the error: InternalErrorMessage : Operating System Licensing Rearm failed
Is this because I forgot to rearm the platform layer again using C:\Windows\System32\slmgr /rearm ? If so do I now need to re-create a new platform layer all over again again or simply add another version?
Thanks!
George Spiers
November 27, 2017If you follow https://jgspiers.com/create-update-os-layer-unidesk-4/ it has steps on how to configure the OS Layer appropriately to deal with KMS activation and also shows how to disable the OS Rearm step when using Machine Creation Services.
Mike
November 28, 2017Thanks George, I will read up your post on KMS. The problem turned out to be with the time being 8 hrs ahead so the activation wasn’t working. So in the end I powered on the image and manually ran the runaipkato.cmd and checked the runato.log to make sure the OS was activated before updating the MCS catalog.
For some strange reason my packaging VM always has its time 8hrs advanced. Have you come across this behaviour. I just can’t put my hand on it, since the VMTools are installed in my OS. Every other new non-domain joined VM I spin up in VMware has the correct time.
George Spiers
November 29, 2017No I haven’t witnessed that before. Once you join the domain your Packaging VM should contact any domain controller for time. Try running command “w32tm /resync” manually on the Packaging VM.
Mike
December 1, 2017The problem is with the non domain joined app layer packaging machines. I just correct the time and restart the VM.
I ran into another issue this time with the Citrix Receiver app layer, in the image along with a Java app layer etc. It was working fine suddenly I started to get an error:
Please run reset receiver to resolve lockdown conflict for Disabled Drivers (error 2320)
So when I do reset the receiver and try again to launch the XenApp session, the circle spins but doesn’t launch the app. The fqdn is in the trusted zone of IE11 but for some reason the ICA file association is broken. I must say after I installed IE11 on top of IE8 from the Windows 7 ISO I have been having this problem. Not sure if it is being caused by the Java layer and its Add-On.
Because in this POC that I am trying to get working does not require SSO I decided not to install Receiver into the Platform layer and or the first time created an App layer for Receiver Client.
Mike
December 1, 2017I will give that a try when I republish the image again.
I ran into another issue this time with not being able to launch a XenApp published app from IE11 connecting to a Storefront. It was working before but on this new image it is giving me the below error:
Please run reset receiver to resolve a lockdown conflict for disabled drivers (err0r 2320)
If I try resetting the receiver the error disappears but I can’t launch the published app, the circle spins and nothing happens.
The VM Image also contains a Java Layer. I think the problem is to do with the IE Add-ons Java plug-in 2 SSV and SSV Helper be enabled or disabled.
Any ideas?
BTW: Because I am not using SSO so I decided (right/wrongly) to create a separate layer instead of installing it in the platform layer.
George Spiers
December 2, 2017Publish an image with just the OS Layer, Receiver Layer and Platform Layer together. If Receiver works then you know that another layer is causing this conflict.
Mike
December 10, 2017Sorry I was offline for a few days and for double posting.. Not sure why but when I posted the first time it just disappeared so I thought I try again.
Thank you for the tip, the problem was in actual fact being caused by the Citrix Receiver GPO in which I had enabled “Do not map drives” A-Z drives and by changing it to C only the Launching error was resolved.
Going back to the logon performance reported by Director, I am still seeing VM start up time being added to the stats when in actual fact the VMs are already powered on (they are random and set to reboot at logoff). So not sure why I am seeing the Start time being added.
markinh
December 13, 2017For nearly instant login i was thinking of creating a simple win32 app that will authenticate, map a drive, store credentials in the vault. Starts as custom shell and in turn starts explorer.exe+shell after authentication. This works well with windows 10. Not so good with Windows TS. If only Anonymous logon was supported with windows 10 …
I tried but it seems difficult to publish a custom authentication as anonymous app on a TS and from there get a desktop.
George Spiers
December 14, 2017Interesting. Would be nice if you found out how to get it working on TS!
Mikael Laine
December 14, 2017How would you renew your tokens without login off first?
markinh
December 14, 2017No tokens. Using the Anonymous session. The time to desktop is the time the custom auth-app takes plus time to start explorer.exe/shell. E.g. 3 seconds with classic storage. Yes this breaks all services depending on AD/Kerberos. But depending on the scenario this could even be desired. Like kiosk print stations.
Jake
December 17, 2017What would you expect to happen if the “Citrix UPM UserMsg” string wasn’t deleted but you had created the scheduled task based on your instructions? I’m only asking because I updated from 7.13 to 7.15 CU1 and realized that string was probably recreated after updating. My logons jumped from an average of 11 seconds to about 18-22 seconds. I’m going back into my master image to delete the string, but still curious about what is happening under the hood.
George Spiers
December 19, 2017I would have thought that since the Scheduled Task would run quicker, there would be no change to logon times. Let me know if deleting the string resolves the longer logon times you are getting.
Pingback: Image Optimization Tools Comparison Matrix - Dennis Span
Alex G.
December 21, 2017Thanks – this is great. You don’t have any script available for 2012 R2 though?
Also, since the Serialize/StartupDelayinMSec value is stored in HKLM/Software, do we really need to change the default profile?
George Spiers
December 21, 2017https://jgspiers.com/windows-server-2016-optimisation-script/
Although the script was designed for 2016, some people have ran it on 2012 R2 and reported that it had worked fine.
StartupDelayInMSec is stored in HKCU, which is why I put it in the default profile. It can also be distributed by Citrix WEM or GPO for example.
Alex G
December 21, 2017Thanks, I guess I saw it wrong on some other site.
Do you know of any tool to mass load and modify ntuser.dat for multiple users? I have 5 servers without centralized profiles, and I don’t want to delete everyone’s profile again since I did that already fairly recently 🙂
Thanks again.
George Spiers
December 21, 2017You should just use Group Policy which will import the key in to the users HKCU hive! Easy enough done.
Kyrian
January 4, 2018George,
you stated the following about your lab: “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”.
how is your broker / Storefront / PVS configured in terms of hardware?
great article btw!
George Spiers
January 4, 2018They are all just standard 2vCPU and 2-4GB RAM. Nothing special, running on a Hyper-V host.
Jeff
January 6, 2018Hi, love your Blog, thank you very much for all the hints!
But I got also a problem with the UPM event. The task from the GPO gets created and tries to start but it fails with “wrong parameter (0x80070057)”. (Maybe the right translation is invalid argument as the original error is in german.)
I also tried “-wait” instead of “wait” only but it didn’t work. Any hints?
The task itself is not configured to run at highest privileges. If I run the exe by clicking on it, I don’t see any errors but also no time in Citrix Director (seems to be OK as the logon is finished at the time i click on it manually)
Jeff
January 6, 2018Never mind, just found it.
The path to the exe should not have ” around it. So it works as soon as I removed the ” in the task.
Logon time 20 seconds, perfect!
George Spiers
January 8, 2018Nice! Thanks for sharing how these tips resulted in an improved logon experience for you.
DaveG
January 9, 2018Great blog George! I’m using Environment Manager to test these tweaks before updating our gold image and am having an issue with the UPMevent. I’m seeing 2x “eventid 1000 – the session is ready for use” in the eventlog? I’ve removed the reg value in HKLM\Run area (using Environment Manager computer startup action) and added it to Environment Manager, Desktop Created trigger/action. After a reboot, the VDA has the reg value removed.
Disabling the Desktop Created action UPMEvent, and I still get 1x “eventid 1000 – the session is ready for use” in the eventlog? Any idea where this is coming from?
Using XenApp 7.6+PVS and our logons are already very quick (10s, 5s interactive), but thought I’d do any tweaks to further improve!
Thanks
George Spiers
January 9, 2018Thanks Dave. Sounds like there is something cached on the VDAs running upmEvent.exe.. I would disable Environment Manager actions etc. and then try running a ProcMon trace to see what exactly is running upmEvent.exe?
Alan
January 10, 2018Hi George,
Love your blogs a lot! Using upmEvent in GPO Task Schedule can save 30 seconds in interactive sessions. But when I use External Task for upmEvent in WEM, the interactive session increase 70 seconds. Any reason causes this? My goal is to use WEM instead of GPO.
Thanks
George Spiers
January 10, 2018Thanks! Yes that is because WEM is too slow to run upmEvent. It is best you use Scheduled Tasks.
Markus
April 14, 2018Actually i did setup a simple c# winform with a custom login (basically net use homedrive).
I use it together with the xenapp anonymous feature. The login time: 9 seconds to usable desktop. Currently experimenting with Explorer pre-warmup. The application prevents alt-tab etc. Login time 2-3 seconds. Id call it instant login 🙂 ( folder redirection works + ue-v possible)
Nirmal Thangarasu
August 21, 2018Hi George, after upgrade from VDA 7.9 to VDA 7.15, our logon has from 14sec to 18sec. only change was straight VDA upgrade to our image. which is 30% increase in our logon. anything can be done ?
George Spiers
August 22, 2018With such a small difference and no other change in your environment, I don’t think you can do anything here.
Jujurackon
August 30, 2018Hi There, great article !
I did follow Autologon tip though when my autologon user logoff it do trigger restart of my non persistent Windows desktops. I’m using Windows 10 VDA in Azure Environment with XenDesktop Cloud Service (currently v7.18)
any idea, why the auto restart is triggered and how to avoid it ?
Many thanks
Kevin Kutzera
August 30, 2018Hello,
I also followed this document and found it excellent. Reduced logins from 45-50 secs down to 18 – 20 sec. I also tried the Autologon trick but found that for the added complexity in the master configuration it didn’t reduce the login that much.
Have you checked the Reboot on logout flag for your delivery group? This can only be altered and read using the PowerShell command.
George Spiers
August 30, 2018Auto-restart is on by default for non-persistent VMs. The autologon feature is more suited for Server OS VDAs. Don’t use it against non-persistent VDI machines.
Jeremy Saunders
August 31, 2018Your mileage will vary as to performance gains you get by the autologon process within VDI. As explained though, non-persistent VDI pools are designed to reboot at logoff. This is controlled by the VDA and happens regardless of the method you use to connect and logon. So you have two ways around this:
1) You can disable the restart at logoff using PowerShell against the delivery group settings. This is not a good idea as you then have to manage reboots using another method.
2) Manage the starting of the VDA (Citrix Desktop Service) service to occur after the autologon has logged off. How do we do this? Well, after the VDA installs I set the service to disabled. I then have a Scheduled Task that runs as startup but delayed for 3 minutes. This sets the service to manual and starts it. By the time it starts the autologon process is complete and it does not force another reboot. Sounds complex, but is actually very simple. Delaying the start of the VDA also addresses issues where the VDA starts and registers before the startup of the VM is complete.
Some food for thought.
Cheers,
Jeremy
Jujurackon
August 31, 2018that’s what I though 🙁
If was hoping to find a “magic” solution to my logon problem and would try anything 🙂
but the culprit is somewhere else. Logon time is really bad and Windows hangs at “preparing Windows” like fore ever. in director GPO processing is good, Interactive session not that high and yet I see an overall +150s logon time.
I’ll have to check with Windows Performance Analyzer
thank you guys
Jeremy Saunders
August 31, 2018I would then be using this script to help pinpoint the phase of the logon process that’s causing the issue(s)/delay(s):
https://gallery.technet.microsoft.com/scriptcenter/Analyze-Session-Logon-63e02691
https://www.citrix.com/blogs/2015/08/05/troubleshooting-slow-logons-via-powershell/
Cheers,
Jeremy
Anonymous
August 30, 2018I’d rather not having to disable automatic reboot at logoff.
As per the article “…the autologon account when it logs off doesn’t trigger any sort of restart to the VDA”
Am I assuming right ?
George Spiers
August 30, 2018For Server OS that is true, but for VDI non-persistent desktops auto-restart is a default feature so I recommend not enabling it. As Kevin said, the autologon won’t bring amazing results to the table. I’d concentrate on other optimisations in this article to reduce your logon times.
Josh B.
November 13, 2018This is a great article!
I’m working on a XenApp 7.15 LTSR CU3 environment based on Server 2016 1607 VMWare virts. This is a small environment so no MCS/PVS. We use GPO-based folder redirection with local user profiles. Folder redirection is limited to documents and favorites. The desktop is not redirected. UPM is not used.
Typically on a newly created profile it takes about 30 seconds to launch a new desktop (measured from the time the icon is clicked in StoreFront Web to rendering of the desktop) with interactive session being 25-27 seconds in director. GPOs are usually 8-10 seconds, login scripts 1.5 sec and profile load 3.5 sec. This testing is completely internal from the StoreFront to the XenApp environment. 30 seconds would be acceptable if it were consistent, but if the server sits for an extended period of time with no users logged in or the server is rebooted, the login times are substantially more. In some cases I’ve seen new logons take upwards of a minute in these situations.
I’ve run Citrix optimizer on all the VDAs. I’ve deleted unnecessary active setup keys. I’ve tried to reorganize our GPOs to make them more efficient, but there is still 10 seconds in GPO processing. Unfortunately I’m not sure we can get rid of those as they are needed to lock down and configure the environment. Is there anything else that I can do to improve the situation? I noticed that Interactive Session is the majority of the time on the Director report, but I’m not certain what that is. I’ve set the StartupDelayInMSec key which improved the accuracy of the reporting in Director, but did not do anything for the real logon time.
The only thing I have noticed is that on the new profile creation during the login process, Windows will present the verbose output of all the things that its doing like User profile notification, Group Policy Processing, Preparing Windows. This part of the login process takes the majority of the time, but then there is a few seconds of a black screen. This is roughly during the same time as Active Setup runs as there is a quick popup for the web components setup which I had to leave the stub in there to get IE to pin properly in the start menu. I’m not sure what else is happening during this time. Maybe this is just Windows performing background creation of the new profile? If I login to an existing user profile, the total login time is roughly half of a new profile and the duration of the black screen is maybe 1-2 seconds at most. I’ve thought about trying mandatory profiles but I feel like that might not give me much improvement over the local profiles I have now.
I feel like I’ve gone through every article, comment, and forum post on this topic, and while there has been some slight improvements, I’m still not really satisfied with the logon performance. Perhaps I’m being a bit unreasonable in my expectations for this environment? Any insight or suggestions would be greatly appreciated.
George Spiers
November 15, 2018Thanks. Non-persistent desktops I take it? If so, logons will always be a struggle, and probably not fully consistent either. You could configure auto-logon so that an account logs on to the VDA after VDA reboot, which may overcome your issue with logon times being long after a reboot.
I would give mandatory profiles a try, since you aren’t using any roaming profile solution anyway, you should also consider redirecting more than just documents and favorites.
Also if you have time, give my Server 2016 Optimisation script a try on a test VDA and see if logons improve any further than what you already have. Keep in mind too that the more applications you have loaded on a VDA, the slower the logon process will be.
As a final thought, search your VDA’s registry for “upmevent” and if it is found under the “Run” key, move it to the “Userinit” string under the “Winlogon” key. This will not make logons quicker, but make Director timings more accurate.
Josh B.
November 16, 2018Thanks for the reply George. Yes these are non-persistent desktops. This is a relatively small environment with only 15 VDAs so I’ve tried to keep things as simple as possible. I wonder how much the underlying storage performance is impacting new profile creation. I assume creating a new profile generates much more read/write I/O than using an existing profile which is why existing profiles are so much faster to login. I don’t have any control over the VMWare hypervisor or storage environments as they are managed by another team. I was talking to that team this week, and they tell me the XenApp environment is hosted on a SAN with 10,000 RPM drives. In your view do you think going to a faster storage platform such as SSD based drives would result in any noticeable performance improvement regarding logon times?
George Spiers
November 16, 2018You mentioned your profile load is reporting at 3-4 seconds which is normal. Flash is always preferred but it’s not the only factor to consider and it really depends what other workloads are sharing the same storage, but I’m not sure it is cause for concern. Since you have a team managing the storage, they should be aware if IOPS consumption is too high or there is too much disk latency. Other factors that can impact logon times are VDAs with extra CPU, more powerful CPU, VDAs with sufficient RAM cache, fast network links between VDAs and profile stores and so on. Profile size is another one.
andrew
November 29, 2018following tips here as well as a logon duration script it seems like a big delay in our logons is due to: \Microsoft\Office\OfficeTelemetryAgentLogOn2016 54.92s C:\Program Files (x86)\Microsoft Office\root\Office16\msoia.exe . (scheduled task)
has anyone else come across this issue or tips to fix it? not sure if this telemetry task can somehow be globally disabled/removed for our base MCS image (so it does it for all users logging into the pool) and if theres any downside to doing it? i’d imagine every months office updates will just re-enable it again too
George Spiers
November 29, 2018What operating system are you running and when you mention the logon duration script, is that from ControlUp?
Anonymous
November 29, 2018in this current test its with Windows 7 SP1 x64 (we have a 10 environment too that we’re migrating too but i started here). and yes it is from ControlUp but based on the same criteria i think but maybe different enough that it doesnt apply. https://www.controlup.com/great-new-update-analyze-logon-duration-script/
That telemetry task though i’m wondering what i can do about it and if thats possibly whats affecting the super inconsistent and slow “welcome ” screen….thats ultimately what i’m trying to fix here and tried everything i can find so far but no luck
Satya
March 20, 2019Hi George, Great fan of your work. In regards to this article, I did implement the same across a customer’s environment Xenapp 7.15 LTSR CU3 on server 2016. Since that time, director stopped displaying logon times for all user sessions. As a test, i re-created “Citrix UPM UserMsg” key again for upmEvent(which was deleted as part of this article) on template and pushed out. And the director started displaying logon times again. I did confirm that the task scheduler for UPMevent is definitely applying, so not sure what else is required?? i did implement the same across 7.13 Xenapp before and it worked without any issues.
George Spiers
March 20, 2019Delete the upmEvent run key and instead specify the executable under the Userinit string and let me know if that works. Userinit is found under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.
Each Userinit entry is separated by a comma. Insert the value “C:\Program Files\Citrix\Virtual Desktop Agent\upmEvene.exe” without quotation marks.
Satya
March 21, 2019Still no joy. Seem to work only if UPM reg key is present.
George Spiers
March 21, 2019Sent me a screenshot of your Userinit string, you can use the contact form to send me a mail and I will reply so you have my email address.
Whitney
April 16, 2019C:\Windows\system32\userinit.exe,“C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe wait”
or
C:\Windows\system32\userinit.exe,“C:\Program Files\Citrix\Virtual Desktop Agent\upmEvent.exe”
George Spiers
April 16, 2019The bottom line works just fine.
Andrew
April 17, 2019I am eager to try as many of these tips as we can in our Citrix MCS non persistent / App layering (user layer) environment for Win 7 and 10. I’ve implemented the citrix optimizer scripts and another windows 10 script to clear up some of the junk ware already but still seeing longer logon times ….most specifically the Welcome screen hangs for up to 30-40 seconds most times and stumped. Using a ControlUp script and a very basic image test (OS layer & platform layer only to start) I still see the issue and it looks like the big culprit is a long interim delay before the user profile step (screenshot link below). would you have any ideas where to start for that specific delay?
https://drive.google.com/open?id=13zkxaQmsA1uMIUQr94QTWSrilSTRpk_X
andrew
April 17, 2019to add to my last comment, i either see the interim delays before user profile or right after group policy: https://drive.google.com/open?id=1JyXGichky4iR1bYbrZPjFDcoxNCBt8AI
andrew
April 17, 2019to add to my last comment, i either see the interim delays before user profile or right after group policy
George Spiers
April 19, 2019In my experience Windows 10 logons are longer, but things like Citrix Profile Management/FSLogix can drive these down. What I would start with again is the OS layer/Platform layer published as an image and nothing else applying e.g. no Group Policies applied period, and no Elastic Layers. Work from there. If you are already getting 30-40 second delays even though optimisations are included in the Platform layer, something is not right. Check your MCS configuration and make sure to use RAM cache with a HDD for overflow. Also I would recommend atleast 4vCPU per Windows 10 VM.
andrew
April 28, 2019Thank you for the help! so we were setup for 1vCPU / 2 cores each and just bumped it up to 4 cores each and that seems to have helped w/ performance overall so thanks for that recommendation. We are using Nutanix AHV so i thought we were told that the ram cache / hdd overflow applied to that setup (unless we were wrong…i dont even think we see that as an option for mcs since changing to AHV)
George Spiers
May 3, 2019Yes MCSIO is not available, or needed, for AHV.
Jeremy
October 20, 2019I wanted to follow up on the 30 -40 seconds hang as soon as you logon. I have same issue.
Pingback: Citrix Troubleshooting 101: Frequently Asked Questions | eG Innovations
Calvin
August 14, 2019Hi George,
First and foremost, big fan of your work, contributions and putting time to help the rest of us out.
We’ve recently picked up ControlUp and in attempt to lower our logon times, we’re seeing that “\Microsoft\Office\OfficeTelemetryAgentLogOn2016” appearing as a logon scheduled task. .
Here is the result from the logon duration analysis:
\Microsoft\Office\OfficeTelemetryAgentLogOn2016 15.02 C:\Program Files (x86)\Microsoft Office\root\Office16\msoia.exe
15.02 seconds (average) for this process, did you or anyone else find anything about this? I can’t seem to find anything online.
George Spiers
August 18, 2019I haven’t specifically heard about this but have you tried to disable the Scheduled Task and does it make a difference? I always disable it.
Jason
August 28, 2019Hey George do you have a W10 1607 optimization script?
George Spiers
August 29, 2019Hi I only have 1709 and 1803.
James Golden
September 19, 2019Hi George, thanks so much for this article over 2 years and going! I am working at our login times, we currently are in the 50 second range!
Just wondering if you had a recommendation for autologon. We run Windows Desktop for users, non-persistent. I was debating about the auto-logon, but currently we have it set to reboot after logoff. So… change the restart at logoff and go with a rolling reboot cycle and use auto-logon? OR.. just leave it?
Also would you be so kind as to send me your excel spreadsheet with the listed modifications! I would greatly appreciate it.
George Spiers
September 29, 2019Hello. Optimisation spreadsheet sent. I personally would only use autologon with Server 2016 VDAs.
Dazza
October 14, 2019Hi George. I tried the upmevent optimisation with 7.15 CU3 seamless apps on 2k16. Whilst it does seem to make things look better in Director, the user experience actually got worse for us. Ultimately, the user just cares about the time from click-to-app of course, and when I did this change the user experience here went from ~28s to ~34s. Director showed an improvement.
George Spiers
October 15, 2019Interesting. Not experienced that before but good to know. Actually in later releases of Director and the VDA, the logon times are more accurate.
Mohan
October 15, 2019Hi George. Can you please tell me the powershell commands to get the authentication time.
George Spiers
October 15, 2019Hello – There is no cmdlet for that.
Allister
October 17, 2019Hi,
Since changing the upmevent to run as a scheduled task the interactive sessions are now should really high times. They are not accurate however I a seeing as high as 823 secs.
Any ideas why this is happening?
George Spiers
November 3, 2019Have you tried placing upmevent n the Userinit string?
Also note that this should not be needed for the latest VDA versions.
andrew
December 4, 2019On the topic of Windows 10 slow “welcome” screen…….we are a Citrix MCS non persistent / App Layering Full User Layer environment. I am doing another run through of all the tips here again to make sure i didnt miss anything but I am seeing very dramatic variances in how long that “welcome” screen can take. At times It can be as little as 7 seconds and in other situations it will sit there for up to 60 seconds (using the same test account at different times of day) and i’m stumped what could be affecting the differences. I do see we have the Citrix telemetry service running/enabled so i am going to turn that off as my next stepWhat is actually going on during that welcome stage?
George Spiers
December 14, 2019Authentication, profile load, any logon scripts etc if configured. Just Windows 10 being Windows 10 too. I would just run a procmon and try and capture the good and bad, then compare to see what you find.
andrewgresbach
December 23, 2019thanks George! so i’m going to see what i can do w/ procmon this week but one big observation i made today…..if i connect to a session via a single monitor setup , total login time is around 25-30 sec (acceptable). but if i connect w/ a dual monitor setup it jumps to 60-70 sec (min). From what i can tell the biggest difference is the time we see Director attach a VDA to the session……single monitor client it attaches one in 12-15 sec whereas dual monitor client takes around 30-35 sec for that step. all goes quick after that. is this normal? or any ideas since all of our users have a dual monitor setup unfortunately
George Spiers
February 17, 2020I have not heard of that issue before. What version of Virtual Apps and Desktops do you use?
andrew
February 17, 2020currently on LTRS 7.15 (but also tested w/ the new 1912 LTSR VDA in preparation to upgrade backend as well) but same result. i also have found if i do the same test but w/ RDP, dual monitor logins are just as fast as single monitor . others in Citrix forums have reported this may be something new since 1903 but cannot confirm that
Chris
February 17, 2020Hi Andrew,
confirming we also have the same issue and Citrix have also confirmed multiple customers have reported it.
It does indeed seem to be linked to Win 10 1903, unsure about 1909. You’ll find that RDPing to the same machines while utilising all monitors will not have the same slowness.
We have it logged through a third party so i can’t give you a case/defect ID to reference when logging a support case yourself.
Chris
andrew
February 17, 2020thanks for chiming in Chris. i tested on 1909 last week and same result unfortunately. so did do you know if this for sure broke as of 1903 ? we didnt fully move to 10 for our users until then so hard to say how 1809 did. I actually have an open ticket w/ Citrix now too and just got escalated so still fighting through them asking for trace logs, details, etc. i even tested by enabling advanced diagnostics during the boot and created .gifs to show that its not any one step of the logon process that is hanging w/ 2 monitors but EVERY step just seems to take longer. i saw other posts on citrix forums that they observed high cpu during this phase w/ 2 monitors so that could account why everything is just slower. not sure what do w/ that info but interesting for sure
George Spiers
May 10, 2020Try this:
In Group Policy, set “Show clear logon background” to “Enabled” under “Computer Configuration -> Administrative Templates -> System -> Logon”.
andrew
May 10, 2020Hey George, thanks for this! i actually JUST stumbled on this a little ways back and helped a lot! now i have my dual screen logins down to the same speed as single so huge improvement w/ this setting (which i understand started w/ 1809?). i’m looking at about 28-40ish sec logons for my non persistent mcs / app layering setup. be awesome if i can trim down even more but making some good progress
Pingback: Citrix Troubleshooting Guide & FAQs | eG Innovations
erkan sefiloglu
March 6, 2020Hi JG, as always very helpful and to the point. Ffor now i have used the userinit part to get this working, but is it only me that finds when i create the scheduled task in group policy, it only runs on second logon as first logon it is only created and does not run. Is there a way to get around this on a non-persistent VDI? Just in case i need to use it in future. No issues using the sched task for autologoff when using autologon as i can logon as the user twice to get it into the autlogoff users profile before sealing the image, but can see a way around it using it for interactive time as a new user can logon anytime.
erkan sefiloglu
March 6, 2020Hi JG, as always very helpful and to the point. For now i have used the userinit part to get this working, but is it only me that finds when i create the scheduled task in group policy, it only runs on second logon as first logon it is only created and does not run. Is there a way to get around this on a non-persistent VDI? Just in case i need to use it in future. No issues using the sched task for autologoff when using autologon as i can logon as the user twice to get it into the autlogoff users profile before sealing the image, but can see a way around it using it for interactive time as a new user can’t logon anytime.
George Spiers
May 19, 2020Hi. Try creating it under Computer Configuration rather than User Configuration?
chris stevenson
April 17, 2020We have an interactive logon, is there a way that we can bypass that for the autologon to complete? thank you
George Spiers
September 7, 2020You could not apply it initially, and then have the autologon account run a script which populates the registry strings:
‘legalnoticecaption’
‘legalnoticetext’
Under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Pingback: Controlling the Starting of the Citrix Desktop Service (BrokerAgent) | J House Consulting - DevOps, Microsoft, Citrix & Desktop Virtualisation (VDI) Specialist - +61 413 441 846
Anonymous
September 7, 2020Okee i got this setup out invernmont is upgraded van 120/280 sec too 30sec only
My only qeustion is i need to shutdown machine on logoff citrix user.
I cant use shutdownafteruse because it will shutdown after ctxautologon.
Cant use peaklogoff action too…
Is there any other way to shutdown on logof except the ctxautologon account.
michael
September 7, 2020Okee i got this setup out invernmont is upgraded van 120/280 sec too 30sec only
My only qeustion is i need to shutdown machine on logoff citrix user.
I cant use shutdownafteruse because it will shutdown after ctxautologon.
Cant use peaklogoff action too…
Is there any other way to shutdown on logof except the ctxautologon account.
Michael
September 10, 2020Next question! Our VDA setup is good now.
But only my next problem is our ThinClients fully updated HP t520 are experiencing slow logons 160 seconds with same profile if started from webbrowserstore or RDP 30 seconds.
Anyone experienced any of this in a envirment?
Our company hasnt had any good Citrix Experience so far from there previous partner wat im trying to fix.
Pingback: Citrix Troubleshooting Steps – eG Innovations
Pingback: www.jgspiers.com today login - portalall
Pingback: Crsd Citrix Data - logininfos.com
Joshua M.
January 13, 2023Awesome.. thank you.
Only thing you should ad for the Auto Logon / Logoff scheduled task would be delaying it for 30 seconds. On my 1912 VDAs on Server 2019, the logon process was not fully complete before it ran the “logoff” bat file. So logoff failed and left the user account logged in and would idle off based on policy.
Pingback: Supercharge Citrix Logins: Collection of Tips From the Field | BLOGS
Pingback: Optimize Logins v2 – World of EUC