How to get the fastest possible Citrix logon times

We all want super-quick logons in XenApp and XenDesktop environments. How can we get them?

Introduction

User experience is a metric which is much more of a consideration today then it ever was before. Ensuring that our users have an interaction with applications and data that is slick, responsive, productive, flexible and satisfying is high on the radar of most enterprises. In today’s modern workplace, users have access to a plethora of personal devices – mobile phones, tablets, laptops, consoles, etc. – that often provides an experience that compares unfavourably towards that they are given in the corporate environment. When user experience in the workplace is poor, users experience frustration and low productivity, and can be tempted to use non-sanctioned external solutions to get things done. Suffice to say, a substandard user experience leads to a plethora of problems, on a number of levels, that are not in the interests of any enterprise to be subjected to, problems such as:-

• Employee dissatisfaction
• Security and data loss issues as users resort to using “shadow IT” solutions
• Loss of productivity and wasted work time
• Delays to processing of business functions
• Increased employee stress
• Problems with employee retention
• Negative perceptions of the business IT department

There are many others, but these are the main issues that can go hand in hand with the delivery of a substandard user experience.

But a problem with defining and delivering a good user experience is that user experience (or UX) is that it isn’t particularly an objective definition. UX is a holistic metric, encompassing the user’s overall feeling of satisfaction or engagement with not just one, but all of the systems at their disposal. UX can vary from user to user and department to department depending on how they interact with applications, and to what degree. Understanding how your users are feeling about the “experience” is vital, yet pinning it down to a specific “rating” can be incredibly difficult.

Whilst difficult, it is possible to define to a certain degree the current level of user experience being delivered to users in the environment. Certain technical solutions can aggregate key performance indicators together to produce a “UX” metric which serves as an indicator of the current level. They normally work by combining together a set of key performance indicators (KPIs) that are used to extrapolate a specific UX reading. The KPIs involved usually include things such as, but not limited to:-

• Logon times
• Application launch times
• Key application interactions (e.g. opening a document from a dialog box, entering data, etc.)
• Common admin tasks (e.g. running a report, exporting data, etc.)
• Printing

Being able to define the UX metric also points us to another bugbear of modern IT environments – the focus of monitoring. Traditionally, monitoring of systems concentrated solely on back-end infrastructure – looking at databases, storage, networks and servers. Now that the performance on the client end – the “front end”, as it were – is also considered equally important, the focus of our monitoring needs to shift to encompass the whole environment, rather than just the infrastructure. This level of monitoring is also vitally important in any upgrade project – allowing baselining of the UX in both old and new environments to assess any performance improvement or degradation.

Some of the products I’ve used to measure levels of user experience – to varying degrees – in past projects are listed below. This list is not intended to be exhaustive, nor as a bake-off, just as a list of examples.

• Lakeside SysTrack
• ControlUp
• eG Innovations
• Nexthink
• LiquidWare Labs Stratusphere
• Flexera AdminStudio
• Citrix Director
• Microsoft System Center / Operations Management Suite

If you can’t stretch to getting a piece of monitoring technology to help you out with KPIs like logon times, then you can use things like this script from Guy Leech which will allow you to measure your logon durations. Ideally you’d want to measure the whole user experience, but for the purposes of this article, this can certainly help you get up and running measuring your logon times.

Logon time is the most pertinent of the KPIs used to measure user experience, because it’s often the first interaction that a user has with a system, and therefore drives the perception of all other interactions after that. We’ve all heard the stories about the exec who comes in, logs in, and then goes off to make a cup of tea or bowl of cereal because the logon takes that long. I’ve seen logon times from the very quick to the insanely time-consuming (ten minutes or more). In environments like healthcare, logon or reconnect time can literally be the difference between life and death. But even if you’re not in such a critical environment, there are still big effects for your business. Imagine you have a hundred employees, whose time makes your company on average £50/hour in revenue, and they each have a three-minute logon to cope with every morning. If you could reduce that to one minute, those hundred employees would be bringing in an extra £165 per day – which is £42,900 per year. You can slide this scale up or down dependent on number of logons and reconnections, number of employees, amount of time saved, or amount earned per hour, but the base fact remains the same – cut down on logon times, and you make more money for your business.

