For many years our AppSense policy engine has had the ability to use “Session & Client” Conditions when the user connects to a Citrix XenApp server, e.g. the “Client IP Address” or “Client Screen Resolution”. My colleague Gareth Kitson talked about how AppSense provides the most dynamic desktop environments by taking advantage of the most comprehensive context aware capabilities on the market in his blog Putting Dynamic Desktops Into Context.
As mentioned in that previous blog, Conditions are filters that determine if an Action should apply at a specific Trigger point, giving greater control as to when, why and how a desktop is configured. When we consider the scenario of a user connecting to a Citrix XenApp server for either a Published application or desktop, AppSense provide many different Session & Client based Conditions out of the box, and, enable our customers to even create their own Custom Conditions too.
One of the things I have noticed when working with customers is that people often use the “Client Screen Resolution” Condition to identify certain devices, e.g. iPhone’s or iPad’s. To me this seemed a somewhat inaccurate way of identifying the client device and with the introduction and growing use of tablets with high resolution screens was likely prone to misidentification.
Attaining Connecting Device Information
For a long time Citrix has had MFCOM and more recently the PowerShell SDK, these tools allow us to get a whole lot of useful information about the connecting device even without an AppSense agent installed on the said connecting endpoint device.
Think about it, by taking advantage of these tools as a Custom Condition in AppSense, we can now understand what type of device it is and then apply a Policy Action based on the result without actually having to touch it. Whether it is a corporate or non-corporate device, in-house or external location, we know what is connecting and can configure the desktop and applications accordingly. So, with that in mind I decided that I could be a lot more accurate when checking for the connecting device operating system and would like to share it with you.
So I started looking on my XenApp 6.5 server and seeing what commands where available to get me the information I needed, and I quickly found:
Understanding the Connecting Device Client OS
This gave me all of the details I needed, specifically the ClientProductId, as each client OS has its own predefined ID. From this I simply created a Custom Condition (AppSense empower our customers with the unique ability to create any Custom Conditions they wish to, in various scripting languages) in Environment Manager to check the ClientProductId for the current logged in user. My Custom Condition was written in PowerShell and looks as follows:
#Add Citrix Snapins
Add-PSSnapin -name Citrix.XenApp.Commands -ErrorAction SilentlyContinue
#Get client version
$ClientType = Get-XASession -Account $env:userdomain$env:username -Full | Select-Object -Property ClientProductId
#Check client version and exit
if ($ClientType.’ClientProductId’ -eq “84″)
By changing the value that is checked in the Custom Condition, you can specify different client Operating systems to attain precise understanding of the connecting client device, even though as mentioned there are no AppSense agents on the (unknown) end point. Some of the common ones (in alphabetical order) are:
Android = 84
Blackberry = 85
iOS = 83
LinuxUnix = 81
Mac = 82
ThinOS = 32993
WinCE = 7945
Windows = 1
So I now have a way of deciding what Policies and Actions I will apply to my XenApp session based on the connecting client OS – cool!
At this point I was very satisfied with what I had achieved, however not long after this I heard rumours that some of our Engineers were looking at a new Citrix SDK, the XenApp 6.5 Mobile Application SDK, see here for more information. I had a chat with one of our Engineers and decided to have a look myself…
AND Understanding the Connecting Device Client TYPE
…Hmmmm, very interesting. This starts to give a whole lot more client information, however the part that caught my eye was the Client Type. This new SDK could tell me whether the user was using a phone or a tablet! Brilliant I thought, this can take what I have been doing to the next level
However my excitement was soon quelled once I started looking at the SDK, this SDK was for “proper developers” and it was doubtful I would be able to get too far. I managed to work out I could use the COM part from PowerShell and that was likely to be the best way. Taking advantage of our close relationship with Citrix, I reached out to the Citrix SDK Team and they helped me out with an example, from that I created the following Custom Condition:
#Load COM Object and get information
$cmpObj = new-object -comObject Citrix.Mobility
$rc = $cmpObj.OpenSession()
$capType = [System.Int16]0
$rc = $cmpObj.GetCapabilityInt16(3, 6, ([ref]$capType));
#Check client type and exit
if ($capType -eq “2″)
The Custom Condition checks whether the session is running on a tablet. You can get the device types from cmpenum.h in the SDK docs:
CMP_DEVICE_TYPE_UNKNOWN = 0×0000
CMP_DEVICE_TYPE_MOBILE_PHONE = 0×0001
CMP_DEVICE_TYPE_TABLET = 0×0002
CMP_DEVICE_TYPE_LAPTOP = 0×0003
CMP_DEVICE_TYPE_PC = 0×0004
CMP_DEVICE_TYPE_MAC = 0×0005
Detecting Both Connecting Client OS AND Device Type
Now this is context aware dynamic desktops without actually having an AppSense agent even installed on the (unknown) endpoint!
I now had a way of not only detecting the connecting client OS but now, when combined, also the device type when a mobile device was being used – brilliant, double thumbs up! and expect some funky demos in the future!
There are a couple of caveats that you need to be aware of:
- The user who runs the Custom Condition to get the connecting device OS needs to have appropriate rights to read this information. I made my users Citrix Read Only admins.
- The tablet and phone detection currently only works for iOS and Android clients.
- All Android versions before 3 will always report as a phone. You need to be using version 3+ to be able to differentiate between Android phones and tablets.
- Make sure you have installed the Mobility SDK on your XenApp server and registered the new virtual channels.
My reason for looking into this was to help someone attain a more accurate contextual understaning in the enterprise environment, and for my colleagues to create a demo that would show different contextual Policies dynamically based on the device type, e.g. company laptop, mobile device etc…
Now, utilizing what I have detailed above, whether you are a customer, partner or colleague, you can apply all sorts of dynamic policies and decide what icons the user has, how applications are locked down, what features are enabled, what network drives may be mapped for the application etc… depending on the Connecting Client OS or Device Type.
Thinking about this a little more I realised you might be able to use this to start an application in a certain mode based on device, e.g. if the connecting endpoint is a mobile device then start the application in Metro mode, otherwise start it normally – I would be interested to know of any other user cases that people have for this.
Rob Dobson | Technical Account Director.