You are here: Home > Blog

We were recently asked, by someone who was planning a XenDesktop 4 Proof of Concept, what minimum components were required to conduct the POC. Rather than prepare a document just for them, it seemed like a good idea to put the information here so others can read and contribute.

In its most basic configuration, XenDesktop is, functionally, going to look like this (click on picture to view full-size):

XenDesktop Functional Diagram


I lifted this drawing from a three-year-old Citrix PowerPoint presentation, and while XenDesktop has evolved considerably since then, the functional building blocks are still much the same:

  • You’re going to have a Desktop Delivery Controller (“DDC”). This is the Windows server that brokers the connection between the client device and the virtual OS. As you move into production and scale up the environment, you will probably have multiple DDCs.
  • You’re going to have a Citrix License Server. In a small deployment, like a POC, this service can also reside on the DDC.
  • You’re going to need a place for Citrix to store configuration data. In a production deployment, you’ll probably want the Data Store on a SQL Server. For the POC, it can also reside on the DDC.
  • You’re going to need a “Web Interface” server. One way or another, the client devices are going to communicate with the WI server, which will consume the user’s authentication credentials and (in most cases) present the user with the desktop choices that are available to him/her. I say “in most cases,” because it is possible to configure a client such that it will immediately connect to a designated virtual desktop without requiring the user to click on an icon.

    Once again, in a small deployment like a POC, the Web Interface services can run on the same Windows Server as the DDC, the Licensing Services, and the Data Store. So far, we haven’t moved beyond just a single Windows server – although, of course, as the environment expands and moves into production, these Web services should also be migrated to their own server.

  • All of this needs to live in a Windows Active Directory Domain, so if you’re building a POC that is isolated from your production environment, you’re going to need to provide a Domain Controller. That poor little DDC system already has enough running on it, so let’s make the Domain Controller a separate server.
  • You’re going to need some kind of virtualization infrastructure. XenDesktop is platform-agnostic at this level – it will run on XenServer, Hyper-V, or VMware. All of the other servers/services we’ve been talking about so far can be virtual servers running on this infrastructure. In a small POC, that’s the obvious way to go anyway.

Now things start to get a little tricky. That gray box that surrounds the repositories labeled “Profiles,” “Apps,” and “OS” can be broken down in a couple of ways.

Let’s assume that we are going to stream an OS, from a single, shared, read-only image, to virtual PCs that will be instantiated (I love that word – it just rolls off the tongue, and it sounds so technical) on-demand on whatever virtualization platform we’ve chosen. That means we need a Provisioning Server, and a place to store those read-only images. For a POC, the images can be stored on the Provisioning Server itself. When we move into production, since we don’t want the Provisioning Server to be a single point of failure in our VDI infrastructure, we’re going to want more than one Provisioning Server, which means that the OS images are going to need to reside on shared storage of some kind that can be accessed by all of our Provisioning Servers.

Elisabeth Teixeira of Citrix has a great 4-part series on High Availability for Provisioning Services over on the Citrix Community Blog site. Rather than go into detail here, I’d strongly recommend reading through her posts.

For our POC, the Provisioning Server can be virtualized. When we move into production, it’s probably best, for a variety of reasons that we won’t go into here, that they be physical servers.

Our virtual PCs are going to need apps as well. (After all, the entire purpose of a PC is to run apps, right?) If you wish, you can “bake” the applications into the read-only “golden” image that we’re going to use for provisioning, by first installing them on the PC that we’re going to use to create the image. Of course, that means that whenever you make a change to an app, you have to change the whole image, and we know what a pain that is, because many of us have been managing images for physical PCs that way for years. So we’re going to be better off if we stream the applications on-demand onto the virtual PCs after they’re booted up and users have attached to them. We will therefore need at least one XenApp server to manage the application streaming.

Finally, we’re going to need a file server to serve as a repository for user profiles and user data. The streamed OS images are, after all, read-only, so we’re going to need to use AD Group Policies to specify where that data is stored, since it can’t be stored in a profile that’s part of the streamed image.

One more thing comes into play, depending on what Windows OS you’re going to use for your virtual PCs. As we’ve noted in other posts, the process of converting a Vista or Windows 7 PC into a shared golden image will break the license key. You must therefore have a KMS Server available to auto-activate the PCs as they boot up. For best results, the KMS service should be running on a Windows 2008 R2 server. For more information on KMS and how it works, please see our earlier blog post on KMS.