Of course in persistent, one-to-one environments where users have local profiles and dedicated devices logon time isn’t that huge a factor (although, I have seen it, so don’t write it off). But in many enterprises where they use Citrix XenApp or XenDesktop, users have non-persistent sessions and often move between many different devices or ways of accessing their applications. Getting logon times right in these environments can be a very big challenge, often made worse by the need to centralize management of the solution. This article aims to give you a set of pointers that can get you the best possible logon times within a Windows-based Citrix environment, but many of the techniques described herein can also be used in non-Citrix environments as well – particularly Windows 10.

What happens during a Windows logon?

It’s worth trying to understand what actually happens during a logon to a Windows-based desktop or application. The diagram below isn’t trying to provide a huge amount of forensic detail, but simply a guide to the various stages of logging on.

Some notes on the above:-

• This only applies to Windows logons! I’m not acquainted (yet) with breaking down logons that may be running from a Linux VDA 🙂
• The Session Initialization phase only applies to applications or desktops that are launched from Citrix Storefront/Workspace app or the RDSH web interface or similar. If you’re logging directly on to a Windows machine, you would naturally start from the Authentication phase, when you submit a username and password.
• If you’re running from Citrix/RDSH, the credentials that are submitted to the Authentication phase are normally (but not always!) submitted via pass-through from the Session Initialization phase.
• These phases all run sequentially, so each one depends on the previous. Each phase will also write an event to the event log upon completion, which is how many technologies measure the logon phase durations, by reading the entries from the logs.
• The Userinit phase only applies to published desktops or “ordinary” sessions, not to published applications.
• The Shell phase also only applies to desktop-based sessions – for a published application, the Shell phase actually launches the application path with the parameters specified.
• If you use a technology such as Ivanti User Workspace Manager which has its own engine that runs at logon, you may see the time taken for this showing as “Logon: Other”.

In my experience, most problems occur at phases #3 or #4 – User Profile or Group Policy.

History of logon times

The logon times for different versions of Windows have increased rather exponentially over the years. This is the time taken for a first logon of a user to Windows based on different Windows OS versions – interestingly (or not), it also shows the change in the user profile size, as well as the logon times. Logon times (in seconds) are shown by the yellow line.

The Windows NT4 figure may be slightly overstated, given that I used a VM with a whopping (for NT!) 1GB of RAM, but the figures show a slight, steady increase until the advent of Windows 8.1, and after that, for Windows 10, a huge uplift to almost unsustainable levels. Server 2016 is the outlier, moving back down towards a more reasonable figure, but it is still clear that over the years the first logon time has experienced an exponential increase.

The reason that Windows 10 stands out so awfully is because of the OS’s habit of “provisioning” UWP applications into the user profile at first logon. UWP apps may well be disappearing in the near future, with the advent of MSIX, Microsoft’s latest application technology, but in the here and now those of using Windows 10 on XenDesktop (or not) will still have to deal with this aberrant behaviour.

Let’s make our logons super-fast!

So, how do we go about addressing these problems, and giving ourselves the best logon times possible, and the happiest users in the world? All over-excitement aside, there are a number of approaches we can take that will help us bring these logon times down. Let’s run through them.

Storage

Do I still need to bang this drum? Sadly, maybe. If you’re not putting your targets on the fastest possible storage, then don’t expect to get the best possible logon times. There are a huge amount of conversations to be had around the storage subject, particularly if you’re using Citrix Provisioning Services or Machine Creation Services, but the golden rule should be – the faster the better.

It’s beyond the scope of this article to actually do a deep-dive into the storage side of things, but there are a huge amount of great blogs out there from CTPs, CTAs and the Citrix user group community that can offer you excellent guidance on getting the best performance from your systems from a storage perspective.

A good point from fellow CTP Paul Stansel around storage – it’s not just the targets that can benefit from speedy storage, but your infrastructure as well. Moving DDCs, Storefront and SQL to more responsive storage can improve response times from the infrastructure and hence increase logon speed.

Group Policy

As I mentioned earlier, Group Policy is one of the areas that proves to hold the key to a lot of logon delays. User-level Group Policies are often quite extensive and apply a huge amount of customizations based on a wide variety of parameters.

Group Policy structuring

Most administrators are diligent about producing a “one GPO, one setting” relationship that looks very neat and tidy, like that shown in the image below. The beauty of this approach is that it makes troubleshooting very easy – simply disable the link to each GPO, retest, and it will soon be obvious which of your policy settings is causing problems.

Unfortunately – this isn’t the most efficient way of actually processing GPOs. Loading lots of settings into a single, monolithic policy object is more efficient when it comes to logon times. I know this is hideously annoying, because you can’t troubleshoot as effectively, but it is what it is. If you want the fastest possible logon times, then combine all GPOs for each OU into a single policy object.

