You are here: Home > Blog

Earlier this week, I had a long discussion with a client (you know who you are) about what licenses they would need for a deployment of “zero client” devices. We’ve written a lot about Microsoft and Citrix licensing, about XenDesktop and XenApp, about the Citrix trade-up, etc., but it occurred to me that it might be beneficial to pull all the licensing information together into one post instead of expecting you, gentle reader, to have to sort through multiple posts to pull it all together.

So, let’s discuss Citrix licensing first, then move on to the Microsoft licensing.

First of all, if all you want to do is to deploy VDI (Virtual Desktop Infrastructure), and you have a limited number of users, then you should probably purchase VDI-in-a-Box. You can read more about this in our April Moose Views article about XenDesktop vs. VDI-in-a-Box.

If you decide that VDI-in-a-Box is not the right fit foryou, the next question you need to answer is whether to use XenApp licenses or XenDesktop licenses. Beginning with the introduction of XenDesktop v4.0, Citrix concluded, reasonably enough, that an organization that was deploying VDI probably wouldn’t get much leverage from a concurrent-use licensing model, because their concurrency ratio (by which I mean the ratio of total users to concurrent users) would be pretty close to 1:1. So XenDesktop v4.0 was introduced with a per-named-user or per-device license model. These licenses were roughly half the cost of the comparable XenApp concurrent-use license: XenApp Enterprise Edition, for example, carries an MSRP of $450 per concurrent user. XenDesktop Enterprise Edition carries an MSRP of $225 per user/device.

At the same time, Citrix made the decision to include XenApp rights in the XenDesktop license. So if you buy XenApp, you get only XenApp. But if you buy XenDesktop, you get both XenDesktop and XenApp – so you can use XenApp to stream applications to your virtual desktops, or have your virtual desktops function as client devices that run published applications that execute on the XenApp servers, or simply deploy a mixture of XenDesktop and XenApp to your user community depending on what delivery method is best for a particular use case. This is what Citrix refers to as the “FlexCast” delivery model.

This created the interesting situation where, because of the difference in license cost, if your concurrency ratio was less than 2:1, you were better off financially to purchase XenDesktop licenses even if all you really wanted to run was XenApp. And, since delivering what Citrix calls “hosted shared” desktops from XenApp servers makes more efficient use of the underlying hardware and storage infrastructure, the bias should probably be toward XenApp unless there is a clear use case for why users need to connect to individual desktop OS instances rather than a shared XenApp desktop (and it isn’t just appearance, because with XenApp v6.5 on Windows Server 2008 R2 we can deliver a XenApp desktop that looks and feels like a Windows 7 desktop). But, for the sake of this discussion, let’s move on down the XenDesktop trail.

Citrix has re-introduced a concurrent-use license option for XenDesktop, which is a better choice for organizations who want to deploy both XenDesktop and XenApp, but have a concurrency ratio greater than 2:1, but so far, I haven’t seen very many use cases where that license model made sense.

If you already have XenApp licenses, and want the ability to deliver VDI as well, you can take advantage of the Citrix trade-up program to transform your XenApp licenses into XenDesktop licenses. And if you trade up all of your XenApp licenses, you can get two XenDesktop user/device licenses for each XenApp license. So 250 XenApp licenses would become 500 XenDesktop user/device licenses. If you want more information on how the trade-up program works, and what your trade-up options are, check out the handy Citrix Trade-Up Calculator.

As of the release of XenDesktop v5.0 Feature Release 1, the license service got pretty smart in terms of how it managed those user/device licenses. This is good news for, say, a hospital, which may have devices that are used by multiple users and other users who use multiple devices. The license server can intelligently and dynamically reassign licenses between users and devices to make the most efficient use of the available licenses. For example, consider the following scenario for a brand-new environment where no licenses have yet been assigned:

  • User 1 logs on from client Device 1. The license server will, by default, check out a license to User 1.
  • User 1 logs off, and User 2 logs on from the same client device. The license server, now sensing that two different users have logged on from the same device, will take the license that was assigned to User 1, and reassign it to Device 1. Any subsequent users who log in from Device 1 will not cause any action by the license server, because Device 1 is already licensed.
  • If User 1 logs on again from a different client device, the license server will again check out a license to User 1 (so, at this point, two licenses are checked out: one to Device 1 and one to User 1). Since User 1 has logged on from two different devices, the license will remain assigned to User 1 unless/until manually released by an administrator (e.g., in the case of the employee leaving the organization), or unless User 1 doesn’t log on for a period of 90 days, in which case it will be automatically released due to inactivity.
  • Likewise, since two different users have logged on from Device 1, that license will remain assigned to that device unless manually released or automatically released due to 90 days of inactivity.

