Fixing SBS 2003 RWW for Console Access From XP SP3, Vista SP1 and Windows Server 2008

Sick of waiting for Microsoft to release a fix to RWW to enable Console access to SBS 2003 and any other Windows Server 2003 systems connected to your SBS network? So am I. So I’ve fixed it. Process is as follows:

Navigate to C:\Inetpub\Remote

Make a copy of tsweb.aspx

Open tsweb.aspx in your favorite editor (mine’s Notepad++)

Line 304 looks like this:

MsRdpClient.AdvancedSettings2.ConnectToServerConsole = console

 

Replace it with this:

version = MsRdpClient.Version
if strcomp(version,"6.0.6001") < 0 then
  MsRdpClient.AdvancedSettings2.ConnectToServerConsole = console
else
  MsRdpClient.AdvancedSettings2.ConnectToServerConsole = false
  MsRdpClient.AdvancedSettings6.ConnectToAdministerServer = console
end if

 

Save the changes. You can now establish console sessions to your SBS 2003 box and any other Windows Server 2003 boxes on your SBS network.

If anyone’s got a better way for displaying code in a Blogger page I’d be interested in knowing about it.

SBS2003 Remote Web Workplace, Console Access and That Awful /admin Change

OK, those of us that have worked with SBS2003 for quite some time tend to put Remote Web Workplace (RWW) right up there on our list of favourite SBS features.
The best feature I like is the pre-authenticated access to enable RDP proxy to the servers in the SBS network (although the use of port 4125 can be a pain behind some firewalls). The "Log on to or resume the console session of the remote computer" allows me to effectively remotely manage the server as though I was on site.

This is particularly useful when dealing with programs that require Session 0 - commonly known as console - access (for a concise description of terminal services history and session 0, see the Terminal Services Sessions: Then and Now article or the Wikipedia Terminal Services entry).
Over the last few months, I'd been finding that the Patch Tuesday reboots on the boxes I'd been RWW'ing to had resulted in hung systems, similar to what Susan Bradley's September 2006 blog entry records. Today, I saw the Ask the Performance Team's blog entry on The Reboot that Wasn't. This seemed to detail exactly what was going on with me, but I'd been enabling the "Log on to or resume the console session of the remote computer" option. So surely this wasn't my problem - or was it?
So I did some digging. I picked a Windows Vista RTM box, a Windows Vista SP1 box, a Windows Server 2003 SP2 box and a Windows Server 2008 box. I tried RWW'ing to my SBS 2003 box on each of them with the "Log on to or resume the console session of the remote computer" option set.
The results were as follows:

Windows Server 2003	Session 0
Windows Vista RTM	Session 0
Windows Vista SP1	Session 1
Windows Server 2008	Session 1

What's going on here? Shouldn't that be Session 0 for all those RWW clients?
No, not exactly. The problem we're seeing here is that the Remote Desktop Client (version 6.1) found in Windows Vista SP1 and Windows Server 2008 has dropped the /console switch and replaced it with /admin. The description of this change can be found in MSKB 947723 and also at the following Terminal Services Team Blog entry (same entry as the KB article, but with user comments). This change also extends to the programmatic interfaces that RWW uses.
As I commented in the Terminal Services Team Blog entry, this change was unwarranted, as the /console switch could have been left alone and have the code handle graceful fallback from the security-enhanced console access in Vista SP1 and Windows Server 2008 to the Session 0 access in Windows XP and Windows Server 2003.
So, the Terminal Services team has broken console access from RWW. Doesn't say much for the QA process when an entire product feature that relies on the Remote Desktop Client isn't tested for regression.
So what can be done to mitigate this? Well, you can use something like CopSSH on the SBS box and ssh to it, then use an ssh tunnel to connect to the SBS box using RDP (a how-to guide can be found on this Remote Desktop and SSH page). Or you can allow direct RDP access to the SBS 2003 box, which is very useful if you're running the Premium Edition and using ISA Server as you can leverage the ISA Server lockdown mode - which means you get RDP access when ISA's in lockdown and you can also tighten up RDP access to a restricted set of computers when ISA's running normally. For Standard Edition, or non-ISA Premium Editions, RDP restriction should be done by your firewall device.
For a hardware solution, something like an iBoot remote power management device might be useful to help with those hang on shutdown problems.
Anyway, patching over RWW can be problematic - see the Repeat after me.... you don't patch over RWW blog entry and the Some months you can't patch over RWW blog entry for some reasons why patch over RWW is bad.