I find this terrifically frustrating, so it’s important to balance out the adverse effects on your management capability against what you’re saving in logon times. In these cases, having a proper client monitoring tool that can measure each part of your logon process very precisely is incredibly vital (hence my mentioning of it in just about every presentation I give!) In most cases, you will probably find that grouping together large numbers of policy objects that are similar in operation can give you the best savings without trading off too heavily in administration overhead. For instance – put Microsoft Office settings all in one GPO, put browser settings in another, etc. The ratio of GPOs to settings is something that you will have to balance out to give yourself the best possible all-round experience.

This is a fairly simplistic view of what can be a very complex area of your environment, however, and dependent on how your GPOs are set up, balancing the functionality against the size is something that may need extra attention. For a very detailed dive into GPO processing and design, see this link.

Group Policy settings

In a similar sort of vein, it has for a long time been a common “best practice” for administrators to try and improve Group Policy processing by disabling Computer settings for GPOs that only contain User settings, and disabling User settings for GPOs that only contain Computer settings (as seen below).

Actually – performing this step not only doesn’t have any effect on overall processing time, making it a completely useless exercise, it also encourages administrators to split GPOs into “user-only” and “computer-only”, which actually increases logon times because (as per the section above), it increases the number of GPOs required. So this is a redundant setting – avoid using it, leave all GPOs set to Enabled. In general, I’d use this only for troubleshooting, which you will soon be glad of, especially if you implement the first GPO tip given above.

Group Policy filtering

Filtering can have a dramatic effect on GPO processing. You can filter in several ways – through standard Security Filtering, a WMI filter, or through Item-Level Targeting (specifically on Group Policy Preferences).

WMI filters can be the most harmful, as they can be written by the user and can contain many different queries. In general, try and keep WMI filters short and to the point, and especially avoid using LDAP queries, as these seem to be the most costly in terms of processing time. In my environments I try, wherever possible, to avoid WMI filters altogether, although this may not be possible for everyone.

Item-Level Targeting can also introduce delays into the logon process. Again, it depends somewhat upon the type of filter selected – my testing indicates that OU, LDAP Query, Domain, Site or Computer Group filters have the most overhead in processing time. Again, if possible I would try to avoid using ILT, although I acknowledge also that sometimes it isn’t possible to remove entirely.

Security Filtering has for a long time been the most efficient way of filtering GPOs because it generally uses user or security group membership, details of which are contained within the user’s local security token. However, for a few years now using Security Filtering by user or group also performs some execution in the computer context, meaning that the Domain Computers group also has to be specified on the security filter to allow it to be filtered by user or group. This change, made for security purposes, also makes processing slightly more inefficient, meaning that even this method of filtering comes with a slight overhead.

Ideally, it would be prudent to apply GPOs without filtering and apply them simply to the relevant OUs without any specific targeting. This would allow for the most efficient processing – but unfortunately very few environments are simple enough to allow this kind of direct targeting. Try and get your filtering as close to vanilla as possible.

GPO processing

Like using fast storage, I’m hoping everyone knows this one, but let’s revisit it for the sake of posterity. Whatever you do, don’t configure the GPO for “synchronous policy processing” and assign it. This will make all of your GPOs process synchronously and delay the logon until they’re finished. Don’t do it (the setting should ideally be Disabled as below)

However, if you’re using XenApp or RDSH on a Server operating system, also configure the GPO below to ensure that your system is running in asynchronous mode, as Server OSes run synchronous processing by default.

The reason that people often enable synchronous processing is normally to allow GPO Software Installation Policies or Folder Redirection to complete. GPO Installation Policies are archaic and should be avoided. Folder Redirection is another bugbear of mine, and is possibly something we should be looking to replace. I will touch more on that later, and then hopefully soon in a full article that describes more modern alternatives to Folder Redirection.

Logon scripts

Another in the “technology from the past” section, but again, one that you’d be surprised just how many people are still relying on for production systems. Logon scripts are by their very nature convoluted, linear, and messy, and we really should be moving away from them by now. If you don’t have access to Citrix Workspace Environment Management or a similar product, Group Policy Preferences can replicate most of the functionality you would typically have used your logon script for.

