If you think licensing your car and interacting with your state's Department of Motor Vehicles (DMV) is a headache, you probably haven't dealt with Windows Terminal Services (TS) licensing. "It stinks on ice," complained one of the 419 respondents to this month's survey about TS. Actually, licensing elicited the most colorful language (e.g., "sucks," "horrible," "hate") but rated as only the second biggest headache in managing terminal services. The biggest pain was printing and profiles: "Printing profiling," as another respondent said, "is a headache almost all the time."
I discussed the survey findings with representatives of Microsoft's TS product team: TS Technical Product Manager Alex Balcanquall and Group Program Manager Tad Brockaway. In addition, you'll find the TS team's interesting answers to some of your technical questions in the Web-exclusive sidebar, "Microsoft Answers Your Terminal Services Questions" (http://www.windowsitpro.com, InstantDoc ID 49220).
Licensing: The "L" Word
"Why is the licensing process so onerous?" one reader asked. Alex replied, "The two aspects of licensing are the technical aspect (how do you use the license server, or configure the servers?) and the Client Access License (CAL) aspect (what am I supposed to buy in what situation?). On the technical side, we recognize that it's very easy to misconfigure the terminal server and the license server. Sometimes, the terminal server doesn't see the license server, or the wrong type of licenses are installed, or the terminal server is set in the wrong mode compared with the licenses. In Windows Server 2003 Service Pack 1 (SP1), we improved the Setup Wizard so it now prompts you to choose a mode and explains why you need to choose a mode. Also, rather than relying on automatic mechanisms that can be problematic on some networks, you can now specify the name of the license server you want. We've had event log entries that recorded when the server couldn't find any licenses and therefore was going to stop allowing clients to connect in 90 days. However, these log entries were cryptic and hard to locate, so we improved them. Pop-up balloons identify issues with the terminal server and prompt you to look at the event logs. If the terminal server might stop accepting connections because it believes there are no licenses or because it can't find them, you should now know in advance so you can go back to the licensing UI. Also, customers can now use updated MOM management packs to collect and report on those events. And in our Windows Server 2003 SP1 Microsoft Management Console (MMC) UI, we added information regarding mismatched licenses and unactivated license servers."
Another reader asked, "Why use a separate licensing server and charge extra for separate CALs? This is confusing, provides no benefits, and is an administrative headache. It stinks." Alex replied, "Because of the nature of devices people use with TS, we wanted to ensure that people were using the appropriate number of CALs. Because the devices may have no state, it's hard to know how many devices you have and where they are. They don't appear in AD. The licensing server tells you how many CALs are consumed and how many you've got left. We understand that this is a pain for customers. We know customers want to be compliant. They don't mind about the enforcement, but they'd like to know how many CALs are left. Whether we can address this in the Longhorn timeframe—I'm not in a position to make promises on that."
So what can you do? Alex advised, "Buy device licenses when you have more users than devices. Buy user licenses when you have more devices than users."
Because nearly 45 percent of respondents said that they are planning to adopt x64-based technology for TS, I asked about licensing for 64-bit multicore machines. "From a TS perspective," Alex said, "it's simple: If you have one CPU with dual core, that's considered one CPU. There are no CAL requirement differences, either. The CAL will let you connect to a 32-bit machine or a 64-bit machine."
Printing, Profiles, and Device Support
"When will [Microsoft's] local printing for remote users be better dealt with, as it is by current third-party products?" was a representative reader question.
Alex answered, "For Printer CL (PCL) or PostScript printers, Windows 2003 SP1 introduced a new fallback printer driver, which will pick a generic PCL or Post-Script driver if it can't find a matching one on the server. We're also investigating WAN issues to see what—if anything—we can do. In the meantime, Microsoft's partners have printing solutions."
Addressing reader concerns about printing profiles, Tad said, "The big problem with profiles today is the Windows 2000 implementation of roaming profiles, which effectively just blindly copies the entire profile from the file server over to the client machine—or in the case of TS, to a server machine. Then, when the user logs out, the whole profile is copied back over. The copy is so coarse that a profile can easily be corrupted if you're logged in to two machines at the same time. All sorts of performance problems arise because it's such a coarse copy, so this problem is hard to solve for TS scenarios."
Alex pointed out, "We released a tool for Windows 2003 called UPH Clean [officially, User Profile Hive Cleanup Service], which solved some of the corruption and other issues with profiles—not just with TS, but also with XP. We're looking to take that tool into the OS in Longhorn. Today, people running TS should consider UPH Clean mandatory, not optional. I'm not sure there's a huge amount of awareness on that tool. Of course, several vendors also have tools." (To find out more about these third-party tools, see Microsoft's Terminal Services Partners page.)
Moving on to discuss requests for USB device support, Alex explained, "USB support is a non-trivial exercise. We are looking at improving device redirection, and we're still locking down exactly how the solution will work. It's going to require that vendors write drivers that are remote-able. The solution will be based on Plug and Play (PnP) devices rather than buses, and it will use the usermode driver framework in Vista. We talked about this in our executive chat with Bob Muglia on TechNet."
"Bus remoting is very hard to do," Alex told me, "because if your USB device expects a response in 1/100th of a second and you have network latency, you're not going to get that response and things fail very quickly. So we're looking at a slightly different mechanism."
Previous
Register
