RG00E – Analyzing logontime SLA with Workspace Manager

By Max Ranzau


One of the most overlooked, yet very cool features of Workspace Manager, is tucked away in the console. It is the ability to analyze user logon time. This is a big deal for many IT departments where SLA’s (Service Level Agreements) are in place. Workspace Manager is actually recording some very nice statistics for you as soon as you start letting users in. All you have to do is to go and get them. Here’s a sneakpeak of the info you can obtain:

Scr, AB, Stats

A little backgrounder in how it works: In order to get things working, you have to make sure that Access Balancing is switched on, found in the Performance Management node of the RES console is switched on. It should be on per default. It would look something like this:

Scr, Access Balancing config

To get to the stats, you have to make your way into Performance Management | Access Balancing | Log (tab). In here you need to remove this checkmark:

Scr, Access Bal, log

When you remove the Show Access Balancing events only, the statistics will be calculated on the background of regular logons, not just the ones which triggered Access Balancing to queue the user. This is what we want in this case. Per default, Access Balancing will only query the last 100 records logins This is to speed up things in the console, but may leave you with statistics a tad too granular for your taste. By removing the checkmark for Show last 100 entries only, you will get statistics for ALL recorded logins. If you have a big environment, it may take a little while to crunch those numbers.

In order to better understand what we’re dealing with here, let’s have a closer look at this feature in Workspace Manager: Access Balancing is essentially a Logon-throttle, meaning it regulates how many users can get a session at the same time. Contrary to common misconception this is not a limit on the number of max logons. Access Balancing was originally implemented for use on terminal/citrix servers, where the throtteling would make sense.

A quick example on the throtteling: Let’s say you’ve got 3 Citrix servers set up for load balancing an app or a desktop. All of a sudden either in the morning or after lunchbreak the farm is hit by 30 users who log on within a short interval. While the Citrix load evaluators will do a nice job of distributing the incoming session requests among the 3 servers, it does not change the fact that each of the 3 servers will have to deal with 10 almost concurrent sessions. This is not good for the users who may experience extended logon time, nor for the users who may already be logged on. Let’s face it. 10 concurrent authentications, profile loads, session configuration etc. may take it’s toll on any piece of steel we have in the datacenter.

So what does access balancing do about it? Well quite simply it informs the user; “Hi there, there’s currently a queue of N people in front of you to get in”. The number N will count down and the user will proceed to his session.  The message they get will look a bit like this:


Much nicer for the user than just sitting and looking at a stupid hourglass, agree? Let’s just have a look again at the statistics counters, which we’ll go through in detail below.

Scr, AB, Stats

Average queue length will tell you if people on a regular basis are facing a bottleneck at logon, induced by Access Balancing. ideally this should be zero, but don’t freak out if it goes up during peak hours – that’s what it’s there for in the first place. If it’s larger than one permanently, chances are either you’ve set the Maximum allowed simultanious logons (as described above) threshold too low, or you may have too few servers to service your users. Maximum queue length specifies the length of the longest queue any user has had to endure so far. Average delay specifies how long (in minutes:seconds) the users was held in the queue. Maximum delay is the longest time a user had to wait in the queue. Average logon duration specifies how long the entire logon process takes, whereas maximum logon duration will tell you about the longest login time anybody has encountered so far. Bear in mind, logon time is recorded from the time Workspace Manager starts. Besides be advised that currently (in Workspace Manager 2008 SR3) the timer stops just before User Preferences are applied, so that does not count as a part of the logintime. # of logons will tell you something about the quality of the stats you’re looking at. The more measuring points, the better statistics. Out of the number of logons # of Access Balancing events is how many times that the queuing mechanism was tripped.  The # of desktop sessions and # of published application sessions tells us the ratio between logins to desktops and published applications.  If you have both access methods enabled, this will tell you what’s being used most by the users. Finally the counter # of exits will tell us how many times the users go “Bah! I’m not going to wait for this, lemme outta here!”. It’s an important indicator of either your queues being too long, or simply the users have no clue what’s going on and just need to click something to feel a bit happier. Either way you need to do something about it.

A final note on access balancing, when you view the log, remember you can sort on the columns, meaning it is very easy to find out who’s had the longest logon time (click the bitmap below to see the fullsize screenshot)


1 Comment

  • By Fred Klomp, September 26, 2012 @ 07:14

    This week I investigated an issue regarding the reported logon duration. In the latest version of RES Workspace Manager the time reported in the column is not accurate and this will be solved in a fixpack based RES Workspace Manager 2012 SR1.

Other Links to this Post

RSS feed for comments on this post.

Leave a comment

You must be logged in to post a comment.