So What's This All About

The purpose of this site

I started off my career in IT 25 years ago as a COBOL Programmer in South Africa and have progressed (or some may say regressed) to consulting on virtualization technologies. I created this site to share my experiences with virtualization and cloud computing, as well as the latest virtualization news, tips, tricks and tools from other experts in the field.

Online Training

Free XenApp 7.6 Training

This free, one-hour online course provides an introduction to Citrix XenApp 7.6. Students will explore key components required in a XenApp 7.6 implementation, the FMA-based architecture, as well as key use cases.

Click here for the course details

Keep Tabs on Me

Social media links

RSS Feed 2.0


How To Double Your VSAN Performance

An article by Chuck Hollis from VMware vSphere Blog » vSphere

How To Double Your VSAN Performance

VSAN 6.0 is now generally available!

Among many significant improvements, performance has been dramatically improved for both hybrid and newer all-flash configurations.

VSAN is almost infinitely configurable: how many capacity devices, disk groups, cache devices, storage controllers, etc.  Which brings up the question: how do you get the maximum storage performance out of VSAN-based cluster?

Our teams are busy running different performance characterizations, and the results are starting to surface.  The case for performance growth by simply expanding the number of storage-contributing hosts in your cluster has already been well established — performance linearly scales as more hosts are added to the cluster.

Here, we look at the impact of using two disk groups per host vs. the traditional single disk group.  Yes, additional hardware costs more — but what do you get in return?

As you’ll see, these results present a strong case that by simply doubling the number of disk -related resources (e.g. using two storage controllers, each with a caching device and some number of capacity devices), cluster-wide storage performance can be doubled — or more.

Note: just to be clear, two storage controllers are not required to create multiple disk groups with VSAN.  A single controller can support multiple disk groups.  But for this experiment, that is what we tested.

This is a particularly useful finding, as many people unfamiliar with VSAN mistakenly assume that performance might be limited by the host or network.  Not true — at least, based on these results.

For our first result, let’s establish a baseline of what we should expect with a single disk group per host, using a hybrid (mixed flash and disks) VSAN configuration.

Here, each host is running a single VM with IOmeter.  Each VM has 8 VMDKs, and 8 worker tasks driving IO to each VMDK.  The working set is adjusted to fit mostly in available cache, as per VMware recommendations.

More details: each host is using a single S3700 400GB cache device, and 4 10K SAS disk drives. Outstanding IOs (OIOs) are set to provide a reasonable balance between throughput and latency.


On the left, you can see the results of a 100% random read test using 4KB blocks.  As the cluster size increases from 4 to 64, performance scales linearly, as you’d expect.  Latency stays at a great ~2msec, yielding an average of 60k IOPS per host.  The cluster maxes out at a very substantial ~3.7 million IOPS.

When the mix shifts to random 70% read / 30% writes (the classic OLTP mix), we still see linear scaling of IOPS performance, and a modest increase in latency from ~2.5msec to ~3msec.  VSAN is turning it a very respectable 15.5K IOPS per host.  The cluster maxes out very close to ~1m IOPS.

Again, quite impressive.  Now let’s see what happens when more storage resources are added.

For this experiment, we added an additional controller, cache and set of capacity devices to each host.  And the resulting performance is doubled — or sometimes even greater!


Note that now we are seeing 116K IOPS per host for the 100% random read case, with a maximum cluster output of a stunning ~7.4 million IOPS.

For the OLTP-like 70% read / 30% write mix, we see a similar result: 31K IOPS per host, and a cluster-wide performance of ~2.2 million IOPS.

For all-flash configurations of VSAN, we see similar results, with one important exception: all-flash configurations are far less sensitive to the working set size.  They deliver predictable performance and latency almost regardless of what you throw at them.  Cache in all-flash VSAN is used to extend the life of write-sensitive capacity devices, and not as a performance booster as is the case with hybrid VSAN configurations.

