In this Chapter
BEST PRACTICES
Long ago the world of computing was a centralized world. Giant mainframes and “dumb terminals” were the norm. Then came the personal computer. The PC revolutionized traditional thinking and put the power into the hands of the end users; decentralization was all the rage throughout the computing world.
Now things are coming full circle. Supporting thousands of individual desktops is a very tedious, complicated, and expensive task. With new versions of software being released constantly, operating system patches, virus definitions, end users who like to “experiment” with their PC, buggy code causing system crashes, and so on, now smaller IT staffs have an almost impossible task of keeping up. One method of combating these problems is to flash back to the past and move again toward centralized computing. You can now take back the power and manage a dozen servers instead of a thousand desktops. Using Microsoft Terminal Services is one way of doing this. In theory you could never have to manage applications on the end user’s desktop again. By centralizing the applications and running them via Terminal Services you could significantly reduce the amount of time and money spent on maintaining end user desktops.
Using Terminal Services can also reduce hardware costs for an organization. Any computer capable of running Windows 95 or later is a candidate for being a client machine. Because all the computing is being done server side and the client device need only display a bitmap of what is occurring on the server the client-side hardware requirements are minimal. Alternatively a PC is not even needed. There are many manufacturers like Wyse, Neoware, and others that manufacture what are called Windows-based terminals. These devices have an extremely small footprint and are designed specifically for use in the server-based computing world. With Terminal Server there is now no need to upgrade client hardware to support newer applications. You no longer have to maintain or repair applications on individual desktops or fix individual client operating system problems. If a client manages to corrupt his client OS, you can simply re-image or reload the box with the base operating system and Terminal Services client and the user is back in business in minutes.
You might think that Microsoft Terminal Services is only good for providing a convenient way for the system administrator to do some remote administration their server. Although it is a great built-in tool for administering servers remotely, Terminal Services running in Application mode can accomplish a good many more things than just remote administration. Some of the ways organizations leverage Terminal Services include the following:
Simplifies Help Desk duties. Using the Terminal Services administrator snap-in, help desk employees can be given the ability to shadow terminal sessions. With this ability there is now no longer a need to go visit the end user or buy or configure some sort of helpdesk or remote control application to assist in troubleshooting an application or answer a “how do I” question. The help desk employee instead clicks on a session, chooses Remote Control, and can see everything the end user sees in real time and can interact with that user’s desktop.
Reduces software installation and upgrade time dramatically. Instead of upgrading 1,000 desktops with new software, you would just upgrade a dozen terminal servers instead. Maintaining a dozen servers is going to be a lot easier and more cost effective than maintaining 1,000 desktops.
Makes data protection easier. Use GPOs and Folder redirection intelligently along with Terminal Services and you can guarantee the safety of your users’ data. Because all the computing is being done server side you have total control of where data is being saved. You can now know for certain that data resides on file servers where it gets backed up versus local hard drives where data can easily be lost.
Easily deploys specialized applications. Some organizations have an application or suite of applications that change revisions much too often, or perhaps a difficult application that might take 30 minutes just to install and configure. These types of applications are ideal for Terminal Server. You can now just maintain the applications on a team of servers instead of hundreds or even thousands of individual end user machines.
Consolidate and simplify IT for hub and spoke environments. Rather than hire unnecessary IT staff for small locations, administrators can use Terminal Services to maintain PCs and applications. Using Terminal Services, a corporation can in essence become its own ASP and serve applications from a central location to those 20 remote offices. This greatly reduces the complexity and cost of supporting the remote offices.
Microsoft’s Terminal Services, now in its third generation, continues to evolve. A good number of improvements have been made based on the Windows 2000 platform. Significant enhancements include the following:
Greater support for low bandwidth connections. Previous versions of Terminal Services did not fair well over low bandwidth connections. With Windows 2003 Microsoft promises marked improvements in low bandwidth performance.
Greater scalability. At the Windows Server 2003 launch events Microsoft made claims of 2003 Terminal Services being able to support up to twice the number of users as the same hardware would with Windows 2000 Terminal Services. Although this seems a little aggressive to make this claim it must mean significant improvements have been made.
Easier to manage. Terminal Services now takes greater advantage of Group Policies and remote management is now available through a comprehensive WMI provider.
Greater client feature set. Terminal Services now supports true color, audio redirection, com port redirection, local and network drive redirection, smart card support, and time zone support.
As the number of terminal servers needed and the number of users accessing these terminal servers increase so does the complexity for you. Administrators now have to consider how to scale hardware, how to handle redundancy, availability, load balancing, printing, user data, profiles, and so on. Without proper planning and consideration, Terminal Services can quickly become a burden instead of a blessing.
There are two schools of thought regarding how to scale the hardware needed to support the end users. For example, look at a company that wants to support 1,000 concurrent users and will be deploying a single application that it knows a server with dual 2.0 GHz processors and 4GB of RAM will be able to support 100 concurrent user sessions. One school of thought is consolidation, meaning do as much as possible with as few machines as possible. For this scenario you could purchase three 8-way servers loaded with 16GB of RAM, each machine supporting 350 concurrent users per server. The other school of thought is to tackle the issue with a larger amount of less powerful machines. For example you could purchases 10 dual processor servers with 4GB of RAM, each machine supporting 100 concurrent users per server.
Although both approaches will meet the goal of supporting 1,000 concurrent users, let’s look at the pros and cons of each school of thought. Using three 8-way servers, updating applications, applying patches, monitoring performance, and other maintenance tasks only have to be performed on three servers as opposed to 10. Although this might look attractive, using this approach puts a lot of eggs into one basket. If a server has a problem, be it loss of connectivity, a blue screen, a hardware failure, or something else that will cause a service outage, 350 users are now affected versus 100 if you go with more of the smaller hardware.
With the cost of hardware today it will be more cost-effective to purchase 10 dual-processor boxes versus three 8-processor boxes. Terminal Services does not scale linearly with the number of processors. Just because a dual processor machine can support 100 users that does not mean an 8-processor machine can support 400 users. In reality scaling really starts to fall off beyond a quad-processor machine so a lot of money can be saved by choosing the hardware wisely. Blade type servers can be quite cost-effective in this application.
Using the larger amount of smaller servers will allow for more flexibility for you as far as redundancy is concerned. Having a larger hardware pool allows for additional flexibility in terms of where applications are installed. A particular application might be unstable or a huge resource hog and as such you might want to quarantine it to its own set of servers. With the larger amount of hardware you could do this and still have enough resources to support the user community.
With Terminal Services out of the box load balancing is only available at the server level and not the application level and is accomplished using Microsoft Network Load Balancing or your favorite hardware/software-based solution such as those offered by F5, Cisco, and others. Unfortunately this means there are a few drawbacks of which you must be aware. Load balancing at the hardware level means that if you are publishing individual applications versus whole desktops then every server that is part of the load balancing pool must have the ability to serve up the particular application. This means that the application must exist on all the servers in the pool and be installed using the same path on each server.
Although at first this might not appear to be much of a hurdle, just make each server identical. Unfortunately, that is not always practical. As mentioned before, certain applications might need to be quarantined to a subset of servers, or for security reasons there might be multiple smaller farms of servers assigned to particular organizations within the company. So one large load balanced pool of identical servers might not be the solution. Instead some creative use of multiple load balancing pools might be in order.
For example you could break up your server farm into three distinct groups and create three load-balancing pools for it. Instead of one virtual address on the load balancer being associated with nine identical servers you might use three virtual addresses and associate them with three sets of three servers. Each smaller farm of three servers would be serving a different set of applications. For example, instead of the clients connecting to ts.companyabc.com they could have three separate connections defined that would connect to tsfinance.companyabc.com, tsengineering.companyabc.com, and tssales.companyabc.com. Each of which would be load balancing a team of three servers containing applications associated with finance, engineering, and sales.
Another drawback with the hardware-based load-balancing solution that Windows 2003 now addresses is that of reconnection. Prior to Windows 2003 if a user disconnects from a terminal server session and then attempts to reconnect to a hardware load balanced farm, the user might or might not attempt to connect back to the server where their disconnected session awaits them. Instead the user can end up having to start a brand new session instead of being able to continue working where she left off in the disconnected session. This leads to inconsistency, open files, wasted resources, and ultimately end user confusion and frustration.
Windows 2003 now addresses this problem with Session Directory. Session Directory is a database that keeps track of sessions on terminal servers in a cluster and provides the information used at connection time to connect users to existing sessions. With session directory when a connection attempt is made to the cluster, the server that receives the request first checks with the session directory server to see if the user has an existing connection on another server.
If so the session directory informs the server of this and it directs the client to the appropriate server that contains the existing session. If the user does not have an existing session, then the session is launched from the server that received the initial request. In both cases after the connection is established the session directory is then updated. Session Directory is not enabled by default. You must perform the following steps to set up Session Directory properly:
A server must be identified as the session directory server. Any server in the domain will work. It is not required to even be running Terminal Services.
After you have chosen what server you want to be the session directory server, you must go into the services control panel and start the terminal server session directory service. It is highly recommended you also set this service to Automatic so that it will start after a server reboot.
After this has been done, open the Terminal Services Configuration MMC snap-in, go to server settings, and right-click session directory.
Here you would check Join Session Directory, and then identify the Session Directory Server by entering the name of the server that has been configured to run the service. See Figure 20.1.
How you configure setting pertaining to Terminal Server IP Address Redirection depends on the load-balancing solution you use and how it is implemented.
If the load-balancing solution allows for the clients to attach directly the terminal server’s IP address you should leave the IP address redirection box checked and select the proper network interface and IP address.
If the load-balancing solution does not allow for direct connection to the terminal server IP address and instead requires the client to attach to the virtual address to direct the request to the proper terminal server, terminal server clients and the load-balancing hardware must both support the use of routing tokens. This requires configuration and software support in the load-balancing device specifically for terminal servers and routing tokens. Uncheck the IP address redirection box and follow the documentation provided by your load balancing solution.
Terminal Servers Requirements
Terminal servers are required to be running Windows Server 2003, Enterprise Edition, or Windows Server 2003, Datacenter Edition, to participate in a Session Directory–enabled farm.
After completing these steps all servers will become members of the cluster and use the session directory. Note this can also be accomplished via a GPO and that would be a more efficient method of configuration as opposed to configuring each terminal server individually.
Although Session Directory does improve things over Windows 2000 Terminal Services it still might not provide the flexibility and effectiveness you want. So in most cases after an environment has outgrown the ability to use machine-based load balancing the company will turn to a third-party software provider like a Citrix, New Moon Systems, or Jetro Platforms to provide application-based load balancing. All of these products will allow for load balancing to be performed at the application level. This allows for dissimilar servers in the farm and the ability to take advantage of dissimilar hardware. Using one of these third-party tools you can configure the system to ensure the client always connects to a server capable of running the specified application with the most resources available at that particular point in time.
To avoid the Session Directory from becoming a single point of failure you can configure Session Directory to run as a clustered service using Microsoft’s clustering technology. You create the cluster by following these steps:
Set Terminal Services Session Directory Server service to Automatic.
Ensure that the following resources are available in the server cluster configuration:
Physical Disk—. In addition to the quorum disk, the cluster will require a shared disk for the shared data. This shared data disk must be able to failover to all nodes in the cluster that you want to be able to host the Terminal Services Session Directory database.
IP Address—. A static IP address accessible from all the terminal servers that will be configured in the load balancing cluster.
Network Name—. A name that is resolvable from all the terminal servers in the cluster. Kerberos is required for all communication between the terminal server and the Session Directory server. Make sure to select Enable Kerberos Authentication and DNS Registrations Must Succeed before bringing the network name resource online.
Select File, New, Resource. This will start a wizard. Enter the name and description, and set the resource type to Generic.
Click Next and accept the defaults.
Define your dependencies. Specify the Physical Disk and Network Name resources.
Define the Generic Service Parameters. Specify the service name, TSSDIS, in the Service Name box, and check the box next to Use Network Name for Computer Name.
Configure Registry Replication. Click Add and type SystemCurrentControlSetServicesTssdisParameters.
Click Finish.
Out of the box there are a number of things you can do to improve the performance of your terminal servers. Many of the options will depend on the specific environment, applications, and expectations of the end users. Things like color depth, audio redirection, printer redirection, and encryption level all have an effect on the amount of CPU, memory, and bandwidth used per session. This, in turn has a direct correlation on the number of users that can effectively work per server and the performance of the connection over the network. It is up to you to evaluate the environment and modify the client connection settings or the server side connection settings to maximize performance.
As a general rule turn off all features that are not needed for the end user to complete his tasks. Server-side resources can also be optimized by the effective use of the terminal server connections. Limiting users to one session, limiting the number of sessions per terminal server, and logging off disconnected or idle sessions are all things you can do to conserve server-side resources and thus increase the overall performance of the system as a whole. It is also important to look at the application(s) being delivered via Terminal Services and tweak them for maximum performance. Microsoft Office is a great example of this. Turning off the Office Assistant, spell and grammar check as you type, automated windows, and things of that sort can greatly reduce the amount of network traffic and CPU consumed.
You can use a few simple tools to help create a very consistent, efficient user environment for the terminal server users. With the use of Terminal Services profiles along with folder redirection to centralize user settings/data the terminal server administrator’s users will enjoy a very consistent environment no matter which terminal server they connect to. Without the use of these tools a new profile will be created every time a user log’s into a terminal server. For the end users this means setting up application preferences over and over again, potentially not knowing where they saved their work, and other inconsistencies that can lead to confusion for the end users.
To define a TS profile you go into your Active Directory Users and Computers snap-in, select a user account, and then click on the Terminal Services Profile tab. Then define the path to the profile storage area. Typically it’s \servernamesharedfolderusername. Alternatively, you can use a terminal server GPO to define the location of the profiles. To configure via GPO, edit Computer Configuration/Administrative Templates/Windows Components/Terminal Services/Set Path For TS Roaming Profiles and place the desired path there. It is very important to make sure the server that the profiles are stored on is robust, highly available, and has plenty of disk space to store all the profiles. Do not use the same path for Terminal Server profiles that has been defined for the regular roaming profiles if they are being used. Having the profile open and updated from multiple locations will cause strange behaviors and even data loss.
It is a good idea to use a GPO to define exclusions for the roaming profile. Things like temporary Internet files, temp files, history, and things of that sort can cause profiles to grow tremendously. By excluding these from the profile it will keep the profile size down and thus require less disk space and will speed up launch times because the time it takes to copy the profile from the central location to the terminal server does directly affect the amount of time it takes to open and close the application. To define the exclusions you will want to modify and enable the following GPO within the Group Policy editor: User Configuration/Administrative Templates/System/User Profiles/Exclude Directories in Roaming Profile.
Folder Redirection
If folder redirection is used, you will want to exclude those redirected folders from the roaming profile as well because it would be counter-productive to redirect the folder and then copy it to the local profile.
Use Folder Redirection Globally
Use folder redirection globally in your network and redirect everything (application data, desktop, My Documents, and Start menu) and now no matter if your users are running local applications from their desktop or applications via Terminal Services their experience and file locations are the same.
The use of folder redirection with Terminal Services has a few benefits making it worthwhile. By redirecting folders instead of storing them in a profile and having them copied back and forth the amount of network traffic required to upload and download the profile is greatly reduced. For example if a user has 100MB worth of Word documents in his My Documents folder all that has to be brought over during launch thus causing a slow application launch and closing as it copies everything back.
If you instead do folder redirection the data will always reside out on a server on the network and does not have to be copied back and forth. It is instead only accessed when necessary and now instead of copying over 100MB worth of profile it might be as small as 2–3MB. The use of folder redirection also ensures that user data is in a known central location making it very easy for you to back up. Use the GPO to remove cached copies of user profiles to help keep the application servers clean. The deletion of the profiles is not 100% so if you are worried about disk space, periodic house cleaning will be necessary because profiles will sometimes be left behind. Include a section to clean up profiles in a reboot script as a good practice.
New for Windows 2003 is the Windows Resource Manager. Although its use is not exclusive to Terminal Services it is a great tool to take advantage of. You can now limit the amount of CPU and memory an application can use. You can even go as far as to have separate settings based not only on an application but a user or group as well. Using Windows Resource Manager you can now provide a more consistent user experience, enforce a certain level of QoS, and be able to prevent things like a single rogue session from bringing all the other sessions on the server to a grinding halt.
Windows Resource Manager can also be used to provide tiered levels of performance for users. A Terminal Server that is dedicated to the engineering department might be underutilized so you might want to open it up to the sales group. By placing CPU limitations by both program and user, you can ensure that the sales users that utilize the Engineering Terminal Server can never use more then 10% of the system’s capacity. This ensures that engineering jobs will still run with acceptable performance on the occasions that they are used.
Windows Server 2003 now provides specific Terminal Services policies to assist you in managing your terminal servers. These are but a handful of the group policies available and will need to be used in conjunction with the other non–TS-specific policies.
Within Server 2003 there are both computer-specific and user-specific terminal server group policies. These policies should be used to maximize the security and performance of your terminal servers. Computer-specific policies will affect the terminal server as a whole no matter who logs into the system. As such care must be taken when applying these particular GPOs.
A simple way to manage the GPOs for your terminal servers is to create an OU for your terminal servers and place the servers into that OU and then apply GPOs to it. One GPO that is very important to apply is the Computer Configuration, Administrative Templates, System, Group Policy, User Group Policy loop back processing mode (see Figure 20.2).
Enabling this GPO is very important if you have created a separate OU for your terminal servers as mentioned previously and have defined the GPOs there. Otherwise the user context GPO settings will not take effect. This means that there are going to be settings that you want to take effect only when a user logs into the terminal server. To accomplish this you create your special set of GPO policies for the OU the terminal servers are in and apply the loopback processing to either merge or replace.
If you select Merge, then existing domain GPOs are merged with the special set created for the terminal servers. If Replace is selected then all the inherited GPO settings are ignored and only the set of GPOs defined for the terminal servers are applied. Some of the configuration options that are available for the GPO are as follows:
Keep Alive Connections. This GPO is particularly useful when the clients are connecting via a WAN link or via the Internet. By enabling this GPO the terminal server will check the session state between it and the client instead of the default behavior, which more or less assumes the session state. The benefit realized by enabling keepalive connections is that if there is a network hiccup that causes a break in the network connection between the client and the server the session will be placed into a disconnected state. Should the client attempt to reconnect to the Terminal Server it will connect back to the existing session instead of being forced into a new session. This prevents the client’s current work from sitting idle in a session it can no longer reconnect to without administrative intervention.
Automatic Reconnection. Assuming the RDP client is version 5.2 or later this setting can be used with or in lieu of the keepalive connection setting. If automatic reconnection is enabled the client will attempt to reconnect to a broken session every five seconds for 20 attempts.
GPO
The shortest interval that can be configured is one minute. Realistically if the environment lends itself to needing configuration, some end user training will be needed. The server will inform the end user to wait one minute, or to default to the keepalive setting before attempting to reconnect. Otherwise this setting is effectively useless.
Restrict Terminal Services users to a single remote session. By enabling this GPO you can accomplish two major things. First is maximizing the performance of the terminal server. By not allowing the user to have multiple separate sessions running at any given time resources are preserved. Zombie sessions, those that are running in an active state with no user actually connected, or sitting idle in a disconnected state forever, are a waste of system resources and will have a direct effect on performance and scalability. By limiting the user to a single session, the zombie sessions can be avoided. Secondly by limiting the users to a single session end user confusion is greatly reduced. If the users have the potential to have multiple sessions they then have the potential over time to leave behind dozens of disconnected or active sessions, which in turn can leave applications running in those sessions that might end up causing all sorts of confusion or even data loss.
Client/Server data redirection section. For granularity these type settings are normally configured client-side but in an environment that is particular about security it might be wise to look at these GPOs. Within this section, things like clipboard, drive redirection, printer redirection, com port redirection, and LTP redirection can all be disabled to prevent the user from being able to upload, download, or print information from the terminal server application.
Encryption and Security section. Enables you to force an encryption level. This is useful not only for security but also for performance. If all the terminal server users are on the local LAN encryption might not be a huge concern for you and as such you can force the encryption level to low and save CPU cycles on the server. This helps with performance and the number of users per server. You can also force a prompt for the password during a connection. This is especially useful in a more secure environment where a user might have checked the Save Password option on her client, which means that any person that walks up to the machine and clicks the icon will now be able to successfully connect to the terminal server as this user and access that data. Instead now even if the Save Password option was checked, the terminal server will always ask for the password thus helping prevent unauthorized use.
Licensing section. By default the terminal server licensing server will hand out licenses to any computer that requests one. Now (as of this printing) that a TS CAL is required for any type of computer accessing the terminal server, managing your licenses becomes more critical than ever. Not doing so might create headaches for you as the help desk gets flooded with calls from end users who cannot connect to the terminal server due to running out of licenses. By using the License Server Security Group policy, you can define a group of computers that the licensing server is allowed to issue licenses to, preventing rogue systems on the network, in perhaps a QA or development environment, from taking away CAL’s need for end user access.
Sessions section. This section is particularly useful for performance and even licensing reasons. You would use these settings to automatically log off disconnected sessions after a particular time frame. Disconnect active but idle connections for security reasons. There is also an option to log off the disconnected sessions or even active but idle sessions. This is particularly useful if the application being run is one with a limited number of licenses and a larger pool of users. By logging off idle sessions, instead of a license being used by a user who is off at lunch, that idle session is logged off and the license is made available to a new user.
User-specific settings are those settings applied to the users and not to the machine. As such by controlling via permissions what users or groups the GPO can be applied to you can control the behavior much more granularly than with the computer settings. Creative thinking here can go a long way in maximizing resources, performance, and security.
It Helps Avoid Confusion
You might find is a lot easier to define a particular application to run rather than publishing an entire desktop. It helps avoid confusion and makes it easier to secure the terminal server.
For example you could create two separate GPOs that modify the User Configuration settings differently. In this example the GPOs are called Finance and QA. For the Finance GPO you could define Start a Program on Connection and configure the financial package as that executable.
For security reasons you could also set the Remote Control of Terminal Server User Sessions to No Remote Control Allowed because this company has a policy that no one other than those in finance should be able to view finance information. Set the disconnected session to time out after 30 minutes and only allow reconnection from the original client to secure who is gaining access to the financial application and its data.
Conversely, the QA manager might want the administrator to define an application like a bug tracking package and would want to be able to view the QA engineer’s session at any time without asking for permission in order to monitor his work. Perhaps also have the session automatically log off after 10 minutes of idle time because the department has a 20 concurrent user license for this particular application but has 40 engineers who might need to use it. By using Terminal Services and managing the sessions via the GPO it is now very possible to need only 20 licenses for 40 users and still allow all 40 users to work effectively.
Because terminal servers will often be accessible via the Internet it is important to ensure that they are well secured. Whenever possible, take a layered approach to securing the devices.
When using Terminal Servers in an ASP environment or sometimes even in a corporate environment you will want to provide some protection for the servers by placing them behind a firewall. By default RDP communicates over TCP port 3389. If for some reason you would like to change the default port this can be done by modifying the following Registry key:
HKEY_LOCAL_MACHINESystemCurrentControlSetControlTerminal ServerWinStationsRDP-TcpPortNumber
Use Registry Editor at Your Own Risk
If you use Registry Editor incorrectly, you could cause serious problems that might require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk.
After modifying this key the server must be rebooted. A simple service restart does not do the trick.
Only RDP Clients Version 5.1 or Later
Only RDP clients version 5.1 or later are able to connect to a Terminal Server running on a nonstandard port. To make a connection to a server running on a nonstandard port you must follow the server name with a colon and the port number, for example, Terminalserver1.companyabc.com:1234
Administrators will need to fully understand their firewall and its settings. A lot of firewalls are configured to close connections after a certain period of inactivity. Although in theory this is a great feature for a firewall, when you’re trying to run a terminal server session through this firewall it is not. Prolonged periods of inactivity within the terminal session (if someone steps away to a meeting, goes on break, or takes a phone call, for example) mean no packets are passed back and forth between client and server. So what happens is the firewall closes the connection resulting in a lost session for the user. Worse yet, more times than not due to the way the session is broken the terminal server ends up leaving the session in an active state and the end user cannot connect back to it without assistance from you. In these cases you might attempt using the keepalive or reconfigure the firewall so it doesn’t drop idle connections.
To properly configure Keepalive, modify the following Registry keys:
HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminal Server DWORD "KeepAliveEnable" value should be set to 1 DWORD "KeepAliveInterval" value should be set to 1 HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters DWORD "KeepAliveInterval" value in milliseconds DWORD "KeepAliveTime" value in milliseconds DWORD "TcpMaxDataRetransmissions" numeric value
After setting these go into the Terminal Services Configuration Snap-In and under Sessions check the Override Users Settings box and chose Disconnect from Session.
Special thought and care should go into building a terminal server that is being used for the deployment of applications or desktops to end users. You should approach this with the knowledge that the end user is now effectively sitting down at the console of the server and working. As such the proper planning and building of the terminal server is critical to providing a stable, secure, and easy to use Terminal Server.
Because the end user is in essence sitting in front of the server it is your task to not only build the server so that the end user can run the applications necessary to work, but also restrict as much as possible of what the end user can do yet still work. An improperly locked down terminal server can and will spell disaster for the end users. Whether done purposely or accidentally, system changes, installation of third-party applications, deletion of files, and so on can equal downtime for all the users of that terminal server while you attempt to repair the damage.
Take the time up front to plan and build a securely locked down terminal server and it will pay off down the road in fewer support issues and less server maintenance.
One of the goals of managing an Application Terminal Server is to simplify security. One easy way to accomplish this is to break the server into three discrete partitions that can be secured independently. An example of a multipartition configuration would be as follows:
Use C: for the Operating System—4 gigs + pagefile space
Assign D: for the applications—depends on how many apps you plan to install—use common sense
Utilize E: for the temporary profiles—depends on how many concurrent users you have and if you do or do not use folder redirection and profile exclusions. If you do not use folder redirection or exclusions from the profile, the temporary profiles can grow to be very large. In the tens or even hundreds of megabytes. If you do use folder redirection and or exclusions profiles can be kept as small as a few hundred KB, generally growing no more than 2–4MB in size.
As you progress you will see that by breaking the server into three partitions you make things easier because the server has now been broken down into distinct categories that NTFS permissions can be applied to fairly easily without disrupting the functionality of the operating system or applications.
The C: drive will be for the operating system and system files only. By doing this, access to the C: partition can be locked down because there will be no user or application files here and thus no need for any accounts other then system and administrators to be able to write or even view the files.
The D: drive will be used as the target drive for application installations. It is advised that each application be installed into its own separate directory. For example install application A into D:applicationA and application B into d:applicationB not D:program filesapplicationA and d:program filesapplicationB. Different applications will require different file permissions to run correctly. If they are all installed into the same root directory it makes it a lot more tedious to secure with NTFS permissions.
That leaves the E: drive. This partition is set aside for the temp profiles terminal server creates during a session. Remember that even if you use roaming Terminal Server profiles, a local profile is always created for each session. By default Windows will place the users’ profiles under C:documents and settingsusername. Because the goal here is to simplify securing the partitions you do no want to require any end user access to the C: partition and as such would rather have the profiles be created on the E: partition instead. To change the default behavior and move the profile location to the E: drive, the following steps must be performed.
Create a Documents and Settings Folder on the E: drive.
Modify this key to change where the local copy of the profiles is written. By default it is %systemdrive%documents and settings.
Modify HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionProfileListProfilesDirectory Reg_Sz to a value of e:Documents and Settings
Reboot the server.
Copy over the Default and All Users profiles to the new location.
Building the server with the three distinct partitions, installing applications into separate directories, and moving the location of the temporary profiles is a great foundation for building a great terminal server. This only the beginning.
Using GPOs you can effectively limit a lot of undesired activity on the terminal servers. Although GPOs cannot protect the terminal servers 100% they are a great tool to use to achieve your goal.
A simple way of managing the GPO(s) for your Terminal Servers is to create an OU for your terminal servers and place the servers into that OU, and create a group policy for them. In this example it is called Lockdown. In order to prevent the group policy from interfering with your ability to perform your duties on the box, you will want to modify permissions on the GPO so that the terminal server administrators, whomever they might be, have the Deny box checked next to Apply Group Policy. See Figure 20.3.
This prevents the policy from being applied when you log in so you can still work. Remember that machine policies will still take effect, but most policies that would end up crippling you are user-based and as such won’t be applied when you log into the server. Now you can safely modify settings in the lockdown GPO. What you do and don’t do here really depends on your environment and the applications you’re going to deploy. It is highly recommended that you configure a set of policies, test your environment, configure another set, and test again until you are completely satisfied.
Applying proper directory and file permissions is a very important step in locking down the terminal server. Although the GPOs do a great job of attempting to keep users from doing malicious or accidental harm to the system they are not enough. A good set of directory and file permissions are a crucial piece of the lockdown process. This is also the area that you need to take the most care. Restrictive directory and file permissions can end up causing undesirable side effects while running applications via Terminal Services. It is imperative you fully test to the best of your ability the functionality of all applications hosted via Terminal Services after every round of modifications to directory and file permissions.
With Microsoft 2003 Terminal Services Microsoft now provides a much more impressive list of redirected local resources to a terminal session. With 2003 Terminal Services and an RDP client version 5.1 or later, you now have the ability to provide the user not only access to local and network drives and printers, but also COM ports and audio redirection. Users can now again enjoy something as simple as a new mail notification sound all the way up to viewing a multimedia presentation all via a terminal server session.
Although audio redirection is nice and another step closer to making a terminal server session experience rival running the application locally a perhaps more useful addition to 2003 Terminal Services is COM port redirection. The most requested use of this is being able to synch a Palm Pilot to applications running via Terminal Services. Prior to 2003 Terminal Services an administrator was usually unable to deploy Outlook to a fair number of users because the users had to be able to sync to their Palm Pilot. This is no longer the case. Although audio and COM port redirection are nice, Windows 2003 Terminal Services have been really improved in the area of local and network drive and printer access. Windows 2003 Terminal Services can now automatically map all of a user’s local and network drives and printers. The user now has full access to all their local and network drives and printers without you having to do anything in the background to set it up.
Ask any terminal server administrator the number one problem she has encountered while deploying Terminal Services and 9 out of 10 times you will hear about printing problems. By default when a client connects to the terminal server the terminal server will attempt to create all the printers that the client device is attached to into the terminal server session. Depending on the type and model of printer this might or might not work. The terminal server is only able to create printers for which it has drivers. By default the only printers that Terminal Services will be able to install are those listed in the ntprint.inf file and whose drivers are contained in the i386 directory. So, if a client device has a printer attached that uses a driver not listed in the .inf file that printer will not get created and the user will not be able to print to it.
To ensure the client device can print you have a few options. One option is to install the printer driver for the device onto the terminal server. Even though the printer is not really attached to the server you just go through the steps of installing the printer to lpt1 and then when complete you can now delete the newly installed printer and choose to leave the drivers behind. Now when the client connects the printer drivers are already installed onto the terminal server and the client will be able to print.
There are major drawbacks to using this method. A majority of manufacturer print drivers are not certified for use on terminal server and as such can cause various undesirable effects ranging from print spooler crashes to the infamous blue screen of death. Also in a large environment imagine trying to identify every single printer that will need to have a driver loaded onto every single terminal server; a daunting, potentially neverending task. A small modification to the previously mentioned method will result in a much more stable terminal server printing environment.
As previously mentioned, by default Terminal Services will be able to install all printers listed in the ntprint.inf file. What you can do is modify the ntprint.inf file to support the client printers. The basic steps are as follows. First identify the name of the printer driver from the client computer. Then the ntprint.inf must be modified by adding an entry to the Previous Names section that exactly matches the name of the client-side driver and then maps to a known stable printer driver that will print to the device. As you can see managing printers can potentially be a very big task for you and is probably the number one reason that people turn to the third-party manufacturers like Citrix, Newmoon, Jetro systems, and so on for their printing solutions. All of these manufactures provide what they call a unidriver. This is a single print driver that will allow printing to most any printer on the market. Although this is excellent for the stability of the terminal server, these unidrivers do lack in functionality and as such at times it will still be a requirement to install vendor drivers for the user to print properly.
If enabled Windows 2003 Terminal Services now maps both local and network drives defined on the client into the terminal session. Now it becomes very simple for a user to be able to run applications on the terminal server yet still access files from their local machine. This feature can of course be disabled for security reasons. It is not always desirable to give the end user the capability to upload and download files to and from the terminal server. In fact in most cases one can argue strongly that it is counterintuitive to what is trying to be accomplished by using centralized computing. That being said there will be many instances where Terminal Services is just being used either for remote access or a specialized application in a traditional decentralized computing environment and access to local resources will be a necessity.
Greater Performance Over Low Bandwidth Connections
Greater performance over low bandwidth connections will be achieved by not enabling client drive redirection. When at all possible keep user data on the local network and map drives via login scripts instead of redirecting the resources from the client.
In this chapter you learned that Microsoft 2003 Server brings with it a much more feature rich and higher performing version of Terminal Services by providing true color support, audio support, local drive mapping, local printer redirection, better support for low bandwidth connections, greater scalability, session directory, and more.
You have also learned the importance of taking the time to properly build and deploy Terminal Services. All the way from partitioning drives, installing applications, applying file permissions, and leveraging group policies, to other aspects of Windows 2003 such as load balancing and clustering to provide high performance, highly available, and secure server-based computing solution for one’s enterprise.
The Terminal Services functions in Windows Server 2003 give you a good indication of things to come from Microsoft. After seeing Terminal Services in Windows 2003 one can see a future where employees will be able to attach to airport kiosks to RDP into their office Terminal Servers, look at their e-mail, and synch that e-mail onto a PDA through a redirected port. Applications will talk to each other even though they are running on separate terminal servers. There is already talk of technologies to allow you to move live user sessions from one Terminal Server to another so that the server can be taken down for maintenance.
As the pendulum continues to swing back and forth between centralized and distributed computing, each cycle of the pendulum brings more and more functionality to the end user. Terminal Services continues to be a valuable and exciting technology that makes the end user experience better and your life easier.