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.”

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.

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.

Adrian Kingsly-Hughes wrote a great article on his zdnet blog entitled “Turkey Day” tech support survival kit. Even though Thanksgiving Day is behind us, those who are technically inclined will have ample opportunities through the rest of the Holiday Season to be buttonholed by family and friends who are…um…technically challenged.

This article describes how, with a little planning and preparation (and a few large-capacity USB flash drives), you can be ready to ride to the rescue of those whose plaintive cries for help can’t be ignored without negative social consequences.

Fenwick J. Moose (our PR Manager) attended last week’s Seattle Interface show. In addition to hanging out at the Watchguard booth, Fenwick took a turn around the show floor, where, of course, he was mobbed by people clamoring to have their pictures taken with him. Here are just a few (click on picture to view full size):

In our opinion, the Face2Face folks do a great job putting together a 1-day show with a lot of good content. It’s probably the best-attended local technology trade show in Seattle these days. Plan ahead to check with http://f2fevents.com and sign up for next year’s show.

You can also view more Interface pictures on Fenwick’s Facebook page. (Yes, he has his own…and if you’re on Facebook, you too can be a Friend of Fenwick.)

Moose Logic had a great time yesterday in the Watchguard booth at the Seattle Interface Show. Several of you filled out forms requesting evaluations of Watchguard products, or information in other areas of interest. Unfortunately, all of those forms were taken in a vehicle break-in at the parking garage of the Convention Center – along with pretty much everything else that was in the car.

If we promised you information, and you’re wondering why you haven’t heard from us, please contact us so we can make sure you get the information you’re looking for, and please accept our apologies for the inconvenience!

The TechTarget family of blog sites has a lot of great information. That’s why we have several of their sites linked in our Blogroll (under “Virtualization” in the right sidebar). But one thing that I don’t like about their sites is that – unlike this blog – there is no way to directly comment on their posts. That makes it difficult to respond to posts like the one last week on VMware’s High Availability (VMHA).

In that post, author David Davis opens by stating:

VMware’s High Availability (VMHA) provides high availability to any guest operating system at a potentially much lower cost than other HA options (as you don’t have to pay per virtual machines [VMs] or per server; VMHA is included in the price of vSphere).

I have a couple of problems with this statement.

First, I don’t know what “a potentially much lower cost” means. Is it less expensive than other HA options, or isn’t it? If it is, which other HA options are you comparing it to? If you’re going to throw that line out there, shouldn’t you give us the data on which the statement is based?

Second, it appears that the “lower cost” claim is primarily based on the fact that VMHA is included in the price of vSphere, rather than requiring a separate license. That’s a little like claiming that the high-end German sound system is less expensive if you get it in a Mercedes – because it’s standard equipment – whereas if you want one in your Malibu you have to buy it separately. What matters is the total amount of money I have to spend to get all the functionality I need, isn’t it?

It is true that with, say, Citrix XenServer, you have to purchase a Citrix Essentials for XenServer license to get HA functionality. That will cost you, at the suggested retail price (which nobody actually pays), $2,500 per XenServer for the Enterprise Edition. But the copy of XenServer you’re putting it on is free. On the other hand, vSphere 4 lists for $2,875 per processor, so if I’m using dual-processor servers, I’m looking at $5,750 for vSphere 4 compared to $2,500 for that copy of Essentials for XenServer. If I’m using quad-processor servers, vSphere 4 is going to run $11,500, but I still only need that single license for Essentials. And don’t forget the cost of VirtualCenter to control my vSphere environment, whereas XenCenter is, again, free, and runs on a workstation rather than requiring a dedicated server.

The point of this post is not to argue the relative merits of vSphere vs. XenServer, nor of whose HA feature is better. In fact, if you follow this blog, you’ll know that we’ve raised some red flags regarding how to properly deploy XenServer HA without risking potentially “career-altering” disasters. The point is simply that the old adage “don’t believe everything you read” is particularly appropriate for stuff you read on the Internet. (But you already knew that, right?)

People who throw out unsubstantiated generalized statements need to be challenged. If the TechTarget site allowed comments, I would have challenged the statement there. Since they don’t, I’m challenging it here. If I’m missing something, David Davis (or anyone else, for that matter) is welcome to comment on this post and point out what it is.

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!

Part 1 and Part 2 of this series covered the basic cryptographic concepts behind SSL certificates, and looked at how an SSL certificate is constructed and how it is validated. This installment will discuss what different kinds of certificates exist, some things to watch out for, and two big takeaways that will save you time, money, and aggravation.

