Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Microsoft Windows Server 2003 Deployment Kit [Electronic resources] : Planning Server Deployments - نسخه متنی

Microsoft Corporation

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
توضیحات
افزودن یادداشت جدید


Planning for Application Hosting


As shown in Figure 4.2, the first step in planning your deployment of Windows Server 2003 Terminal Server is to clearly identify the scope of your deployment. This step provides you with a high-level specification on which to base the design of your network and domain infrastructure.


Figure 4.2: Planning for Application Hosting with Terminal Server



Identifying the Role of Terminal Server in Your Organization


The way in which you plan to use Terminal Server has an effect on how you deploy it. The following sections outline the various ways in which you might use Terminal Server in your organization. Use the information in these sections to clarify how you are going to use Terminal Server in your organization.

Hosting Line-of-Business Applications


If your organization or certain groups within your organization use specialized applications to do their work, it might be beneficial to host the applications with Terminal Server. For example, you might decide to use Terminal Server in the following situations:

Custom applications. If your line-of-business application is developed in-house or especially for your organization, and it tends to require frequent updating or repair, deploying the application once on a terminal server can simplify administration of the application. This is especially useful if your environment is geographically dispersed or if you are deploying Terminal Server to centrally serve your organization's branch offices.

Large central data pool. Applications that rely on access to a single data source often run better on a terminal server because large amounts of data do not have to travel across the network to users. Instead, the data processing takes place on the server. Only the keystrokes and display information travel across the network, so you can use lower bandwidth connections. This is especially useful if the users of the data pool are located remotely, for example in a branch office with a slow connection to the database server.

Task workers. In environments where you want workers to access only the application that they need to perform their jobs, you can centralize the administration of these users by using Terminal Server.

IT Admin tools. System administrators can perform tasks that require Enterprise Admin or Domain Admin permissions on a terminal server that has the necessary tools installed on it. They can also run their desktop applications on their local computer without these permissions.

Upgrading operating systems. If your organization uses a line-of-business application that is not optimized for your desktop operating system, you can host the application with Terminal Server rather than change operating systems.


Hosting the Desktop


You can use Terminal Server to host users' entire desktop environments, so that when users log on, they see their usual desktop environments or desktop environments especially designed for their remote use. In this situation, users can open and close the applications they choose in the same way that they access applications from the Windows desktop on the local computer. You can host the desktop in the situations discussed in the following sections.

Remote users

Hosting the desktop with Terminal Server can provide higher levels of consistency and performance for users in remote locations because large amounts of application data are not being transmitted over the connection. For example, you might use Terminal Server in the following situations:

Bandwidth-constrained locations. In areas where high bandwidth is not available or cost-effective, deploying applications on a terminal server can improve performance for users who are connecting to the network from a remote location over slow dial-up connections.

Mobile users. For users who are traveling and tend to access the corporate network over connections of varying bandwidth, Terminal Server can provide a more consistent experience.

Client heterogeneity

If your organization is in the process of converting all users to the same platform or upgrading desktop hardware, you can use Terminal Server to quickly deliver the most up-to-date version of the operating system and applications to the user while enabling you to spread the desktop platform or hardware conversion over a longer period of time. You can also deliver a highly controlled standard desktop to users by using Terminal Server, as illustrated in more detail in the following list:

Mixed-platform environment. If you have users who require applications based on operating systems other than Windows to perform their jobs, but your organization is transitioning to or requires a Windows-based desktop, you can host the desktop with Terminal Server. This requires the use of third-party software in conjunction with Terminal Server.

Upgrading hardware. If your organization is planning to upgrade to Windows XP on the desktop, but not all of the desktop hardware is compatible, you can use Terminal Server to host the desktops of users who have older hardware while you are in the process of upgrading the hardware. All users can have the same desktop environment and run the latest versions of the applications designed for Windows XP regardless of their desktop hardware.

Highly controlled environments. In situations where you want to deliver a standardized and controlled environment to users, you can host the desktop with Terminal Server to centralize management.


Hardware Considerations


You can reduce hardware costs by hosting applications with Terminal Server and using thin client devices or older hardware on your users' desktops.

Use of thin clients. Windows Powered thin clients (sometimes called Windows-based terminals) offer an alternative to personal computers and traditional "green screen" terminals by enabling easy remote access to productivity and line-of-business applications that are hosted on Windows-based terminal servers.

Extending the life of older hardware. Rather than replacing older hardware that is no longer capable of running new Windows-based applications, you can use that older hardware much like a thin client to access the desktop and applications on the server rather than on the local computer.

Using the Remote Desktop Web Connection


The Remote Desktop Web Connection is an ActiveX control that provides virtually the same functionality as the executable version of Remote Desktop Connection, but it delivers this functionality over the Web even if the executable version is not installed on the client computer. When hosted in a Web page, the ActiveX Client Control allows a user to log on to a terminal server through a TCP/IP Internet or intranet connection and view a Windows desktop inside Internet Explorer.

