Как да използваме отдалечен работен екран на Windows XP от Windows Vista/7?

от Mark Kaelin

Microsoft Windows Vista/7 добавя няколко нива на сигурност в сравнение с това което се ползва при Windows XP. като цяло това е добре. Обаче тези нива на сигурност взаимодействат с потребителя. Отдалечените работни екрани за приложения е един пример за това. Осъществяването на отдалечена връзка с работен екран на Windows XP от друг компютър работеш под Vista/7 операционна система може да е проблемно ако не се погрижим за определени неща свързани с конфигурирането.

Въпроса за свързване с компютри работещи под Windows XP в офиса от компютър под Vista/7 от къщи е важен за потребители с нови компютри, защото потребителските домашни машини имат често пъти по-нова версия от тези във фирмите.

Windows XP

За целите на упражнението предполагаме, че имате стабилна връзка. Също се предполага, че отдалечения Windows XP компютър е конфигуриран да приема отдалечени връзки както е показано на Фиг A.

Фиг A

Remote tab (System Properties)

Windows 7

След като имате сигурна връзка до отдалечения компютър, трябва да стартирате Remote Desktop Connection приложението Фиг B.

Figure B

Start Remote Desktop Connection

The Vista/7 версията на софтуера за отдалечена връзка е подобен на Windows XP. От ключово значение за връзката е да напишете пълното име на компютъра с който се свързвате. Би трябвало да изглежда така:

yourworkstationname.domain.server

За разлика от Windows XP, Windows Vista/7 ще ви попита за удостоверяване на потребителя когато щракнете бутона за връзка, което се вижда от диалоговия екран на Фиг C.

Фиг C

Enter your credentials

След като кликнете OK, ще видите предупредителния екран показан на Фиг D. Той ви предупреждава че някои от възможностите на системата за сигурност ще бъдат загубени заради връзката с машина работеща под Windows XP. Няма какво друго да се направи освен да натиснете Yes, Искам да се свържа така.

Фиг D

Yes, I want to connect anyway

След това би трябвало да гледате познатия екран на отдалечения компютър.

Remote Desktop Connection 7 for Windows 7, Windows XP & Windows Vista

Microsoft blog entry that gives details on all the features available with various RDP clients on  different OSs.

http://blogs.msdn.com/b/rds/archive/2009/08/21/remote-desktop-connection-7-for-windows-7-windows-xp-windows-vista.aspx?wa=wsignin1.0

Using TS Easy Print to Redirect Printers in Terminal Services

Windows Server 2008 Terminal Services Easy Print (TS Easy Print) makes it much easier to redirect print jobs from a local client to a terminal server. John Savill shows you how TS Easy Print works and how to use Remote Desktop Connection and TS Easy Print to redirect printing.

TS Easy Print video

Виж също:

Windows 2003 Terminal Services
Windows Terminal Services Scaling
RDP Security – Designing Terminal Server Security

Windows Terminal Services Scaling

How many servers will we need for a certain application?

This document provides some insight into the servers necessary for WTS (Windows Terminal Services) or VDI (Virtual Desktop Infrastructure).

In the old days, companies had just a single mainframe and certain applications running on it. As CPU load generally is the primary bottleneck, the people responsible for the mainframe just looked at the CPU utilization and, when it was over 80%, they knew they had to buy a bigger one. When paging was too high they had to buy more memory.

Today we can run applications in many ways, and these ways all have different needs for computing power and memory.

First we look at desktops. As Windows Vista has been available since early 2007, most users found out running Windows Vista with less than one gigabyte of memory is quite slow.

When we have desktops, these should share their data. This is typically done over a file server. I have heard people say a modern server can handle 5,000 simultaneous users when this server is used as a file server.

How about Terminal Services? At the moment of this writing, most terminal servers are used by around 50 users. 32-Bit operating systems are mostly used; the problem with 64-Bit operating systems (Windows) is that not all drivers are available in 64-Bit versions. As companies have more users, load-balancing is used to connect all the users to multiple servers.

But Windows Server 2003 and Windows Server 2008 can handle many more concurrent users. In the paper on

