Published: February 25, 2008
The goal of this step is to examine each application that is intended to be served through Terminal Services in Windows Server 2008 in order to identify any applications that cannot or should not be used with Terminal Services.
During this step, applications that are within the scope of the project are categorized according to their suitability for delivery in a Terminal Services environment, and this information is recorded in a spreadsheet like the job aid included in Appendix B: “The Application Analysis Job Aid.” At the end of the step, the categorized list should be reviewed with the business since some applications may not be immediately suited to delivery by Terminal Services. Those applications may require some changes in order to remain within the scope of the project. Those changes incur cost and, before embarking upon them, this information should be reviewed with the business so that those additional costs and risks can be understood and the best business decision arrived at.
The applications that remain after this step are subject to further testing and measuring in the next steps so that the servers and server farms can be sized appropriately to host them.
Task 1: Examine Each Application’s Capability to Be Served
There are many issues that can affect whether an application can or should be hosted by a Terminal Services environment in Windows Server 2008. The issues can be divided up as follows:
- Issues that affect the application’s business viability.
- Issues that prevent an application from being served.
- Issues with the application’s behavior that cause problems in a multi-user server.
The data may be gathered from application vendors, Terminal Services community sites, and the application support personnel.
The Application Compatibility Toolkit (ACT), available at https://technet.microsoft.com/en-us/desktopdeployment/bb414773.aspx, can also be used to evaluate an application while it is running on a stand-alone computer for suitability in a Terminal Services environment.
Review each application against the questions below, and record the assessments in the job aid in Appendix B, along with the final determination on the application’s suitability. This will determine which applications may need to be excluded from the project.
Issues That Affect Business Viability
A number of business issues may arise when an application is considered for delivery in a Terminal Services environment. While the application may be technically suitable for presentation virtualization, these issues could prevent its delivery in this environment. For that reason, the following issues are considered first:
- Can the application be licensed to run in a Windows Server 2008 Terminal Services environment? Contact the application vendor for this information.
- Is the application supported on Terminal Services in Windows Server 2008? If the vendor does not support the application in a Terminal Services environment, it may not work correctly, or certain features may not be available. Or the application may still work, but additional testing may be required. A review of the risk of running an unsupported application should also be conducted to see if running the application in Terminal Services is warranted.
- Does serving the applications cause license fees to become too expensive? There are numerous software licensing models. Since every terminal server in a farm has the application installed, does this present any undue financial issues given the licensing structure of the application?
- Are there legal reasons for not serving an application? Can protected data, such as national security or private patient data, be allowed to exist on a server residing outside a country or region’s borders? How about data not allowed off site or off certain computers? Can the data traverse a prohibited or nonprotected area on a network?
- Is the required encryption level within the means of most of the RDC clients? If the RDC clients are not yet at a version that supports the desired encryption level, wait until they are upgraded before deploying the application. Alternatively, the application might be delivered to the clients that are in compliance while leaving the other clients to run the application locally.
Issues That Prevent an Application from Being Served
There may be limitations in the way the application is designed or runs that make it unusable in a Terminal Services environment:
- Can the application run on Terminal Services in Windows Server 2008? An internally developed application may be written to install and run only on earlier operating systems. Verify that the application can run on Terminal Services in Windows Server 2008. If not, use the ACT to see if the application works in a compatibility mode.
Issues with the Application’s Behavior That Cause Problems in a Multi-User Server
At the completion of the project, applications that have been running separately on individual workstations will be run together in a server environment. This requires that they co-exist and run in that environment without interfering with each other. The applications must also behave in a way that does not degrade their scalability and performance in this environment to the point that it is no longer cost effective. The following questions raise the issues that may commonly surface with applications:
- Does the application consume excessive resources or neglect to release them appropriately? An application cannot be allowed to monopolize the CPU, memory, or other shared server resources. For instance, a small memory leak may not present much of a problem on a stand-alone computer, but 50 users concurrently running that same application on a shared server can cause the server to run out of memory very quickly. Monitor memory usage to test for the problem. If discovered, have the software’s creator fix the issue and evaluate the risk of running the application while it still leaks.
- Does the application require access to client-based resources that may not be available to Windows Server? Client-side devices such as scanners, specialty printers, USB devices, and floppy or hard disk drives used by the application need to be checked for compatibility in a Terminal Services environment. A determination must be made as to whether these can be provided in the Terminal Services environment.
- Does the application follow proper installation and uninstallation standards? Applications need to be functional for all users after installation, and uninstalls must not remove components needed by other applications on the terminal server. The ACT tools can help determine setup issues. If any are found, determine the impact to the server and users.
Does the application alter shared system files and components? An application that is changing files such as fonts, dynamic link libraries (DLLs), and drivers affects other applications’ ability to function. Use the ACT to watch for this behavior. If detected, the software must be fixed before the application can be used in Terminal Services.
Alternatively, it may be possible to use Microsoft SoftGrid Application Virtualization to overcome this by running each application in its own virtual environment on the terminal server. In this case, the application must be supported for delivery by Microsoft SoftGrid Application Virtualization, and a Microsoft SoftGrid Application Virtualization environment will need to be instantiated.
Note At the time of writing, Microsoft SoftGrid Application Virtualization does not support 64-bit environments.
- Is user data kept discrete from other data? If an application places user and temporary files in the same location, then other instances of the application can overwrite or alter the files, producing unpredictable results. Test to see if this is occurring. If so, it must be fixed before using the application in Terminal Services.
- Is the registry accessed properly? An application must not make changes to the registry at a level where the change can affect other users or applications. Normally, Terminal Services installation redirects registry entries installed to HKLM\Software on a standard desktop to HKCU\Software on the terminal server, but software may be written in a way that circumvents these protections. Use the ACT or a registry comparison tool to watch for changes in the wrong areas. If such changes are discovered, evaluate the impact upon the server and users.
- Do changes made by the user to program options affect other instances of the program? Changes made in a user’s environment should not affect other users. For example, when user “A” changes the default view in an e-mail client, every other user’s default view should not change as well. Some ways to fix this issue include preventing changes in programs via permissions, creating mandatory user profiles, or having the vendor fix the issue.
- Is the application video-intensive? Video streams from the Terminal Services server are cached on the client, so the server only needs to send that part of the screen that changes to refresh a client. Applications with screen animations or other processes requiring significant screen updates to be sent more frequently place an increased load on both the server and the network, effectively reducing the scalability of the application. Record in the Application Analysis job aid, whether the video delivered by the application is Low, Medium, or High intensity, depending upon the level of graphics the application uses. An application such as Notepad with few screen updates is considered a Low graphics intensity application, whereas an application with several animations and embedded video would be a High graphics intensity application. High graphics intensity applications use more server-side processor and memory while consuming more network bandwidth for the frequent screen updates.
- Is the application audio-intensive? Audio is another consumer of network bandwidth. Rate the audio as Low for a few system sounds, Medium for low bandwidth audio delivered occasionally, or High for an audio-intense application such as a media player or computer-based training with voice instruction.
- Does the application employ code not optimized for either 32-bit or 64-bit architecture? Programs that include 16-bit code must be treated differently by the operating system, which causes the application to use a disproportionate amount of memory and CPU resources compared with programs written in 32-bit or 64-bit code. Use the ACT to detect 16-bit components and move to a newer version, have the software repaired, or decide whether the extra resources required to run the application are acceptable.
Using the factors listed above, rank each of the applications according to their suitability:
- The application is a good candidate. Keep the application in the project and continue working through the steps.
Application has some issues but can still be run in Terminal Services. The issues can affect the implementation but not in such a way as to prevent its inclusion in the project. Add the application to the design while you continue to monitor the risk of the application.
For example, the application may not be supported by the vendor in Terminal Services; however, the business need to run it there is critical. A decision is made to leave the application as a candidate. There could be additional risk later in the process about the scalability of the application or some other reason that emerges that will force another review of the application. - Application is not suitable for Terminal Services at this time. The application is dropped from the project scope and alternative methods for dealing with the application will need to be considered by another project. Applications not ready for Terminal Services may be good candidates for other virtualization technologies. Please refer to the Infrastructure Planning and Design series, Selecting the Right Virtualization Technology, available at https://www.microsoft.com/ipd.
Decision Summary
In this step every application has been examined for its suitability to be delivered by Terminal Services in Windows Server 2008 and ranked on that basis.
Applications that are within the scope of the project have been categorized according to their suitability for delivery in a Terminal Services environment, and this information is recorded in a spreadsheet like the job aid included in Appendix B.
Now, at the end of the step, the categorized list should be reviewed with the business. This is because some applications will likely not be immediately suited to delivery by Terminal Services. Those applications may require some changes in order to remain within the scope of the project. Those changes incur cost and, before embarking upon them, this must be fed back to the business so that those additional costs can be understood and the best business decision arrived at.
It is also possible that some applications that the business wishes to include in the scope of the project cannot be delivered without major work, and a re-evaluation of the project may be required.
The next step determines the resource requirements to deliver those applications through Terminal Services.
Tasks and Considerations
Application Compatibility Toolkit (ACT). The ACT, available at https://technet.microsoft.com/en-us/desktopdeployment/bb414773.aspx, is a group of tools that can be helpful for gathering and evaluating information about an application as it is running on a stand-alone computer as well as when it is running on a terminal server. Some of the tools most helpful to evaluating an application for Terminal Services are:
- Setup Analysis Tool (SAT). Watches a setup and detects the installation kernel mode drivers and 16-bit components, among other things.
- Inventory Collector. Identifies installed applications within an organization.
- Compatibility Reporting. Helps with compiling and evaluating collected data.
- Find compatibility information from the community. Common repository of compatibility issues and their remediation.
Additional Reading
|
|
.jpg)