That’s really all you need to do a POC, provided that all your clients will be connecting from within the protected network. If you want to grant access to clients connecting in from the public Internet, you’re going to need a secure way to do that. The simplest way is to use the software Citrix Secure Gateway that comes with XenApp. The CSG is basically an application-specific software SSL/VPN – running on a Windows Web server – that provides a secure proxy between the public Internet and the Web Interface server. For more demanding environments, you should consider the line of Citrix Access Gateway appliances, which can function as general-purpose SSL/VPN appliances as well as providing access to the XenDesktop infrastructure, and can provide advanced features like redundancy, automatic failover and, with the NetScaler software load, even provide Global Network Load Balancing for automatic failover between a primary site and a DR site.

If you have clients in branch offices connecting to your XenDesktop infrastructure across a Wide Area Network, you may see some benefits from deploying the Citrix Branch Repeater line of WAN optimization appliances. It’s likely that as we move through the year and see the release of new technology like XenClient, we will see an expanded role for the Branch Repeater with Windows Server and its ability to cache data locally at the branch office level – but that’s another post for another day.

So there you have it. To summarize, our minimum POC environment will consist of the following servers/services running on our virtualization infrastructure:

  • Domain Controller
  • A Windows Server hosting the following services (which can be broken out onto separate servers as the environment scales):
    • Desktop Delivery Controller
    • License Server
    • Data Store
    • Web Interface
  • Provisioning Server
  • XenApp Server (for application streaming)
  • File Server (optional – in a pinch you could make file shares available on one of the other servers)
  • KMS Server (if you want to provision Vista or Win7 PCs)
  • Secure Gateway Server or Access Gateway Appliance (if you want to provide secure access from the public Internet…note that this server or appliance should be in a DMZ for best security)

Citrix has announced that, effective immediately, the XenDesktop 4 trade-up offer has been extended to customers who have XenApp Advanced Edition. This is great news for those customers, because, under the terms of the original trade-up offer, XenApp Advanced customers would have had to first upgrade their XenApp licenses to XenApp Enterprise, and then do the trade-up.

The table below shows the pricing grid for the trade-up program, depending on which version of XenApp you currently own, which version of XenDesktop you want to trade up to, whether you’re trading up all of your XenApp licenses, and whether or not your Subscription Advantage is current (click on the graphic to view full-size):

XenDesktop 4 Trade-Up Pricing

XenDesktop 4 Trade-Up Pricing


Because the part numbers for the trade-up from XenApp Advanced have not yet been released, customers who want to take advantage of it will need to request a special quote. Two other points to remember:

  • If you trade-up 100% of your XenApp licenses, you get two XenDesktop licenses per XenApp license. Otherwise it’s one-for-one.
  • The trade-up offer runs through June 30, 2010. And as much as I hate to say this, that date will be here before you know it, so please don’t wait until the last minute!

The on-line trade-up calculator has been updated to include information for XenApp advanced.

Effective today (12/7/09), qualifying institutions can take advantage of Citrix’s new campus-wide licensing for XenDesktop 4. This is an annual license (meaning that you pay this every year) that is based on the concept of “Full Time Equivalents” (FTEs). For example, an FTE student is defined as either:

  • One student attending the educational institution on a full-time basis, or
  • Three students attending the educational institution on a part-time basis.

The suggested pricing is as follows:

  • XenDesktop Platinum – $29/year/FTE
  • XenDesktop Enterprise – $19/year/FTE
  • XenDesktop VDI – $9/year/FTE

