Before we get too far in, you may be wondering how this article is going to be any different than a few of the other articles that are out there on XenMobile timeouts.

Fair question and I’m glad you asked!

Articles like this one that explain how the various NetScaler/MDX timeouts work and this one by my colleague Albert on how the inactivity timer works have been around for a while. This article also starts to get into it.

In my (admittedly biased) opinion, they do a great job of just that; explaining what each timeout does and where it is configured. If you haven’t read those articles yet, now is the time. To answer the question we started with, I’m not going to try to explain how these timeouts work. You already know that because you already read those articles, right?

Instead, we are going to focus on WHY we would configure them one way or another to get the balance between user experience and security that we are after.

DISCLAIMER: The values we are going to discuss are meant as examples and starting points. Every environment is unique and has different security requirements. You may need to adjust these values based on environment specific use cases and security requirements and (of course) you should TEST any configuration changes in a non-production environment prior to production implementation.

Now, on to the good stuff. Let’s forget about the timeouts for a second and look at an example of the desired user experience. After all, these timeouts only exist to tune user experience with security in mind (or to enforce security lockdowns with user experience in mind – depending on who you ask :)).

EXAMPLE: “I want my users to leverage WorxMail to have as seamless an email experience as possible. My security guy said that if they don’t use their enterprise apps for 15 minutes, we want them prompted for some kind of credential, so let’s do that. I want to allow offline access to the stuff that makes sense, but not forever, just for the ‘right’ amount of time. I don’t really care what happens to my users authentication-wise when they want to access the WorxStore. They don’t go there all that often day to day. Oh, and WorxWeb, that’s big for us. When a user opens it, I definitely want that to be easy for them. Last thing. When we push updates to policies and apps, I also don’t want it to be more than a business day before that propagates to our end-users to keep things manageable.”

Believe it or not, out of just that short ‘conversation’ we have most of what we need to start making decisions. From that information, we probably would end up landing on something like the following (and no, no dart throwing was involved):

App Passcode: On

Online Session Required: Off

Inactivity Timer: 15 minutes

Max Offline Period: 8 hours

Background Services Ticket Expiration (WorxMail): > 8 hours

NetScaler Session Timeout: > 480 minutes (8 hours)

NetScaler Forced Timeout: N/A

So, how did we come up with these values?

Let’s break it down. First, the ‘customer’ asked for a WorxMail experience that is as seamless as possible. To do this, we want our ‘background services ticket expiration’ value to be greater than (or at least equal to) our ‘max offline period.’ The reason is that when the max offline period expires, the user is forced to perform an ‘online authentication’ against the NetScaler Gateway. This renews both their STA (background services) ticket and the NetScaler session cookie. As long as the user has a valid STA ticket, they should be getting email. PS, if you are not familiar with WorxMail and STA, this is a must-read.

That still doesn’t answer how we landed on 8 hours for the ‘max offline period,’ so how did we get to that?

Well, there were three parts to that. We wanted to allow offline access for ‘just the right amount of time.’ That is about as subjective as data comes, but not when you apply it to what a mobile user might be doing. I fly a lot. That is when offline time is critical to me. When I am on the plane I want to be able to read email I already downloaded, look at cached browser pages, take notes, etc. even if my flight doesn’t have WiFi. But most domestic flights aren’t 8 hours long, and I promised we didn’t throw darts to come up with these numbers. We landed on 8 hours because ‘when we push app and policy updates we don’t want it to be more than a business day’ before that change hits the end user. Around 8 hours is a pretty typical business day, and online logon (forced when the max offline period expires) is what triggers WorxHome to check in with the backend to see if there are MDX policy updates and/or application updates.

Now on to the NetScaler session timeout. For those of us that are fans of the wizard (myself included), we are focused on the _OS and _WB session policies/profiles it creates. We actually already covered this one above. We want this value to be greater than or equal to the max offline period because as long as I have a valid NetScaler session, my WorxWeb (or any other app using mVPN) experience should be relatively seamless. I may be prompted for a credential based on inactivity, but once I am through that, off I go. We don’t want to make the session timeout unnecessary large because it can have memory consumption ramifications on the NetScaler side.

At this point, all that is left to the imagination is the forced timeout. In a high-security environment where we want to terminate active NetScaler session at a specific interval, this setting is very useful. In your average deployment on the other hand, it is a setting that is commonly forgotten when making adjustments and can add complexity that is often not necessary.

Last, but not least, the ‘app passcode’ setting is really what determines if MDX timeout settings such as inactivity timer apply to the specific app in question.

So something like the above is where our ‘balanced’ customers usually land. We would at least be in the ballpark. But what about the ends of the spectrum? We have some customers that are extremely security conscious and others that are 100% drive by the user experience. Here are two examples of how those policies might look. The decision points would be no different than those we reviewed before, the input data just changes.

Security driven:

App Passcode: On

Online Session Required: Off

Inactivity Timer: 10 minutes

Max Offline Period: 1 hour

Background Services Ticket Expiration (WorxMail): > 1 hour

NetScaler Session Timeout: > 60 minutes (1 hour)

NetScaler Forced Timeout: 60 minutes (1 hour)

Workflow driven:

App Passcode: Off

Online Session Required: Off

Inactivity Timer: N/A

Max Offline Period: 168 hours

Background Services Ticket Expiration (WorxMail): > 168 hours (7 days)

NetScaler Session Timeout: > 10080 minutes (7 days)

NetScaler Forced Timeout: N/A

In summary, there really is no right or wrong answer when it comes to how these settings should be tuned. We want to be sure that the max offline period is shorter than the background services timeout and the NetScaler Gateway session timeout. We also want to be sure we map the timeouts to user experience demands, administrative needs and security requirements. From there, a few testing and feedback iterations should put you right where you want to be with a predictable and consistent user experience.

If you have any questions or want to share timeout settings that have worked for you, feel free to drop me a note below. Happy mobilizing.

Ryan McClure
Architect | Citrix Consulting