Remote, Terminal, and Assisted Computing for Windows Hosts

A Windows XP or Windows 2003 machine is "over there" and you want to use it as if you were sitting in front of it. What are you going to do? Again, that's the idea of remote computing. When we're on a Windows or Linux guest, we'll show you how to connect to that machine in the basement that doesn't have a keyboard, monitor, or mouse.

Additionally, Windows 2003 servers can house applications, such as Microsoft Office or your own home-grown application, and run them on behalf of dozens of guests. This is the terminal computing scenario. We'll show you how to do that, as well as talk about the major add-on here, Citrix.

Finally, when a user logs on to a Windows XP or Windows 2003 machine and runs into difficulty, they have the ability to ask for help. This is the "assisted computing" feature we mentioned earlier. Alas, the Linux RDP guest application isn't smart enough to accept such a call for help from a Windows host, at least not yet. We'll show you how to work around this problem using VNC.

Remote Computing for Windows Hosts

Remote computing is built right in to Windows XP and Windows 2003. You do have to turn it on, however. Microsoft made this a feature that you turn on only if you need it, and for good reason. Turning off remote access features by default is always a sensible security practice.

In this section, we'll first demonstrate Windows-to-Windows remote computing, just to make sure it's all working properly. Then, we'll set our sights on how a user on our Linux guest adlincli1.ad.corp.com or any other Linux client can remotely log on and interact with a virtual desktop on the host windc1.ad.corp.com , one of our Windows servers. Since windc1.ad.corp.com happens to be a Domain Controller, we'll have to take an extra step or two to enable remote computing on it.

Enabling Windows Remote Desktop on a Windows Host Computer

Windows XP and Windows 2003 can remotely connect to one another. To make this happen, the following pieces must be in place:

Windows Remote Desktop must be enabled on the Windows host.
If the Windows host is joined to Active Directory, the right user must be expressly granted rights to log on remotely.

In our example here, we'll enable Remote Desktop on windc1.ad.corp.com (but it can be any Windows XP or Windows 2003 system). To enable Remote Desktop for a Win dows host:

Click the "Start" menu.
Right-click "My Computer" and select "Properties."
Select the "Remote" tab.
Check the "Enable Remote Desktop on this computer" box, as shown in Figure 8.1.

Figure 8.1: You can enable Remote Desktop for either Windows XP or Windows 2003 systems.

From here, you should now click the "Select the Remote Users" button and add the users you want to allow to connect to this system. By default the Administrator is the only one with remote access, but as you can see in Figure 8.2, we've added salesperson2 and salesperson3 .

Figure 8.2: Here, add in the users to which you explicitly want to grant remote access.

If this Windows host was a regular file server or a Windows XP machine, you'd be done. But because windc1.ad.corp.com is a Domain Controller, there's an extra security measure in place to ensure that mere mortals cannot log on there. This is because of the extra-sensitive nature that Domain Controllers have. In real life, you wouldn't normally be granting salesperson3 the ability to log on via Remote Desktop to your Domain Controller. No, no, no. That would be bad. However, WinDC1 is the only Windows 2003 server in our lab, so together, we'll be bad, bad, bad and circumvent Windows' security to allow salesperson3 to log on. If you don't do this step, when you try to make a connection (using the steps in the next section), you'll get the error shown in Figure 8.3.

Figure 8.3: This is the error you will receive unless you expressly add the users you want to allow to remotely connect to a Domain Controller.

To specifically enable RDP connections for users logging on to Domain Controllers:

Log on to the Domain Controller as Administrator.
Select Start Programs Administrative Tools Terminal Services Configuration.
Click the "Connections" folder, and in the right-pane, right-click the item called "RDP-Tcp," as shown in Figure 8.4. Select properties to open up the "RDP-Tcp Properties" dialog, also shown in Figure 8.4.
Click the "Permissions" tab and then click the "Add" button. Add the Active Directory user you want to specifically allow access to this Domain Controller. In the Permissions list, select User Access in addition to Guest Access. This permits the user to obtain information about the session, send messages to users in other sessions, and connect to another session. Then click "OK."

Figure 8.4: Because this is a Domain Controller, you need to expressly add the users (or groups) of users you want to allow to remotely connect.

