Monthly Archives: February 2015

XenMobile 10.0

The following content is a brief and unofficial prerequisites guide to setup, configure and test XenMobile 10.0 prior to deploying in a PoC, Pilot or Production environment by the author of this entry. The views, opinions and concepts expressed are those by the author of this entry only and do not necessary conform to industry descriptions or best practises.

Shortened Names

What’s New
1: XenMobile is now a single unified hardened Linux virtual appliance.
2: Complete overhaul of the Web UI which dramatically simplifies policy setup & configuration of MDM + MAM policies and it allows for the management of multiple platforms within a single policy.
3: Built-in V6 Citrix Licensing server provides a 30 day trial/evaluation and also support for remote V6 CTX licensing server.
4: Built-in PostgreSQL database recommended for PoC’s and there’s also support for remote MS SQL database which is recommended for production deployments.
4: XMS V/A includes IPtables which is a Linux firewall –
5: XMS placement is in the DMZ. The V/A is hardened and is FIPS 140-2 compliant and remember you data is actually stored in a MS SQL database unless your utilising PostgreSQL database within the XMS V/A.
6: Traffic flow and ports between NetScaler Gateway and the XenMobile Server (XMS) have changed please refer to eDocs for an architecture overview of the changes at –
7: The Admin Web UI is now on https://XMS-FQDN:4443/. This port is not configured as part of the XenMobile 10 wizard on NetScaler Gateway build 10.5-55.8 which means that you will not be able to access the mgmt. Admin Web UI from the internet it will only be accessible from the DMZ and the TRU network dependant upon your firewall(s) ACL list.
8: New WorxHome build which is also backwards compatible from XenMobile 10.x.n
9: The XenMobile NetScaler Connector (XNC) currently is still a separate Windows Server.
9: You can find our more by watching the following Mobility Master Class: What’s New in XenMobile 10 available from Citrix TV.

Mobility Master Class: What’s New in XenMobile 10

Mobility Master Class: Citrix XenMobile 10 Clustering & MDM Migrations

Deploying XenMobile 10
1: Review the system requirements for XMS at – to understand the supported hypervisors, computing requirements. You should also make sure that you review the latest XM architecture as it has changed between XenMobile 9.0 vs. 10.0 and it can be viewed at – You’ll notice that the traffic between NSG and the XMS V/A has changed however all traffic externally still occurs on there traditional ports (443, 8443, 2195, 2196, 5223).
2: Review and understand the NetScaler Gateway compatible requirements at –
3: Make sure that you print out and fill-in all the pre-requitses for the XMS V/A ref – prior to deploying your XMS V/A on your chosen hypervisor.
4: Once you have uploaded the V/A to the hypervisor and booted it complete the onscreen instructions ref – Once you are finished login into the Admin WebUI replacing the IP Addr with your XMS V/A ip addr from this example https://XMS-IPADDR:4443/ and login with Administrator account your specified during the deployment and NOT admin which is used to access the XMS V/A CLI from your hypervisor only.
5: Once you’ve logged in you’ll need to have the following listed below available to successfully complete the second part of the initial XenMobile 10 deployment. There is also a pre-requites check list available at –

– Citrix v6 licensing file for either local or remote. Remote is recommended for H/A purposes.*
– Microsoft Active Directory (AD) ip addr or FQDN, base DN, domain, search service account with read-only permissions.
– Certificate in *.p12 or *.pfx format for the SSL_Listener which is used for two way secure HTTPS communication to the XMS V/A.
– APNS certificate.
– Separate MDM and MAM+ FQDN’s correctly setup in DNS with fwd and reserve lookup’s configured and each configured with its own static IP addr for external resolution.
– 3x VIP for configuring XenMobile 10 with NetScaler Gateway +. You can find a compatible NSG V/A version and builds at –
– MS SQL Database server configured to accept traffic and with write/read privileges to create and manage the remote XMS database.
– Mail server configuration which enables and provides workflow email messages, notifications to users e.t.c

