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!

Color me skeptical when it comes to the “cloud computing” craze. Well, OK, maybe my skepticism isn’t so much about cloud computing per se as it is about the way people seem to think it is the ultimate answer to Life, the Universe, and Everything (shameless Douglass Adams reference). In part, that’s because I’ve been around IT long enough that I’ve seen previous incarnations of this concept come and go. Application Service Providers were supposed to take the world by storm a decade ago. Didn’t happen. The idea came back around as “Software as a Service” (or, as Microsoft preferred to frame it, “Software + Services”). Now it’s cloud computing. In all of its incarnations, the bottom line is that you’re putting your critical applications and data on someone else’s hardware, and sometimes even renting their Operating Systems to run it on and their software to manage it. And whenever you do that, there is an associated risk – as several users of Amazon’s EC2 service discovered just last week.

I have no doubt that the forensic analysis of what happened and why will drag on for a long time. Justin Santa Barbara had an interesting blog post last Thursday (April 21) that discussed how the design of Amazon Web Services (AWS), and its segmentation into Regions and Availability Zones, is supposed to protect you against precisely the kind of failure that occurred last week…except that it didn’t.

Phil Wainewright has an interesting post over at ZDnet.com on the “Seven lessons to learn from Amazon’s outage.” The first two points he makes are particularly important: First, “Read your cloud provider’s SLA very carefully” – because it appears that, despite the considerable pain some of Amazon’s customers were feeling, the SLA was not breached, legally speaking. Second, “Don’t take your provider’s assurances for granted” – for reasons that should be obvious.

Wainewright’s final point, though, may be the most disturbing, because it focuses on Amazon’s “lack of transparency.” He quotes BigDoor CEO Keith Smith as saying, “If Amazon had been more forthcoming with what they are experiencing, we would have been able to restore our systems sooner.” This was echoed in Santa Barbara’s blog post where, in discussing customers’ options for failing over to a different cloud, he observes, “Perhaps they would have started that process had AWS communicated at the start that it would have been such a big outage, but AWS communication is – frankly – abysmal other than their PR.” The transparency issue was also echoed by Andrew Hickey in an article posted April 26 on CRN.com.

CRN also wrote about “lessons learned,” although they came up with 10 of them. Their first point is that “Cloud outages are going to happen…and if you can’t stand the outage, get out of the cloud.” They go on to talk about not putting “Blind Trust” in the cloud, and to point out that management and maintenance are still required – “it’s not a ‘set it and forget it’ environment.”

And it’s not like this is the first time people have been affected by a failure in the cloud:

  • Amazon had a significant outage of their S3 online storage service back in July, 2008. Their northern Virginia data center was affected by a lightning strike in July of 2009, and another power issue affected “some instances in its US-EAST-1 availability zone” in December of 2009.
  • Gmail experienced a system-wide outage for a period of time in August, 2008, then was down again for over 1 ½ hours in September, 2009.
  • The Microsoft/Danger outage in October, 2009, caused a lot of T-Mobile customers to lose personal information that was stored on their Sidekick devices, including contacts, calendar entries, to-do lists, and photos.
  • In January, 2010, failure of a UPS took several hundred servers offline for hours at a Rackspace data center in London. (Rackspace also had a couple of service-affecting failures in their Dallas area data center in 2009.)
  • Salesforce.com users have suffered repeatedly from service outages over the last several years.

This takes me back to a comment made by one of our former customers, who was the CIO of a local insurance company, and who later joined our engineering team for a while. Speaking of the ASPs of a decade ago, he stated, “I wouldn’t trust my critical data to any of them – because I don’t believe that any of them care as much about my data as I do. And until they can convince me that they do, and show me the processes and procedures they have in place to protect it, they’re not getting my data!”