So…how do you know how many licenses you really need? There is actually a formula that will tell you that. You need to know how many total users you have (let’s call that number “A”), how many shared devices you have (let’s call that “B”), and how many of your users will use only shared devices (let’s call that “C”). The formula is A – C + B. So, if you have 1,000 total users, 300 shared devices, and 600 of your users will use only shared devices, you need 1,000 – 600 + 300 = 700 total licenses.

For more information on exactly how this works, see the Citrix Community Blog post by Christophe Catesson, which in turn links to a recorded session from Synergy 2011 that was a deep dive discussion of XenDesktop licensing.

Now for the Microsoft licensing component.

If you have users who will be executing applications on a XenApp server, you will need a Remote Desktop Services (RDS) CAL for that user, or for the client device that user is using. It is very difficult to manage a mixture of user CALs and device CALs in a Remote Desktop Services environment, so, in most cases, you’re going to be better off purchasing user CALs.

If you have users who will be attaching to a virtual desktop instance, the licensing requirements are different, depending on the client device. If the client device is a Windows PC whose Operation System is covered by Software Assurance, you do not have to purchase any additional Microsoft license to use that PC to connect to a virtual desktop. If the client device is not a Windows PC, or that copy of Windows is not covered by Software Assurance, you need a Virtual Desktop Access (VDA) license for that client device. VDA licenses are only available under the Open Value Subscription license model at present, meaning that you will continue to pay for them every year. Forever.

But wait! That’s not all! As Gabe Knuth outlines in a recent article on Techtarget.com, there is a very strange loophole in the VDA license terms. If you have a VDA license for your primary device (or if it’s covered by Software Assurance), you have what Microsoft calls “Extended Roaming Rights,” which allow you to also use your home computer to access your virtual desktop, or use your iPad when you’re at home or traveling. But, technically, it does not entitle you to bring your iPad into the office and use it there! To solve that (using the term “solve” loosely), Microsoft recently announced something called a “Companion Device License” (CDL) which allows you to use up to four other devices (in addition to the primary licensed device) to access your virtual desktop. No word yet on what the CDL will cost.

So let’s see if we can summarize what our client would need for a deployment of “zero client” devices (like, for example, the Wyse Xenith thin client).

  • You’re going to need some kind of Citrix license, either VDI-in-a-Box, XenDesktop, or XenApp.
  • Since the thin client is not a Windows PC, and therefore cannot be covered by Software Assurance, you would need to purchase a Microsoft VDA license for it.
  • If the thin client will be used only to attach to a virtual PC desktop and execute applications within that desktop OS environment, no additional Microsoft license is needed. However, if the thin client will also be used to attach to applications that are executing on a XenApp server – either directly or indirectly by having the Citrix client baked into the virtual PC desktop – you will also need a Microsoft RDS CAL.
  • You do not need an RDS CAL if you are only using XenApp to stream packaged applications to a virtual (or physical, for that matter) desktop for execution there. Since you are not actually utilizing Remote Desktop Services by executing code remotely on a Remote Desktop Server, no RDS CAL is required.
  • If you want to institute a BYOD program, where users can bring whatever client device they wish into the office and use it to access your VDI, you’ll probably need some of the new Microsoft CDL licenses.

If I’ve overlooked anything, feel free to submit questions via comments on this post, and we’ll try to get them answered. Let the discussion begin!

We’ve written a lot here regarding XenDesktop’s two provisioning methods: Provisioning Services and Machine Creation Services. Earlier this week, at the Citrix Synergy Conference in San Francisco, there was a session specifically devoted to discussing those two provisioning methods, providing a high level overview of how they worked, the best practices for deploying each of them, and even some guidelines for how to determine which approach is best for your organization. For the benefit of those who couldn’t make it to Synergy – or those who did make it, but would like a better way to share that information with others in their organizations – that session was recorded and is available on Citrix TV. You can view it below:

Last Friday (May 4), the news broke that Citrix had made some changes in their “End of Life” (EOL) dates. Just a couple of months ago, in our March issue of the Moose Views newsletter, we told you that if you were running any version of XenApp other than XenApp v6.5 on Windows Server 2008 R2, you needed to start seriously planning for your migration, because by mid-July of next year (2013), those older versions will all hit their EOL dates.

