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.

Sophos Enterprise Console - Stuck on Connecting to Server

I have a problem on an SBS 2003 Premium Edition box (2 NICs and running ISA Server) where launching the Enterprise Console sits forever at the connection screen.



This is the same problem even if I perform a console-only install to a separate box.

The drastic remedy is to reboot the server. By using the console on a separate box I was able to use TCPView to find that EnterpriseConsole.exe was connecting to MgntSvc.exe on the server.

I then tried stopping the service from the command line:

> net stop "Sophos Management Service"

Which resulted in me being told that the service could not be stopped. I then used PsKill to stop the service:

> pskill "Sophos Management Service"

And I then restarted the service:

> net start "Sophos Management Service"

This then allowed me to successfully use the Enterprise Console.

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.

SBS 2003 Media, Service Packs, Repair Install - Oh My!

This has been a long-running battle I've had with Microsoft over the years - the inability to either roll my own slipstreamed SBS media, or obtain slipstreamed SBS media at reasonable cost (like the Volume License media kits).

Why would I want to roll my own or access low-cost SBS media, you ask?

Well, if you ever have to do a Repair Install of your SBS box and you've added a Service Pack, you're hosed. The Repair Install will undo the service pack applied to the once-working box, and on reboot will give you a lovely blue screen. The only way around this is to restore from the last full backup, or re-image from your favorite imaging tool of choice (two listed below if you're not already using one).

Thanks to the wonderful advances of products like Acronis True Image and ShadowProtect, performing Repair Installs are a thing of the past, especially if you're using Repair Install to migrate a Retail SBS install to new hardware. The hardware independent restore capabilities of these products makes a full backup / minimal install / full restore / repair install redundant, as well as a lot slower.

But it's a pain if you don't have these, so make sure you have SBS media from the same channel (OEM, Retail or Volume License) with the Service Pack you're running already slipstreamed. Or simply don't install Windows Server 2003 Service Packs to SBS 2003 boxes.

Modifying SBS 2003 SP1's bkprunner.exe for Improved Backup Performance

I'll quickly jot this down before I forget.
I've recently been having a shrinking backup window on one of my client's SBS 2003 boxes. It backs up to tape and I didn't want to create a backup script and lose the nice reporting features that SBS provides. So I hacked the bkprunner.exe process instead :-)
On my own SBS 2003 box I was getting terrible server performance during my daily backup to USB drives. I found the undocumented /FU switch that was included with the SP1 version of ntbackup and some registry modifications that the Exchange team of Microsoft IT performed to improve their backup performance.

Open Explorer and go to "C:\Program Files\Microsoft Windows Small Business Server\Backup"
Make a copy of bkprunner.exe

Download and extract XVI32.
Run XVI32.exe
Open bkprunner.exe in XVI32

The address range $10F0-$11B7 is used for backups to .bkf files
The address range $11B8-$1277 is used for backups to tape

To turn off verify when backing up to a .bkf
Go to address $113A
In the hex pane (the middle one), type in the following hex values:
6E 00 6F 00 20
This enters in the text "no " in Unicode format.

To turn off buffered writes (as explained in MSKB 839272 and also here) when backing up to a .bkf - recommended
Go to address $115E
In the hex pane (the middle one), type in the following hex values:
46 00 55 00 20 00 20 00 20 00 20
This enters in the text "FU " in Unicode format.

To turn off verify when backing up to tape
Go to address $1202
In the hex pane (the middle one), type in the following hex values:
6E 00 6F 00 20
This enters in the text "no " in Unicode format.

Registry modifications for performance
Run regedit
Open HKEY_USERS
Load Hive
Open SBS Backup User's NTUSER.DAT registry hive; call the key name BACKUP
Browse to HKEY_USERS\BACKUP\Software\Microsoft\Ntbackup\Backup Engine.
Edit the value of the entry Logical Disk Buffer Size from 32 to 64.
Edit the value of the entry Max Buffer Size from 512 to 1024.
Edit the value of the entry Max Num Tape Buffers from 9 to 16.
If the above keys don't exist, create them as String values.
Click on HKEY_USERS\BACKUP
Unload hive

Small Business Server 2003 - The Dreaded 5 CAL Reset Issue

A runaway process on SBS2003 decided to fill up all the disk space on C: in the early hours of the morning. The fallout from this was the System log was corrupt and the SBS license data was reset to the default 5 CALs.
The System log was easy to fix - reboot the server.
The SBS license data was an absolute pain. I'd never run the "Back up licenses" utility in the Licensing section of Server Management. Microsoft have KB article 888818 discussing this, which is either re-enter the licenses, restore the C:\WINDOWS folder or restore a backup of the licenses.
The first wasn't an option as I was offsite and the person with the key to the safe wasn't in. The second was just not viable - why Microsoft couldn't specify which file/folder needed restoring I don't know. The third would have been OK if ever I had run it.
After much stuffing about I found that the SBS2003 licenses are kept in the licstr.cpa file in the WINDOWS\system32 folder. Thankfully, Microsoft actually keep an automatic backup of this in autolicstr.cpa. The simple process was to stop the License Logging Service, rename licstr.cpa to licstr.cpa.old, then copy autolicstr.cpa to licstr.cpa. After this I started License Logging Service and used Server Management to confirm that the licenses had been restored.

DHCPServer 1010 1014 1016 Errors

I've recently installed a server at home and installed SBS 2003 SP1 Premium Edition on it. Everything went smoothly and I eventaully set up the Monitoring to send me daily reports. I started to get concerned with the DHCPServer 1010, 1014 and 1016 errors that were occurring daily. Backing up and restoring the DHCP database didn't work, chkdsk /f /r didn't show any errors, and hard drive diagnostics were fine. Memory testing was also fine. I removed Anti-spyware and Anti-virus software. Still no difference.

With much grinding of teeth, the occasional expletive and the desire to smash something out of the way, I continued the Googling to find an answer. Lo and behold, there was a thread in the newsgroup microsoft.public.windows.server.sbs which talked about turning off indexing on the %WINDIR%\System32\DHCP folder. I decided to give this a go by going into the folder properties, clicking Advanced on the General tab and disabling "For fast searching, allow Indexing Service to index this folder". Clicked OK twice and waited a couple of days to see if the critical error count dropped in the Monitoring report. Yes! Victory! The 1010, 1014 and 1016 errors stopped occurring! Sanity has been restored! The cat no longer cringes when I'm around!