So what is cloudbursting and why would you want to do it?  Cloudbursting is the ability to expand your existing datacenter infrastructure into the cloud.  This could be useful at times of high demand, for instance seasonal peaks around Christmas, or if your existing infrastructure loses capacity in a disaster recovery situation.

One of the major stumbling blocks on the way to widespread acceptance of utilising cloud infrastructure is the fear in the eyes of many executives of losing control of their data.  What happens when your critical data is stored on someone else’s infrastructure?  Is it secure?  Is it reliable?  Is the support good enough?  What are the response times?  Can you believe the providers when they say you don’t have to worry about your fears?

This is why a XenApp workload is particularly suitable to cloudbursting, there shouldn’t be any data stored on XenApp servers.  Also they should all be identical, making them conducive to fast provisioning.

Imagine the situation of a sales call center, over the xmas period they hire temp staff to cope with extra demand, as their software is provided via XenApp, the company needs to have enough infrastructure to cope with the demand peak, but sits idle most of the year.  As EC2 charges per hour then the ability to use EC2 to cope with the extra demand could save large sums of money.

Now we have decided that cloudbursting is a good idea, can we actually do it?  By this I mean are the tools available off the shelf, without a large development effort.

So what do we need?

• A secure link between the cloud and your datacenter
• The ability to quickly provision and decommission servers in the cloud
• WAN acceleration between the cloud and you
• Monitoring to know when to cloudburst
• Automation to control it all

Lets take these needs one by one:

A secure link between the cloud and you, currently Citrix provide an Amazon Machine Image (AMI) template for Citrix Access Gateway (CAG) with one in the cloud and one in the premise you can have a secure channel between the two. You could also use the Vyatta AMI.  Full marks

With the new workflow studio library we can quickly provision our own saved AMI’s and destroy them when needed.  The question here is why are we not using Provisioning server?  It would be best to provision a ‘bare metal’ server and PXE boot to receive a provisioning server vdisk. So Half marks.

WAN acceleration is possible, you can install the software repeater client on the XenApp servers, but a proper Repeater AMI would be better. Half marks again

Monitoring could be done either with Edgesight or the power and capacity management feature, so full marks.

Automation is the big problem, although workflow studio, now it’s 2.0 with more libraries, is getting there, at the moment it simply doesn’t have enough pre-configured workflows or libraries to cope.  We need a way to join the Servers to the domain and farm and publish the applications. (Although XenApp 6 will let us do this using GPO’s). We could script this, but I want to do it without any dev work. It also needs to be able to take in the output from the power and capacity management feature set.

So where does that leave us?  I’d say it leaves us almost there, in fact with a little powershell knowledge and using the tech preview of XenApp 6 it’s possible right now.

If I have time over the holidays I think I’ll try and set it up and let you know how I get on.

With the announcement of the inclusion of the PC over IP (PCoIP) Teradici in VMware View this week at VMworld.  I think that there is something people may be missing.

The big disadvantage of the original hardware to hardware PCoIP implementation was that each connection to the server required it’s own Teradici card.  This is obviously not a scalable solution.  As the software to software solution is unveiled at VMworld, the attention seems to be on the fact you can get the performance without stuffing your servers full of Teradici cards.  To my mind the software to software approach has a big flaw, you need power on the client. Power on the client means either a full PC on the other end, which defies the point, or a really expensive thin client.

The real key would be to go from software to hardware.  A software client on the server communicating with a hardware Teradici chip on the client.  You could avoid all the issues of managing the ‘almost PC’ modern thin clients and go back to the cheap, minimal management, devices I think thin clients should be.

I’m curious as to why this is not being made more of as the client devices are already there like this one from Samsung and if you look at the Teradici video on Brian Maddens site they say it will work.

As the devices get cheaper, maybe down to about $200 with the great performance of PCoIP I can see this being the ‘killer app’ for VMware in this space.

Generally the ICA client doesn’t get much attention, undeservedly so in my opinion.  So I decided to make this guide as a quick reference sheet for all you need to know about the Windows client for Citrix XenApp.

Most people install the client when they set up their first farm and forget about it, maybe upgrading with a major server refresh.  The people who leave old clients on their desktop estate are missing out on a whole lot of functionality.  So my first and most basic bit of advice is to upgrade your clients!

As the first bit of advice is to upgrade I’ll show you how to best do that below.  The rest of this post will only be relevant for clients from 10.2 onwards, if you have an earlier client, I’m sorry, but this post isn’t for you.

For a complete list of the features included in the latest client have a look at the Citrix Client Feature Matrix PDF.  Hopefully the new cool stuff (and the weird errors from supporting a mess of clients) has persuaded you to upgrade your desktop estate to the latest client which at the time of writing is the ‘XenApp Plugin for Hosted Apps’ 11.000.

A lot of administrators don’t even know which client versions they have out there, and unfortunately Citrix doesn’t help you very much in this regard, as it only shows the build numbers for connected clients and not the version numbers i.e. version 10.2 shows up as 02650.  In XenApp 5.0 and later, this client build number can be seen by selecting the user session in the Access Management Console and selecting the Client Build Number column.  So now you need to know what the build numbers mean.  The knowledge base article CTX112613 will give you this information.

