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:

This post requires two major disclaimers:

1. I am not an engineer. I am a relatively technical sales & marketing guy. I have my own Small Business Server-based network at home, and I know enough about Microsoft Operating Systems to be able to muddle through most of what gets thrown at me. And, although I’ve done my share of friends-and-family-tech-support, you do not want me working on your critical business systems.
2. I am not, by any stretch of the imagination, a Linux guru. However, I’ve come to appreciate the “LAMP” (Linux/Apache/MySQL/PHP) platform for Web hosting. With apologies to my Microsoft friends, there are some things that are quite easy to do on a LAMP platform that are not easy at all on a Windows Web server. (Just try, for example, to create a file called “.htaccess” on a Windows file system.)

Some months ago, I got my hands on an old Dell PowerEdge SC420. It happened to be a twin of the system I’m running SBS on, but didn’t have quite as much RAM or as much disk space. I decided to install CentOS v5.4 on it, turn it into a LAMP server, and move the four or five Web sites I was running on my Small Business Server over my new LAMP server instead. I even found an open source utility called “ISP Config” that is a reasonable alternative – at least for my limited needs – to the Parallels Plesk control panel that most commercial Web hosts offer.

Things went along swimmingly until last weekend, when I noticed a strange, rhythmic clicking and beeping coming from my Web server. Everything seemed to be working – Web sites were all up – I logged on and didn’t see anything odd in the system log files (aside from the fact that a number of people out there seemed to be trying to use FTP to hack my administrative password). So I decided to restart the system, on the off chance that it would clear whatever error was occurring.

Those of you who are Linux gurus probably just did a double facepalm…because, in retrospect, I should have checked the health of my disk array before shutting down. The server didn’t have a hardware RAID controller, so I had built my system with a software RAID1 array – which several sources suggest is both safer and better performing than the “fake RAID” that’s built into the motherboard. Turns out that the first disk in my array (/dev/sda for those who know the lingo) had died, and for some reason, the system wouldn’t boot from the other drive.

This is the point where I did a double facepalm, and muttered a few choice words under my breath. Not that it was a tragedy – all that server did was host my Web sites, and my Web site data was backed up in a couple of places. So I wouldn’t have lost any data if I had rebuilt the server…just several hours of my life that I didn’t really have to spare. So I did what any of you would have done in my place – I started searching the Web.

The first advice I found suggested that I should completely remove the bad drive from the system, and connect the good drive as drive “0.” Tried it, no change. The next advice I found suggested that I boot my system from the Linux CD or DVD, and try the “Linux rescue” function. That sounded like a good idea, so I tried it – but when the rescue utility examined my disk, it claimed that there were no Linux partitions present, despite evidence to the contrary: I could run fdisk -l and see that there were two Linux partitions on the disk, one of which was marked as a boot partition, but the rescue utility still couldn’t detect them, and the system still wouldn’t boot.

I finally stumbled across a reference to something called “SuperGRUB.” “GRUB,” for those of you who know as much about Linux as I did before this happened to me, is the “GNU GRand Unified Bootloader,” from the GNU Project. It’s apparently the bootloader that CentOS uses, and it was apparently missing from the disk I was trying to boot from. But that’s precisely the problem that SuperGRUB was designed to fix!

And fix it it did! I downloaded the SuperGRUB ISO, burned it to a CD, booted my Linux server from it, navigated through a quite intuitive menu structure, told it what partition I wanted to fix, and PRESTO! My disk was now bootable, and my Web server was back (albeit running on only one disk). But that can be fixed as well. I found a new 80 Gb SATA drive (which was all the space I needed) on eBay for $25, installed it, cruised a couple of Linux forums to learn how to (1) use sfdisk to copy the partition structure of my existing disk to the new disk, and (2) use mdadm to add the new disk to my RAID1 array, and about 15 minutes later, my array was rebuilt and my Web server was healthy again.

There are two takeaways from this story:

First, the Internet is a wonderful thing, with amazing resources that can help even a neophyte like me to find enough information to pull my ample backside out of the fire and get my system running again.

Second, all those folks out there whom we sometimes make fun of and accuse of not having a life are actually producing some amazing stuff. I don’t know the guys behind the SuperGRUB project. They may or may not be stereotypical geeks. I don’t know how many late hours were burned, nor how many Twinkies or Diet Cokes were consumed (if any) in the production of the SuperGRUB utility. I do know that it was magical, and saved me many hours of work, and for that, I am grateful. (I’d even ship them a case of Twinkies if I knew who to send it to.) If you ever find yourself in a similar situation, it may save your, um, bacon as well.

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.