Don’t get me wrong – the “Cloud” (however you choose to define it…and that’s part of the problem) has its place. Cloud services are becoming more affordable, and more reliable. But, as one solution provider quoted in the CRN “lessons learned” article put it, “Just because I can move it into the cloud, that doesn’t mean I can ignore it. It still needs to be managed. It still needs to be maintained.” Never forget that it’s your data, and no one cares about it as much as you do, no matter what they tell you. Forrester analyst Rachel Dines may have said it best in her blog entry from last week: “ASSUME NOTHING. Your cloud provider isn’t in charge of your disaster recovery plan, YOU ARE!” (She also lists several really good questions you should ask your cloud provider.)

Cloud technologies can solve specific problems for you, and can provide some additional, and valuable, tools for your IT toolbox. But you dare not assume that all of your problems will automagically disappear just because you put all your stuff in the cloud. It’s still your stuff, and ultimately your responsibility.

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.

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:

Parameter XenDesktop Bandwidth without Branch Repeater XenDesktop Bandwidth with Branch Repeater
Office Productivity Apps 43 Kbps 31 Kbps
Internet 85 Kbps 38 Kbps
Printing 553 – 593 Kbps 155 – 180 Kbps
Flash Video (with HDX redirection) 174 Kbps 128 Kbps
Standard WMV Video (with HDX redirection) 464 Kbps 148 Kbps
HD WMV Video (with HDX redirection) 1812 Kbps 206 Kbps

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:

Yesterday (August 25), Citrix formally announced XenDesktop 4 Feature Pack 2. It’s expected to be available by the end of September, and, of course, will be available at no charge to existing XenDesktop customers whose Subscription Advantage is current. The big news in this Feature Pack is the incorporation of XenClient and XenVault.

We’ve talked a lot about XenClient here, but haven’t said much about XenVault. It’s high time we did, because it’s a pretty cool piece of technology in its own right.

If you’ve used Citrix products in the past, you know that we have administrative control over whether, for example, users who are running applications on a XenApp server are able to save data back to a disk drive on their client device. With the advent of Smart Access (enabled by Access Gateway Enterprise policies), we can get even more granular: we might allow a user to save data to a client drive if they’re connecting from within the protected network, or connecting from a corporate-owned laptop, but deny that same user the ability to do so if they’re connecting from a personal device or public location like a hotel business center.

Unfortunately, once the data is on a client device, you now have a security risk. It could potentially be copied to a USB drive. The corporate laptop could be lost or stolen. (For some of the more high-profile examples, check out the “laptop losers hall of shame.”) Nevertheless, it’s often viewed as a risk we have to take so that our mobile users can be productive.

XenVault, which was first previewed at the Synergy event last May, is designed to address this risk. XenVault is a new plug-in for the Citrix Receiver. As such, its deployment and configuration are controlled through the Citrix Merchandising Server. To quickly review, Merchandising Server is the preferred tool Citrix has provided for installing and configuring client software. The first time a user authenticates to the Merchandising Server (through a simple browser interface), the Citrix Receiver will be pushed down and installed on the client device, together with whatever plug-ins and configuration details the administrator has defined for that user. Subsequently, the Citrix Receiver will check back with the Merchandising Server behind the scenes, and receive any configuration updates that may be available.

The XenVault plug-in creates a secure, encrypted (256-bit AES) storage area on the client hard disk. Typically, any application that is running remotely on a XenApp server or XenDesktop virtual PC will only be able to store data in the secure, encrypted location, if it is allowed to store data on the client drive at all. Same for an application that has been streamed via XenApp for local execution on the client (regardless of whether it was packaged with the Citrix streaming tools or with App-V). While the user will be able to use Windows Explorer to look at the secure location and see what files are there, the user will not be able to copy files from the secure location to a non-secured area of the hard disk, nor open the files with applications other than those specified by the administrator. For a deeper explanation of how this works, see Joe Nord’s blog post on the subject.

