Fix: rdpclip.exe won’t run on Windows Server 2003


I had two identically configured Windows 2003 SP2 servers, one that would allow remote copy/paste from the server to the client via RDP, and one that wouldn’t.  I finally took the time today to resolve the issue once and for all.

First thing I verified was that in the Local Resources tab of Remote Desktop Connection (mstsc.exe)  the connection was set to connect to remote disk drives.
 
I noticed was that rdpclip.exe was running in task manager on the server that allowed copy/paste, but was not running on the problem server.  Manually executing rdpclip.exe didn’t make a difference in behavior, it wouldn’t even briefly show as a running process in task manager.  I figured this was the problem, but didn’t know how to resolve it.
 
Next I verified the following registry keys were identical on both servers:
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\AddIns\Clip Redirector]
“Name”=”RDPClip”
“Type”=dword:00000003

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\SysProcs]
“rdpclip.exe”=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\Wds\rdpwd]
“StartupPrograms”=”rdpclip” 

Some blog posts suggested the following three services needed to be running in order for interaction with the clipboard viewer that stores the copied data – but they were stopped and disabled on my good server, so I knew that wasn’t the issue.
  • Network DDE DSDM
  • Network DDE
  • ClipBook
I found a nice post on the Terminal Services Team Blog that explains how the clipboard viewer chain can be broken and how to resolve the problem based on observed symptoms, but this really didn’t apply to my situation.
 
Finally I found this post that describes if the HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\Winstations\RDP-Tcp registry key has the  fDisableClip value set to 1, rdpclip.exe will terminate because clipboard mapping is disabled.  I compared the registry and found that on the server I could successfully copy/paste to and from, this value was 0.  On the problem server, this value was set to 1.
 
On the problem server I changed the 1 to a 0, terminated my client’s remote desktop session and reconnected, and was once again able to copy and paste to and from remote servers!
 
See Benny Tritsch’s nice page detailing the most important Terminal Server registry keys and values, which outlines the fDisableClip setting and many more.

A Portable Remote Desktop Connection (mstsc.exe)


I ran across Claus’s link to the makeuseof.com article that shows how to run Microsoft’s Remote Desktop Connection program as a portable application from a USB drive.

This lead me to think about how this could be of value in my environment.  I frequently hop from server to server using Microsoft’s Terminal Services client, mstsc.exe, which is built into Windows XP, Windows 2003 and newer operating systems.

My Windows 2000 servers can be accessed though RDP, but since do not have the updated client on them, I had not been able to run mstsc from the Windows 2000 server itself.
 
The makeuseof.com article lists four files that need to be copied in order to run Remote Desktop from a USB drive:  mstsc.exe and mstscax.dll, plus mstsc.exe.mui and mstscax.dll.mui.
 
I copied the first two files from my Windows XP SP2 machine up to my Windows 2000 server.  The second two .mui files did not exist on my Windows XP machine, probably due to the version of the OS I am running.
 
Once the files were copied up to my server I double clicked mstsc.exe, and was able to use the Windows 2000 server as a Terminal Services Client.  This will allow me to break my reliance on VNC and Terminals as Remote Desktop Clients on older OSs.

Fix: Intel PROSet for Windows Device Manager missing tabs


I’ve been building some new Dell PowerEdge 1950 servers for a new deployment running Windows Server 2003 SP2.  I had originally configured the servers to use the integrated Broadcom NICs, but wanted to change to my new Intel Quad Port VT 1000 PCIe card.  I went with the quad port since I was planning on doing some teaming/link aggregation, and have always had sporadic at best luck with the Broadcoms.  My server only had one free slot for the NIC, and since a dual port card was not available I had to go with the quad port.

Intel PROSet is traditionally configured through a Control Panel applet, but the current version is integrated directly into the NIC configuration, so it can be setup inside Windows Device Manager.  

I RDP’d into the server using the Broadcom NIC’s IP address, installed the intel drivers from the Dell support site, accessed the NIC inside Device Manager, and saw the four tabs I was used to seeing.  After a server reboot, I still saw the usual four tabs in device manager and no Advanced Network Services (ANS) configuration for PROSet.
 
I tried a different driver off the Dell site, which still did not allow me to view the ANS settings.  I moved onto drivers directly from Intel, but my situation did not change despite uninstalling, rebooting, and reinstalling the drivers.
 
I finally ran up to the data center and physically moved the cables from the Broadcom NIC to the Intel NIC.  Since the Intel NICs did not have the static IP assigned to them like the Broadcom did, and I had no idea what address DHCP had assigned to them, I accessed the server via the DRAC remote access card.  When I went into Device Manager I could see the additional ANS tabs that would allow me to configure the teaming!
 
I disconnected from the DRAC and reconnected via RDP.  No teaming options appeared.  I then connected to the server console by running mstsc /console, and the teaming options were there!
 
