You are here: Home > Blog

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.

Citrix and Software Maintenance

December 16th, 2009 | Posted by Sid Herron in Citrix | Licensing | XenApp - (2 Comments)

Traditionally, Citrix has not offered “software maintenance” in the sense that most other software companies use the term. “Software maintenance” from most software vendors includes both ongoing upgrades and some level of telephone-based technical support. It also typically runs 20% – 25% per year of the cost of the software itself, depending on whether support is available 7 x 24, or only during business hours. Instead, Citrix offered something they dubbed “Subscription Advantage” (“SA”), which included upgrade protection, but no technical support. For technical support, they relied primarily on their channel partners (like Moose Logic) to deliver services and technical support to the end users. SA is also less expensive than other vendors’ software maintenance programs – typically running 11% – 13% (depending on the product) of the software list price.

For the most part, that has worked well for Citrix, the end users, and the channel partners. It’s no secret in our industry that nobody makes much money selling hardware and software. It is ultimately the revenue from architecting, installing, and supporting solutions built on the hardware and software that keeps the doors open and the lights on. Furthermore, on the rare occasion that we run into something that stumps us, we’ve got a direct pipeline into the Citrix support team…plus we get to bypass that first level where they ask you questions like whether your servers are plugged in and powered on. So when you engage with a competent Citrix channel partner, you get access to that partner’s technical expertise, which has been honed by lots of time spent in the real-world school of hard knocks, and you still get access to the Citrix technical support team standing behind that partner. The benefit to Citrix was that they didn’t have to staff up to handle the potential call volume from tens of thousands of customers.

The key word here is, of course, “competent.” We recognize that not all Citrix channel partners are created equal…and so does Citrix. Furthermore, there are some channel partners who simply specialize in license fulfillment, and really don’t have any capability to provide services. Finally, there are some end users who insist on being able to go directly to the manufacturer for support, and refuse to do business with manufacturers who won’t give them that ability.

To cover these situations, Citrix began offering separate, incident-based support agreements some time ago. These are pretty expensive: the entry point for XenApp support is a 25-incident plan for $7,500 that offers telephone support during business hours. If you want 7 x 24 support, you need to step up to a 50-incident plan that costs $25,000. If you want to buy one of these plans, you can buy them through your favorite Citrix channel partner, including us. The numbers aren’t so bad if you are a large organization with several hundred, or several thousand, XenApp licenses, but the fact is they just don’t fit a lot of customers who have only a few hundred (or fewer) licenses.

Recently, Citrix announced a real “software maintenance” option for XenApp, in the classic sense of the term. In addition to upgrade protection, it offers 7 x 24 telephone, Web, and email support. You get five annual incidents and one named contact for every 50 XenApp licenses you own. The cost is roughly 20% per year of the list price of the licenses. For example: if you own XenApp Enterprise Edition licenses that were not purchased through a volume license agreement, it costs you $50/year/license to simply renew Subscription Advantage. At your option, you can now pay $90/year/license and get both upgrade protection and 7 x 24 support. The MSRP of a XenApp Enterprise license is $450, so the math is pretty simple: just a tad over 11% for SA alone, 20% for full software maintenance.

Is this a good deal for you? (You know what I’m going to say, don’t you?) It depends. Are you happy with your Citrix channel partner? (Do you even work with a channel partner?) Is your Citrix infrastructure humming along with very few problems – as it should if it was built right in the first place – or do you need a lot of support to keep things running? How many XenApp licenses do you own? (Divide that number by 50, and that tells you how many incidents you’d get if you opted for software maintenance.) How does the cost compare with what you’d normally pay to your channel partner over the course of a year? How does it compare to the cost of buying a separate Citrix support agreement?

The 5-incidents-per-50-licenses formula can lead to some interesting trade-offs. For example, let’s say you own 190 XenApp Enterprise licenses. At $90/license, it would cost you $17,100 for software maintenance, and you’d get 15 incidents. If you simply renewed your SA (for $9,500) and bought a separate 25-incident plan for another $7,500, you would pay only $17,000 and end up with 25 incidents – although you would only have coverage during business hours. If you want 7 x 24 coverage, you’ve got to compare the software maintenance cost to the cost of a 50-incident, $25,000 plan, and software maintenance is going to be less expensive until you hit a crossover point at about 640 licenses. From there on up, software maintenance is going to be more expensive – but you’ll get more than 50 incidents.