Since Server 2012, logon scripts don’t actually run at logon anyway, they run five minutes afterwards. This only applies to GPO logon scripts, however – logon scripts configured directly on the user object in Active Directory aren’t affected by this setting. If you want to get rid of the logon script delay, you need to configure the Logon Script Delay GPO and set it to 0. This is Microsoft kind of dropping you a hint that logon scripts suck and make your sessions perform poorly – get rid of those logon scripts!

Most logon scripts are concerned with drive mappings, printer mappings, folder redirection and the like. Printer mappings are slowly being replaced by “follow-me” print solutions in most enterprises. Drive mappings and Folder Redirection (as I’ve already mentioned!) I personally consider to be archaic, outdated methods of dealing with problems that we don’t really have any more. I am looking to do some articles on this in the next couple of weeks, but now is a good time to mention that if you’re going to get rid of a logon script that handles these things, then it might also be an ideal time to revisit the reasons you implemented them in the first place. Drive mappings in particular can have a drastic effect on logon time – I saw an example recently where an inaccessible set of DFS targets caused a seven minute timeout in the middle of a user logon.

Active Directory

AD underpins everything in your environment, and will have a big effect on not just your logons, but the performance of your entire infrastructure. Making sure that your AD is optimal is a surefire way to improve the entire environment.

Carl Webster did an excellent series of presentations on optimization of traditional AD back in 2012 and most of the points he made then stand the test of time. Some of the key takeaways are reproduced here:-

1. Check domain and forest functional levels
2. All DCs should be Global Catalog servers
3. Have no manually created Connection Objects in Sites and Services
4. Make sure all subnets are correctly defined in Sites and Services
5. Create reverse DNS lookup zones for all subnets
6. Remove orphaned DCs
7. Configure the PDCe to be the domain authoritative time server
8. Configure DNS correctly for all DCs

I believe that the most common mistakes I see are #4 and #8. Subnets not being correctly defined I see a lot. And people normally say “does it matter?” Well, if the authenticating session broadcasts for a domain controller and picks up one on the end of a slow connection in Uzbekistan or similarly remote place that just happens to be synchronizing at the time, maybe yes, it will matter. Once it hits that DC, it’s going to keep using it for policies and authentication.

Bad DNS configuration is also common. I saw recently a single Citrix server that because of a DNS misconfiguration on a particular DC, it could be contacted by the Desktop Delivery Controller but not the clients launching the app. And because no-one was on it, the DDC was constantly directing sessions towards it. Resolving the DNS issues sorted out all of the problems.

I have unashamedly stolen (with permission, naturally) Mr Webster’s diagram on DNS configuration for DCs for your reference.

If you’re embracing Azure AD or a more hybrid model, then you also need to make sure that your cloud infrastructure is in the best possible state as well.

Profiles

It sometimes seems all I talk about is user profiles 🙂 However, even though to vendors user settings and persona seem to be the last thing on their minds, the unescapable fact is that these things matter to users – and problems with the user profile can put an enormous dent in your logon times.

Profile types

As you all probably know there are three main Windows profile types – local, roaming, and mandatory (there’s also super-mandatory, but the difference is not relevant to this discussion). Roaming profiles are stored on the network, and will cause a huge drag on logon time if the profile is very large and/or contains many files. Local profiles (clue’s in the name) are stored locally to the device, and are typically very fast to load. Mandatory profiles are a read-only kind of roaming profile, although they can be stored locally to the device as well as on the network, and any changes made to them are discarded.

As far as logons are concerned, local profiles are your best bet. However, the trade-off that we then have is that we cannot retain user settings between sessions or in non-persistent situations – the profile is tied to the device where the user has logged on. To get around this, we have traditionally used third-party profile management solutions to handle the user settings, which are then injected into the user’s session in some way. Citrix User Profile Management, Ivanti User Workspace Management, LiquidWare Labs ProfileUnity, VMware UEM – there are a whole stable of technologies dedicated to handling this in various ways.

If you choose to adopt one of these technologies it’s up to you to tune it for the best possible logon time. I am in the process of writing an article that will discuss best practices for tuning UPM for logons, and there are many other resources out there covering all of the tools described above. Such tools can actually help you bring down the logon time, by offloading certain logon tasks until after the shell has actually started. But if they’re not configured correctly you can actually adversely affect the logon time, so be careful.