Today, Citrix announced a new, permanent XenDesktop trade-Up program. (Well, mostly permanent – the special offer to users with expired Subscripion Advantage only runs through the end of 2011.) This new offer shouldn’t come as a big surprise, as all indications were that there would be some kind of upgrade path provided after the last trade-up program expired at the end of 2010. What did come as a surprise is the announcement of a concurrent-use (“CCU”) license model for XenDesktop Enterprise and Platinum. The new CCU license is good news for XenDesktop v3 customers, some of whom have not upgraded to XenDektop v4 or v5 because they didn’t want to give up the CCU license model.

The new trade-up program will allow XenApp users to trade up to either the user/device-based license model or the new concurrent use license model. New concurrent use licenses cost roughly 2x the cost of a user/device license. Here are the high points of the new trade-up program:

• As was the case with the earlier trade-up programs, XenApp users can choose a straight one-for-one deal, where they receive one user/device XenDesktop license for each XenApp license, or, if they trade up all of their XenApp licenses, they can choose a two-for-one deal, where they receive two user/device licenses for each XenApp license. It will just cost you a little more than it would have if you had done it before the end of 2010.
• Through the end of 2011, customers with expired Subscription Advantage can trade up their licenses for the same price as customers with current Subscription Advantage – and take advantage of the two-for-one deal. After December 31, 2011, it will cost an additional $50/license if your Subscription Advantage is expired.
• You can now choose to trade up your XenApp licenses one-for-one to XenDesktop concurrent use licenses – although it’s more expensive than trading up to user/device licenses.
• “Trade-up PLUS” – If you trade up all of your XenApp licenses, you can purchase additional XenDesktop licenses (on the same order) for 10% off the suggested retail price. These additional licenses do not have to be the same product version as the version you’re trading up to, i.e., you could trade up to XenDesktop Platinum Edition, and purchase additional XenDesktop Enterprise licenses (although I’m not sure why you’d want to).
• “Trade-up MAX” – If you trade up all of your XenApp licenses, and purchase additional XenDesktop licenses for all of your remaining users (on the same order), the additional licenses would be 35% off the suggested retail price. Again, the additional licenses do not have to be the same version as the trade-up licenses. The order must total a minimum of 2,500 XenDesktop licenses, including both the licenses received via the trade-up offer and the additional licenses. Citrix will accept data from Dun & Bradstreet or Hoovers.com, or the user count from an active Microsoft Enterprise Agreement as evidence of how many users you have.

Here is a summary of the new trade-up suggested retail prices:

Note that if your Subscription Advantage is expired, all of the prices above will go up after December 31, 2011. Note also that if you purchased XenApp Fundamentals bundled with Microsoft Terminal Services CALs, and you want to keep those Terminal Services CALs after the trade-up, you must specify that on your trade-up order. Otherwise, the Terminal services CALs will be rescinded along with the XenApp Fundamentals licenses that you’re trading up.

Citrix has provided a new Trade-Up Calculator that makes it really easy to figure out what your trade-up cost will be. You simply enter your data – how many XenApp licenses you own, how many you’re trading up, what edition your trading up from and to, whether your Subscription Advantage is current, whether you’re trading up all of your licenses, and whether you want to purchase additional licenses along with your trade-up – and the calculator will give you the various options available to you, along with the suggested retail price of each option.

You can also download a Trade-Up Brochure, and a Trade-Up FAQ Document from the Citrix Web site.

Dan Feller is a Lead Architect with the Citrix Consulting group, and has written extensively about XenDesktop. We found his series on the top ten mistakes people make when implementing desktop virtualization to be quite enlightening. In case you missed it, we thought we’d share his “top ten” list here, with links to the individual posts. We would highly recommend that you take the time to read through the series in its entirety:

#10 – Not calculating user bandwidth requirements
Back in the “good old days” of MetaFrame, when we didn’t particularly care about 3D graphics, multimedia content, etc., we could get by with roughly 20 Kbps of network bandwidth per user session. That’s not going to cut it for a virtualized desktop, for a number of reasons that Dan outlines in his blog post. He provides the following estimates for the average bandwidth required both with and without the presence of a pair of Citrix Branch Repeaters (which have some secret sauce that is specifically designed to accelerate Citrix traffic) between the client device and the virtual desktop session:

NOTE: These are estimates – your mileage may vary!

