Your are here: Home > Blog

Brian Madden had a great post today over on techtarget.com. In it, he outlined eight challenges that he contends that Microsoft will have to deal with in the realm of desktop virtualization. You might want to bounce over there and read his post before you continue. Go ahead, I’ll wait. (Note, however, that you might have to register with techtarget.com and give up your email address to read the content. Do it. In my opinion, the content is worth it.)

While I agree that all eight of the challenges he identifies are indeed issues that have to be dealt with, there is something that he failed to point out (perhaps he thought it was already clear): these issues exist regardless of whose VDI solution you choose. Whether you’re a fan of Citrix XenDesktop, VMware View, Microsoft’s own VDI solution, or someone else’s, if you’re going to be virtualizing Windows desktops you’re going to have to deal with these issues. And people are going to be virtualizing Windows desktops. And a lot of those desktops will be Windows 7 desktops.

What Microsoft really needs to decide is whether they want to proactively smooth the way for people by making it as easy as possible to virtualize Windows, or whether the projects will be done by people who are muttering and swearing under their breath about what a pain in the you-know-what it is to navigate the labyrinthine licensing requirements, deal with KMS license activation, etc.

There are a lot of really smart people at Microsoft. I know some of them – after all, here on the East Side of Lake Washington, you can hardly throw a rock without hitting a Microsoft facility. And I’m sure that many of them are smart enough to know that it’s in Microsoft’s long-term best interests to make desktop virtualization as easy and painless as possible, since people are going to do it anyway. The easier it is, the faster it will be adopted, and that adoption will boost Windows 7 adoption in the process.

But Microsoft also has a great deal of institutional inertia. I liken it to a fully-loaded oil tanker that takes five miles to start turning after you put the helm over. So it will be really interesting to see whether the really smart people will be able to overcome the institutional inertia. The fun will begin tomorrow, when we see what Microsoft has to say in their “Desktop Virtualization Hour” Webcast.

You may want to mark your calendar – one week from today, Microsoft is holding a “Desktop Virtualization Hour” Webcast, beginning at 9:00 am Pacific time.

Why should you care about this? Well, techtarget.com and others are reporting that there are some licensing changes coming that will make it easier – and hopefully less expensive – to license desktop virtualization technologies.

I really hope they’re right, because the current license model is complex, expensive, and, in my experience, not very well understood by the user community. The vendors of VDI technologies are often not very helpful in this regard, because their focus is to sell you on why their VDI approach is the best, not to needlessly (in their view) complicate the sale by saying, “By the way, here are all the hoops you have to jump through to legally license this deployment from the Microsoft perspective.” Not to mention the fact that their salespeople may not understand the Microsoft licensing side very well anyway.

Today, there is one and only one way to legally license access to virtual Microsoft desktop operating systems, and that’s with the VECD license. (When it was first introduced, VECD stood for “Vista Enterprise Centralized Desktop” – today it stands for “Virtual Enterprise Centralized Desktop.”) The VECD license is only available as an annual subscription license…and the annual cost varies, depending on what the client device is that’s being used to access the virtual desktop OS. If the client device is a Windows Desktop that’s covered by Software Assurance, then adding a VECD license for that client is only $23/year. If it’s anything else – a Windows desktop that’s not covered by Software Assurance, a thin-client terminal, a Linux desktop, a Mac, etc. – the cost jumps to around $120/year. That adds up pretty quickly, and it goes on forever. That’s a tough license model to adjust to if you’re a Small- or Medium-sized business that’s used to just buying new PCs that come with OEM copies of Windows.

These days, you can buy a pretty darned good desktop PC with a professional version of the Windows OS, and probably an OEM copy of the Office Suite, for $700 – $900. If you amortize that over three years, well, you can do the math. Throwing another $120/year on top of that for the VECD license is not insignificant…and we haven’t started talking about the cost of the rest of the VDI infrastructure.

Don’t get me wrong – I’m a fan of VDI in general, and Citrix XenDesktop in particular, which you already know if you’ve followed this blog for any length of time. I truly believe that there are overall cost savings to be had. But most of the savings are in soft costs: reduced effort to manage the desktop image; easier to upgrade and patch; harder for users to break things; easier to insure that critical data is being stored in the data center and backed up; flexible application deployment options; consistent access to the same desktop from just about anywhere; extended life for the client device; faster rollout of Windows 7; etc. Those cost savings are real. Unfortunately, they are also, by definition, hard to quantify, despite the best efforts of the Gartners of the world. And a lot of businesses are still in an operating mode where reducing hard costs today is more important than reducing soft costs in the future.