If the laptop is lost or stolen, the administrator can issue a “kill pill” that will cause the secure, encrypted area to be locked or deleted the next time the Receiver checks in with the Merchandising Server. Pretty cool.

If you can’t wait until the end of September to try it out, and you have a mycitrix login, you can download the XenVault technology preview now. And keep watching this space, because I’ve got a feeling that this will be a good subject for a future video blog.

I just read an interesting blog post over on ZDnet, entitled The Changing Face of IT: Five Trends to Watch. As I read through the article, I was struck by how Citrix solutions can enable IT organizations to deal with these trends. Consider:

  1. The consumerization of IT – “Workers are bringing their own laptops and smartphones into the office and connecting them to corporate systems. More people than ever are telecommuting or working from home for a day or two a week. And, the number of Web-based tools has increased dramatically…”

    Yep. In fact many companies are instituting “BYOPC” (Bring Your Own PC) policies, because in the long run it can be less expensive to give employees a fixed allowance and allow them to buy whatever they want than it is to issue – and maintain – a company-owned laptop. Citrix themselves instituted this policy a few years ago.

    If you’re using XenApp or XenDesktop to provide access to your key line-of-business applications, you don’t care what the endpoint is. If your employee prefers a MacBook, fine. Want to use an iPad? No problem. Connecting in from your home PC because your kids are sick? We’ve got that covered, too. Just install the Citrix Receiver and you’re good to go.

  2. The borderless network – “…today’s IT security model is more about risk management than network protection. Companies have to identify their most important data and then make sure it’s protected no matter who’s accessing it and from wherever and whatever device they’re accessing it from.”

    Citrix likes to say that their products are “Secure by Design,” meaning that security is built into them from the ground up. First of all, when you’re accessing your virtual desktop remotely, or running a published application from a XenApp server, the data never leaves the data center. The remote endpoint (whatever it is) is just sending keystrokes and mouse movements to the data center and getting back pixel updates. On top of that, we can encrypt that data connection using the Citrix Access Gateway.

    Citrix also gives you very granular control over whether files can be copied between client and server, and/or whether print jobs can be directed to a client-attached printer. In fact, using Advanced Access Control policies, those controls can be context-sensitive, i.e., you might allow files to be copied to the client device if the client device is a company-owned laptop, but not if it is a home PC; or you might allow client-attached printing if the client is connecting from a branch office, but not if the same user, using the same client device, is connecting from home, or from a hotel.

  3. The cloudy data center – Let me go on record as saying that the most cloudy thing about the cloud is trying to understand what someone means when they say the word. Not unlike the word “portal” a few years ago, the first question that usually needs to be asked in any discussion about cloud computing is: “When you say ‘cloud,’ what exactly do you mean?”

    But the point to remember is that when you’re delivering applications via Citrix, users don’t know and don’t care where the data center is or where the applications are being executed. It doesn’t matter. Want to move your entire infrastructure to a co-lo? Fine. Want to have multiple data centers with automatic failover from one to the other? We can do that, too. By some definitions of the term, we’ve been building “private clouds” since the release of WinFrame back in the mid-90s.

  4. The state of outsourcing – “Outsourcing is thriving in many different forms, and it’s reasonable to expect that it will accelerate.”

    We made the point above that users don’t know and don’t care where the data center is. The fact is, for about 90% of what they need to do, neither do the administrators. Virtualization in general, and Citrix products in particular, make it very easy to administer, troubleshoot, and repair issues remotely. We built the entire Evans Fruit Company infrastructure without ever having our engineer set foot on site. In fact, actually dispatching an engineer to a customer location is now the exception rather than the rule.

  5. The mobilization paradigm – “While PCs still make sense on the desks of knowledge workers, for all of these other workers who regularly move around as part of their daily job, the stationary PC often changes the natural flow of their routine because they have to stop at a system to enter data or complete a task. That’s about to change. Mobile computers in the form of smartphones and touchscreen tablets (like the iPad) have taken a big leap forward in the past four years. They are instant-on, easy to learn because of the touchscreen, and they have a whole new ecosystem of applications designed for the touch experience…”

    Very true…but these same users are going to still need to access your traditional line-of-business applications, which will not be transformed overnight into touchscreen enabled apps. It is axiomatic that, in IT, nothing ever actually goes away – instead, new technology just gets layered over the top of old technology…which is why you’ll still find applications running on big mainframes in a lot of enterprises. So how do you manage that transition?

    Once again, Citrix comes through. There’s a Citrix Receiver for the iPhone, one for the iPad, one for Windows Mobile phones, one for the Android, and just a couple of months ago, Citrix released a version of the Receiver for BlackBerry devices. And, of course, Receivers for Windows, Mac, and Linux PCs have long been available. I don’t know of any other product or technology that offers this kind of flexibility in delivering applications to users regardless of location, connection, or endpoint device.

  6. So a big “Thank you!” to Jason Hiner for an excellent post. You’ve just described, in a nutshell, why Moose Logic is still excited to be a Citrix partner after all these years. Just remember, as you work to adapt to all of these trends that are indeed changing the IT landscape, we’ve got your back.

