This is probably where the most changes have been made. To make your machine a terminal server license server you will have to install it separately. Once you have installed this option your server will be listed in the terminal server licensing console. You will have to activate the server before it can start distributing licenses. Activation of the licensing server can be done via a direct connection to the internet, a web browser or over the telephone.
The following is a screenshot of the terminal server licensing console demonstrating what you would have to do to start the activation process. This will bring up a wizard asking you to enter details and select options to suite your needs.
Follow the on screen instructions and press Finish when you are done. They can both be found in the administrative tools folder in control panel or on the start menu.
When you select the server name you can choose to view and manage the Users, Sessions or Processes tab. The green icons indicate that the server is online. If you had to disconnect it, the icons would be gray. The Users tab allows you to see who is connected, how long they have been connected and the state of their connection. The Sessions tab permits the viewing and control of the terminal server sessions.
You can right click a session and select the status to see the incoming and outgoing data or reset to reset the session.
The processes tab shows all the processes that are running and which user they belong to this is a simplified version of the processes tab found on the windows task manager.
The image below shows the Terminal Services Manager with an active connection initiated by a user andrew. If you select the RDP-Tcp 12 username option you can view the processes and session information specific to that user. Note: The 12 number will be different for each session. Any connections that have been setup will be displayed in the connections part of the console. Technically following the Microsoft terms, you would need to buy a license for each unique user or computer that connected to your server.
Clearly this is not feasible. To address this challenge, Microsoft introduced the External Connector License ECL , designed to be used when systems are extended to external parties, including business partners and the public. ECLs are available for all new Microsoft products except products that are licensed on a per-processor basis since per-processor licenses already account for unlimited users and client devices.
In Terminal Server environments, ECLs provide a simple way to buy "concurrent" user licenses for those who need to connect to your server. At this point you might be wondering why you can't just buy ECLs and forget all this per-user and per-device garbage. To legally access a Windows Terminal Server, each client seat requires each of the following licenses:.
License 1. This license provides the "basic" access rights that allow users to store files, print, and be part of an Active Directory. License 2. It builds upon the regular Windows Server CAL, adding the legal right for users to access a "remote control" session on a Terminal Server. Special Licensing Scenarios Prior to Windows Server , there were special license rules for specific situations. Microsoft has changed the way these situations are handled with the introduction of Windows Server The only requirement was to purchase a TS CAL for client devices that ran an operating system lower than the Terminal Server operating system.
If you bought it before April 24, , then it does. Interestingly, the added TS CAL costs of Terminal Server on Windows Server has upset some companies so much that they are claiming it as the sole reason that they will keep their Terminal Servers running on Windows While you were legally supposed to purchase the correct licenses, there was nothing technically stopping you from connecting more users than you paid for.
While the honor system worked well for system administrators and thieves, it has not worked as well for Microsoft shareholders. As alluded to in the opening sentences of this chapter, this system changed when Windows was released. Microsoft implemented this licensing service as a "service to their customers" who were "deeply concerned that they might accidentally forget to pay for a license or two, every once in awhile.
Windows Terminal Servers also make use of licensing servers—although the exact manner depends upon for which of three licensing options a server is configured per device, per user, or the external connector license. In Windows environments, there are four main technical components that make up the Terminal Services licensing infrastructure:.
Figure 4. Like Windows environments, a Windows license server is responsible for issuing licenses and tracking their use. Microsoft License Clearinghouse TS license servers and TS client access licenses must be activated be Microsoft before they can be used.
The Microsoft license clearinghouse is a large Internet-based certificate authority that authorizes and activates these licenses and servers. Microsoft does this to ensure that no TS CALs are stolen, copied, or pirated which is why more and more Microsoft software requires activation after you input your license codes.
A TS license server will function before it's activated via the Microsoft clearing-house, however, an unactivated license server will only pass out temporary TS CALs that expire after 90 days. In order for a license server to distribute permanent licenses, it must be activated. Terminal Server Windows Terminal Servers understand that client devices must be licensed. To that end, when you enable Terminal Services, the server immediately begins trying to locate a licensing server.
It then communicates with the licensing server to ensure that client devices are licensed properly. The Logon settings are configured under another tab. On the client, you enter the logon information including the password, if required into the fields under the corresponding radio buttons. The data is passed on to the server at logon. Be careful not to confuse this with the single sign-on solution in which the information the user enters at logon is automatically used to establish a session on the client.
Even though this option is convenient for logging on to a terminal server session, it does present security problems. Furthermore, not all clients support this option.
Alternatively, you can input a user name , domain, and password for logging on to the terminal server. This enables an automatic logon, too, and is valid for all user sessions requesting a connection over this type of protocol.
In many environments, however, there might still be security concerns regarding user access. Nonetheless, this is a very powerful option that allows anonymous users to access a terminal server running noncritical applications, for example, information terminals in a department store. You can make both logon options more secure by requiring the user to enter the password manually. To activate this option, select Always request password option. This prevents the stored password from being used, no matter where it resides client side or server side.
Regardless of the logon option, users will be required to enter their password each time they log on to the terminal server, thus significantly increasing security. In production environments, always select this option button, unless the user is authenticated in a special secured environment that is safe for password transmission.
The configuration of sessions on this tab sets the timeout limits for Terminal Services and determines the reconnection settings. The timeout limits are set using three counters. You have the choice of three predefined settings:. End a disconnected session This counter sets the maximum time a disconnected user session remains in memory. When the interval specified is completed, the session is ended; that is, the session is physically removed from memory, the user s applications are terminated, and the user is logged off.
Terminal Services configuration allows you to set the value for the protocol in question only RDP in the default installation only if you select Override user settings. In this case, the setting you define here overrides the corresponding setting in the terminal server-specific expansions for local users and groups or users and computers in the Active Directory directory service.
In this way, the terminal server administrator can set a generally valid standard for the behavior of Terminal Services for separate sessions. Active session limit This counter sets the maximum duration of a user session.
When the time is up, the session is either disconnected or ended, depending on the settings specified in the following paragraph. To set the active session limit value, you also need to override the user settings. Idle session limit With this counter, you set the time that a user can remain inactive. If this time limit is exceeded, the session is either disconnected or ended, depending on the settings described in the following section.
This is yet another value that you can set only if you override the user settings. Setting session limits does involve a certain amount of risk. For instance, if the idle session limit is set to 60 minutes, a session might be disconnected or ended when the user is simply on an extended lunch break.
In the worst case scenario, data might be lost. On the other hand, setting a time limit is sometimes the only way to prevent inactive users from wasting server resources. The following settings relate to system behavior when the session limit is reached or the connection is broken. Selecting Override user settings combined with Maximum Idle Time overwrites the settings in the terminal server-specific settings for local users and groups or users and computers in the Active Directory.
Thus, the configuration settings chosen here turns an individual user request into a generally binding system behavior preset by the terminal server administrator. When the session limit is reached or the connection is broken for example, by switching off a client , there are two options:.
Disconnect from session The network connection is interrupted but the session remains stored in terminal server memory. This applies to all open applications and the corresponding user data. End session The user session is completely removed from memory. Unsaved application data is lost if the user did not save it and no automated backup processes were activated. On closer examination, one combination of settings seems completely useless at first: A disconnected session is ended after 10 minutes, yet the session also ends when the session limit is reached.
Can a disconnected session remain in memory? The answer is yes. A user can explicitly ask the client to disconnect from a session. This disconnection does not result from a session limit or an interrupted network connection. In this case, the minute time limit is valid for the disconnected session until it is ended, if the user does not reconnect to it.
A disconnected session can be reestablished by any client under the RDP protocol. The user account and the corresponding password are essential to establish a new connection. This option is particularly helpful if the terminal server is protected by an uninterruptible power supply, but the clients are not. In this case, a short power failure does not result in the loss of user data or application statuses. The user can then continue working with his or her session from any client. This setting cannot be changed under the RDP protocol.
Other protocols might allow limiting reconnections to the previous client. Therefore, this configuration option does appear in the dialog box. Here, too, selecting Override user settings overwrites the corresponding setting in the terminal server-specific expansions for local users and groups, or for users and computers in the Active Directory.
If the user is allowed to reestablish the connection to a disconnected session from the same client only, this can result in problems if the physical client fails. Even if an identically configured client replaces the original client, the user will not be able to use his or her session again. In production environments, the time limits for user sessions are usually set in this tab and can overwrite previously set, different user settings.
In particular, this applies to ending a disconnected session after several minutes or hours and after the idle session limit. Therefore, it is strongly recommended that these values be thought through and communicated to users well in advance. When sessions disappear without sufficient warning, users often reject the technology, unjustifiably. It is not the technology that creates the problem, but the organization or, in some cases, the communication involved.
The Entering two strings in the tab Environment enables the configuration of an exclusive program that is started automatically upon user logon. An entry at the Program path and file name specifies the program desired. The Start in prompt determines the default directory allocated to the program. When a user logs on, the program inside a full-screen session window is displayed instead of the normal desktop. When the user ends the program, the terminal server session is terminated, too.
This leads to a basic form of environment where only one application is able to run. This option becomes active only if the Override settings from user profile and Remote Desktop Connection or from Terminal Services client option were activated. This overwrites the corresponding setting in the terminal server-specific settings for local users and groups or users and computers in the Active Directory, including the client side as well.
In this instance, too, the Terminal Services configuration takes precedence over the user or client-specific settings. In general, specifying a start program does not prevent the user from running another program. Some desktop functions could still be misused behind the active application. For a strict single-application environment, the terminal server administrator needs to add further security settings. Problems that arise when starting the program over the network might indicate improper timing.
For example, the terminal server might be trying to start a program before a required network drive in a logon script is connected.
The options in this tab are usually not modified in production environments. In general, a different technology is used to display individual applications. We will describe this technology in detail later in this book. The Remote Control tab allows a user session to be mirrored on another client. This function is for administrative tasks, for example, help desk tasks.
The remote control configuration allows you to use user-specific default settings, as well as to fully deactivate and configure the following settings:. Use remote control with default user settings means that the user settings of a local user or in the Active Directory are used to determine the following options.
Under Use remote control with the following settings in the dialog box, the administrator can determine if a user must approve of remote control when the administrator assumes control over a session. Additionally, it is possible to define whether the remote session can be viewed only under remote control, or if the administrator can also interact with the session by assuming control of the keyboard and the mouse.
Figure Configuration of remote control, where the user must give his or her permission, and the remote session can only be viewed. Labor-law restrictions in some countries prohibit monitoring users without their knowledge. It is therefore mandatory to obtain the user s permission. For this reason, remote control behavior in production environments is usually preconfigured under this tab and not under user settings.
Client settings allow an administrator access to several options related to the integration of client resources in the user session. Integrating these options supports the intuitive assumption by the user that he or she can continue to use local resources even though the application on the screen is physically running on a remote server.
Furthermore, this reduces the time it takes a user to become familiar with the system. For example, during a Terminal Services session, a user can issue the print command without first having to correctly allocate the appropriate resources. In principle, the following options can be preconfigured for a connection protocol such as RDP 5. The first three options can also be defined through the user settings. Connect client drives at logon At logon, this option displays the local client drives as network drives in the corresponding terminal server session.
This option is activated by default. Connect client printers at logon At logon, this option displays the local client printers as network printers in the corresponding terminal server session. Default to main client printer This option determines whether a print job is forwarded automatically to the terminal server default printer or to the main client printer. This option is activated by default, which sends the print job automatically to the default client printer.
Limit maximum color depth With this option you determine whether you want to limit the maximum color depth for a terminal server client using this connection. If this option is active, you can select 8-bit, bit, bit, or bit. The default setting is preconfigured to bit. Printer connections will take the most time because numerous driver combinations can apply. The other interfaces are a bit easier to integrate, although you can always disable them again as well.
0コメント