It seems sometimes that we are stuck in a bind with Citrix environments, that we can’t use local profiles because we want smooth roaming, and roaming profiles adversely affect our user experience too much. So we generally think down the third-party route, and then we have overheads of cost or maintenance or time involved in keeping them running smoothly. However, there is now a different option, one that gets the benefits of a local profile combined with centralization for roaming purposes. It is the “VHD mount” option, mapping the entire user profile to a mounted VHD that is stored on the network. It is addressed as a local profile, but is only a single file, and is in a centralized location so can easily roam settings between sessions. From a purpose of logon optimization, VHD mount is one of the best things you can do. It does require some tuning if you want to keep the storage requirements down (keep your eyes peeled for a co-operative article on this very subject sometime very soon), but nowhere near as much as the average third-party profile management tool. The drawback is that there is no cross-OS roaming of settings, but that is something that not every enterprise has as a requirement.

Microsoft have a feature called User Profile Disks (UPD) which will do the VHD mount for you, however it is single-session only so would only work if users were restricted to one session at a time. Ivanti User Workspace Manager and LiquidWare Labs ProfileDisk also have this capability, but currently the most flexible and feature-rich way to do the VHD mount is using FSLogix Profile Containers, which allows multi-session capability and can also replicate the profile stores and use a cached local copy by leveraging a feature called CloudCache. In my opinion, if you want to get the most efficient handling of a profile from a logon perspective but still have smooth roaming and centralized management, FSLogix Profile Containers is the way to go currently.

If you’re an environment that uses mandatory or super-mandatory profiles, often a cunning trick is to point the mandatory profile path to a local area rather than on the network, and simply update the mandatory profile from a central location using Group Policy Preferences. That way the profile is loaded from the local machine and isn’t dependent on network infrastructure.

Windows 10 and UWP app provisioning

If you’re doing Windows 10 XenDesktop or simply using Windows 10, then you might just be aware that there is a bottleneck on first logon caused by the provisioning of Microsoft’s UWP apps. This can escalate the first logon time to something like 4 minutes+, which isn’t acceptable at all.

I’ve written about how to remove these apps several times already so I don’t intend to do it again, but let me reiterate this point once more – REMOVING THE UWP APPS WILL HAVE THE MOST POSITIVE EFFECT ON A WINDOWS 10 LOGON TIME OUT OF ALL THE TIPS IN THIS ARTICLE. It will, in some cases, shave literally minutes from the logon time. Here’s a link to my article describing how to remove them. Also, don’t forget the points in this article about creating a custom Start Tiles layout once you’ve removed the apps – this will also reduce your logon time as it will no longer need to iterate through the entire DefaultLayouts.xml file, saving around another five to ten seconds from your logon time. If you’re on Windows 10, removing the built-in apps and configuring a LayoutModification.xml to replace the default Start Tiles will make an INCREDIBLE difference.

Custom default user profiles

The second biggest way to shave logon times (particularly on Windows 10) is by creating a custom default user profile, instead of using the one provided with the OS. Again, this is something I’ve written about previously so there’s no need to revisit the whole process here. It is important, though, to stress that most of the gain is made by strimming the profile down as specified in the last section of the article. You can also go a bit further than just the permissions changes and file deletions specified in the article if you want to make the profile even slicker:-

• Set permissions on Registry and filesystem (don’t forget to give All Application Packages Full Control)
• Remove Restricted group from ACL for Registry
• Remove any references to username or SID (use psgetsid) from the Registry file (load the ntuser.dat file from regedit.exe)
• Remove extraneous Registry keys and values

You can, should you wish, use the custom default profile to apply any global settings you would normally deploy via user GPOs (think desktop background, browser home page, etc.), thus saving the GPO processing time. However, if you wish to enforce these as policies, then you may need to use the GPOs to do so. If there are any global settings that you can enforce on a machine rather than a user level (sometimes settings have a corresponding value in HKLM which will be used if the HKCU value is not present – proxy server is a good example of this) then you can use these settings (enforced by Group Policy Preferences) to further reduce your requirement for GPOs.

I have also seen (mainly in environments where logon time is absolutely critical) people loading the custom default user profile with the actual Registry values that apply to particular global GPOs, ensuring that the GPO settings are preloaded, rather than having to be processed. Microsoft’s GPO spreadsheet lists the Registry values that apply to each GPO setting, so you can load them into the Registry as you build the default user profile and not have to rely on actual GPOs (just remember you need admin access to write these particular Registry values). This is extremely useful if you have settings that need to be applied to all users and are trying to get the logon time as fast as humanly possible, but the trade-off is that if you need to update or change these settings, you will need to open up the default profile and redeploy it (or you’re going to end up falling back on GPO processing).

Profile optimization