If your eyes are starting to glaze over right now, I completely understand. You could, of course, build an Excel spreadsheet that calculated the costs of the various options for you when you entered the number of licenses you own (which is how I came up with the numbers in the preceding paragraph). Or, you can just go to the new Citrix on-line “Software Maintenance for XenApp Value Calculator.”

Software Maintenance Value Calculator

Software Maintenance Value Calculator


This tool lets you enter how many XenApp licenses you own, specify which version they are (Advanced/Enterprise/Platinum), specify whether or not you bought the licenses through a volume license agreement, and choose whether you want to compare the software maintenance cost with the cost of a 25-incident, business hours plan or a 50-incident, 7 x 24 plan. The tool will then present you with the relative costs of software maintenance vs. straight SA + the plan you picked for comparison.

At the present time, software maintenance is only available for XenApp Advanced, Enterprise, and Platinum editions. I suspect (based on nothing more than my own opinion) that, given the shift toward XenDesktop 4 as their flagship product, it won’t be long before we see something like this for XenDesktop.

Finally, please note that as of this moment in time, the on-line tool that we use to generate SA renewal quotes for you does not yet give us the option to generate a quote that includes software maintenance. That’s coming, but in the meantime, if your renewal date is coming up, and you want to explore the software maintenance option, please let us know so we can work with our Citrix contacts to get you a quote that includes it.

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

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

Live Messenger System Requirements

Live Messenger System Requirements


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

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

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

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

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

To install Live messenger you will need to download:

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

Customization and Installation steps:

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

    Open the Windows Live installer file

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

    Using ResHack

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

    Select Text to Replace

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

    Compile Script

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

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

Happy Messaging!

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

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

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

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

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

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

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

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

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

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

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

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

I have been cloning Citrix servers since the days of MetaFrame XP. Over the years I’ve done hundreds of systems and taught a number of people a process for cloning servers that has worked 100% of the time. Unfortunately that process required removing registry keys, running tools to change the SID, and “sterilizing” the image to get it ready to clone. Then once this was done you had to make a copy of the server (in the Bad Old Days we used Symantec Ghost – today we have better imaging tools, which we’ll discuss below), and then move that copy to either different hardware or to a virtualization platform. Then, after copying it, you had to reverse the whole process by adding back registry keys, changing the server name, joining the domain, and finally running “chfarm” (change farm) to join the machine back to the Citrix farm.

About a year and a half ago, Citrix came out with a tool called XenApp Prep, which takes the whole process down from about 30 minutes to just a couple of minutes (not including the amount of time to copy the files). With Windows 2008, the process is simple, and I’m going to tell you exactly how I clone an image. But before I start, I want to stress that, while the process is nearly the same for using XenApp Prep to make a V-Disk image for use with Provisioning Server, there are some slight differences, so be sure to read the “readme” file and the FAQ that come in the XenApp Prep zipped download.

Here are the high-level steps I use to create the server that I’m going to turn into a “Gold” image that I can then use as the source of my cloned image(s):

  1. First I install Windows Server 2008 and apply all critical OS patches and any optional patches I deem necessary to bring the server up to current standards. (Most IT shops have their own policies and standards for approving and applying patches, so your list may be different from mine.)
  2. Install any extra pieces that will be required by your application set: j#, .NET (whichever versions you need) with the appropriate SP, Java, etc.
  3. Turn on the required Terminal Services roles, and, if you are going to place the Web Interface on the server (I don’t personally recommend this), turn on the IIS role.
  4. When all my prerequisites are met – and you may want to check the admin guide or the Citrix Web site to find the most recent requirements – I install XenApp 5.0.
  5. Install the most recent Citrix service packs, hotfixes, feature packs, etc.
  6. Apply any best practices and tweaks necessary. (This is a whole topic by itself, so we won’t try to cover it here.)
  7. Now, unless I’m using application streaming (another subject we’re not covering here), I install all of my applications. Generally I start with Microsoft Office, because nearly all the time, a customer requires that at least part of the Office Suite be installed. For specific “line of business” and third-party applications, I would always want to work with the customer’s Subject Matter Expert (“SME”) to verify proper operation.
  8. After the application is installed, I have the SME test the functionality to verify that the application is functioning as would be expected to do whatever it is the business needs the application to do.