One thing that should come across loud and clear from the table above is what a huge difference the Citrix Branch Repeater can make in your bandwidth utilization. And as we’ve always said: you only buy hardware once – bandwidth costs go on forever!

#9 – Not considering the user profile
It should go without saying that user profiles are important. But if it’s number 9 on the list of things people most often screw up, then apparently it doesn’t. In a nutshell: If you mess up the users’ profiles, the users won’t be happy – logon/logoff performance will suffer, settings (including personalization) will be lost. If the users aren’t happy, they will be extremely vocal about it, and your VDI deployment will fail for lack of user buy-in and support. There are some great tools available for managing user profiles, including the Citrix Profile Manager, and the AppSense Environment Manager. AppSense can even maintain a consistent user experience across platforms – making sure that the user profile is the same regardless of whether the user is logged onto a Windows XP system, a Windows 7 System, or a Windows Server 2008 R2-based XenApp server.

Do yourself a favor and make sure you understand what your users’ profile requirements are, then investigate the available tools and plan accordingly.

#8 – Lack of an application virtualization strategy
How many applications are actually deployed in your organization? Do you even know? Are the versions consistent across all users? Which users use which applications? You have to understand the application landscape before you can decide how you’re going to deploy applications in your new virtualized desktop environment.

You have three basic choices on how to deliver apps:

1. You can install every application into a single desktop image. That means that whenever an application changes, you have to change your base image, and do regression testing to make sure that the new or changed application didn’t break something else.
2. You can create multiple desktop images with different application sets in each image, depending on the needs of your different user groups. Now if an application changes, you may have to change and do regression testing on multiple images. It’s worth noting that many organizations have been taking this approach in managing PC desktop images for years…but part of the promise of desktop virtualization is that, if done correctly, you can break out of that cycle. But to do that, you must…
3. Remove the applications from the desktop image and deliver them some other way: either by running them on a XenApp server, or by streaming the application using either the native XenApp streaming technology or Microsoft’s App-V (or some other streaming technology of your choice).

Ultimately, you may end up with a mixed approach, where some core applications that everyone uses are installed in the desktop image, and the rest are virtualized. But, once again, it’s critical to first understand the application landscape within your organization, and then plan (and test) carefully to determine the best application delivery approach.

#7 – Improper resource allocation
Quoting Dan: “Like me, many users only consume a fraction of their total potential desktop computing power, which makes desktop virtualization extremely attractive. By sharing the resources between all users, the overall amount of required resources is reduced. However, there is a fine line between maximizing the number of users a single server can support and providing the user with a good virtual desktop computing experience.”

This post provides some great guidelines on how to optimize the environment, depending on the underlying hypervisor you’re planning to use.

#6 – Protection from Anti-Virus (as well as protection from viruses)
If you are provisioning desktops from a shared read-only image (e.g., Citrix Provisioning Services), then any virus infection will go away when the virtual PC is rebooted, because changes to the base image – including the virus – are discarded by design. But you still need AV protection, because the virus can use the interval between infection and reboot to propagate itself to other systems. The gotcha here is that the AV software itself can cause serious performance issues if it is not configured properly. Dan provides a great outline in this post for how to approach AV protection in a virtual desktop environment.

#5 – Managing the incoming storm
In most organizations, the majority of users arrive and start logging into their desktops at approximately the same time. What you don’t want is dozens, or hundreds, of virtual desktops trying to start up simultaneously, because it will hammer your virtualization environment. There are some very specific things you need to do to survive the “boot storm,” and Dan outlines them in this post.

#4 – Not optimizing the virtual desktop image
Dan provides several tips on things you should do to optimize your desktop image for the virtual environment. He also has specific sections on his blog that deal with recommended optimizations for Windows 7, and recommended optimizations for Windows XP.

#3 – Not spending your cache wisely
Specifically, we’re talking about configuring the system cache on your Provisioning Server appropriately, depending on the OS and amount of RAM in your Provisioning Server, and the type of storage repository you’re using for your vDisk(s).

#2 – Using VDI defaults
Default settings are great for getting a small Proof of Concept up and running quickly. But as you scale up your VDI environment, there are a number of things you should do. If you ignore them, performance will suffer, which means that users will be upset, which means that your VDI project is more likely to fail.

#1 – Improper storage design
This shouldn’t be a surprise, because we’ve written about this before, and even linked to a Citrix TV video of Dan discussing this very thing as part of developing a reference architecture for an SMB (under 500 desktops) deployment. We’re talking here about how to calculate the “functional IOPS” available from a given storage system, and what that means in relation to the number of IOPS a typical user will need at boot time, logon time, working hours (which will vary depending on the users themselves), and logoff time.

