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.

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: Enable Remote Desktop on a Windows 2008 Server Core System


Windows 2008 Server Core uses the SCregEdit.wsf script found in C:\Windows\System32 to configure Terminal Services (TS) behavior. TS is the method of remote controlling your Server Core system through Remote Desktop (RDP).

To view the current Terminal Server settings for Vista/Windows 2008 clients, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR /v

The following values correspond to the response generated by the scregedit.wsf script.

1 = Terminal Services Disabled (remote access disabled)

0 = Terminal Services Enabled (remote access enabled)

To enable Terminal Services access from Vista/Windows 2008, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR 0

To disable Terminal Services access from Vista/Windows 2008, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR 1

Note:

The /AR setting applies to Windows Vista/2008 machines. If you want to allow Terminal Services connections to the Windows 2008 server from Windows XP machines, you have to use the /CS switch.

To view the current Terminal Server settings for Windows XP clients, at the server command prompt type:

c:\windows\system32\scregedit.wsf /AR /v

To enable Terminal Services access from Windows XP, at the server command prompt type:

c:\windows\system32\scregedit.wsf /CS 0

To disable Terminal Services access from Windows XP, at the server command prompt type:

c:\windows\system32\scregedit.wsf /CS 1

You could also edit the registry directly to enable Terminal Services using the same registry entry I wrote about when describing how to enable remote access for Windows XP machines remotely.

Finally you will need to create a hole in your server’s Windows Firewall for inbound RDP traffic on port 3389. KB 947709 details how to use the netsh advfirewall firewall command to configure the firewall in several different ways. I suggest running the following at the server command prompt:

netsh advfirewall firewall set rule group=”remote desktop” new enable=yes

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