I was scanning through Microsoft Security Bulletin MS08-006 and saw the Aggregate Severity Rating was ‘Important’ for all versions of Windows XP and Windows 2003. Because no critical ratings were listed, I felt secure in waiting a day or two before applying this patch. I tend to wait for others to find patch problems before I apply them to my vital machines.

Luckily Susan pointed out that in fine print at the bottom of the Security Bulletin is the following:

Note Supported editions of Windows Small Business Server 2003 contain the same affected code as Windows Server 2003 Service Pack 1 and Windows Server 2003 Service Pack 2. However, for the ASP Vulnerability (CVE-2008-0075), default configurations of Windows Small Business Server 2003 have a greater exposure to the same vulnerability and therefore merit a severity rating of Critical.

Gee, thanks Microsoft for putting all the effort into making sure security professionals are aware that Small Business Server has this critical vulnerability. Talk about being the red headed stepchild of the server world.

I recently had to help a customer clean up their SBS 2003 server which had been used to send out spam. It seems that one of their user accounts had been compromised, and we were able to stop the spam by changing the user’s password. The server’s performance was horrible, even after a reboot, and we found messages stuck in over 500 SMTP queues. Rather than clear the queues one at a time, I used the Aqadmcli tool to delete all the stuck messages at once.

To clear all the SMTP queues at once, run the following from a command prompt on the Exchange server:

aqadmcli.exe

setserver [servername]

delmsg flags=all

quit

where [servername] is the name of the Exchange server containing the queues you want to clear.

You can also delete messages from a particular sender using the syntax

delmsg flags=SENDER,sender=user@domain.com

You can read more about this tool here [via the Wayback Machine]

KB 324958 describes an alternate way of cleaning up the SMTP queues. There is also a webcast that shows how to accomplish SMTP queue cleanup.

One of the smaller networks I manage consists of a handful of users who connect to a SBS 2003 server. Their server keeps reporting the following in the Windows Application Log:

Event: 2000

Source: MSExchangeIS Mailbox

“Verify that the Microsoft Exchange MTA service has started. Consecutive ma-open calls are failing with error 3051″

This error would lead you to believe that the MTA Stack service wasn’t started when it should be. But if this is the only Exchange server in your organization and you aren’t connecting to an X.400 mail server, the MTA Stack service is not necessary. Previously I had even changed this service’s startup type to disabled, yet the server continued to report this error.

KB 810489 explains that stopping and disabling the Microsoft Exchange MTA Stack service is not sufficient to resolve this error. Two registry entries need to be created on the server for each public or private database on the server.

Open the following key in regedit:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ServerName

For each private or public database that is listed under this subkey, perform these steps

1) Right click on the database, select New – DWord Value. Name the value Gateway In Threads

2) Set the Gateway In Threads value to 0 (zero)

3) Right click on the database, select New – DWord Value. Name the value Gateway Out Threads

4) Set the Gateway Out Threads value to 0 (zero)

You must restart the Micrsoft Exchange Information Store service for the changes to take effect. The KB also explains:

“When you set the Gateway In Threads value and the Gateway Out Threads value to 0, Store and MTA connection failure events are not logged in the Application log after the MTA Stacks service has been disabled. If you create a new database on the server, you should set the Gateway In Threads value and the Gateway Out Threads value for the new database.”