Just to round things out, Dan also tossed in a few “honorable mentions,” like the improper use of NIC teaming or not optimizing the NIC configuration in Provisioning Servers, trying to provision images to hardware with mismatched hardware device drivers (generally not an issue if you’re provisioning into a virtual environment), and failing to have a good business reason for launching a VDI project in the first place.

Again, this post was intended to whet your appetite by giving you enough information that you’ll want to read through Dan’s individual “top ten” posts. We would heartily recommend that you do that – you’ll probably learn a lot. (We certainly did!)

I’ve found that one of the least-understood features of XenApp is “VM hosted apps.” So, gentle reader, I thought it was time to try to bring some clarity to what is actually a very cool piece of technology, and may actually be the solution for how to continue to deliver IE6 for the Web apps that require it, even after you upgrade to Win7. (As you probably know, Microsoft has, so far, taken the position that packaging, streaming, or otherwise delivering IE6 by itself is a violation of their license – much to the consternation of users who have applications that depend on it.)

Why it exists
Anyone who has been around the block a few times with XenApp knows that there are some applications that just don’t play nicely in a multi-user environment. I can tell you that our own engineering team has become quite talented at making applications run in a XenApp environment even when the application vendors themselves said it couldn’t be done. And as the older DOS-based and 16-bit Windows applications gradually die of old age, things in general are getting better. Tools like application isolation and application streaming can help as well. But every now and then, you’ll run into an application that either just won’t run in a Remote Desktop Services (formerly Terminal Services) environment, or won’t play nicely with other applications, or misbehaves when more than one person at at time tries to run it.

We also occasionally run into applications that require some kind of hardware “dongle” as a license enforcement mechanism. Other applications have license mechanisms that are dependent on IP or MAC addresses, and/or save user-specific information that will require the application user to go back to the same system each time s/he wants to run the application. Finally, there may be users who need a very high-performance graphics processing unit, e.g., to run a graphics-intensive CAD program.

To help you deal with this, Citrix included a little bit of XenDesktop technology in XenApp, beginning with XenApp 5 Feature Pack 2. It’s only fair, after all, since XenApp functionality is now included in XenDesktop Enterprise and Platinum Editions, but while XenDesktop 4 (and now XenDesktop 5) includes all the functionality of XenApp for delivering applications to your XenDesktop users, XenApp’s VM hosted apps feature contains just enough XenDesktop functionality to create virtual – or physical – desktop systems specifically to run individual applications. In fact, that’s all those systems do. You can’t deliver multiple VM hosted apps from a single PC Operating System (well, not very easily anyway).

How it works
First of all, you have to build out the basic components of a XenDesktop farm. Yes, it can share some components with the rest of your infrastructure, but you’re going to need to build a Desktop Delivery Controller, you’re going to need a XenDesktop farm database, you’re going to need either a virtualization host (if you’re going to use virtual PC instances) or some physical PCs or blades, and you’re going to need an Operating System image with the target application installed into it. You may also deploy Provisioning Services if you want to stream the OS image either to your virtual infrastructure or to your blade PCs. In short, you go through the same process that you would go through if you were putting together a XenDesktop infrastructure to deliver a virtual desktop…but in this case, we’re delivering an application, not a desktop.

Here’s a high-level overview of the process:

• Create an OS image.
• Install the XenDesktop Virtual Desktop Agent into the image.
• Install the desired application. If the application needs “helper apps” (e.g., an accounting app may require Microsoft Excel to display reports), you can install them too. You can even install the Citrix Online Plugin, Offline Plugin, Single Sign-On Plugin, etc., if you want to launch those helper apps on a XenApp server or have XenApp stream them down to the desktop image for local execution.
• Create a shortcut for your desired application. If you really need to launch multiple applications, or launch something like the Citrix Online Plugin, create a script or batch file to launch the applications you want to launch, then create a shortcut to that script or batch file instead.
• Place that shortcut into the C:\Program Files\Citrix\ICA Service\SeamlessInitialProgram folder of your desktop image. NOTE: If you try to put more than one shortcut in that folder, you will get an error!
• Using the Citrix XenDesktop tools, convert your image into a VHD if you’re going to be streaming it via Provisioning Services or deploying it in a virtual environment. Like any other XenDesktop image, it can be a private image that is either preassigned to a specific user or assigned on first logon, or it can be a public image that you use with Provisioning Services to boot and run multiple instances.
• Publish that application. It can be displayed via the Citrix Web Interface right alongside other applications that are being delivered via XenApp.