http://www.microsoft.com/windowsserver2003/techinfo/overview/tsscaling.mspx

Microsoft says they have tested several hundred users on hardware dated 2003. As today we have more advanced hardware with fast CPUs, many cores and lots of cheap memory, I believe running terminal servers with hundreds of users is no problem. Of course, 64-bit hardware and software is needed in this case.

But some key points should be kept in mind: Windows, as well as other modern operating systems, does paging as a default configuration. Paging means, memory not frequently used is written to the page files on disk, so less memory is needed. What happens if a machine has enough memory so that no paging is needed? As Windows always tries to have some memory space available for when new applications are started, it still writes pages to disk and frees the internal memory as it is not needed. The problem today is that the gap between CPU speed, memory speed and disk speed always widens. And as we have more memory, the page file on disk gets bigger and it takes even longer to read in the requested memory pages when needed.

We have a big WTS in use for our developers, running MS Visual Studio and Eclipse. Our WTS is sometimes up for many months and users do not log off. In the evening they disconnect their RDP session. When they come in the next morning they start their RDP client and can continue to work where they left off the day before. Our users find that straight-forward. When we had paging enabled, and when applications had not been used for maybe several days, the users clicked on the icon in the task bar and had to wait maybe 10 minutes until the application was paged in and the users could work again. Sometimes the application did not show up any more, even after hours. All these problems disappeared when we turned off paging in the Windows operating system. Without paging, our system always immediately responds to every action users make. It’s a great system!

I can give the following advice: Buy so much memory for your servers that paging can be disabled. Memory is cheap and will get even cheaper. Disable paging by configuring Windows accordingly.

As you have no more paging, you do not need fast disks any longer. It is sufficient to buy big, cheap SATA disk drives instead of buying the faster but smaller and more expensive SCSI disks.

Let us talk about VDI or desktop virtualization. Using VDI means you have servers running virtualized single-user operating systems such as Windows XP or Windows Vista.

When VDI is used, multiple copies of the (guest) operating system are simultaneously in memory, so much more memory is needed. Remember that you should not have less than one gigabyte for every Windows Vista. And remember you should have paging turned off. When running VDI, I recommend you disable paging on the host level, but paging on the guest level will still be needed (otherwise you would need just too much memory). If you have a Windows Vista system and give it only one gigabyte of memory without paging, you will not be able to start many applications.

So when we have a server with 16 gigabytes of memory, we can only have around 16 simultaneous Windows Vista guests running.

So, compared to WTS, VDI needs much more hardware resources. However, there are still occasions where VDI is more suitable than WTS. And hardware keeps getting more powerful and cheaper, so VDI, in some cases, becomes more attractive.

13.08.08 Klaus Brandstätter

See also:

Using TS Easy Print to redirect print in terminal services

RDP Security – Designing Terminal Server Security

RDP Security – Designing Terminal Server Security

by Daniel Petri – December 30, 2008

Remotely accessing your servers and workstations through terminal services or RDP is an easy method of doing your job from a remote location, or gaining access to specific published applications that have been published on your servers. However, without properly investing in securing these types of RDP connections, you could be compromising the security and integrity of your servers, the data on them, and the services they’re providing.

Terminal Server usage scenarios

When planning for terminal server and RDP security we must take the terminal server usage scenario into consideration. While some terminal server and RDP deployment scenarios are created to allow full remote desktop capabilities, some allow full remote administration capabilities, while others only allow access to a specific list of line of business applications. Every scenario might pose additional security risks and thus require us to make additional changes to our security design.

Terminal Server usage scenarios include:

• Publishing Users’ Desktops – In this scenario, the Terminal Server is used to publish the users’ entire desktop, and bring all the desktop and application capabilities of the server to the remote users. The users log on to the remote desktop through RDP, use applications that are installed on the server, surf the Internet, and generally feel as though the desktop is their full personal workspace. This remote connection can be accomplished by using an RDP client (also known as an RDC client), or by using a thin client hardware. In this scenario you will need to purchase TS CALs for each concurrent connection to the server.
• Publishing selected applications – In this scenario, the Terminal Server is used to publish a few selected applications such as Microsoft Office, an ERP or CRM application, Internet Explorer windows for "Internet sharing", and generally speaking – any application that you want to be made available for the remote users. Users click on their published application shortcut (which can be a desktop icon or an Internet shortcut, depending on the method used to publish the applications). After logging on, users gain access to the published application and only to that application. There is not full desktop capability, and when the application is closed, the session ends. Here too, remote connections can be established by using RDP/RDC clients, or by using thin client hardware. Here too, you will need to purchase TS CALs for each concurrent connection to the server.
• Remote administration – Another scenario for using Terminal Server/Remote Desktop is for remote administration purposes. In most cases, passing the RDP protocol (TCP port 3389) through the corporate firewall is a lot easier than having to allow Microsoft Management Console snap-ins (MMC) or other types of management tools that use RPC and other protocols through the firewall. In this scenario, the remote administrator initiates the RDP/RDC connection and gains access to the server’s entire desktop, where they can use any locally installed application to manage the server’s services and functionality. Also, this scenario does not require purchasing TS CALs, as the RDP connection is limited to only 1, 2 or 3 concurrent connections (the number depends on the version or operating system you’re running: Windows 2000 and Windows Server 2008 only allow 2 concurrent connections, while Windows Server 2003 has 3. Windows XP and Vista only allow 1 concurrent connection).

Security Guidelines

Here are some points that you need to take into consideration when designing your terminal server security. Keep in mind that some are specific for published application usage, while others are general and should be applied to all the usage scenarios. Read through these guidelines and see which ones apply to your situation.

Note: These guidelines are listed in no particular order.

• Do not implement terminal services on a domain controller – This is one of the basics. Doing so means that you will need to allow users the "Log on locally" user right. Also, doing so means that in order to delegate management tasks for specific users on the TS servers, these users will automatically become administrators for the entire domain’s domain controllers, which is obviously a wrong thing to do.
• Design a good Organization Units (OUs) structure in Active Directory for the computer objects of the terminal servers – Using a good OU design makes it easier to link specific Group Policies (GPOs) to these OUs and have them effect all servers within these OUs. This consideration is mostly beneficial when looking at the published applications usage scenario, where it’s most likely that you’ll be using more than one TS which will be dedicated to running that role.

  

• Implement "Loopback Processing" on GPOs to control settings for users that are not in the same OU as the terminal server computer objects – This is most important when you have users from different OUs accessing terminal servers that are in another OU. When using this configuration, because user accounts log on to the servers after the servers are booted, there may be inconsistencies between the terminal server-linked GPOs and the GPOs for the user accounts. In this case, you can use the GPO loopback feature to apply Group Policy Objects that depend only on which computer the user logs on to.
• Use Group Policies to control many terminal servers – Instead of separately configuring each server, use GPOs that are linked to the OU where the server objects are located.

  

• If possible, publish a single application on each terminal server – While not always possible, this will allow you to better fine tune for security (and performance) issues that are related to specific applications.
• For specific published applications, consider pre-configuring the startup application – In order to pre-configure exactly what application is started when the user logs on to the terminal server. This setting is only useful in specific application publishing scenarios and NOT for remote administration, but using it will increase security for the terminal server.

  

• Consider implementing IPSec between the client and the terminal server – If the protection of the traffic between the clients and the terminal server is important, use IPSec to add an extra layer or security and encryption to the traffic.
• Implement data encryption on the terminal server – For Terminal Services connections, data encryption can protect your data by encrypting it on the communications link between the client and the server. Encryption protects against the risk of unauthorized transmission interception on the link between server and client. By default, Terminal Services connections are encrypted at the highest level of security available (128-bit). However, some older versions of the Terminal Services client do not support this high level of encryption. You can select the level of encryption, with higher encryption offering better security, but adding extra CPU cycles to the server.

  

• Use a mechanism to configure IP Address filtering on the terminal server – This will allow only specific IP Addresses to connect to the terminal server. To do that, you can either use the built-in Windows Firewall (depending on the version of Windows that you’re using), or a 3rd-party firewall that is installed on the servers. You can also use IPSec to implement blocking filters (In Windows Server 2008 IPSec blocking filters is a part of the Windows Firewall with Advanced Security).

  