Apparently Citrix has been feeling some heat from customers who weren’t too happy about that, so they have announced something new called “Extended Support,” that will be available after EOL for an additional fee – which was not specified. The “End of Extended Support” (EOES) dates have been aligned with the comparable Microsoft dates for the underlying server Operating System.

The odd thing about this is that the EOL dates have not changed (except for XenApp v6.0, which will now hit EOL on January 2, 2015). It’s just that EOL doesn’t mean what it used to mean. Previously, when a Citrix product hit EOL, that meant there was no support available for it whatsoever. Now, apparently, “End of Life” means “End of Life Unless You Pay Us More Money to Keep Supporting You.”

For the record, the EOES dates for the versions of XenApp that run on Server 2003 have been set to July 14, 2015, and the EOES dates for the versions that run on Server 2008 (and 2008 R2) have been set to July 10, 2018.

You can read more about this on the Citrix Product Matrix Web page.

As of now, the Extended Support program for XenDesktop is still being defined…

There is a lot of buzz about Citrix VDI-in-a-Box (“ViaB”), and rightly so: it’s a great product, and much simpler to install and easier to scale than a full-blown XenDesktop deployment. You don’t need a SAN, you don’t need special broker servers, you don’t need a separate license server or a SQL Server to hold configuration data. Unfortunately, some of the buzz – particularly some of the cost comparisons you see that show a $3,000 – $4,000 server for 30 or more virtual desktops, is misleading. So let’s talk seriously about the right way to deploy ViaB. For this exercise, I’m going to assume we need 50 virtual desktops. Once we’ve worked through this, you should be able to duplicate the exercise for any number you want.

First of all, I’m going to assume that we are building a system that will support Windows 7 virtual desktops – because I can’t see any valid reason why someone would invest in a virtual desktop infrastructure that couldn’t support Windows 7. There are two important data points that follow from this: (1) We should allow at least 1.5 Gb per virtual PC, and preferably 2 Gb per virtual PC. (2) We should design for an average of about 15 IOPS per Windows 7 virtual PC, because, depending on the user, a Windows 7 desktop will generate 10 – 20 IOPS. Let’s tackle the IOPS issue first.

Thanks to Dan Feller of Citrix, we know how to calculate the “functional IOPS” of a given disk subsystem. Here are the significant factors that go into that formula:

  • A desktop Operating System – unlike a server Operating System – has a read/write ratio of roughly 80% writes and 20% reads.
  • A 15K SAS drive will support approximately 175 IOPS. The total “raw IOPS” of a disk array built from 15K SAS drives is simply 175 x the number of drives in the array.
  • A RAID 10 array, which probably offers the best balance of performance and reliability, has a “write penalty” of 2.

With that in mind, the formula is:

Functional IOPS=((Total Raw IOPS x Write %)/(RAID Penalty)) + (Total Raw IOPS x Read %)

If we put eight 15K SAS drives into a RAID 10 array, the formula becomes:

Raw IOPS = 175 x 8 = 1,400

Functional IOPS = ((1,400x.8)/2)+(1,400x.2) = 560 + 280 = 840

If we are assuming an average of 15 IOPS per Win7 virtual PC, this suggests that the array in question will support roughly 56 virtual PCs. So this array should be able to comfortably support our 50 Win7 virtual PCs, unless all 50 are assigned to power users.

That’s all well and good, but we haven’t talked yet about how much actual storage space this array needs. That depends on the size of our Win7 master image, how many different Win7 master images we’re going to be using, and whether we can use “linked clones” for VDI provisioning, in which case each virtual PC will consume an average of 15% of the size of the master, or whether we’re permanently assigning desktops to users, in which case each virtual PC will consume 100% of the size of the master. For the sake of this exercise, let’s assume we’re using linked clones, and that we have three different master images, each of which is 20 Gb in size. According to the Citrix best practice, we need to reserve 120 Gb for our master images (2 x master image size x number of master images). We then need to reserve 3 Gb per virtual PC (15% of 20 Gb), which totals another 150 Gb. The ViaB virtual appliance will require 70 Gb. We also need room for the hypervisor itself (unless we’re provisioning another set of disks just for that) and for swap file, transient activity, etc., so let’s throw in another 150 Gb. That’s 490 Gb minimum. So we need to use, at a minimum, 146 Gb drives in our array, which would give us 584 Gb in our RAID 10 array.