When the user clicks the icon, the application will be launched within the desktop OS, but will run as a “seamless app,” meaning that it looks and feels to the user as though it was running locally (just as applications published from the XenApp farm do). The user will never know, or care, which apps are running on XenApp servers and which are running on desktop OS instances.

Just as you would with any other XenDesktop deployment, you can configure, via the Desktop Delivery Controller, how many OS instances you want running in an idle state at any given point in time during the day – this eliminates the need for the user to wait for the PC/OS to boot before launching the app. Remember, though, that a desktop OS is not multiuser…meaning that if you have ten people who may need to run that application at the same time, you have to provide resources for ten virtual PC instances (or ten blades, as the case may be). And if you have two different applications that need to be deployed this way, you’re probably going to need to provide separate resources for each application. (Yes, I suppose you could create a script that launched both apps – but do you really want your users to click on a single icon and launch two completely different apps? Never mind the fact that the users who need one of the apps may have no overlap with the users who need the other one.)

Here are a couple more things to remember:

• Your users are going to be remotely interacting with a Microsoft Desktop OS. That means you’re going to have to comply with Microsoft’s VDI licensing requirements. We’ve beat that horse to death elsewhere in this blog, so we won’t go into it again here.
• Citrix never expected that VM hosted apps would be used for more than one or two percent of all the applications you may need to deploy in a XenApp environment. But sometimes that one or two percent represent business-critical apps, even if they’re only business-critical to a handful of your users.
• You do not need XenDesktop licenses to do this. Users who launch a VM hosted app will consume a concurrent-use license from your XenApp license server. Users who launch multiple apps, e.g., a VM hosted app and several other apps delivered via XenApp, will still consume a single license.
• You could also use VM hosted apps to quickly deploy an application while you’re figuring out how to make that application run on XenApp. Once you’ve figured that out, just re-publish the application. The users will never know – they’ll go to the same Web Interface and click on the same icon, and the app will launch.

So – back where we started this: If you’re one of those who are struggling to figure out how you’re going to continue to support IE6 in your environment while still migrating your users off of Windows XP, this is one potential answer for you. Deploy IE6 on Windows XP using VM hosted apps. Your users will never see the XP desktop, so they’ll never know.

A very cool tool to have in your toolbox, in our opinion.

If you want to know more about VM hosted apps, here are a couple of videos from Citrix TV. The first is from the XenApp Expert Series, with our old buddy Vinny Sosa (on the left) and Modesto Tabares talking about various use cases for the feature. This one will take you about 25 minutes if you watch the whole thing:

…and here’s a more technical video from the Learning Lap series that actually takes you through the installation and configuration of VM hosted apps. This one is about 20 minutes long:

This is big news for anyone who wants to use XenDesktop to facilitate a Windows 7 migration. Here’s why: It only takes a moment’s thought to realize that if your desktop virtualization project simply trades inexpensive desktop SATA storage for expensive data center SAN storage, it’s not going to do good things for your ROI. So provisioning your virtual desktops from a shared Standard Image is a must. And that’s what Provisioning Services (“PVS”) allows you to do. If your standard Windows 7 OS image is, say, 15 Gb, you only need one instance of it on your SAN regardless of how many virtual PCs you’re provisioning from it. Then, using the Citrix Profile Management tool in conjunction with standard Group Policy folder redirection techniques, you can merge user personalization at logon time.

There was only one problem…turning a Win7 vDisk into a Standard Image broke the Microsoft license key. The only way around that was to use Key Management Services (KMS) to auto-activate systems as they were provisioned, but there were problems in using KMS with PVS, as we’ve documented in earlier posts.

I am happy to report that the problem has been addressed in PVS v5.6, SP1, which is now available for download at the Citrix download site. Not only that, but PVS v5.6, SP1, also works with a Multiple Activation Key (MAK) for smaller environments where KMS is not justified. Here’s the difference between the two activation methods:

KMS is a service that runs on a server in your own network. It supports Windows Server 2008 and 2008 R2, Vista, Win7, and Office 2010. However, it requires a minimum number of systems checking in for activation before any systems will be activated. That threshold is 8 systems for server activation, and 25 systems for workstation activation. Prior to SP1, systems provisioned from a Standard Image looked to the KMS server like the same system checking in again and again, so the threshold counter didn’t increment. SP1 fixes that. Please note, however, that you must be running KMS on a 2008 R2 server if you want virtual machines to increment the threshold counter.