Traditionally, an SSL server certificate, such as the Wells Fargo Bank certificate that we discussed in Part 2, were issued for the Fully Qualified Domain Name (“FQDN”) of the server the certificate is intended to secure. The certificate we discussed was specifically issued to “www.wellsfargo.com.” This is called the “Common Name” (abbreviated as “CN”), and is specified in the “Subject” field of the certificate:

That means that if there were other DNS entries, such as “remote.wellsfargo.com” or “email.wellsfargo.com” that happened to resolve to the IP address of the same physical server, and you pointed your browser at one of those, you would get a certificate error – because the certificate was issued to “www.wellsfargo.com,” not to one of those other entries, and the browser won’t be happy unless the host name in the address bar exactly matches the Common Name listed in the Subject field.

In recent years, a couple of new kinds of certificates have been introduced. One is the Multiple Domain, or “UCC” (Unified Communications Certificate) certificate. [Note: Yes, I realize that saying “UCC certificate” is inherently redundant – like saying “PIN number.” If, by chance, my former English professor is reading this, I apologize. But I’m going to do it anyway.] A UCC certificate contains an extra field called the “Subject Alternative Names” field, which can be used to list multiple subdomains that the certificate can be used to secure. For example, a UCC certificate could be used to secure “remote.mooselogic.com,” “email.mooselogic.com,” “extranet.mooselogic.com,” and so forth, provided that all of those subdomains are explicitly listed in the Subject Alternative Names field. That means that you must specify what subdomains you want listed when you purchase the certificate, and if you want to add or delete one, the certificate must be regenerated by the issuer (which will generally cost you more money).

In addition to the Subject Alternative Names field, a UCC certificate still has a “Common Name” listed in the “Subject” field. However, according to the X.509 certificate standard, if the Subject Alternative Names field is present, the client browser is supposed to ignore the contents of the Common Name field (although not all of them do). Therefore, if the common name is “www.mooselogic.com,” but that common name is not repeated as one of the Subject Alternative Names, a browser that strictly adhered to the standard would end up with a certificate error if it tried to connect to “www.mooselogic.com.” This interaction between Common Name and Subject Alternative Names has some implications for mobile devices that we’ll come back to in a bit.

The other new kind of certificate is the “Wildcard” certificate. A Wildcard certificate could be issued for, say, “*.mooselogic.com,” and used to secure any and all first level subdomains. (E.g., email.mooselogic.com is a first level subdomain; email.seattle.mooselogic.com is not a first level subdomain, and could not be secured with a Wildcard certificate.) A Wildcard certificate does not contain a Subject Alternative Names field – instead, the Wildcard (“*.mooselogic.com”) is actually listed as the Common Name in the Subject field.

If you are running a browser that was released anytime since 2003, it should support Subject Alternative Names, and probably Wildcard certificates as well. In that case, your browser will be happy if one of the following three conditions is true:

1. The host name in the address bar of the browser exactly matches the Common Name of the certificate. (Unless the cert is a UCC cert, in which case the browser is supposed to ignore the Common Name.)
2. The Common Name is a Wildcard, and the host name in the address bar matches the Wildcard.
3. The cert is a UCC cert, and the host name in the address bar exactly matches one of the names listed in the Subject Alternative Names field.

However, if you are using a browser on a mobile device of some kind, it’s a different story. Windows Mobile 6.x devices support both Subject Alternative Names and Wildcards. Windows Mobile 5 devices support Subject Alternative Names, but do not support Wildcards. If you’re not running a Windows Mobile 5 or 6 device, you’re going to have to check with the vendor of your mobile device. Some support both Subject Alternative Names and Wildcards, some only support one of them, some support neither.

So what? Well, if you’re trying to use a mobile device to synchronize e-mail with an Exchange Server, it’s usually done by pointing the device at the same URL that you’re using for Outlook Web Access (“OWA”). If you’re using a Wildcard certificate to secure your OWA site, and your mobile device doesn’t support Wildcards, you’re out of luck – it’s simply not going to work. However, if you’re using a UCC certificate to secure your OWA site, and the URL of the OWA site is also the Common Name of that UCC certificate, your mobile device will be happy even if it doesn’t support UCC certificates…because it will simply look in the Common Name field and find a match.

