Déjà Vu and a Trip Down Memory Lane
About six years ago to the day, I was conducting my 20th career Infrastructure Assessment Project (IA) for a customer. As I began writing up the final deliverable, I experienced so
me serious déjà vu. It honestly felt like I was writing about the same risks for at least the 20th time!
That got me to thinking. Following our assessments, had our consulting team ever documented the common risks that we find? After some digging, I pulled up an ancient whitepaper on one of our Sydney file shares that was written by Hector Lima and Scott Thompson in 2001. Both still work at Citrix by the way and run our Consulting & Education and Support businesses, respectively! Their document was a little old and outdated. So, I decided to “refresh” their content by completely rewriting it. I documented the “Top 10 Items Found by Citrix Consulting on Assessments” back in 2008.
I published this as a whitepaper.
Earlier this year, my colleague, Andy Baker refreshed the same document again. The results (still Virtualization-focused) are published here.
Now that Citrix has Spread its Wings into the Mobility Space
I thought it was time to tackle a “XenMobile Edition.” To provide a bit of context, our Americas Consulting team has now conducted about 70 XME/Mobility engagements over the last 2 years. I oversee most of the Mobility projects across the GEO and almost all of the large or complex engagements we do. So, I dug up all the XM IAs we’ve done to date. And I put together the following list of the 10 most common risks or items we continually see customers design or implement incorrectly as it relates to XenMobile.
The XenMobile Top 10
10. AppC Service Account Permissions
Almost no one gets this right! This is probably due to the fact that we just published something official on this topic a couple months ago. This article outlines the permissions required for the AppC service account that we use for things like “delta sync” with AD.
9. Apple “Stuff”
You would be surprised how often we still run into issues related to Apple/Mac. I cannot think of a single XM engagement we’ve been on where we showed up and the customer said, “I’ve read all the pre-reqs you sent me.” Few have completed every one of them. Few can say, “Here is the Mac laptop with the latest MDX Toolkit we’ll use for wrapping.” Or, “We already have an Apple Developer license & I tracked down the corporate account we can use.” Few have started the APNS cert process. Honestly, if someone relayed these statements to me when we started a project, I wouldn’t believe them.
A lot of our customers are new to Mobility. They aren’t familiar with things like Apple licensing and APNS. We still run into IT shops that don’t have a MacBook (or similar) handy for app wrapping. This results in delays and a possible trip to BestBuy (Laugh if you must. This actually happened). So, it’s important to review the latest XM pre-reqs (published online) before you get started. Have an OSX-capable machine available for app wrapping . There are rumors of a web-based wrapping tool coming in the future (that I can neither confirm nor deny). For now, the MDX Toolkit that we use to wrap both iOS and Android apps requires OSX. Another big sticking point is that we’ve seen a number of admins create certs/profiles with their own personal Apple credentials. This is probably not the best long-term strategy for an enterprise. Once you start that way, it is difficult to go back. The one last thing I’ll mention here is; many customers are still unaware that we have a new portal for signing APNS CSRs. So, you can stop pinging your SE or opening a Support case for this!
8. LDAP High Availability.
AppC only allows for a single field when specifying an LDAP server. We have found that most customers do not specify an appropriate “VIP” for their LDAP services, creating a single point of failure. We recommend creating a VIP for your LDAP infrastructure if you don’t already have one and specifying the VIP when configuring AppC.
7. “Other” Mail Options.
It is amazing how few customers are aware of our “other” mail options besides WorxMail. Obviously, WorxMail is a key differentiator for us. It is the most secure option, so we always try to lead with it. But, this option might not be for everyone. We have found in some cases that XNC or XMM (our other mail options) work better for customers with specific use cases. Especially, when customers are dead-set on the experience of native email clients or leveraging a cloud-based email solution, such as O365. Don’t get me wrong – we end up deploying WorxMail probably 90% of the time. But, it’s not the only solution. Sometimes I see customers or partners trying to “force it” when other options are available.
6. SSL Offload.
It’s still somewhat controversial where to put XDM in the network (DMZ or internal) and whether to use SSL Offload for this component. But, even if you decide to put XDM in the DMZ rather than utilize SSL Offload for that component, you should still be leveraging SSL Offload for every other XME component! We find that once customers forego SSL Offload for XDM, they also aren’t configuring it for AppC and ShareFile (which they should be doing a large majority of the time for scalability).
5. AppC/XDM Integration.
I don’t think we’ve seen more than one or two customers get this right yet – most customers point AppC to the load balancer used for XDM enrollment, which in most cases resides in the DMZ and “hair-pins” the traffic out to the DMZ or external network and back in. If it were up to us, we would have a separate pair of internal load balancers for AppC to leverage when connecting to XDM and other services to prevent this hair-pinning and optimize network traffic.
4. WorxMail with STA.
If I was writing this article a year ago, I would have talked about how customers were still (mistakenly) using mVPN in conjunction with WorxMail (as opposed to the STA method). But, we hyped it up pretty good (myself included). So, most customers are using WorxMail with STA now. And, life is good. However, what we do see over and over again is customers mistakenly thinking that AppController (which is acting as the STA for XenMobile) can also be used for XenApp and XenDesktop. I repeat – AppC cannot be used as the STA for XA or XD – the AppC STA implementation is completely different and you still need to point your XA and XD deployments to an XML Broker (more than one for HA!), which has the STA encapsulated in the XML Service.
3. StoreFront Integration.
StoreFront is completely optional when deploying XenMobile (depending on what you need to aggregate and where). But, we often see customers scratching their heads after deciding to integrate StoreFront with their XenMobile deployment. They’re confused about subscriptions and NS session profiles. The first thing to note is: AppC and StoreFront have different subscription mechanisms and backend storage (They are not one in the same and the user experience could be inconsistent across different device platforms or Receiver versions). So, a little user education can go a long way here. Lately, I’m also seeing issues related to subscriptions where customers are still creating multiple StoreFront stores or even separate server groups for internal and external users. Again, people are wondering why their app subscriptions are not migrating seamlessly between everything. As my colleague, Sarah Steinhoff, pointed out in her awesome StoreFront series, it is probably best to have a single store (or two stores with the same name within the same server group) for all users or for each user community. And yes, this is different from the way we’ve been doing WI for the last decade (where we’d almost always create separate sites for internal and external). We made this problem kind of go away in v2.6 (since you can now share subscriptions between a couple stores). But, this solution is not meant for a large number of stores and it’s certainly not subscription replication. The key to remember is limit the number of stores on StoreFront – and AppC and StoreFront do not share a database. As for NS session profiles, we almost always find customers messing up at least one thing when integrating AppC, StoreFront and NetScaler. Or customers are blindly following the article that outlines how to do this configuration without understanding what they are actually doing and how that impacts their users.
2. NetScaler Firmware.
In my opinion, it’s understandable why we see this one a lot. Most of our customers still leverage the MPX “flavor” of NetScaler and have been running a specific firmware version on the box for a year, or sometimes more. But, if you’re deploying XenMobile, you’ll need to select from our list of XenMobile ‘certified’ firmware versions. You will notice that some have a “.e” at the end. This “e” stands for enhanced and it’s a special version of firmware that has XenMobile-specific features, such as wizards for ShareFile, proxy support, etc. Here is an example of the “120 e build” as we call it for NS 10.1. Don’t need any of those features for your XenMobile deployment? That is still a risk, since you are only officially supported by Citrix if you are running one of the listed builds! Because we do all our XenMobile testing with these special versions, it is really in your best interest to adopt the enhanced version for your XM deployment. And you know what easily solves this problem? SDX. So, maybe it’s time to upgrade. J
1. Authentication Strategy.
We come across this one all the time. But, I listed it as “#1″ because of its criticality. Far too often, we see customers choose a basic authentication strategy (such as WorxPIN without certs or two-factor authentication) and roll out their first 100 or 1000 devices. Then, they decide they want to enable cert-based auth or add two-factor authentication for additional security. But, they do not understand the ramifications of altering their authentication strategy post-rollout. The ramification is what I want to highlight – changes like these to authentication strategy require re-enrollment.
Yeah, the dreaded “R” word! The one that no one wants to talk about. The one I hope never comes up for you. Because, re-enrollment could mean disaster for user adoption. We really want to avoid it at all costs.
So, it’s absolutely critical that you do a proper design and really think about your future-state authentication strategy. And, that you try to implement it before you even enroll that first device. You’ll be a lot better off in the long-run and it will greatly increase your chances of wide-scale adoption. This is also a good reason to avoid migrating your XME POC environment into production. Which, we are also seeing way too much of lately.
Special thanks to Ryan McClure and RaghuG for their input to this article. I hope you find this useful in your travels.
Nick Rintalan, Lead Architect, Americas Consulting, Citrix Consulting