Reportedly, one of the changes Microsoft is announcing will be a move from per-device licensing to per-user licensing. Depending on what the numbers look like, that could be a step in the right direction.

The other change I’d like to see – and this applied to Windows Server licenses as well as to desktop OS licenses – is to have the OS license associated with a workload, not with a physical device. If a Windows Server license was associated with a workload, e.g., my Exchange Server, instead of me having to “assign” it to a piece of hardware, then I could use live motion to move it from one virtual host to another, or use HA functionality to restart it on another virtual host in the event of a host failure, without having to worrying about whether I’m violating my Microsoft license agreement.

On the desktop OS side, I tend to agree with Tony Wilburn of Betis Group, Inc., who is quoted in the techtarget.com article as saying, “If I buy a Windows 7 license…let me use that instance of Windows 7 whether I have it installed locally, attach to it remotely with a PC or thin client running Windows or Linux, [or] have it running on vSphere, XenServer, or Hyper-V.”

Microsoft’s answer to the Server OS issue is: buy Windows Datacenter Edition licenses for your virtual hosts. And that does indeed solve the license compliance issue. It can also nearly double the cost of licensing for a smaller business that is looking at server virtualization for the first time.

So far, Microsoft’s answer to the desktop OS issue is: buy the VECD license.

But Microsoft is not totally insensitive to customer pushback. Some of us remember when NT 4 Terminal Server Edition was first introduced. Microsoft’s initial licensing stance was to say, in effect, “Terminal Services provides another way of accessing an NT 4 desktop. Therefore, if the client device you’re using is not an NT 4 Workstation, you must buy an NT 4 Workstation license for it, no matter what it is.” Customers who were running Windows 9x, or thin-client devices, or Macs, were not happy about being told that they had to buy a bunch of NT 4 Workstation licenses that would simply sit on a shelf or in a file cabinet and never be installed. The customer outcry was so loud that, less than a year later, Microsoft converted to the Terminal Services CAL license model – which at least had the virtue of being consistent with the way they licensed other server products.

Windows 7 adoption is important to Microsoft. And Windows 7 adoption is driving a lot of the current interest in VDI. Therefore, it is in Microsoft’s best interests to make it as easy as possible for customers to deploy VDI as a means of enabling and accelerating Windows 7 adoption. The signs are hopeful, we’ll just have to wait and see what comes out of next week’s Webcast.

If you’re looking at buying more SQL Server licenses, this may be a good time to do it. Microsoft recently announced that there will be several changes, including price increases, when SQL Server 2008 R2 is released – which is still supposed to happen in the first half of this year.

The price increases affect only the per-processor licensing model – at present, the Server/CAL licensing model remains unchanged. The processor pricing for SQL Server Standard edition is going up by 25%, and the processor pricing for Enterprise Edition is going up by 15%. Bear in mind that this is per processor socket, regardless of the number of cores – and Microsoft is the only major database vendor whose pricing does not depend on the number of processor cores.

In addition, there will be some limits placed on the capabilities of the Enterprise Edition, and two new premium editions will be released. In R2, Enterprise Edition will support no more than 2 Tb of RAM, and no more than 8 processors. Virtualization rights will be limited as well.

The new Datacenter Edition will support unlimited memory (up to whatever the underlying OS can support), and up to 256 logical processors. If that still isn’t enough horsepower, you can check out the new “Parallel Data Warehouse” edition with its support for “massively parallel processing” (MPP).

You can find more information on SQL Server 2008 R2 at http://www.microsoft.com/sqlserver/2008/en/us/R2.aspx.

So, grasshopper, you have decided to take the plunge and virtualize your server infrastructure. Someone (perhaps us) explained the business benefits of virtualization, you decided that it made sense, and that it’s time to make the move. But do you know how virtualization will affect your Windows Server licensing model?

The first thing you need to know is that Windows Server licenses are assigned to physical hardware, not to server workloads. When you purchase a license, you must “assign” that license to a physical server. How do you do that? Well, in today’s world, there is no formal process for doing that, although if it makes you feel better, you can write it down somewhere.

You may assign more than one license to a physical server, but you may not assign the same license to more than one physical server. You may reassign a license from one physical server to another, but not more frequently than every 90 days, unless the server it was assigned to is being retired due to “permanent hardware failure.”

Sound reasonable so far? Of course it does. Right up until the license model runs head-on into one of the coolest features of virtualization: live motion. Most virtualization platforms, including Microsoft’s Hyper-V R2, allow you to easily move a virtual server from one physical host to another. Great feature, right? But if you do it, you may have just violated your Windows license agreement.