In this final test, we look at an 8 node VSAN configuration, and progressively increase the working set size to well beyond available cache resources.  Note: these configurations use a storage IO controller for the capacity devices, and a PCI-e cache device which does not require a dedicated storage controller.

On the left, we can see the working set increasing from 100GB to 600GB, using our random 70% read / 30% OLTP mix as before.

Note that IOPS and latency remain largely constant:  ~40K IOPS per node with ~2msec latency.  Pretty good, I’d say.

On the right, we add another disk group (with dedicated controllers) to each node (flash group?) and instead vary the working set size from an initial 100GB to a more breathtaking 1.2TB.  Keep in mind, these very large working set sizes are essentially worst-case stress tests, and not the sort of thing you’d see in a normal environment.


Initially, performance is as you’d expect: roughly double of the single disk group configuration (~87K IOPS per node, ~2msec latency).  But as the working set size increases (and, correspondingly, pressure on write cache), note that per-node performance declines to ~56K IOPS per node, and latency increases to ~2.4 msec.

What Does It All Mean?

VSAN was designed to be scalable depending on available hardware resources.  For even modest cluster sizes (4 or greater), VSAN delivers substantial levels of storage performance.

With these results, we can clearly see two axes to linear scalability — one as you add more hosts in your cluster, and the other as you add more disk groups in your cluster.

Still on the table (and not discussed here): things like faster caching devices, faster spinning disks, more spinning disks, larger caches, etc.

It’s also important to point out what is not a limiting factor here: compute, memory and network resources – just the IO subsystem which consists of a storage IO controller, a cache device and one or more capacity devices.

The other implication is incredibly convenient scaling of performance as you grow — by either adding more hosts with storage to your cluster, or adding another set of disk groups to your existing hosts.

What I find interesting is that we really haven’t found the upper bounds of VSAN performance yet.  Consider, for example, a host may have as many as FIVE disk groups, vs the two presented here.   The mind boggles …

I look forward to sharing more performance results in the near future!


Chuck Hollis





Reducing PIN Prompts with NetScaler Gateway and Smart Cards

An article by Nicholas Czabaranek from Citrix Blogs

Smart Cards and NetScaler Gateway are a common XenApp/XenDesktop access scenario for many of our customers – especially in the U.S. Federal space where smart card usage has been mandated for most government agencies. One of the most common requests that we get when implementing Smart Cards is to reduce the number of PIN prompts that a user receives before they can get to their Windows applications or desktops. In this article I’m going to outline what configurations result in different PIN prompts, primarily in the context of Windows-based client devices accessing the NetScaler Gateway through a web browser.

Let’s go through the different places where we expect to see a PIN prompt in a non-optimized NetScaler Gateway + Smart Card configuration:

  1. Authentication to NetScaler. We need to authenticate the user with their PIN + Certificate before we can do anything else on the system. This is accomplished by requiring a client certificate to make the initial SSL connection to NetScaler Gateway.
  2. ICA Connection to NetScaler. After a user selects a published application or desktop to launch, Citrix Receiver will connect them to the NetScaler Gateway over SSL to begin the ICA session. If the Gateway vServer asks for a client certificate, the user will receive a PIN prompt.
  3. Windows Authentication to Desktop or XenApp Server. If single sign-on hasn’t been configured, or isn’t available, the Windows machine hosting the application or desktop that we want to connect to will also ask for the user’s PIN to logon.

Some would say that’s a lot of prompts, and I would tend to agree. Most users expect that they authenticate only once with their PIN as this is what they are used to on their traditional local Windows devices.

The good news is…it can be done!