How about RAM? If we allow 1.5 Gb per Win7 desktop, then 50 virtual desktops will consume 75 Gb. We need at least 1 Gb for the ViaB appliance, at least 1 Gb for the hypervisor, plus some overhead for server operations, so let’s just call it 96 Gb.

We can handle 6 to 10 virtual desktops per CPU core – more if the cores are hyper-threaded – so we’re probably OK with a dual-proc, quad-core server.

Now, I don’t know about you, but if I’m going to put 50 users onto a single server, I’m going to want some redundancy. I will at least want hot-plug redundant power supplies, and hot-plug disk drives. Ideally, I would provision “N+1″ redundancy, i.e., I would have one more server in my ViaB array than I need to support my users. I’m also going to want a remote access card, and probably an uplift on the manufacturer’s Warranty so if it breaks, the manufacturer will come on site and fix it.

By now, you’ve probably figured out that we are not talking about a $4,000 server here. I priced out a Dell R710 – using their public-facing configuration and quoting tool – with the following configuration, and it came out to roughly $11,000:

  • Two Intel E5640 quad-core, hyper-threaded processors, 2.66 GHz
  • 96 Gb RAM
  • Eight 146 Gb, 15K SAS drives
  • PERC H700 controller with 512 Mb cache
  • Redundant hot-plug power supplies
  • iDRAC Enterprise remote access card
  • Warranty uplift to 3-year, 24×7, 4-hour response, on-site Warranty

(NOTE: This is a point-in-time price, and hardware prices are subject to change at any time.)

The ViaB licenses themselves will cost you $195 each. Be careful of the comparisons that show the price as $160 each. ViaB is unique among Citrix products in that the base cost of the license does not include the first year of Subscription Advantage – yet the purchase of that first year is required (although you don’t necessarily have to renew it in future years). That adds $35 each to the cost of the licenses.

Finally, If you don’t have Microsoft Software Assurance on your PC desktops – and my experience is that most SMBs do not – you need to factor in the Microsoft Virtual Desktop Access (VDA) license for every user. This license is only available as an annual subscription, and will cost you approximately $100/year.

So, your up-front acquisition cost for the system we’ve been discussing looks like this:

  • Dell R710 server – $11,000
  • 50 ViaB licenses @ $195 – $9,750
  • 50 Microsoft VDA licenses @ $100 – $5,000

Total aquisition cost: $25,750, or $515/user. Not bad.

But wait – if we’re going to compare this to the cost of buying new PC, shouldn’t we look at the cost of ViaB over the same period of time that we would expect that new PC to last? If we assume, like many companies do, that a PC has a useful life of about 3 years, then we should actually factor in another two years of VDA licenses, and two years of Subscription Advantage renewal for the ViaB licenses. That pushes the 3-year cost of the ViaB licenses to $13,250, and the cost of the VDA licenses to $15,000. So the total 3-year cost of our solution is $39,250, or $785/user.

If you want N+1 redundancy, you’re going to need to buy a second server. That would push the cost to $50,250, or $1,005/user.

What conclusions can we draw from all this? Well, first, that VDI-in-a-Box is not going to be significantly less expensive than buying new PCs, if you actually do it right. However, it is competitive with the price of new PCs, which is worth noting. As long as the price is comparable, which it is, we can then start talking about the business advantages of VDI, such as being able to remotely access your virtual desktop from anywhere, with just about any device, including iPad and Android tablets, and about the ongoing management advantages of having a single point of control over multiple desktops.

Also, as you scale up the environment, the incremental cost of that extra server that’s required for N+1 redundancy gets spread over more and more users, and becomes less significant. For example, if we’re building an infrastructure that will support 150 virtual desktops, we would need four servers. Total 3-year cost: $128,750, or $858.33/user for a robust, highly redundant virtual desktop infrastructure. In my opinion, that’s a pretty compelling price point, and you won’t be able to hit that price point with a 150-user XenDesktop deployment, because of the other server and storage infrastructure components that you need to build a complete solution. On the other hand, XenDesktop does include more functionality, like the rights to use XenApp for virtual application delivery, ability to stream a desktop OS to a blade PC or a desktop PC, rights to use XenClient for client-side virtualization, etc.

