Deploy applications using Terminal Services

You can find instructions on how to install and use terminal services on the Internet and in local bookstores. However, most of them provide users with unknown benefits for remote applications. With only a few operations, you can quickly deploy a terminal server that hosts the required applications in your environment. However, to meet user expectations, you must consider other situations.

If you are a terminal server administrator, you need to consider the following points by setting aside the remote application infrastructure: How do you plan to deploy the application? Do you want to provide users with remote desktop or TS RemoteApps? How do users access their applications through static Remote Desktop Protocol (RDP) files, Web pages, or Desktop shortcuts?

Finally, how can we evaluate the user experience when using terminal service applications? Since terminal services have been improved in Windows Server 2008, the best answers to these important questions may surprise you.

Say goodbye to desktops and welcome RemoteApps

With a group of important services and function extensions, Windows Server 2008 solves many problems in terminal service management. In TechNet magazine in November 2008, we discussed its new and improved features, at that time, Joshua Schnoll gave a detailed description of the various new features that can be achieved by switching to Windows Server 2008 through enhanced Terminal Services to demonstrate virtualization ). Among these functions, the most important thing is that the terminal server does not have to deploy a complete desktop for the user. Now, you can deploy a single application.

These individual applications are called TS RemoteApps. for users, these applications are just as directly installed on the user's local desktop. When you click to start a RemoteApp, you can only view the app on the local computer. There is no additional "start" menu bar or dual desktop, so that you can easily interact with non-local systems. Judging from the implementation and user expectations, TS RemoteApp may be more advantageous than deploying a complete desktop because it can make these applications look like a part of a normal local desktop experience.

In Windows Server 2008, it is very easy to create a new TS RemoteApp on the "TS RemoteApp Manager" TS RemoteApp Manager in "Administrative Tools. Click the "Add RemoteApp Programs" link in the "Actions" Operation) pane to start the "RemoteApp Wizard" RemoteApp Wizard. This Wizard can query the Windows Management Instrumentation (WMI) of the terminal server) to determine the list of potential applications installed on the server. An Example 1 in this list is shown.

Figure 1 "RemoteApp wizard" enumeration of installed applications on the Terminal Server

Select the application you want to create as RemoteApps from the list, and click "Next" Next ). If the application does not contain the required application, click "Browse" to Browse) to locate the main EXE file. The main EXE file is usually used to start the application. After the Wizard is complete, you can start to deploy your remote application.

If you right-click to view the properties of the new RemoteApp, you will find several options to adjust. In addition to the name, position, icon, and alias information, you can also enter command line parameters. This is very convenient for applications that require a set of parameters to run properly at startup. In addition, it can be used together with some applications to create connections to remote content.

Many administrators may not immediately realize that transferring to TS RemoteApps does not only mean that applications can be displayed on the user's screen. With some tips, you can also use RemoteApps to automatically start pre-configuration content.

For example, assume that you want to deploy a specific document instead of an application. You may not want to create a RemoteApp that links a user to a blank application, such as Microsoft Office Word or Access. For example, you want to link a user to a specific Word document or Access database. In this case, you can enter the document name as a parameter after the main EXE of the application. Therefore, if you want to create a PTO paid vacation based on Access 2007) database connection, the database is stored in \ fileServer \ fileShare \ CompanyPTO. in accdb), you only need to create a new RemoteApp named "PTO Database" and enter the location of this document as the command line parameter. Now, when you double-click to start the PTO Database application, it will automatically connect to Access and pre-load the correct Database.

As you can see, creating a connection to remote content is another way to expand the practicality of RemoteApps. However, for all RemoteApps, you must connect to the icon to start the operation. In subsequent sections, I will discuss several methods to use Terminal Services to complete these tasks in Windows Server 2008.

Start an application from the Web

The new TS Web Access role service allows you to host application shortcuts on pre-configured Web pages. This role service will be integrated with the terminal server in the environment to provide users with a location where they can find and start their applications. Figure 2 shows the appearance of the webpage to the user.

Figure 2 TS Web Access page enumeration of deployed RemoteApps

