Life after MS02-047: Making Web-Based Remote Desktop Work

Why server administrators really want to read those bulletins

Alex K. Angelopoulos

Some people using web-based Remote Desktop/Terminal Services access who had automatic updates set up for Internet Explorer (and don't read the bulletins describing what they do) got a surprise after a recent round of Internet Explorer patches: the Remote Desktop Client OCX embedded in web pages suddenly failed to work on sites where administrators had failed to install an updated version closing off the vulnerability documented in MS02-046, designed to work after the patches for Internet Explorer documented in MS02-047 were installed on IE clients.

The failure of the client is also detailed very precisely in the Knowledge Base:

Q328002 - You Cannot Connect to Terminal Services from a Web Page

And the original vulnerability documented in MS02-046 is also covered in:

Q327521 - MS02-046: Buffer Overrun in TSAC ActiveX Control Might Allow Code Execution

Let's talk about what you need to do to fix this; the most important issue is

Making Sure This Never Happens Again

The problem in a nutshell is this: people have been telling Microsoft they have concerns about security, and Microsoft is now taking a hard line on all security issues.  If you ask for products to be automatically updated and patched, they will be given security patches.

If you subscribed to Microsoft's security bulletins and at least skimmed them, you knew what was happening before the first patch went out over the wire. If you didn't, you aren't alone; I spent 3 days tracking down portions of this problem and then found the information all wrapped up neatly in MS02-046 and MS02-047.  Much as I would like to, I can't complain about my wasted time.  Microsoft has told us that security is fast-tracked; Microsoft has told us that it is a top priority; and Microsoft warned us about the issue and the patch in the freely available bulletins before the patch ever went out over the wire.

The fix? GET THE SECURITY BULLETINS. It takes only a few seconds to read the summary information and know whether or not it affects you.

The Short Story On The Fix

The problem must be fixed on the server.  An administrator should download and install the updated version of the TSWeb package and read the download page carefully. It contains everything that needs to be done on the vast majority of systems. Getting clients to roll back is NOT a good idea.

In some cases - if you are using a customized connect.asp page or were using the web client on a LAN with locked-down workstations -  you may need to take a couple of extra steps to hook everything back up.

If that applies to you, I've documented the process and some workarounds for special situations.

Fixing Custom Environments

There are really 2 parts to the resolution.  One is an update on the system serving the client control and is a necessity for making things work again.  The second part is updating the control on the client system; this should happen automatically, but on systems with restrictions in place may take an extra step.  I will step through both parts of this for you.

Updating the Server

The procedure below will walk you through fixing the problem and then discuss some secondary issues you may have.  In a nutshell, you need to install an updated web client control for users to download, then modify the OBJECT reference to said control in any custom pages you use. 

  1. On the system with the TSWeb setup, you need to install the updated version of the TSWeb package.

    XP Systems: The web package update defaults to installing in C:\Inetpub\wwwroot\TSWeb, no matter where your files really are already!  You should redirect it to C:\Windows\Web\TSWeb (or wherever your TSWeb folder really is if different).  The following short script can be used to display that folder for you if you run it as a VBS file on your webserver.

    'Webclients.vbs
    Set Sh = CreateObject("WScript.Shell")
    sData = Sh.Regread( _
     "HKLM\SOFTWARE\Microsoft\TS Web Clients\InstallDir")
    WScript.Echo "Web Clients folder is", sData
    Sh.Run "%COMSPEC% /c start " & sData & "\.", 0
     
  2. One issue MAY affect you after that, but it can be fixed easily. If you are using "connect.asp" to log on, you won't be able to since that file does not get updated. Here's how you handle that.  On the server, open that file up in a text editor and look for the OBJECT tag in the file. Change the CLSID and CODEBASE attributes there to this:

    CLASSID="CLSID:9059f30f-4eb1-4bd2-9fdc-36f43a218f4a"
    CODEBASE="msrdp.cab#version=5,1,2600,1095"

    Any other pages you use - such as manyservers.htm - should be modified also to point to this new client.  To simplify things, here are links to zipped copies of connect.asp and manyservers.htm.

    Note: printer redirection needs to be enabled manually as well. In connect.asp find the window_onLoad procedure and add this line to it to get printer redirection going:
    MsTsc.AdvancedSettings2.RedirectPrinters = TRUE
     
  3. There is a residual problem with potential client version overwrites which you may want to prevent.  The original version of the TSWeb control was in a file named mstscax.cab.  Consequently, the cab file is not overwritten on the server during the control upgrade process.  I suggest removing that file completely; if you don't and somehow miss a reference to it in a page then you may break the control install on client systems.  This is important because the new GUID prevents IE from identifying the old msrdp.ocx as a prior version of a currently installed control.
     
  4.  Printer and Drive Redirection.  Finally, printer redirection works against Windows 2000 servers and drive redirection against XP/.NET systems - but the new control has them disabled by default.  The downloadable connect.asp I provided turns this on for you.

    If you don't use that page but do have custom web pages, you must set this on within the web page by using the control's AdvancedSettings2 interface before connecting to the server.  For example, if the ID for the control in the web page is "MsTsc", then the following two lines within the window_onLoad or body_onLoad event handler will set up your redirection:

    MsTsc.AdvancedSettings2.RedirectPrinters = TRUE
    MsTsc.AdvancedSettings2.RedirectDrives = TRUE

Once this process is complete, the TSWeb folder will be passing out pages and a control that fully patched IE systems can use.

Updating the Client

I know, you got into this mess by updating the client, right?  Well, chances are if you are doing automatic updates and your client systems allowed end users to do software installs, the client will automatically download the new version of the control. This will not work until the server has been updated as outlined above. Once again, for most situations having an administrator patch the server as outlined by Microsoft will completely take care of client issues; a new client control will be automatically downloaded the next time the server is contacted.

You may have a problem on domains with classic security in place, though.  NT family systems prevent anyone but administrators from installing an ActiveX control such as the web client; once and administrator installs it, anyone can then use it.  There are also erratic reports of problems with the install, usually due to other configuration issues on the client system. We'll step through a process that covers handling all the major problems which could occur; as soon as you get the control working, you can ignore the rest of the procedure.

Note: this process is outlined for Windows XP Professional (which uses IE6).  Depending on the client OS and IE version options may vary slightly.

  1. Log on to the client system as an administrator.
  2. Navigate to the web page which hosts the control and attempt to start a client session.
  3. If you get the Terminal Services/Remote Desktop logon screen, you're done; the control has downloaded and autoinstalled.  If not, we have more work to do.
  4. If it doesn't work, you may be having a problem with IE silently refusing to download controls from the hosting site.  Go into Internet Options | Security and add the host to your Trusted Sites.  Make sure that the security for Trusted Sites will at least prompt you to download controls. After configuring this, quit all running instances of Internet Explorer and try 2-3 again.
  5. If this doesn't work, the control may be damaged.  Go to Internet Options | General and click the Settings... button. On the Settings page, click View Objects... and look for any Remote Desktop or Terminal Services controls.  Right-click each of them and select Remove from the context menu. Again, when you are done exit the Internet Options applet, close all instances of IE, and try to connect.
  6. If that doesn't work - or if there were no controls in place - you may need to manually download and install the control.  That is an unattractive option, but it will work.  Here's how you do it.
  7. Manually download the control. Let's say the web page your clients connect to is http://www.foo.bar/TSWeb/connect.asp. In that case the control is at http://www.foo.bar/msrdp.cab, and you can manually download the cab file by just typing that in IE's address bar or Start | Run.
  8. Extract msrdp.ocx from the msrdp.cab file.  Usually you can just double-click to open the CAB, then drag the OCX out.  On older systems or ones where certain zip utilities have been installed you may have problems with this; in that case, you will need to open a command prompt in the directory where you have the CAB file and run the following command:
    extract msrdp.cab msrdp.ocx
  9. Copy the OCX to a "permanent" storage location where it won't be accidentally deleted.  Open a command prompt and type the following:
    regsvr32 msrdp.ocx
    which should register the OCX and give you a message confirming that it succeeded.
  10. Close all instances of IE and go back to the web page again.  It should now work.

In certain circumstances, it may be necessary to deploy the web client to a large number of systems at once. If this applies to you, take a look at my page Creating an Install Package for the Web Client.  It briefly discusses some easy ways to do this, and includes a link to a pre-assembled MSI package for the OCX that can be deployed via AD or WMI.

Back to main Terminal Services page