A Guide to Deploying Terminal Services
James D. Silliman
At a Glance:
- Deploy Terminal Services in a few easy steps
- Optimize Office in your TS environment
- Manage your users efficiently using TS
Flash back to 1998: Microsoft releases Windows NT 4.0 Terminal Server Edition, code-named "Hydra." Microsoft licensed technology from Citrix Systems, creating its first thin-client/
server offering. For system administrators, "Hydra" was a difficult deployment. Fast-forward a few years and Terminal Services has changed dramatically. It's fully integrated into the kernel and sets up easily with a built-in installation wizard, requiring no separate CD or Internet download. Given the relative ease of installation, there are many reasons why deploying Terminal Services in your organization makes sense. The most immediate advantage is having all your applications run on a central server or servers, so that client architecture and hardware is not an issue. All the end user needs is a Remote Desktop Protocol (RDP) client to connect to the central servers. Fortunately, RDP clients are available for most current architectures.
In this article, I show you how to enable Terminal Services on an existing Windows Server® 2003 installation, how to apply Terminal Services Group Policies, and how to use the Custom Installation Wizard to automate Microsoft® Outlook® profile settings. When we're finished, you will have a fully deployed Terminal Server to serve up applications to your users.
The first step you'll need to take to set up Terminal Services is to open the built-in Configure Your Server Wizard that is located in Windows Server 2003 Administrative Tools. Select Terminal Server and then click Next until the wizard completes. The installation program warns you that it will have to automatically reboot the machine to initialize the changes. After the reboot, the server will be in Terminal Server mode.
Make sure, by the way, that you've got your Terminal Services Client Access Licenses (CALs) in hand before you start or no one will be able to connect after your successful deployment. Now join the box running Terminal Services to your Active Directory® domain and log in with an account that has Domain Admin privileges. If you're not on a domain, it will be difficult to proceed because you won't be able to enforce Group Policies. For this article, the server where you're installing Terminal Services is called TS01.
Next, launch Active Directory Users and Computers from the Admin Tools and create a new Organizational Unit (OU) where you'll place the Terminal Server. For simplicity's sake, let's give the OU the highly original name Terminal Servers. Locate your Terminal Server, TS01, and move it into your new Terminal Servers OU.
Next, download and install the Group Policy Management Console (GPMC) from microsoft.com/windowsserver2003/gpmc. This management utility allows you to set up a new Group Policy, assign permissions to it, and then edit the policy so you can turn applicable policy settings on or off for any of the users who will be connecting. GPMC is an essential tool for Terminal Services deployment because it has a built-in Modeling wizard that immediately reflects which policies have been applied to a user and which have not.
Launch the GPMC console from Administrative Tools, and locate your new Terminal Servers OU on the left side of the Group Policy Management window. Right-click the OU, choose Create and Link a GPO Here as shown in Figure 1, and give it a utilitarian name like Terminal Server Policy #1.
Figure 1** Creating and linking a new GPO **(Click the image for a larger view)
You'll notice that an Authenticated Users group magically appears in the Security Filtering box on the right side of the GPMC window. This group is added by default to all Group Policy Objects (GPOs). Click on the group and then click the Remove button. You want to set up a Terminal Services group instead in your Active Directory tree to which to apply your GPOs when users log on to TS01. Let's call our Terminal Services group BottleWashers. Go ahead and add them into your Active Directory structure using Active Directory Users and Computers from Administrative Tools. You'll also need to add BottleWashers to the Remote Desktop Users group on TS01 and on any other Terminal Servers that you install.
Make sure you are on the Scope tab now. Click on the Add button in the Security Filtering box and then add BottleWashers as a group. The BottleWashers will automatically get the Read and Apply Group Policy rights to Terminal Server Policy #1. These two permissions are the default Group Policy rights and they're necessary for any policies to apply to an object.
Next, add your server, TS01, into the Security Filtering box as well. For this operation, there is an additional step. First click Add and then under Object Types, make sure you place a checkmark in the Computers tab; otherwise the GPMC will not be able to locate TS01 in Active Directory. The final result should look like Figure 2.
Figure 2** Adding TS01 under Security Filtering **(Click the image for a larger view)
Likewise, the correct policy rights will automatically be applied to TS01 by adding it into the Security Filtering box. It's a good idea at this point to click on the Delegation tab at the top of the right-hand GPMC screen, and then find Domain Admins, which is also listed by default on any new policies. Click the Advanced button in the bottom right-hand corner of the screen.
You will now be viewing the Security Settings for the Group Policy object. Be sure to place your focus on Domain Admins and then find the Apply Group Policy setting on the bottom. On the right-hand side, check the Deny option. When you click OK, you'll receive the standard warning message that's issued any time you set a Deny permission. This step prevents your new TS policy from being applied to Domain Admins—a result that would be less than desirable.
Remember that I advised you to have your Microsoft CALs in order? You will need to review the licensing paperwork and determine which Terminal Services CALs you purchased. There are two flavors of CALs for Terminal Server: User and Device. You can obtain more information on licensing at microsoft.com/windowsserver2003/howtobuy/licensing/ts2003.mspx.
Basically, per-user licensing enables one user to consume only one Terminal Server license, regardless of the number of devices (PCs) from which the user connects.
If you do not have a Terminal Server license server already in your domain, locate a member server that can take on the role. Though it's supported, it's best not to make TS01 the licensing server because if you add more Terminal Servers to your organization at a later time, you would not be building much fault-tolerance into your infrastructure. Go into Control Panel on your proposed licensing server. Open Add/Remove Programs | Window Components | Terminal Server Licensing, and follow the prompts to enable the licensing server. After this completes, click on Start | Run and enter:
This brings up the Terminal Server Configuration\Server Settings tree. It's here that you click on Server Settings | Licensing and choose Per User or Per Device. The default is Per Device. If you already have a Terminal Server licensing server in your domain, there is a setting within Terminal Server Policy #1 that indicates the server that's holding the License Server role. After you complete this task, go to Start | Run again and type:
Now you need to activate your CALs so users can connect. Conveniently, you can do this either by phone or Web. Users should then be able to connect to your Terminal Server but there will be no enforced policies, so let's start setting a few important ones. Some that Microsoft recommends are located in the Knowledge Base article "How to lock down a Windows Server 2003 or Windows 2000 Terminal Server session".
The main thing to keep in mind is not to start enabling policies right and left without knowing exactly what each policy does, or you may get some unintended results down the line. A better approach is to start with a few essential policies and test them extensively in a lab environment.
The first policy you may want to enforce is the Loopback Policy. To enable it, launch GPMC, locate the Terminal Server Policy #1, right-click on it and then select Edit. Go to Computer Configuration | Admin Templates | System | Group Policy and enable the User Group Policy loopback processing mode setting. After enabling this policy, you set its Mode value, which can be either Replace or Merge. For the best results in Terminal Services, select Replace.
Another Terminal Server setting you should enable is Add the Administrators security group to roaming user profiles, located in Computer Configuration\Administrative Templates\System\User Profiles. This setting ensures that you, as an administrator, always have full control over user profile folders. It needs to be set sooner rather than later, as it will not apply if the folders have already been created after the user logs in for the first time (see Figure 3).
Figure 3** Enabling the Add Administrators security group value **(Click the image for a larger view)
You will find a whole range of policies in Computer Configuration\Administrative Templates\Windows Components\Terminal Services. Consider enabling these:
- Restrict Terminal Services users to a single remote session
- Set path for TS Roaming Profiles
- TS User Home Directory
Note, however, that restricting Terminal Services users to a single remote session will not prevent users from logging in more than once, as you would think it would. Instead, when a user attempts to launch a second Terminal Services session, he simply takes over the first logged-on session.
Roaming profiles are an essential element of proper Terminal Server operation. By default, when a user logs on to a Terminal Server, a local profile is created on the Terminal Server C: drive, even if you've hidden the C: drive from users. The default behavior for a roaming profile is to synchronize the local profile to a roaming profile share on the network when the user logs off. A Group Policy can be set to purge this local profile when the user logs off.
The next two Terminal Services policies mentioned above, Set path for TS Roaming Profiles and TS User Home Directory, are related to roaming profiles. These settings are often hardcoded in an Active Directory user's Terminal Services Profile Path box. It's much easier and preferable to set the Terminal Services paths via Group Policies. In the case of Active Directory Users and Computers' Terminal Services Profile paths, if you set up a new user or copy an existing user, the TS Server Profile Path information has to be added manually every time—a major pain. It's much better to set these paths to a network share and use a GPO to configure them for you.
Now let's take a quick look at another very important Terminal Services component, Folder Redirection, which optimizes the TS experience by preventing excessively long logons and logoffs. The folders you can redirect are Application Data, Desktop, My Documents, and Start Menu. These four folders have to exist on a network share and they require specific access control lists (ACLs). Have a look at Knowledge Base article "How to Dynamically Create Security-Enhanced Redirected Folders by Using Folder Redirection in Windows 2000 and in Windows Server 2003" for further information on this topic.
The advantage of Folder Redirection is that the whole user profile does not have to be copied every time a user logs on or off. Terminal Services recognizes that these folders reside on the network and basically just provides a pointer to them.
It is advisable with roaming profiles and Folder Redirection to explore the Distributed File System (DFS) to simplify maintenance of your network shares. Due to space constraints, I won't go into DFS in this article, but you can explore it further at the DFS Resource Center.
You'll find the Folder Redirection settings in User Configuration\Windows Settings\Folder Redirection (see Figure 4). The Folder Redirection folder values are very straightforward. You may want to remove the checkmark in each Folder Redirection setting that reads Grant the user Exclusive Rights, otherwise administrators will not be able to access the folders.
Figure 4** Folder Redirection settings location **(Click the image for a larger view)
Install Microsoft Office
Now that you have some essential polices in place, let's get ready to install Microsoft Office 2003 or the 2007 Microsoft Office system. Microsoft Office is optimized for Terminal Services, so there isn't much that needs to be changed during the installation. High-bandwidth items within the Office suite are turned off by default. At this point, you will need to download and install the Group Policy Administrative Template Files (ADM files) so you can control policies within the Office suite.
The ADM files you need are located at microsoft.com/office/orkarchive/2003ddl.htm. For our purposes, you only need to download two files: Office Template Files (ORKSP2AT.exe) from , and the Custom Installation Wizard. However, the second file is only necessary if you are going to deploy Office 2003. The 2007 Office System does not use the wizard; all you have to do is simply click on Start | Run, and type Setup /a and it launches automatically.
After you unpack the first file, ORKSP2AT.exe, you'll see a number of files. The office11.adm and outlk11.adm files are the ones you'll focus on (see Figure 5).
Figure 5** Office Template files **(Click the image for a larger view)
Launch Windows Explorer and copy these two files to %systemroot%\inf. Go back and launch the GPMC console again. Locate Terminal Server Profile #1 under Group Policy Objects, right-click on it and then select Edit. Now go to Computer Configuration\Administrative Templates within the defined policy. Right-click on Administrative Templates and select Add/Remove Templates, as in Figure 6.
Figure 6** Adding Administrative Templates into the GPO **(Click the image for a larger view)
You'll see that the two files are available to you now. Add them one at a time. These template files appear in User Configuration\Administrative Templates\Microsoft Office 2003 and in User Configuration\Administrative Templates\Microsoft Office Outlook 2003. You can browse these template settings and enable or disable them as you wish.
I won't go into many settings here, but two that you may want to remove are the Office Assistant and Outlook AutoArchive. Note that some settings, such as Exchange Cache Mode and Junk Mail filtering are disabled by default in Terminal Services, so it is not necessary to disable these policies.
You will find more information in "Outlook Features That Are Disabled with Terminal Services". The Office Assistant can be easily disabled by selecting User Configuration\Administrative Templates\Microsoft Office 2003\Assistant\Options in Group Policy.
In a Terminal Services environment, you don't want to continually prompt your users to take some action. One particularly intrusive example of prompting involves Mail AutoArchive settings for Outlook. If this setting is ignored within your Group Policy, your users are prompted to AutoArchive at specific intervals. Disabling this setting takes it entirely off their Outlook Preferences menu. Of course, you may want to AutoArchive, so you can fine-tune the settings in the policy User Configuration\Administrative Templates\Microsoft Office Outlook 2003\Tools | Options\Autoarchive.
The next step to take to ensure a successful Terminal Services deployment is to set up an Outlook PRF file so users will not be prompted to configure their Outlook settings manually. This may seem like a Herculean task, but it's not. It requires installing the OrkTools and using the Custom Installation Wizard to create a PRF file that tells the Outlook setup wizard how to behave. The 2007 Office System has a mechanism that makes the process obsolete, though you can still use a PRF file with Office if you want.
Let's set up an Outlook PRF file with the CIW. You won't actually run through the entire CIW routine, only the part necessary to export the modified PRF file. There are only a few steps.
First, launch and unpack the second file you downloaded earlier, (the Custom Installation wizard). After you launch the wizard from Start | Programs | Microsoft Office 2003 Resource Kit, you'll be asked for the location of the Office 2003 MSI file. Insert your Office 2003 disk and indicate the name and path to the MSI file.
Now jump ahead in the CIW, directly to page 17 of 24, so you can skip the rest of the CIW and simply create the PRF file. At Step 17, select New Profile and give it a name such as Outlook, then click Next. You are presented with a screen that allows you to select an Exchange Server (as in Figure 7). Type in the name of your Exchange Server and click Next to proceed.
Figure 7** Configuring an Exchange Server connection **(Click the image for a larger view)
It's a good idea to add the Outlook Address Book to the profile you are creating. Doing so lets users select their Contacts when they are composing a new message. This step alone could save you lots of manual work down the road. You can also configure additional customized features here if you select the Add button. Now click Next and all that's left to do is to export the PRF file.
At this point, you'll need to create a batch file and place it in your Netlogon share on your domain controller, not on TS01. The batch file will launch any mappings you need and set up the PRF file for deployment. I've made the task easy by writing the WMI scripts for you. However, please only use these scripts as a guide; you need to insert the information relevant to your situation. If you prefer, you can use another script processor, like KiXTart.
Your batch file (logon.bat) should include these lines:
REM Logon.bat @echo off wscript %0\..\clean.vbs wscript %0\..\outlook.vbs
The Clean.vbs file will remove the First-Run registry key so that Outlook will process the PRF file:
' Clean.vbs Const HKEY_CURRENT_USER = &H80000001 sComputer = "." Set oRegistry=GetObject("winmgmts:\\" & _ sComputer & "\root\default:StdRegProv") sKeyPath = "Software\Microsoft\Office\11.0\ Outlook\Setup" sValueName = "First-Run" oRegistry.DeleteValue HKEY_CURRENT_USER, sKeyPath, _ sValueName
Outlook.vbs will add the proper Outlook setup key to the registry for each Terminal Server user. You need to provide your own path in the SValue= setting and don't forget to add your actual customized PRF file into the real network directory:
sValue = \\Serv01\PRF\Outlook.prf
Change this path and place your Outlook.prf file in it:
' Outlook.vbs Const HKEY_CURRENT_USER = &H80000001 sComputer = "." Set oRegistry=GetObject("winmgmts:\\" & _ sComputer & "\root\default:StdRegProv") sKeyPath = "Software\Microsoft\Office\11.0\Outlook\ Setup" oRegistry.CreateKey HKEY_CURRENT_USER, sKeyPath sValue = "\\Serv01\PRF\Outlook.prf" sValueName = "ImportPRF" oRegistry.SetStringValue HKEY_CURRENT_USER, _ sKeyPath, sValueName, sValue
The next item on your deployment agenda is to install Office 2003 or the 2007 Microsoft Office system on TS01. As I've mentioned, Microsoft Office is optimized for a Terminal Services environment. There is no longer any need to create custom Transforms. You can turn off Office features beyond the ones that are preselected, but it's not mandatory. Conversely, you can also turn on features but doing so may have adverse bandwidth repercussions. Remember to test any features you enable in a lab environment before deploying them in a production situation.
Before you install either version of Microsoft Office, you will want to place TS01 in the proper user mode. There are two possibilities to choose from: Install and Execute. You should be in Install mode before performing any software installations. To place TS01 into Install mode, type this at the command prompt:
C:>change user /install
After the installation completes, put TS01 back into Execute mode by typing:
C:>change user /execute
Install mode is automatically launched if you run a Setup.exe or Install.exe file on TS01. All Microsoft products have these launch files. However, some apps don't use either, so go with the Change command to be safe. What if you forget what mode you're in? Just execute the command below, which will tell you:
C:>change user /query
If you've made it this far, things are good. You can now go to a Windows client workstation, click on Start | Run, and then type this command:
If you're using Windows 2000, you can download the Microsoft Terminal Services Client (Mstsc) utility.
A Remote Desktop Connection screen should now appear. Simply type in the Terminal Server name or IP address to connect. There are many available selections under the Options button, such as whether to connect local drives or printers, or change the video resolution. You can also hardcode TS01 into the Options area and then save the RDP profile to your desktop. By default, the RDP profile is called Default.RDP.
If you want to perform some administrative tasks on TS01, your best bet is to use this command because it simulates actions just as if you were physically sitting at the console:
If you're administering a number of different Terminal Servers, you may want to use the Remote Desktops utility located in Administrative Tools because you can add all your remote Terminal Servers into a single Tree format.
One last command you should know about is Tsadmin, which lets you view which users are connected to your Terminal Server and which Windows processes users have open. It also allows you to shadow your users, a huge benefit to administrators. Note, though, that if you launch TSadmin from your workstation, you won't be able to shadow users. You will only be able to see the connections. You have to be logged in directly to the TS01 in order to shadow users, send them a message, or log them off.
You should now have a solid understanding of Terminal Services, so deploying a Terminal Server on your own will be a snap. There are lots of topics for further exploration, including Group Policy settings and DFS, but if you remember the basics, like not going overboard when you set your GPOs, and testing them extensively before unleashing them on your users, you'll have made a very good start.
James D. Silliman, MCSE, a Senior Systems Engineer at DirectApps, Inc., specializes in terminal server deployments. DirectApps architects .NET solutions and provides hosting and ASP services. You can reach him at James@directapps.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.