Greetings, all:
A few months ago, I reviewed some licensing information in an issue of Terminal Services UPDATE. Because that newsletter dealt with inhouse terminal services, I skipped one part of Microsoft's licensing model—server-based computing licensing as it applies to application service providers (ASPs). However, now that we've merged Application Service Provider UPDATE and Terminal Services UPDATE, it's a terrific time to ask the obvious question. Why is there a difference between inhouse server-based and ASP server-based computing licensing models?

For those of you who didn't know there WAS a difference, let me elucidate. If the people who access your terminal server work for the same company you work for, your company must purchase terminal server licenses on a per-seat basis. For example, anyone who accesses the terminal server from a computer running Windows 2000 Professional can draw licenses from the built-in pool created on the terminal server license server. However, if the people who access your terminal server rent applications from you, the rules change. In that case, access to the OS might be licensed either on a per-subscriber basis or on a per-CPU basis. In per-subscriber mode, each authorized subscriber needs a Subscriber Access License. In per-CPU mode, for each CPU license an unlimited number of subscribers can use the software that runs on a single CPU.

Having separate inhouse and outsourced licensing models leaves Microsoft open to an obvious (and often-asked) question—why the difference? People who run inhouse Windows terminal services have wrestled with the per-seat licensing structure since 1998, when Microsoft released Windows Terminal Server. As I've discussed in this space before, licensing access on a per-seat basis exposes Terminal Server to a number of problems, such as a one-time use eating a license, reinstalled PCs forgetting that they have a license, and rented PCs taking their licenses back with them to Ye Olde Rental Outlet when the leases end. Adding insult to injury is the fact that most inhouse Windows terminal services installations use MetaFrame. (A year ago Giga estimated that MetaFrame was installed on 90 percent of Windows terminal servers. Microsoft, a bit more conservative, estimated 70 percent. Even with Win2K's improvements to Windows terminal services, you won't find MetaFrame now installed on a minority of Windows terminal servers.) MetaFrame uses per-connection licensing, so anyone who administers an inhouse terminal server needs to keep track of both per-user and per-connection licenses.

Obviously, no self-respecting ASP will want to mess with a licensing nightmare like this, so Microsoft doesn't make them. ASPs get to choose between per-subscriber and per-CPU modes. The trouble is, people who use Windows terminal services inhouse will still have the same problems they've always had. I was happy to hear that Microsoft plans to let license servers reclaim terminal services client access licenses (TSCALs), but these changes are only a partial fix. And if you consider that terminal services are supposed to make applications more platform-independent, a license scheme that restricts you to logging in from a particular machine doesn't make a lot of sense. A real fix would be to move to a current-usage model (such as the per-CPU license model) or to a per-user model, so that it truly doesn't matter which device you use to connect to the terminal server.

Honestly, a Byzantine licensing system helps me, because I make my living explaining complications. But this licensing system is scaring away potential terminal services users. I'm told that the higher-ups at Microsoft finally "get" the concept of terminal services. If so, let them prove it by moving to a terminal services licensing scheme that makes sense for EVERYONE.