You'll get a message saying that changes you've just made will only take effect for the next time someone remotely connects. Click "OK," then proceed.

Ensuring Windows XP can Connect via RDP to Windows 2003

To connect to windc1.ad.corp.com as salesperson2 or salesperson3 , simply log on to any Windows XP machine as anyone . Then select Start All Programs Accessories Communications Remote Desktop Connection, as shown in Figure 8.5. You'll get a window called "Remote Desktop Connection," also shown in Figure 8.5.

Figure 8.5: The Remote Desktop Connection applet lets you remotely connect via RDP to other Windows machines.

In the Remote Desktop Connection applet, clicking "Connect" after adding the computer you want to connect to performs the magic. At that point, you'll be able to provide your credentials and virtually be there.

Connecting a Linux Guest to a Windows Host (Installing rdesktop and tsclient )

When Linux needs to connect to a Windows host, our Linux workstation requires appropriate software. Handily for us, Fedora includes everything we need. All we have to do is install it using the familiar Add/Remove Applications tool, which we've seen many times in this book.

In the course of this chapter we will use three Linux client applications:

rdesktop Is used for RDP connections. It's analogous to the Windows Remote Desktop client we just played with.
Uncviewer Is used for VNC connections. We won't be using this right away, but since we're here installing software anyway, there's no time like the present to install this one too.
tsclient Is the "terminal services client" that acts as a convenient front end to both of the preceding and launches the appropriate one as needed. While it doesn't integrate as tightly with rdesktop and vncviewer as we'd like, it does make them easier to start. And installing tsclient on a Fedora system automatically installs rdesktop and vncviewer as well, which saves us a few check boxes of effort.

To install tsclient and rdesktop on adlincli1.ad.corp.com , follow these steps:

Select Applications System Settings Add/Remove Applications.
Scroll down to the "System" category and click the "Details" link to the right of "System Tools."
Check the box next to " tsclient ." This automatically installs rdesktop and vncviewer as well.
About the Citrix ICA Client for Linux
Citrix makes software that rides on Windows Terminal Services to add a slew of additional features. It can provide load balancing features, centralized application deployment features, and a super-duper protocol called ICA (Independent Computing Architecture) that is more efficient than Microsoft's RDP. For instance, ICA performs better with video than RDP does, and it supports individual application sharing (instead of having to share a whole honkin' desktop).

The Linux application tsclient appears to have support for acting as a front end to the Citrix ICA client for Linux, if it is installed. However, in our tests, this did not work. Apparently, the current version of tsclient passes command-line arguments that the current version of the Linux ICA client does not like.

You can, however, run the Citrix ICA client directly if you need it. It is not included with Fedora Linux, but you can download an rpm of the official Linux client from www.citrix.com . Once you install that rpm with the usual rpm installation command:
```
 rpm -i rpmfilename.rpm 
```
you can then configure and use the client with the following command:
```
 /usr/lib/ICAClient/wfcmgr 
```
For more information, see the Citrix website.
Click "Close" to return to the "Package Management" screen.
Click "Update." After a delay, the "Completed System Preparation" dialog appears.
Click "Continue" to begin the actual installation process.
Insert CDs when prompted, as usual.
Click "OK" when the installation is complete.
Click "Quit" to leave the Add/Remove Applications tool.

That's it! We now have the tsclient (Terminal Server Client) software available on our Linux guest computer. Now we're ready to make our first connection as a guest.

Connecting a Linux Guest to a Windows Host with Terminal Server Client

We have everything we need to make a terminal computing connection between Linux and Windows with the rdesktop guest application via the Terminal Server Client front end. Let's take the plunge!

In our example, we'll connect to windc1.ad.corp.com . The Terminal Server Client software calls this the "Computer:" field. We'll log on as the Active Directory user salesperson1 with the usual password. Since Terminal Server Client and rdesktop are smart enough to understand Windows authentication domains, we'll specify that this user is in the AD domain. In this scenario, we'll assume that the user is an administrator logging on to carry out administrative tasks on windc1.ad.corp.com without the need to physically sit in front of it. Other users can also log on remotely, as long as they have been granted this right on the server.

