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: Remotely disconnect a Terminal Services Session, Part 2


Previously I discussed two methods for remotely disconnecting a terminal server session.  Today I discovered another way do disconnect my Windows 2000 server from my Windows XP workstation.  Here’s how I did it:

1) Launch a command prompt

2) Authenticate to the server:
net use /user:administrator \\MyServer\c$

3) Type:
reset session 1 /server:MyServer

Start with session 1 and keep incrementing this number if you receive the message “session ID 1 not found”. You will not receive any notification when a session is successfully terminated, but you will receive a message if the session doesn’t exist.

Once a session has been freed you can logon to the terminal server as normal and kill any additional sessions through Terminal Services Manager.

Howto: Remotely disconnect a Terminal Services Session


[update 2008-08-06]
I’ve written about another method for remotely disconnecting a terminal server session can be found here.

Windows server 2000/2003 allows two remote terminal services connections for administrative purposes.  Every once in a while I’ll get the “You exceeded the allowed connection count” message when trying to connect to a server via RDP, because previous sessions were not disconnected correctly.

You can use either of the following methods to remotely disconnect Terminal Server sessions.

Method 1

You can normally run the Terminal Services Manager program on another server, or even from a Windows XP workstation, to disconnect Terminal Services connections by clicking StartRun and then typing

%SystemRoot%\system32\tsadmin.exe

This will launch the local copy of Terminal Services Manager.  Next right click on All Listed Servers and select Connect to Computer.  Type in the name or IP address of the server you wish to manage. 

 All Listed Servers in Terminal Services Manager

Select your server from the left pane, then select the Sessions tab from the right pane.  Right click on the session you wish to disconnect and select Disconnect.

You should now be able to login to the target server via Terminal Services.

Method 2

Authenticate to the server you wish to manage.  You can easily accomplish this by mapping a network drive to a share on the target server.  Start a command prompt and type

qwinsta /server:yourservername

where yourservername is the name or IP address of the server you wish to manage.

In my case I ran qwinsta /server:10.0.0.2

You can see the Administrator account is logged into session 0 and the admin account is logged into session 1.  To disconnect the admin session with ID=1 I’ll run the following from a command prompt:

rwinsta ID /server:yourservername

where ID is the process ID of the sesstion you wish to terminate, and yourservername is the name or IP address of the server you wish to manage.

In my case I ran rwinsta 1 /server:10.0.0.2

I again ran qwinsta /server:10.0.0.2 which verified session 1 had been disconnected.  I confirmed that I was once again able to login to Terminal Services.

Thanks to Ingo for some of the information, which I found via Andy.