But if all you want is a VDI solution, ViaB is, in my opinion, the obvious choice. It’s clear that Citrix wants to position VDI-in-a-Box as the preferred VDI solution for SMBs, meaning anyone with 250 or fewer users…and there’s no reason why ViaB can’t scale much larger than that.

For more information on ViaB, check out this video from Citrix TV, then head on over to the Citrix TV site to view the entire ViaB series

**** EDIT April 12, 2012 ****
You may already be aware of this, but Dell has announced a ViaB appliance that comes pre-configured, with both XenServer and the ViaB virtual appliance already installed. Oddly enough, even though Moose Logic is a Dell partner, I couldn’t get Dell to tell me what one would cost. Their answer was that I should call back when I had a specific customer need, and they would work up a specific configuration and quote it. I considered calling back with a fictitious customer requirement, but decided that I didn’t want to know badly enough to play that game.

They did, however, tell me what the basic server configuration was – and it was very close to the configuration I’ve outlined above: two X5675 processors, 96 Gb of RAM, eight 146 Gb drives in a RAID 10 array, Perc H700 array controller (don’t know how much cache, though), and iDRAC Enterprise remote access card. I do not know whether it has redundant power supplies (although I would certainly hope so), nor exactly what Warranty is included…perhaps that option is left up to the customer.

That gave me at least enough information to run a sanity check on the configuration. The array would provide 960 functional IOPS, which should be adequate for an 80 user system – which is how the appliance is advertised – depending, of course, on the percentage of power users. Also, the array should provide enough storage to handle the needs of most SMBs, unless they have an unusually large number of images to maintain.

One of my Citrix contacts recently told me that the Dell appliance was priced at $440/desktop for an 80 concurrent user configuration, which is very much in line with the cost per user in the post above, considering that $100 of my $515/user number was for the first year of Microsoft VDA licenses, which, to my knowledge, are not included with the Dell appliance.

Mark Twain allegedly came up with the famous line: "Figures don’t lie, but liars figure." That’s a good thing to keep in mind any time you’re looking through a report that was sponsored ("sponsored" = "paid for") by a vendor that concludes that their product is better than the other guy’s.

Maybe it is better than the other guy’s. But you might want to look closely at what was tested, how it was tested, and whether they were, shall we say, selective in the facts they present.

Case in point: The Tolly Group’s report, released May 27, comparing VMware View 4.6 Premier Edition to Citrix XenDesktop 5 Platinum edition. There are several interesting aspects to this report, which are dealt with in detail in Tal Klein’s blog over on the Citrix Community blog site. Here are a few of the more egregious items:

  • VMware View 4.6 Premier licensing costs less than XenDesktop 5 Platinum. Absolutely true, and absolutely irrelevant. That’s like pointing out that if you load every possible dealer option onto your new car, it’s going to cost more than the basic model. Thank you, Captain Obvious. If you want an "apples-to-apples" comparison, you need to compare VMware View to the XenDesktop VDI Edition. But wait, if you do that, XenDesktop is actually less expensive, and that would be an awkward point to publish in a paper that’s being paid for by VMware.
  • VMware’s PCoIP provides a more consistent multi-media experience than XenDesktop 5. (Over a LAN. Using a single thin client device that did not support any of the Citrix HDX media acceleration features.) Sorry, guys, but once again this is not an apples-to-apples comparison. And did they publish any results of testing across a WAN link? Nope…and for the same reason they didn’t use XenDesktop VDI Edition for their price comparison.
  • It’s easier to upgrade View 4.5 to View 4.6 than it is to upgrade XenDesktop 4 to XenDesktop 5. Once again, both true and irrelevant. It’s easier to give your kitchen a new coat of paint than it is to rip out the cabinets and completely remodel it. Anybody surprised by that? There are significant architectural changes from XenDesktop 4 to XenDesktop 5. It shouldn’t be surprising to anyone that this will involve more effort than a "dot release" upgrade.

I’ve always been skeptical of vendor-sponsored "analysis" reports, and, to be fair, Citrix has used the Tolly Group in the past for its own sponsored reports – but it seems to me that this one is just over the top. Apparently, former Gartner analyst Simon Bramfitt agrees. His pithy assessment of the report: "There are undiscovered tribes lost in the darkest parts of the Amazon jungle that would know exactly what to do if a vendor airdropped a pile of competitive marketing literature authored by the Tolly Group; send it back, and asked [sic] that it be re-printed on more absorbent paper."

