Hello everyone,

I’ve finally decided to start blogging and hope you will enjoy my posts. In my first blog post, I would like to talk about how you can improve your logon times and describe few advanced techniques.

It’s all about users

A lot of people are forgetting this fundamental rule – virtual desktops are all about your end users. You can have great infrastructure, but if your users are not satisfied, you won’t be successful.

When your users are complaining about performance, most of the administrators\consultants will start looking at some metrics – while this approach is often valid, you shouldn’t underestimate the easiest method how to find the problem – simply ask your users why do they complain. It may sound like obvious thing to do, but you would be surprised how many times this step is skipped and we dive into sizing, memory, IOPS…

In general, I like to look at performance from two different aspects (from the end user perspective) – how long does it take to get access to the environment and how is the performance while they are working. Especially for XenApp, users are mostly not satisfied with the time it takes before they get their application – they don’t understand that their session needs to be created before they can run the application.

Cheat, cheat, cheat!

Human mind can be very tricky – for example I had customer that decided to deliver applications using XenApp. First they’ve migrated small group of users (pilot) and they started tuning the environment with these users. Soon, they started to receive complains from the end users about performance of these applications. The catch? Users that were complaining were not migrated yet and were still using locally installed applications.

You can use this for your own advantage. There are two different aspects that should be measured – real performance (the one that you can measure) and “perceived” performance. Think about any modern smartphone platform – it’s not as fast as it appears, it’s just the feeling. Instead of freezing your screen for few milliseconds, asynchronous animation is performed to let you know that something is happening. This concept of perceived performance is very important to understand and keep in mind.

You can use this to your advantage though – while this trick is very simple, you would be surprised how successful it can be. Simply inform your users about what is going on. Most of the logon scripts I’ve seen in past few years are based either on .cmd, or .vbs. CMD scripts usually looks like this:

Bad user experience

Do you think your users are really going appreciate your scripting skills?

VBScripts usually looks like this (that’s correct – users don’t see anything):

Simple add some verbosity to your scripts – easy way is to use @Echo Off together with some user friendly messages and colors:

Good user experience

Or even better, implement some sort of progress bar:

Progress bar
Ok, maybe you don’t agree with me on my previous point and measurable performance is the only one you really care about. Can I share something with you that could help you out?

Typically, you want to use logon scripts to solve two different problems

  1. You want to personalize workspace for user
  2. You need to apply some dynamic settings

Don’t use logon scripts

Yes, that’s correct. Most of the logon scripts I’ve seen are used to map network drives, map network printers and apply some changes to the registry or ini files – you simply want to personalize workspace for current user. You don’t need to use logon scripts to achieve this functionality – much easier solution is to use Group Policy Preferences.

I’m still surprised that many people have never heard of group policy preferences. This functionality is based on PolicyMaker product from company called DesktopStandard (acquired in 2005 by Microsoft). I used their products many years ago (2002\2003) and guess why? I wanted to get rid of logon scripts (even though I love scripting).

Group Policy Preferences allows you to configure users workspace without writing a single line of code. As an added bonus, you can even specify if you want to apply it once (default settings) or you want to enforce it, you can create complex filters…

Ask yourself a question please – do you really, really need to use a logon scripts?

Computers are patient – users are not

Maybe you’ve answered “yes” to my last question – maybe you just need to keep some configuration dynamic and want to change it whenever user logs on to the machine. Many of these settings however are not specific to the user – they are specific for the workstation. For example you need to modify an ini file to contain computer name.

Usually, you can reduce the logon scripts by moving their functionality to either startup scripts or sealing scripts (scripts that are running whenever you update your master image). Your priority should be the end user experience – I was rather slow down the startup time than logon time. If startup takes 30 minutes longer, but user logon time is decreased by 30 seconds, it’s improvement (well, depends :)).

Use Pre-Launch\Lingering

Consider using Pre-Launch\Lingering if possible – when properly implemented, you don’t need to worry about logon times (well, not as much as without these policies).

The benefits of Pre-Launch\Lingering are also hard to measure – it highly depends on the usage patterns. For example user A opens Outlook early in the morning (and takes the coffee while it is starting) and keeps it opened the whole day (and the rest of his applications are on the same server). User B is going through the folder and opens documents one by one – he will open .doc, read it, close it, find another one, open it, read it…

User A wouldn’t really benefit from pre-launch\lingering, while the situation would be completely different for user B.

Pre-Launch\Lingering requires proper design though – I highly recommend to involve Citrix Consulting to properly design this solution.

Properly design your profile

This one is VERY easy – Dan Allen has actually done all the work for me already 🙂 I personally prefer white listing for profiles (disable by default, roam only specified settings) – which this approach is much harder to manage, it got great impact on stability (and amount of helpdesk calls). If you roam\redirect only some of the settings, your users will quickly realize that simple logoff\logon can solve most of their problems.

Group Policy optimization

You will hear a lot of different theories about GPO optimization – I don’t think it’s possible to simplify such complex technology into few universal recommendations… The one and only recommendation I’ve heard over and over again is that your logon time will increase if you use too many policies. This is never ending discussion about monolithic versus functional GPOs. If you understand how GPOs are being processed, then it’s obvious that there is no simple answer.

My personal best practices:
  1. Keep amount of settings (NOT GPO objects) to the minimum – you want to use GPO to simplify your management, not to make it a nightmare
  2. Properly design your AD structure – if you’ve structured your OUs well, you don’t need to use ACL\WMI filtering
  3. Disable what you don’t need (computer vs user policy) – while in theory it shouldn’t matter (computer and user policy settings are NOT process synchronously, but are executed on two separate threads), I still keep this best practice. Call me old fashioned.
  4. Don’t spend too much time thinking about theory – since Windows Vista\2008, we’ve got all the information we need to actually measure the performance. GP operational log (Applications and Services Logs\Microsoft\Windows\Group Policy\Operational) is great source of information

GPO processing is a science – and I really mean it. If you want to understand more, I highly recommend following blog post.

Hope you have enjoyed my first blog post.

Martin Zugec