It seems a week doesn’t go by without someone asking how to improve battery life in our internal support threads – and most of these inquires are related to WorxMail and our Mobility products. And one of the first things that either myself or someone from the Product team might ask the inquirer is: “Are you using Micro-VPN (mVPN) or the new STA method with WorxMail? Because we highly recommend the STA method with WorxMail now!” In this article, I’m going to attempt to explain what this “new” STA method is, why it’s nothing new, why it’s better than mVPN in terms of battery life and how to configure the STA method for WorxMail. I’m also thinking of following-up this article with a more general “battery life” article since it seems there are lots of questions around this topic. If you’re interested in that, please drop me a comment and let me know.
CVPN vs. mVPN vs. STA
Before we dive right into this new STA method, let’s back up and talk about what mVPN is and why it wasn’t the right fit for WorxMail. Why do we even need mVPN or STA in the first place? Well, in a nutshell, we have “untrusted” mobile devices and internal services that we need access to…and we need a secure method of accessing those internal resources from these untrusted devices. (Internal resources might be an MDM server, XenApp published app, internal website or Exchange server to name a few.) So it’s all about access, authorization and authentication. And based on the different resources that we need access to, we have different methods of gaining access. And options are a good thing since these internal resources might have different “profiles” – meaning that some are static or don’t require constant authentication (a CAS or Exchange server is a good example). And some are very dynamic or might require constant authentication or frequent re-auths (maybe different internal web sites). So it doesn’t make sense to connect to these different internal resources that have different profiles with the same method every time. CVPN might be the best method for accessing internal websites. mVPN might be best for accessing a mobile app that you only use for a minute or two. But what happens if we need access to an internal resource for a long time? And that internal resource is not changing (in terms of hostname or IP)? And we don’t want to re-authenticate every day? And we want the best battery life? That is where this “new” STA method comes in.
What’s Old is New!
I have been putting “new” in quotes because the STA method is really nothing new. If you’re familiar with XenApp or XenDesktop or you’ve been around Citrix a while, you probably know and love the Secure Ticket Authority (STA). It actually used to be it’s very own server back in the day when I joined Citrix! But then circa 2005, we ported the STA service and put it “inside” the XML service. So wherever you had an XML Service running (every XA box), you could point to it and also call that your STA server. Fast-forward to today – let’s say you don’t have XA or XD in the picture – you’re just implementing XenMobile. Can we use the STA method? What do you point to in a XM world without XA/XD? Well, before a few months ago, you actually couldn’t use the STA method with XenMobile or WorxMail – you were essentially forced to use mVPN. And that meant a somewhat unfriendly user experience since users were authenticating more than they wanted to…the mVPN was essentially connected 24/7 and battery life sort of suffered as a result (I might do another article on mVPN to explain why that is). If you were an early adopter of XenMobile or @WorkMail, you probably know what I’m talking about. So we needed a better method of supporting a longer-lived connection for WorxMail specifically – so we essentially leveraged the nuts and bolts of the STA method – SOCKS5!
AppC is an STA!
SOCKS has been around for a long time – and this is really what’s at work when we are using the STA method. We’re just proxying TCP connections to internal CAS or Exchange servers via SOCKS5 – simple as that. It’s a protocol that has been around forever and it’s very flexible in that it’s scalable and virtually transparent to the end-user. And what do we point to as an STA in a XM world? Starting with App Controller version 2.8 released a few months ago, AppC can now act as a Secure Ticket Authority! Is it the exact same implementation as XA/XD? Not exactly, but the concept is the same. In this implementation of STA for XM/AppC, it’s specially designed for WorxMail. So that’s the first important thing to understand – we still have to use other means like CVPN or mVPN when using non-WorxMail apps. Could other apps possibly work with STA? Maybe, but we don’t test it and I doubt we support it. So just stick to this new STA method with WorxMail until you hear otherwise.
AppC STA vs. XA/XD STA
More about the AppC STA implementation – we basically have a “ticket table” that lives on the AppController. And in that table is where we keep track of the STA tickets and which users and devices have access to which internal resources (mainly Exchange hosts in this case). And we keep those tickets in this magic table, so we can use them again for validation later if the same device comes in. This is different than the XA/XD STA implementation – tickets are only valid once and we destroy them afterwards. We don’t keep them around and save them for later, like on AppC.
How to Configure STA w/ WorxMail
So this is all very good – STA is the answer for WorxMail since it supports long-lived connections and gives us better battery life compared to mVPN. But how do we configure it? It’s pretty simple. There are 2 parts:
1. Define the AppC as an STA on the NetScaler Gateway.
2. Configure the appropriate MDX policies within the WorxMail app on AppC.
To accomplish the first, simply add the AppC as an STA like you normally would for XA/XD. Just use the FQDN – you don’t need to append anything like “/Scripts/CtxSta.dll”. There is also an option to define the AppC as an STA in the GUI on the newer versions of NetScaler 10.1 (second screenshot below). But here is a screenshot showing how to define it on NS:
To accomplish the second, you need to define a few special parameters within the WorxMail app. So either while you’re setting up WorxMail for the first time or editing it afterwards, you need to define a few MDX policies. These “special” MDX policies or parameters are unique to WorxMail and exposed via the latest MDX Toolkit. The first is “Background network services” – this should be the FQDN of your CAS/Exchange server with a colon and port. i.e. “cas.mycompany.com:443″. The second is “Background services ticket expiration” – this specifies how long the STA ticket is good for in that STA ticket table on AppC I mentioned earlier. The default value is 7 days (and may be specified in hours depending on the platform, so you might need to do some math). You can increase or decrease depending on your security requirements and desired user experience. And the last MDX policy is “Background network service gateway” – this should be the FQDN of your NS or AG VIP. i.e. “ag_vip.mycompany.com”. Here is a screenshot to show the MDX policies I am talking about within WorxMail (and here is a link to an eDocs page that explains these specific MDX policies a little better than I probably just did):
Impact on Battery Life and Wrap-Up
And that’s it – once you’ve defined the AppC as an STA on NetScaler and configured those MDX policies within the WorxMail app, WorxMail will leverage the STA method. You will only be “bugged” for auth whenever you choose based on that ticket expiration value…and your battery life should dramatically improve when using WorxMail for a long period of time. How dramatic? You’re mileage will vary, but based on my personal testing with a GS3 (where I get about 16 hours of battery life a day with my native email client), I am now happy to report I get about 14 hours of battery life a day with the STA method and the latest version of WorxMail. Compared to mVPN and an older version of @WorkMail/WorxMail, I was only getting about 10 hours. So it’s certainly significant and can really make a difference, especially on the Android platform. Battery life should be better if you’re using mVPN on iOS due to how we’ve implemented mVPN on iOS (much different than Android), but we still recommend using STA across the board for WorxMail to achieve the best battery life.
One of my colleagues, Albert Alvarez, has created a video that actually demonstrates how to configure WorxMail with STA, so I’ll add the link to this article once he’s done editing it and has it uploaded to CitrixTV (UPDATE: Here is the link to the video!). But I hope that helps explain the difference between mVPN and STA, why we want to use STA with WorxMail and how to actually configure it on NS and AppC.
Maybe next time we’ll talk more about our mVPN implementations on Android and iOS, and battery life in general. Feel free to drop me a comment if you found this article useful or want to hear more about these mobility-related topics.
Nick Rintalan, Lead Architect, Citrix Consulting