6: Follow the onscreen prompts and once completed the web UI deployment wizard then you have successfully deployed a XMS V/A. Please not reboot the XMS V/A so that the existing SSL certificates for HTTPS can be unbound and the newly uploaded SSL cert(s) can be bound to HTTPS.
7: You may now setup a XMS cluster and configure H/A with a NSG and thereafter begin configuring your XenMobile 10.0 environment. See the H/A section for a how-to.
8: Logon to one of the XMS v/a direct IP addr e.g https://XMS:4443/ if in H/A fronted by the NSG as the XenMobile 10 wizard will not configure 4443 which means that you cannot access the mgmt interface via the VIP owned by the NSG. This means that the mgmt interface is not accessible either internally or externally on the FQDN that resolves the VIP owned by the NSG.
9: Scaling XenMobile 10.0 from 1000 up to 100,000 devices –

XMS V/A High-Availability (H/A)
1: Prior to understanding how-to setup a XMS H/A or clustering you need to understand that the minimum requirements are for a remote CTX v6 licensing server and MS SQL database as the XMS V/A do not hold any user/cfg information this is all held in the remote database.
2: Once your have setup XMS follow the prompts in the CLI to enable clustering and configure the IPtables firewall ACL and then finally shut it down and clone it.
3: Rename the cloned XMS V/S to your required naming convention and then boot up the cloned XMS V/A login to the CLI and changed the IP addr and ensure that the IPtables firewall ACL ports are correctly enabled then shutdown the V/A.
4: Boot the first XMS V/A and then 60 seconds later boot the cloned XMS V/A and login to the CLI to very the cluster is enabled and then login into the XMS admin WebUI to verify that the cluster is up and functioning as expected. The original XMS V/A will be the oldest in the cluster.
5: You can now proceed to setting up the load-balancing for the XMS V/A’s with NSG to service MDM + MAM requests.

Supported NetScaler Gateway (Builds & Versions) for XM 10
1: MR5; MR4; MR3; 10.1.130 MR & 10.1.129 MR ref –

Deploying XM 10 with NetScaler Gateway 10.5.x.n (Draft)
1: Before beginning its worth mentioning that the way I will be describing how-to deploy XenMobile 10 in this blog article will be to utilise to external static IP addr’s + FQDN’s that are NATed to DMZ IP addr’s and I will utilising SplitDNS for device mgmt. in/outside of my TRU network. I will also be implementing the described XenMobile 10 environment below utilising an SSL Bridge although offloading includes a few more minor steps the intention of this section is aimed at helping you front your XenMobile 10.0 deployment with a NSG 10.5.x.n V/A.
2: Please review the following CTX article entitled “FAQ: XenMobile 10 and NetScaler 10.5 Integration” – which will aid you in been able to setup and configure load-balancing for XMS V/A’s, mVPN for Worx’s apps for XenMobile 10 with NetScaler Gateway 10.5.x.n.
3: You’ll require the following prior to be beginning:

– Correct NetScaler (Gateway) build +_ version the NSG version + build I’ll be discussing here is NetScaler Gateway MR5 but you can check the latest supported version + builds at –
– 1x FQDN for MDM e.g. * that resolves to both external internet routable static IP addr and your internal assigned static IP. Please note that this should match exactly the FQDN entered in at the time of the deployment of your XMS V/A during the first phase in the CLI the text your looking for is/was “XenMobile Server FQDN:” and its highlighted in yellow. It is also worth/noting that if you have utilised an internal domain e.g as the FQDN this will only manage devices internally as that FQDN is not routable on the internet so you’ll only be able to manage devices INSIDE of the trusted network to its recommended to a FQDN that is internet routable and you can utilise SplitDNS to manage traffic requests to the NSG VIP’s for XenMobile.
– 1x FQDN for MAM (Worx’s Apps) e.g. * that resolves to both external internet routable static IP addr and your internal assigned static IP
– 2x External routable internet IP addr’s * e.g which most IT Pro’s utilise to ping to check internet connectivity
– 3x Internal IP addr’s owned by the NSG as VIP
|- 1x for MDM
|- 1x for MAM Gateway
|- 1x for Load-balancing IP
– Wildcard certificate for your domain e.g *
– If your implementing SSL Offloading (HTTP) of your XenMobile traffic for MAM then you’ll require the devices cert from the XMS V/A which can be downloaded from the XMS Web AdminUI at https://xms:4443/