What do you think?

No, I’m not talking about the weather here in San Francisco – that’s actually been pretty good. It’s just that everywhere you look here at the Citrix Summit / Synergy conference, the talk is all about clouds – public clouds, private clouds, even personal clouds, which, according to Mark Templeton’s keynote on Wednesday, refers to all your personal stuff:

  • My Devices – of which we have an increasing number
  • My Preferences – which we want to be persistent across all of our devices
  • My Data – which we want to get to from wherever we happen to be
  • My Life – which increasingly overlaps with…
  • My work – which I want to use My Devices to perform, and which I want to reflect My Preferences, and which produces Work Data that is often all jumbled up with My Data (and that can open up a whole new world of problems, from security of business-proprietary information to regulatory compliance).

These five things overlap in very fluid and complex ways, and although I’ve never heard them referred to as a “personal cloud” before, we do need to think about all of them and all of the ways they interact with each other. So if creating yet another cloud definition helps us do that, I guess I’m OK with that, as long as nobody asks me to build one.

But lest I be accused of inconsistency, let me quickly recap the cloud concerns that I shared in a post about a month ago, hard on the heels of the big Amazon EC2 outage:

  1. We have to be clear in our definition of terms. If “cloud” can simply mean anything you want it to mean, then it means nothing.
  2. I’m worried that too many people are running to embrace the public cloud computing model while not doing enough due diligence first:
    1. What, exactly, does your cloud provider’s SLA say?
    2. What is their track record in living up to it?
    3. How well will they communicate with you if problems crop up?
    4. How are you insuring that your data is protected in the event that the unthinkable happens, there’s a cloud outage, and you can’t get to it?
    5. What is your business continuity plan in the event of a cloud outage? Have you planned ahead and designed resiliency into the way you use the cloud?
    6. Never forget that, no matter what they tell you, nobody cares as much about your stuff as you do. It’s your stuff. It’s your responsibility to take care of it. You can’t just throw it into the cloud and never think about it again.

Having said that, and in an attempt to adhere to point #1 above, I will henceforth stick to the definitions of cloud computing set forth in the draft document (#800-145) released by the National Institute of Standards and Technology in January of this year, and I promise to tell you if and when I deviate from those definitions. The following are the essential characteristics of cloud computing as defined in that draft document:

  • On-demand self-service. A consumer can unilaterally provision computing capabilities, such as server time and network storage, as needed automatically without requiring human interaction with each service’s provider.
  • Broad network access. Capabilities are available over the network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).
  • Resource pooling. The provider’s computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to consumer demand. There is a sense of location independence in that the customer generally has no control or knowledge over the exact location of the provided resources but may be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter). Examples of resources include storage, processing, memory, network bandwidth, and virtual machines.
  • Rapid elasticity. Capabilities can be rapidly and elastically provisioned, in some cases automatically, to quickly scale out, and rapidly released to quickly scale in. To the consumer, the capabilities available for provisioning often appear to be unlimited and can be purchased in any quantity at any time.
  • Measured Service. Cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency for both the provider and consumer of the utilized service.

If you’ll read through those points a couple of times and give it a moment’s thought, a couple of things should become obvious.

First, most of the chunks of infrastructure that are being called “private clouds” aren’t – at least by the definition above. Standing up a XenApp or XenDesktop infrastructure, or even a mixed environment of both, does not mean that you have a private cloud, even if you access it from the Internet. Virtualizing a majority, or even all, of your servers doesn’t mean you have a private cloud.

Second, very few Small & Medium Enterprises can actually justify the investment required to build a true private cloud as defined above, although some of the technologies that are used to build public and private clouds (such as virtualization, support for broad network access, and some level of user self-service provisioning) will certainly trickle down into SME data centers. Instead, some will find that it makes sense to move some services into public clouds, or to leverage public clouds to scale out or scale in to address their elasticity needs. And some will decide that they simply don’t want to be in the IT infrastructure business anymore, and move all of their computing into a public cloud. And that’s not a bad thing, as long as they pay attention to my point #2 above. If that’s the way you feel, we want to help you do it safely, and in a way that meets your business needs. That’s one reason why I’ve been here all week.

So stay tuned, because we’ll definitely be writing more about the things we’ve learned here, and how you can apply them to make your business better.