Based on the three PIN prompts above let’s talk about how each one can be handled:

  1. Authentication to NetScaler. This prompt is normally needed as it allows us to authenticate the user at the NetScaler before allowing them access to internal resources. At a minimum the user will need to select their certificate if their Smart Card is configured with multiple certs. If their PIN is cached by a middleware application from their Windows client logon (like ActivClient), then they won’t need to enter a PIN here. Otherwise we expect both a certificate selection and PIN entry here.
    1st Prompt – Removable!

    If the client device has middleware that supports and is configured for PIN caching, the user can bypass the PIN prompt for the initial NetScaler Gateway connection.

  2. ICA connection to NetScaler. This is the easiest prompt to get rid of completely, and just requires that you setup a second NetScaler Gateway vServer that only handles ICA proxy. This NetScaler Gateway will not be configured to prompt for Client Certificate Check, meaning the SSL ICA connection doesn’t need to prompt the user again. At Web Interface we would setup Secure Access to point to this vServer instead of the initial authentication NetScaler Gateway. For information on how to do this in StoreFront using Optimal Gateway Routing, check out Bill Hackley’s blog post :

    Read More


X1 Skin for NetScaler Gateaway

An article by Richard Hayton from Citrix Blogs

One comment I’ve heard repeatedly is that whilst the new X1 UI is great, the users accessing it need to access this via NetScaler Gateway. So, the question becomes, can we please re-brand that as well?

The short answer is yes – that is very much on the list of active work. However, it isn’t part of the tech preview. So, in this blog I’m going to explain a quick and dirty way of moving NetScaler into the X1 era.

What we are going to do in this blog is rebrand the NetScaler login screen with something more X1-ish. This isn’t a full reskin – but is just enough to make the UX seamless. Here is what we are going to achieve:



We are going to use a feature in NetScaler to support ‘themes.’ NetScaler currently has two built in themes called ‘Default’ and ‘Green Bubbles.’ Plus, there is support for a third ‘custom’ theme. Initially, I looked at providing a custom theme. But. it turns out this is both version specific to the ‘dot’ release of NetScaler, and is also a little too powerful. Getting a custom theme wrong can break the admin UI.

For simplicity and breadth of support, I’m going to simply replace the existing ‘Green Bubble’ theme with a new X1 styled one. That change is easier to make, and as has the advantage that one file will work with all 10.x NetScalers.