I say “may” because different versions of Windows Server come with different virtualization rights. For example, a Windows Server Standard license can be used to run one physical instance of Windows (and by “physical instance,” I mean Windows is installed directly on the hardware) or one virtual instance of Windows, but not both – unless the physical instance is being used solely to manage the virtual environment.

Let me say that another way: If you buy a single license for Windows Server Standard Edition with Hyper-V, you can install it directly on the hardware without bothering with the Hyper-V role. Or you can install the Hyper-V role, have one virtual Windows Server running on top of Hyper-V, and use the physical instance exclusively to manage the virtual instance. Of course, you haven’t really gained anything by doing that…but you can purchase additional copies of Windows Server Standard, assign them to the same physical host, and run more virtual servers on Hyper-V.

Thinking this scenario through, then, if you currently have a bunch of physical Windows Servers – each licensed with Windows Standard Edition – and you want to virtualize them all, that’s no problem. You can reassign your server licenses to your virtual hosts and be perfectly legal. As long as you don’t move a server from one host to another. But if all you own are Standard Edition licenses, and you move a server from one host to another, you’ve just violated the license agreement – unless you own a “spare” server license that you have “assigned” to the target server (the host you’re moving it to) but that is not being used.

Now, in the scenario I just described, it’s possible that the most cost-effective thing you could do is to just buy a few additional licenses as “spares” rather than re-licensing your entire environment. But let’s move ahead – once we’ve covered the other Windows editions that are available to you, you’ll be better able to decide what makes financial sense for your project.

Windows Server Enterprise Edition comes with expanded virtualization rights. Each Enterprise Edition license gives you the rights to run one physical instance and up to four virtual instances on the physical host to which it is assigned. Once again, if you want to run all four virtual instances, then the physical instance may only be used to manage the virtual environment. If you want to run other services on the physical instance – and that’s actually fairly common in a Hyper-V deployment – then you only get to run three virtual instances. And you may not split the license across multiple physical hosts.

The “estimated retail price” (just the license, no Software Assurance, assuming Open Business pricing) for Windows Enterprise is $2,358, vs. $726 for Windows Standard. So Enterprise is less expensive than four copies of Standard. Therefore, if you need to buy new licenses (perhaps you’re upgrading from Server 2003 to Server 2008 as part of your virtualization project), it may make sense in a small environment to buy a copy of Enterprise Edition for each virtual host, and perhaps supplement it with a few spare copies of Standard Edition. Here’s an example:

Let’s say you have a total of nine physical servers today, and you want to virtualize them on three dual-processor virtualization hosts. (You could probably run them on two hosts, but if one failed, it might be a stretch to run all nine on one host. If you start with three hosts, and one fails, you still have two to carry the load.) You could buy nine new copies of Windows Standard Edition for $6,534, but you’d have no flexibility to use live motion to move things around. On the other hand, you could buy three copies of Enterprise Edition for your three hosts for $7,074, and effectively have one “spare” instance on each host that’s available for moving a virtual machine from one host to another.

Of course, that may not be quite enough if you want to completely unload one of your servers (perhaps to take it off-line for maintenance), because unless you’re prepared to shut down one VM completely, you’re going to need to run five VMs on one of your remaining servers. Since you may not know in advance which server needs to assume the extra VM workload, you could just buy three additional copies of Standard Edition, and assign one to each host. That would push your total license acquisition cost to $9,252, but you would then be licensed for five VMs on each of your hosts.

The ultimate in flexibility is Windows Server Datacenter Edition. Datacenter Edition is licensed per processor socket rather than per physical host, but includes unlimited virtualization rights. You can run as many VMs on your hosts as they’re capable of running, and move them around to your heart’s content. If you just don’t want to worry about what’s running where or whether or not it’s technically legal to move a given VM around, this is the license model to use.

Of course, this is also the most expensive edition of Windows. The estimated retail price for Datacenter Edition is $2,405 per processor socket (regardless of the number of cores per processor). So it would cost $14,430 to license three dual-processor servers with Datacenter Edition. This probably isn’t cost effective if you’re only virtualizing nine servers. However, if you have lots of servers, and many of them are fairly lightly loaded (in terms of processor utilization), the picture could change. If your average consolidation ratio is greater than or equal to four servers per physical processor then Datacenter Edition becomes the most cost-effective license.

In fact, if you’re even close to that 4:1 ratio, you should strongly consider Datacenter Edition, for two reasons:

  1. Windows environments inevitably grow. However many servers you have today, you’re probably going to have more of them a year from now. With Datacenter Edition, you can continue to fire up new servers to the limits of your hardware without having to buy more server licenses.
  2. AMD already has six-core processors. You know the “arms race” between Intel and AMD will continue. So the number of servers per processor that you can reasonably expect to support will continue to increase as the processors themselves become more powerful and contain more cores, and as this happens, Datacenter Edition will look better and better.