One annoyance you'll be sure to notice: the "Password:" field in Terminal Server Client isn't good for much. In our experiments, both rdesktop and vncviewer prompted us separately for a password regardless of what we entered in the Terminal Server Client password field, so you can save yourself some typing and leave that field blank. Or, if you like, test it out to see if this has been improved in later updates of Fedora Core 3 or 4.

To make an RDP connection from a Linux guest to Windows Remote Desktop on a Windows host, follow these steps:

Select Applications Internet Terminal Server Client.
The "General" tab of the "Terminal Server Client" dialog box appears as shown in Figure 8.6. In the "Computer:" field, enter windc1.ad.corp.com .
Set the "Protocol:" pull-down menu to "RDP."
In the "User Name :" field, enter administrator .
Leave the "Password:" field blank (you will be prompted later). In the "Domain:" field, enter AD .
Leave the "Client Hostname:" and "Protocol File:" fields blank. Click "Connect."

Figure 8.6: Making a Windows Remote Desktop connection from Linux to Windows using the Terminal Server Client application. The "Password" field didn't seem to do much for us in our experiments.

After a few moments (or a bit longer if your connection is not over a local network), you should see a standard Windows logon prompt with the password field blank. Enter p@ssw0rd and click "OK" to log on.

Shortly thereafter, you will see salesperson1 's desktop on windc1.ad.corp.com , as shown in Figure 8.7. Just click in the "Terminal Server Client" window to interact with the remote desktop exactly as if you were sitting at the console of windc1.ad.corp.com .

Figure 8.7: Remote computing accessing a Windows host from a Linux guest workstation using RDP and the rdesktop application, started from Terminal Server Client

When you are finished, log out of the Windows desktop as you normally would. Alternatively, you can disconnect by clicking the "X" (close window) button in the upper-right corner, in which case the desktop remains available for reconnection.

Tip	You can configure how Windows hosts react to disconnected sessions by using the "Sessions" tab as seen in Figure 8.4.

Terminal Computing for Windows 2003 (Windows and Linux Users Running Windows Applications Remotely)

Recall the preceding remote computing examples (where we allowed salesperson2 and salesperson3 to connect to our Windows 2003 server). When we did this, Windows permitted a maximum number of two connections to our server. That's right: a maximum of two. That's because remote computing is really meant to let administrators remotely manage their boxes in the basement or the server cabinet.

Terminal computing is a logical extension of remote computing. You can think of terminal computing as "more users doing remote computing." It provides true multiuser access, even to the same application. Five users can log in to separate accounts, and each can run Microsoft Word to edit their own documents, without interfering with one another. Windows does support this, but it's optional. In Figure 8.8, you can see how to optionally add the licensed Terminal Server components of Windows:

On Windows 2003, make sure you're logged in as Administrator
Select Start Control Panel Add/Remove Programs.
Select "Windows Components."
In the "Windows Components" screen, select "Terminal Server" and "Terminal Server Licensing."

Figure 8.8: Since Windows Terminal Services is an optional component, you must also add licensing services somewhere on your Windows network.

Space prevents us from delving in to setting up Windows Terminal Server and Terminal Server Licensing. However, here are some references to you get on your journey if you want to set up a full-fledged Windows Terminal Server:

Windows Terminal Services by Christa Anderson, Sybex 2002 www.sybex.com .
Terminal Services Home Page on TechTarget Lots of good stuff, including a lot by the well-known Terminal Services goddess, Christa Anderson: http://tinyurl.com/77eme .
Brian Madden Brian is a one-man Terminal Services deity. There are books, training classes, and more at www.brianmadden.com/

Again, this is a licensed option. If multiuser terminal computing of Windows and Linux clients is desired, you must pay up. No licenses mean no love, though there is an initial grace period of 120 days to get compliant. Afterward, the server will reject requests to open simultaneous connections if a license server is not available that has been configured to dispense Terminal Server Client access licenses.

Also available is the third-party Citrix Metaframe that rides on top of Windows Terminal Services both technically and for licensing. Yes, that's right. If you want the features of Citrix Metaframe, you need to first license your clients for Windows Terminal Services, then also pay for the Citrix Metaframe licenses. Citrix provides a gaggle of add-on features, the two biggest being their leaner ICA protocol and their ability to manage a lot of applications over a large number of servers. Be sure to check them out at www.citrix.com .