The moral of the story appears to be you must be connected to the server console in order to see the PROSet ANS settings inside Device Manager.  I assume this is so administrators do not accidently lock themselves out of the server when remotely configuring the NICs.

Howto: Install rdesktop on SLES 10 SP2 Linux


rdesktop is software that allows a Linux client to connect to a Microsoft Windows server via RDP, much like mstsc.exe, which is Microsoft’s Remote Desktop Connection (RDC) program.

More precisely, rdesktop.org describes the software as:

rdesktop is an open source client for Windows Terminal Services, capable of natively speaking Remote Desktop Protocol (RDP) in order to present the user’s Windows desktop. Supported servers include Windows 2000 Server, Windows Server 2003, Windows Server 2008, Windows XP, Windows Vista and Windows NT Server 4.0.

rdesktop currently runs on most UNIX based platforms with the X Window System.

To install rdesktop on SLES 10 SP2: 

1) Make sure all pre-requisites are installed on the system.  If they are not, add with YaST or download them.
 
2) Extract the rdesktop package. From a terminal window run
gzip -d rdesktop-1.6.0.tar.gz
tar -xvf rdesktop-1.6.0.tar
 
3) From the directory you extracted rdesktop run
./configure
 
4) From the directory you extracted rdesktop run
make
 
5) From the directory you extracted rdesktop run
make install
 
rdesktop will be installed by default to /usr/local
 
to run from a terminal
rdesktop [options] server
 
for example
 
rdesktop -u admin -p passwd 192.168.1.1
 
Would establish a RDP connection to server 192.168.1.1 using admin’s credentials
 
The most commonly used  options are:
 
–u username specifies the user name for authentication on the server.

–p password provides a password for authentication on the server. To keep others from seeing the password supplied on the command line, use –p – to read the password from stdin.

–g geometry allows you to specify the desktop geometry. This can be given as a resolution, such as 1024×768 or as a percentage of the entire screen, as in 70%.

–r device enables device redirection, allowing you to redirect a device, such as sound from the remote machine to the local one. This feature requires Windows XP or newer.

Fixes for known issues when compiling and installing rdesktop
 
“ERROR: Could not find X Window System headers/libraries
To specify paths manually, use the options –x-includes and –x-libraries”
 
FIX: add the X-windows development tools though YaST to compile successfully – x-org-x11-devel
 
ERROR: Could not find OpenSSL headers/libraries.
To specify a path manually, use the –with-openssl option
 
FIX: add the OpenSSL development tools through YaST to compile successfully – openssl-devel

Howto: Log Connections to Specific Ports and Processes on Windows Machines


A client asked me for a report that showed who connected to his server on port 3389 via RDP, Microsoft’s Remote Desktop Protocol . Apparently some of his techs had been connecting to his servers through the Microsoft Remote Desktop Connection (RDC) to perform maintenance, and he wanted to know when they connected to the server and where they connected from.

I figured I could enable RDC logging through a registry hack, but couldn’t find a documented solution anywhere. Finally I found a few tools available from Microsoft that I could use to do the job.

The first tool I used was the Microsoft Port Reporter utility. This program installs as a service on Windows XP and Server 2003. It does generate a large amount of log files, so make sure to configure the log file location on a drive with plenty of free disk space per KB 837243, which has detailed installation and usage instructions.

The Port Reporter service is initially set to manual startup, so you’ll have to start it yourself in services.msc. Once the service is running, three detailed log files are created. These files can generate an overwhelming amount of information, so to help you decipher all the data Microsoft released the Port Reporter Parser Tool.

The Port Reporter Parser Tool turns the log file data into a sortable spreadsheet. You can sort and filter the sheet based upon factors such as date, time, local and remote IP and port, Process ID, account name, etc. See KB 884289 for specifics on analyzing logs and tracking suspicious data. You can do so many things with Port Reporter that Microsoft even created a support webcast for the utility. See KB 840832 for more information.

Once I had my Port Reporter log file loaded into Port Reporter Parser, I filtered my data to show only rows where the connection to the local port was made on TCP port 3389. Port Reporter Parser made me a nice report showing all data regarding RDP connections to the server.

My only complaint with Port Reporter Parser is I couldn’t save my filtered queries or export them to a .csv or similar format.

Microsoft also has some related tools to Port Reporter –PortQry and PortQuery UI. See KB 832919 for instructions on using PortQry. Other applicable KB articles include:

KB 310456 – How to Use Portqry to Troubleshoot Active Directory Connectivity Issues

KB 310298 – How to Use Portqry.exe to Troubleshoot Microsoft Exchange Server Connectivity Issues

KB 325494 – Support WebCast: Port Scanning Using PortQry

KB 890381 – TechNet Support WebCast: TCP/IP port and process auditing