There are several other things you need to know if you want to take advantage of the campus-wide pricing model:

  • For K-12 educational institutions, a “campus” may be defined as a single school, or as an entire school district. Either way, all FTE students must be licensed – either all FTE students attending that single school, or all FTE students in all schools within the district.
  • For higher educational institutions, a “campus” may defined as “a school or department, an individual location, or an entire multi-campus university.” For example, it could be the entire University of YourState, the University of YourState SpecificCity Campus, or just the University of YourState School of Engineering. Again, whichever definition you choose, you must license all FTE students that fall within that definition.
  • You are not required to license faculty and staff, but if you choose to do so, you must license 100% of them, “using the same FTE calculation as your Microsoft Campus or School Agreement.”
  • You must hold an active Microsoft Campus or School Agreement. The Citrix definition of “FTE” is deliberately designed to align with the definition Microsoft uses in these agreements.
  • To qualify for a campus-wide agreement, you must be:
    • “A school organized and operated exclusively for educational purposes, such as a correspondence school, junior college, college, university, scientific or technical institution, which is accredited by associations recognized by either the Department of Education and/or the local Education Authority, and that teaches students as its primary focus.” – or -
    • “The district, regional, or state administrative office of an entity described above, if the office is organized and operated exclusively for educational purposes.” – or -
    • “A hospital, healthcare organization, medical testing laboratory, non-profit museum or public library which is wholly owned by an entity described above. By way of example, the hospital or library of a university meeting the requirements would be part of the customer for purposes of this Agreement.” – or -
    • “Any administrative office or Board of Directors that controls, administers, or is controlled by or administered by an entity described above may also participate.”
  • There is a minimum purchase requirement of 1,000 licenses. You don’t necessarily have to have 1,000 students, you just have to buy 1,000 licenses.

You can find more information in this Citrix Community blog post by Sumit Dhawan.

A couple of days ago, while reviewing some of the blog posts here, I happened to read Sid’s post regarding Citrix’s new per device or per user licensing model for XenDesktop 4. That led, in a somewhat convoluted way, to this post, which will focus on how you would implement this new model.

Even though I already knew some of the changes that were being incorporated into this licensing model, as soon as I read his post I immediately asked myself how, exactly, from a technical standpoint that was going to work? You see, at that exact point in time I was actively working on upgrading our XenDesktop (XD) and Provisioning Server (PVS) lab to XD4 and PVS5.1 sp1, so this topic really interested me – for the simple reason that what Citrix says is supposed to happen was not what I was seeing in my lab. At that point I was already running XenDesktop 4.0 in my lab, and I’d done nothing to put any per user or per devices licenses in place (I do however still have my previous XD Platinum Licenses from my XD 3.0 build on my 11.6.1 license server), but everything worked and I was not getting any license errors. Strange, you say? I agree!

So, like any curious tech, I started what turned out to be a long and exhaustive search for information regarding how the new license model should be implemented. But after a few hours, and a few emails between Sid and I, I had unfortunately turned up nothing, zilch, nada! In fact, the only thing I could find from Citrix – and this is pretty much common knowledge at this point because lots of people have already blogged on the topic – is the set of XenDesktop 4 documents located in the new Citrix eDocs Library. However, if you actually plow through the XenDesktop 4 documents, you will discover that there is no information on how, from a technical standpoint, this new license model is supposed to be implemented.

During my search I did run across one (yes, only one) blog post which had some insight regarding how it will actually work. That blog post was by Helge Klein of Sepago, a Citrix partner in Cologne, Germany. In that post, Helge states, “If what I have been told is true, the current version of XenDesktop 4 has no licensing enforcement built in.” (emphasis added) Now that statement really got me interested, because that was consistent with what I was actually seeing in my lab, but could it really be true?

Again, my curiosity required that I had to verify this information one way or the other. So today I picked up the phone, called the Citrix XenDesktop support team, and asked, “How does it work?” The initial answer (which I actually expected and would have bet money on) was, “I don’t know!”

To the credit of the Citrix technical support person I had on the phone, he did not just let this drop. Rather, he kept digging and reviewing information until he finally turned up an “internal only” document – which, of course, he could not share with me. However, based upon what he was reading in that document, his answer – specifically regarding the named user model – was that any user who is supposed to be assigned a license will need to be placed into the OU that was created during the install of the Desktop Delivery Controller (DDC). My reaction was, “What? You guys are going to require a business to move their users from their current OU(s), which may have group policies being applied, and place them into the XD OU? That’s crazy, because businesses, especially larger enterprises, are going to laugh at us!” Then I asked, “Can we at least nest the OUs to maintain GPO and AD structure?” to which the answer again was, “I don’t know.”

Once again, to the credit of the Citrix support person, I was asked to hold and give him a few minutes so that he could go talk to the escalation team and get a definitive answer. When he returned he confirmed what he had told me about how it was supposed to work…however, he also confirmed that today in XenDesktop 4.0 there is no license enforcement mechanism coded into the product. Basically, the license enforcement is based upon the honor system and what is written in the EULA.