Assisted Computing for Windows Hosts (Linux Users Helping Windows Users)

When a Windows XP user needs help, there's a built-in function called "Remote Assistance" that enables the distressed user to get help from another Windows XP user.

This is a lengthy and interesting subject, but the Linux RDP client doesn't support it, and since we're mostly interested in where Windows and Linux collide, that's what we'll explore here. However, you can learn more about Windows XP's Remote Assistance here:

A while ago I (Jeremy) did a webcast about this subject. You can watch it at http://tinyurl.com/c2a26 . (Be sure to disable any pop-up blockers beforehand.)
Microsoft has a step-by-step guide to Remote Assistance at www.microsoft.com/techne t/prodtechnol/winxppro/maintain/rmassist.mspx (or, get to it via the shortened URL http://tinyurl.com/4aw3g ).
Microsoft's Remote Assistance FAQ is at www.microsoft.com/windowsxp/using/helpandsupport/rafaq-general.mspx (or, get to it via the shortened URL http://tinyurl.com/b7vc3 ).

Microsoft's Remote Assistance relies on "invitations" to the person providing the help, and Linux's rdesktop guest application does not know how to interpret these. So, in mixed Windows and Linux environments (where you want folks on Linux machines to help out Windows users), Microsoft's built-in Remote Assistance isn't going to work.

Instead, we recommend setting up the Virtual Network Computing (VNC) software in advance of the problem. This software works great for assisted computing purposes, so we'll use it instead.

In this section, we'll demonstrate how a user ( salesperson1 ) on a Windows machine can get help from a user ( salesperson2 ) on a Linux machine, using VNC.

Note

We'll specifically discuss VNC on Linux later, but it's worth noting that VNC is available for many systems, including Macs. That includes clients for handheld devices from many vendors . You can find more information about VNC for other operating systems at this page, maintained by RealVNC but offering links to many other sites: www.realvnc.com/resources.html .

Requirements for Assisted Computing on Windows Hosts

Now, we're ready to get up so that our Linux clients can remotely assist our Windows boxes. To make assisted computing happen from a Linux guest to a Windows host, the following pieces must be in place:

VNC server software must be installed on the Windows host. There are several distributions of VNC software for Windows. The package we'll use is called TightVNC. See the sidebar "VNC Distributions for Windows and Other Platforms" for a comparison of the two most common VNC packages for Windows.
The firewall on the Windows host must be adjusted to allow connections on the VNC port, which is TCP port 5900.
The vncviewer VNC guest application and the tsclient front-end software that makes it more convenient to use must be installed on the Linux guest. If you followed the "Remote Computing for Windows Hosts" section, these packages should already be installed. If you did not, refer to the section "Connecting a Linux Guest to a Windows Host (Installing rdesktop and tsclient )".

VNC Distributions for Windows and Other Platforms

Each of these packages includes both a Windows server and a Windows client. In both cases, Linux clients and servers are also available, but we'll use the perfectly adequate VNC client and server included with Fedora on the Linux side.

RealVNC RealVNC is directly descended from the original AT&T Laboratories VNC software. RealVNC "free edition" is available free of charge under the terms of the GNU General Public License (GPL). The Personal Edition, which is not free, offers fully encrypted sessions. The Enterprise Edition also supports Windows authentication, avoiding the need for a separate VNC password. More information about RealVNC is available from www.realvnc.com/

TightVNC TightVNC is an alternative open source distribution of VNC, specifically focused on reducing the bandwidth requirements. TightVNC also offers improvements to the user interface for configuring VNC clients and servers. TightVNC is a good example of open source licensing at work. The original VNC was released under the GPL, so the authors of TightVNC were able to improve on it and share their work under the same free license. TightVNC compresses the data stream more than other VNC products, which can be important over dial-up links. This benefit only comes into play if the client and server both run TightVNC. If they run different versions, the connection still works but falls back to features included in the original VNC protocol, which still works just fine, especially for local network and broadband Internet connections. We will be using TightVNC in this chapter because all of its features are available free of charge. More information about TightVNC is available from www.tightvnc.com/ . However, if you fall in love with what VNC has to offer and your budget permits, we recommend you check out the RealVNC Enterprise Edition. Since it can use Active Directory for authentication, you won't have an additional password to rememberand built-in encryption is also an extra-nice thing to have.

Installing and Configuring TightVNC on the Windows Host

We'll set up the TightVNC host software on xppro1.ad.corp.com and use the standard Fedora vncviewer guest application on adlincli1.ad.corp.com to access the desktop of the other computer, providing live assistance to a console user who can also see everything that is happening. While we're at it, we'll find it convenient to also install the TightVNC guest software (known as the VNC "viewer"), which we'll use later in this chapter.

For installation purposes, we'll log on to xppro1.ad.corp.com as the Administrator, who has the necessary privileges to install applications. Then we'll download and install the TightVNC software from the TightVNC website. After TightVNC is installed and running as a service, we can log in normally as any user, and it will always be possible to log on and provide assistance via VNC with the appropriate password.

TightVNC uses a password to control who gets access to remotely control or view your PC. If these passwords get into the wrong hands, it could be the start of a very bad day for you. The password is encrypted on the network but only obfuscated on the local hard drive. And an obfuscated password is just as bad as a plaintext password, so TightVNC Server isn't likely a true enterprise solution. Our suggestion is to check out the Enterprise Edition of RealVNC, which hooks in to Active Directory and can specify which Active Directory users can take control.

Setting up the TightVNC host software, known as the TightVNC Server, is very straightforward. There are just two decisions to be made:

Do we want to run TightVNC as a Windows service? Windows services, like Linux daemons, run in the background and are always present on the system. This is useful when we want VNC logons to always be possible on a particular system. We'll choose to enable this option in our walkthrough. It is also possible to launch the TightVNC Server application on an as-needed basis from the Start menu.
What password scheme do we want? TightVNC has two potential passwords: one for remote control and the other for "view-only" access. In our upcoming example, we'll suggest the same password for both, but you may choose to offer view-only access for training purposes. There is no hard limit on the number of "spectators" simultaneously watching a VNC session. For our tests, we used the password p@ssw0rd , but in a production environment your VNC password should be well- chosen and kept secure. Remember that the VNC password provides full access to the console.

Warning

If the Administrator is logged into the console, the VNC password is as good as the Administrator password! Choose accordingly .

To install TightVNC on xppro1.ad.corp.com , follow these steps:

Log on to xppro1.ad.corp.com as Administrator.
Launch Internet Explorer.
Access the website www.tightvnc.com .
Click "download" to proceed to the download page.
Click the link to download the setup program for the latest stable version. As of this writing, it's tightvnc-1.2.9-setup.exe .
A list of mirror download sites appears. Find the mirror closest to your location and click the download link at right (not the name of the company hosting the mirror).
Save the file tightvnc-1.2.9-setup.exe to disk when prompted.
When the download is complete, launch tightvnc-1.2.9-setup.exe .
The TightVNC Setup Wizard will appear. Click the "Next" button to leave the introductory screen.
On the "Information" screen, review the license terms and click "Next."
On the "Select Destination Directory" screen, click "Next" to accept the default installation location.
On the "Select Components" screen, leave the server, viewer, and documentation options checked, and click "Next."
The "Select Start Menu Folder" screen appears. Click "Next" to accept the default name, "TightVNC."
On the "Select Additional Tasks" screen, check "Register TightVNC Server as a system service" and "Start or restart TightVNC service." Click "Next" to proceed.

Review the "Ready to Install" screen and click "Install."

Note	During the final steps of the installation process, you may see messages indicating that the "WinVNC" service has been installed. This message is left over from the open source WinVNC code on which TightVNC is based.

The message "The WinVNC Service was successfully registered" will appear. Click "OK."
The message "WARNING: This machine has no default password set. WinVNC will present the "Default Properties" dialog now to allow one to be entered." will appear. Click "OK."
The "WinVNC: Default Local System Properties" dialog appears, as shown in Figure 8.9. Set the "Password:" field to p@ssw0rd . Also set the "Password (view only):" field to p@ssw0rd .
Click "OK" to dismiss the dialog.
The "Completing the TightVNC Setup Wizard" screen will appear separately while you are still working with the dialogs of the TightVNC Server service. That happens because the service is running as a separate application. You may click "Finish" on this screen at any time.

Figure 8.9: Setting up the TightVNC host software to allow Linux guests to assist the user of a windows host

Firewall Configuration for VNC on the Windows Host

Our Windows host is ready to accept VNC connections, but since Windows XP/SP2 disables most inbound connections with the Windows Firewall, we need to take some action.

Inbound RDP connections (which we discussed earlier) aren't a problem. This is because Windows Firewall expressly permits these connections. However, for VNC we'll need to explicitly tell Windows to open the VNC port. The standard VNC port number is TCP port 5900.

To allow VNC connections through the firewall on xppro1.ad.corp.com , follow these steps:

Select Start Control Panel.
Double-click "Windows Firewall."
Select the "Exceptions" tab.
Click "Add a Port."
The "Add a Port" dialog appears, as shown in Figure 8.10. In the "Name:" field, enter VNC .
In the "Port number" field, enter 5900 .
Select the "TCP" option.
Click "OK" to dismiss "Add a Port."
Click "OK" again to close "Windows Firewall."

Figure 8.10: Adding a firewall rule allowing traffic on the VNC port 5900 to reach the Windows host

Connecting a Linux Guest to a Windows Host with VNC

We're ready to demonstrate how a Linux user can assist a Windows user with VNC. The Windows host is already configured to allow this, and the Linux guest already has the necessary guest applications.

The vncviewer VNC guest application and the tsclient front-end software that makes it more convenient to use should already be installed on the Linux guest. If you followed the "Connecting a Linux Guest to a Windows Host (Installing rdesktop and tsclient )" earlier, these packages will already be installed. If you did not, be sure to go back before continuing.

We'll encounter one minor annoyance when making the connection. Although Linux's Terminal Server Client front-end application supports VNC as the transport, any password entered in Terminal Server Client is not actually passed to the vncviewer VNC guest application. Frustrating, but livable. We'll just skip entering the password in "Terminal Server Client's Connection" dialog and wait until we are prompted for it separately by vncviewer .

Here are the steps to make a VNC connection from a Linux guest to our Windows host, so that salesperson1 (on Linux) can assist salesperson2 (on Windows):

Log out of xppro1.ad.corp.com as Administrator and log back in as salesperson2 .
Log into adlincli1.ad.corp.com as salesperson1 .
On adlincli1.ad.corp.com , select Applications Internet Terminal Server Client.
The "General" tab of the "Terminal Server Client" dialog box appears as shown in Figure 8.11. In the "Computer:" field, enter xppro1.ad.corp.com .
Set the "Protocol:" pull-down menu to "VNC."
Leave the "User Name:" "Password:" and "Domain:" fields blank. Also leave the "Client Hostname:" and "Protocol File:" fields blank. Click "Connect."
The "VNC Authentication" dialog appears, as shown in Figure 8.12. Enter the VNC password that you set in the "TightVNC Default Local System Properties" dialog and press Enter. The "Username" field is not used with TightVNC, so it is disabled.
The Windows desktop appears, as shown in Figure 8.13. salesperson1 can now use the keyboard and mouse to operate the host Windows desktop while salesperson2 observes from his seat at the host console.
When salesperson1 is through assisting salesperson2 , she can disconnect by clicking the "X" (close window) button in the upper-right corner of the vncviewer window.

Figure 8.11: When VNC is used as the transport for Linux's Terminal Server Client application, the password field isn't passed through to the VNC viewer, so we leave that field blank. We will be prompted for the password separately later.

Figure 8.12: Entering the VNC password is a separate step when making a VNC connection from Linux to Windows using the Terminal Server Client application.

Figure 8.13: Assisting the user of a Windows host from a Linux guest workstation using VNC and the Terminal Server Client application

We've succeeded in accessing Windows hosts from Linux guests, both for assisted computing and for remote computing. As far as the Linux guest is concerned , the solution for terminal computing is the same as that for remote computing. But what about the opposite scenario? How can Windows guests access Linux hosts? The short answer: VNC (again!). Read on for the long answer!