If you’ve been following this blog for any length of time, you know that we’ve written extensively about XenDesktop, and spent a lot of time on best practices and problems to avoid. And one of the biggest problems to avoid is poor storage design resulting in poor VDI performance.

In a nutshell, the problem is that a Windows desktop OS uses disk far differently than a Windows server OS. Thanks to the way Windows uses the swap file, disk writes outnumber disk reads by about 2 to 1. You can build your virtual desktop infrastructure on the latest and greatest server hardware, with tons of processing power and insanely huge amounts of RAM, but if all of the disk I/O for all of those virtual desktops is hitting your SAN, you’ve got a scalability problem on your hands.

Provisioning Services (“PVS”) can help to mitigate this in two ways (assuming for sake of argument that you’re provisioning multiple virtual systems from a common, read-only image): First, if you build your Provisioning Servers correctly, you should be able to serve up most of the OS read operations from the Provisioning Server’s own cache memory. Second, you can use the virtualization host’s local disk storage as the required “write cache” – because all of those write operations have to go somewhere while the virtual system is running.

But XenDesktop 5 introduced a new way to provision desktops called “Machine Creation Services” (“MCS”). We wrote about this in the April edition of our Moose Views newsletter, so if you’re not familiar with all the pros and cons of MCS vs. PVS, I’d encourage you to take a brief time out and read that article. Suffice it to say that, despite all the advantages of MCS, the biggest downside of using MCS to provision pooled desktops was that all of the IOPS hit your SAN storage, which limited the scalability of an MCS-provisioned VDI deployment.

But all of that just changed, with the release of XenDesktop 5 Service Pack 1, which was made available for download a week ago (May 13). With SP1, XenDesktop 5 is now able to take advantage of the “IntelliCache” feature that was introduced as part of XenServer v5.6 Service Pack 2. Using MCS with the combination of XenDesktop 5 SP1 and XenServer SP2…

  • The first time a virtual desktop is booted on a given XenServer, the boot image is cached on that XenServer’s local storage.
  • Subsequent virtual desktops booted on that same XenServer will boot and run from that locally cached image.
  • You can use the XenServer’s local storage for the write cache as well.

The bottom line is that you can move as much as 90% of the IOPS off of the SAN and onto local XenServer storage, removing nearly all of the scalability limitations from an MCS-provisioned environment.

With most of the IOPS for running VMs taking place on local storage, it’s pretty straightforward to figure out how many VMs you can expect to support on a given virtualization host. Dan Feller’s blog post does a great job of walking through the process of calculating the functional IOPS that your local XenServer storage repository should be able to support, and inferring from that number how many light, normal, or power users you should be able to support as a result.

This also means that using XenServer as the hypervisor for your XenDesktop 5 deployment is going to yield a significant performance advantage over any other hypervisor, unless or until the other guys come out with similar local caching features. So, if you’re a VMware shop, my advice is this: Go ahead and virtualize all of the supporting XenDesktop server components on your VSphere infrastructure. Run your XenDesktop 5 VMs on XenServer hosts, and just don’t tell anyone! If you’re asked, just say, “Oh, yeah, these are my XenDesktop host systems – they’re completely separate from our VSphere infrastructure, because we don’t need the (insert favorite VSphere feature) function for these systems.” Your infrastructure will run better, and no one will know but you…

We’ve written extensively here about the challenges of using Citrix Provisioning Services to provision VMs that require key activation (i.e., Vista, Win7, and Server 2008/2008R2). We publicly rejoiced when the news broke that PVS v5.6, SP1, supported both KMS and MAK activation.

But now, with the advent of XenDesktop 5, there is a new way to provision desktops: Machine Creation Services (“MCS”). As a public service to those who follow this blog, I thought I’d share Citrix’s official statement regarding MCS and KMS activation:

MCS does not support or work with KMS based Microsoft Windows 7 activation by default, however the following workaround has been provided and will be supported by Citrix Support should an issue arise.

For details on the workaround, click through the link above to the KB article.

It does not appear that there is a workaround that will allow MCS to be used with MAK activation, and I saw a comment by a Citrix employee on a forum post that indicated that there were “no plans to support it in the near future.” So…MCS with KMS, yes; MCS with MAK, no.

Not having MAK support probably isn’t a big deal, since the main reason why you would go with MAK activation rather than KMS activation would be if you had fewer than 25 desktops to activate, and if you have fewer than 25 virtual desktops, you may as well just stick with 1-to-1 images instead of messing around with provisioning anyway. But we thought you should know.