Note that everything we’ve discussed holds true if you’re virtualizing on XenServer or VMware rather than on Hyper-V. The only difference is that you won’t be using any of the allowed physical instances of Windows.

If you want to delve deeper into this issue, you can download a copy of the Microsoft Product Use Rights document from their Web site. Happy virtualizing!

VSS and Snapshots

February 3rd, 2010 | Posted by Sid Herron in Computer Basics | General - (0 Comments)

“VSS,” or Microsoft’s “Volume Shadow Copy Service,” provides a means of requesting a “snapshot” of a data volume. In very basic terms, a snapshot captures an image of the data volume at a particular point in time. This can be useful, for example, in allowing backup software to back up a volume even though it is still in use and data may be changing while the backup operation is under way. It can also be used to facilitate a roll-back of the data volume to the point in time when the snapshot was taken.

You typically don’t want your snapshot to consist of a complete copy of your data volume, though. That would be a waste of disk space, and could take a long time to complete – and I/O operations on the data volume have to be suspended for the length of time required to take the snapshot, so we want that time to be as short as possible. Therefore, most products that use snapshots, including VSS, use a “copy on write” approach. Here’s how it works:

First, a table is created that initially contains nothing but pointers back to the physical data blocks in the original volume. This can be done very quickly, will take up very little space, and can immediately be used as though it was a complete copy of the data volume. As long as nothing has actually changed in the original volume, any read request that’s made to the snapshot for a specific block of data will simply be redirected back to the original volume.

When a write operation takes place on a block of data in the original volume, the existing data is first copied to a “recovery area,” and the pointer for that block in our snapshot table is changed so it points to the recovery area instead of to the original volume. The snapshot can continue to be accessed as though it was a complete copy of the original volume, because the point in time at which the snapshot was taken can be reconstructed by merging the unchanged blocks of data in the original volume with the blocks that were copied to the recovery area before changes were made.

As time goes by, and more and more changes are made to the original volume, the storage space consumed by the snapshot will continue to grow as more and more data is copied to the recovery area. Eventually, it will approach the size of the original volume. For this reason, snapshots are generally not retained forever – they’re kept until the purpose for which they were created has been fulfilled, e.g., until the backup operation has been completed, and then purged to release storage space.

That, in a nutshell, is what a “snapshot” is all about. For more information, check out the “Volume Shadow Copy Service Technical Reference” on Microsoft Technet.

Judging from the questions we continue to be asked, lots of people are confused about how to license the Microsoft Office Suite if you are accessing it via Microsoft’s Remote Desktop Services (a.k.a. Terminal Services) and/or Citrix XenApp. Hopefully, this will clear up the confusion.

First of all, it is important to keep in mind that desktop applications such as the Office Suite are licensed per device, not per user. The following comes directly from the Microsoft “Product Use Rights” document dated January, 2010: “You must acquire a license for each device on or from which you access or use the software (locally or remotely over a network)…You may access copies of the software installed on a network device only from a device that has a license for the software.”

In other words, if you can walk up to a device and use it to interact with an Office application, you must have an Office license for that device. It doesn’t matter whether that device is a PC or laptop that has the Office bits installed on its local hard drive, or whether it is a thin client device that allows you to connect to a XenApp server, you need to have “assigned” a license to that device.

That begs the question of what “assigned” means, and the answer – particularly for devices like thin clients, where you couldn’t install the application locally if you wanted to – is that you are on the honor system. You decide, in the privacy of your own conscience, which licenses you are assigning to which devices – with the caveat that, if you’re ever audited, you’d better be able to produce a license for every device people are using to run Office apps. You can reassign a license from one device to another, but not more often than every 90 days.

But that’s not all. Quoting again from the Product Use Rights document: “The device you use to remotely access software must be licensed for the same or higher edition, but not a lesser edition.” That means that if you have Office Professional Plus installed on your XenApp server, you are not entitled to access it from a device that only has an Office Standard license assigned to it (because it’s a “lesser” edition); but you are entitled to access it from a device that has an Office Enterprise license assigned to it (because it’s a “higher” edition). Likewise, if you have Office 2007 installed on your XenApp server, you are not entitled to access it from a device that is only licensed for Office 2003 (or any other earlier edition).

You do not, never have had, and probably never will have the right to access Office on a XenApp server from a device that has an OEM Office license installed on it. If your PC or laptop came from the manufacturer with Office pre-installed on it, then you have an OEM license, and you do not have “network storage and use” rights. There is an excellent blog post over on the Microsoft SMB Community Blog that explains this in detail. Yes, it’s an old post (from July, 2005). No, the policy hasn’t changed.