To create such a webpage, you can install the TS Web Access role on an existing IIS server, then, add the computer account of the TS Web Access Server to the Global Group of TS Web Access Computers in the domain ). Note that in some small environments, you can install TS Web Access on an existing Terminal Server to implement a single server solution.

After the RemoteApp is installed, you can right-click the configured RemoteApp in the "TS RemoteApp Manager" TS RemoteApp Manager, and select "Show" in TS Web Access to enable it. Users who use Remote Desktop client 6.1 or later can then navigate to http: // serverName/ts to view the list of application shortcuts. Clicking any shortcut will automatically start the RemoteApp.

TS Web Access is a very simple method that provides a friendly interface for searching and starting applications. This is useful if the application or version is changed regularly. Updating a website only involves hiding links to old applications or versions in TS Web Access, then, the new link is displayed after the new application or version is installed.

However, this tool also has some restrictions. First, there is no built-in mechanism to restrict applications that users can access. Each authenticated user can see all the remoteapps created on the terminal server and set as visible in TS Web Access.

The second problem is related to the application processing method that users usually use. When you start an application such as Word, do you often start it by clicking the shortcut of the application? I bet there won't be too many times. It is possible to double-click an existing Word document to start the application and pre-load the document.

Unfortunately, TS Web Access does not support this method of starting an application. For users who are used to double-clicking documents to start associated applications, TS Web Access may not be a satisfactory solution. But don't worry. Next we will discuss another more useful option for this situation.

Start the application from the desktop

For users who want to start the application by double-clicking the document, Terminal Service now provides the function of "installing" The Remote Application link to the desktop. In this process, the RDP file of RemoteApp can be effectively encapsulated into an MSI file of the Windows Installer package, and then installed on the Environment desktop.

In addition, the installed MSI can modify the file extension Association on the desktop to re-route the double-click File to the RemoteApp associated with the terminal server. Figure 3 shows the modifications made to the file extension association after the Word RemoteApp is installed on the client system. In this case, double-click any common Word file extension name to start Word through "Remote Desktop Connection.

Figure 3 modify the file extension Association to start Remote Desktop Connection

To create a Windows Installer package from an existing RemoteApp, first navigate to "TS RemoteApp Manager" TS RemoteApp Manager ). Right-click the target RemoteApp and choose "Create Windows Installer Package" to Create a Windows Installer Package ). By default, all created Windows Installer packages are stored in C: \ Program Files \ Packaged Programs, but you can change this location using the RemoteApp wizard. In the wizard, you can also configure the name and port of the server hosting the RemoteApp, as well as server authentication, certificate settings, and TS gateway settings.

Settings 4 related to application location after installing to the candidate desktop are shown in. As you can see, shortcuts can be created not only on the desktop, but also somewhere in the "Start" menu folder. The most important check box on this screen is the check box at the bottom of the screen. This check box is used to "replace" the client settings. It will re-associate all file extensions of the RemoteApp from the local desktop to the terminal server. To enable users to start their TS-hosted applications by double-clicking the document, select this check box. Click "Next" Next) and "Finish" to end the wizard.

Figure 4 Create a Windows Installer package to enable Association of client file extensions

Obviously, the advantage of using desktop installation to connect a user to an application is that it does not need to change user behavior. After the application is installed, you can start the application by double-clicking the document as before.

However, this method also has drawbacks, that is, it needs to perform additional desktop management work. Each RemoteApp used in this way must be installed on each desktop to be accessed. Although this process can be simplified later through "Group Policy software installation"), it still increases the management burden. In addition, when the application changes, it is very likely that the RemoteApps installed on each desktop also need to be updated.

After creating a Windows Installer package, it is not complicated to install the package through "Group Policy software installation. First, create a file share that can be accessed by the Group Policy. The ideal location for file sharing in a single Terminal Server solution may be the default C: \ Program Files \ Packaged Programs folder on the terminal server. Make sure that appropriate permissions have been assigned to the folder and share so that the client can access the share during the "Group Policy" process. Then, create a new group policy object (GPO) and navigate to "Computer Configuration" Computer Configuration) Policies | keep "Policies" Policies) Policies | keep "Software Settings" Software Settings) installing | installing "Software installation" Software ). Right-click "Software installation" Software installation), and select "New" to create) packages | packages "Package ). In the displayed dialog box, locate the MSI file created for RemoteApp. Select "Advanced" when asking about the deployment method ).