You’re welcome.

I recently discovered a video on “Citrix TV” that does as good a job as I’ve ever seen in presenting the big picture of desktop and application virtualization using XenApp and XenDesktop (which, as we’ve said before, includes XenApp now). The entire video is just over 17 minutes long, which is longer than most videos we’ve posted here (I prefer to keep them under 5 minutes or so), but in that 17 minutes, you’re going to see:

  • How easy it is for a user to install the Citrix Receiver
  • Self-service application delivery
  • Smooth roaming (from a PC to a MacBook)
  • Application streaming for off-line use
  • A XenDesktop virtual desktop following the user from an HP Thin Client…
    • …to an iPad…
    • …as the iPad switches to 3G operation aboard a commuter train…
    • …to a Mac in the home office…
    • …to a Windows multi-touch PC in the kitchen…
    • …to an iPhone on the golf course.
  • And a demo of XenClient to wrap things up.

I remember, a few years ago, sitting through the keynote address at a Citrix conference and watching a similar video on where the technology was headed. But this isn’t smoke and mirrors, and it isn’t a presentation of some future, yet-to-be-released technology. All of this functionality is available now, and it’s all included in a single license model. The future is here. Now.

I think you’ll find that it’s 17 minutes that are well-spent:

We’ve been working with Citrix products pretty much as long as there have been Citrix products, and one of the toughest questions to answer over the years has been, “Will my application run in a Citrix environment?” Often, the answer was, “Ummm…..maybe, but we need to test it.”

Back in the bad old days of DOS and the first few revs of Windows, programmers could get away with taking shortcuts like talking directly to hardware peripherals without using the proper APIs – in fact they could make things run faster on the limited hardware of the day by doing so. But as we moved forward into NT-based execution platforms and multi-user server operating systems, those programming shortcuts played holy you-know-what with application compatibility.

As time went on, more and more of those applications either died off or got re-written to comply with the proper programming conventions. But for a long time you would still find applications that were mostly well-written…but they had shortcomings like hard-coded UNC paths. They might, for example, create some kind of temporary “scratch” file in C:\TEMP, which may be just fine on a single-user PC, but is not fine at all on a Terminal Server that’s supporting 40 or 50 concurrent users, all of whom are trying to write to that file in the C:\TEMP directory and overwriting (or corrupting) one another’s data.

Sometimes a good “Citrix mechanic” could figure out what was going wrong, and manually tweak something (often in the Windows registry, which is not for the faint of heart) that would allow the application to play nicely in a multi-user environment. Over the years, our own engineers were able to make some applications work when their own manufacturers said it couldn’t be done. More recently, application virtualization tools such as Microsoft’s App-V, or the packaging and streaming tool included with XenApp, have made it easier to do things like redirect hard-coded paths to user-specific paths.

We finally reached the point where most 32-bit Windows applications would run just fine in a Terminal Services/XenApp environment, although some manufacturers still won’t support running their applications this way, probably because they don’t want to go to the extra effort of testing and certification. (You know who you are.)

But now we have a whole new level of potential incompatibility: 64-bit execution. Windows Server 2008 R2 is 64-bit only. The latest version of XenApp, v6.0, is designed specifically for 2008 R2. It’s a safe bet that there will never be another 32-bit version of Windows Server, so this is our new reality. And we’re finding that some apps that ran fine under Windows 2003 Terminal Services, and even on 32-bit Windows 2008 platforms, won’t run on 2008 R2. (And don’t even get me started about printing – that’s a whole discussion of its own!)

The good news is that there are a couple of Web resources out there that are devoted to answering the question, “Will my application run?” The first is the Microsoft Remote Desktop Services Community Verified Compatibility Center. You’ll find separate sections there for Server 2003, 2008, and 2008 R2. The other site is the Citrix Ready Community Verified site. There you will find information on over 4,000 third-party products including both hardware and software.

Of course, I can’t guarantee that you’re going to find your app listed on either site. But the odds are a heck of a lot higher than they were a few years ago, and that’s a very good thing.

Latest Blog Feeds
Testimonials
“Our business is all about process and margins; we rely on Moose Logic to install and manage network solutions that enable us to control both. Moose Logic created solutions that transformed our business relationships and processes.”
Ron Horowitz
Birchwood Park Homes
Read our Newsletter
Copyright © 2010 All rights reserved.
Wordpress Delicate template designed by NattyWP