If the customer’s SME agrees that the applications are working correctly, I am ready to transform this server into my Gold image. This couldn’t be easier, especially if you’re virtualizing the XenApp servers. (And you know that XenServer is the best virtualization platform for XenApp, right?) Here are the steps:

  1. Hopefully I was thinking ahead and used a generic name for the server when I built it…but if for some reason I forgot to do that, I change the server name to something generic and reboot.
  2. Now I download XenApp Prep and install it to the server by running the MSI file. By default, the XenApp Prep installation places its executables in the C:\Program Files\Citrix\XenAppPrep directory (click image to view full size):
  3. The XenApp Prep Directory

    The XenApp Prep Directory

  4. If you are not creating an image for Provisioning Server – and we’re assuming here that you’re not – then all you do is navigate to the directory shown above and double click the XenAppPrep.exe to run it. (Again, refer to the readme and FAQ that come with XenApp Prep if you are creating an image for PVS.) A command window will appear, run a few commands, and close. That’s it – and that quick little process that took about 15 seconds saved you at least 10 minutes.
  5. Command Window

  6. Once XenApp Prep has completed, I next remove the IP address by either setting it to DHCP or to some static IP address. I prefer to set the address to something that’s not on its local subnet, so when it reboots, it cannot communicate until I want it to.
  7. I now navigate to the C:\windows\system32\sysprep directory, and doubleclick the sysprep.exe file to run, select the “OOBE” option (that’s “Out Of Box” Experience, not “Out Of Body”), select the option to shut down the server (not reboot), then click “next,” and sysprep runs – taking only a few seconds to complete:
  8. The Sysprep Directory

    The Sysprep Directory


    The Out-of-Box Experience

    The Out-of-Box Experience


    Sysprep Runs

    Sysprep Runs

At this point, you have your Gold image and you’re ready to deploy it over and over again. How do you do that? Again, it couldn’t be any easier:

  1. Copy the image to a new physical server using whatever imaging tool you prefer – we generally use Ultrabac’s UBDR Gold or Acronis, but whatever tool you prefer should work fine. If you’re virtualizing on XenServer, Hyper-V, or VMware all you need to do is copy the image to another storage repository.
  2. After the copying process is done – which is the longest step in the process of creating your clone – boot the server up, and follow the sysprep utility prompts (as though you just ran “setup” on a brand new server – hence the “Out of Box Experience”) to give the server its final name. This may take several minutes to complete.
  3. Boot Your New Server

    Boot Your New Server

  4. When sysprep is done, you will need to change the password in order to log on to the system.
  5. Immediately set the correct IP address and verify that the machine can ping the domain name.
  6. Go to the system properties and join the machine to your domain.
  7. Reboot
  8. When the server comes up this time, and you log onto the domain, your server should have already joined the Citrix farm and be ready to go. Just to be sure, I open a command prompt and type “qfarm” to verify that the server is now a member of the farm.
  9. Once you’ve confirmed that the server is in the farm, run the Access Suite Console, and configure it to see the farm. Once it comes up, I simply drag and drop the published applications that should be assigned to the new server and it’s ready to go.
  10. After I drag the applications onto the server, just to be sure, I again run a qfarm command – “qfarm/app” – to verify that the farm sees the new server with the newly allocated published applications on it.
  11. After you test the new server, make sure you’ve enabled logons on it.

That’s it – you now have another server in your farm, and creating more servers should only take you a few minutes for each one. (Of course the copy process is the slowest part…but you can always use that time to refill your coffee cup, comment on our blog site, or otherwise multitask if you’re really ambitious.)

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