In this case, you can select. The RemoteApps installer is very small. Only the RDP Files and icons are installed in the C: \ Program Files \ RemotePackages folder, therefore, you may want to select this option to "Uninstall" the application when it exceeds the management scope. After this option is selected, the RemoteApp will automatically remove the GPO from the computer each time the GPO is deleted or the computer is moved to a new OU that is no longer applicable to the GPO. Enabling this option simplifies the RemoteApp removal process when computers and applications move in or out of the management scope.

 

User Experience

Application Deployment through any of these mechanisms is excellent, but terminal service management is not limited to creating and deploying applications. It is equally important to ensure that your implementation meets your needs. In any discussion about application delivery, it is critical to consider subjective performance indicators to capture the quality of user experience. Although it is difficult to use hard indicators for quantification, effective Terminal Service deployment must consider the overall user satisfaction as a measure of the definition success.

For example, in some cases, users may feel very troublesome, especially when multiple people share resources on the same server. When using Terminal Services, multiple users need to share the applications installed on the server on a single server. Combining a large number of users to a few servers can reduce the number of applications and simplify application management. The fewer applications to be managed, the fewer Patches required, the easier the environment to control, and the fewer management difficulties.

This integration requires the terminal server administrator to assume the role of system maintainer. Experienced administrators can manage Terminal Server farms by observing users' behaviors in the system and actively formulating countermeasures. Through reconfiguration and lock prevention, you can ensure that the improper behavior of a single user does not affect the experience of other users.

For example, experienced terminal server administrators configure performance alarms to be notified when processor utilization increases and remains very high. This behavior usually indicates that a process occupies the processor exclusively, or a user-initiated Operation occupies too many resources in the shared system. Tracking and ending such malicious processes is only the first step in solving such incidents. Finding out the cause of such a process is a long-term solution to this problem.

In this case, make sure that the Remote Application can be executed at least as on the local desktop. The "Important terminal service performance counters" tab displays the PerfMon metrics that help you understand performance.

RemoteApps = predictable performance

RemoteApp is a valid Terminal Service session. The width and height of the session are the same as those of the application to be started. The result is that the Remote Application looks like a local application, because the session boundary is never extended beyond the application's own boundary.

RemoteApps implemented by Microsoft is actually much more intelligent than previously described. From the perspective of the resources required to start and run, the deployed RemoteApp is different from the deployed full desktop. To start a remote desktop, you must use the assumer.exe instance to operate the desktop shell program and all the processes configured to start with assumer.exe, for example, a system tray application, a help application, or any service or process started with a standard desktop.

In contrast, the launch of the RemoteApp does not require a complete assumer.exe shell or all the add-ons. In fact, RemoteApp uses two other processes, rdpshell.exe and rdpinit.exe, to replace assumer.exe. The two simplified processes will be used as an alternative shell and shell to log on to the application and run the program to start the RemoteApp.

Figure 5 shows a simplified example of the Terminal Server, where two users connect and start the calculator application. User1 logs on through the complete desktop, while User2 connects to the pre-created RemoteApp instance calc.exe. Although you will find that User2 requires more processes to start calc RemoteApp, the total memory used by these processes is less than the memory used by User1's resource manager shell, 6.

Figure 5 the Task Manager displays the differences between the resources used by the desktop and RemoteApps.

Figure 6 memory usage example

Running Process	User1-complete Desktop	User2-RemoteApp
Assumer.exe	7064KB	Not applicable
Tasking.exe	1792KB	1704KB
Dwm.exe	588KB	516KB
Rdpclip.exe	1032KB	908KB
Calc.exe	648KB	716KB
Rdpinit.exe	Not applicable	860KB
Rdpshell.exe	Not applicable	828KB
Total	11124 K	5532KB

This reduction in RAM consumption is only part of the Performance Discussion. In addition, the impact of user behavior on processor usage must be considered. After you deploy a complete desktop for a user, the user will be able to run all installed applications on the terminal server.