4: Setup the NetScaler Gateway configuration within the Admin WebUI of the XMS V/A following the process outlined at – its fairly straight forward and simple.
5: Login into the NSG Admin WebUI interface and click the XenMobile Wizard in the bottom left-hand corner and then you’ll be prompted to setup either XenMobile 9.0 or XenMobile 10.0 please selected XenMobile 10.0 and click “Get Started” to continue.
6: Ensure that “Access through NetScaler Gateway” which is for MAM, “Load Balance XenMobile Servers” which is for MAM are checked they should be by default, however you know have the opportunity to deselect either if one depending upon your deployment scenario/use case and obviously your acquired license. The current XenMobile 10 datasheet is available at –
7: Enter in your first VIP for the MAM Gateway then port should be 443 and provide a suitable name.
8: Select your previously uploaded SSL certificate (I am utilising a wildcard cert for my domain * or upload your SSL cert.
9: Create your (s)LDAP binding you will need to provide the following:

– LDAP IP addr
– LDAP Port default is 389
– Base DN e.g Cn=Users,dc=axendatacentre,dc=com
– Service account username & password
– Timeout default is 3 seconds
– Server Login sAMAccountName or UserPrincipalName (SuGgEsTeD)

10: Now enter in your MDM FQDN and then the Load-balancing IP addr beneath and accept the default port of 8443. You can now also choose to select HTTPS (SSL Bridge) vs. HTTP (SSL Offload) and you can choose your DNS mode including split tunnelling.
11: Select your previously uploaded SSL certificate (I am utilising a wildcard cert for my domain * or upload your SSL cert.
12: Enter in your MDM VIP and you’ll notice the default ports are 443, 8443 for communication to the XMS V/A(s). You’ll notice that you cannot change the SSL traffic configuration as I specified to not to perform any SSL offloading in set 10 above or its under section “Load Balancing IP address for MAM” within the NSG XenMobile 10 wizard.
13: Next add in the XMS ip addr’s of each V/A in your XMS cluster and provide an appropriate name and ports are automated defaulted to 443, 8443.
14: Click continue to finish and then click done and you have now setup and configured all your traffic for XenMobile to route through your NSG V/A and we are performing SSL Bridging in the above scenario.

Worx Features by Platform
1:The following eDocs web page lists the features by Worx app which includes WorxHome, WorxMail, WorxWeb, WorxEdit, WorxNotes, WorxTasks & WorxDesktop ref –
2: Be sure to also checkout the known issues list at – and it is also worth noting that as of writing this blogging entry WorxTask’s is in Tech Preview (TP) ref –

You should follow the XenMobile team on twitter at – for the very latest on Worx’s apps, updates, upgrades and so much more.

1: The XenMobile security web page is available at –
2: The XenMobile Security whitepaper is available at – and I would strongly advise that you read/review it to get a better understanding of how XenMobile can help and assist any organisations EMM (Mobility) requirements.
3: The Mobile Application Management with XenMobile and the Worx App SDK –, this is well worth reading.

vGPU for XenApp and XenDesktop 7.6 powered by nVidia GRID K1, K2 Cards on XenServer 6.2 SP1, 6.5

“The following content is a brief and unofficial prerequisites guide to setup, configure and test vGPU technology using XenServer 6.2 SP2+ or XenServer 6.5, XenDesktop 7.6, nVidia GRID K1 or K2 cards and a supported server from either the Citrix or nVidia HCL prior to deploying in a PoC, Pilot or Production environment by the author of this entry. The views expressed here are my own and do not necessarily reflect the views of Citrix.

Shortened Names

What’s New
1. vGPU for XenApp is now supported ref the following blog article published entitled “Citrix supports NVIDIA GRID™ vGPU™ for XenApp!” –
2. XenServer 6.5 can now support up to 3x nVidia GRID cards scaling up to 96 VM’s with a vGPU assigned in a GRID enabled/compatible supported server hardware.
3. nVidia have certified new GRID profiles all of which are Q certified check them out at –
4. The latest GRID card datasheet is avaiable at –

What is vGPU?
It is a logical portion of a physical GPU assigned to a VM to deliver rich graphical applications from either a multi-user or desktop OSes. It is currently only supported with either nVidia GRID K1/K2 cards, compatible HCL server running either XenServer 6.2 SP+ or XenServer 6.5+ with XenApp or XenDesktop 7.6. The GPU resources (Frame buffer) + access time that is allocated to a vGPU assigned to the VM is managed with the help of a vGPU profile e.g K120Q which manages the GPU resources + time in conjunction with the vGPU manager which is installed within Dom0 of the XenServer 6.2 SP1+ or 6.5 host which intern allows for any VM assigned a vGPU to handle and delivery graphical intensive applications e.g AutoCAD Map 3D or Adobe Photoshop CS. For more technical information and an alternative description and overview including a diagram checkout – on the nVidia website.

GRID Card History
The first generation of GRID cards were called K1, K2 Cards and made use of the “Kepler” architecture, technical details can be found on the datasheet here –

The second generation of nVidia GRID cards are called TESLA which make use of the “Maxwell” architecture which includes 3x offerings TESLA M10 (Rack Servers), TESLA M6 (MXM Blade Servers) and TESLA M60 (Rack Servers)

Overview of Citrix HDX vs. HDX 3D Pro
HDX stands of High Definition eXperience and is built upon the ICA protocol which is developed, owned and maintained by Citrix. HDX automatically and dynamically adapts to any changes within the users ICA session end-2-end to ensure that the users experience always comes first and foremost. HDX inspects the computing resources within the data centre e.g. the VM or physical server that the desktop or server VDA is install on, the network and the end-point device to see what computing resources can be leveraged to offload onto to further enhance the users experience. For a technical overview to Citrix’s HDX technologies and policies in XAD 7.6 check out – Citrix has published document entitled “What is HDX? / Citrix HDX technologies for optimizing the virtualization experience” available at – which provides a great introduction into HDX technologies.

vGPU Pre-requites & System Requirements
1. Start by reviewing
2. Hardware requirements can be found at – and to purchase a GRID enabled server please visit –
3. I would suggest downloading and reviewing the guide entitled “Part 1: XenServer GPU Pass-through” available at – prior to starting as this will cover off the installation of a GRID card into a Dell R720 Server which will be useful to review if your about to embark on deploying your first GRID K1/2 card in a compatible supported server.
4. The following guide entitled “Part 3: XenServer GPU Virtualization (vGPU)” covers off the full deployment from installing and configuring XenServer 6.2 SP1+ to preparing the VM and assigning a vGPU through to the installation and configuration of the nVidia GRID drivers, XenTools and the Desktop OS VDA. The guide is available at – *
5. Encoding method suggested is H.264 although you do need more power server h/w as this protocol type does require more computing power but uses less bandwidth and you’ll also require an end point capable of decoding the H.264 stream.

Installation & Configuration
1. or refer to point 4 in the above “vGPU Pre-requites & System Requirements” section.
2. NVIDIA GRID Configuration Checks by Jason Southern at nVidia

HDX 3D Pro Policy or Policies
1. I would strongly recommend when you begin your testing of a vGPU VM(s) that you create a new custom policy in Studio and perhaps title it “vGPU HDX 3D Pro” and apply the following sUgGeStEd vGPU HDX 3D Pro policy as described in this nVidia GRID forum article available at – Why not use my current HDX policy? Firstly this policy is a sUgGeStEd and should be considered as an initial base line to begin testing from and its based off real world field experience from an EMEA nVidia GRID Architecture based in the UK.
2. The following XenDesktop master class from July 2014 will provide you with a great insight into HDX 3D Pro with nVidia GRID cards. This master class is a must if your looking at deploying an HDX 3D Pro with a customers environment to enable the deliver of HDX Rich Graphics to users within LAN and WAN scenarios.

HDX or HDX 3D Pro Thin Clients
1. If your looking for HDX or HDX 3D Pro verified thin clients then please check out the Citrix Ready website at –
2. HDX Search results – and for HDX Ready Chrome Device –
3. HDX Premium search results –
4. HDX 3D Pro search results –

Customer Stories
1. Story | –
2. Case Study | Daewoo Shipbuilding & Marine Engineering Co. Ltd –
3. Success Story | Bell Helicopter Elevating The Design and Manufacturing of World-Class Helicopters –
4. Success Story | PSA Peugeot Citroen Accelerating Automotive Design with NVIDIA GRID –

nVidia GRID Forums
1. Drivers –
2. GRID cards –
3. XenApp –
4. XenDesktop –
5. Announcements –