Obviously once you have decided to upgrade your clients you need a way to distribute them.  To do this your standard software distribution method will be fine.  To create a silent installation download the latest client to your local drive and run the following command:

msiexec.exe /a XenAppHosted.msi

This will give you all the options you need to create a silent installation package tailored to your enterprise ready for distribution.

If you run into issues with upgrading clients and need a clean machine for install you can use the free tool from Gourami to remove all traces of the client from 2000/XP/Vista or Windows 7 machines.  If you aren’t comfortable with the tool you can use CTX325140.

So, now you have an estate of updated clients, but you need more granular control over the client behaviour.  You can get this by using a GPO, first you need to import the handy icaclient.adm administrative template. You can usually find it in “C:\Program Files\Citrix\ICA Client\Configuration”.  With this template you can control almost all aspects of the client behaviour, with the one weird exception being that you cannot manage the pnagent url.  The main topics in the template are:

• Network routing
• User Authentication
• Remoting Client Devices
• User Experience
• Client Engine

In most cases this should be enough to sort out most of your problems, if you have any niggling connectivity issues you should use the Troubleshooting ICA 32-bit and Web Client Connectivity CTX075552 article.

At the time of publishing there is a tech preview of flash remoting available on Citrix’s website, all I can say is it works superbly given the restrictions of the fact it is beta code.  Stick it in your test environment and have a go.  For more information on the future of protocols see my previous post: How games will show who is the remote protocol winner.

Finally, I have some tuning tips for your environment, I think most of these should probably be in the icaclient.adm file, but we’ll see if they make it into a future release.  If anybody has any more client side tips, please let me know in the comments and I’ll add them to the table.

Lastly, although this is not strictly a client side change, if you are accessing a XenApp Server on Windows 2008 with a client version less than 11.0 you will need to install KB949914 on the server to stop your clients crashing.

If remote protocols are almost exclusively used in regard to business applications, why are games important?  The reason is that if I try and think of what would be the hardest thing to do over a remote protocol, it would be to play games with the same quality as you would see them on your desktop.

Of course I’m not talking about web based flash games, I mean full on, high frame rate with lots of 3D and explosions, all in DirectX with HD sound games, actually lets add some kind of TeamSpeak in there too.

There are two goals in respect to remoting protocols:

• Get desktop behaviour no matter the application over the LAN
• Scale the fidelity of the connection according to the bandwidth and endpoint device

The first case is the one I want to talk about, VDI and TS vendors need to be able to prove that their remote protocol can cope with any type of application or companies are not going to be convinced that the old bugbears of bad sound and choppy video poorly synced are over.

If people are out there touting the ‘better than desktop experience’ line I want to see it and as yet the performance just isn’t quite there.

When Microsoft bought Calista back at the beginning of 2008, I had hopes that the features they were working on would have made it into RDP by now, but they just announced that their remote DirectX technology isn’t going to make it into final release.

VMware have the software Teradici stuff in the works and I have no doubt something from Citrix is out there.

The wild card as regards remote protocols go is a company called OnLive who plan to provide games over the cloud remoted to your PC.  I’ve no clue how it works, but I’m anxious to see.

Wouldn’t it be interesting to see someone get up on stage and demo a game over a remote protocol?  I wonder who’s going to be first?  I would say that in the court of public opinion, even if not quite in the technical detail (silverlight etc) then they would have ‘won’.

I’ve always had customers ask me, why can’t I just use VOIP over Citrix, when it works to talk to my niece in Oz?  Once we have good quality bi-directional audio the second device on the users desktop can disappear.  Once we have rich multimedia, users will no longer have to manage without seeing that great presentation from their CEO .

People are talking about Avistar at the moment in regards to this, but from the brief time I’ve had to look at it I think it requires some kind of broker server in the middle.  So if anyone can enlighten me a bit more about exactly what they do and how they do it, please leave me a comment.

Edit:  It seems I’m not the only one thinking about protocols

Virtualization Display Protocol Wars

Brian Madden on Calista

Small application vendors need to raise their game, it’s no longer good enough to code an application, check it works on your local copy of XP or Vista and sell it to the customer.  Terminal services has been around fifteen years, and Application Virtualisation five years, these are no longer new technologies.  If I phone up a vendor and ask them what’s the correct way to install their application on terminal services or App-V, I don’t want to hear ’sorry that isn’t supported’.

The tools part is starting to get really interesting, Apptitude have released their App-DNA product, which will test whether your app is suitable for Citrix, App-V, Windows 7, x64 and more.  If you have an MSI, it only needs to look at the MSI tables, you don’t even have to install the application to get the report.

Acresso, the folks who make Admin Studio, have developed a new feature which allows direct conversion from an MSI to an App-V, Citrix Streaming or VMware ThinApp package.

Both the above technologies can drastically reduce the time taken to implement new application delivery methods.  To best take advantage of both tools you need applications provided in an MSI format.