That’s not necessarily bad – it’s worked reasonably well for Microsoft for many years. And our experience over the years has been that nearly all businesses want to be legally licensed, and will comply with license requirements as long as (1) they understand what constitutes compliance (which hasn’t always been easy), and (2) they don’t feel like they’re being ripped off. But it’s certainly a bit unexpected, to say the least.

So, finally, I had the answer directly from the Citrix XenDesktop support team regarding how it is implemented, which left only one more question: When will license enforcement be implemented? The answer: “I don’t know!” So, until Citrix decides to shed some light on this for us, we’ll just live with EULA-enforced licensing.

One last thought: With all due respect, wouldn’t you think that Citrix would want to tell their own internal support people the details about something like this BEFORE the product actually launches? Maybe they didn’t want the world to know about the lack of license enforcement – but things like that always come out…it’s just a matter of time. (Pssst! Hey, Citrix – it’s not a secret anymore!)

In our post of October 6, hard on the heels of the Citrix news release that announced XenDesktop 4, (hereinafter called “XD4” to save wear and tear on my keyboard) we told you that XD4 was moving toward a strict per-user licensing model, rather than the concurrent-use model that Citrix products have been using since forever. Since that initial news release, however, Citrix has backed down on that position, and made some changes in how XD4 can be licensed.

XD4 Enterprise and Platinum Editions can now be licensed in either per-user or per-device mode. The per-device mode has obvious benefits in, say, classroom situations where a single device will be shared by multiple users, a clinical workstation in a hospital that is used by multiple users, or a factory floor where different shifts come and go. This aligns very closely with the Microsoft RDS CAL licensing model. (RDS, or Remote Desktop Services, is the new name for Terminal Services.) If a given use case would be more economically licensed using per-device RDS CALs, then per-device licensing for XD4 will probably make more sense as well.

A user who has been assigned a user license is entitled to use an unlimited number of devices to access an unlimited number of desktops. A device that has been assigned a device license can be used by an unlimited number of users. Just as is the case with Microsoft RDS CALs, user licenses can be reassigned permanently if a licensed user leaves the organization, or temporarily if a licensed user is absent for a protracted period of time. Likewise, a device license can be reassigned if a device must be replaced, or reassigned temporarily while a device is being repaired.

Customers can have both user and device licensing in the same enterprise, and licenses may be switched from user to device and vice-versa after 90 days. Once you reassign a license, you must wait at least another 90 days before you can switch back.

Just in case that’s not confusing enough, the low-end XD4 “VDI Edition” – which supports only VDI deployments and does not include any of the XenApp or “FlexCast” functionality – can be licensed in either per-user or per-device or concurrent mode. Concurrent licenses for the VDI Edition can be upgraded to either user or device licenses for XD4 Enterprise or Platinum Edition. However, within the VDI Edition, you cannot convert VDI concurrent licenses to VDI user or device licenses, nor can you convert VDI user or device licenses to VDI concurrent licenses.

License Management
Device licenses are assigned by manually adding a unique device identity to a device log. This device log must be manually maintained as devices come and go. User licenses leverage Active Directory – you create and maintain a specific OU for your licensed users.

One wrinkle that you may not be aware of is the concept of “overdraft” licenses. Citrix will actually grant one overdraft license for every 10 licenses that you allocate to a license file. These overdraft licenses are automatically rolled into the license file when it’s generated, and are displayed in a separate column of the License Management Console. The allocation of an overdraft license is recorded in the XenDesktop event log, but you won’t know unless you go looking for it – there is currently no alerting system that would proactively tell you that it’s happened. I would expect that, at some point, Citrix will build in some kind of overdraft alert.

Bear in mind that the overdraft licenses are not intended to let you, on an ongoing basis, exceed the license count you purchased. They’re intended to prevent the situation where a user is denied service because of a temporary spike in usage, or because a license hasn’t been properly allocated or re-allocated, and give you time to purchase additional licenses before the lack of available licenses becomes a crisis. Bottom line here is that if you think you’re getting close to your maximum license count, you should probably check the License Management Console from time to time to see how many licenses are actually in use, and whether you’re into your overdraft pool.

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

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

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

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

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

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

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

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

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

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

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

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

Citrix Changes the Game Again

October 6th, 2009 | Posted by Sid Herron in Citrix | VDI | XenDesktop - (1 Comments)