I’ve pre-created a theme for NetScaler 10 here (located here: and all you need to do is install it.

Uploading the Theme

The first step is to upload the theme onto the NetScaler box. To do this I’m using WinSCP ( ). For references I’m using NetScaler 10.5, but this should work with any 10.x variant.

Use win SCP to log in to NetScaler. Use the IP address you normally use for the admin console, and the admin credentials. (Default values are &##8216;nsroot’ and ‘nsroot’ – obviously on a production system you will have changed them!)

Navigate the local machine (left) and NetScaler (right) until you can see your local copy of the new theme on the left, and the NetScaler copy on the right. (Note these will have the same name)

Read More


X1 Customization: Going deeper with CSS

An article by Richard Hayton from Citrix Blogs

This is my third blog post in a series related to the Receiver X1 Tech Preview. We have shared some background about X1 and practical tips to deploy X1. In this post we will dive deeper on how to customize with CSS.



The key to customization in X1 is Cascading Style Sheets (CSS). This is a standard part of the HTML specification familiar to web developers. For those who are new to web programming, it can be a bit daunting, but simple changes are really easy in CSS.

We have deliberately focused on standard technologies when looking at the X1 APIs to make customization extremely easy instead of forcing everyone to learn a new tool. CSS is the first and foremost means for customization. In fact if you use the StoreFront admin console to make changes under the covers CSS is created to match those changes (see last blog).


To do much more you need to break out an editor – notepad will do, but I recommend something like Visual Studio or Visual Studio Express Web. These tools will warn you of any syntax errors and save you time in the long run.

In this blog I’ll use Visual Studio Express for Web and Chrome as my browser, as it has excellent development tools. IE and FireFox are pretty good as well, so choose your own poison.

Be sure to run your tool as administrator, or you won’t be able to write any of the files. (Later I’ll show you how you can take a copy of the web site to develop away from the server, but let’s keep it simple for now).

In Visual Studio, use ‘Open Web Site’, select local file system and then your site. For me this is C:\inetpub\wwwroot\Citrix\PurpleWeb’ (Substitute your own store name in for ‘Purple’).

If you’d prefer to stick with notepad, note that it will also has to run as admin to allow you to edit the style.css and script.js files in the PurpleWeb\custom directory. For those just cutting and pasting from the blog, this will be just fine.

Note that once the site is loaded into a tool like Visual Studio it looks a bit overwhelming. This is because it contains all of X1 and all of the classic ‘green bubble’ Receiver. You can ignore 99% of this. All we care about is the contents of the ‘custom’ directory, and specifically the style.css and script.js files.

Let’s open style.css and make some simple changes

Add the following to the bottom of the file:

#customTop {

This says. “Find the area called ‘customTop’ (strictly with id=’customTop’) and set its height to 30 pixels and its background color to red.

Reload the X1 UI and you will find it has acquired a new region.

This region is exclusively for customization. A red stripe is fine – but you probably want to put other stuff into it – custom toolbars, messages etc. We will talk more about this next blog. There are two other regions called #customScrollTop and #customBottom. Let’s define them all and take a look.

Add the following to the bottom of style.css. Save, and reload the web page




(Note the pink strip clashes with the copyright message. This will be fixed by release :-) )

The blue strip (#customScrollTop) scrolls with the rest of the page, the other two are fixed. You can make these larger or smaller, or hide/show in different circumstances. As a simple example try adding the following lines:

.myapps-view #customTop {

Back to the web site and you will see that the blue region, is no longer shown on the ‘Favorites’ page. This new statement says “If the ‘customTop’ element lives under an element marked with the ‘myapps-view’ class, then hide it”. (myapps-view is the internal name for ‘favorites’).

Read More


Deploying and Branding Receiver X1

An article by Richard Hayton from Citrix Blogs

This is my second blog post in a series related to the Tech Preview of Receiver X1. In my first, I provided background and explained the rational behind X1. This blog is more practical – a step-by-step guide to help you deploy X1. I’ll also show you how to make some simple but powerful customizations to brand X1 to your company colors.

The Tech Preview download is StoreFront 2.7. This is an iteration on 2.6. While there are features beyond X1, I’m going to focus exclusively on X1. For the tech preview, there is no upgrade support. So, please start with a clean machine, or uninstall StoreFront first. (The GA release will support upgrade from earlier releases, but not from the Tech Preview itself).


As a Demonstration,
I’m Going to Install and Use StoreFront on a Virtual Machine.

I’m using Windows 2012 R2 (see the release docs on the download page for full list of supported platforms). The machine should be domain joined, but there are no other pre-requisites.

Step-By-Step Guide

First, download and run the installer. You will need to be an admin to compete the steps I’m demonstrating.


Handle any UAC prompts. (Yes I know it says ‘Citrix Delivery Services’ not ‘Citrix StoreFront. Know that we are currently addressing this obvious bug.


Go through all of the obvious steps until you get to to this point.

Once you click ‘finish,’ the admin console will be opened. (You can open this again by running ‘StoreFront’ from the start screen).

Hint: Pin to task bar


The StoreFront UI should be familiar to previous StoreFront admins. No big changes here:

Read More


vCenter Server 6.0 Deployment Guide

An article by Mike Brown from VMware vSphere Blog » vSphere


Over the course of the last few months I’ve been working on a pretty massive deployment guide for vCenter Server 6, the result turned into a 100 page guide. Before getting scared off by the size the guide it goes into details for installing and upgrading many different scenarios including new installs and upgrades from the most common configurations.

This guide also serves as the documentation for the sso-ha utility that will be available with vSphere 6. Our engineering team has greatly simplified the process of setting up the new Platform Services Controllers in a highly available configuration behind a load balancer. I also go through a sample configuration of how to setup a F5 BIG-IP LTM, this sample configuration can be taken and applied to your load balancer of choice. For support reasons we are recommending NSX, F5 BIG-IP, and the Citrix Netscaler, but there is no reason another load balancer that meets the requirements won’t work. That said, the current versions of NSX do not fully meet the requirements, I’ll have a post closer to GA detailing what needs to be done to use NSX.

I really enjoyed putting this guide together and I hope it aides you in your journey to vSphere 6.
You can download the vCenter Server 6.0 Deployment Guide from:


Wrapping and Uploading of Apps for Windows 8.1 Device

An article by Devdas Sagar from Citrix Blogs

This blog helps in understanding the steps to wrap apps to be used with Windows 8.1 devices. The process is same for XenMobile Server v9.0 and v10.0.

Below are the pre-requisites for wrapping apps for Windows 8.1 as on February 2015:

  1. Computer running 64 bit version of Windows 7 or 8.1 Operating system
  2. Latest MDX toolkit for Windows 8.1 downloaded from Citrix Download page
  3. Latest Worx Apps from Citrix Download page
  4. .NET Framework 4.5 or higher
  5. Microsoft Silverlight 5 runtime and SDK for Windows 8.1
  6. Microsoft Visual Studio 2013 (Update 3 or later) with Windows 8.1 SDK tools
  7. Open a Microsoft Windows Store Developer Account (Corporate account type). For more information, refer Account types, locations, and fees.
  8. Obtain a Publisher ID (PHONEPUBLISHERID) from the Windows Store developer account profile. For more information, refer Managing your profile.
  9. Acquire an enterprise certificate from Symantec to sign Windows mobile apps. For more information, refer Company app distribution for Windows Phone.
  10. Create an Application Enrollment Token (AET) using Windows Phone SDK tool. For more information, refer How to generate an application enrollment token for Windows Phone.

Download and Extract MDX Toolkit

You can download the MDX Toolkit from Citrix Download page. You need to login with your Registered ID to access the download page.

1. Download the MDX Toolkit from Citrix Download site:


2. Extract the MDX Toolkit zip file onto a local drive on your computer

Note: Make sure you have the pre-reqs in place, including the Worx Apps downloaded from Citrix Download page.

Wrapping of Apps

In order to publish the Worx Home and WorxApps, you need to wrap them. The command used to wrap WorxHome is different than that of WorxMail and WorxWeb.

Note: Signing an App and wrapping an App convey the same meaning.

Follow the below steps to wrap apps.

1. Make sure you have the Worx apps, Enterprise certificate and Application Enrollment Token (AET) downloaded and stored at a location on local drive

2. Login to Command prompt and navigate to the location where the MDX Tool kit is installed

Read More


NetScaler Policies – Simplifies Client-IP Insertion on Backend

An article by Abhilash Verma from Citrix Blogs

As the CDN networks and Secure Web Gateways grow in terms of practical usage, it becomes even more challenging to preserve the Client-IP throughout the path to the last leg. We get this question often. We addressed it directly in this 2012 blog post: ( What we did not cover was the actual implementation of this concept as how one can read the IP address from incoming TCP Options and insert it into the HTTP header going to backend server/app.


Using TCP Options To Insert Original Client-IP And Also Preserve It Through The Stream Has Become a Common Use Case

In most cases while NetScaler is deployed as reverse proxy, we sit close to the Server side on the network and hence we become the last proxy request passes through. At backend, it is required to get original Client-IP from logging, compliance and application perspective. Hence NetScaler becomes the logical place where you retrieve the IP from TCP options and insert it into the HTTP header going to the backend server/app. Here is an example of Rewrite policy/action which achieves the same for you.

Read More


Citrix XenServer: How to Access XenStore Information, from a Windows Guest VM, Using WMI Interface

An article by Rachel Berry from Citrix Blogs

A while ago I wrote a Knowledge Base article (CTX136426) documenting the Windows Management Instrumentation (WMI) available in XenServer to transfer data between the hypervisor and an operating system within a VM such as a XenDesktop or XenApp VD. I still frequently get enquiries on our SDK forum that are basically looking to see if such an interface exists so I’m republishing my article here in the hope that google finds it easier to index!

The WMI interface in XenServer uses the underlying Xen hypervisor XenStore datastore. It is of particular use to developers looking to build products for the XenServer platform such as anti-virus or backup products for XenDesktop or management/monitoring solutions. However it could also be exploited by an experienced System Administrator to develop their own scripts and tools. WMI offers a mechanism to access information about a Windows Virtual Machine from within the guest Virtual Machine (VM), such as the name of the VM or its IP address.

I had a lot of help from a very helpful XenServer developer (Ben Chalmers) in their Windows tools team to write this article, he even wrote several code examples below to get others started.

The information is fairly technical but we’ve had a lot of requests for more technical blogs recently, such as feedback from the UK User Group. We do try to listen and accommodate all tastes ;-)


The History of This Functionality

The XenStore_Client.exe is a small executable program that was (in previous versions of XenServer) distributed with the XenServer Tools and enabled users to access the value of parameters contained in XenStore. This program was removed from XenServer 6.1.0 as there was no knowledge of dependencies or other consumers. However, after the program was removed, Citrix noticed that there were users relying on this unsupported tool. XenStore_Client.exe was never officially supported or tested.

XenServer 6.1.0 introduced an alternative mechanism for extracting XenStore information by using Windows Management Instrumentation (WMI), which offers a far richer interface. This article provides information about using WMI for extracting XenStore information.

Developers wishing to use XenServer 6.2.0 and above and the Windows guest WMI interface as for communicating with XenStore and other hypervisor interfaces should read CTX136422 outlining its usage and providing code examples. The WMI interface can be used in XenServer 6.1.0 as an alternative to XenStore_Client.exe which was available in earlier versions of XenServer.



The XenStore_Client.exe is a small executable program that was (in previous versions of XenServer) distributed with the XenServer Tools and enabled users to access the value of parameters contained in XenStore. This program was removed from XenServer 6.1.0 as there was no knowledge of dependencies or other consumers. However, after the program was removed, Citrix noticed that there were users relying on this unsupported tool. XenStore_Client.exe was never officially supported or tested.

XenServer 6.1.0 introduces an alternative mechanism for extracting XenStore information by using Windows Management Instrumentation (WMI), which offers a far richer interface. This article provides information about using WMI for extracting XenStore information.


This article is for (XenServer 6.1.0 and above) customers who use the Windows guest WMI interface as for communicating with XenStore and other hypervisor interfaces. The WMI interface can be used in XenServer 6.1.0 as an alternative to XenStore_Client.exe which was available in earlier versions of XenServer.

Read More


Making the Citrix License Server (Truly) Highly Available

An article by Nick Rintalan from Citrix Blogs

I’ll begin by saying that this solution is certainly not for everyone. It adds complexity. It creates additional management overhead. It requires NetScaler integration and mildly advanced networking skills. We have never publicly documented the solution before this week. But it is absolutely the only bulletproof solution for making our License Server (LS) truly highly available in an active/active fashion without any downtime.

And while we finally got around to documenting the solution this past week, it’s not like this is a “new” solution we just invented. Our Consulting team has quietly kept this solution in our bag of tricks and actually been implementing this (or subtle variants) for our largest customers with the most demanding uptime/resiliency requirements for several years now. But this past week while working with Entisys on a XA design for one of our largest customers in the world (~5k XA servers – not a typo), we made the solution even better by lab’ing it all up, doing some Wireshark traces to find every port being used and testing some advanced failover scenarios to simulate black holes and acquisition errors (which can cause our License Server to NOT go into grace period, and ultimately create a DoS and take down an entire Citrix environment in minutes).


The Bottom Line

I am not going to go into a ton of detail here (since Dane has already done a fantastic job documenting the solution and all the details here), but a few quick comments on how the solution works at a high-level:

  • We stand up 2 Citrix License Servers with identical hostnames on separate networks (non-domain joined)
  • We utilize NetScaler and PoSh to intelligently monitor all LS services and ports on each LS
  • We direct traffic to only ONE LS at any given time (this ensures EULA compliance)
  • Only when the primary LS is “down” (black-holed or otherwise), we failover and start routing traffic to the secondary LS (which is already up and has all licenses installed)

Read More