Out of the box, Windows 2000 Terminal Services can do some pretty neat stuff. Many administrators are including it in their arsenal as a cost effective way of providing some of the benefits of Windows 2000 to client machines that cannot immediately be upgraded to Windows 2000 because of hardware, financial, political, or other reasons.
However, in talking to customers and participating in techie mailing lists, I have realized that many administrators are missing out on some of the best tools and tips for making the most of Win2K Terminal Services. Admins may not know about or haven’t yet implemented some of the extra goodies that Microsoft supplies. Make no mistake: These tools can make the difference between being able to run Windows 2000 Terminal Services efficiently on a production network and being forced to struggle with the process or turn to third-party solutions.
The hidden extras that I’m going to cover in this article are:
- Local group policies
- Application security tool
- File copy
- Drive share
- License reporting
- License server viewer
- MMC snap-in
- .msi Terminal Services Client
And if you’re interested in fault tolerance and load balancing between multiple terminal servers, don’t forget that Windows 2000 Advanced Server supports this out of the box with clustered disks (Cluster Service) and network load balancing (NLB).
Local Group Policy
Local GPOs tend to receive bad or limited press from standard Microsoft documentation. That’s because most of the literature assumes an Active Directory environment where Group Policy can be defined at the site, domain, and OU level. Local group policy, which only relates to a single computer, can be defined but is discouraged because, by definition, the control is not centralized. More importantly, in order of GPO processing, it has the lowest priority, so local settings are likely to be overwritten by those at higher levels, if you are running Active Directory.
However, for administrators running Win2K Terminal Services outside of an Active Directory environment, a local group policy for Terminal Services becomes very relevant. If user accounts are not stored on the terminal server itself (e.g. using NT4 accounts), then only the computer settings will be relevant in the local group policy. But if user accounts are defined on the terminal server, then both the computer settings and user settings will apply.
A subset of the local computer settings can be found in Start | Administrative Tools | Local Security Policy (for settings such as password restrictions, audit settings, user rights, and IPSec). Loading gpedit.msc from the command line can access the full set. This is where you’ll find the Administrative Templates for controlling what users can use and see on their desktops and logon/logoff and startup/shutdown scripts. I suggest you use Microsoft’s “The Group Policy Reference” available in the Windows 2000 Server Resource Kit for more information on each setting.
However, you will want to make a note that any user settings defined in the local group policy will also apply to local administrators. You cannot filter local group policy settings to apply to only certain users (as you can with Active Directory GPOs). If this is a concern, then you could use the Application Security tool, which is explained in the following section.
Another work-around is to exploit the fact that the local group policy folder (%systemroot%System32\GroupPolicy) requires Read permission for users. If you configure the restrictive settings you want for users and then remove the Read permission on this folder for administrators, the settings will only affects users. The downside of this workaround is when you need to modify any local GPOs, you’ll have to first take ownership of the folder to give yourself permission to change the settings. When you’re done, change your NTFS permission back again.
Resource Kit tools
The Windows 2000 Server Resource Kit tools include the Application Security tool (Appsec.exe), File Copy (RdpClip), Drive Share (Drmapsrv.exe), License Reporting (Lsreport.exe), and License Server Viewer (Lsview.exe). You can get an explanation of what they are, how they work, how to use them, and sample syntax from the Win2K Server Resource Kit. However, here is a brief overview of each tool.
The Application Security tool is designed to restrict the programs users can run on the terminal server. When you load it, you supply the list of programs that you want users to be able to access. Because this is done by the executable name, it covers icons, shortcuts, menus, and supplying the name of the program on the command line. Administrators are automatically exempt from these restrictions; they can always run all programs unless restricted by other means (such as NTFS permissions or Group Policies). It works best when you want to supply a limited number of programs for users.
File Copy allows users to copy files and folders between the terminal server and their PC. For security reasons, this behavior isn’t allowed by default. However, there are many reasons why users will want to do this legitimately. This covers copying files to their hard disk, their floppy disk, their CDRW drive, and to any network drives they have mapped from their PC. Note that copying text (using the clipboard) between a Terminal Services session and a local machine is a supported option on Terminal Services out of the box.
Drive Share maps local drives on the user’s PC onto drives within the terminal server session and allows a user to access all their drives. The local drives automatically map to the last letters of the alphabet, so within a terminal server session, the user’s A: drive will display as Z: when using the terminal server’s Windows Explorer, their C: drive will display as Z: and so on. Obviously, this utility is often used with File Copy, but it’s important to note that if you want to use both you must install Drive Share first and then File Copy. If you already have File Copy installed and want to install Drive Share, reinstall File Copy afterwards.
License Reporting and the License Server Viewer
License Reporting is used to interrogate Windows 2000 Terminal Services Licensing. No administrator or manager likes having to run this additional service when using Windows 2000 Terminal Services in Application Mode, but you must run it in order to ensure your terminal server sessions will remain available. If all your terminal server clients are running Windows 2000 Professional, this service will have minimal impact. But if you connect pre-Win2K clients, then you have to install Terminal Services Client Access Licenses (TS CALs) onto license servers and monitor when the licenses are claimed.
You need to make sure that only legitimate clients are claiming these licenses and only one per machine. There have been a number of problems with computers incorrectly grabbing multiple licenses. If you haven’t already done so, install the Terminal Services licensing hotfix and read the information included with it.
However, be aware that you cannot reclaim licenses that were lost before installing this hotfix, and there may remain some licenses incorrectly taken. You need to spot these, remedy the problem, and claim back the licenses from Microsoft. You also need to keep an eye on when temporary licenses are being issued, because this means you have more terminal server clients than licenses and must buy more licenses before the temporary licenses expire.
You can use the Terminal Services Licensing MMC to keep track of which licenses you have and which computer claimed them (and when). That’s fine for ad-hoc maintenance. However, to keep on top of this as a routine administrative task, you really need an automated system that can interrogate the license system and spit out just the information you need without having to wade through every license detail. This is where the License Reporting tool helps out. It can collect the data you’re interested in and output this into a tab delimited text file, which you can then import into a spreadsheet or a database.
You can use the License Reporting tool to give you a list of all licenses, but perhaps more importantly, you can identify just the temporary licenses, which will tell you how many new licenses are outstanding. You can also use it to give you license information within a given date range so that, for example, you could chart your license usage per month.
You can also interrogate multiple license servers at once (used for fault tolerance and/or network bandwidth on remote sites). If you are not sure which license servers you have on your network, use the License Server Viewer tool to discover these servers on your network. It returns the names of the license servers and their type (domain or enterprise). Note, however, that this tool will not be able to find Windows 2000 terminal license servers outside the local subnet if you are not running Active Directory and enterprise license servers.
Three more gems
There are three more Terminal Services gems available in Windows 2000 Service Pack 1:
- Terminal Services Advanced Client (TSAC), an ActiveX control that allows you to run Terminal Services in a Web browser
- An MMC snap-in for Terminal Services, which is a must-have for all administrators (even if only using Terminal Services in Remote Administration Mode)
- An updated version of the Terminal Services Client in an .msi package format
The best thing about TSAC is the automatic deployment. You install the files onto IIS, and users connect to the “tsweb” virtual directory and are prompted to download a Microsoft signed ActiveX control. If you configure the site to be trusted (within Internet Explorer’s security options), the control will be automatically downloaded without prompting.
The MMC snap-in is a must-have for all administrators, even if only using Terminal Services in Remote Administration Mode, because it streamlines administration.
The updated version of the client in .msi isn’t only applicable to Active Directory environments where you can assign and publish .msi packages with GPOs. It’s also useful for non-Active-Directory networks because it will upgrade the client to support 128-bit terminal services encryption (even if the version of Windows is 56-bit) and can support a fully automated scripted installation from the command line including importing preconfigured terminal session details.
I think these hidden extras make supporting Windows 2000 Terminal Services much easier in a production environment. They are there for the taking, so make the most of them where appropriate.
Have a comment or a question?
We look forward to getting your input and hearing your experiences regarding this topic. Post a comment or a question about this article.