The Remote Desktop Web Connection provides an easy way to offer Terminal Server through a URL. Consider using the Remote Desktop Web Connection in the following situations:

Roaming users. Users who are away from their computers can use Remote Desktop Web Connection to gain secure access to their primary workstations from any computer running Windows and Internet Explorer, provided they can reach the target computers.

Delivery of extranet applications. You can use Remote Desktop Web Connection to allow business partners or customers access to internal applications over the Internet. Users who gain access in this manner do not need to reconfigure their computers, and they do not gain access to your internal network.

Deployment transition. You can deploy the Remote Desktop Web Connection quickly and use it while you are deploying your full Remote Desktop Connection infrastructure.

For more information about the Remote Desktop Web Connection, see the Server Management Guide of the Windows Server 2003 Resource Kit (or see the Server Management Guide on the Web at http://www.microsoft.com/reskit).


Choosing Applications to Host


Before deploying applications with Terminal Server, you must determine which applications are ideal candidates for hosting in your organization, and determine if those applications will work well in a Terminal Server environment. You might also want to host the entire desktop through Terminal Server.



Identifying Ideal Candidates for Hosting


When choosing applications to host with Terminal Server, consider the compatibility of those applications with Terminal Server. Many desktop applications load and run correctly with Terminal Server. Applications that have been certified for Windows are generally compatible with Terminal Server. For more information about the Certified for Windows program, see the Certified for Windows link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

With any Windows-based application the definitive source of compatibility information should always be the application's vendor or developer. For more information about application compatibility with Terminal Services, see "Program compatibility" in Help and Support Center for Windows Server 2003. There are also application compatibility notes for some applications available on the VeriTest Catalog of Certified Windows Server Applications link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

Application Characteristics That Affect Performance with Terminal Server


Because Terminal Server is available for multisession (multiuser) use, and because the display and keystroke information travels over the network, applications that have certain characteristics might perform poorly with Terminal Server. When planning for your organization, establish a set of acceptable performance guidelines and determine through testing whether such applications run better on the user's local computer. For example:

Multimedia applications or applications that have very large graphical output do not run well with Terminal Server. Because large amounts of display information travel over the network, the performance of these types of applications is often unacceptable, especially over low-bandwidth connections. Many computer-aided design (CAD) and streaming media applications fall into this category.

Running 16-bit programs with Terminal Server can reduce the number of users a processor supports and increases the memory required for each user. Windows Server 2003 translates 16-bit programs in enhanced mode through a process called Windows on Windows (WOW). This causes 16-bit programs to consume additional system resources. A similar situation exists with running 32-bit applications on the 64-bit versions of Windows Server 2003.





Note

You can prevent 16-bit applications from running on Windows Server 2003 by enabling the Prevent access to 16-bit applications Group Policy setting. This setting is located in Administrative Templates/Windows Components/Application Compatibility. You can set this setting for both the computer and the user.


There are third-party add-ons that you can use to help with the performance of 16-bit applications and other application compatibility issues. For more information about these add-ons, see the AppSense and Tame Software links on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.




Applications that are based on the Microsoft MS-DOS operating system use keyboard polling that can consume all the available resources on a CPU.

Applications with features that run continuously in the background (for example automatic spelling and grammar checking in Microsoft Word) can affect performance with Terminal Server. In some cases, you can restrict user or group access to certain application types, disable unnecessary features that require the most resources, or install applications on separate servers to minimize the performance effects.

Complex automation or macros can be CPU-intensive and are not recommended. If you use or plan to use macros with the applications you plan to host, test your plans thoroughly to ensure adequate performance.

If you plan to use Terminal Server to host custom applications or applications developed in-house, you need to consider the specification for applications for the Certified for Windows program. For more information about the Certified for Windows program, see the Certified for Windows link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. For information about guidelines for developing applications for use with Terminal Server, see the Optimizing Applications for Windows 2000 Terminal Services link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.

If you plan to host older applications with Windows Server 2003 Terminal Server, for example applications that you have hosted with the Microsoft Windows NT 4.0 Terminal Server Edition operating system, be aware that you might need to run Terminal Server in Relaxed Security mode, which allows access to system files and the registry on the server, in order for these applications to function properly. For more information about security modes, see "Designing the Terminal Server Configuration" later in this chapter.

After you choose the applications you want to host, analyze these applications for potential problems in a multiuser environment and thoroughly test them, including end-user testing and pilot testing, to ensure that they work in your environment. For more information about piloting and testing, see "Planning for Deployment" in Planning, Testing, and Piloting Deployment Projects of this kit.

Compatibility Scripts


You might have to modify or provide support for custom applications or applications that are not written to accommodate multiuser access. Such applications might not use per user data storage, the user-specific portions of the registry, or appropriate permissions. You can run compatibility scripts for these applications after you install the application. These scripts are available:

With the Windows Server 2003 operating system. These scripts are located in the systemroot\Application Compatibility Scripts\Install folder.

From your application vendor. These scripts might be available on the application CD, on the Web, or by special order from the company.

By developing them yourself. Use the scripts in the systemroot\Application Compatibility Scripts\Install\Template folder as a template.


Information about running these scripts is available in the "Designing Application Installation" section later in the chapter. For more information about the Windows Application Compatibility Toolkit, see "Testing Application Compatibility" in Automating and Customizing Installations of this kit.


Hosting Full Desktops with Terminal Server


If you determine that hosting with Terminal Server is an ideal way to manage an application, consider running just the application (not the entire desktop) on the terminal server. This can save significant resources on the terminal server and can allow many more users to log on to the server simultaneously.

If, however, you want your users to access their full desktop from the terminal server as outlined in "Terminal Server Capacity Planning" later in this chapter.

Choosing the Desktop Theme


If you host the full desktop with Terminal Server, the desktop environment is like the Windows desktop. The default desktop theme for Windows Server 2003, however, is Windows Classic. You can use the Windows XP default theme, however this theme affects performance for the user because it is more graphic intensive than Windows Classic. Test the responsiveness for the end user and perform real-user testing to ensure that the performance is satisfactory when using this theme. For more information about testing, see "Terminal Server Capacity Planning" later in this chapter.

You can also choose a specific theme for your end users or enforce the use of the Windows Classic theme through Group Policy. For more information, see "Configuring User Group Policy Settings" later in this chapter.


Choosing the Licensing Model


To use Terminal Server in your organization, you are required to have a Windows Server 2003 license for every terminal server that you deploy in your organization as well as Terminal Server Client Access Licenses (CALs) for devices that access the terminal servers. For terminal servers that are running Windows Server 2003, there are two types of Terminal Server CALs:

Per Device

Per User


Which CAL you choose depends on how you plan to use Terminal Server. By default, Terminal Server is configured in Per Device mode, but it can be switched to Per User mode using the Terminal Services Connection Configuration (TSCC) tool or by using Windows Management Instrumentation (WMI). You can serve both license types from the same license server. For more information about how to set your licensing mode, see "Designing the Terminal Server Configuration" later in this chapter.





Note

Windows 2000 Internet Connector Licensing has been replaced by Terminal Server External Connector Licensing in Windows Server 2003. Improvements include licensing qualification extended to business partners in addition to customers, authenticated access, and unlimited concurrent users per server. For more information about External Connector Licensing, see the "Windows Server 2003 Licensing" link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. Windows Server 2003 retains support for Windows 2000 Internet Connector Licensing.


A Terminal Server license server on your network manages the Terminal Services CALs. A license server stores all Terminal Server CAL tokens that have been installed for a terminal server and tracks the license tokens that have been issued to clients. For more information about setting up a license server, see "Planning the License Server" later in this chapter.

For more information about Terminal Server licensing, see "Terminal Server Licensing overview" in Help and Support Center for Windows Server 2003 and the "Microsoft Windows Server 2003 Terminal Server Licensing" white paper at the Terminal Services link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. For more information about licensing, see the Licensing Programs for Enterprises link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.





Note

Each serviceor application that users access from the terminal server must be licensed appropriately. Typically each device requires application licenses and CALs associated with it, even if the application or service is accessed indirectly through the terminal server. For more information, check the product documentation, End User License Agreement (EULA), or any other document that specifies product usage rights.


Per Device Licensing Mode


A Per Device CAL provides each client computer the right to access a terminal server that is running Windows Server 2003. The Per Device CAL is stored locally and presented to the terminal server each time the client computer connects to the server.


Per Device licensing is a good choice for:

Hosting a user's primary desktop for devices the customer owns or controls.

Thin clients or computers that connect to a terminal server for a large percentage of the working day.

Hosting line-of-business applications that are used for the bulk of your users' work.

This type of licensing is a poor choice if you do not control the device accessing the server, for example computers in an Internet cafe, or if you have a business partner who connects to your terminal server from outside your network.

Per User Licensing Mode


In Per User licensing mode you must have one license for every user. With Per User licensing, one user can access a terminal server from an unlimited number of devices and only needs one CAL rather than a CAL for each device.





Note

At the release of Windows Server 2003, Per User licensing is not enforced. However the terminal server must be able to discover a license server after the 120-day grace period expires. Otherwise, clients are denied access to the terminal server. For more information about the 120-day grace period, see "Planning the License Server" later in this chapter. For more information about the enforcement of Per User licensing, see the "Microsoft Windows Server 2003 Terminal Server Licensing" white paper at the Terminal Services link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources. For more information about plans for enforcing per user licensing, see the Licensing Programs for Enterprises link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.


Per User licensing is a good choice in the following situations:

Providing access for roaming users.

Providing access for users who use more than one computer, for example, a portable and a desktop computer.

Providing ease of management for organizations that track access to the network by user, rather than by computer.

In general, if your organization has more computers than users, Per User licensing might be a cost-effective way to deploy Terminal Server because you only pay for the user to access Terminal Server, rather than paying for every device from which the user accesses Terminal Server. Check the end-user license agreement for the applications that you plan to host to determine if they support per user licensing.

/ 122