XenMobile is Citrix's Enterprise Mobile Management suite. It allows enterprises to maintain better control over how their IT users interact with company data, when connected through either company-provided or employee-owned mobile devices. The importance of such a solution is easy to see when you consider how ubiquitous mobile devices have become and also how they offer better on the run access to information, something hugely important to the mobile workforce of today.
Before we dive into troubleshooting XenMobile integration, let's look at some fundamentals.
From an integration perspective, the key components are as follows:
- The XenMobile Server, a Linux virtual machine which is an amalgamation of the following:
- The AppController service, which provides mobile application management, but also acts as an STA for ticketing
- The MDM service, which provides mobile device management
- The WorxHome component, which is the application on the mobile device that takes care of User enrolment, as well as handling application enumeration and subscription.
- The Worx applications, such as WorxMail, WorxWeb, or even custom applications.
- A SAAS-based sharing platform which allows users to store and share files. It works both as a standalone application and as a connector built into other WorxApps, such as WorxMail, allowing users to attach files directly from the cloud.
The Ports used for NetScaler integration are as follows:
Let's take a look at a communication flow that demonstrates NetScaler's integration with XenMobile server using the most popular use case for this integration, WorxMail. We will once again break this into phases to make it easy to digest:
- Phase1: Authentication and discovery
- Phase2: Mobile application enumeration and launch
When User Bob launches WorxHome on his mobile device, it sends a GET to the path /zdm/cxf/public/getserverinfo on XenMobile server. This for the purpose of discovery and results in a redirect to the NetScaler Gateway VIP:
Bob logs in and his credentials are verified with the LDAP server.
Use aaad.debug, as in the VPN scenario, for any issues with authentication. Along with the credentials, WorxHome also tells NetScaler Gateway what kind of device Bob is connecting from, by using the User-Agent header:
User-Agent: CitrixReceiver/com.zenprise build/10.2.2 Android/4.4.2 KOT49H.N5110XXDNF1 VpnCapable
This results in a redirect to the path /cgi/setclient?andr. The andr here stands for Android. The redirect also contains the NSC_AAAC cookie, which identifies all further requests from this User:
The discovery finishes with the VPN client receiving the XenMobile server's details:
Once discovery is complete, WorxHome on the User's mobile device needs to be able to show the list of Worx Applications available to them. This is called application enumeration.
WorxHome requests a list of available applications through a series of POST, the last of which is to /StoreWeb/ws/Resources/List. So if it's enumeration that's failing, this is the request you'd be looking for. The response will be a list of apps and info about these apps, such as where to pull the icons from, their app ID, and their SSO details:
The app ID here is very useful because if you have app launch failures you can search using this value, and identify all pertinent requests. In the following screenshot the app ID is MobileApp2:
At this point Bob clicks on the WorxMail icon and this results in the application being fetched for installation. We can follow the exchange using a filter such as http contains MobileApp2. This should show something similar to the following:
The really large 200 OK is the WorxMail package. At this point, communication starts between the mobile end point and the end server, which is exchange in the case of WorxMail, and the User should see their mail:
For WorxMail, this will appear as a series of ActiveSync requests.