So here’s big takeaway #1: If you’re going to use a UCC certificate to secure multiple URLs, and one of those URLs happens to be the URL you’re going to use to synch email to mobile devices, make sure that URL is the Common Name of the certificate in addition to being listed as one of the Subject Alternative Names.

Another common “gotcha” involving SSL and mobile devices involves intermediate certificates. Remember that “chain of trust” discussion from the second post in this series? It is increasingly common to find that the certificate you have purchased to secure your Web site is not chained directly to the CA’s trusted root. Instead, there is at least one intermediate certificate in the chain between the trusted root and the certificate you purchased. This isn’t a problem for “big Windows,” because the browser is smart enough to sense that the certificate the server is presenting is not chained directly to the trusted root that it knows about, and to request the intermediate certificate(s) so it can validate the complete chain of trust. Mobile devices, including Windows Mobile devices, are not that smart.

Mobile devices depend on the server to present the entire certificate chain, including any intermediate certificates, at the time of connection. And the server won’t do that unless all of the intermediate certificates are present in that server’s own local computer certificate store. Installing the certificates into IIS for use in securing the OWA Web site does not automatically put them in the local computer certificate store – you must explicitly import them.

But why purchase a commercial certificate at all? Can’t you be your own Certificate Authority if you’re running a Windows Active Directory Domain? Yes, you can…if you don’t care about supporting connections from any PCs other than ones that have been joined to the domain, and you don’t care about supporting mobile devices. For example, when you set up a Windows Small Business Server, the wizard that configures that server for OWA automatically secures it with a self-issued certificate. That’s not a problem for any PC or laptop that has been joined to your SBS domain, because the very act of joining a computer to a domain inserts the domain’s own self-issued root certificate into the computer’s trusted root certificates store. But if you then try to connect from your home PC, or your mother-in-law’s PC, or any other PC that isn’t a member of your domain, you get a certificate error. At least with a PC, you have the opportunity to override the error and connect to the Web site anyway…but a mobile device will simply fail to connect, while typically giving you very little information about what the problem is.

You may or may not be able to manually import a certificate into the trusted root certificate store of your mobile device. Some mobile operators give their subscribers that level of “management access” to their mobile devices and some don’t. Some mobile operators provide special certificate installation utilities for their smart phones, some don’t. Sometimes there are workarounds, sometimes there aren’t. To our knowledge, there is no definitive list available of which mobile devices have their certificate stores locked down and which don’t. So the question is: How much is your time worth? The first time you (or we, on your behalf) spend a half day trying to make a mobile device work with an SSL certificate that wasn’t built into the phone, you will have spent more money – not to mention the time and aggravation – than it would have cost to go to a public CA and purchase a certificate that’s already supported.

So big takeaway #2 is: If you’re going to synch e-mail to mobile devices, do yourself a favor and decide in advance what mobile devices you’re going to support, then buy an SSL certificate from a public CA whose trusted root is already supported by those mobile devices. You’ll save money in the long run, and probably keep your blood pressure lower as well.

For more information on certificates and mobile devices, including a list of the trusted root certificates that ship with Windows Mobile 5 and Windows Mobile 6 devices, download the Moose Logic Technical Bulletin entitled Recommended Best Practices for Exchange Synchronization with Mobile Devices.

For quite some time now, Citrix has had the ability to stream applications on demand, either to XenApp servers, or to desktop/laptop PCs. If you own current versions of XenApp, you can use it. Microsoft also has an application streaming product called App-V, which it evolved from its acquisition of Softricity a few years back. They recently announced that they were going to discontinue the App-V for Terminal Services licenses, and just bundle the rights into what is now (in Windows 2008 R2) called the Remote Desktop Services (“RDS”) CAL. So if you own Server 2008 TS CALs or 2008 R2 RDS CALs, you’ve got the rights to use App-V to stream apps to your Remote Desktop Servers a.k.a. Terminal Servers.

Not wanting to be left out of the application streaming game, VMware went shopping a while back, and bought ThinApp. They maintain that ThinApp is better – or at least safer – because it runs exclusively in user mode, whereas both App-V and Citrix App Streaming require the explicit installation of an agent that contains kernel components.

So what’s the real story? Which application streaming technology should you use? Which is really best? As is so often the case with IT, the answer is a resounding, “It depends.” It’s sometime frustrating, but the fact is that we work in an industry where there is often no single “right way” to do something. But today I ran across a blog entry over in the Citrix Community Blog area that did such a great job of delving into the differences that I thought it was worth linking to here.

Check it out and let us know what you think.