Background
It seems a week go without someone asking how to improve battery life in our son internal media - and most of these requests relate to WorxMail and our mobility products. And one of the first things myself or someone from the product team could ask the interviewer is: " Do you use Micro-VPN (mVPN) or the new method STA with WorxMail? Because we strongly recommend the STA method with WorxMail now! "in this article I will try to explain what this" new "STA method is, why there is nothing new, why it is better than mVPN in terms of battery life and how to configure the STA method WorxMail. I think also follow this article with a "battery life" article more general, because it seems there are a lot of questions around this topic. If you are interested in that, please leave me a comment and let me know.
CVPN mVPN vs. vs. STA
Before we dive right into this new method STA, back in back and talk about what mVPN is and why it was not good for WorxMail. Why do we even need mVPN or STA in the first place? well, in a word, we have devices "unreliable" of mobile and internal services that we need access to ... and we need a secure method to access these internal resources of these unapproved devices. (internal resources could be an MDM server, XenApp published application, internal Web site or an Exchange server to name a few.) So it's all about access, authorization and authentication. And based on the different resources we need access, we have different access methods. And the options are good because these internal resources could have "profiles" - meaning that some are static and do not require constant authentication (CAS or an Exchange server is a good example). And some are very dynamic and may require a constant or frequent re-authentication auths (maybe different internal Web sites). So it makes no sense to connect to these internal resources that have different profiles with the same method every time. CVPN might be the best way to access internal sites. mVPN might be better to reach a mobile application that you use only for a minute or two. But what happens if we have access to an internal resource for a long time? And this internal resource does not change (in terms of hostname or IP)? And we do not want to re-authenticate every day? And we want the best battery life? That's where this "new" method STA comes in.
What's old is new!
I put "new" in quotes because the STA method is really nothing new. If you are familiar with XenApp or XenDesktop or you've been around a while Citrix, you probably know and like Secure Ticket Authority (STA). In fact, it used to be very clean server back in the day when I walked Citrix! But by 05, we focused STA service and the XML Service to "inside". So wherever you have an XML service running (XA each box), you can point to it and also call your STA server. Fast forward to today - let's say you do not have XA or XD in the picture - you are just implementing XenMobile. Can I use the STA method? What point you in a world without XM XA / XD? Well, before last few months, you really could not use the STA method with XenMobile or WorxMail - you were basically forced to use mVPN. And that meant a little unpleasant user experience because users have been authenticated more they wanted ... the mVPN was mainly due 24/7 and the battery life kind incurred as a result (I could do another article on mVPN to explain why that is). If you were an early adopter or XenMobile @WorkMail, you probably know what I mean. So we need a better way to support a longer connection to WorxMail specifically - if we have benefited mainly the nuts and bolts of the STA method - SOCKS5
APPC is an STA
SOCKS has been around a long time - and this is really what is at work when we use the method STA. We are only CAS proxying TCP connections or internal Exchange servers via SOCKS5 - simple as that. It is a protocol that has always been there and it is very flexible in that it is scalable and virtually transparent to the end user. And what do we emphasize as STA in a world XM? From App Controller version 2.8 released just a few months ago, APPC can now act as a Secure Ticket Authority! Is it the same exact implementation XA / XD? Not exactly, but the concept is the same. In this implementation STA for XM / APPC, it is specially designed for WorxMail. So what is the first important thing to understand - we still have to use other means as CVPN mVPN or when using non-WorxMail applications. Other applications could possibly work with STA? Perhaps, but we do not test and I doubt that we support. So just stick to this new method with STA WorxMail until you hear otherwise.
APPC STA vs. XA / XD STA
Learn more about the APPC application STA - we essentially have a "ticket table" that lives on the AppController. And in this table is where we keep track of STA tickets and that users and devices have access to which internal resources (mainly Exchange hosts in this case). And we keep these notes in this magic picture, so we can use them again for subsequent validation even if the device comes in This is different from the implementation XA / XD STA -. Tickets are only valid once and we destroy them after. We do not keep around and save them for later, like APPC.
How to configure STA w / WorxMail
So this is very good - STA is the answer for WorxMail because it supports connections long life and gives us a better battery life compared to mVPN. But how to set up? It's pretty simple. There are 2 parts:
1. Define the APPC as STA on NetScaler gateway.
2. Set MDX appropriate strategies within the WorxMail APPC application.
To accomplish the first, just add the APPC as STA as you normally would for XA / XD. Just use the FQDN - you should add something like "/Scripts/CtxSta.dll". There is also an option to set the APPC as STA in the GUI on the new versions of NetScaler 10.1 (second screenshot below). But here's a screenshot showing how to define the NS:
To achieve the latter, you need to set some special settings in WorxMail the application. So either while setting WorxMail for the first time or changing thereafter, you must set some MDX policies. These MDX or political parameters "special" and unique to WorxMail exposed through the last box MDX tools. The first is " basic network service s" - this should be the FQDN of your CAS server / Exchange with a colon and the port say. "Cas.mycompany.com:443" is the second. " the back-end services post . "- this indicates how long the STA ticket is good for this table STA tickets on APPC I mentioned earlier default is 7 days (and can 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 experience of desired user and the latest MDX policy is " network service gateway Background ." - this should be the FQDN of your NS AG VIP or say "ag_vip.mycompany.com" Here is a screenshot.. to show the MDX policies which I speak in WorxMail (and here's a link to a eDocs page that explains the specific MDX policies a bit better than I probably just did):
impact on battery life and Wrap-Up
and here - once you have set the APPC as STA on NetScaler and configured MDX these policies within the WorxMail application WorxMail will use the STA method. You will not be "bothered" to auth whenever you choose based on the value of the ticket expires ... and your battery life will significantly improve the use of WorxMail for a long period of time. How dramatic? You're mileage will vary, but based on my personal tests with a GS3 (where I get about 16 hours of battery life per day with my native email client), I am now happy to announce that I get about 14 hours of battery life from one day to the STA method and the latest WorxMail. Compared to mVPN and an older version of @ Workmail / WorxMail I was only receives about 10 hours. So it is definitely important and can really make a difference, especially on the Android platform. Battery life should be better if you use mVPN on iOS because of the way we have implemented mVPN on iOS (very different from Android), but we always recommend using STA across the board for WorxMail to achieve the best battery life.
one of my colleagues, Albert Alvarez, created a video that shows how to configure WorxMail done with STA, so I'll add the link to this article once it has been edited and uploaded to the CitrixTV ( UPDATE: This is the link to the video) !. But I hope this helps to explain the difference between STA and mVPN why we want to use STA with WorxMail and how to actually set on NS and APPC.
Maybe next time we'll talk about our MVPN implementations on Android and iOS, and the battery life in general. Feel free to leave me a comment if you found this article useful or want to learn more about these topics related to mobility.
Cheers, Nick
Nick Rintalan, Lead Architect, Citrix Consulting
0 Komentar