Basically, it comes down to this: Why do people tend to purchase Office bundled with their new PC? Because it’s less expensive. Why is it less expensive? Because the license you’re buying contains fewer usage rights than more expensive licenses. You do not have the right to transfer that license to a different PC – it dies when the PC you bought it with dies. You typically do not have the right to downgrade it to an earlier version. And you don’t have the right to access the application over a network.

However, there is a way for you to obtain those rights if you buy an OEM license. Microsoft allows you to purchase Software Assurance for your OEM license within a 90-day window of acquiring the license. (It’s one of only two cases where you can purchase Software Assurance as a stand-alone purchase – the other case is when you’re renewing it.) Software Assurance will do a number of things for you:

  • It removes pretty much all of the OEM license limitations, e.g., you now have the right to transfer the license to a different PC, the license will survive the demise of the hardware, and you gain network use rights.
  • You get upgrade protection for the term of the Software Assurance coverage (two years if purchased on an Open Business agreement, three years if purchased on an Open Value agreement).
  • You gain “Home Use Rights.” For each Office license covered by Software Assurance, you have the right to designate one employee who can install Office on his/her home PC. (Which, by the way, would then give them the right to access Office on your XenApp server when they’re working from home.) These Home Use Rights evaporate if you allow your Software Assurance coverage to lapse. Also, the employee loses his/her right to run the software if they leave your employ.
  • You probably qualify for some e-learning benefits as well.

Bottom line: Volume Licensing is your friend. If you’re planning to deploy Office via Remote Desktop Services (with or without XenApp), the right thing to do is buy your Office licenses through a Microsoft Volume License agreement. In fact, last time I checked, you couldn’t even install Office on a Remote Desktop Server unless you were installing from Volume License media. If, for convenience, you want to buy OEM licenses with your new hardware, you should also budget for adding Software Assurance to those licenses, or you’re probably not going to be happy with the limited license rights.

One final item: The license terms for Volume License editions of Office include something called “Portable Use” rights. Quoting again from Microsoft: “You may install a copy on a portable device for use by the single primary user of the licensed device.” In other words, if you have purchased an Office license for Joe’s or Mary’s desktop PC, and Joe (or Mary) also has a laptop, you are entitled to install Office on that laptop (the “portable device”) without having to purchase an additional license. By extension, since that laptop is now legally licensed, it could then be used to remotely access the Office apps via XenApp from wherever Joe or Mary may happen to be.

Disclaimer: I do not work for Microsoft, nor do I define their license terms, which are subject to change, particularly when new product versions are released. I have, however, worked with them for a very long time, and had lots of discussions about what is, or is not, legal under the terms of various license models. The foregoing is my own interpretation of information that is publicly available on the Microsoft Web site – and I have helpfully provided you with links to that information. I highly recommend that, if you have any questions, you download the Product Use Rights document and read it for yourself.

To continue the discussion of “What is Virtualization?” that I started back on December 4, I bring you the next installment – Application Virtualization.

Application Virtualization is the isolation and separation of an application from its underlying Operating System (OS) as well as from other applications. The application is fooled into believing that it is working as normal, interacting with the OS and using those resources as if the application had been installed directly on the OS as normal.

Additionally, the application can be installed once within the datacenter and preserved as a “golden image” to be delivered out to the end users. This gives you one instance to manage, one instance to patch, one instance to maintain – all housed in one location. This will help cut IT application maintenance costs as well as help control licensing costs as it will be easier to track application utilization.

Since each virtualized application is isolated from other applications it becomes possible to deploy, on the same piece of hardware, applications that typically didn’t play nicely together in the past. This cuts down on the time needed to test application compatibility since each application resides inside its own “bubble” (much like teenagers).application silos

Traditionally, both desktop admins and admins who were in charge of Terminal Servers (and XenApp servers) spent hours and hours on application compatibility testing. When a new application was added to the official desktop or server image, or an existing application was upgraded, regression testing was necessary to insure that the new or upgraded application didn’t break some other application by, for example, overwriting a shared DLL file. By providing a method for virtualizing Registry entries and calls to particular folder locations, application isolation overcomes most of these headaches.

The real trick with application virtualization is the delivery method, since the delivery methods of these virtual applications is what separates the different vendor solutions in this field. The big three application virtualization solutions are Citrix XenApp, VMware ThinApp, and Microsoft Application Virtualization (a.k.a. “App-V”). These three vendors use either one method or a combination of delivery methods to get the applications to the end users.

