Support  |  News & Events  |  Blog  |  About  |  Help  

Category Archives: Licensing

XenDesktop 4 Campus-Wide Licensing

December 7, 2009 12:01 pm ⋅ Leave a Comment ⋅

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.

Posted in: Citrix, Licensing, VDI, Virtualization, XenDesktop ⋅ Tagged: , , , , ,

Implementing the New Citrix XenDesktop 4 Licensing Model

November 20, 2009 9:13 am ⋅ Leave a Comment ⋅

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!)

Posted in: Citrix, Licensing, VDI, XenDesktop ⋅ Tagged: , , , ,

Citrix Fine-Tunes XenDesktop 4 Licensing

November 9, 2009 1:13 pm ⋅ 1 Comment ⋅

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.

Posted in: Citrix, Licensing, VDI, XenDesktop ⋅ Tagged: , , , , ,

Provisioning Services, Microsoft Licenses, and KMS

November 5, 2009 8:39 pm ⋅ 9 Comments ⋅

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!

Posted in: Citrix, Licensing, Microsoft, Provisioning Services, VDI, XenApp, XenDesktop ⋅ Tagged: , , , , , , ,