Chapter 1, “Microsoft Windows Terminal Services,” talks about the management tools included with Terminal Services, including the special options available for configuring a user’s account for operation on a Terminal Server. Active Directory Users and Computers for both Windows 2000 and 2003 provides these features. Figure 21.1 shows the Terminal Services Profile tab for a user’s account properties. This is where the user’s Terminal Server home and profile folders are defined.

Figure 21.1. Populating the Terminal Services Home Folder field.

The home folder is of particular importance in a Terminal Services environment because it’s where the user-specific application and environment data are stored. For example, a Terminal Server uses the home folder to store a personal copy of WINI.INI and SYSTEM.INI for each user who may be running a 16-bit application, instead of using the single copy normally found in the %SYSTEMROOT% folder.

The Terminal Server home folder and profile paths are referenced only when a user is logged on to a Terminal Server. When the user is logged on to a non–Terminal Server environment (such as a Windows 2000 or Windows XP Professional desktop), this information is ignored. Figure 21.2 shows the simple process flow used by Terminal Server to determine where the user’s home folder is located.

Figure 21.2. The process flow for determining the home folder path to use in a Terminal Services session.

If a Terminal Server home folder has been defined, it’s used. If not, and a regular Windows home folder has been defined, that’s used instead. If neither has been defined, Terminal Server defaults to using the user’s local profile path:

You can view the current location of a user’s home folder simply by opening a command prompt from within the session and running SET to view the current environment variables. The variables to look for are HOMEDRIVE, HOMEPATH, and HOMESHARE. Assuming that the share point is \FileSrvUsers, a sample output of SET would look something like this:

HOMEDRIVE=U:
HOMEPATH=
HOMESHARE=\FileSrvUsers	wmathers

Another application integration feature available with Terminal Server is having two special modes of operation: execution mode and installation mode. By default, the Terminal Server operates in execution mode for all users, including administrators. As you may have guessed, the server is put into installation mode when an application is being installed on the server.

There are two ways in which to control the mode of operation. The first is to use the CHANGE USER command from a system prompt as follows:

The other option is to use the Add/Remove Programs applet in Control Panel. When adding or removing a program, the server automatically performs the switch between execute and install modes.

In Windows 2003/2000 Terminal Services, the operating system itself doesn’t let you install many applications unless the server has been placed into install mode. Figure 21.3 shows the message you receive when you try to do this. This doesn’t work for all applications, but many of the most popular commercial applications are caught by this operating system feature. This feature was not available in Windows NT Server 4.0, Terminal Server Edition.

Figure 21.3. The warning message displayed on a Windows 2003 or Windows 2000 Terminal Server when you attempt to install an application while in execute mode.

Terminal Server provides the ability to modify the behavior of specific applications as well as the registry and INI file mappings that I discussed in the preceding section. This is done through use of program compatibility flags (PCFs). PCFs are a special set of registry values that tell Terminal Server what to do with a specific program, registry key, or INI file. These three registry keys are located under this key:

These are the specific keys:

Depending on the key, certain compatibility flags are available to use in modifying the entries’ behavior. All PCFs are REG_DWORD hexadecimal entries. If multiple entries are set for a particular value, you need to sum the individual hex values to determine the actual hex number to enter. If you’re uncomfortable with performing hexadecimal arithmetic, use the Calculator application to perform hex calculations in scientific mode.

SYSTEM:REG_DWORD:0x44
WIN:REG_DWORD:0x44

MicrosoftWindows NT:REG_DWORD:0x108

Application Registry Key

For a specific application, up to four registry values can be created that control the application’s behavior while running on Terminal Server. Figure 21.4 shows the registry entries for the Microsoft Access application (MSACCESS.EXE). Notice that the .EXE extension is not included in the key name.

Figure 21.4. Program compatibility flags for Microsoft Access.

As the figure shows, there are four registry values for MSACCESS:

• FirstCountMsgQPeeksSleepBadApp

• MsgQBadAppSleepTimeInMillisec

• NthCountMsgQPeeksSleepBadApp

• Flags

