Certification Objective 8.02: Configuring Applications for Use in a MetaFrame Environment
|
| < Free Open Study > |
|
After the application is installed, you have to configure the application to make it available to the end user and to make it function properly in this environment. In this section, you will first learn how to 'publish' the application and then how to correct certain application problems unique to this environment.
One of the most challenging aspects of MetaFrame XP administration is to get badly written legacy applications, which were designed to run on a single-user system, working properly in a multiuser environment. Fortunately, there are a number of tools available to make this possible. These tools fall into two broad categories, debugging tools to find out what's wrong, and configuration tools to fix the problems.
Publishing Applications
In order to load-balance an application, or make an application available to a Program Neighborhood or NFuse client, the application must be published. Publishing an application allows an administrator to control user access, determine minimum client requirements, configure application settings, set required encryption levels, and choose which server the application is load-balanced on.
Applications are published and managed using the Citrix Management Console's Applications node. Within this node you can change, add, delete, or copy published applications within the MetaFrame XP farm.
To publish an application in the MetaFrame farm, right-click the Applications node in the Citrix Management Console and select publish application. You will then be presented with the Application Publishing Wizard, which will walk you though your configuration. (See Figure 8-10.) The wizard will prompt you for information pertaining to the applications configuration. Table 8-2 lists the information required when publishing an application.
Figure 8-10: The Application Publishing Wizard
| Field Name | Description |
|---|---|
| Display Name (required) | Published Application name that clients will see when using NFuse and Program Neighborhood, or when browsing for Citrix published applications. |
| Application Description | Detailed description of the application being published. |
| Published Application Command Line & Working Directory (required if not publishing a desktop) | Command line executable and working directory for the application. The executable listed will launch when a user selects that application. |
| Published Desktop (radio button) | Used to publish a load-balanced desktop instead of a specific executable. |
| Program Neighborhood Folder | Used for Program Neighborhood and NFuse clients. Will create a folder in the Program Neighborhood interface for sorting applications. |
| Application Shortcut Placement (Start Menu and Desktop) | Allows an administrator to put an icon for the application on the user's Start menu or on their desktop. (Win32 Program Neighborhood clients only) |
| Window Size and Colors | Configures minimum settings for application to launch. |
| Audio | Allows an administrator to configure audio to be on or off for the application. This can also be set as a minimum requirement. |
| Encryption | Allows an administrator to configure the encryption level for this application. This can also be set as a minimum requirement. |
| Specify Servers | Allows you to configure which servers will host the application. |
| Specify Users (required unless anonymous connections are used) | Allows the administrator to specify which users or groups have access to that published application. |
One important facet is the ability to publish applications 'anonymously.' While Citrix documentation will lead you to believe that a user can launch applications without authentication, this is not the case. Due to Windows NT and Windows 2000's need to remain C2 security-compliant, it is impossible to launch an application or a session to a Windows server without some type of authentication. So to work around this security, Citrix creates several local anonymous user accounts during the installation of MetaFrame. When a connection to an anonymous application is launched, the server will use one of the local anonymous accounts to authenticate the user (see Figure 8-11). So, while the user is not required to 'log in' with their own credentials, they are still being authenticated using these local accounts. This type of application is often used with programs that have their own authentication built in, with no need for domain resources.
Figure 8-11: Local Computer Management, Local Anonymous Users
While this may seem like a very convenient way to publish applications it does have a couple of drawbacks:
-
No access to domain resources. Since the accounts used to authenticate are local to the server, they do not have access to domain resources.
-
User-specific application information normally stored in the user's profile is not unique to each user. Since a user never knows which local account they are using, their applications settings are lost at logoff.
Because of both of these drawbacks, applications like Microsoft Outlook, which requires both domain resources and user profile settings, do not lend themselves well to anonymous publishing.
| On The Job | In certain situations, you may find you wish to publish an application anonymously, but wish the anonymous connection to have access to a Windows shared folder. This was common with older database applications that used a flat database like DB3 or FoxPro. In this case, all the anonymous connection may require is a mapped drive to a network share point. This can still be accomplished, though it does pose some security risk. By placing a Net Use command in a script that runs at login, these anon accounts can accomplish this. You will need to create a domain account with access to the share you want to map to, then use this account in the command line that follows. |
NET USE X: \\Servername\Sharename /user:Domainname\username password
Placing this command in the USRLOGN2.CMD in the %systemroot%\system32, or any files that it calls will map this drive for everyone connecting to that server (anonymous or not). The /user switch will authenticate to the share using the credentials that follow it. Replace Domainname with your domain name. Username should be replaced with the account name you created, and password should be replaced with the password for the generated account.
Exercise 8-2: Publishing Microsoft Word 2000
 |
