Terminal Services in the Enterprise


In this part of the chapter, we discuss some issues that will likely be encountered when adding Terminal Services to an enterprise organization.

Domain Considerations

The standard principles for installing a Terminal Server apply equally to Windows 2000 and Windows 2003 Terminal Services. If Active Directory is installed on the network, simply join the Active Directory domain. There is no longer a primary domain controller (PDC) or backup domain controller (BDC) in Active Directory setup. For legacy support, a PDC Emulator will be created in the Windows 2000 domain controller when a Windows NT Domain client attempts to log on. Therefore, it is possible to mix TSE servers with Windows 2000 and Windows 2003 servers running Terminal Services.

click to expand

Migrating to Windows Server 2000 or Windows 2003 Server from an Existing Windows NT 4.0 PDC

If a Windows 2003 server is installed in an existing network that employs backup domain controllers, the new Windows 2003 server operates as a "mixed mode" domain controller. In this case, the Windows 2003 DC will be migrated first to Active Directory and will emulate a Windows NT 4.0 PDC. The old PDC-to-BDC security database synchronization will continue until all BDCs are migrated to Active Directory and "mixed mode" has been switched to "native mode."

Application Considerations

Most applications are written to run on a single-session platform such as Windows 95, 98, or Windows NT Workstation with a single user. Terminal Services requires significant changes to be made to the kernel and operating system to accommodate multiuser access. Because of these changes, both programmers and administrators must fully understand the issues and possible solutions in order to configure the system so that single-session applications can be executed in a multisession environment. We discuss some of the problems and possible solutions in this section.

Terminal Services makes special demands on how an application is written and how the application uses the Windows NT operating system. The Windows NT Registry is used by many programs to store variables during an installation, changes while the program executes, and changes that normally occur when users with differing logons access the application. On a typical Windows 2000 Professional workstation, an application may put data into the HKEY_LOCAL_MACHINE registry hive, assuming only one user will access the application at a time. On Terminal Server, this could prove disastrous, as changes to this registry hive would affect all users of this Terminal Server, not just the user executing the application making the change.

Many problems occur with applications that store local data constructs in global locations. In addition to separating global and local information in the registry, global and local file-based data constructs should also be maintained separately. For example, user preference files should not be stored in a main system directory (/%systemroot%) or program directory (\Program Files). Instead, preference files or other user-specific local data should be stored in the user's home directory or a user-specified directory. This consideration also applies to temporary files used to store interim information (such as cached data) or to pass data on to another application. User-specific temporary files must also be stored on a per-user basis.

Some specific issues that may cause an application to fail in a multiuser environment include

  • Incorrect registry entries Many applications write a global INI file to the system root for user-specific information. Thus, when one user changes or opens the INI file, other users may not be able to access the same file. Some applications add shortcuts to only the installer's menu during installation; because of this, other users may not see the shortcut. Still, many applications point the data files, temporary files, or cache files to the same location for all users. In this situation, only one user can run the application at a time.

  • Changed object name An object created in a session is named differently. The application may not be able to find the object using the expected name or location.

  • Incorrect file and object rights access An application normally locates libraries and executables in the Windows NT %SystemRoot% directory. Multiple users accessing the same file may create file-locking problems.

The following are some other application problems and issues to be aware of within a multiuser Terminal Services environment:

  • Do not assume the computer name, MAC address, or IP address equates to a single user. In the traditional distributed Windows client-server architecture, one user is logged on to one computer at a time. Thus, the computer name or Internet Protocol (IP) address assigned to either a desktop or server computer equates to one user. In the Terminal Services environment, the application can only see the IP or NetBIOS address of the server. Applications that use the computer name or IP address for licensing, or as a means of identifying an iteration of the application on the network will not work properly in the Terminal Services environment because the server's computer name or IP address can equate to many different desktops or users.

  • MS-DOS and 16-bit Windows applications require more RAM than native 32-bit Windows applications and may not execute at all in Windows 2000 Server or Windows Server 2003. Windows runs an emulation layer called the Virtual DOS Machine (VDM) as a process on the 32-bit operating system. Although this memory requirement may not show up as performance degradation on a high-powered desktop computer running the latest Windows operating system with 64MB of RAM, it may easily show up on a system running Terminal Services due to the multiplier effect of many user sessions.

Multiuser Application Issues

You may encounter several possible issues when running applications under Terminal Services that were not designed to run in a multiuser environment. Some of the most important issues are summarized here. We will discuss these and other application-related issues in more detail in Chapter 13.

Application Compatibility Scripts