With an MAK, the activation server is hosted at Microsoft. The MAK is a reusable key that’s good for a predefined number of activations. With SP1, PVS will cache the activation confirmation code for each system, so they will automatically reactivate on subsequent reboots.

Here is the configuration process, straight from Citrix. First of all, the Imaging Wizard allows you to choose which activation method you’re going to use:

Choosing the Activation Method

Once you’ve chosen either KMS or MAK, here are the next steps:

KMS Activation

• Reset the activation status on the vDisk image:
  • Boot the master target device from vDisk in Private Image mode
  • Run slmgr.vbs -rearm in console on master target device
  • Shut-down master target device
• Put disk in Standard Image mode and stream. Target devices will automatically register with KMS server, and activate (provided there are at least 25 systems checking in).

MAK Activation

• Put disk in Standard Image mode and stream.
• Use “Manage MAK Activations” to remotely activate streamed target devices. This is done only once per group of devices.
• Provisioning Services will cache activation confirmation code for each device so that devices will automatically reactivate on subsequent reboots.

Kudos to the Citrix PVS development team for getting this done and out the door. Great job!

Volume 9 of the Microsoft Security Intelligence Report is out, and it makes for some pretty interesting reading. Among other things, it talks extensively about botnets – the various “families” of botnets, how they are used, how they work, and how access to them is sold and traded on the black market. Why? Because (quoting from the report), “When we look at that intelligence as a whole, it’s clear that botnets pose one of the most significant threats to system, organizational, and personal security.”

One of the things you’ll find in the report is a discussion of the infection rates of different versions of the Windows Operating System. You may have noticed that every now and then, as part of the critical patches and updates that Microsoft pushes to your PC, there’s something included called the “Malicious Software Removal Tool,” or “MSRT.” Microsoft keeps track of how often the MSRT actually finds malicious software when it runs, and that information is presented here as the number of computers cleaned of bot-related malware per 1,000 executions of the MSRT. Take a look at the following graph, which covers just Q2 of 2010 (click to view larger image):

I would like to particularly direct your attention to the fact that the infection rate for Windows XP SP3 is four times the infection rate for Windows 7, and the rate for Windows XP SP2 is five times the Win7 rate.

I understand that, for some people, the issue of upgrading from Windows XP to something else borders on being a religious discussion. But, honestly, if Windows 7 is that much more secure – which it clearly is – isn’t it getting a bit difficult to justify the “you can have my Windows XP when you pry it from my cold, dead fingers” position?

Of course, larger enterprises have some challenges to overcome. As we discussed in our September post about the cost of a Windows 7 migration, Gartner recently reported that, since most organizations weren’t planning to begin their Win7 migrations until 4Q2010, and with PC hardware replacement cycles typically running at four to five years at present, most organizations simply will not be able to complete a Windows 7 migration through the normal PC replacement cycle before Microsoft ends support for XP SP3. There just isn’t enough time left.

But even if there was enough time – why would you not want to move to an Operating System that’s four times more secure as quickly as you possibly can?

As Gartner pointed out, one alternative is to move some users to a “hosted virtual desktop” instead of a new PC. Translation: Making VDI part of your migration strategy can help get you out from behind the eight ball. It can also boost the overall security of your organization. Doesn’t that make it a conversation worth having?

In our interview with the “Wyse guys,” they talked about the Xenith “zero client” terminal. To clarify, “zero client” doesn’t mean that there’s no local operating system in the device. It means that you – or better yet, your end user – can literally take one out of the box, plug it in, turn it on, and have it up and running with absolutely no need to do anything to configure it. Wyse says you can have it out of the box and running in five minutes. It took us about three…and we weren’t particularly hurrying.

The one thing you do have to do is to configure a DHCP option that will provide a pointer to your config.xml file. When you turn the Xenith on, it will query your DHCP server, and along with the basic stuff like the IP address, subnet mask, default gateway, and DNS settings, the DHCP server will, through the option you configure, provide the Xenith with the URL of your Citrix Web Interface server and the path to the config.xml file. The Xenith boots so fast that by the time your monitor wakes up and syncs to the video signal, you’re looking at a login prompt.

In this video, Steve Parlee of Moose Logic and Dave Jolley of Wyse walk you through the process of configuring the necessary DHCP option, and then demonstrate how easy it is to take a new Xenith out of the box and be up and running with a virtual desktop.