A couple of days ago, in the post entitled “What Is Application Virtualization?” I made the statement that, although application virtualization is a component of XenApp, and has been since the release of Presentation Server v4.5, XenApp is more than just application virtualization. To fully understand what I mean by that, you need to understand the Citrix vision of how applications should be delivered to users.

Over the years, there have been a lot of ways to connect client devices to server-based applications and desktops: Program Neighborhood, Program Neighborhood Agent, “Project Charlotte” which became Nfuse which became Web Interface, etc., etc. But if you look back over the last 15+ years, you will see an evolution toward the Citrix vision of “Any” – any application, to any device, anytime, anywhere, over any kind of connection – and you will see an ongoing effort to make it simple and easy for users to access the applications they need, as well as easier for the IT staff to deliver the right applications to the right users.

In Citrix’s view, the delivery of applications to users should be as simple as the delivery of broadcast content over your satellite TV network. Think about that model for a moment – you generally don’t have to worry about whether you have a big or small TV set, or whether it has a traditional picture tube (yes, there are still some of those around), an LCD screen, or a Plasma screen…because you have a receiver that conforms to an accepted standard, and that will connect to any TV. You bring the TV home, take it out of the carton, and connect it to your satellite receiver, and with little or no additional configuration, you can watch the channels you’ve subscribed to. And you get to decide what you watch and when. If you have a DVR built into your receiver (as most do these days), you can even cache the programming content and watch it later.

The current Citrix delivery method is darned close to this, and completely unique in the market, in my opinion. There are four basic components:

  • The Citrix Receiver, together with several plug-ins for the Receiver.
  • The Citrix Merchandising Server, which is a virtual appliance designed to run on either XenServer or VMware. My expectation is that it will also soon be ported to Hyper-V.
  • Citrix Dazzle, which is a mechanism for user self-service.
  • Citrix Update Service, which is an on-line service provided by Citrix that is responsible for notifying Merchandising Servers of available plug-in updates.

Let’s look at these in turn, then see how they all play together.

Receiver
Citrix used to have a lot of separate clients, that all had to be installed separately. You had a client for XenApp. You had another client for XenDesktop. You had one for the Access Gateway, one for Single Sign On (a.k.a. Password Manager), one for Branch Repeater acceleration, one for receiving streamed apps – you get the picture. It was getting a little ridiculous, not to mention difficult to manage, and cluttered up your System tray with multiple little icons. By contrast, the Receiver is a sort of “universal client” that is responsible for managing a variety of plug-ins on the client desktop. Instead of multiple client icons in your System Tray, you’ll have just one – the Receiver. The plug-ins are modules of client functionality that are managed by the Receiver. At the moment, you have plug-ins for:

  • Secure Access (for Access Gateway Enterprise Edition)
  • Secure Access (for Access Gateway Standard Edition)
  • Online Plug-in (for XenApp hosted applications/desktops and connecting to XenDesktop-managed virtual PCs)
  • Offline Plug-in (for streamed applications)
  • App-V Plug-in (for Microsoft App-V streamed applications)
  • Communications Plug-in (for EasyCall)
  • Acceleration Plug-in (Branch repeater)
  • Service Monitoring Plug-in (enables Edgesight for Endpoints to gather data from the client)
  • Profile Management Plug-in (enables Citrix Profile Manager)
  • Dazzle Plug-in (enables application self-service via the Dazzle interface)