The first three entries are used to tune an application to function optimally on Terminal Server. You shouldn’t modify or set any of these values for an application unless you’re experiencing a real performance issue. I talk more about these settings a little later in this section.

The fourth entry is the Flags value. It contains a hex value that provides Terminal Server with information about the application and indicates whether any special actions are required, such as disabling registry mapping. Table 21.2 lists the entries for the Flags value. As with the INI and registry settings, multiple values are set simply by summing the hex values to come up with the new hex value. For example, if you want to flag that the entry is for both the 16-bit and 32-bit applications, you sum 0x04 and 0x08, resulting in 0x0c in hex.

Table 21.2. Valid Flag Settings for an Application

Flag	Description
0x00000001	DOS application.
0x00000002	OS/2 application.
0x00000004	Windows 16-bit application.
0x00000008	Windows 32-bit application.
0x00000010	Substitutes the user name for the computer name. If the application requests the computer name using the GetComputerName API, Terminal Server returns the user name instead. This setting is typically used with applications that equate the NETBIOS name for the machine with an individual user.
0x00000020	Returns the Terminal Server build number instead of the Windows build number. For Windows 2003/2000, the build numbers are the same. On TSE4.0 the Terminal Server component has a different build number than the OS.
0x00000040	This indicates that INI file or registry data should be synchronized with any new data instead of the existing information being replaced by the new information.
0x00000080	For this application, don’t substitute the user’s personal Windows folder for the system folder. This means that the user’s personal Windows folder is not substituted, and the %SystemRoot% folder is used instead when this application makes reference to an INI file.
0x00000100	Disables registry mapping for this application.
0x00000200	Enables per-object mapping for user and system global objects associated with this application.
0x00000400	Returns the %SystemRoot% folder to the application instead of the user’s personal Windows directory. This overrides the server’s default behavior when running in execute mode. This applies only to the specific application.
0x00000800	Limits the physical memory reported to the application. This flag is typically used when an application has problems running on a system with a large amount of physical memory. When specified, the default memory reported is 32MB. You can modify this value by including the PhysicalMemoryLimit value in the program compatibility key. This value should also be of type REG_DWORD.
0x00001000	Logs creation of named objects by the specified application. This flag is used to assist in debugging an application not running properly on Terminal Server. Normally, when an application runs, objects are created within the user’s name space by appending the session ID to the object name. This can cause certain applications that expect to find a fixed object name to fail. Using the REGISTER command, you can tell the Windows Object Manager to not append the session ID to an object created by a specified DLL or EXE. Using this flag you can generate a list of the objects created by an application along with the associated DLL. From this, you can get a list of the DLLs that must be registered. For the logging to take place, you must create a system environment variable called CITRIX_COMPAT_LOGPATH and assign it a valid directory where the log will be created. The logfile “<app name>.log” will be created in the specified location. This flag should be set only while debugging because it will degrade the application’s performance. For more information on the REGISTER command, see Appendix A, “Terminal Services Command Reference.”
0x20000000	Indicates that the application should not be put to sleep when it polls the keyboard unsuccessfully. This option should normally not be set because it can cause significant performance degradation.

Notice in Figure 21.4 that the value for the Flags entry is 0x80c. Consulting Table 21.2, this equates to the following:

• For both 16-bit (0x008) and 32-bit (0x004) applications we get the following summed flag values: 0x008 + 0x004 = 0x00c

• Limiting the physical memory reported has the flag value 0x800.

• For both 16-bit and 32-bit applications: 0x008 + 0x004 = 0x00c.

• This value limits the physical memory reported (0x800).

This is easily validated by adding the results to get 0x80c.

Now that you’re familiar with the various flags available for an application, the next thing to look at is the settings used for tuning a “badly behaved” application.

A “bad” application can exhibit unusually high or low processor utilization. If an application is run on a Terminal Server and a corresponding key does not exist for it under the CompatibilityApplications registry, it is automatically throttled by Terminal Server if it queries the message queue too often within a default time period. The result is an application that runs very slowly even though the system resource utilization (such as CPU and disk) is low. Software installation programs commonly fall into this category. A common solution is to add a registry key corresponding to the application’s executable name with values that correspond to the MSACCESS key. The descriptions for these registry values are as follows:

• FirstCountMsgQPeeksSleepBadApp—. This represents the number of times the application can query the message queue before Terminal Server initially flags it as “bad.” Lowering this value causes the application to be flagged more quickly, decreasing its processor utilization.

• MsgQBadAppSleepTimeInMillisec—. Once Terminal Server has decided that an application is “bad,” this is the number of milliseconds that the application must “sleep” before it can query the message queue again. Increasing this value forces the application to sleep longer.

• NthCountMsgQPeeksSleepBadApp—. Once Terminal Serer has flagged an application as “bad,” this is the number of times the application can query the message queue before it is once again put to sleep. Typically, this value is less than the FirstCountMsgQPeeksSleepBadApp value.

Looking again at Figure 21.6 for the MSACCESS entry, the values for the three settings are as follows:

• FirstCountMsgQPeeksSleepBadApp = 0xff (255 decimal)

• MsgQBadAppSleepTimeInMillisec = 0x1 (1 decimal)

• NthCountMsgQPeeksSleepBadApp = 0x5 (5 decimal)

So after 255 consecutive queries of the message queue, Access is put to sleep for one millisecond, and thereafter for every 5 queries.

NOTE:

These tuning values apply only to 16-bit or 32-bit Windows applications. If they’re set for a DOS application, they’re simply ignored. No native Windows mechanism ships with Windows 2003 or Windows 2000 to tune a DOS application. Those of you familiar with using the DOSKBD command from NT 4.0, Terminal Server Edition, will find that this tool is no longer available with Windows 2003/2000 Terminal Services.

As mentioned, you shouldn’t create or modify any of these program compatibility flags unless you have an application that’s behaving “badly.” If the application is running unusually slowly, even though the system utilization is low, then add an entry and assign values equal to those for the MSACCESS key. If an application exhibits unusually high processor utilization, I recommend performing the following steps to tune the application:

1. Launch PerfMon and monitor CPU utilization.

2. Start the offending application and record the baseline performance while running the application. Ideally, you should run it for 5 to 10 minutes or longer.

3. Exit the application and create the corresponding entry or entries in the registry under the Applications key. You can either type the entries or save the Setup key and then add it back in with the name of your application. The default values for Setup are as follows:

   • FirstCountMsgQPeeksSleepBadApp = 0xf (15 decimal)

   • MsgQBadAppSleepTimeInMillisec = 0x1 (1 decimal)

   • NthCountMsgQPeeksSleepBadApp = 0x5 (5 decimal)

   • Flags = 0xc (16-bit or 32-bit)

4. Rerun the application and compare the new PerfMon results with the baseline.

5. Exit the application and change the application settings to something like this:

   • FirstCountMsgQPeeksSleepBadApp = 0xf (15 decimal)

   • MsgQBadAppSleepTimeInMillisec = 0x64 (100 decimal)

   • NthCountMsgQPeeksSleepBadApp = 0x5 (5 decimal)

6. Run the application again and compare the reduction in processor utilization to the responsiveness of the application. You may want to compare this to adjustments in the FirstCount value to see if one provides a larger improvement over the other. Unfortunately, this is not an exact science, so it might take some time to develop the ideal tuning values for a particular application. You’ll likely have to settle for some excess utilization to ensure that the program is responsive enough that users will be able to use it.

Luckily, additional tuning isn’t usually required with most applications that run on Terminal Server.

NOTE:

Be careful with applications that are CPU-intensive. Many of these applications, even with use of program compatibility flags, are simply poor candidates for a Terminal Server environment. Compatibility flags won’t always rein in a poorly behaved application.

The next application support feature I look at is Terminal Server’s handling of each individual user’s temporary folder location. Normally, every user who logs on to a Windows computer has a temporary directory defined with the environment variables TEMP and TMP, where temporary data can be stored that can be deleted when the user logs off.