Application Streaming: This refers to streaming the application over the network to the client PC on demand. The “secret sauce” here is in figuring out how to stream down just enough of the code to launch the application and allow the user to begin interacting with it. The rest of the code can be streamed down when the user attempts to use a feature that requires it, or it can be simply streamed down in the background until all of the application code is cached locally. An added benefit of streaming all of the code down is that it allows the application to continue to be used when the PC is not connected to the network. (E.g., you can unplug your laptop and take it on the road.)

The application streaming technology you use will determine the control and security of the application once it has been streamed to the end user device. For example, Citrix allows you to administratively set a “time to live” limit on how long apps will run in a disconnected state. If the PC isn’t reconnected to the network within that time limit, the app simply stops working – giving you some level of protection if a PC is lost or stolen. For another example, ThinApp allows you to make an application completely portable – you could carry the Office Suite with you on a USB stick, plug it into any PC, use it, and leave no trace behind when you unplugged the USB stick. (Note: Doing this with the Office Suite could result in a violation of the Office EULA!)

Another “secret sauce” ingredient is the ability to allow limited communication between applications, even though they’re running in their own isolation environments (the “bubble” referred to earlier). For example, your accounting application may need to call Excel to render the output of a particular report. Early versions of application isolation required these applications to be “packaged” together, i.e., installed into the same isolation environment – otherwise, the accounting app wouldn’t know that Excel was available, and you’d get an application error. The latest implementations allow enough inter-isolation communication to take place to avoid problems like this while still avoiding application compatibility conflicts.

Application Hosting: This method can take a couple of different forms. The first is to virtualize the presentation of a typical Windows application by installing the application on a Terminal Server (in most cases, a Terminal Server with Citrix XenApp installed on it), and connecting to that Terminal Server using some kind of remote communications protocol (e.g., Microsoft’s RDP, Citrix’s ICA, etc.). We’ve been doing this for years, and thousands of customers and millions of users access applications this way every day.

Most readers of this blog are probably familiar with the advantages of this deployment model: centralized deployment and management, tighter security, granular control over what can be saved and/or printed at the client location, etc.

Application Streaming can work with this kind of Application Hosting by allowing you to stream applications to your Terminal Servers rather than having to explicitly install them or build them into your official server image. Citrix XenApp customers have the rights to use the Citrix streaming technology to do this, and Microsoft recently announced that the new Server 2008 R2 Remote Desktop Services CAL (formerly called a Terminal Services CAL) will include the rights to use App-V to stream applications to Terminal Servers.

Web-based applications can also be legitimately called “hosted applications” – whether they’re hosted in your own corporate data center, or by some kind of application service provider (e.g., Salesforce.com). In this scenario, all that’s required on the client PC is a browser – at least in theory.

In fact, the browser then becomes an application that must be managed! For example, you may find that you require a specific version of Java to access a particular hosted Web application – and if the user has local admin rights to the PC, the possibility exists that s/he will inadvertently install something that breaks its compatibility with your critical Web application. Some Microsoft applications require the use of Internet Explorer (e.g., Microsoft CRM is not compatible with Firefox). Some applications may even require a specific browser version. (When IE7 was first released, it caused compatibility issues for users of Microsoft CRM v3.0.)

Also, as a general rule, a Web application will require a more powerful client PC as well as more bandwidth between the client and the Web server to yield a good user experience, compared to an RDP or ICA client device connecting to a Terminal Server.

There is, of course, the option of installing an application directly on a device either by physically visiting the machine with installation media in hand or by using some kind of central management system to push the bits onto the client’s hard drive. These options, however, do not fall under the definition of application virtualization that we’re using here.

The important thing to take away from application virtualization is that no matter how you approach it, it will save you money:

  • Hardware – being able to host multiple applications on a single piece of hardware without worrying about application incompatibility. This can virtually eliminate the “silos” of servers with different configurations in large XenApp environments that used to be necessary to isolate those problem apps that wouldn’t play nicely with any others.
  • Licensing costs – with all your applications being housed in the data center you will have a better understanding of how many instances of each application you are using and will be able to better track your licensing needs
  • Maintenance – being able to update or patch a single instance of the application rather than needing to physically update and patch each machine.
  • Management – less hardware to look after, less time spent with helping end users with application issues, less time spent in application regression testing

Hope this clears up that “what is application virtualization” question. However if you have more questions feel free to use the comments or contact me directly.

Recently I had my first opportunity to create a Windows 2008 R2 virtual machine on Citrix XenServer 5.0. When I attempted to install the operating system I ran into an interesting issue where the installation would hang right at the initial Windows install screen and the CPU usage pegged at 100%. Once that happened no matter how long I waited the installation never progressed beyond that point.

