One of the first questions that seems to come up when we are helping customers get going with XenMobile AppController (XAC – formerly CloudGateway) is “Ok, now how do I integrate this with my existing XenApp or XenDesktop deployment?”
Before we get too far into answering that question, let’s first take a moment to set expectations. This article is intended to help clear some of the fog around which components ‘sit in front’ of others and how they integrate. The article will also attempt to explain how they can be used to tailor the user experience in one way or another for certain device types. We won’t be going into what these components are or how they work, so if you are still getting up to speed on technologies like StoreFront and AppController, now would be a good time to hit the eDocs for a summary so this stuff will make more sense. We also aren’t going to turn this into a runbook on how to set this up, mainly because there is not just one way to be successful at this and (as usual) it really depends on what matters to your end users.
Question 1: StoreFront or Web Interface?
First a disclaimer, we are not recommending one over the other for general (non-XenMobile purposes). And which your organization chooses to use really hinges on feature sets needed. Luckily Thomas Berger, one of my colleagues, was kind enough to help us with all that in his article.
Let’s also remember that there is no reason you can’t have WI and SF deployed at the same time. Certain use cases might lend themselves well to the StoreFront experience right away, others might not. This could also be a good stepping stone to get familiar with SF so that you are prepared when WI reaches EOL.
But back to XenMobile. Can I still use Web Interface with XAC? – Sure you can, but you are going to lose some functionality. Should I? – Probably not… unless that is your only option or you do not want to use the features we are about to discuss. So from here on out, let’s assume we are talking StoreFront.
With XAC you can configure ‘trusts.’ When integrating with StoreFront, these trusts can go two ways or just one. One of these trusts allows XAC to display XenApp and XenDesktop resources to mobile users. That part can be done with StoreFront or Web Interface. We are actually using the legacy PNAgent functionality for this. But let’s not forget that XAC can do more than just publish wrapped (or sandboxed) mobile applications. We have the ability to publish SaaS connectors and Web links also. As a user I might find that functionality useful even if I am not on a mobile device. My organization can publish all of those long hard-to-type web links I can never remember and I can launch them without needing to wait for a published application. I can also be single signed on to SaaS resources that I commonly use. Above all, most users just want to have the same options no matter what device they are on. For that, we need StoreFront. Just set up the other trust we were talking about and now I can see the same sets of resources whether I am connected to XAC or StoreFront.
Question 2: Why can’t I just use AppController? Why do I need both?
I cheated. That is technically two questions, but they have the same answer. XAC does have a built-in Receiver for Web (RfW) and it looks just like StoreFront (we call it “StoreFront light”). What XAC does not have is a robust XML service the way that SF and WI do (hence the ‘light’ part :)). That is why we need WI or SF. One of them needs to help XAC out by performing the initial application enumeration process. WI and StoreFront are also capable of a host of fancy features like auto-launch, and session pre-launch that XAC can’t do.
Question 3: If we need both, which sits in front?
Now we are back to our root question. How does this architecture really look? What goes where?
In previous releases (SF 1.2 and XAC 2.6 or below), StoreFront sat ‘in front’ for all use cases. Along with the release of XAC 2.8, we released this our mobility client called ‘Worx Home.’ We will not go too deep into the evolution of the mobile client for iOS and Android. That might be a good topic for a follow-up article. But now Worx Home (WH) needs to be pointed directly to XAC (through a NetScaler Gateway). It can’t be pointed to StoreFront anymore like Receiver could. This does not mean that any user with a mobile device (Android or iOS) needs to hit XAC from all of their devices. The important thing to keep in mind here when figuring out what is right for your users is subscriptions. We don’t want the user to see a different set of applications from RfW than they see from Receiver and WH. Below is an example of what we have done for some customers in the past that seems to work nicely. This can all be controlled with NetScaler Gateway session policies and profiles for users coming in from an external network. The assumption in the scenario below is that our mobile devices (Worx Home users) are all on an external network or guest wireless as they may be BYO or untrusted:
- RfW Users (Browser-based). For some of the reasons we discussed earlier (those extra features and the ability to customize) we want to send these users to StoreFront. Users are also probably already used to doing this (or the WI equivalent), so we don’t want to change any more than we have to. This can be done by filtering on the ‘Referer’ header in the session policy. As users access the store, they are going to generate a list of subscriptions. Subscriptions do not synchronize between SF and XAC.
- Native Receiver Users (Windows, Mac, etc.). Similar to our RfW users, we are also probably going to want these users hitting StoreFront so they can leverage all of the enhanced functionality. This also makes sure that the user will see the same set of subscriptions when accessing the environment via a native Receiver as they do with RfW. In our NetScaler session policy we can filer on ‘CitrixReceiver’ and ‘X-Citrix-Gateway.’ We can also get more specific and filter based on Windows or Mac etc.
- Worx Home Users (iOS and Android). As noted above, we need these users pointed to XAC on the back end. But what about our subscriptions? – Interestingly, most users do not want the same list of applications pushed to their mobile device as they would use on another endpoint. The separation of these subscriptions is actually somewhat by design based on that user feedback. As far as our session policy, we can filter for Worx Home based on the ‘Zenprise’ header. As a fun fact, a good portion of our XenMobile suite was acquired from a company called Zenprise (yes, with a ‘Z’), so that is where the header comes from.
We have a pretty good list of these headers available here if you want to get even more granular with it.
If you are thinking about having these Worx Home (mobile device) users on your internal network (without NetScaler in play), remember that you will lose some functionality such as micro-VPN and STA, which are required for certain components of the solution to function properly. For other use cases (non-mobile devices), you can control the internal user experience based on which URL you tell the user to access.
Ultimately the “which sits in front” question was kind of a trick question. Neither component really sits ‘in front.’ That’s why some Citrites might say XAC and StoreFront function “in parallel.” How you choose to use them is really up to you and the requirements of your organization. As usual, this all comes down to the desired user experience. Just be sure to keep subscriptions in mind so you don’t have users scratching their heads about what they are seeing one place vs. another. Hopefully you find this useful when designing your own XenMobile environment. Feel free to drop me a note if you have any questions or comments on your specific setup.
Best of luck,