The main reason that I have found applications not being delivered in the correct format is that organisations have not realised that it is vital that the IT department of any organisation is involved in the decision making process when it comes to purchasing new applications, at the very least they need to set the minimum standards required:

• The application should be provided in an MSI format
• The vendor must suport multi user OS deployment
• The vendor must support application virtualisation/streaming

If you are an application vendor and it’s ‘too much effort’ to support the above minimum standards, I would suggest you are cutting yourself off from a large and growing sector of the market.

If you develop applications in-house or are purchasing a bespoke product, there is no reason why standards should slip, apply the same set of rules to these as you would to an off the shelf product.  A bit more development time, is going to save you a whole lot of heartache in the future.

Last week I watched a webinar by Daniel Feller who is the “Server, desktop and application virtualization senior architect from Citrix” and he went into why it might be a good idea to stream all your apps.  He did say that since it normally wasn’t possible to stream all apps, mixed mode environments were what you would expect, with some streamed and some installed applications.

If you want to watch the webinar its recorded here TechTalk: Fact vs. Fiction: The Truth about App Compatibility & Citrix.

I like to keep things as simple as possible and anticipating using two technologies to put apps onto a Citrix server seems the wrong way to me, I’d much rather just use one.

As streaming can’t cope with drivers, services or apps that license based on MAC address you are likely to get at least a few that are not suitable for streaming.

Installing has a much higher hit rate than Streaming, most of the issues around multi user apps have now been solved including DLL Hell.

I’d say your first impulse should be to install your apps, if you think you can get them all without any silos.  So columns one and two should be reversed.

If you need help getting your apps to work, have a look at this application validation toolkit

When installing applications you need a reliable way to build and re-build servers, re-install and update apps, while it is possible to script, a more reliable method should be used. You could use a generic server build tools or there are more specialist advanced building tools available from Citrix partners.

To work this out we need to start from first principles, way back in 2005ish.  We had many expensively maintained fat desktops, spare CPU cycles in the data center and a virtualisation layer.  This meant that we could take the fat desktops not already covered by terminal server (which only counted for around 20%) and move them into the data-center.  These new desktops would allow our users to install apps, personalise their OS, and IT could keep the environment stable.  People were saying things like ‘I can give my users local admin privileges!’.

That was the dream and it all sounded pretty good.  Then people realised that they would have to change cheap storage on the end point for expensive storage in the data-center.  Also it just seemed, well silly, to have 5000 copies of explorer.exe sitting on the SAN.  The advantages of data de-dupe were talked about, but the model that everyone settled on was a golden OS image, Citrix had Provisioning Server and VMware had linked clones.  Not only did this solve the high SAN demands, it enabled us to only update/patch one golden image and it worked for everyone! Double win!

So now we have thousands of users on one golden image, trouble is we need different application sets.  No Problem! said the industry, we have application virtualisation, it’s even a fairly mature technology, ThinApp, Citrix Streaming, App-V and all the rest.  Except not all applications are suitable for streaming, some have license requirements that rely on MAC addresses, some install drivers or services, etc. etc.

In any large organisation there are maybe 2% of these applications which are generally more than 10 years old, but that can’t be dumped.  Out of say six hundred apps that’s only twelve apps that need to be in the golden image, so we increase the number of golden images to twelve, and the rest of the applications are streamed.

So far so good, although with this golden image model, we have hit a snag, to allow users to install applications, we need to use block level deltas to save the personal information.  Over time these block level deltas can grow to the size of the original installation, ruining our nice SAN space saving ideas!  Not only that, when you update the base image you can’t reconcile the deltas, you have to throw them away.  That’s no good, you can’t give users a facility and then randomly remove their changes.  OK, lets lock down the OS, we can use a profile solution to save user personalisation using the file system (although obviously no user installed apps).  For a great explanation of block vs file see Brian Madden’s post “Atlantis Computing hopes to solve the “file-based” versus “block-based” VDI disk image challenge ”

Lots of vendors already in the Terminal Server space, immediately said ‘We have a profile solution!’ and Appsense, RES, RTO, Tricerat etc put out VDI profile solutions.

All of this worked great in the POCs and pilots, trouble is when it scaled up to 1000s of users we found that the power users who were moving gigs of VMDK’s around or working with large media files etc. meant we had to have REALLY expensive Tier 1 storage at the SAN, it became uneconomical to move those users to VDI so we left them on their fat desktops.

So where does that leave us on our big VDI project?

• Multiple users on an OS image
• Application silos
• Locked down desktops
• Profile solutions from Appsense, RTO, RES etc.
• Users limited to Task and knowledge workers
• Oh yeah, print solutions from Citrix and ThinPrint.
• Desktops accessed via RDP or ICA

I mean what does that sound like to you?  To me it sounds EXACTLY like Terminal Server.  What we have done is taken a VDI dream and apply terminal server thinking to it, unsurprisingly, it’s now looking just like terminal server, but with extra licensing costs.

We need to apply some brand new thinking, there are vendors out there trying to do this, like the afore mentioned Atlantis, but before VDI really takes off we need to rethink a lot of things or Gartners prediction of VDI being a $65 billion business with 40% of the worlds professional desktops seems to be a long way off.