• Properly configure your corporate firewall to only allow specific computers to connect to the terminal server – Needless to say, properly configuring your corporate firewall to block all unnecessary traffic to and from the terminal server is one of the first steps you should take to protect it. While your mileage may vary, it’s worth noting that RDP communication uses TCP port 3389, and all firewalls, routers and NAT devices between the remote clients and the terminal servers should be configured to properly allow (or block) traffic based upon your design.
• Unless required for published applications, require user credentials when logging on – The logon process can be made easier by storing the user credentials on the client’s computer as part of the RDP/RDC program. However, this means that anyone that double-clicks on the RDP/RDC shortcut will be automatically logged on to the terminal server. While useful in some cases (such as kiosk environments where casual users do not have a user name and password they can type in), it will lower your security level.

  

• Restrict RPC management access to the terminal server by requiring security – For management purposes, restrict RPC access to the TS. This is done through either a GPO linked to the OU where the TS computer accounts are located, or by using local policies.

  

• Consider limiting the active user session length – While not strictly security-related, this can add some security to a terminal server session. Be careful not to limit the active session to a time that is shorter than what your users need to perform their job.
• Limit the idle session and disconnected session time – Idle sessions should not be left open for ever, and they should be automatically terminated after 15 or 30 minutes. Disconnected sessions, on the other hand, are harder to control because of the possibility that a user’s connection has terminated due to network issues, and killing that session will result in lost un-saved data on the user’s session. I use 3 hours for application or desktop sharing, and 24 hours for remote administration scenarios.
• Disconnect from session – Should be enabled, in order to put a user’s session into "disconnect" state when a session limit is reached.

  

• Restrict reconnections of a disconnected session to the client computer from which the user originally connected – This makes it easier to prevent session hijacking, but might prove a bit of an annoyance if clients lose Internet connectivity temporarily, and when they come back online they get a different IP address than the one used in the disconnected session.
• Restrict the number of client sessions that can remain active on the server – This makes it easier to keep track of who is connected.
• Override user settings in the terminal server Configuration console – This will allow the administrator to centrally configure user session settings from one place, and not need to configure these settings on each user’s user account properties.
• Do not enable remote control on users’ sessions – Terminal server allows you to "shadow" or view users’ sessions when logged on to the server via RDP/RDC. While useful for training and help desk scenarios, this also means that administrators can view users’ sessions, possibly exposing themselves to private and confidential information.

  

• Use granular permissions to control who can connect to the terminal server – Typically, default settings are adequate for regular TS deployments, however in order to increase security you should consider manually changing the scope of users and groups that are allowed to log on to the TS, and what they can do. For example, who can reset a connection, who can remote control another session, and who can send messages to other concurrent sessions.

  

• Limit users who can log on remotely – Only allow certain users remote desktop access, even when using RDP on a regular workstation. Make sure that you only allow the users who you want to be able to log in remotely.

  

• Possibly prevent administrators from logging on through RDP – In some cases, when remote users only need to run specific applications, you might want to configure the local policy of the server/workstation to prevent administrators from logging on through RDP/RDC.

  

• Consider limiting the applications that a user can access on the terminal server – Especially useful for full desktop access, you can use Group Policy to limit the list of applications that can be opened by a user on the terminal server. Also consider preventing access to some of the command-line tools found in the %systemroot%’system32 folder – applications such as subst.exe, xcacls.exe, xcopy.exe, cmd.exe, format.exe, regini.exe, reg.exe and similar.
• Set an account lockout policy – There are tools that will use brute-force to guess passwords and log-on remotely. You cannot totally stop this, but you can minimized it by setting an account lockout policy. If someone tries to guess the password, then after a few guesses they will be locked out for a period of time.

  

• Change the TCP Port for the terminal server listening port – You can change the terminal services port from 3389 to another port by changing a registry key. Please see my "Change Terminal Server Listening Port" article.
• Consider implementing a secure remote access infrastructure by using VPN to protect the transmitted data and prevent Man In The Middle attacks – Regular RDP connection provides encryption for the data that is sent between the terminal server and the client computer. However, this kind of connection does not provide authentication for the terminal server. In order to mitigate some of the security issues, you should consider implementing a VPN tunnel between the clients and the terminal server. See my "Record Secure Remote Access SSL VPN Gateway Sessions" article for more information.

  