Many of the issues discussed so far have been addressed by the creation of application compatibility scripts. After installing an application, an administrator is required to run the corresponding script to resolve the issues mentioned. Windows 2000 shipped with 27 native Application Compatibility Scripts, and since then scores of software manufacturers have created additional scripts to provide users with fixes for their software in a multiuser environment. At the time of this writing, Windows 2003 only has four scripts in the Application Compatibility Scripts folder. Since Microsoft requires an application be multiuser compatible before it can be certified for Windows 2003, our assumption at this time is that a large majority of application vendors have simply included the scripts in their install process, thus alleviating the need for scripts. Obviously there will be some stragglers, so the need for Application Compatibility Scripts will continue for the foreseeable future. Application compatibility scripts are located in the %SystemRoot%\Application Compatibility Scripts\Install folder.

DOS and 16-Bit Windows Programs

After over eight years of Microsoft operating system support for 32-bit applications, it seems logical that all application vendors would have completed their software porting to take advantage of the speed, stability and interface changes. Win32 allows code sharing and thus runs more efficiently in a multiuser environment. If additional users need to access the same Win32 application code, a pointer is created that shares the same code from the original copy loaded in the kernel and user modes. Code sharing cuts down the total amount of memory usage when multiplying a large number of sessions. On the other hand, 16-bit Windows and DOS applications need to run in their own VDM, and so no code sharing is possible. Also, Win16 applications often require 16- to 32-bit conversion programs ("thunking" and "context switching") that increase resource utilization even further. Even with all of these obvious advantages, and nearly ten years to get it done, there are still a few poorly run software vendors who have not ported their software to a 32-bit code. We highly recommend running only 32-bit Windows applications whenever possible, even if it requires a large investment in moving to another vendor. Because Windows 2000 and 2003 are not well suited for DOS or 16-bit application support (although there are some instances where it works), if 16-bit or DOS applications are required, consider dedicating a Windows NT 4.0 TSE server to those applications, while building the rest of the farm around Windows Server 2003.

Effective Use of the Registry

In a multiuser environment, applications should store common information pertaining to systemwide operation in the HKEY_LOCAL_MACHINE section of the registry. Such information includes the path used to load application components, and what components are needed during execution. User-specific information, such as the locations of custom dictionaries (custom.dic) and user templates (normal.dot), should be stored in HKEY_CURRENT_USER. Some applications incorrectly store information meant to be user specific in HKEY_LOCAL_MACHINE.

Application compatibility scripts, Group Policies, and user profiles can all address an unused drive letter to the home directory of each user. REG.INI then changes pointers to this drive to each user's home directory environment variable. In this way, each user gets her own copy of an initialization file.

Tip

A utility in the Exchange Server Resource Kit, named profgen.exe, resolves common pointer issues arising from users trying to open the same e-mail post office box when a mandatory profile is used. This utility can be useful when enabling many users running Terminal Services to access the same Exchange server.

Application Install and Execute Modes

During installation, an application writes user-specific keys to the Administrator's HKEY_CURRENT_USER registry hive. Information such as Document Path and Autosave Path are missing from other users' HKEY_CURRENT_USER keys because they did not install the application. These keys are crucial in successfully using the application. Terminal Services provides a global Install mode to address this situation. During installation, the system is placed under Install mode by entering the command Change User /Install at the command prompt or by using Add/Remove Programs from the Control Panel. All user-specific keys generated by the application under the software hive are shadowed by a key hive in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNt\CurrentVersion\TerminalServer\Install.

This key hive is appropriately called the shadow key. Once installation is completed, the system can be switched back to normal execution mode by entering the command Change User /Execute at the command prompt. In the Execute mode of operation, the shadow key information is written back into each user's software key hive when the system finds that the keys are missing.

The same command addresses missing INI and DLL files in the case of 16-bit applications. These files are copied into each user's Windows directory (normally, %homedrive%\%homepath%\windows). This also applies to 32-bit applications if they use INI files. The %homedrive% and %homepath% variables are both solved when running chkroot.cmd and are replaced simply by %rootdrive%. The files that are copied to C:\WTSRV and C:\WINNT are copied to %rootdrive%\windows when a new user logs in.

User-Specific Application Data

Some settings, such as DocumentPath in the HKEY_CURRENT_USER Microsoft Word subkey, may only be created the first time the application is run. Therefore, the installer must execute the application in global Installation mode right after finishing the initial installation. By doing this, the system will generate these values and record them in the shadow key so that they can later be copied into each user's HKEY_CURRENT_USER registry hive.

Note

