Slow logon is one of the most common user complaints faced by Citrix admins. When logon is slow, it affects the end-user experience and business productivity.
Because XenApp and XenDesktop logon comprises many steps and depends on various parts of the infrastructure, it is often difficult to know what is causing logon slowness. The biggest question every Citrix admin has is “How do I make Citrix logons faster”?
Here are some best practices from George Spiers, CTP, based on his real-world experience to optimize your Citrix infrastructure to make logons up to 75% faster.
• Understand what factors are involved in Citrix login processing
• Learn optimization techniques to make logon faster including profile management and image optimization
• Learn how to improve logon times using new Citrix technologies such as App Layering and WEM
• Pick up tips, tricks and tools to proactively detect logon slowdowns
Mention the CTP award in 2018.
Mention I am a Technical Services Architect, and I oversee a large XenDesktop farm in my day-to-day job, including foreseeing the roadmap and adoption of new Citrix technologies within the enterprise space.
So, first let us understand the Citrix Logon Process itself and what is involved there, as well as the implications of logon slowness.
Starting at the top: What happens when there is logon slowness
Talk about how I like to investigate these types of problems by way of process of elimination
There is always a consequence when things aren’t working quite like they should, or as they did:
These are typical and common reasons why logons increase in Citrix environments.
Bad image management or lack of love for an image is a reason.
Using old hardware with more users or using newer OS which is more demanding, but expecting to get the same user experience – doesn’t always work that way.
Look at how a simply 15 second logon increase can affect user productivity. Over 20 hours per week lost due to logon increases.
It is your job to monitor for slow logons. Don’t let end-users do your job for you.
Director out of the box can provide average logon durations to many of your helpdesk and Citrix administrator staff, there is no reason not to use this product.
Third-party solutions go a step further, testing life-like logons and alerting you if anything is abnormal so that you can act before users notice the impact.
Logon performance cannot be treated the same for every case. There are a lot of factors that can impact logon performance, outside what Director itself monitors.
Factors include slow/latent network connections, StoreFront/NetScaler Gateway load and authentication times, brokering times and so on. You need to track logon performance end to end. It is not just about the GPO load times, profile load times, desktop availability and so on.
The logon differences between Server OS and Desktop OS across XenApp and XenDesktop do not differ a whole lot.
Now that we understand the impact of logons, and the process, let us look at some best practices to drive logon times down, starting off with Windows Optimization
This is one of the newer techniques I have started to think about when deploying new Citrix environments. It is generally easy to configure and little overhead if any to maintain.
A common trend I and others find is that the first user to log on after a Server OS restart generally encounters the longest type of logon. Rather than having a real user bear the pain, we can hand that off to an auto-logon account configured with tools such as Autologn from Sysinternals.
Image optimization is a must in any environment if you want to reduce logon times.
If you want an example, take this real-life example performed by me. After running my optimization script, average logons were down by over 20 seconds.
It is important to not forget about optimizations, ever.
Just because you have already optimized the image during base build doesn’t mean you should stop.
New Windows patches, software installs and so on can create new Scheduled Tasks, Services and other items that should be removed if not needed.
If you are looking for optimization scripts, I advise you check out the three links here. I’ll leave this page up for a few seconds so you can grab a screenshot. For those who cannot make it, the webinar is also recorded.
You can delay scripts from running until the user has logged on.
The best advise is to try and do away with logon scripts completely.
Group Policy is the configure once and walk away tool. People are scared to even remove settings that have been there for years as they don’t know the effect. With some homework it’s quite easy to determine if a policy setting should be kept or not. Regularly do this.
Merge group policy settings under the minimum number of GPOs as possible. It’ll be easier to manage and gives the Group Policy processing engine less work to do.
Take the example where you have a root folder and five sub folders for each department, and each department have their own mapped drive and drive letter. Do you need this? Learn to be more creative with your drive mapping. It is all too easy to spin up a new drive letter for a group of users or department.
Access based enumeration and permissions allow you to have a single mapped drive that is still secure for each department.
WEM is another option which maps the drives after a user has logged on.
Printer sprawl is hard to manage and keep track off. Many broken printers or printers that no longer exist still have a print queue residing on a printer server which is being mapped to a users session.
WEM again can help improve logon speeds by processing print queues after a user has logged on.
Autoruns is a great tool for analysing what is actually starting up when you log on
Let us now look at infrastructure optimization
Hyperconverged can at times offer better performance than traditional server to SAN type configurations.
Flash storage should always be used, and you want to size it for peak load for example during logon storms during peak times like 9AM. There is no point in sizing storage or other elements of hardware for anything other than peak load.
Power settings across XenServer, Hyper-V and ESX can be tuned for VDI workloads. Always check with your hypervisor vendor and hardware vendors for best practices on configuring for Citrix workloads.
Subnet to Active Directory Site can cause logons to travel further than they necessarily have to. Always make sure if you work in a large organisation and they have multiple locations, that AD Sites and Services is configured according to the company locations.
Always consult with your security team before excluding any file, folder or process from anti-virus.
As Citrix release new solutions, old recommendations go away and new ones replace them.
Next we look at Citrix optimization.
Session Prelaunch is for XenApp applications only and there is no licensing restrictions.
Users that use physical PCs don’t always launch their Citrix applications straight away. We can use this to our advantage.
Unregistered VDAs typically mean more contention for resource however you look at it.
Monitor for unregistered desktops, or let the monitoring tools do it for you. Director can do it in Platinum, third party tools can also do it and even take action for example to force restart desktops when they are unregistered for a certain amount of time
Just by upgrading to 7.11, you are getting some optimised code that makes improvements to SQL blocking queries. Look at the table, it shows the brokering requests per second between 7.11 and previous versions. Also the amount of time it takes to broker 10k users.
Zones is another way to group Delivery Controllers and VDAs together so that you have your resources closest together wherever they are in the world.
Don’t let an incorrectly configured Power Plan be the cause of slow logons. Adding desktops to a Delivery Group but not adjusting the power plan is one I have witnessed before.
Also, if using cloud, Smart Scale is a must to make sure you have the correct amount of VDAs powered on to serve your user base, without wasting money on compute that is not being actively used.
You are probably all familiar with RAM cache. MCS can now do the same thing post 7.9+
Elastic Layers is new to many, and a great feature for flexibility and user customisation. Just do not get too dependent on it.
Fine tune CPM to get the best performance possible during logon. You don’t need everything in the profile, putting in the effort to tune CPM will reward you in the long run.
Rather than cache the profile fully to the VDA, grab files when needed.
XenApp and XenDesktop
You can only predict to a degree which folders and files to exclude from the beginning. What about the files and folders after that consume a lot of space?
Previously you would have depended on scripting to remove those from the profile store.
Now you can use Logon Exclusion Check so that excluded directories/files are either
Kept on the profile store but not synchronised down to the VDA when a user logs on
Deleted completely from the profile store.
Versions 5.7 and 5.8 controlled this setting via UPMPolicyDefaults_all.ini
Version 7.15+ can be controlled by ADMX.
Rather than cache a large file to the VDA, we can just have CPM create a symbolic link to it. This is pretty much like redirected folders at a file level.
Support for one active session at a time.
Many times you have published applications that do not depend on the profile at all. In this case, you can use XenApp Optimization, a new feature to 7.16. You create an XML file with the file and registry keys the application DOES need, and anything else in your profile is created as a symbolic link back to the CPM store.
WEM is a big player in reducing logon times.
It is all about user perception in this case. Getting the user logged on as quickly as possible before applying actions such as printers, mapped drives and registry edits. Something we would have done during logon.
WEM goes further than that and improves the user experience using CPU and IO optimization. This is important in shared environments because a simple bad process consuming large amounts of CPU will undoubtedly affect the next user logging on. Instead of this being the case, WEM can tame such applications and processes so they don’t hog resources.
What is WEM and why is it different? Discuss how before you have Group Policies applying as a user logs on. Now you have WEM doing the same but only after logon.
Brief mention of architecture and Agent placed on VDA.
Mention of entitlement (Enterprise + CSS)
User perception is key, the quicker they see the desktop wallpaper and interact with the desktop the better.
Mention how GPP, Logon Scripts etc. would have traditionally been used to do the same.
With Spikes Protection, you can configure your VDAs to object to processes consuming 90% CPU for example for a defined amount of time. If a process is consuming 95% CPU for 60 seconds or more, its priority is lowered.
The default priority initially is High and then a history is kept as to each time a process triggers spikes protection.
Example if when a user first launches Internet Explorer.
Proactively detect logon issues and solve them before real users access the Citrix environment
Benchmark logon performance with simulation, and use it as measure of comparison for when real users connect
Compare logon performance from different locations
Test application availability and whether all components of the Citrix delivery stream work in concert
Question 1: How much RAM should I give to Server OS VDAs and Desktop OS VDAs when using PVS?
Answer: 2-4GB for XenApp and 256-512MB for XenDesktop. The more RAM you assign the less chance writes will be written to disk = better performance.
Question 2: You mention XenApp Optimization for Citrix Profile Management released in 7.16, can I run 7.16 Profile Management on a VDA 7.15? If so, how can I upgrade?
Answer: Yes, there is an MSI within the 7.16 install media that you run, which upgrades your profile management piece to 7.16.
Question 3: What entitlement must I have to run WEM?
Answer: XenApp or XenDesktop Enterprise with an active subscription to Citrix Success Services
Question 4: When performing Optimizations to an image in App Layering, if for example I create an Adobe layer and want to disable the update scheduled task, is this done in the application layer or on a Platform layer?
Answer: On the Adobe application layer. The same applies to applications such as Office, which creates telemetry scheduled tasks which can be disabled within the Office layer itself.