![]() |
Windows Terminal Server, Virtualization, Application Delivery, Windows Software Development, Market Analysis, Training Classes and more... |
|
|
Navigation |
|
|||||||||||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Awards |
|
||
|
||||
Posted by Benny Tritsch on May 19, 2008
[TS Overview] [Things You Should Know...] [History & Features] [Presentation Virtualization]
Essentially, Terminal Services allow administrators to install, configure, manage and maintain applications on central servers. In many cases this is more efficient than deploying applications on local client computers. Terminal Services enable client devices ‑ often referred to as thin clients and sometimes even called terminals ‑ to connect to a desktop running on the central server. Such a Remote Desktop Client can be either a physical device or Terminal Services client software executed on a computer in the network. Each client is assigned a separate interactive user session on the server. Using this session, a logged-on user performs all operations on the server except operations directly related to physical local devices such as keyboard, mouse and monitor. Only such local operations take place on the client itself. This design opens up interesting and powerful options for Windows Server because it can be used in corporate environments with computer networks that may even be widely dispersed geographically.
The multiple-user function of Terminal Services should not be confused with the function that allows multiple users to be connected to server resources through the network in a more general sense. Multi-user service without interactive logon to the server's user interface is frequently used for file, print, or directory services. In contrast, Terminal Services allows multiple interactive user sessions in parallel, with each of the sessions providing a full user desktop or another kind of graphical user shell.
In Windows Server 2008, Terminal Services is available in two varieties: application server mode, a server role which must be activated before it can be used or remote desktop mode, which is used for remote administration of the server and requires special permissions to access.
A Windows Server with Terminal Services activated in application server mode is commonly referred to as terminal server, even if this is not an official product name. Such a terminal server is an efficient and reliable way to provide Windows-based applications on a network. The terminal server represents a central installation point for applications that are accessed simultaneously by several users from their respective clients.
NOTE: A multiple-user environment has special configuration requirements regarding the applications installed. If applications are already installed on the Windows Server operating system and Terminal Services is later activated in application server mode, some of the applications may not work properly. This is why applications intended for simultaneous access by multiple users must be installed after application server mode was activated.
Windows Server with Terminal Services in application server mode allows simple centralization of user applications and the use of low-maintenance clients. In the past the technical term for this arrangement was server-based computing. In these days it became more common to call it presentation virtualization, allowing cost-effective and highly efficient application centralization and consolidation scenarios. However, today’s modern terminal server environments go far beyond the rather simple concepts behind server-based computing.
The remote administration mode of Terminal Services was first introduced with Windows 2000 Terminal Services. Under Windows Server 2003, this mode was renamed remote desktop due to its relation to Windows XP. It was developed mainly to allow remote access to a server running on Windows 2000, Windows Server 2003 or Windows Server 2008. This enables administrators to access the Windows Server desktops across the network, including all their administrative tools for installed server applications or services.
A server's performance or server application compatibility should not be compromised by remote administration. Therefore, remote desktop mode only requires a minimum of additional memory and processor resources. A maximum of only two remote administrator sessions and one local console session are allowed per Windows Server. The remote administrator sessions do not require special licenses.
NOTE: Consoles are referred to as input and output devices physically connected to the server hardware.
With past versions of Windows Server some programs require a direct logon to the console for administrative tasks. Under Windows 2000, it was not possible to use the console remotely via Terminal Services. Windows Server 2003 introduced system extensions that allowed you to run a console remotely by using the /console parameter in the Terminal Services client software. On Windows Server 2008 the concept of the console session was substantially modified, eliminating the necessity to use a dedicated remote console session for administrative tasks.
Why are people using terminal servers? Historically the primary design objective of Terminal Services was the display of many kinds of Windows-based applications on multiple client hardware platforms. To function properly, the applications had to be able to run as is on Windows Server with Terminal Services enabled in application server mode. By centralizing applications, the technology was intended to reduce operating costs, especially in corporate environments. This implied that Terminal Services provided a powerful option for distributing and updating software.
Essentially, a terminal server is a host computer on which several users can work simultaneously while their screens can be displayed remotely. But is the terminal server platform a server or a client? The answer is far from being simple: An application server for several simultaneous users, who are logged on interactively to a single machine, acts both as a server and as a client, depending on one's point of view.
That being said the central question is still not answered: Why would small, medium and large enterprises want to introduce or maintain terminal servers? In the past this answer was very simple; the reasons were economics and quality of service. Companies wanted to reduce costs based on usage and apply management based on policies. Both worked very well with terminal servers. This didn’t mean that IT managers and users particularly liked terminal servers for what they are; they only turned out to be very effective in reaching the goals mentioned previously. Besides that, terminal servers were mostly regarded as being unattractive, static and old-fashioned as host computers.
The advantages of terminal servers in corporate environments started to vanish as new system management concepts and products were introduced for standard Windows applications. Microsoft System Center Configuration Manager and other system management products allowed deploying and managing standard workstations almost as efficiently as terminal servers, even if the workstations were geographically distributed. Infrastructure and operations maturity had improved, apparently leaving terminal servers behind. This was particularly true in agile environments where both infrastructure and application sets are very dynamic. While terminal servers still were able to provide high stability, good manageability and relatively low costs in traditional medium and large enterprises, they seemed not to be suitable for smaller or more agile environments.
However, common practices show that terminal servers were and still are particularly useful for many organizations. The following scenarios outline a collection of typical terminal server use cases:
With Windows Server 2008, Terminal Services finally became a commodity. Combined with other technologies, such as hardware virtualization and application isolation and streaming, terminal servers are a lot more agile and adaptable to increased business requirements than ever before. In combination with the typical terminal server advantages in terms of stability, manageability and costs, such a technology mix has a bright future in many organizations.
A terminal server allows access to one or multiple remote applications. This sounds rather obvious. However, there are different ways how a user may launch remote applications, each way including specific user interface and usability characteristics.
If a user wants to display a remote desktop on the client, he or she selects the IP address or the logical name of the corresponding server. According to the permission settings, the appropriately authorized user can launch and use the installed applications on that desktop. This access concept can also be used on simple clients that have no desktop or on client desktops with reduced functionalities, such as a Windows Embedded desktop.
If all of a user’s required applications are not installed on the same terminal server, that user may then create remote desktops for each required application that exists on a different terminal server. For most users, the effect of accessing applications through multiple concurrent desktops is confusing which often leads to increased support costs.
If terminal servers are used, different configuration options allow the selection of an application that is started automatically when a user logs on. After logon, the predefined application will consume the complete area of the server desktop that is displayed on the client. Configuration of this option is available to either a user on the client side, an administrator who is responsible for the user accounts, or the terminal server administrator.
Even if the desktop is not directly visible when the automatic program start option is used, the desktop functionalities are still available, which becomes very obvious when the application is minimized to an icon. But still this concept is very good for clients with limited local desktop functionalities. However, the restrictions concerning access to desktop elements stay exactly the same as if the user would access the desktop directly.
The scenario of Remote Applications Integrated Locally (RAIL) resolves the requirement that a terminal server desktop should not be displayed on the client when a remote application is started. Pushing the icon of a terminal server hosted application to a client desktop is one of the core mechanisms required for launching Remote Applications. It includes some additional configuration and requires the enhancement of the client’s window manager components providing presentation of desktop elements. This allows the application published by a terminal server to be displayed in an individual window on the client desktop.
If one or more Remote Applications can be launched on the client without the surrounding of the server desktop they are executed inside seamless windows. As a result of this, the application looks as if it was executed locally on the client. Authentication is only needed when the user launches the first application in a seamless window. Using seamless windows produces adequate results only if the client has its own fully functioning desktop including proper window management.
NOTE: Launching a seamless application on a client still requires the creation of a full user session and a dedicated desktop on the server, even if this desktop is not visible on the client.
The server side of presentation virtualization represented by terminal servers is only one component required. A complete multi-user environment, however, consists of the following four groups of components:
Throughout the following chapters this book introduces and describes in detail all four groups of components from different perspectives.
Which server types support Terminal Services? For application servers, Terminal Services is provided with 32-bit and 64-bit Windows Server 2008 Standard, Enterprise, and Datacenter editions. The following table lists important features of various server types. It also includes functions such as Remote Desktop to transmit the graphical user interface (GUI) to a remote computer for administration purposes, as well as Session Broker to manage user sessions in server environments with load-balancing mechanisms.
| Function | Web | Standard | Enterprise | Datacenter |
|
Terminal Services in Application Server Mode |
No | Yes | Yes | Yes |
|
TS Gateway |
No | Yes (250) | Yes | Yes |
|
RemoteApp Programs |
No | Yes | Yes | Yes |
|
TS Session Broker |
No | Yes | Yes | Yes |
|
Remote Desktop for Remote Administration |
Yes (2) | Yes (2) | Yes (2) | Yes (2) |
|
Internet Information Server |
Yes | Yes | Yes | Yes |
|
Hyper-V (Virtualization) |
No | Yes | Yes | Yes |
|
Server Core |
Yes | Yes | Yes | Yes |
|
CPU Sockets (x86) |
4 | 4 | 8 | 32 |
|
CPU Sockets (x64) |
4 | 4 | 8 | 64 |
|
Maximum Memory (x86) |
4GB | 4GB | 64GB | 64GB |
|
Maximum Memory (x64) |
32GB | 32GB | 2TB | 2TB |
Table: Functions and system requirements of different server products (all products are available in both 32-bit and 64-bit versions)
| Read in this chapter... | |
| 1 | Terminal Services Overview |
| 1.1 | Things You Should Know Before Getting Started |
| 1.2 | History and Features |
| 1.3 | Presentation Virtualization |