Logging in as a user and changing settings in an application can cause problems for any user running that application. Making a change while logged in as a normal user on a production machine to store a user's name and initials would cause all future users to see that user's name and initials when they edit documents. Thus it is important to find where these paths are stored and to script or add them to the shadow INSTALL key mentioned earlier so that all users only get the changes the administrator wants them to have.

Sometimes an application creates a path pointer to a common location for all users. For example, the Microsoft Office 97 installation program sets a document template pointer to C:\Program Files\Microsoft Office\Template. When multiple users try to update or open the same file, errors will occur. To address this situation, the administrator needs to search the registry and change the pointer to each user's home folder, such as H:\Office 97\Template, then create the correct directory structure for each user in the logon script %SystemRoot%\System32\usrlogn2.cmd. This file is called by the usrlogon.cmd (if this file does not exist, create it using a text editor) and add the following simple statement to accomplish this task:

 IF NOT EXIST H:\OFFICE 97\TEMPLATE MD H:\OFFICE 97\TEMPLATE 

Note

Most of the Microsoft Office installation issues discussed here have been resolved with Office 2000 and XP, or are easily resolved with the Office Resource Kit. These discussions still serve as an example of how to resolve similar problems with other applications.

A similar problem occurs when all users are directed to use the same cache files. The cache file pointer is set to a common location, such as C:\Temp\Cache. When multiple users attempt to write to the same location, the application will often halt, corrupt the cache, or simply crash the server. Again, the solution is to change the pointer in HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, then create the corresponding directory structure in each user's home directory to support an individual application cache.

File Security

Applications often store files in the system root directory. Security is normally set to Read-Only for regular users. When a user attempts to write to a file stored in this directory, execution of the application may fail. You can track down the particular file and reassign security to it by using the FILEMON utility (this freeware utility is available from Sysinternals at http://www.sysinternals.com). A better method is to relocate the file to each user's Windows directory.

Registry Security

Many issues arise due to registry security and incorrect use of the registry by legacy applications. REGMON is another tool available at the Sysinternals web site that administrators can use to track down registry keys that have the wrong security.

Application COM/DCOM Objects

The same application may create identical objects for multiple sessions. To separate the same object created by different sessions, a logon ID is appended to each object name. Session objects created in this way are called user global objects and are only visible inside the session in which they were created. If an object is created from the console, there will be no logon ID appended to the object name. This type of object is called a system global object. Because of this distinction, application objects to be used for multiple sessions should be generated as system global objects and installed from the console instead of a user session.

Note

Always install software from the console because of the issues mentioned earlier that arise from running applications in a session.

Memory Utilization

Some applications do not return memory to the system upon exit. This situation is exacer-bated in a multiuser environment, and is difficult to track down when a large number of applications and users are involved. Although a nightly reboot with Windows 2000 or Windows 2003 should not be required if the applications are well written, real-world environments typically have at least one rogue application that is poorly authored. Many SBC environments implement a cyclical reboot program in order to clear memory and prevent memory leaks from causing erratic performance and server crashing. The frequency of the reboot depends on how active the memory utilization is. Citrix MetaFrame XPe has a reboot tool, and many of the resource web sites we list in the appendixes have example scripts as well.

DCOM Compliance

Most programs use traditional Open Database Connections (ODBC) to access network objects, such as a data source in a SQL database. To allow a common interface for communication between all system programs (objects) across a network, Microsoft developed the Distributed Component Object Model (DCOM).

In order to be certified by Microsoft as Windows 2000 or Windows 2003 compatible, an application must support DCOM. This ensures that software components can communicate and share functions over a network in an efficient and reusable manner. TSE inherited a subset of DCOM functionality from Windows NT 4.0. Therefore, some applications written for Windows NT 4.0 may not function properly under TSE's multiuser environment. Microsoft has addressed this issue in Windows 2000. All DCOM activation modes are fully supported, as shown in the following:

  • Run as Activator Local activation is the same whether Terminal Services is enabled or not. The server is activated on the same session as the activator.

  • Remote Activation When DCOM is activated remotely, the process is launched in a WindowStation with a special SessionID =0, not a session corresponding to the user. This modification preserves the implementation activity of a remote call.

  • Run as Named User The application is configured in the registry to run as a specified user. Local and remote activation of DCOM behaves in the same way.

  • Run as Windows NT-Based Service The application is configured to run as a service. This type of service is not tied to any session.

  • Run as Interactive User The application is configured to run in the security context of the user.




Citrix Metaframe Access Suite for Windows Server 2003(c) The Official Guide
Citrix Access Suite 4 for Windows Server 2003: The Official Guide, Third Edition
ISBN: 0072262893
EAN: 2147483647
Year: 2003
Pages: 158

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net