The only difference on a Terminal Server is that multiple temporary folders exist at the same time and must be managed individually. The default temporary folder location for all users is the %UserProfile%Temp folder. From Control Panel, open the system properties. Select Advanced and then click the Environment Variables button to display the TEMP and TMP values set in the user variables (see Figure 21.5).

Figure 21.5. The default temporary folder settings on Windows 2003 Terminal Services.

Figure 21.6. The root drive letter is entered and saved after running the chkroot.cmd batch file.

To give multiple simultaneous users access to the temporary folder, Terminal Server provides a feature known as per-session temporary folders. Every time a user logs on, Terminal Server creates a subfolder corresponding to the user’s session number underneath the TEMP folder. The user’s TMP and TEMP variables are then updated automatically to point to this location. If you open a command prompt and type “SET”, you see the modified values for these environment variables. For example, you might see this:

The subfolder “a5” corresponds to the current session number, and the short name (eight-character maximum) is used to ensure that DOS and Win16 applications can use the same environment variable. If these were my temp folders and I did a QUSER from a command prompt, I would see something like this:

USERNAME       SESSIONNAME      ID  STATE    IDLE TIME   LOGON TIME
 nsamble       ica-tcp#390      143  Active         .    8/2/2004 9:47 AM
 jhayman       ica-tcp#391      148  Active         .    8/2/2004 9:49 AM
>twmathers     ica-tcp#392      165  Active         .    8/2/2004 9:50 AM
 gott          ica-tcp#393      169  Active         4    8/2/2004 9:53 AM
 bsmith        ica-tcp#394      170  Active         .    8/2/2004 9:59 AM

The hexadecimal number a5 in base-ten notation is 165, which corresponds to my session ID, not the session name shown in the list above.

The permissions set on the folder are set to allow access only by the specified user and SYSTEM. When the user logs off, Terminal Server automatically deletes the associated temporary folder.

Whenever you reference a user’s temporary folder, be sure to use the TEMP or TMP environment variables. Never hard-code the complete path because it’s very likely that the next time the user logs on, he or she will have a different temp folder.

The temporary folder mapping feature can be disabled using the FLATTEMP command or through Terminal Services configuration. When this feature is disabled, the special subfolder is not automatically created and the contents of the user’s TEMP folder are not automatically deleted when the user logs off. I do not recommend disabling this feature.

In order to ensure a smooth upgrade path from Windows NT 4.0, Terminal Server Edition (TSE) and Windows 2000 Terminal Services to Windows Server 2003 Terminal Services, certain legacy application support features had to be retained and supported. These are root drive mapping support and application compatibility scripts, both of which were well-used in the majority of the TSE implementations, saw diminished use in Windows 2000, and now are, for the most part, relegated to backwards compatibility status in a Windows Server 2003 environment.

While neither one of these features are necessary for the majority of new Windows 2000 or 2003 implementations, if you are tasked with supporting an environment that was upgraded from TSE, or are involved in a project to migrate an existing TSE environment, then I feel that it is important to have a clear understanding of how these two support features function so that you will better understand the roles that they serve and what requirements must be considered when migrating or supporting such an infrastructure.

HOMEDRIVE=U:
HOMEPATH=
HOMESHARE=\FileSrvUsers	wmathers

HOMEDRIVE=U:
HOMEPATH=	wmathers

%SystemRoot%Application Compatibility Scriptschkroot.cmd

    Set RootDrive=W:

    Subst W: U:users	wmathers

To help resolve issues that applications might have when trying to run on Terminal Server, particularly an NT 4.0 Terminal Server, Microsoft developed an intricate group of batch scripts called application compatibility scripts (ACSs). These scripts are used to perform any necessary file and registry modifications in order to allow an application to function properly on Terminal Server.

Most of the files that collectively make up the ACS are located in the folder %SystemRoot%Application Compatibility Scripts. The main batch script, which is called by every user who logs on to Terminal Server (whether remotely or from the console), is located in the System32 folder and is called USRLOGON.CMD.

The ACS has three main functions:

Typically, application compatibility scripts are invoked by an administrator the first time an application is installed on the Terminal Server. Not all applications require compatibility scripts, and Microsoft provides only a limited set of scripts for those that do. In certain situations, you may need to define your own compatibility scripts; I provide an example of how this can be done in the “Application Installation Examples” section of this chapter. Before you can develop your own scripts, you need a clear understanding of how the ACS environment operates, and you must know the exact functions of the files that comprise the ACS. Table 21.3 lists and describes the main scripts that make up the ACS environment. The scripts are identical on both Windows 2003 and Windows 2000.

Terminal Server also comes with a set of three “helper” executables used by the compatibility scripts to retrieve and update registry and file information. These helper application names all begin with the AC (application compatibility) prefix. The helper applications are as follows:

Even with a list of all the components that make up the ACS, it’s not necessarily clear how these pieces fit together. The flowchart in Figure 21.7 summarizes how the different application compatibility scripts interact from the main script, UsrLogon.cmd.

Figure 21.7. The process flow for application compatibility scripts during user logon.

Each release of Terminal Server has included a number of application compatibility scripts created by Microsoft to assist in the installation and operation of applications on Terminal Server. Windows 2000 Server includes 31 compatibility scripts, while Windows Server 2003 includes only 3. When Windows 2000 Server was released, compatibility scripts were created for a number of legacy applications including Office 4.3 and Netscape Navigator 3.x. These applications had never been designed with the idea of a multi-user environment such as Terminal Services in mind, so some rather intricate scripting had to be done in order to enable these applications to function. Many of the scripts found in Windows 2000 were direct ports from scripts found in Windows NT Server 4.0, Terminal Server Edition.

With the release of Windows Server 2003, all of these legacy compatibility scripts were thankfully omitted with the exception of only 3. These 3 scripts are:

A small portion of the Outlook 98 installation script is shown below. You will notice is that this script makes use of the %rootdrive% environment variable discussed in the “Root Drive Mapping” section of this chapter. The script begins by checking to see that %rootdrive% has been defined. This is done by calling the ChkRoot.cmd script. If the script fails, this script simply exits without any warning. If the root drive has been defined, the script next verifies that Outlook 98 has been installed by searching the registry using the ACRegL utility.

@Echo Off

Rem ######################################################################
#

Rem
Rem Verify that %RootDrive% has been configured and set it for this
script.
Rem

Call "%SystemRoot%Application Compatibility ScriptsChkRoot.Cmd"
If "%_CHKROOT%" == "FAIL" Goto Done
Call "%SystemRoot%Application Compatibility ScriptsSetPaths.Cmd"
If "%_SETPATHS%" == "FAIL" Goto Done
Rem
######################################################################
#

Rem
Rem Get the installation location of Outlook 98 from the registry.
If
Rem not found, assume Outlook isn't installed and display an error
message.
Rem

..ACRegL %Temp%O98.Cmd O98INST
"HKLMSoftwareMicrosoftOffice8.0CommonInstallRoot" "OfficeBin"
"Stripchar1"
If Not ErrorLevel 1 Goto Cont0
Echo.
Echo Unable to retrieve Outlook 98 installation location from the reg-
istry.
Echo Verify that Outlook 98 has already been installed and run this
script
Echo again.
Echo.
Pause
Goto Done
.
.
.

:SkipWarning

Pause

:done

Even though this script is dependent on the existence of the root drive, if you find that you must create an application compatibility script for an application that you are deploying, you are not required to enable the root drive feature. Instead I would recommend that you simply reference the proper drive letter that you have defined as the home folder for your Terminal Server users.

There is really no practical reason why the root drive functionality needs to be used in a Windows Server 2003 (or even a Windows 2000) Terminal Server environment.

