Profile Optimization and “How do I speed up login times?” generally go hand-in-hand. These have to be two of the most important and most talked about items when it comes to delivering XenApp desktops. There are lot of difference philosophies and strategies with regards to this, and in this article I’ll simply talk about what I have implemented in my environment. I have gone through extensive testing, tracing, logging, and analyzing of my settings and will show you what has worked for me. You can use some of these techniques to troubleshoot your own environment and see if you can get some gain in yours.
To start, I have leveraged many whitepapers, blogs, and Citrix KBs to generate my settings. I’d like to give credit where credit is due. First the Citrix XenApp and XenDesktop Policy Planning Guide was a good resource and baseline for everything. Second, this Citrix blog about Citrix Profile Management had a lot of great information. Also, CitrixIRC, of course, has been a great reference to talk things through with a bunch of great Citrix Admins. Join our chat at http://join.citrixirc.com. I have also read many other things on these topics, but I don’t recall them well enough to cite them.
Let’s get the framework in perspective here. I work for a Citrix CSP (Citrix Service Provider) and we currently have a couple dozen farms mostly in the SMB space (<250 users) I don’t do any enterprise work, so my tools and tricks are built around an SMB mindset. I use Citrix Profile Manager and GPOs, exclusively. I do not use any other third party tools to manage my profiles. I try to keep my environments simple enough for our other admins to be able to manage them. I think that if you can configure and test these tools properly they can do the job well enough to not need additional cost factors in our environments.
That being said lets start with Folder Redirection! Simply put, I redirect everything, except for AppData, utilizing GPOs. I manipulate AppData with UPM and we will talk about that later. Redirecting everything keeps it out of the profile and keeps the profile small. Simple enough.
Folder redirection isn’t the only culprit for large profiles. There are other commonly used programs that keep crap in the profile. I use GPOs to redirect these items as well. Outlook PST and OST files. Download the Office admx templates and USE THEM. “Microsoft Outlook 2010/Miscellaneous/PST Settings”. I set “Default location for PST/OST files” to a network drive. Well, I’m not using cached mode you say? Other things are stored in PST files as well, such as SharePoint Lists, so keep this in mind. AutoArchive? This will create a PST also, so if you are using this, you will want to make sure PST/OST files are moved. AutoRecover files are also stored in the profile. You can redirect Excel and Word Autorecover using the same admx templates.
How about Evernote? A lot of my users use Evernote, and by default the database is stored in AppData\Roaming. I redirect this to a network drive with a GPP Registry key. “HCU\Software\Evernote\Evernote” REG_SZ “DatabasePath”. I have seen very large databases and this is a good tweak to keep the profiles small.
Let’s talk AppData. First, I use UPM to exclude AppData\Local and AppData\LocalLow at the root. I keep AppData\Roaming in the users profile mainly for the performance implications of this being redirected on a large scale. However, I use the UPM to exclude a bunch of directories to keep it as small as possible. I will attach my UPM GPO for you to look at these settings in more depth. I exclude about 12 directories from AppData\Roaming that were gathered from the various best practices documents. Using Chrome? Chrome keeps all of its settings in AppData\Local. Shame on you, Google! With UPM, this is no problem. I do 2 things with Chrome. First, I include AppData\Local\Google in Synchronization. Second, I exclude AppData\Local\Google\Chrome\User Data\Default\Cache, Cached Theme Images, and JumpListIcons. This allows my users’ Chrome settings to save, but excludes the not-needed bloat directories.
Don’t forget the cookies! I have written another blog here on that. Read it!
How about the rest of the UPM settings? Again, I’m going to attach my UPM policy in here somewhere, but we can run through the basic settings. I delete cached copies of local profiles. We always want to load a fresh profile each time. This will lower profile corruptions. How about profile streaming and active writeback? Well, I turn these off. Most people will say that’s dumb, and those are great features, and you should keep those on. Well, I can see how these are great features, but again, I’m tuning these settings for my environments. With the tweaks I am implementing I have an average profile size of 30meg. The profile itself can load in less than 1 second on a gigabit network, so I’m not too concerned about this. These settings are nice for larger setups, but in my environment I’ll keep it as simple as possible.
Did you use the 2008 R2 Optimization Guide for XenApp 6/6.5? Well, don’t forget this blog post about one of the settings you need to change if you are using the UPM. Without changing it, UPM times out a lot and slows logon/logoff processing.
Don’t forget to exclude all of the un-needed folders inside of the profile as well. This is done with a GPO.
When all is said and done, here is what my profile looks like. Of course, this is a test user, but this is a great foundation to build user profiles on. Notice there are not any folders in there except for Windows and AppData.
Do you already have an environment built and would like to tweak these settings? I certainly did. I actually wrote a script that would go through the Profile Store and delete out all of the bloat from the users’ existing profiles. You can check that out script here. Its powershell, so have fun. I had users with 1gig profiles and was able to lower then to 30-60meg in our internal environment. Note, this must be run from the Profile Store directory.
One setting that works for me, but will require testing, is the GPO to wait for network at computer startup and logon. I was able to gain about 13 seconds on my logon times when I disabled this setting. Your mileage may vary.
Are you using GPPs for shortcuts and printers and such? I did a lot of GPP tracing to analyze these mappings and found this to be true inside my environments. If you create GPP Shortcuts using “update” it takes about 200ms for each item at each logon to parse. If you have 60 shortcuts between the start menu and desktop, that’s 12 seconds right there. That’s not a short amount of time. Setting these to “create” will speed this up to about 5ms per item at each login. You can change it to “update” if you actually want to change something in the future. I gained another 15 seconds on my logins when I changed all of my GPP shortcuts to “create”. The same basic numbers apply for printers too, however, I have not traced them to get exact numbers yet.
Login times have a lot to do with how many GPOs that you have in your environment. Remember these tips. Always prefer fewer larger GPOs opposed to many smaller ones. Each GPO has a set base processing time that can be avoided by consolidating GPOs into one larger one. Make sure you disable Computer/User settings in a GPO if you aren’t using them. This lowers login time a second or so per GPO.
So, what did I use to troubleshoot all of these things? I do curse Microsoft for getting rid of the userenv.log detailed logging. Nothing works quite as good. UPM logging is a really good place to start, however. You can turn it on in the UPM Policy GPO, and parse the logs with the UPM Log Parser. You should also be using the GPSvc.log. You can set that up using this blog. Don’t forget to create the “usermode” directory if it doesn’t exist, or the logs won’t work. You can also turn on GPP Tracing in a GPO under “Computer Configuration\Policies\Administrative Templates\System\Group Policy\Logging and Tracing”. You can turn all of these on, and enable tracing, to get detailed information of your GPPs. Some people like to use Policy Reporter to go through the logs. This is a nice tool, but I just read the logs manually.
Using all of these tips and tricks above, I was able to get my test user in my test environment to log in after about 9 seconds on the 3rd login. Obviously the first 2 logins are a tad slower as it builds the profile from scratch and runs some other scripts that I have in my environment. Now, keep in mind that’s a bare environment and your mileage will vary here as well. In my internal environment I was able to speed my logins up from around 75 seconds to 23 seconds. This is keeping in mind that our internal environment has about 847 GPOs and isn’t optimized at all. In my customer facing CSP environments I have gotten about a 75% improvement time in the environments that I have implemented these changes.
Take a look at my detailed UPM policy is here