You need to keep a good eye on your profiles, no matter what tool you’re using, and adapt as necessary. More and more software I find is dropping large and unwieldy files or caches, particularly into the %LOCALAPPDATA% area. Ones to be aware of are OneNote, IE, Chrome, Teams, Slack, DropBox, OneDrive and the like, but you will likely find many more.

Stay tuned for an article dropping hopefully very soon about default profile exclusions which should hopefully help you keep them as trim as possible, no matter what method you’re using to manage them.

UserInit – Active Setup

Active Setup is a feature that will affect you if you are using full desktops, not published applications. It is, bluntly, a mechanism for executing commands once per user early during logon. Active Setup is used by some operating system components like Internet Explorer to set up an initial configuration for new users logging on for the first time. It is a way of hard-coding user-specific data.

Active Setup runs before the desktop appears. Commands started by Active Setup run synchronously, blocking the logon while they are executing. You can tell Active Setup is running when you see images like that shown below

Active Setup employs neither a timeout nor any other mechanism to determine if a StubPath process it started is still alive, so if it hangs, the entire logon will stop.

Active Setup looks for values called StubPath in the [GUID] subkeys under these two Registry keys –

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Active Setup\Installed Components

Any found will be executed at this stage of the logon process. Now, there are some StubPath entries that you may need, such as .Net components, but some of them are literally absolutely irrelevant to the modern world and I fail to understand why Microsoft have not removed them from Windows. Windows Mail is the one that springs to mind instantly. Also, other installed software (such as Google Chrome) may well insert its own StubPath entries here. An example of a StubPath entry is shown here

It’s worth noting here that because Active Setup runs after the application of Group Policy, I’ve seen instances where people have configured Registry settings and then found that Active Setup has overwritten them. I’m thinking specifically of the settings for Internet Explorer Enhanced Security Configuration, but there may be others as well.

When dealing with Active Setup entries, my approach is usually very aggressive – I delete as many of them as possible. However, it is important to assess whether there is any impact on any of your applications by removing them. I can’t see any, but I know I can’t speak to every application in existence. Ideally, if there is anything deployed by the StubPath entry that is required for application performance, then it would be prudent to capture it and deploy the settings in a different way – maybe even wrap the settings up into the default profile? But it definitely has a big impact on reducing logon times for desktop sessions if you remove as many of the Active Setup entries as you can. Deleting the StubPath entries will do the trick, but I find it more efficient to delete the [GUID] keys entirely.

Folder Redirection

I’ve got a detailed article in the pipeline about how to deal with Folder Redirection, but when talking specifically about logon performance, there are certain redirected folders that can cause particular issues. Desktop is the main one – having hundreds of files on the desktop has a detrimental effect on logon times. Recent Items is another, but this cannot be redirected through Group Policy any more – it can only be configured by tools such as Ivanti UWM, or through direct Registry manipulation. From the standard GPO redirections, only Desktop and to a lesser extent Start Menu have a detrimental effect on logon performance. It is recommended to not redirect either of these folders to gain the best possible logon times – ideally, I would wrap them up in a VHD mount using UPD or FSLogix.

Pre-boot

Particularly for Windows 10 XenDesktop, this will make a big difference to logon times, as this version of Windows presents the logon interface long before background processing has finished. If you hit a VDA when it is still in the “freshly booted” phase, you will experience a resource contention that has a detrimental effect on your logon time.

It is important to understand when your peak logon times are in order to ensure that enough machines are pre-booted ahead of the demand – at least ten minutes prior to logon will ensure that all processing is cleanly finished. You can pre-boot in many different ways – Citrix’s tools can do power management very easily, and you could even do it using Wake-On-LAN and SCCM. If you power up enough machines to meet demand at least ten minutes ahead of time, you will see a much better logon performance, most markedly if using Windows 10.

Automatic logon

In a similar sort of vein to pre-boot, there’s a very interesting observation I made recently when on-site with a client troubleshooting some logon time problems. Namely, that when you logged on to a Windows VDI session for the second time, the logon was fully two seconds faster than the first one after booting up. Now this isn’t anything to do with profiles or the like – the accounts we were using discarded their profiles, and I made absolutely sure that they were gone. But I tested this something like forty times off the belt, and it showed the same every time – two seconds faster for a second logon after bootup, rather than the first. It was nothing to do with the contention issues after boot either – I let the machine sit for an entire hour before logging on after it booted, and still the result was the same, a full two seconds faster second time around. I can only assume that the first logon loads some module or artefact into memory which then doesn’t need to be done again the second time.

