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."
Take Two Web Applications and Call Me in the Morning?
One reader wondered why he should bother with the TS headaches: "With the maturity of Web-based applications, we no longer need TS for application accessibility," he said.
Alex responded, "We see TS as being complementary to Web applications, but you want TS any time you want to make a rich application available. I don't think it's an either-or question at all."
Tad pointed out, "Simple HTML pages were designed to go over links that are fairly static so you can cache on either side. As soon as you need to pull data down, if you're on a thin link you can get a poorly performing application even if it's Web."
"In fact," Alex continued, "many Web applications can benefit if you put them close to the data in the data center. Then, using TS, you remote just the UI and save bandwidth, increase the application's performance, and improve the user experience. TS provides a rich experience without your having to worry about what the target platform is or isn't capable of."
Tad added: "And TS simplifies the security model. You can have one security model for all your apps, whether they're Web apps or non-Web apps. You don't differentiate at the app level. You just differentiate at the user experience level."
Alex agreed. "Security is a good point. The interface between Remote Desktop clients and the client you're running on is quite constrained in terms of the interactions allowed across that barrier, so with TS, no customer data is left on the local machine. For example, we see healthcare organizations with rich Web applications still delivering over TS to rooms in the hospital because they can help comply with HIPAA guidelines."
Tad went on, "Looking forward to the Longhorn timeframe, TS for Remote Applications lets you seamlessly launch an application from your desktop, and you don't have to worry about doing all the VPN plumbing to get back to the application."
Alex said, "Instead of remoting whole desktops, we can remote just the application and integrate it seamlessly with your local desktop so it looks and behaves like a local application."
No Panacea, but Progress
Alex and Tad understand the pain points with TS and are focusing on the problems you identified in this month's survey. Although the problems are clearly not solved, new functionality in Windows 2003 SP1 and imminent functionality in Longhorn Server seem to be moving in the right direction. Have you found solutions to some of the concerns the survey brought to light? I'd love to learn about your workarounds.