Disclaimer: Moose Logic is a Citrix Solution Advisor, and the author has worked with Citrix products for well over a decade – which is about how long there have been Citrix products to work with. As a fan of the company and the technology, it’s sometimes difficult to be objective…but I’ll try.

Citrix has shown in the past that it is not afraid to make bold moves to shake up the market landscape. The most recent was the decision to make XenServer, the “type 1” hypervisor obtained through the acquisition of XenSource, free. With today’s announcement of XenDesktop 4, they’ve made another bold move – arguably the boldest and the most far-reaching retooling of their product line ever.

You can read the press release at the Citrix Web site, and also get all of the details of the new offerings there, as well as from the volumes that will be written in the blogosphere and trade press over the next few days. But the basics are as follows:

  • XenDesktop, in all but it’s most basic version, will include XenApp. With a single XenDesktop license, you will be able to:
    • Deploy a shared virtual desktop from a XenApp-equipped Terminal Server, or deliver published applications running on a XenApp-equipped Terminal Server.
    • Connect to a virtual instance of a PC Operating System running on your choice of virtualization platforms (XenServer, Hyper-V, or VMware) – the classic definition of “VDI.”
    • Connect to a blade PC, if your computing or graphics needs are so demanding that you need dedicated hardware.
    • Stream a PC Operating System in real time to a desktop PC across the LAN – allowing you to boot and run your PCs from a common master image.
    • Stream applications to XenApp servers, PCs (whether virtual or physical), or both, and, if necessary, cache them for off-line use.
    • (Coming very soon) stream a PC Operating System to a client-side hypervisor, where it can be cached for off-line use.
  • XenDesktop will be moving to a per-user license model – a major shift, since Citrix licensing has almost exclusively been based on concurrent use as long as anyone can remember. Sales of concurrent-use licenses for XenDesktop will be discontinued on November 16, when sales of XenDesktop 4 licenses begin.
  • XenApp Enterprise and Platinum users with current Subscription Advantage will be offered a screaming “trade-up” deal that runs through June 30, 2010.
  • Strategically speaking, XenApp is clearly taking the back seat compared to XenDesktop. It will continue to be sold in all existing editions, but is being repositioned as the best solution for customers with high user concurrency (greater than 2:1), or those who use it as a “point solution” (e.g., remote access over limited bandwidth connections, call center applications, etc.). This also is a huge shift, when you consider that XenApp is the product that made Citrix.

So…what’s behind these moves? Citrix clearly believes that the battle for control of desktop delivery is where the future of the company lies. WinFrame/MetaFrame/Presentation Server/XenApp has been the de facto standard for remote access and server-based computing for well over a decade. But if all you care about is deploying Terminal Services (a.k.a. Remote Desktop Services in Windows Server 2008 R2), the value proposition for adding XenApp to your Terminal Servers has been steadily declining – and with the new features of Windows Server 2008 R2, it declines even further. This is why Citrix has worked so hard to reposition the conversation as one about application delivery as opposed to remote access or server-based computing, and why they have continued to roll more features into XenApp – particularly the Platinum Edition, which is really a suite of products more than an edition of one product.

Now they are working to reposition the conversation yet again. Nearly everyone agrees that there will be a huge uptake of Windows 7 over the next couple of years. And as Brian Madden pointed out in a techtarget.com article recently: “…there’s no sense virtualizing your desktops just to end up with XP again. And when Windows 7 launches, there’s no sense migrating to it while still managing your desktops the ‘old’ way.” Clearly, the Windows 7 rollout is a perfect opportunity for organizations to rethink the way they deploy and manage desktops.

The message from Citrix is clear: Desktop virtualization does not equal VDI. VDI, as it is classically defined, is only one way to deliver a virtualized desktop. There are many other ways – which we listed at the top of this article – and all of them have perfectly valid use cases. Since Citrix has solutions that cover all of those ways, it makes sense to offer a single license that will allow customers to “mix and match” and choose the best virtualization solution for each use case.

As the old saying goes, “Nothing succeeds like success.” If this works out the way Citrix obviously hopes it will, it will, by definition, be viewed as one of the most brilliant marketing moves since the deal with Microsoft that led to MetaFrame. At the very least, I think it must be recognized as a pretty gutsy move. And it’s certainly going to be fun to watch.

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