Overview
One of the first questions that seems to come when we help our customers get going with XenMobile AppController (XAC - formerly CloudGateway) is "Okay, now how do I integrate with my existing XenApp or XenDesktop deployment on?"
Before going too far in answering this question, let's first take a moment to set expectations. This article is intended to help clear some of the fog around which the components "sitting in front" of others and how they integrate. The article will also attempt to explain how they can be used to customize the user experience in one way or another for some types of devices. We will not return to what these components are and how they work, so if you are still getting up to speed on technologies such as StoreFront and AppController, now would be a good time to hit the eDocs for summary then this stuff will more sense. We are also not going to make a Runbook on how to implement it, mainly because there is no one way to succeed in this and (as usual) it really depends on what which account for your end users.
Question 1: StoreFront or Web Interface?
First a warning, we do not recommend one over the other for general (non-XenMobile purposes). And your organization chooses to use really hinges on sets of necessary features. Fortunately Thomas Berger, one of my colleagues, was kind enough to help us with everything, in his article.
Remember also that there is no reason you can not have WI and SF deployed simultaneously. Some use cases could lend themselves well to the experience of StoreFront immediately, others not. This could also be a good springboard to become familiar with SF so you're ready when WI reaches EOL.
But back to XenMobile. Can I use the Web interface with XAC? - Of course you can, but you will lose some functionality. Should I? - Probably not ... unless that is your only option or you do not want to use the features that we will discuss. So from now on, assume that 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 XAC allows to display XenApp and XenDesktop resources for mobile users. This part can be done with or StoreFront Web Interface. We are using the feature inherited PNAgent for it. But do not forget that XAC can do more than just publish wrapped (or sandbox) mobile applications. We have the ability to publish SaaS connectors and web links too. As a user, I might find this useful feature, even though I'm not on a mobile device. My organization may publish these long links difficult to type Web I never remember and I can run without having to wait for a published application. I can also only be signed for SaaS resources I usually use. Above all, most users just want to have the same options, no matter what device they are. For this, we need StoreFront. Simply set up another trust we talked and now I can see the same resource sets if I am connected to XAC or StoreFront
Question 2 :. Why can not I use AppController? Why do I need both?
I cheated. This is technically two questions, but they have the same answer. XAC has a built-in receiver for the Web (RWF) and it looks like StoreFront (we call it "StoreFront light"). What XAC is not a robust XML service how SF and WI are (hence the "light" part :)). That's why we need WI or SF. One needs to help XAC by performing the initial listing application process. WI StoreFront and are also capable of a lot of fancy features like auto-launch and pre-launch session that XAC can not do
Question 3 :. If we need at a time, which is opposite?
Now we're back to our basic question. How this architecture really look? What goes where?
In previous versions (SF XAC 1.2 and 2.6 or below), sitting StoreFront 'front' for all use cases. With the release of XAC 2.8, we released it our mobility client called "Home Worx. 'We will not go too deeply into the evolution of the mobile client for iOS and Android. This could be a good topic for a follow-up article. But now Worx Home (WH) must be reported directly to XAC (via NetScaler Gateway). It can not be emphasized more as a receiver could StoreFront. This does not mean that any user with a mobile device (Android or iOS) needs to hit XAC all their devices. The important thing to keep in mind here in determining what is right for your users subscriptions. We do not want the user to see another set of applications RFW they see the receiver and WH. Here is an example of what we have done for some customers in the past that seems to work fine. All this can be controlled with policies and Gateway NetScaler session profiles for users who come from an external network. The assumption in the scenario below is that our mobile devices (users Worx Home) are on an external network or without guest wire as they can be BYO or unreliable:
- Frw Users (browser- based). For some reasons we discussed earlier (these additional features and the ability to customize) we want to send these users StoreFront. Users are also probably already used to do this (or equivalent WI), so we do not want to change more than we need. This can be done by filtering the header "Refer" in the session policy. As users access the store, they will generate a list of subscriptions. Subscriptions are not synchronized between SF and XAC.
- the native receptor users (Windows, Mac, etc.). Similar RFW our users, we're probably going to want these users hit StoreFront so they can take advantage of all the improved features. This also makes sure that the user will see the same set of subscriptions to access the environment through a native receptor as they do with Frw. In our session we NetScaler policy of settling on "CitrixReceiver" and "X-Citrix Gateway. We can also be more specific and filter based on Windows or Mac, etc.
- Worx Home Users (iOS and Android). As noted above, we need these users stressed 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 on any other endpoint. The separation of these subscriptions is actually somewhat by design based on what the user comments. Regarding our policy session, we can filter for Worx Home based on the header 'Zenprise'. As a fun fact, much of our suite XenMobile was acquired from a company called Zenprise (yes, with a 'Z'), so that is where the header comes.
We have a very good list of these headers available here if you want to get more granular with it.
If you think you have these Worx Home (mobile device) users on your internal network (without NetScaler in play), remember that you will lose some features such as micro-VPN and STA, which are necessary 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 the URL that you tell the user to access.
Wrap
Ultimately the "who is in front" question was somewhat a trick question. Neither component is really located "in front". That's why some might say Citrites XAC and StoreFront tool "in parallel." How you choose to use is really up to you and the requirements of your organization. As usual, it all boils down to the desired user experience. Just be sure to keep subscriptions in mind so you do not have users scratching their heads about what they see one place compared to another. We hope you find this useful when designing your own XenMobile environment. Feel free to leave me a note if you have questions or comments about your specific configuration.
Good luck,
0 Komentar