Of course what did I do? I turned to Google and quickly found the following article which provided a workaround for the issue I was having.

I followed the advice in the article and after running the “xe vm-param-set uuid= platform:viridian=false” command as outlined in the article was able to install Windows Server 2008 R2.

Two more things are worth mentioning here, which are not specifically addressed in the previously referenced article:

  1. With Windows 2008 R2 I was able to install the XenServer 5.0 tools with none of the problems others people are having with Windows 7 installations.
  2. This issue has been resolved in XenServer v5.5!

This post was inspired by my quest to install the newest version of Windows Live Messenger on our 32-bit, Windows Server 2008 servers running XenApp 5.0 here at Moose.  We were previously running Live Messenger 8.5 until it started prompting us that an update was available and would not let us use the program until it was updated.  This update is mandated by Microsoft to keep everyone’s messengers up-to-date to protect against security flaws.

According to the Windows Live Essentials System Requirements, you can install it on Server 2008…HA!  Good luck!  Standard attempts to install just don’t work – it goes through the process and at the end of the installation it rolls everything back. (Note: Click on an image to view full-size.)

Live Messenger System Requirements

Live Messenger System Requirements


I tried a couple of different approaches, including copying the bits from C:\program files\Windows Live\Messenger on a Vista SP2 box over to the Citrix XenApp Servers, but that didn’t work either (big surprise).

By default, the package you download from http://download.live.com to install Live Messenger is a small executable that asks you what other programs you want to install.  Once you’ve made your choices, it downloads the actual installation bits from the Internet.  There is a full download that contains all the installers, but you won’t find it on a Microsoft site (at least I couldn’t).  I ultimately found it on this third-party Web site. You can do the installation with either package, but I did it with the full 140 Mb package, so I know it works that way.

I have not found any way to extract the contents of the full package executable into separate .msi files for each product.  You can browse to c:\program files\common files\windows live\.cache\ and search for the particular piece you’re looking for (Messenger.msi in my case), but it is a silent install, and things still didn’t work after trying to install it on Server 2008.

The solution I found was to actually hack the installer to allow it to install on a server OS.

I found an article via a Google search that is actually for installing Windows Live Wave 3 Beta on unsupported x86 and x64 versions of Server 2003 and 2008, and discovered that the method worked perfectly for Live Messenger as well.

To install Live messenger you will need to download:

  1. The full install of Windows Live Essentials;
  2. “Resource Hacker” from the link in the article above. I chose the UK mirror.

Customization and Installation steps:

  1. Extract the ResHack.zip file to your hard drive (anywhere works, I used the Desktop).
  2. Launch ResHack.exe from the extracted files.
  3. Open the Windows Live Installer executable (WLSetup-All.exe or WLSetup-Web.exe).
  4. Open the Windows Live installer file

    Open the Windows Live installer file

  5. Locate CONFIG -> CONFIG0 -> 0.
  6. Using ResHack

    Using ResHack

  7. Select-All and copy the XML code into a text editor such as Notepad (choose Word Wrap from the Format menu in Notepad to make it easier to edit)
  8. Find ‘os productType=”workstation”’  and replace ‘workstation’ with ‘server’
  9. Select Text to Replace

    Select Text to Replace

  10. Copy/paste the XML code back into ResHack, replacing the old code
  11. Click ‘Compile Script’
  12. Compile Script

    Compile Script

  13. Select File -> Save and save the modified executable (Make sure to put .exe on the end of the filename and name it something unique).  It’s 140Mb – be patient as it compiles the executable.
  14. Run the modified executable.

The Windows Live applications should now be installed on Server 2008!

Happy Messaging!

Citrix Provisioning Services, which evolved from their acquisition of the Ardence technology, enables some great concepts:

  • Since the first time a Citrix customer deployed more than one WinFrame server, we’ve struggled with the issue of change control – how do we insure that, over time, all of the servers that are supposed to be identical do, in fact, remain identical? Booting and running them all from a single, read-only image is a great way to do that.
  • It gives you an “undo” option when you upgrade your server image. You can make a copy of your read-only image, set it to read/write, apply your patches, updates, etc., reboot one server from the new image, do your testing, then set the new image to read-only, reboot your servers, and ba-da-boom ba-da-bing (that’s a technical term), in the time it takes them to reboot, they’re all running from the new image. If you then discover that there’s something wrong with the new image, point them back at the old image and reboot them again, and, in the time it takes them to reboot again, you’ve just rolled back to the old image.
  • In a VDI scenario, not only do you enjoy the first two advantages, you also save a ton of expensive SAN storage. If your typical desktop image is, say, 10 Gb, and you want to deploy 100 virtual desktops, with some vendors’ approaches you will consume a full terabyte of expensive SAN storage. By using provisioning services, you consume only the 10 Gb required by the common image.

