First published on CloudBlogs on Jun, 27 2006
TS License Server Discovery: or Why Listening to your Customer is a Good Idea
Hi, name is Rob Leitman, and I work on the Terminal Services team. Right now I work on TS Web Access and Remote Programs Publishing, but when I started on TS about eight years ago (!) I was working on Licensing.
I’d like to talk about the evolution of License Server discovery, and what we learned along the way by listening to customers.
NT 4 Terminal Server Edition
(Or as I like to call it: TS4.)
This was the first implementation of Terminal Services from Microsoft. I wasn’t involved in this version, but here’s the relevant info: every Terminal Server had a local License Server. This made it really easy for the TS to find the LS.
However, there was no way to track CAL usage across multiple Terminal Servers. Also, if you bought 100 CALs and had 5 Terminal Servers, how should you allocate these CALs among the Terminal Servers? Or should you just install all 100 on all the Terminal Servers? A bit of a mess.
Windows 2000
I joined the TS team right around we started work on Windows 2000 (which was much later than when the rest of Windows started work – a whole other story).
It was pretty clear that we needed a central License Server, but how should the TS find the LS? It seems logical that the easiest solution for the admin is to require no configuration at all. The TS should “auto-magically” discover the LS.
The easiest solution is to put the LS on a machine that the TS already knows about: the domain controller. That way, the TS just needs to check each DC to see if there’s a license server there.
But what about big companies with multiple domains – do we really want to force them to put an LS in each domain? Well, Win2000 had this neat new feature called Active Directory. Why not put discovery information there? That way, all TSs in an AD Site could use the same LS. We called this Enterprise Discovery, I guess because only big enterprises would have multiple domains.
But that still left TSs that were in a workgroup (or an NT4 domain with no Win2000 DCs). In that case, there’s no DC to install on, and no AD to put discovery information in. The best we could do in that case was to broadcast, and wait for an LS to respond.
So that’s what we shipped. If everything went well, this was a great system: install the TS, install the LS, and no further configuration needed.
However, some customers did have problems that were hard to figure out (especially over the phone with customer support). When the TS can’t find the LS, how do we figure out why? It’s pretty frustrating when you know the LS name, but have no way to tell the TS what the name is. Luckily we remembered that we had a registry key we had used for testing that would let you override the discovery mechanism and specify the LS directly. This was pretty handy, and maybe we should have realized that if we found it useful during testing, our customers would too.
Because this was never an official feature though, there were some drawbacks: only one LS could be specified, the admin tools didn’t pay any attention to the key, and all the discovery processes still ran after you set the key.
Another customer complaint was that poking every DC every hour caused some unfriendly audit events and unnecessary network traffic. Also, some domains have a lot of sites, possibly requiring slow or expensive network traffic to contact.
Finally, for simplicity of implementation we required LSs in domains to be installed on Domain Controllers. This makes sense for “Domain Discovery” but not for “Enterprise Discovery” (or for “Registry-based Discovery”). Most domain admins don’t like running extra software on their domain controllers.
Next Time: Windows 2003 and beyond
Rob
