Managing Servers via Remote Desktop
You get the ultimate in server-based storage by eliminating the PC completely. Thin-client computing has been steadily gaining market share over the last few years as companies discover this and other benefits of hosting users directly on a server in a multiuser environment.
Multiuser Windows got its start in 1995 with Citrix WinFrame, a rework of the NT 3.51 base code. Citrix had already made its mark in the multiuser market with WinView, a rework of the OS/2 base code. The enabling technology in both WinView and WinFrame was Citrix's Integrated Computing Architecture (ICA) protocol, a highly efficient client/server mechanism for transmitting session information.
When NT4 came out, Microsoft decided that the multiuser code belonged in the core OS rather than an OEM version. Citrix and Microsoft worked out a licensing arrangement whereby Citrix retained control of the ICA protocol and Microsoft got everything else. The result: NT4 Terminal Server Edition, a mix of Microsoft and Citrix code.
In Windows 2000, Microsoft upped the ante by incorporating multiuser functionality into the base operating system rather than shipping it as a separate, layered product. This improved performance and stability. Windows 2000 terminal services had two operational modes:
Remote Administration mode.
This permitted two administrators to run sessions at a server at the same time.
This permitted any number of authorized users to run sessions concurrently, with each session getting discrete configuration parameters saved in the user's home directory.
Microsoft has now made terminal services ubiquitous throughout the product line. Both servers running Windows Server 2003 and XP desktops have terminal service capabilities. Microsoft also changed the terminology associated with terminal services. The ability to establish a terminal service session is now called Remote Desktop. The ability to host multiple, independent user sessions, similar to the Windows 2000 Application mode, is now simply called Terminal Services.
That's the good news. The bad news is that while the two-node concurrent access license is now standard on all servers running Windows Server 2003, true Terminal Services—that is, the ability to host multiple, concurrent, independent sessions—is only available on Enterprise Edition and Datacenter Edition. This adds at least a couple thousand dollars onto the cost of a terminal server, in addition to the client license costs.
Remote Desktop Protocol (RDP)
There are two ways to initiate a terminal services session on Windows Server 2003. One is Microsoft's proprietary Remote Desktop Protocol (RDP). Originally called T-Share, RDP is a rework of the international standard T.120 communications protocol. RDP is fast and permits multichannel communication, but up until Windows Server 2003 and XP, it was somewhat clunky and sported few features. RDP requires a Windows client.
The other interface is Citrix's ICA protocol. Using ICA requires loading the Citrix MetaFrame service and using an ICA client. There are ICA clients for virtually all non-Windows platforms, from Linux to HP-UX to Macintosh.
If you want to avoid the additional complexity and cost of MetaFrame to get non-Windows client support, there are a couple of alternatives. You can purchase a Java RDP client called HOBLink JWT that can connect to both W2K and Windows Server 2003 terminal services. Visit www.hobsoft.com for details. There is also an open-source RDP client. Download it from www.rdesktop.org.
Don't ignore MetaFrame completely, though. Citrix has worked hard over the last few years to add value to MetaFrame and ICA to make them worth the additional investment. For example, if you want to publish individual applications from a robust, centrally-managed server farm, you need MetaFrame. Visit the Citrix web site at www.citrix.com to see the new features in MetaFrame for Windows Server 2003. The product isn't free, not by a long shot, but the features are compelling and you'll get solid performance.
Still, you may not need MetaFrame after you see the features in the new version of RDP. Version 5.1 is not only faster and more reliable than earlier versions, it supports 24-bit color, a full suite of device redirection options, clipboard sharing, 128-bit encryption, and the ability to use keyboard shortcuts within the session. You can also use RDP to connect directly to the console of a server running Windows Server 2003 or XP desktop, something that required NetMeeting in earlier versions of Windows.
You can also run terminal services within a network load balancing (NLB) cluster. This feature was present in Windows 2000 but it was dogged with connection problems. Microsoft improved NLB cluster support in Windows Server 2003 with the addition of a Session Directory service. When a user connects to a server in the NLB cluster, the server notifies the Session Directory. If the user disconnects then reconnects, the server accepting the connection checks with the Session Directory then ushers the user back to the original server.
The Remote Desktop client (Mstsc.exe) is installed on every version of Windows Server 2003 as well as XP desktops. The shortcut is located in the classic Start menu under PROGRAMS | ACCESSORIES | COMMUNICATIONS | REMOTE DESKTOP CONNECTION.
The new Mstsc client differs from the Windows 2000 version by combining the RDP client with the connection manager, something that required two separate executables in Windows 2000. The configuration files saved by Mstsc are simple text files with an RDP extension. You can double-click one of these RDP files to open a session with the target server. This makes it simple to distribute links to clients.
The RDP 5.1 client will run on any 32-bit Windows platform. The Windows Server 2003 CD has an MSI package you can use to deploy the client to Windows 2000 desktops using group policies. You can push the client to your Windows NT/9x/ME clients using whatever deployment method you currently use. It requires the Windows Installer to run. Installation on downlevel clients requires a restart.
Advanced Client Features
As you are probably aware, Microsoft included "advanced" RDP clients in Windows 2000 SP1 and later:
An MMC console-based client, Mstsmmc.msc, that supports simultaneous connections to multiple servers in the same window.
A web-based client consisting of an ActiveX control, Msrdp.ocx, and an installation script, Msrdp.inf.
These clients are also in Windows Server 2003 under different packaging. The MMC-based client is installed by default on every Windows Server 2003. The shortcut is located under START | PROGRAMS | ADMINISTRATIVE TOOLS | REMOTE DESKTOP. The web-based client is a component of IIS along with a virtual folder, TSWeb, that contains an ASP page, Connect.asp, that collects credentials from users and routes them to whatever terminal server they select.
The RDP 5.1 client also has additional connection functionality exposed on the command line. Type mstsc /? to get a list of the options. Two of them are especially useful. You can specify a different port (RDP uses TCP port 3389 by default) if you need to get through a firewall. You can also connect directly to the console of a server rather than creating a new session.
RDP Client Connection Features
The Remote Desktop Connection application, Mstsc, contains the management options for the client. Launch it via START | PROGRAMS | ACCESSORIES | COMMUNICATION | REMOTE DESKTOP. (See Figures 19.10 and 19.11 for example windows.)
Figure 19.10. Remote Desktop Connection window showing the Display tab.
Figure 19.11. Remote Desktop Connection window showing the Experience tab.
Here are the features that can be managed from the client interface:
The session desktop can be any size up to and including the size of the base PC desktop. If launched as full screen, a navigational aid appears at the top of the screen to help remind the user that the screen displays a session and not the base desktop.
You can elect to use the Windows hot keyzs within the RDP session rather than on the base desktop. This is a big help for users who get confused when their favorite shortcut (like Ctrl+Alt+Del or the Window key) doesn't work as they would expect in the session.
Maximum color depth is 24 bits, but you'll get better performance without sacrificing much in the way of aesthetics by setting the color depth to 16 or 15 bits.
Local device redirection.
The user can choose not to redirect drives, printers, and serial ports. This protects local files. It does not affect performance.
The user can select a connection speed and the client will automatically disable options that are not appropriate for the selected speed.
The Terminal Service service (Termservice) is installed on every Windows Server 2003. The service supports both a standard client session and a direct connection to the console. This second option is essentially a remote control feature.
To connect to the console of a server, launch the Remote Desktop Connection executable, Mstsc, from the command line with the /console switch—mstsc /console—then select the server. When you make the connection, one of two things happens:
If your account is currently logged on at the console of the server, your session takes over where the console left off and the console goes to a locked state.
If someone else is logged on at the console and you have administrator privileges, you force the console user to log off and the console goes to a locked state.
The Remote Desktop feature on a server permits two concurrent users. The users share a common set of configuration parameters rather than the discrete settings maintained by true Terminal Services. This feature is intended for administrators to access servers for management purposes, but see section, "Controlling Remote Access Permission," for ways to give access to non-admins.
The Windows Server 2003 CD comes with a Remote Desktop driver for handheld PCs (HPCs). This driver also works with PocketPCs such as the Compaq Ipaq. The ActiveSync product that comes with the handheld will not install this application. Copy the appropriate CAB file to the PocketPC then click on the CAB file and install it. For example, the RPC_SA1100.cab file works with the Ipaq handheld.
The client does not support 128-bit encryption, so be sure to set the terminal server encryption to Client Compatible. For more information, see www.cewindows.net/faqs/terminalserver-citrix.htm.
If your unit has a CDPD (Cellular Digital Packet Data) modem, you'll find that 9600 baud gives a slow but acceptable remote desktop connection.
Past versions of Microsoft's terminal services and RDP gave scant support for device redirection. With NT4 Terminal Server Edition (TSE), you could include a NET USE command in a logon script to map a COM port back to a serial port at the client. This permitted using a modem or barcode scanner at the client. Starting with Windows 2000, printers could be redirected back to the client, as well, but an administrator was required to install printer drivers at the server.
The combination of an RDP 5.1 client and a Windows Server 2003 terminal server provides a suite of new device redirection features:
Printers (with automatic printer redirection for Windows Server 2003, XP, and 2000 clients)
LPT and COM ports (true redirection rather than NET USE)
All of these redirection options are enabled by default when a PC-based client makes an RDP 5.1 connection to a Windows Server 2003 terminal server. This includes downlevel clients such as NT4 and Windows 9x/ME. Here are details about the various redirection options.
This feature permits the user cut-and-paste information between an RDP session and the desktop or between different RDP sessions if you have a multisession thin-client device. This feature is available in Windows 2000 as an add-on package from the Resource Kit, Rdclip, but it is fairly clumsy to install.
The clipboard mapping feature is surprisingly useful. You can use it to grab screen shots, transfer document contents, even work at the command line. One thing to be careful of is inadvertently creating compound documents when you paste. If you build an OLE connection to an inserted object over an RDP connection, the pasted object will only be available inside an RDP session.
To see the behavior of client drive redirection, connect to a Server 2003 terminal server using an RDP 5.1 client. Open My Computer and look at the lower portion of the window under Other. The client drives are listed by their drive letter and the name of the client computer. Figure 19.12 shows an example.
Figure 19.12. My Computer showing redirected client drives in an RDP 5.1 session.
Users can copy freely between server drives and client drives as long as they have appropriate NTFS permissions at the server. RDP is not as efficient as SMB for file transfers, so don't expect much in the way of performance. You can transfer files from the client drives to a network drive inside the client session at the server. The data stream is first sent to the server via RDP then it is handed over to the SMB redirector for delivery across the network. This transition takes time and CPU cycles.
To see the result of printer redirection, open the Printers and Faxes window within an RDP 5.1 client session. Do the same at the terminal server.
If you connect from a Windows 2000 or XP client, the RDP session will show each of the printers at your desktop plus the printers that are locally installed at the terminal server (see Figure 19.13). The Printers and Faxes window at the terminal server shows all printers from all active clients plus the locally install printers.
Figure 19.13. Printers and Faxes window showing printers that have been redirected from client PCs running RDP 5.1 client.
When the client logs off, the printers are removed from the printer list at the terminal server. The printers reappear when the user logs on again. The information for the printer settings comes from cached parameters for that client.
The redirected printers use RDP ports created dynamically at the terminal server that point back to the client PC. You can see the COM port redirections using the CHANGE PORT utility in the client session. Here is an example listing:
AUX = \DosDevices\COM1
COM1 = \Device\RdpDr\;COM1:2\tsclient\COM1
COM2 = \Device\Serial1
Notice that COM2 redirects to the local COM1 (Serial1) interface, which then aggregates the ports (COM1:2) and sends them back to the terminal server via the Terminal Server director, Rdpdr. The parallel ports are redirected in the same way but do not appear in the port listing.
Redirected ports appear at the terminal server with names corresponding to the client session, such as TS004, CLIENT1: LPT1. Ports corresponding to redirected printers use the PRN device name, such as TS011, CLIENT1: PRN1. Figure 19.14 shows an example port list.
Figure 19.14. Port list at a terminal server showing redirected client ports.
The terminal server automatically configures printers for Windows Server 2003, XP, and Windows 2000 clients by obtaining the drivers from the client. The permissions on the printers are set so that only administrators and the user who created the session has access. Users cannot see printers in other client sessions, but they do see printers created manually at the terminal server.
Printers for downlevel clients must be manually created and redirected at the terminal server. This is because the server is unable to obtain the proper driver from the downlevel client. Create the printer using the Add Printer Wizard as you normally would and select one of the client's redirected LPT or COM ports as the target port. The client must have an active session to see the port list.
The printer at the downlevel client must be installed on an LPT or COM port. You cannot redirect a terminal server printer to a USB port because the USB port does not "appear" until it is used, like an elementary particle appearing from nowhere around a black hole.
Print jobs are fully rendered at the terminal server then sent to the client's printer using RDP. This avoids driver conflicts. You'll need a Windows Server 2003/XP or Windows 2000 driver for the printer. This can be a challenge for less expensive printers that only have drivers for consumer desktops such as Windows 9x/ME. Driver availability should improve after XP makes inroads into the consumer market.
Many applications play sounds. Without audio redirection, the sounds would play at the terminal server, which only entertains/annoys the administrators in the server room. With audio redirection, the stream is processed at the client.
There are no codec compatibility issues because the stream is decoded at the server then packaged for delivery over RDP to the client. For example, as I write this, I'm listening to Monty Python's Dead Parrot sketch (www.montypython.net/fullsketches.php) streaming to an IE window in a remote desktop session and from there to my PC over RDP via audio redirection. A user could listen to an audio CD mounted at the terminal server if an administrator were crazy enough to put a disk in the player.
The audio stream uses User Datagram Protocol (UDP) for performance. If the bandwidth changes while the stream is playing, the client and server can automatically negotiate new stream capabilities.
Video playback is fairly poor via RDP. The frame rates are poor and you'll get a lot of dropped frames. Also, audio streams often become degraded on a busy terminal server. Use this feature only when necessary.
You can control the user's ability to redirect audio, video, and the other redirection features using the Properties window of the RDP connection in the Terminal Services Configuration console. The Client Settings tab has the options.
Terminal Server Security
Remote Desktop and terminal services security concerns generally focus in these areas:
What protects the RDP data stream between the client and the server?
How do I create an RDP connection through firewall?
How do I prevent users in a terminal server session from messing with server files?
How do I control who can get remote access to a server or desktop?
Let's start with the last item.
Controlling Remote Access Permission
As many administrators discovered in Windows 2000, the ability to connect to a terminal server depends on the security permissions assigned to the RDP-Tcp connection in the Terminal Services Connection console.
Here are the permissions associated with the RDP-Tcp connection:
Windows Server 2003 has a new Built-In group called Remote Desktop Users. This group is on the RDP-Tcp connection ACL. Under the default Remote Desktop configuration, the group has User Access and Guest Access permissions. This represents only Query, Logon, Message, and Connect permissions. When full terminal services are installed, the Remote Desktop Users group gets Full Control permissions on the RDP-Tcp connection.
Windows Server 2003 has a new User Rights Assignment setting called Allow Logon Through Terminal Services. The Remote Desktop Users group is on the member list of this group. Membership gives users the ability to connect via an RDP session even though they have not been given explicit connection permissions at the console.
There is also a RemoteAssistant account with Full Control access to the RDP-Tcp connection. This account is used to provide access to individuals invited to participate in Remote Assistance at a desktop or server. This account is disabled by default. It is only used to intermediate the connection. If you delete this account at a local machine, you cannot connect to the machine via Remote Assistance, although you are still able to use Remote Desktop if that feature has been enabled.
The Remote Desktop feature has an additional security setting at XP desktops (not servers running Windows Server 2003). The account used to make the connection must have a password. By default, accounts with blank passwords are blocked from making any sort of network connection to an XP desktop.
System Configuration Lockdown
When you install Terminal Services on Windows Server 2003, Enterprise Edition, you'll be prompted to choose between Full Security and Relaxed Security. With the Full Security option, users are blocked from writing to or modifying system files and Registry entries.
This may present a problem for older applications that expect to get access to files in the system folder or to Registry entries that would be protected by the Full Security setting. If you have applications such as this, you may need to install with the Relaxed Security option.
You can shift back and forth between Full Security and Relaxed Security by toggling the setting in the Terminal Services Configuration Manager console. Highlight the Server Settings icon to reveal the settings in the right pane. Figure 19.15 shows an example.
Figure 19.15. Terminal Server Configuration Manager console showing server settings.
The Full Security option in Server Settings is not, I repeat, not, a substitute for a full lockdown of the terminal server. It only protects the operating system files in \Windows, the common files in \Program Files, and critical HKLM Registry entries. You'll need to go through every folder outside those areas to determine how best to protect them from bored, negligent, or malicious users.
You should keep terminal server users off the Internet, if possible, or at least remove all rights to install software to keep them from installing applications from the Internet. Use the following group policies to your advantage:
Set Path for Roaming TS Profiles.
This option prevents roaming users from depositing their personal folders, which may contain executables, onto your terminal server. Specify a common location so that the users get a single profile for use when on the terminal server.
Do Not Allow Drive Redirection.
This option prevents users from copying files from their PC onto the terminal server. You may find that users keep executables in their home directories, so this is not a perfect solution.
This policy applies the user policies in Group Policy Objects (GPOs) linked to Organizational Units (OUs) containing the computer object instead of the user policies in GPOs linked to OUs containing the user object. This prevents user policies from changing the configuration of the terminal server.
Always Prompt Client for Password Upon Connection.
This policy prevents an administrator from inadvertently removing the requirement in the RDP-Tcp configuration to require logon. Without this requirement, users can set their credentials in Remote Desktop Connection. Other users can use this RDP file to gain access.
Allow Reconnection From Original Client Only.
This prevents users from disconnecting from one machine, walking over to another machine, and reconnecting.
Internet Explorer - Security Zones - Use Only Machine Settings.
This prevents users from bypassing security zone settings and downloading ActiveX controls, Javabeans, Shockwave files, and other inappropriate material.
Prohibit Access to the Control Panel.
This keeps users from fussing with system settings.
Prevent Access to the Command Prompt.
This keeps users from bypassing Explorer limitations.
Restrict These Programs From Being Launched From Help.
Don't forget about back doors. The Help and Support Center is a mother lode of shortcuts to inappropriate programs.
Remote Control Settings - View Session Without User's Permission.
This is a controversial policy, I'll grant you, but nothing keeps people honest like knowing that someone might be looking over their shoulder without their knowledge. This one policy, combined with management's willingness to discipline folks who break the rules, is more effective than any lockdown setting.
This list is only the beginning of your adventure in TS user management. I cannot stress strongly enough that active support by management is essential to controlling the common workspace on a terminal server.
Terminal Servers and Firewalls
RDP uses TCP port 3389. Network administrators might refuse to open this port on the firewall. You cannot really blame them. After all, they're the ones who get blamed if a configuration change creates a vulnerability that some bad guy exploits to steal information or do damage.
If only certain ports are available in your firewall, you can configure both the terminal server and the RDP clients to use that port rather than port 3389.
First, change the RDP port in the Registry at the terminal server. Here is the setting:
Key: HKLM | System | CurrentControlSet | Control | Terminal Server | Wds | Rdpwd | Tds
Data: 3389 (REG_DWORD)
Change the PortNumber data entry to a port available at the firewall. Be sure to select decimal, not hex.
Now change the port on this Registry key:
Key: HKLM | System | CurrentControlSet | Control | Terminal Server | WinStations
Data: 3389 (REG_DWORD)
Restart the server to initialize the new port. Verify using netstat -a that the server is listening on the new port.
To connect a remote desktop client to the server using the new port, launch the client using a command-line switch that specifies the port number:
If you use the ActiveX control in the TSWeb interface to connect users to the terminal server through the firewall, configure the web page to redirect the user using a port other than 3389 by following the steps in Procedure 19.4.
Procedure 19.4 Changing Default RDP Port in the TSWeb Interface
Find the Connect.asp file under \Windows\Web\TSWeb.
Edit it with Notepad and look for entries starting with MsTsc.AdvancedSettings2.
Add a line right after these entries as follows:
MsTsc.AdvancedSettings2.RDPPort = 3389
Replace the 3389 with whatever port you've configured your terminal server to listen at.
This procedure does not work for Windows 2000 servers because the ActiveX control used by Windows 2000 does not export the AdvancedSettings2 methods. You can work around this limitation by copying the Tsweb folder from a server running Windows Server 2003 to the server running Windows 2000 and creating a web share for the folder. If a client has already downloaded the Windows 2000 ActiveX control, you need to uninstall the control before the client connects to the updated share.
Data Stream Encryption
The RDP data stream is always encrypted. Windows Server 2003, XP, and Windows 2000 SP2 machines running the RDP 5.1 client use 128-bit encryption. Legacy clients that do not have the high encryption pack installed default to 56-bit in RDP 5.0 and 40-bit in RDP 4.0.
The security level is configurable in the Terminal Services Connection console. Open the Properties window for the RDP-Tcp icon. The General tab has an Encryption Level drop-down box. There are two options:
The 128-bit RC4 encryption stream is highly resistant to attack, but if you want a more secure environment for exchanging initial handshaking information, give Citrix SecureICA a try. It features Diffie-Hellman key exchange and 128-bit RC5 encryption.
Users tend to treat terminal server session connections rather cavalierly. They'll disconnect and reconnect rather than log on and off because of the speed. This is especially true in thin-client environments where the boot time of the client can be measured in tens of seconds.
If you permit disconnected sessions to pile up, you'll eventually run out of memory and other system resources. You can control session timeouts with the Terminal Services Configuration console. Open the Properties window for the RDP-Tcp connection and select the Sessions tab (see Figure 19.16).
Figure 19.16. RDP-Tcp Properties window showing the Sessions tab.
The RDP client can request timeout values for disconnected session termination, active session limits, and idle session limits. These are generally requested as indefinite.
Select the Override User Settings option and set a time limit that allows users to reconnect soon after they disconnect to allow for dial-up failures and power failures but not so long that it encourages disconnects instead of logoffs. I've found 15 minutes to be satisfactory.
Be sure to select the End Session option for the default action when a timeout is reached. This prevents disconnected sessions from piling up.
If a user ends up with more than one session, he is presented with a pick list when he reconnects. You can use the TSCONS command-line utility (see the section later in this chapter) to swap into the other session to exit it gracefully. You can also use the Remote Control feature to break into the session if it is still active.
For security reasons, you may want to enable the Allow Reconnection feature and set the option for From Previous Client. This prevents the users from wandering around the floor reconnecting from various machines. This also potentially uses up licenses unnecessarily.
Terminal server licensing is a complex subject. The Microsoft Knowledgebase lists nearly two-dozen articles relating to TS licensing, and those are only the major articles. For the most current information, I suggest you talk over terms with a Microsoft VAR that has experience with terminal service products. Many Value-Added Resellers (VARs) do not understand the licensing jungle and you'll end up paying too much. Here is a synopsis.
First off, if you do not plan on using true terminal services to share applications in a multiuser environment, stop right here. You get two free licenses of Remote Desktop with each copy of Windows Server 2003. You can put anyone into the Remote Desktop Users group, not just administrators. Note: This is not a true multiuser environment. Configuration changes made by one administrative user will affect other users.
To connect to the terminal server, you'll need a TS Client Access License, or TS CAL. This CAL is essentially the same as a license of Windows XP, in so far as running a terminal service session is the same as running XP. You'll also need a standard CAL, which gives permission to make a network connection to the server.
If you connect to the terminal server from an XP desktop, you still need a TS CAL. This is a change from earlier versions of Terminal Services. You'll also still need the standard CAL. If you plan on installing Citrix MetaFrame, you must still purchase TS and standard CALs from Microsoft in addition to MetaFrame Server and ICA client CALs from Citrix. The total per-seat cost of all these client licenses, without volume discount, can easily total $400 or more. If you have 100 terminal server clients, you'll spend quite a bit of money just to have a few certificates in your file cabinet.
If you plan on using the terminal server only for anonymous, non-commercial Internet connections, you can purchase an Internet Connector license. The price for this license, which permits 200 concurrent connections, has historically hovered around $10,000. This may go up as Microsoft ramps up its pricing model. There is no per-user authentication permitted using this license. Purchasers of this license include large organizations that use terminal services to provide remote desktops to their mobile workforce.
Within 120 days of installing Terminal Services, you must install the Terminal Services Licensing (TSL) service on at least one domain controller. Use the Add/Remove Programs applet in Control Panel. The TLS must be installed on an Active Directory domain controller because the other terminal servers use LDAP to find it. For standalone installations, install the service on the terminal server.
The license database is a standard Microsoft Jet database. The database location is selected during the licensing service installation. By default, it is \Windows\System32\LServer. The database name is TLSLic.edb.
Terminal servers discover the existence of TSLs by querying Active Directory. After a terminal server finds a TSL, it will use it exclusively to get licenses. The TSLs do not share or pool licenses. Stock a TSL in a high volume office with more licenses than a low volume office.
When you install a TSL, the installation wizard prompts you to decide between a Domain/Workgroup model and an Enterprise model.
If you select the Enterprise model, the TSL will pass out licenses to any client from any domain in a particular site. If you select the Domain/Workgroup model, the TSL will pass out licenses to any client in the domain regardless of the client's site affiliation.
If you have a multiple-domain forest, you'll be best served with the Enterprise model. However, this can make license distribution at remote sites a chore. Terminal servers will not search for a TSL in another site. Be sure you have at least one TSL in any site containing a terminal server.
The TSL must be activated either by connecting directly to the Microsoft Clearinghouse across the Internet or calling Customer Support for an initialization number. This activation does not contain any client licenses. It simply supplies a digital certificate to the TSL that uniquely identifies it to Microsoft. The TSL activation is not related to the Windows Product Activation (WPA) process other than it uses a similar methodology.
If you install MetaFrame, you'll also need to install a license server for the ICA client licenses. These licenses are a bit more flexible than TS CALs.
After the TSL is initialized, you must stock it with TS CALs. Obtain these from Microsoft or an authorized VAR. The CALs come in the form of a certificate with a 25-character number. You enter this number into the Licensing Manager console and it communicates to Microsoft across the Internet. After validating the CALs, the Microsoft server returns an authorization code, which is embedded into the TSL. License packs are available in a variety of programs, also called agreements. If you open the Properties window for the license server and select the Licensing Program tab, you can choose the agreement (see Figure 19.17).
Figure 19.17. Terminal Services License Manager console showing Properties window for licensing server with the Licensing Program tab selected.
You cannot change the name of the TSL or its domain affiliation or remove the license service from it. If you do, you sacrifice the licenses that are stored on the server. You can transfer the licenses to another TSL then change the server's status, if necessary.
TS CAL Tokens
When a client connects to a terminal server, the license server issues a TS CAL token. This token is cached at the client. All TS CALs are issued on a per-seat basis. The token permits a licensed client to connect to any terminal server in the forest.
The per-seat nature of a TS CAL can come as a surprise if you aren't ready for it. For instance, if a TS user travels to branch offices in 20 cities and connects from a desktop in each city, you've just expended 20 TS CALs.
Per-seat TS CALs caused some problems in Windows 2000 that was fixed in Service Pack 3. The problems centered around devices that obtained a TS CAL token from a license server then never actually connected to a terminal server. The fix consisted of a two-stage licensing transaction.
The first stage consists of a temporary TS CAL token that expires in a random interval between 52 and 119 days. If a user actually logs on to a terminal server within that period, the token is changed to a permanent TS CAL token.
If a user does not log on to a terminal server from the device, the desktop client continues to get temporary tokens while the old tokens expire and are returned to the token pool. This prevent losing licenses to inappropriate devices.
If no one ever connects to a terminal server from those desktops again, you might think you've given away a lot of money, but the license agreement permits you to do a one-time transfer of the TS CAL to another device. You can also transfer the license if a device fails. This requires a phone call to a human being at the Terminal Services Licensing Clearinghouse operated by Microsoft. The process takes a few minutes.
The client PC stores its TS CAL token in the Registry under HKLM | Software | Microsoft | MSLicensing | Store | License000 (or License001).
If there is more than one license listed, the TS CAL license has a Product ID of 41 00 30 00 32 00 00 00.
An NT client might exhibit the problem of getting multiple TS CALs, one for each user who logs on to a terminal server from the desktop. This is because the user does not have sufficient rights to the MSLicensing Registry key. You can use Regedt32 to give the Authorized Users group Full Control permissions to the key.
You can remove the token from the client by deleting the entire License### key. Be sure to reclaim the token at the license server by calling Clearinghouse Customer Support.
If the TSL runs out of licenses, it issues 90-day temporary tokens to clients that do not already have a token. If you stock up the TSL with TS CALs within the 90-day interval, the clients will trade in their temporary token for a permanent one.
As I said at the beginning of this section, you do not need to purchase a TS CAL to connect to a terminal server from an XP desktop. However, the TLS tracks these connections in a special built-in pool. The pool is unlimited and exists solely for administrative evaluation.
Automatic licensing can get a little tricky as you make the transition from Windows 2000 clients and servers to Windows Server 2003 and XP clients. Downlevel clients continue to use their TS CAL tokens, but modern clients will need specific TS CALs. By default, a TSL will issue an XP TS CAL to a Windows 2000 client if all the Windows 2000 TS CALs have been exhausted. This simplifies restocking your TSL.
You can block the automatic license upgrade if you want to maintain separate stores to avoid stocking upgrade licenses. The group policy is called Prevent License Upgrade and is located under Computer Configuration | Administrative Templates | Windows Components | Terminal Services | Licensing.
If you have a TS CAL token for a Windows 9x client then upgrade the client to Windows XP, you can reclaim the license for use by another downlevel client. This requires a call to Clearinghouse Customer Service.
If you are running TSL services on an evaluation version of Windows Server 2003, be sure to never install actual licenses on the server. You'll lose the licenses when the evaluation expires. Theoretically, you'll be able to get the licenses back by calling Clearinghouse Customer Service, but it's a hassle you don't need.
You can use the Terminal Services Manager console to remotely control, or shadow, a user session. This enables you or your Help Desk staff to troubleshoot or to demonstrate a feature to a user.
If you need to call Clearinghouse Customer Service, you can get its phone number for your area from the Licensing Manager console as follows:
Open the Properties window for the server.
Select the Connection Method tab.
Select your country and click OK.
Right-click the server icon and select INSTALL LICENSES from the flyout menu. The Licensing Wizard starts.
Click Next. The Obtain Client License Key Pack window opens. This window contains the telephone number and the 35-character TSL activation license.
Unlike ICA in Citrix MetaFrame, RDP does not permit shadowing a user directly at the console of the terminal server. You must connect to the terminal server using RDP then open the Terminal Services Manager console from within the session. Shadowing in RDP uses a T.120 feature that supports multicasting to selected devices.
Figure 19.18 shows the Terminal Services console with a list of users who have active sessions. To shadow a user, right-click the user's icon and select Remote Control from the flyout menu.
Figure 19.18. Terminal Services Manager console showing list of users.
By default, the user's permission is required before you can shadow a session. After the user grants permission, your current session is disconnected and you get a copy of the user's session. You can interact with the session to show the user a step or fix a problem.
When you're done shadowing, press Ctrl+* from the numeric keypad to break out of the session and return to your own session.
You can also use the SHADOW command to break into a user session. See the "Managing Terminal Services from the Command Line" section for details.
If you want to shadow without asking permission, configure the RDP-Tcp connection in the Terminal Services Configuration console, proceed as shown in Procedure 19.5.
Procedure 19.5 Permitting Unvalidated Shadowing
Open the Properties window for the RDP-Tcp connection and select the Remote Control tab (see Figure 19.19).
Figure 19.19. RDP-Tcp connection Properties window showing Remote Control tab.
Select the Use Remote Control With The Following Settings option and uncheck Require User's Permission.
Under Level Of Control, select whether you want to simply View The Session or you want to Interact With The Session.
Managing Terminal Services from the Command Line
There is a suite of command-line tools for use with terminal services. They run the gamut in functionality. Here is a quick list of the most commonly used utilities:
The CHANGE utility has three options that call separate executables to perform the functions:
CHANGE USER (CHGUSER)
CHANGE LOGON (CHGLOGON)
CHANGE PORT (CHGPORT)
The CHANGE USER option permits you to change the multiuser mode of the system. There are three switches for this option:
This mode maintains discrete application configuration files for each user. It is the default mode. For standard Remote Desktop servers, this mode has no effect.
This mode permits you to install an application so that it can be run in multiuser mode. If you neglect to set this option during installation, the system treats the application as a single user application and does not store per-user configuration information.
Determines the current mode.
In previous versions of Windows and MetaFrame, you had to remember to shift to INSTALL mode when you installed applications. If you used the Add Programs option in Control Panel, the system automatically shifted to Install mode, but you had to remember to say No to automatic installations from an Autostart menu. Many administrators have found, to their dismay, that they forgot this step and were required to deinstall then reinstall their application in the correct mode.
A server running Windows Server 2003 automatically shifts to Install mode when you install an application. An After Installation window opens to guide you through shifting back to Execute mode when you've completed the installation.
This option is used to control RDP access to the terminal server. Use it to disable new session creation when you want to install an application or you are troubleshooting. The syntax is change logon /disable to stop new session creation and change logon /enable when you're ready once again for users.
This option allows you to redirect a logical COM port outside the range understood by legacy applications to a lower port number. The syntax is change port portx=porty.
This option consists of two elements, both of which are separate executables:
QUERY PROCESS (QAPPSRV.EXE).
This option lists the processes running on a terminal server by user. It includes the session name, session ID, program name, and process ID (PID). This is helpful when troubleshooting a process for a user.
QUERY SESSION (QPROCESS.EXE).
This option lists each session in a terminal server along with the associated user and device and the session status. The /counter switch tallies the active, disconnected, and reconnected sessions.
QUERY TERMSERVER (QWINSTA.EXE).
This option lists the known terminal servers in a domain. It obtains this information by querying Active Directory or by broadcasting.
QUERY USER (QUSER.EXE).
This option lists the users who have sessions at a terminal server along with the session ID, the session name, the idle time, and the logon time.
QUERY WINSTA (QWINSTA.EXE).
This option gives the same information as QUERY SESSION.
This command logs the user out of a session and reclaims the process. Don't use it unless you're sure the user has saved all data because it does not exit gracefully.
This utility allows you to connect to an active or disconnected terminal server session. TSCON is an invaluable tool for recovering users' sessions when they have been disconnected and cannot reconnect, or when they reconnect and get a new session. Without this tool, the old session becomes an orphan that is eventually removed when the disconnected session timeout is reached. Using TSCON, you can swap into the session and close it down gracefully, saving the user's data in any running programs at the same time.
You must issue this command within a session. It will not work from the console. You'll need to know the ID or name of the session to which you want to connect. Determine this information using the QUERY SESSION command. After you know the session information, the syntax to connect to that session is tscon <session_id>.
When you issue this command, it disconnects you from your current session and disconnects the user from the session (you both can connect up later) then connects you to the user's session, which is still running in the user's security context. You must have administrator privileges on the terminal server.
This utility is related to TSCON. You can use it to initiate a remote control session with a terminal server client. Instead of swapping out a session like TSCON, the SHADOW utility creates a second instance of the session that includes both you and the user. This is the same as selecting the Remote Control feature for a user session in the TS Management console.
Like TSCON, you can only use this utility from inside a session on the same terminal server. Run QUERY SESSION to determine the user's Session ID then take remote control of the session using the following syntax: shadow <id>.
When you issue this command, you are disconnected from your session and the user is prompted to give you permission to take remote control of the user's session. You can then use this shadowed session for troubleshooting. The command line takes the place of taking remote control of a session from the Terminal Services console.
As soon as you exit out of the client's session (using Ctrl+* from the numeric keypad), you are reconnected to your session.
To get the most benefit out of terminal services, especially when it comes to reducing that all-important Total Cost of Ownership, you should consider deploying thin-client devices. These are simple, CE-based units that link up to a terminal server via RDP or ICA. Most units come with a local serial and printer port along with a USB. Some legacy-free units have strictly USB connections. Be sure you get the most current models that support RDP 5.1.
The advantage to a thin client is flexibility and simplicity. Don't look for ultra-low prices. Quality units range in price from $400-$600 depending on speed, video, and extra features such as a web browser, local CD, or even a local hard drive. A few not-so-thin clients are essentially XP-based desktops in a tight enclosure. Some even run embedded NT4.
Thin-client vendors typically build lots of margin into their retail prices, much more than for PCs, so bargain hard, especially if you are purchasing quite a few units. Also, not all devices are created equal even though their specs might look the same. Insist on fast video with lots of memory, 100MB Ethernet, and enough system memory to support multiple concurrent sessions.
For a great web site that has an up-to-date list of thin-client solutions, visit www.thinplanet.com. You can get product guides, pricing, and feature comparisons.
XP desktops run the same Terminal Service service, Termservice, that Windows Server 2003 runs. However, a desktop cannot host virtual sessions, only a single console session.
For reasons of security, an administrator or average user cannot simply connect to the console of an XP desktop. The user must "invite" another user to connect to the console, either for troubleshooting or demonstration purposes. This Remote Assistance feature resembles many "over-the-shoulder" products that permit a Help Desk administrator to work at a user's desktop remotely.
Windows Server 2003 also has the Remote Assistance feature, but it's not likely that you'll use it much with the standard 2-node connection feature available.
XP desktops also permit multiple-user sessions at the physical console. This feature is called Fast User Switching. This feature is only enabled on standalone desktops. It requires a special logon window (called a GINA, for Graphical Identification and Authentication). It is possible to produce a custom GINA, but as of this writing, only Microsoft has a GINA that supports Fast User Switching. If you install the NetWare Client or a remote control program such as PC Anywhere that replaces the GINA, you will lose Fast User Switching capabilities.
Enabling Remote Assistance
The Remote Assistance feature is enabled by default on XP desktops. The setting is in the new interface Control Panel under Network and Internet Connections. Click the Remote Desktop link in the left pane.
You can also enable Remote Desktop connection to an XP desktop. With this feature enabled, an administrator can connect to a desktop without being invited. In this situation, though, the administrator takes over the console session and the console is locked. Console sharing is only enabled via Remote Assistance.
Remote Assistance is initiated via an "invitation" from the user. This invitation takes the form of a digitally signed file delivered in one of three ways:
Remote Assistance via Messenger
As you might expect, this feature only works with Microsoft Instant Messenger, not with IM clients from Yahoo or AOL. The invitation recipient must be running Windows XP or Windows Server 2003 to get the most current version of Instant Messenger, the RDP client, and the Remote Assistance application.
Right-click an entry in your "buddy" list and select ASK FOR REMOTE ASSISTANCE from the flyout menu. This sends an invitation to the recipient. The recipient accepts the invitation and creates an RDP session.
Before the RDP session can make the final connection to the user's desktop, the user must click Yes when asked, "Do you want to let this person view your screen and chat with you?"
With the amenities out of the way, the person receiving the invitation gets a Remote Assistance window that shows a view-only rendition of the user's desktop. They can chat with each other in text or by voice (see Figure 19.20).
Figure 19.20. Remote Assistance window.
The invitee can click TAKE CONTROL from the top menu to share control of the console session with the user.
This session requires TCP port 3389 open through any intervening firewalls. For the most part, you would not want users to expose their desktops to the outside world, so you can leave this for internal use only by not opening up port 3389.
Remote Assistance via Email or File
You can send an invitation via email. The invitation takes the form of a MsRcIncident file that is delivered as an email attachment. You also have the option of saving the file and delivering it another way if the email option is not available.
Both of these options are only available in the Help and Support Center. Click Invite a Friend to Connect to Your Computer. This opens a little wizard that walks you through sending the invitation via email or saving it to a file. Figure 19.21 shows what this interface looks like.
Figure 19.21. Help and Support Center interface to Remote Assistance options.
The MsRcIncident file is an XML file that contains the following elements:
<?xml version="1.0" encoding="Unicode" ?>
PassStub="UP!9Udt*cemT4h" L="1" />
The sensitive portion of the contents are encrypted and digitally signed. The recipient can be required to know a password to use the file. The sender must communicate the password to the sender in some fashion.
The MsRcIncident extension is associated with the Help and Support Center. You can double-click the file to view the rendered contents. Figure 19.22 shows an example.
Figure 19.22. Remote Assistance file message displayed by Help and Support Center.
Disabling Remote Desktop
If you want to protect a server by disabling Remote Desktop access, follow Procedure 19.6.
Procedure 19.6 Disabling Remote Desktop on Windows Server 2003
Right-click the My Computers icon and select PROPERTIES from the flyout menu.
Select the Remote tab (see Figure 19.23).
Figure 19.23. System Properties showing the Remote tab.
Under Remote Desktop, uncheck the Allow Users To Connect Remotely To Your Computer option.
Click OK to save the change.