IE7 RDP web client fix


We have a security appliance that manages user passwords.  One feature of this appliance is it can initiate a RDP session to a Windows box and pass the user’s credentials for authentication, which allows the users to access the remote system without knowing their password. 

This appliance uses the Remote Desktop Web Connection ActiveX control, and works great with Internet Explorer 6 and Internet Explorer 8.  It does not work with Internet Explorer 7 at all in our environment.
 
When trying to initiate the RDP web connection in IE7, the RDP Transparent Connection window has a red X on it, and the following error message is shown:
 
Remote Desktop Web Connection ActiveX control could not be installed. A connection cannot be made without a working installed version of the control. Please contact the server administrator.
 
The fix for this problem is:
 
Download and install the Remote Desktop Web Connection for Windows Server 2003 (actually for XP clients) on the IE7 machine.
 
The Remote Desktop Web Connection for Windows installer will create
the C:\InetPub\wwwroot\TSWeb\ directory.  Within that folder you will find the msrdp.cab file.  
 
Extract the msrdp.cab file, and place the two extracted files ( msrdp.inf  and msrdp.ocx ) in the C:\Program Files\Internet Explorer\PLUGINS directory.
 
Finally, you’ll need to registered the msrdp.ocx file using the following syntax:
 
regsvr32 “c:\program files\internet explorer\plugins\msrdp.ocx”
 
I restarted IE, and was able to successfully use the Remote Desktop ActiveX control without issue.  Tested on Windows XP SP2.
Thanks to Ster who pointed me in the right direction.

Microsoft releases load simulation tools for desktops


Microsoft has released their Remote Desktop Load Simulation Tools which have nothing to do with Remote Desktop in the RDP sense.  Instead, the tools are designed for 32-bit and 64-bit server capacity planning and performance/scalability analysis.  According to Microsoft:

In a server-based computing environment, all application execution and data processing occur on the server. Therefore it is extremely interesting to test the scalability and capacity of servers to determine how many client sessions a server can typically support under a variety of different scenarios. One of the most reliable ways to find out the number or users a server can support for a particular scenario is to log on a large number of users on the server simultaneously. The Remote Desktop Load Simulation tools provide the functionality which makes it possible to generate the required user load on the server.

Supported operating systems are:

  • Windows Server 2008
  • Windows Server 2008 Datacenter
  • Windows Server 2008 Datacenter without Hyper-V
  • Windows Server 2008 Enterprise
  • Windows Server 2008 Enterprise without Hyper-V
  • Windows Server 2008 for Itanium-based Systems
  • Windows Server 2008 R2
  • Windows Server 2008 R2 for Itanium-based Systems
  • Windows Server 2008 Service Pack 2
  • Windows Server 2008 Standard
  • Windows Server 2008 Standard without Hyper-V

(Notice the lack of Windows 2003 support?)

A minimal test environment requires:

  1. Target Remote Desktop Server
  2. Client Workstations
  3. Test Controller Host

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