Exchange

I'm sure a lot of you have seen event 9548 in your event logs from time to time.
If 9548 isn't ringing a bell, maybe this example text will:

Disabled user /o= Organization Name /ou= Administrative Group Name /cn=Recipients/cn= Computer Name does not have a master account SID. Please use Active Directory MMC to set an active account as this user's master account.

A lot of time this will happen when you have a person leave an organization that has a mailbox that IT wants to keep around but their actual account has been deleted already. If you get enough of these, the Exchange 'clean up agents' that run from time to time will have performance problems. This also happens a lot when moving from Exchange 5.5 to Exchange 200x.

Check out KB 903158

Update: The Exchange team just put up some info on it now too.

http://blogs.technet.com/exchange/archive/2006/03/22/422799.aspx

Sometimes it happens - a 0-day exploit will be release that takes advantage of an Exchange specific SMTP extension. Short of twiddling the bits in the metabase to disable/enable various extensions, sometimes you can get around the problem by unregistering the DLL involved with the related verb.

A listing of DLLs and the add-on functions they provide can be found here:
http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3TechRef/ab1f4ae5-caee-40d8-a92c-f00a3e5eb744.mspx?mfr=true

Of note is, X-LINK2STATE contained in Xlsasink.dll, which was mentioned in an Exchange 2000/2003 hotfix as a workaround if you couldn't/wouldn't install the security fix. More info here: http://www.microsoft.com/technet/security/bulletin/MS05-021.mspx

The actual KB artcle about it is here: http://support.microsoft.com/kb/894549

I typically only do this when there is a dire need and when there isn't a smarthost/SMTP proxy in front of the Exchange server. It can break more things than it fixes.

I wasn't aware of this but having IMF updated every 2 weeks without (much) work is very handy. By default you have to do it manually, unless you set HKLM\SOFTWARE\Microsoft\Exchange\ContentFilterState to a DWORD of 1.

More technical details here:
http://blogs.technet.com/exchange/archive/2005/12/14/416070.aspx

I wrote about changing it in the past for Exchange 2003 but today I had to revisit an Exchange 2000 server so I figured I'd write down the steps I took to get the job done.

First, I downloaded Metaedit 2.2 from Microsoft's website:
http://download.microsoft.com/download/iis50/utility/5.0/nt45/en-us/mtaedt22.exe

It will try to overwrite common system files that are newer than what is packaged with MetaEdit. Alway keep the most recent copy of the DLLs, so answer 'Yes' when it complains.

Launch MetaEdit and drill down to "LM\SmtpSvc\[your virtual SMTP server]" where [your virtual SMTP server] is typically '1' on standard setups. Inside there, insert a 'String' with an Id of 'Other' and a number of 36907. In the data field, enter in what you want the banner to say. I typically set it to:

"** Unauthorized use and unsolicited commercial e-mail prohibited (NO UCE) **"

Before the edit, connecting directly to the SMTP port looked like this:

220 mail.clownballoons.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.xxxx ready at Thu, 16 Mar 2006 11:24:06 -0500

After the edit, and restarting the SMTP service, it should look like:

220 mail.clownballons.com ** Unauthorized use and unsolicited commercial e-mail prohibited (NO UCE) ** Thu, 16 Mar 2006 11:24:06 -0500

Why is it sometimes a good idea to do this? There are bots out there looking for Exchange servers with specific version numbers and by default, the banner gives that information away. It won't stop a smart hacker, but it will fool/obscure the script kiddies.

It is from a November/December build and apparently MS is currently running on a Feb. build. There won't be an upgrade path from this CTP to Final so don't plan on it. It only installs on Win2k3 as far as I can tell. It won't work under Longhorn yet.

This version runs on 32-bit and 64-bit.

More info:
http://blogs.technet.com/exchange/archive/2006/03/01/420941.aspx