Unfortunately, when you convert a modern Microsoft OS image to a shared read-only image, it looks like a hardware change to the OS, and breaks the license activation. This is the case with Windows 2008, 2008 R2, Vista, and Windows 7.

Enter the KMS server. KMS stands for “Key Management Service,” and it’s one way to automate the activation of Microsoft volume licenses within an organization. There’s a pretty good video that you can download from Microsoft Technet that walks through the process of configuring a KMS server to automatically activate servers and workstations, but it was made prior to the release of 2008 R2, so it omits a very important point (which we will get to in due time).

The concept is that as an un-activated copy of Server 2008, Vista, or Win7 boots, it queries Active Directory to see if there is a KMS server on the network. If there is, it contacts the KMS server for activation. However, for reasons that are not at all clear to me, the KMS server must be contacted by a minimum number of machines before it will actually activate anything. So, each time a different machine contacts the KMS server for activation, it is assigned a unique ID number, and the KMS server increments its counter by one. When it has been contacted by a total of five different systems, it will begin to activate servers. When it has been contacted by a total of 25 different systems, it will begin to activate workstations.

Before the release of Server 2008 R2, only physical systems would increment the counter – virtual systems would not. (Don’t ask me how the KMS server could tell the difference – that’s one of the ongoing mysteries of KMS.) And that’s the message you’ll hear when you watch the video referenced earlier. However, if KMS is running on a Windows 2008 R2 server, both physical and virtual systems will increment the counter. Note also that what matters is the aggregate number of all systems that have contacted the server for activation, regardless of whether they’re running Server 2008, 2008 R2, Vista, or Win7.

If the threshold has not yet been reached, the system will not be activated, but will still run…within the constraints of the built-in 30-day “grace period” for activation. (Although the nag messages get pretty intrusive in the last three days of the grace period.) This, by the way, is good news if you’re looking at an evaluation or proof of concept that will involve fewer systems than it takes to meet the threshold – you should be OK as long as the evaluation term doesn’t exceed the 30-day grace period. The system will continue to check back in with the KMS server ever two hours to see if the threshold has been met. When it is met, all of the systems that have been waiting will be activated. Once activated, a system will attempt to check back in and renew its activation every 7 days. It must renew its activation within 180 days, or it will revert back to an un-activated state.

The KMS server keeps track of the ID numbers of the systems that have contacted it for activation. If an activated system does not check back in within 30 days, its ID number is removed from the KMS server’s cache, and the counter is decremented. If the count falls back below the threshold, the KMS server will stop activating systems. To help guard against this, the KMS server’s cache size is set to 2x the threshold. In other words, if you’re only activating servers, the cache will contain the IDs of the last 10 servers that have contacted it for activation. If you’re activating workstations, or a combination of workstations and servers, the cache will contain the IDs of the last 50 systems that have contacted it for activation.

The KMS service can be co-hosted with other services in your server infrastructure – you do not have to dedicate a server to this function. In fact, if all you care about are workstations, you can host the KMS service on a Win7 workstation. You’re going to want to have more than one KMS host running, to insure that it doesn’t become a single point of failure in your infrastructure. And remember, unless you’re going to be activating enough physical systems to meet the KMS threshold, you need to be running KMS on Server 2008 R2. That will give you the ability to activate “any Windows operating system that supports Volume Activation,” (which today means the four operating systems we’ve been discussing here), and count both physical and virtual systems toward the required threshold.

So…wrapping back around to the beginning of this discussion, if you want to use Provisioning Services to provision XenApp servers on Server 2008 (and remember, XenApp does not yet work on 2008 R2 as of this writing), you’re going to need a couple of KMS servers. And unless you have five or more physical 2008 servers that it can activate, you’re going to need to have your KMS servers running on R2. And even then, you’re going to need a total of at least five machines to meet the threshold before KMS will activate anything.

Likewise, if you want to use Provisioning Services to provision Win7 desktops – and I’m ignoring Vista here, because, even though I personally liked Vista, I think Win7 is sufficiently superior that it just doesn’t make sense at this point not to go to Win7 – you’re also going to need a couple of KMS servers. And unless you have 25 or more physical systems (in aggregate, counting both servers and workstations), they’re going to need to be running on R2. And in any event, you’re going to need a total of at least 25 systems.

For more information on exactly how KMS works, I strongly recommend the Technet Volume Activation Planning Guide for Windows 7 and Windows Server 2008 R2. Happy provisioning!