-
Log on to your server as Administrator.
-
Log on to the Citrix Management Console.
-
Right-click the Applications node and select Publish Application.
-
Name the application word test.
-
Using the Browse button, browse to winword.exe, where you installed Office. The default is Program Files\Microsoft Office\Office\winword.exe.
-
The working directory should default to the proper directory. Click Next.
-
Select Add Shortcut To Client's Desktop. Click Next.
-
Select Maximize application at startup. Click Next.
-
Add your server to the list of configured servers. Click Next.
-
Add domain users into the list of configured users. Click Finish.
|
| Exam Watch | The exam is sure to test your knowledge of publishing applications. Make sure you know which utility to use and the available options. |
Debugging Tools
Finding out why an application is generating dumps is generally a logical progression comprised of the following steps:
-
Monitor file system level activity by the application. What DLLs, INI files, and temporary scratch areas are being accessed; are there any access denied errors?
-
Monitor registry access by the application. Are there any missing registry settings, or access denied errors? Are the value settings logical?
|
Teaching students how to use Filemon from www.sysinternals.com is extremely simple, but often overlooked during class. I have found that one of the easiest ways to teach this utility is done after installing Microsoft Office. When installation is complete, I remove Domain Users from the permissions list on the MS09.DLL in the Office directory. Then, as an Admin, I log in and use Word and Excel. The students then log in using standard domain user accounts and try to run the same applications.
Once the application fails, I have them run Filemon while launching the application, afterward viewing the results to find the Access Denied on the MS09.DLL.
-Ron Oglesby MCSE, CCEA, CCI, CSA
|
Optimizing Application Performance
Optimizing application performance means something special on multiuser systems. Normally, the intention is to tune systems and applications to run as fast as possible, but on multiuser systems, the strategy has to change, tuning applications so they run adequately for as many users as possible.
An additional factor to consider when tuning is that in NT 4.0 TSE and Windows 2000 terminal services, the operating system is application-aware. If an application uses the system message queue too heavily, it can be flagged as a 'bad' application and will typically run much slower than normal. Once this happens, you will have to tune the application to make it run at an acceptable speed.
Application Compatibility Settings
Some applications have special requirements to enable them to work properly on MetaFrame XP. These requirements may include memory size restriction, CPU usage modification, special handling of INI files, and system naming modifications. One method of modifying application behavior is to use application compatibility flags and values.
These are located under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\Applications. Three CPU utilization settings exist: FirstCountMsgQPeeksSleepBadApp, MsgQBadAppSleepTimeInMillisec, and NthCountMsgQPeeksSleepBadApp, as well as a flags value that is the sum of the wanted application compatibility flags.
To 'register' an application and begin with default compatibility settings, create a new key under the Applications key using the application name. For example, for Prowin32.exe, create a key named PROWIN32. A good starting point is to copy the values under the MSACCESS key. The resulting key is shown next.
Tuning CPU Utilization
Copying the MSACESS key values for your application gives you a starting point for bad application tuning. The basic strategy in tuning a bad application, after creating the application key and settings, is to define a time-measurable task for the application, run up Performance Monitor and then modify the application compatibility values. The new values take effect immediately on restarting the application, so the tuning process is quite fast. Measure the task completion time versus CPU utilization for each new setting.
The idea is to get acceptable performance with the least amount of impact to the CPU. The best strategy is to start by setting MsgQBadAppSleepTimeInMillisec to 0. This allows the application to run with no restrictions. If it doesn't run any faster, your slow speed problem is due to something else. If it does run faster, then the next step is to set MsgQBadAppSleepTimeInMillisec back to 1, and slowly increase the FirstCountMsgQPeeksSleepBadApp value until the times are acceptable.
More detailed information on application compatibility settings is provided in Table 8-3 and Table 8-4 that follow.
| Value Name | Description |
|---|---|
| FirstCountMsgQPeeksSleepBadApp | Number of times the application can query the message queue before it is put to sleep. Increase this to make the application faster. |
| MsgQBadAppSleepTimeInMillisec | Number of milliseconds the application is suspended. Setting this to zero turns off bad app detection. |
| NthCountMsgQPeeksSleepBadApp | Number of times the application can query the message queue before it is suspended again. Increase this to make the application faster. |
| Flags | See Table 8-4 that follows. |
| 'Flags' Value (Hex) | Action |
|---|---|
| 0×1 | DOS application |
| 0×2 | OS/2 application |
| 0×4 | Windows 16-bit application |
| 0×8 | Windows 32-bit application |
| 0×10 | Return username instead of computername |
| 0×20 | Return Citrix build number |
| 0×100 | Disable registry mapping for this application |
| 0×400 | Not substitute user Windows directory for %systemroot% directory |
| 0×800 | Limit physical memory reported to app to 32MB |
| 0×1000 | Log object creations to %citrix_compat_logpath% |
| On The Job | There are times when you will be using every tool you can find to reduce the amount of processor used by an application. At such moments, either processor utilization will not decrease, or it will decrease in such a way that the application will slow to a crawl. When this happens, you may have to look at an application change. Most applications can be tuned to work in this environment, but you should be aware that there are applications that will not work correctly, no matter how many tools you throw at them. |
Note: the easiest way to modify the application compatibility values is with the free tool: CMPTMAN.EXE. There are separate NT 4.0 TSE and Windows 2000 versions of this utility available from Citrix. (See Figure 8-12.)
Figure 8-12: The CMPTMAN.EXE user interface
Now that you have a better understanding of how to configure applications, here are some real world problems and their solutions.
| You need to make an application available to any user on your network. The application is sensitive and does not require any per user configuration settings. What is the simplest way to deploy this app so everyone can use it? | Using the Citrix Management Console will publish the application anonymously. |
| In trying to determine why one of your servers has extremely high utilization, you discover that a DOS application is consuming an enormous amount of CPU time. What possible utilities can you use to fix this? | DOSKBD can be used with NT 4.0 Terminal Server. TAME and DPAKBD can be used with Windows 2000. |
Modifying INI File Handling
While the normal execute mode INI file distribution mechanism works very well, there are a number of applications that use personalized INI files that shouldn't be updated. A couple of examples of these are the Lotus Notes client and SAP GUI client. The normal behavior, updating from %systemroot%, can be modified by registering the INI files as exceptions under the key HKLM\Software\Microsoft\Windows NT\CurrentVersion\Terminal Server\Compatibility\IniFiles, with values having the name of the INI file, less extension and data corresponding to the flags, shown next in Table 8-5.
| Flag Value (Hex) | Action |
|---|---|
| 0×4 | Windows 16-bit application. |
| 0×8 | Windows 32-bit application. |
| 0×40 | Synchronize user INI file to system version. |
| 0×80 | Do not substitute user Windows directory. |
Other Application Tuning Tools
DOS applications can use excessive CPU time if the DOS application has uncontrolled keyboard polling. While the application compatibility settings provide a way to tune 16- and 32-bit Windows applications, these will not work effectively for DOS applications. While NTVDM.EXE could be registered as a 'bad' application to control the CPU utilization of misbehaving DOS applications, this would adversely affect all DOS applications on the server. A far more effective way is to use DOSKBD for NT 4.0 TSE, a TSR that can control keyboard polling behavior.
Microsoft does not provide or support any tools such as DOSKBD for controlling DOS applications on Windows 2000. However, DPAKBD (ftp://ftp.citrix.com/utilities/dpakbd.zip) has been used with some success and version 4.0 of TAME (http://www.mindspring.com/~dgthomas/tame.htm) is excellent for managing DOS applications on Windows 2000.
|
| < Free Open Study > |
|
EAN: 2147483647
Pages: 169