During the implementation of various XenMobile sites I notice several customers run into the same problems. Problems and question which are being asked at the support forums as well. Sharing my “Lessons learned” hopefully helps others while doing deployments of Citrix XenMobile.

Pre-Installation Checklist

In many cases a pre-installation checklist is a nice to have, but not really necessary for installing a product. In case of Citrix XenMobile this is an absolute must have, before starting the project. There are many dependencies, without it you are not able to do a efficient installation.

Make use of the Pre-Installation Checklist Citrix offers !

Test Hardware
Get hold of a test device, it’s not convenient to use your own production device during the test / installation fase. Several XDM deployments use different ROOT CA’s, which are not able to work next to each other. First you have to deleted your current profiles, before you can re-enroll the device to a different environment. Durings configuration and tests I would also like to test the geo-fencing options, including a full-wipe of the device. Not something you would want to test on your own production device.

Get a test device for every platform you need to support

Apple Mac OS X
To manage iOS and Android applications from within the AppController, applications (.ipa/apk) need to be wrapped. For wrapping applications Citrix provides the MDX Toolkit, which unfortunately only runs on Mac OS X. The MDX Toolkit doesn’t work on a virtualized Mac OS X, you need real Apple hardware for this.

The MDX Toolkit requires a Mac Mini, MacBook Air, or other Mac Device

Apple Developer Account
This was a hard one to figure out at first, for signing an iOS application a Apple Certificate is required. There are two type of Apple Developer accounts available :

My question was, which one to choose? The $ 99 account sounded better, but if this was insufficient I would had to spend the $ 299 anyway. With the developer account you are able to wrap applications, but on forehand you have to enter all used device id’s, with a max of 100 devices. In a develop environment with dedicated test devices this ain’t a problem, but in a production environment this is a real problem. It’s not convenient to rewrap the application everytime a new device is being added. Therefore my advice would be purchasing to purchase an Enterprise account!

Keep in mind the enrollment procedure for the Apple Enterprise Account is a time consuming process, which took me almost a week. Make sure the Developer account is available before starting the project !

Provide all systems (XenMobile Device Manager / AppController / StoreFront / DDC / ShareFile) with a SSL certificate when setting up the environment. If there is a internal PKI infrastructure available make use of this! Otherwise use self-signed certificates.

Don’t try to change the certificates created during the XenMobile XDM setup, use the certificates created by the setup.

With a Netscaler in front of the XenMobile environment you don’t need public trusted SSL certificates on the XenMobile Device Manager, AppController & ShareFile Storagezone Controller. On the Netscaler however you do need a trusted public certificate. My advice is to use a wildcard certificate, because I prefer to use different FQDN for the required components:

  • xenmobile.mydomain.com (XenMobile Enrollment URL)
  • worx.mydomain.com (MicroVPN URL)
  • sharefile.mydomain.com (ShareFile Storagezone)
  • enterpriseenrollment.mydomain.com (Windows 8.1 Enrollment URL)

Don’t forget to add your internal root CA to the Netscaler! Otherwise the Netscaler won’t trust your internal XenMobile servers

To create a high available environment you will need a load balancer in front of the XenMobile environment. Although several brands of load balancers exists, I prefer using a Citrix Netscaler. The Netscaler is available in three models, VPX, MPX & SDX. The version you need is very dependent of the amount of devices and MicroVPN tunnels which will be opened at the same time.

For small environments start with a free VPX Express, which has a 5MB passthrough limitation, but does support LB/HA.

Load Balancing / High availability
Consider HA/LB from the initial setup, make sure everything is designed and prepared for this. The architecture can be complex, start with a single XDM/XAM server and make sure everything works as expected. Soon as everything works as expected add the additional LB/HA.

Start the single server setup with the LB/HA FQDN, so no configuration needs to be changed afterwards.

DNS Records
Make sure the DNS records are created on forehand! All XenMobile components (Internal/Externals) must be resolvable correctly. Also don’t forget to register DNS entries for the LB/HA FQDN which are being routed through the Netscaler.

All XenMobile components needed to resolve with DNS.

XenMobile makes use of the Apple Push Notification Service, which required a  Apple Push Notification Service certificate. This self-signed certificate should contain the public FQDN of the XenMobile enrollment URL which is being used. The signing request needs to be sends to Citrix, for which you will have to open a technical support case. The signed request received from Citrix needs to be forwarded to Apple for signing as well. You will need to create a Apple Account for this.

APNS Certificate request needs to be signed by both Citrix and Apple

During the setup a XenMobile license file is required to successful finish the installation, make sure it’s available

Without a License File the setup won’t finish !

Auto-Discover Record
For Auto-Discovery based enrollment a service record is required in the Zenprise database, not a service record in your own public DNS like the Citrix Receiver. For Windows devices even a public SSL certificate is required (enterpriseenrollment.mydomain.com).

Auto-Discovery needs a service record in the Zenprise Database, additional for Windows RT a certificate is required

The XenMobile setup requires a database to store all its configuration, which can be a local Postgress of central SQL Database. Because we are building a high available environment which needs to be scalable, I would suggest using a SQL database which is hosted on a separate server.

Use a SQL Database for XenMobile for scalability / high availability

Active Directory
For ease of the XenMobile users during enrollment I would recommend using the UserPrincipalname (UPN) and not the samAccountName. This way a user only has to enter his/her email address, after which the auto-discovery process will look up the enrollment URL. WorxHome will pre-populate the username with the UPN and only the password needs to be entered to start the enrollment. It’s possible to change the logon type from samAccountname to userprincipalname afterwards, but previously enrolled need to re-enroll when this is beeing changed.

Start with UserPrincipalName (UPN) for authentication, changing this afterwards results in re-enrollment of devices

Use Certificate Based Authentication
To simplify the user experience XenMobile devices can be provided with a certificate and Worx Pin for authentication. Also make sure revoking certificates is enabled, so that you can disable a compromised user certificate.

Simplify the user experience with WorxPin and a user certificate

To improve the battery life of the XenMobile connected devices its highly recommend to use the STA method with WorxMail.

Save the battery life with the WorxMail STA method

Policies and Deployments Packages
For every device type (iOS/Android/Windows) separate policies and deployments packages needs to be created. Keep in mind that available options are very various per type of device.

Create policies / deployment packages per type device (iOS/Android/Windows)

Scheduling Policy
XenMobile uses the Apple Push Notification Service (APNS) to update iOS devices, for Android their is no push notification services. Android devices need a scheduling policy deployed, otherwise you won’t be able to update enrolled Android devices.

Don’t forget the scheduling policy for Android to keep these device managed

AppController GUI
The Devices tab within the AppController does not show any devices by default. Af first it seems like no devices are available. Soon as you add a (partial) device name in the search box the enrolled devices appear:


 Without a search query the Devices tab in the AppController is empty, even though devices are available

Wrap WorxMail / Worxweb
By default WorxWeb and WorxMail are not wrapped and can’t be managed through the AppController. Both applications need to be wrapped with the MDX toolkit before the can be fully managed

Applications needs to be wrapped to be fully managed, this includes WorxMail/WorxWeb


Also check out the blog Bas van Kaam wrote about this “XenMobile prerequisits, what do we need and how does it all fit together? Technical overview included!”



Post Navigation