• Consider enabling Transport Layer Security (TLS) to authenticate the terminal server and to encrypt the data – As noted in the above item, regular RDP connection does not provide authentication for the terminal server. Instead of using a VPN tunnel, you may want to make sure that your terminal server is correctly authenticated before you connect to it. Furthermore, you cannot verify the identity of the terminal server you’re connecting to. By using Windows Server 2003 Service Pack 1 or higher together with Transport Layer Security (TLS) you can increase terminal server security.

  

• When using Windows Server 2008 Terminal Server, consider using TS Gateway – Using the new capabilities of Microsoft Windows Server 2008 TS Gateway provides further protection of RDP traffic by encapsulating it into SSL packets – much like SSL VPN, but without the need to deploy special VPN servers. The benefit of using the TS Gateway capabilities of Microsoft Windows Server 2008 is that remote users will only be granted access to the internal servers based upon a strict policy that can be enforced on the TS Gateway, and when combined with the NAP capabilities of the system, will only allow connection of computers that fully meet the security requirements set by the administrator.
• Monitor Log Files – The Event Viewer logs failed login attempts and account lockouts. Monitor the event log for such events.

Conclusion

Without properly securing terminal server connections you could compromise the security and integrity of your servers, the data on them, and the services they’re providing. By following the above guidelines you will be able to protect your data and applications.

Виж също:

Windows 2003 Terminal Services

Windows 2003 Terminal Services (Part 1)

Terminal Services, known to some as an Admin’s best friend, uses RDP (Remote Desktop Protocol), relies on TCP/IP, and falls under the application layer of the ISO 7-layer model. It has been improved by offering more features, greater reliability and scalability in Windows 2003.

• Published: Mar 08, 2004
• Updated: Jun 16, 2006
• Section: Articles & Tutorials :: Windows 2003
• Author: Andrew Z. Tabona
• Printable Version
• Adjust font size:
• Rating: 3.9/5 – 588 Votes
• For more information about Windows Terminal Services, please visit MSTerminalServices.org.

Introduction

Terminal Services, known to some as an Admin’s best friend, uses RDP (Remote Desktop Protocol), relies on TCP/IP, and falls under the application layer of the ISO 7-layer model. It has been improved by offering more features, greater reliability and scalability in Windows 2003.

Terminal Services allow:

• the sharing of applications and desktops over the network
• administrators to take control of, and manage, a computer from their desk
• the centralization and management of applications (constantly keeping them up to date)

The ability to access a terminal server and establish a session via a Pocket PC, for example, is a great feature that would be handy for employees on the move. Terminal Server does not require the client to have a Microsoft Windows operating system in order to connect to it.

A 128 bit, RC4 bi-directional encryption method is used to secure the connection. Should the terminal services client not support such a high level of encryption, then lower levels can be set.

A few of the most sought after advantages include:

• Automatic re-connection of a disconnected session (useful for wireless connections)
• Smart Card Authentication support
• Automatic re-direction of client local and network mapped drives
• Automatic re-direction of Audio
• 24-bit color mode support
• Session Directory (stores a list of sessions indexed by username and server to allow automatic re-connection from a disconnected session, in a terminal server farm environment)

However, a disadvantage would include the fact that although Windows 2003 and Terminal Server offer load balancing, this can still be improved. The current system is based on network utilization and can handle up to 32 servers.

A very important feature which has been implemented is the way in which bandwidth is managed for a terminal services session. It has been improved to provide low-bandwidth connections (such as dial up) with better performance by only transmitting a screen view of the remote computer, rather than the actual data itself.

To benefit from these new features, the terminal services client must be using RDP 5.1 (included in Windows XP) and the server must have RDP 5.2 (included in Windows 2003).

Setting up Windows 2003 as a Terminal Server