Without proper locking prevention, lightweight users who use Terminal Services to write documents in Word can turn to heavyweight users at any time by starting another application with more powerful functions and requiring more resources. The unpredictability of such behavior makes it extremely challenging to plan resources for each user. It also makes the management of the Terminal Server more complex, thus increasing the possibility of affecting the experience of other users due to the behavior of a single user.

Internet Explorer may be the best example of this unpredictability. This application is installed on every instance of Windows Server, and running it usually does not require too many resources. However, when Internet Explorer is used to present a website that requires many plug-ins and is poorly written, its resource usage increases significantly. If a user accidentally runs Internet Explorer in a desktop session, the available resources on the terminal server may be accidentally exhausted, resulting in lower program performance for other users.

Compared with the full desktop, the structure of RemoteApps is more predictable in terms of resource usage. Users who start RemoteApp can only use specific applications and other applications associated with the initial application. Therefore, it is easier to predict user behavior in terms of performance.

You can choose

The ultimate goal of this article is to help you understand the options you can select when deploying remote applications for users. In Windows Server 2008, its terminal service has new features that can provide users with multiple ways to connect to applications. A combination of desktop hosting and Web hosting, coupled with a comparison of the complete desktop and RemoteApp, will be able to provide the correct configuration for your special environment.

Important terminal service performance counters

Although user experience measurement is usually a subjective activity that involves personal perception rather than objective indicators, there are also some very useful performance counters, its measurement indicators can help you determine the performance of the terminal server, which will affect user satisfaction. You shall consider measuring the following counters on the terminal server:

Memory \ Available MBytes

If this counter is reduced to a very small value, it indicates that the process on the terminal server is consuming most of the available physical memory. Although a lower value may not be good, when it appears together with a higher number of threads and a higher number of pages/sec, A lower value may indicate that too many users are trying to execute too many tasks on a server.

Memory \ Pages/Sec

This counter is related to the speed at which the disk reads data from the memory or writes data from the memory to the disk. If the High Count value and the low Available MBytes Count value appear at the same time, it may indicate that the Available memory is insufficient and the server cannot load tasks, resulting in poor user experience.

Processor \ % Processor Time

This counter clearly shows the number of processors in use for productive work. You should pay close attention to this metric, especially in a multi-processor system, because it can indicate a processor in the suspended or peak state.

System \ Threads

Each process running on the server is composed of multiple threads. The Threads counter is an integer that represents the sum of all processes on the system. The terminal server usually has a high thread and process count, because many users use system resources at the same time. When this Count value is high, there is reason to assume that a large number of activities are trying to execute simultaneously on the server. A high thread count usually leads to a high Context Switches count, because the server will try to handle the needs of each process.

System \ Context Switches/Sec

"Context Switch" Context Switch) occurs every time the processor changes its current processing thread. Each context switch produces a slight load, so a high count here is accompanied by a high thread count) may indicate that many users are attempting to execute a large number of tasks at the same time.

System \ Processor Queue Length

When the processor cannot bear all the load, the request starts to queue. The counter used for this Queue is called Processor Queue Length. When the value of this counter is very high, it can be assumed that the server's processor cannot process all requests, which may also affect the user experience.

Terminal Services \ Active Sessions and Terminal Services \ Total Sessions

These two indicators help to efficiently assess the resource usage relative to the number of users working on the terminal server. The first counter measures the users who are processing sessions, and the second counter measures the users who are in idle or disconnected state. Combining these two counters with other counters will help determine the maximum number of users that can be processed before your server is overloaded and affects user experience.

The actual quantity you see depends on your hardware composition, installed applications, and the number and type of users in the system. Therefore, a precise value as a threshold may be misunderstood. On the contrary, when your indicators differ greatly from normal operations, you should check the changes in your own quantity or time, and use it as the first-hand information to determine when the user experience gets worse.

Windows Server 2008: New and improved features) published by SAPIEN press. You can contact Greg through www.ConcentratedTech.com.

Greg Shields is an MVP and co-founder and IT expert of Concentrated Technology. His New book Windows Server 2008: What's New/What's Changed

Original article address

Source: TechNet