Merchandising Server
The Merchandising Server is the virtual appliance responsible for managing and delivering the Receiver and its various plug-ins to end users. The Merchandising Server can contact the Citrix Update Service via the Internet and download the latest versions of the Receiver and plug-ins. Once you have those, you create rules that stipulate what the Merchandising Server will push to different users as they authenticate, depending on such parameters as Machine Name, User Domain Membership, Machine Domain Membership, Operating System, and IP Address Range.

The first time the user connects, s/he will point a browser at a designated URL and enter login credentials, and the Merchandising Server will push down the specified package, which will be automatically installed. One installed, the Receiver will periodically check back with the Merchandising Server for updates, so you can dynamically add, remove, or update plug-ins as required.

Dazzle
Dazzle is a new variation on the old Program Neighborhood Agent theme that enables user self-service. Those who have worked with Citrix technology for a while will remember that the PN Agent communicated “behind the scenes” with a special Web Interface site to retrieve a list of the published applications available to the user. Icons for those applications could be pushed onto the Start Menu, or accessed by right-clicking on the PN Agent icon in the System Tray. The Dazzle plug-in also communicates with a special Web Interface site, but allows the user to open a window, view the available applications, and select the ones s/he wants to use (see below):

Dazzle User Experience

Dazzle User Experience


Applications can be organized into multiple “Stores” by the Administrator, and can be tagged to appear in a “Featured” list to draw the user’s attention. There’s a friendly description of each available application, and a column that indicates whether that application will work offline (i.e., whether it will be streamed to the client machine) – and, by the way, it doesn’t matter whether the app was packaged for streaming using the Citrix tools or using Microsoft’s App-V, so long as you’ve delivered the correct plug-in to them. Applications that are not tagged as working offline are, by implication, going to be executed on a XenApp server, and therefore will only be available when the client has connectivity to the XenApp server farm.

The user can browse through the list, or use a search function, which is extremely valuable in an enterprise that may have dozens – or even hundreds – of applications. To select an application, the user simply clicks on the “Add” button. The selected applications will appear in a “Dazzle Apps” folder on the Start Menu tree:

Dazzle Apps Folder

The Dazzle Apps Folder


So let’s summarize what we have with this system:

  • Administrators can easily publish applications, and organize them into “App Stores.” Applications from multiple server farms can be integrated into a single App Store, or multiple App Stores can be created as desired (e.g., one for Human Resources, one for Engineering, etc.).
  • Users no longer have to install or configure anything – all required client software is transparently pushed out to them and installed, and automatically updated, by the Merchandising Server.
  • Users can help themselves to the applications they need to be productive, and to only those applications. Just because an application is available to them doesn’t necessarily mean they will have an icon for that application cluttering up their desktop or Start Menu.

I don’t think that application delivery can get much easier than that.

And why, you may ask, is User Self-Service something you should be concerned about? Well, in addition to the obvious fact that is makes life easier for both your users and your IT staff, take a peek at the following video. Increasingly, these are the people you are going to want to attract and retain as employees. They’ve grown up with technology, and they have their own preferred ways of using it to be productive. Here’s what they had to say about corporate computing:

This is why I contend that XenApp is substantially more than just application virtualization, and substantially more than “something I add to my Remote Desktop Servers to make things run faster.” It is a new and unique way of delivering to your users the applications they want and need, and only those applications, with minimal muss and fuss on both ends of the transactions. Increasingly, your users are used to the self-service model (e.g., the Apple on-line store), they find it intuitive, and they like it. It enables BYOC (“Bring Your Own Computer”) policies. It makes life simpler for everyone. And no one else has anything like it at the moment.

If this has caught your interest and you’d like to see more detail, check out the video below. It’s a bit long (about 30 minutes), but does an excellent job of explaining how everything works:

Some folks out there are still scratching their heads over the Citrix decision to change the name of Presentation Server to XenApp. There were actually several reasons for that change. For one thing, we’ve all seen Remote Desktop Services (formerly known as Terminal Services) get better and better with every release of Windows Server – and don’t think for a minute that Citrix didn’t see that coming. As closely as they work with Microsoft, of course they did. So it became obvious to Citrix long ago that they needed a better value proposition for their product than “something that I add to Terminal Services to get better performance.”

In point of fact, Citrix does have a considerably better value proposition than that – but not everyone was “getting it.” One way to help people get it is to re-frame the conversation by repositioning the product, and sometimes changing the product name can help make that happen.

But why XenApp? Well, that goes back to the acquisition of XenSource a few years ago. It seems that, after making that aquisition, Citrix decided that, in their vocabulary, “Xen” = “Virtualization.” Therefore…

  • “XenServer” = “Server Virtualization”
  • “XenDesktop” = “Desktop Virtualization”
  • “XenApp” = “Application Virtualization”

But does it, really? (XenApp, I mean.) Well, sort of. These days, application virtualization is a component of XenApp, but XenApp is more than just application virtualization.

Which brings me back to the question: What is application virtualization? I would suggest, as a good working definition, that, just as server virtualization is the abstraction of a server operating system from the underlying hardware, application virtualization is the abstraction of an application from the operating system it’s executing on.

We virtualize servers by interposing a layer of software – the hypervisor – between the hardware and the operating system. Although some operating systems, like Windows Server 2008, are virtualization-aware, meaning that they know when they’re running on a hypervisor and modify their behavior accordingly, earlier OS versions had to be fooled into thinking that they were running directly on server hardware when in fact they were not.

Applications today are still at the stage of development where they have to be fooled into thinking that they’ve been installed normally when in fact they have not. When they’re installed, applications typically write specific information to specific locations in the Windows registry. They place .DLL files into specific folders (most frequently into C:\Windows\System32) – and sometimes these .DLL files overwrite or conflict with others, which is why you can’t, for example, run two different versions of Microsoft Access on the same PC workstation without some kind of application virtualization. Application virtualization places a sort of “software wrapper” around the application – sometimes referred to as an “isolation environment,” or a “sandbox.” It causes these Registry keys and files to be written to an application specific location, and redirects the application calls so they can be found when the application executes.

By contrast, when an application is executed via Remote Desktop Services (with or without the involvement of XenApp), you’re really virtualizing the presentation of the application. The application is executing on the server, and the user interface is being presented remotely at a client device, using a protocol such as RDP (Microsoft) or ICA (Citrix) to transport keystrokes and mouse movements from the client to the server, and screen updates from the server to the client.

In the old days – and often today as well – that application was installed directly on the Remote Desktop server. Today, we can instead use application virtualization to deliver the application to the server for execution on demand rather than installing the application in advance in the traditional way. But it’s important to understand that presentation virtualization – running the application in one place and displaying the user interface in another – is not the same thing as application virtualization, which, as we have defined it, has to do with how that application is installed on the desired execution platform and how it behaves when it executes.