Recovering Public Folder Items Easily in Exchange Server 2003

I occasionally get requests from clients and colleagues asking me to recover Public Folder items from Exchange Server 2003.

Thankfully for me I performed the ultimate fubar while performing a test migration from NT4.0 + Exchange 5.5 to SBS 2003 Premium back when SBS 2003 first came out. That's right, I managed to blow away the majority of the Public Folder store in one fell swoop, simply because I wasn't following my own instructions properly and wasn't used to the new Exchange System Manager interface.

Thankfully, I had just been getting familiar with the new capabilities of Outlook Web Access and had used the Recover Deleted Items feature to get familiar with it and to be able to instruct clients on how to use it.

I didn't really want to have to spend the time re-copying the Public Folder store from the Exchange 5.5 install, so I looked for the Public Folder equivalent of the Recover Deleted Items feature for the mailbox. It appeared to be missing. Or was it?

I had noticed that the Recover Deleted Items window had essentially opened the Deleted Items folder in the mailbox and had set a URL variable. The variable and its setting was:

cmd=showdeleted

Being the lazy kind of guy I am - as well as being inquisitive - I thought I would give some link hacking a try. I opened up the Public Folders link, navigated to the parent folder of the folder I deleted, right-clicked on the parent folder and selected Open in new... This opened the folder in a new window. The URL of this folder was of the form:

https://server/public/Public%20Folder/?Cmd=contents

I then replaced contents with showdeleted. The URL then looked like:

https://server/public/Public%20Folder/?Cmd=showdeleted

Ta da! The folder I trashed was now visible and capable of being recovered, which saved me additional copying time. Sometimes screwing up a test environment is a great way to learn a new, lazy technique :-)

New Business Web Site

I finally upgraded the single page Melbourne IT-hosted site to a self hosted site for my business.
Because I'm a Microsoft registered partner and have access to the Microsoft Action Pack, I decided to see if I could build my own site using Expression Web. I used one of the corporate templates and was able to quickly build my site with my own content. I had installed Expression Web on my Vista laptop, so my initial design was only viewed using IE7.
I then proceeded to use Virtual PC to load up a Windows XP VM to test IE6 and I downloaded Firefox 2.0, the PortableApps version of Firefox 1.5, Opera 9.22 and Safari for Windows 3.0.3. The site displayed correctly under all these browsers! For someone who's used previous versions of FrontPage, I was fairly impressed to see consistent rendering across all browsers and proper handling of hand coding by the IDE (ie, by leaving it alone!).
It certainly took me less time to get the site up using the template and modifying it than hand coding it from scratch.
My final verification was to run the W3C Validator, the Validome Validator and the WDG Validator over the site. There were a couple of problems, but these were ones that I had introduced into the site. Microsoft's claim of "Built-in support for today's modern Web standards makes it easy to optimize your sites for accessibility and cross-browser compatibility" - while not rigorously tested by my effort - is backed up by the browsing consistency I saw as well as passing the three validators I used.

Outlook Web Access 2003 New E-mail Problem

One of my clients contacted me to say that their Distribution Lists weren't working in Outlook Web Access 2003. Due to the roaming nature of staff and the lack of Outlook installed on the PCs, I was unable to get them to switch to Outlook to check if the problem occurred there.

I spent a bit of time on it earlier this evening, only to find that I got a cryptic "The item could not be found. It may have been deleted" error pop up when trying to send an e-mail to a Distribution List created in the user's Contacts.

OK. Back to basics. I created a new Distribution List and added the addresses one by one. Wouldn't you know it, the problem only reared its ugly head on the last email address. Interestingly, the same problem occurred when I entered in the email address into a new message.

I looked at the Contact entry with the associated email address and found the cause of the problem - there was a trailing space at the end of the email address. I backtracked the cause of the error - an import of e-mail addresses from Alt-N's WorldClient created a trailing space for each imported address. How very nice of the Exchange Migration Wizard to create Contact entries with invalid email addresses. Grrr.

Looks like I'll be writing a script to strip trailing spaces from the email fields of the Contact entries...