So wouldn’t it be cool if, when you booted a machine up, it logged itself on automatically then logged out, allowing you to make sure that the first logon was actually a second logon? It can be done.

Create a user called autologon or similar. I used to create a local account and deploy it via Group Policy Preferences so it exists on every machine, but Microsoft removed this functionality from GPP, so you will have to do it another way. Putting it in the base image is easiest.

Configure a Startup Script for the machine that sets the Registry values that will enable automatic logon. The following would suffice

reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v DefaultUserName /d “autologon” /t REG_SZ /f
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v DefaultPassword /d 4utoLogon /t REG_SZ /f
reg add “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v AutoAdminLogon /d “1” /t REG_SZ /f

Once the Startup Script is applied, the machine will log on automatically for this user at boot.

Next, configure another script with the following code and store it somewhere on the machine

reg delete “HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon” /v DefaultPassword /f

logoff

Now, set up a Scheduled Task and set it to run in the context of the autologon user. Set it to be triggered when the autologon user logs on, and call the script you just wrote and stored on the local machine. Make sure the account running the task has “Log on as a batch job” rights – if you get error 2147943785, that’s the issue. You can configure the Scheduled Task through the GUI, via PowerShell, or through Group Policy Preferences – the choice is yours.

Also you need to make sure the autologon user has rights to edit the Winlogon Registry key. You can set this manually, or use a Group Policy Object to do it.

Now, when the machine boots up, the Startup Script will set the autologon. The user will log on, the logon will trigger the Scheduled Task, which will remove the password (disabling the autologon) and then log the user out. Hey presto – every first logon will now actually be a second logon, shaving another couple of seconds off your logon times.

If you’ve got non-persistent XenDesktop and they are set to reboot at logoff, obviously this won’t work very well, so you need to particularly consider in that situation if you are actually being affected by the issue that I observed. If you are then it makes sense to disable the reboot at logoff and implement this. If not, then it would be more prudent to disregard it.

(Worth mentioning here that fellow CTP George Spiers actually documented a very similar process to this and blogged it, which I only discovered after I’d started putting this together myself, rather annoyingly!) 🙂 A very good point raised in George’s article is the possibility of using SysInternals AutoLogon tool to set the Registry keys in the Startup Script, as this will encrypt the password rather than storing it in plain text.

Application pre-fetch

Of course, the upshot of finding that George had done the auto-logon and blogged it was that I found another cool tip in his article which brought my logon times down even further. It involves preloading a bunch of applications at startup, and then killing them off afterwards.

This does actually shave another second or so from your logon time, but I couldn’t explain why, until I presented on it at the Citrix User Group in London and Tim Mangan informed me it was most likely due to application pre-fetching. So to save even more logon time, create a script like this similar to George’s and load up your most commonly used applications.

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

Run this as a Startup Script or a Scheduled Task triggered at startup, and you will have even more benefits.

Firewall rules

Specific to Windows 10, this tip will again reduce contention at boot and therefore reduce logon times. Windows 10 appears to create firewall rules for each AppX application on a per-user basis. These rules are not removed when a user profile is deleted, and often contain large amounts of duplicates. At boot, Windows iterates through the firewall rules and can take a long time to parse them if there are a large number. One example I saw of this had over twenty thousand entries on an open-access computer. In order to get the best possible logon times, it makes sense to remove the rules.

Hat tip to Shaun Miller for tipping me off about this – here’s Shaun’s PowerShell to get rid of the defunct firewall entries as well 🙂 I typically run this as a Shutdown Script.

$UserProfiles = Get-CimInstance -ClassName Win32_UserProfile

$DefunctRules = Get-NetFirewallRule | Where-Object {$UserProfiles.Sid -notcontains $_.owner -and $_.Owner -ne $null}

Foreach($Rule In $DefunctRuleS.Name) {

    Remove-ItemProperty -Path “HKLM:\System\CurrentControlSet\Services\SharedAccess\Parameters\FirewallPolicy\FirewallRules” -Name $Rule -ErrorAction SilentlyContinue

}

Citrix virtual channels

Now, there is a school of thought that suggests disabling unneeded Citrix virtual channels will save you logon and reconnect time as well. Each Citrix virtual channel handles something different, and some of them may not be in use in your environment. For instance, if you’re not doing client drive or printer mappings, there is no conceivable need to use the virtual channels that enable this functionality.