Open the ‘configure your server’ wizard from Administrative Tools and in the select a role section, choose Terminal Server and click Next twice to confirm your actions. The wizard will then start to install the required files and warn you that the machine will have to be restarted during the installation process. Close any open programs and click OK.

The installation will continue for a few minutes before the machine is restarted. After the machine has booted and you logon, you are presented with a confirmation screen that states the computer is now a terminal server.

It is important to take note that a 120-day evaluation period has been allocated for unlicensed clients. If you do not obtain a license within that period then terminal services clients will no longer be able to initiate a session.

Licensing

This is probably where the most changes have been made. Microsoft have introduced a ‘per user’ license to add to the already familiar ‘per device’ method.

To make your machine a terminal server license server you will have to install it separately. This can be done from the windows components wizard section in the add/remove window from the control panel.

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.

Terminal Server Configuration

The two main applications used to configure the terminal server are:

(They can both be found in the administrative tools folder in control panel or on the start menu).

• Terminal Services Manager (completely re-written in Windows 2003)
• Terminal Services Configuration

Terminal Services Manager

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. If you select a user and right click you can disconnect or reset the user’s session, send a message (which will be displayed as a pop-up message box on the client side), view the status or log the person out of the terminal server session.

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).

Select a user, click the right mouse button and choose ‘end process’ to kill the process.

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.

‘Favorite servers’ will list all the servers that you have added as a favourite – you can do this by right clicking a server and selecting ‘add to favorites’.

You are able to connect to multiple terminal servers by press Actions > Connect to computer. These will be listed in the ‘All Listed Servers’ node.

Terminal Services Configuration

The screenshot below is that of the Terminal Services Configuration.

Any connections that have been setup will be displayed in the connections part of the console. Double click a connection to open the properties page.

The following table will describe what actions you may take on each tab.

Tab

Description

General

add a comment, change the encryption level, enable standard windows authentication

Logon Settings

select whether or not to always use the same credentials for logging on, enable ‘always prompt for password’

Sessions

select whether to override the user’s settings with a set of predefined settings

Environment

choose to override settings of a user profile and run a program when the user logs on

Remote Control

change the way the remote control facility is used, disable remote control

Client Settings

change connection, colour and mappings settings

Network Adapter

specify the type of network adapter you want to use and change the connection limit

Permissions

specify the user permissions (who has access to the terminal server and who doesn’t)

The server settings section enables you to modify the settings of the server. Double click a setting from the list to bring up the appropriate window and be given the option to make a change.

Each setting shown in the above window is self explanatory. The settings in the list each have an attribute which you can set according to your preferences.

Terminal Services give you the opportunity to provide a secure and reliable tool to employees. Microsoft has built on the success of Terminal Server in Windows 2000 and come up with new solutions to meet user’s needs.

Better manageability and user friendliness are just two of the improved features worth mentioning. You have just been reading Part one of an article based on terminal services. Part two will be released next week. It will include troubleshooting potential logon problems, terminal services tips and a guide on how to log on to a terminal server from a Windows client.

A Windows 2003 Terminal Server can be accessed by a windows client that has Remote Desktop Connection installed or via a web browser (remote desktop web connection).

Troubleshooting Logon Problems

Apart from the obvious logon error of typing in a wrong username or password, there exists two common problems that users come across when logging on. These are shown below.

The local policy of this system does not permit you to logon interactively.

This error indicates that the group policy of the terminal server does not allow you to logon interactively. The settings will have to be changed from the group policy object editor by your administrator.

To do this, open gpedit.msc and navigate to the following section:

Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment

and after double clicking on the “Allow Log on Locally” from the Policy list, choose the user that you want to grant local log on access to and press OK. The image below indicates which section must be clicked on.

You do not have access to logon to this session.

The error message below means that you do not have access to logon to the terminal services session because your account has not been given the effective permissions from the terminal services manager on the server.

To correct this, open the Terminal Services Configuration, double click the RDP option in the main window and go to the permissions tab. Select Add and choose your account before pressing OK and assigning the right permissions to that account. Now attempt to logon again with that user account.

Terminal Services Client Logon – A step-by-step guide

Web Client

The terminal services web client will allow you to logon to a terminal server from your web browser. This is very handy as it provides quick and easy access from anywhere.