If I had to choose only one utility to assist in the installation and configuration of applications on a Terminal Server, it would be an extremely difficult decision between these two excellent utilities. When it comes to troubleshooting security-related issues with applications running on a Terminal Server, no other utilities come close to SysInternal’s Regmon and Filemon. Best of all, the basic versions of both of these tools are available free from the SysInternals Website (http://wwwsysinternals.com), where besides Regmon and Filemon, a plethora of other tools exist.

No proper installation is required for either product, simply download the appropriate Zip file and extract the single executable into the desired directory. My preference is to save these files into a folder that has been added to the system path so that the files can be launched by opening a command prompt and entering the desired executable name (regmon.exe or filemon.exe). Another option is to create a shortcut on the Windows desktop that points into a folder containing all of the tools that I commonly access. Figure 21.8 shows the main window of the Regmon utility, which is very similar in appearance to the main window of the Filemon utility.

Figure 21.8. The main windows for the Regmon and Filemon utilities are nearly identical.

When either tool is first opened it will immediately begin to log all file or registry access and very quickly tracks thousands of log entries. Sifting through so much log data in an attempt to troubleshoot a problem is neither time-effective nor likely to be very successful. Sysinternals provides some simple configuration options to help narrow down the scope of information being tracked and displayed. These settings are managed through a combination of toolbar (or hot-key) and menu selections. The options along the toolbar are:

One option specific to Regmon is the Log Boot setting under the Options menu. When checked, this configure Regmon to log registry access during the system startup. This can provide valuable assistance in troubleshooting a problem during the startup of your Terminal Server.

Filemon also has some settings that are not found in Regmon. The Volume menu option in Filemon allows you to specify what drive volumes are monitored as well as alternate file sources such as mailslots and named pipes.

I will provide an example of the use of Regmon when discussing the installation of Infor Global Solutions’ Invue product in the “Application Installation Examples” section of this chapter.

Windows 2000 Server and Windows Server 2003 each have their respective set of resource kit tools available for download free from the Microsoft Website (www.microsoft.com). The resource kit tools were developed by Microsoft and their partners to assist in streamlining the support of a Windows server environment. Tools such as Lsview.exe, the Terminal Services License Server Viewer, have been designed specifically for Terminal Server environments, while other tools provide more generic functionality to an administrator.

After downloading the resource kit (or an individual tool), a very simple installation wizard will walk you through the actual installation steps. During installation, unless an alternate installation location is selected, the resource kit tools will go into the folder C:Program FilesWindows Resource KitsTools.

The installation will then automatically update the system path to include a reference to this folder, allowing you or any authorized user the ability to execute a resource kit command from a command prompt without requiring the full path to where the tools reside.

One resource kit tool that I use quite often when creating simple application-related scripts is the IfMember utility, which determines whether the current user is a member of one or more user groups. IfMember is commonly used to direct process flow in a batch script, and can be useful to an application integrator when scripting changes that must be applied to only certain users. The following code sample demonstrates how IfMember might be used to copy a folder of files into a user’s personal U: drive, but only if a user belongs to a certain application group (“APPCustService”). Multiple user groups can be listed, allowing for a single test condition to be satisfied by more than one group membership. Multiple groups are separated by a space and logically OR’d together, so one positive membership match will satisfy the ifmember test.

The use of the IfMember utility as part of an application-specific script is also discussed in the “Application Installation Examples” section of this chapter.

@echo off
ifmember "APPCustService"
if not errorlevel 1 goto quit
xcopy "S:CSConfig*" "U:CSConfig." /s /I /R /Y /Z

:quit

Microsoft also makes available the Office Resource Kit (ORK), a collection of tools designed to aid an administering and deploying Microsoft Office. In particular, there are four components of the ORK that are of particular interest to a Terminal Server application integrator:

I’ve always felt that one of the most useful skills that an application integrator, (or a Windows administrator in general) can have is the ability to create basic Windows command line scripts. Whether it is copying files to a user’s home folder or ensuring a required drive letter is mapped, not being able to automate these tasks with scripting can leave the administrator with few options other than manually making the necessary adjustments for each user or educating the users on how to do it themselves. While this type of solution does work, I find that it is neither very elegant, nor very time (and cost) effective to the user or the administrator.

Repetitive user intervention increases the likelihood of error and a subsequent support call. A basic understanding of scripting does not require an in depth knowledge of application development. A number of resources exist that provide excellent learning tools for those administrators that may need to brush up on their scripting. Many online resources exist including Microsoft’s own scripting site, http://www.microsoft.com/script and the excellent scripting community site, the MSN Windows-Script group (http://groups.msn.com/windowsscript). Articles and information can be found to satisfy all skill levels, including webcasts that are put on periodically that are geared specifically to novice scripters.

Many of you will find that you can quickly get up to speed simply by investing a few hours in playing around with some basic scripting in a test environment. Once you understand the basics you will be able to perform many of the tasks commonly relegated to scripts, and you’ll wonder how you ever managed to administer an environment without it.

Since the release of Office 2000, Microsoft’s flagship product has natively supported running in a Terminal Services environment, although it is only since Office XP that the product has seamlessly supported installation on a Terminal Server with no special configuration required by an administrator.

The installation of Office 2003 is very straightforward on a Terminal Server and is performed as follows:

Before users begin to log onto your Terminal Server and work with Office, it is a good idea to configure the desired Office administrative policies in your Active Directory, establishing the desired default configuration from the very beginning. Details on the setup and creation of group policies were discussed in Chapter 15.

Almost at the completely opposite end of the application spectrum are legacy applications that require some post-installation “tweaking” in order to behave properly in a Terminal Server environment. A nice example of this is the Invue 4.0 Advanced Terminal Emulation software. A product circa 1999 that was created in order to provide an advanced terminal interface to SHIM, Trend and the WDS-II host systems, are all products from NxTrend Technology. While the software is certainly legacy, many customers still access systems such as Trend on IBM RS/6000 hardware, and of course still require access via software such as Invue.

When deploying legacy software on a Terminal Server there are a couple of points to keep in mind:

The installation steps for the Invue application, like most other Windows applications follow the standard installation wizard. After completing the installation some basic testing as an administrator indicates that everything is functioning normally, but as soon as an attempt is made to launch the application as a regular user, an error message appears stating that the application “Failed to update the system registry.” Clicking OK terminates the message and the application starts but obviously such an error is not acceptable for the end-user.

Considering that the application functioned properly as an administrator but not as a regular user immediately raises the alert that it is permission related, and considering that the message states the registry, it is apparent that the Regmon tool is required.

Ideally you will want to run Regmon on a server that has no active users so that you can easily isolate the issue with only one instance of the offending application. For this test we will assume that there is only the test user running Invue.

I start by launching Regmon from within an administrator’s session, immediately stop capturing data, and then configure the filter to capture data only originating from the Invue application. The executable is Invue40, so the Regmon filter would look as shown in Figure 21.12. As you can see I have entered “Invue40*”. I’ve included the wildcard so that I capture all instances of the Invue executable running on the server. Because I don’t know yet what the process ID is for the user when he or she runs the application, I can’t narrow it down any further.

Figure 21.12. Regmon filtering allows you to specify a wildcard when filtering on an executable name.

Making sure that Regmon is once again capturing, I log on as the test user account and launch Invue. Immediately Regmon begins to capture all registry traffic from the Invue program. As soon as the registry error appears in the client session I halt capturing in the Regmon tool. There is no need to keep capturing data now. We already have what we need in the log.

From the top of the Regmon log file I perform a search for the text ACCDENIED, the telltale sign that the user did not have sufficient privileges to perform an action on the registry. Immediately I find three hits pertaining to the properties for a key called Joystick. This is a common ACCDENIED entry and can be ignored. This is not the source of the problem.

The next hit is for the subkey Pixel under HKLMSoftware. This seems much more likely, since the About Window in Invue mentions Pixel Innovations. These entries are noted and I continue searching the log. The next entry is under HKCRSession.Settings. This is also likely so it too is noted.

Another match is found pertaining to a CLSID entry. Security issues are common with legacy applications attempting to access CLSID entries, so this too is noted. This turns out to be the last match, so I find that there are 3 registry keys that are likely causing the error message in the application to appear. The registry entries are:

This example clearly demonstrates how involved the process of troubleshooting a permission issue can be, but also how helpful a tool such as Regmon is in tracking down and resolving these types of problems.

Once these registry corrections were made, the pair of test users were able to log on and use this new application. Everything appears to be going well until it is determined that the users are unable to save the changes that they have made to their terminal sessions—changes such as font and background color changes, as well as customized macros. In some environments, administrators would not want their users modifying the default configuration, but in others the administrators may be less strict. Assuming that we’re going to allow the users to save their Invue changes, we need to figure out a solution.

After some quick investigation it is determined that the default Invue configuration has all users accessing the same session file located in the folder containing the Invue executable. This introduces two problems. The first is that the file is located in a folder where users do not have write access; and second, even if they did, all users would share the same file, likely resulting some other kind of contention issue, or at the very least a situation were one user could easily overwrite changes made by another user.

A solution is devised where each user will keep their own personal copy of the default session file in their home folder. Invue is then configured to read that file using the home drive letter mapping. For example, if U: maps to each user’s personal home folder, then we could configure Invue to read from the U:InvueData folder.

The final piece to this puzzle is ensuring that each user has a copy of these default files in their personal U:InvueData folder. The easiest way to do this is using a Windows script that checks for the existence of those files, and if they don’t exist then copies them over to the user’s U: drive. If they do exist, then we do nothing so that we don’t accidentally overwrite any personal settings the user may have.

This script could be implemented as part of a logon script, but because it is required only on a Terminal Server, it actually makes more sense to configure it as an application compatibility script. The script in question looks as follows:

@ECHO OFF
REM This script configures Invue for everyone so that they can manage
their
REM own session files and save personal preferences
REM When users launch Invue they are accessing session files in their
own
REM personal home folder, in the "U:InvueData" subfolder.

REM Begin by verifying group membership
IfMember "APP_Invue"
if not errorlevel 1 goto END

REM Now see if the folder already exists on the U: drive
U:
cd
if exist "InvueData" goto END

REM Does not exist, so let's copy over the folder from the D: drive
xcopy "D:InvueData*" "U:InvueData." /s /I /R /Y /Z

:END

The actual script is copied into the %WINDIR% Application Compatibility ScriptsLogon folder, since we want this script to run for every user as they log onto the Terminal Server, but only if they belong to the group APP_Invue. You can see within this script that I have also used the IfMember script to verify group membership before attempting to copy the files.

In order for this script to run during the user’s logon, we must configure it to do so. This requires adding an entry to the Usrlogn1.cmd batch script located in the %SystemRoot%System32 folder. If the file does not exist it must be created. For a new file the contents would look as follows:

REM This batch script processes application compatibility scripts
that
REM do not require the existence of a RootDrive mapping. There should
be
REM no reason why the root drive feature should be enabled on a W2K3
Terminal Server.

REM Process the Invue application setup.
call Invue.cmd

When a user logs on, the Usrlogon.cmd file is run. This in turn launches the Usrlogn1.cmd file, which finally launches the custom Invue.cmd file, whose responsibility it is to ensure that the user’s session is prepared to run Invue.

With the implementation of this script, the installation of the Invue application is complete.

The final application that we will discuss involves the deployment of custom-developed client-server applications on Terminal Server. For the most part, the deployment of a custom application is somewhere between a typical legacy application and the most current Windows applications. Development environments such as Microsoft Visual Studio provide robust application packaging and deployment tools that allow a developer to create a self-contained set of installation files that can be used to deploy the application on Terminal Server.

While the number of issues is typically minor, there are some that I have encountered on more than one occasion. Issues such as:

All of these types of issues are preventable simply by properly educating the development team to the requirements of the environment that they are developing for. In my experience a brief phone call is not enough. Detailed boundaries within which the developers must comply is key to ensuring a successful application build the first time, eliminating the need for the development team to go back and correct the deficiencies.

NOTE:

One installation note worth mentioning has to do with the configuration of a data source entry for accessing a database management system such as SQL Server or Sybase. A common question that I am asked is what type of database data source name (DSN) should be created? Should it be a User DSN, a System DSN, or a File DSN? When creating a DSN for a custom application, the appropriate type in most cases is a System DSN as shown in Figure 21.13. System DSNs are globally accessible by all users on a Terminal Server.

Figure 21.13. Custom applications that require a DSN entry, usually require a System DSN.