Infrastructure Assessment

Before setting up a terminal server–based environment, the existing infrastructure needs to be analyzed and documented. In addition to comprehensive tests, this analysis is essential for installing a terminal server without running into major problems.

First, infrastructure analysis will provide an integrated view of terminal servers and their clients, within the framework of a business plan. The result will then be adapted to a three-layer model to show the general error tolerance options in a terminal server environment. The layers are structured as follows:

• Layer 1 Central domain controllers, file servers, or database servers (backend servers) that need to be configured using different methods to ensure failover protection. This layer handles data storage and provides central network services.

• Layer 2 Load-balanced terminal servers. If one server fails, the user can immediately log on to another server. The user’s profile and data are not located on the terminal server; instead they are stored on the domain controller and file server. This layer hosts the application execution environment.

• Layer 3 Thin clients for user interface. If the network or client hardware fails, the user can reconnect to the session and continue working from another client. This layer visualizes the user interface and connects input devices (mouse, keyboard, and so on).

Redundancy and scalability considerations make this type of environment superior to most other concepts. If the existing application servers are no longer adequate, new servers may be added. Thus, fewer users work on each server, which increases the amount of resources available per user. Smart load-balancing mechanisms also allow different server generations to be mixed.

To integrate this type of environment into a corporate network, the existing infrastructure must be analyzed. The following list contains a number of issues that need to be clarified to prepare the necessary documentation and evaluate the infrastructure. The results should be taken as a precondition for planning the integration of terminal servers into the system.

• ServerManufacturer, BIOS version, motherboard (including processor versions), number of processors supported, main memory, disk capacity, disk access speed and peripherals.

• Infrastructure Computer naming conventions, names of the domains or work groups, backup systems, emergency plans, and procurement details.

• Local network Transport protocols used, server and client bandwidth available, physical LAN aspects such as topology or active components (such as routers or switches), IP addresses assigned to the terminal servers, subnet masks and standard gateways, name resolution (DNS, WINS), address assignment (static or via DHCP), and file server access protocols.

• Wide area network Connecting remote corporate locations, including the available bandwidths, backup data lines, and existing routers or firewalls, as well as filter rules and modem dial-up options.

• Backend systems Domain setup, connection to third-party systems (that is, UNIX, Novell, or others), file servers, supported file systems, database servers, and Internet connection including possible regulations.

• Printers List of printers and print servers needed.

• User environment User names, group assignments, logon scripts, profiles, and Group Policies.

• Administration and monitoring Administration tools used (Microsoft Systems Management Server, Microsoft Operation Manager, CA UniCenter, HP Openview, or others).

• Applications Commercial applications, applications with special hardware requirements, and proprietary applications developed for your company’s business requirements.

• Security Public key infrastructure and smart cards.

• Clients 3270 terminals, 5250 terminals, VT-100 terminals, Windows-based terminals, network computer, X terminals running under UNIX, PCs running under a 16-bit Windows operating system, PCs running under a 32-bit Windows OS, and browser-based clients.

Referring to this list will help the project manager or the person in charge of the system evaluate the potential terminal server target environment.

Project Integration and Corporate Architecture

Experience shows that the introduction of terminal servers and their related application access portals often follows a specific pattern. These projects usually succeed if simple rules are adhered to, especially rules related to the above-mentioned technical requirements of the potential target environment and other existing framework conditions.

So what is the ideal sequence in which terminal server technologies should be introduced in a company? The following phases have been identified time and again in successful terminal server projects:

1. Backend server consolidationTerminal servers usually rely on central services. (See Chapter 3.) Therefore, file, database, and e-mail servers as well as other backend server services should be centralized before terminal servers are set up. For this reason, successful terminal server projects are launched only after a backend consolidation process has been launched and completed.

2. Terminal server environment setupFollowing successful tests, a large terminal server environment is planned and introduced. During this time, administrators and users need to be prepared and trained intensively so that they will be able to work within the environment. In this phase, the terminal server environment is accessed through conventional clients’ desktops or thin clients.

3. Application access portal launchTo further cut conventional clients and their desktop administrative costs, an application access portal is placed on the intranet; this occurs after the terminal servers have successfully been set up. The application access portal centralizes functions such as authentication or personalized administration of application icons.

4. Concept expansion to external usersAs soon as a terminal server environment and application access portal have been launched on the intranet, the concept can be expanded to external users if appropriate security mechanisms are in place. The group of external users can include people who are not part of the company and have limited access to the environment. However, this group can also consist of employees who need to access the environment from outside the company network, possibly from unsecured locations.

In some (very ambitious and very complex) projects, these phases take place simultaneously. For these projects to succeed, it is absolutely essential that the requirements and framework conditions be distinctly planned in advance because the project goal must be accurately defined. The following six points help define the project objective:

• What? What data should be generated or managed within the scope of the terminal server project? Are databases, file system documents, or other data sources required? What data model will be used? Is better data or an improved data generation workflow expected to be the result of the terminal server project? Does data need to be saved as it relates to the organizational unit, and is it necessary to include a revision stage?

• How? Which corporate processes will be involved in the terminal server project? Which application architecture is affected? Which individual applications need to be integrated in the environment? How are the applications installed in the terminal server environment? Are all applications installed on one farm with identical terminal servers, or will there be an individual terminal server farm for each small group of applications? What are the consequences for the existing security infrastructure? Do agreements on definition and grade of service need to be drawn up?

• Where? What is the existing corporate environment, and how does it need to be modified to fit terminal server requirements? To answer this question, it makes sense to use the preceding questions for analyzing infrastructure.

• Who? Which individuals and organizational units will be affected by the terminal server environment? Is there a clear-cut organizational chart including roles and skills? Will end users and management be sufficiently involved in the process of introducing terminal servers? Do training concepts for all employees exist?

• When? What is the key timing factor for the terminal server launch? How does the time of launch fit into the overall business plan of the company? When does the terminal server environment need to be available for everyday operations? What are the time-related dependencies between business processes and applications on the terminal servers? What are the maximum downtimes for terminal servers before a situation is reached that could endanger business?

• Why? What is the reason for introducing a terminal server environment? Is the overall objective cost reduction or the introduction of new technologies, or does technical necessity caused by a problematic vintage system call for a new one? How do these objectives fit with overall business goals? Does the corporate strategy need to be modified as a result of the introduction of terminal servers?

Answering these questions before a terminal server project is kicked off helps avoid misunderstandings regarding goals and procedure. Nevertheless, the answers to these questions contain some high-risk elements that should be addressed.