Open your web browser and in the address bar type the following details:

http://server_name/tsweb

where server_name is the name of the terminal server (this can also be the IP address). If the WWW service and the tsweb website has been started on the server then you will be directed to a page like the one seen below:

Enter the name of the server you want to connect to and choose the size of the screen before clicking ‘connect’. If you do not already have the required ActiveX component installed then you will be prompted to install it – click Yes when the window pops up and asks you to confirm the setup. In my example I have chosen for the screen to use a 800×600 display size. The web browser will act as a place holder for the terminal services screen to be displayed, as shown in the following screenshot.

Remote Desktop Connection

Remote Desktop Connection is installed by default on Windows XP- but can also be downloaded as a separate application from the Microsoft website. This is used to initiate a terminal services session from the client side. To open it type mstsc in the run box or navigate to Accessories > Communications on the Start menu.

The image below shows the general tab of the Remote Desktop Connection window, which was expanded by pressing the Options >>> button on the original window.

In this tab you can save your connection settings for future use, specify which computer you want to connect to and supply the logon credentials. The other tabs are used for performance related options like the display size and colour, speed and placement of resources.

Once you have entered the correct logon details press connect to initiate the session. It is likely that you will be asked to re-enter the logon credentials – unless the administrator has disabled the option from the terminal server.

10 Tips

1. If you want to connect to a terminal server via the command prompt you can do so by typing the following: “mstsc -v:servername /F –console”. ‘mstsc’ represents the remote desktop connection executable file, -v specifies which server to connect to, /F is for full screen mode, and –console to indicate that you want to connect to the console.
2. If you need to install a terminal services client for the MAC OS you can download it from here. Once it is setup, (given that you have network access and the right permissions) this will allow you to connect to a windows-based operating system running terminal services from a Macintosh computer.
3. You can allow users to automatically logon to a session without having to type the username and password each time they initiate a connection. To do this two things have to be done.
   • From the server side, open Group Policy Object Editor (gpedit.msc), double click Administrative Templates > Windows Components > Terminal Services and then choose Encryption and Security. Open the properties box of ‘Always prompt client for password upon connection’ and disable it.
   • From the client side, open Remote Desktop Connection, and in the general tab enter the logon credentials in the appropriate boxes.
4. The web client can be installed from the Add/Remove windows components. Go to the World Wide Web components section in the IIS 6.0 option. From there you can find and install Remote Desktop Web Administration.
5. Available in the Windows 2003 resource kit is a self-extractable file called tsscalling.exe. This contains a set of tools that will aid with the scalability planning of terminal services.
6. Each application you run uses up valuable resources, which might be needed by other users so close any programs or windows that you are not actively using.
7. If you want to remotely restart a terminal server on the network you can use the tsshutdn command. The syntax is as follows:
   tsshutdn wait_time /server: server_name /reboot /powerdown /delay: log_off_time
   wait_time is the number of seconds you want to wait before the user is logged off from a session. The default time is 60.
   server_name specifies the name of which terminal server you want to shutdown.
   log_off_delay is the amount of time to wait, after users have been logged off from the session, before all processes are ended and the computer is shutdown. The default time is 30 seconds.
8. Instead of just disconnecting from a session or closing the remote desktop window, log off – this will free up resources for other users.
9. By default, Terminal Services runs on TCP and UDP port 3389. If for some reason you have to change that you can do so by open the registry editor (regedit.exe) and navigating to the HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlTerminalServerWinStationsRDP-Tcp key. Look for the DWORD PortNumber and edit that to your needs.
10. Run disk defragmenter on the terminal server to keep the disk clean, fast and ‘healthy’.

That concludes part two of the Windows 2003 terminal services article.

If utilized correctly, terminal services can be a quick, safe and reliable tool that will allow application sharing and remote administration to become part of the package that benefits an organization and allows administrators to be more flexible.

For more information about Windows Terminal Services, please visit MSTerminalServices.org.

Конфигуриране на SQL Server Express за отдалечен достъп
RDP Security – Designing Terminal Server Security
Windows Terminal Services Scaling