The first product to do application virtualization on a large scale for Windows apps was Softricity, by a company called SoftGrid. Softricity evolved into App-V after Microsoft acquired SoftGrid. App-V not only virtualizes the application as described above, it also allows the application to be streamed on demand to the computer that needs to execute it. Application streaming works better than you might think, because it turns out that for most Windows apps, most of the code is seldom (if ever) used. (Just think of all the arcane features in Word or Excel that the average user will probably never use.) So we can stream down just enough code to get the user interface up and running, and continue to stream additional code in the background as features are actually required.

The combination of (1) not having to explicitly install applications on workstations (or Citrix servers, for that matter), and (2) not having to worry about applications conflicting with one another can make life much easier for the IT staff:

  • You no longer have to run around from workstation to workstation with a backpack full of installation CDs.
  • It can potentially eliminate the old practice of having multiple “silos” of servers within a Citrix server farm to run applications that would not play nicely with one another.
  • It makes image management for both workstations and XenApp servers much simpler, because if all of your applications are baked into your OS image, then any application change requires that you change (and regression test) your OS image – but if a streamed application changes, all you have to change is that application.

Meanwhile, back in Fort Lauderdale, Citrix had been working on its own approach to application isolation, which was added to the Enterprise and Platinum editions of Presentation Server when v4.0 was released. This “Application Isolation Environment” then evolved into application streaming with the release of Presentation Server v4.5. For those who are familiar with the Citrix application publishing paradigm, you can now:

  • Run the application through the Citrix packaging utility
  • Park the resulting package on a shared folder that’s accessible by your target machines
  • Step through the process of publishing the application, with a new twist: “I want to make this application available to this group of users, on this set of XenApp servers, and here’s the path to the application package.”

NOTE: Yes, I know that not all applications can be successfully packaged for streaming. But most modern Windows applications can be. Yes, you’ll have to test your apps, or, if you have a lot of apps, use a tool like AppDNA to analyze them for compatibility.

Administrative options allow you to specify whether an application package will be streamed to a XenApp server to be executed there, or streamed directly to the client PC to be executed there, or conditionally streamed (e.g., stream to the client PC if a particular set of criteria is satisfied, otherwise execute the app via XenApp). You can also stream it and cache it on the client PC so, in the case of a laptop, it can be disconnected from the network and continue to run the app for a specified period of time.

So, in a sense, the application virtualization component of XenApp competes with App-V. Prior to the release of XenApp 6, our advice would have been to use XenApp to package and stream apps if your need was primarily to serve up apps to Citrix users, and use App-V if Citrix represented only a small piece of your infrastructure and you primarily needed to package and stream apps to Windows-based workstations. This was mostly based on the fact that App-V needed its own servers to control publishing and streaming of the applications – so if your primary need was to deliver apps to XenApp users, it didn’t make sense to build that App-V control infrastructure when your Citrix farm already had everything you needed to stream apps via XenApp.

One of the features of XenApp 6, however, is the ability to deliver App-V packages through the Citrix application publishing infrastructure, without having to build out the App-V back-end server infrastructure. So now you can use whichever packaging tool you prefer with your Citrix infrastructure. If your staff is more familiar with – or just prefers – App-V, it’s not a problem, because XenApp will support those packages natively.

A discussion of application virtualization wouldn’t be complete without mentioning VMware’s ThinApp. A while back, VMware, seeing which way the competitive winds were blowing, realized it needed an application virtualization solution of its own, so it went out and bought one. In addition to packaging and streaming, ThinApp can also wrap an application up as a free-standing executable, meaning that you could theoretically carry the entire Microsoft Office suite with you on a USB stick, and plug it into any Windows PC anywhere regardless of whether (or which version of) Office was installed on that PC. Of course, if you actually did that with a PC that wasn’t already legally licensed for Office, you’re violating your Microsoft Office license, but I digress.

There are other application virtualization products in the marketplace, but at the moment, the “big three” are App-V, ThinApp, and XenApp. However, as I said way back in the beginning of this post, XenApp is more than just application virtualization. And that will be the subject of my next post.

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