You can disable specific virtual channels by editing the following Registry value on the connecting clients (not the actual target VDA, the client with the Receiver software on it)

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Citrix\ICA Client\Engine\Configuration\Advanced\Modules\ICA 3.0\VirtualDriver

The value is populated with comma-delimited entries, and you can remove the ones that you don’t actually need. You can also remove the files that are loaded by directly deleting the files beginning with “vd” from the C:\Program Files (x86)\Citrix\ICA Client folder. This may be necessary because sometimes there are virtual channel drivers from third party vendors that don’t appear listed in the Registry value. This article should provide a decent guide as to the functionality of each entry or file.

If you disable the maximum amount of entries in here, you can take about three seconds away from the Citrix logon or reconnect time. However, you will need to test this carefully in your environment in order to ensure that there is a tangible benefit that doesn’t affect functionality. It’s also a little hacky to be disabling some of the Receiver functionality in this way, and upgrades or patches may reverse it.

You can also disable virtual channels via Citrix policies, although I have not tested whether these will bring a similar logon gain.

Antivirus

Another huge drag not just on logon performance but on in-session performance is the use of antivirus and other intrusive security software. In an ideal world, we would get rid of reactive antivirus and replace it with something different, but regulatory requirements such as Cyber Essentials often make this a difficult sell to enterprises.

If you’re not able to remove the reliance on antivirus and replace it with a more modern approach, then scale it back as much as possible. Apply all the required exclusions. If possible, disable realtime monitoring and move to scheduled scans, preferably when the system is not under load. Perform the same recommended actions for all security software. Anything that hooks into processes should be investigated carefully to see if there is any impact on user logon times.

The whole debate about reactive antivirus and its place in a modern infrastructure is one for a different article which I will hopefully put together soon, but I prefer a robust approach based around newer Windows 10 security features like AppGuard and DeviceGuard, combined with application whitelisting technologies.

Scheduled Tasks

There are many, many Scheduled Tasks configured on Windows these days and some of them run at user logon. If you want to improve logon times, get rid of the ones that you don’t need. You may need to verify some of them, but I will warrant there are a good few that could do with being removed.

Autoruns

Grab the SysInternals tool AutoRuns and run it against your targets. Anything that’s running at user logon time that you don’t need, get it gone as well.

Some other tips

A few final bits and bobs you can do to further strim logons:-

Use the Citrix Optimizer! This excellent tool does all sorts of stuff that we’ve covered here already for you, as well as other cool stuff like pre-compiling .Net assemblies, disabling unneeded services, disabling NTFS access timestamps, etc. Running this on a golden or reference image will make a big difference not just to logons but all round performance for the user session. It’s worth noting that VMware also have an optimization tool that does a similar job, the VMware OS Optimization Tool (OSOT).

Use the BIS-F Framework! Another excellent tool, this one from Login Consultants, this is for image optimization but not just on the OS level, it also works on aspects of common installed software as well, and even does optimization of components like antivirus.

Defragmentation – is this still a thing? It sure can be…if your logon involves bringing data from remote shares (such as the user profile), then defragmenting the storage that they’re sat on can make a hell of a difference (thanks to Martin Zugec for reminding me about this)

Use Session Pre-Launch and Session Linger in your Citrix environments, where possible, if you’re using XenApp published apps. Even though this is technically cheating, what matters is user perception, and if this makes them think they’ve had a rapid logon, so be it 🙂

If you’re using Citrix User Profile Management, use the Profile Streaming option.

If you’re mapping or redirecting to networked SMB file shares during logon, make sure that the file shares are as upstream as possible with regard to SMB versions (for security, as well as performance).

If you’re using Citrix Director for your logon stats, set Registry value HKEY_CURRENT_USER\Software\Microsoft\Windows \CurrentVersion\Explorer\Serialize\StartupDelayInMSec to 0. It doesn’t make your logons any faster, but it makes Director report them as slightly faster 🙂

Check you haven’t got any Load Evaluators set via Citrix policy that are configured erroneously.

Validate your Citrix policies the same way as you would your standard AD GPOs.

Results

When I’ve applied all of these to my VDAs on Windows 10 XenDesktop and a Server 2016 published desktop, let’s see what sort of improvement we get…

Wow….97% increase on the XenDesktop instance, and 87% on XenApp….happy days, and happier users!

I’m pretty interested in keeping this maybe as a “live” article where I compile all of the tips and tricks for faster logons on Citrix, so please feel free to leave comments or send me a message on Twitter with anything you’ve found that makes the logon times even better.

More articles soon!