Exchange 2003 End-of-Life? Fix it today.

Two business days until Exchange 2003 goes end-of-life.  Two more days until you need to need to be upgrade.  Whether you work for an MSP, or you've been trying to get your boss to move off of Exchange 2003 or the past decade, you're quickly running out of time.  That being said... I get it... if you haven't upgraded yet, it's unlikely that you're going to next week.  But sooner or later, you're going to wish you had.  And when you do, would't it be nice if you had a goto plan that's already been put through it's paces?  A plan that's already been used in real customer environments... everything from SBS 2003 to the Enterprise.  Wouldn't it be nice if you could just execute the plan?  Without buying an Exchange book, learning everything about an application that you don't even like... and wouldn't it be nice if you knew it was going to just work.  Well, this is the kit you've been looking for.

I just moved my final SBS 2003 client off of Exchange 2003 last week.  Yes, that's right.  After years of recommending, suggesting, and imploring... they bought it.  And using the kit I did it with a minimum of pre-planning, one scheduled reboot of the SBS 2003 server, and a bulk mail move of all of their accounts - I was finished by 4:00pm on Friday.  No late nights, no angry clients, and no annoying ActiveSync problems.  On top of that, I sold it as a fixed-cost, basing the project on a 40 hour gig, and it took two days total effort.  How's that for a fixed cost no-brainier?

Buy the Exchange end-of-life kit today for $73 and with 1-2 days of total effort, you can do what normally would take a week.  How's that for a good fixed cost margin?  On top of that, it's no stress, no lost weekends, and most importantly - a happy client.  Our kit works, because we've been using it, and continuously improving for years.

Exchange Message Tracking Center or findstr?

If you need to track down messages in Exchange, using the Message Tracking Center in ESM is probably the first place to go for information.; and for the most part that works just fine. But if you need some more detail, or need to be able to search for wildcards or other strings, you might want to consider using findstr against the log folder

Open a command prompt, browse to Exchange log folder and do a search for you’re looking for.

findstr /s /i "StringToSearch" “c:\Program Files\Exchsrvr\servername.log\*.*”

In the example, /s seraches on the current directory and subdirectories and /I indicates that the search is not case-sensitive. If you’ve not used findstr before, take a look as there are plenty of parameters you can use.

As an aside, I usually copy off the *.log files that I'm interested to a separate folder before running findstr - just so as to not get bogged down searching irrelevant logs.

Do you store PST files on file servers?

You probably shouldn’t – you’ll eventually see I/O problems (hang’s and general slowness) on the file servers. I see this occasionally with new clients that we bring on, and not surprisingly it’s the IT organizations (or HR) that often institutesthe policy of having users store their .PST files on the file server. It’s hard to argue with the logic – PST files stored on a file server can get backed-up. Further, on smaller networks you can often get by with doing this for quite a while – until growth and higher I/O utilization cause the issue to manifest itself.

KB article 297019 hits the highlights, and there’s an excellent post on TechNet as well.

So you can either store the PST files locally and risk them being lost or destroyed - or, put them on files servers and risk having the I/O problems. If you’re looking for a compromise, check out the Outlook Add-In Personal Folders Backup tool. There are also some other third-party tools like Genie Outlook Backup, and Mobiliti Outlook Backup. The downside of course is that these are all compromise solutions in that they don’t’ just work. In each case, it’s another layer of complexity – deployment, management, and user training to consider.

Exchange, UCE: How to handle NDRs (Non-Delivery Reports)

A discussion that keeps coming up concerns how we should be handling NDRs for our customer installations. It seems that even with the higher-end anti-spam appliances, the “recommended” configuration is to generate bounced messages – even when the incoming mail is scored as decisively spam/uce.

So the question becomes, should we even generate NDRs at all?

Between the fact that incoming spam will invariably have a forged “From:” address, and that some organizations are recommending that we disable all NDRs – why even bother with the NDR?

It certainly doesn’t take too many complaints from your customer’s ISP or the re-addition of their IP/domain name to RBLs to cause your customer have serious misgivings about your service.

That leaves you with disabling NDRs across the board.

The first place to consider disabling NDRs is at the perimeter. So if you have a perimeter antispam appliance, consider not generating NDRs there. If your perimeter happens to be your Exchange server itself, you might want to consider disabling NDRs in Exchange 2000 and 2003 , (see this link for Exchange 5.5).

SBS: Accepting mail for multiple domains

When a customer claimed that one of our competitors (who we were bidding against us for a project) informed them that one of the downsides of using SBS was that you couldn’t host email for multiple domains, we needed to explain to the customer (gently) that in fact you could add multiple domains to SBS without issue. Contained below is a procedure for doing just that.

For Exchange 2000/2003, and SBS 2000/2003

1) Open Exchange System Manager
2) Expand Recipient Policies, and right-click on the Default Policy
3) Select the “E-Mail Addresses (Policy)” tab
4) Click the “New” button, select “SMTP Address” and click ok.
5) In the “Address:” field, type “@yourdomain.com”, leaving checked the checkbox indicating that “This exchange organization is responsible for all mail delivery to this address” (Click here for more information on authoritative and non-authoritative domains).
6) If this is going to be your new primary domain, you can choose to “Set as Primary”.

Finally, keep in mind that if you’re adding a new domain, you need to add an appropriate MX record for this new domain to DNS (typically done though an administrative interface, provided by your registrar or web host).

SBS 2003: SMTP Queue length follow-up

I received a follow-up question about the SMTP queue length post from last week.

The question was... "I followed the instructions in the SMTP server remote queue length post, but I just received a another alert... ?"

After following the instructions, go ahead an check your queue... there probably are still a number of messages that need to be flushed out. Just give it some time (or delete the items from the queue), and everything should clear up. If you're still having problems after waiting/deleting junk from the queue, you might have missed a step in the article.

Go head and look though the article again. I just referred back to my post to help out a customer, and everything seemed to work as expected. But certainly let me know if I overlooked something.

SBS 2003: SMTP Server Remote Queue Length Alert

Have you been getting the following notification from an SBS 2003 server?

“SMTP Server Remote Queue Length Alert on SERVER”… “A large number of messages are pending in the e-mail server send queue.”?

To start off with, make certain that your internet connection is up, and that it’s not a momentary outage from you ISP. Okay, so assuming that your internet connection is good, in all likelihood the solution will probably be to filter out recipients not in Active Directory (which is explained below). But before we turn that on, let’s just entertain for a moment that a weak password has been compromised, and that a spammer might be relaying using that account (hey, here’s another good argument for password complexity requirements).

So let’s go ahead and enable maximum logging on the SMTP protocol. Later you can sort though the application log in Event Viewer for event ID 1708, and determine if an account is being authenticated against using a weak-password for the purpose of relaying UCE/Spam.

To enable logging on SMTP, open Exchange System Manager (ESM), expand servers, and right-click on SERVER (where “server” is the name of your server). Select the “Diagnostics Logging” tab, then under services select “Exchange Transport”, and in the right-hand categories column, select “SMTP Protocol” and for the logging-level choose “maximum”.

The next thing that you’ll want to consider doing (possibly after getting a good sample of data via SMTP logging above) is to prevent Exchange from trying to process email for users that don’t have an account in Active Directory. In other words, Exchange will bounce email at the SMTP level for email being sent to users that don’t have an account on your system. This is a short two-step process, and should go a long way toward eliminating the SMTP Server Remote Queue Length issue you’re getting.

1) Open ESM, click Global Settings, Message Delivers, the Recipient Filtering tab, and check the box to enable “Filter Recipients who are not in the directory”.

2) Next, you’ll need to enable this on the SMTP virtual server in order for it to take effect. While you’re in ESM, click Servers, then SERVER (the name of your server), then Protocols, then SMTP, right-click on Default SMTP Virtual Server, click Advanced, click Edit on “all unassigned”, and enable “Apply Recipient Filter”.

This usually does the trick… in larger environments, I tend not to see this… Or at the very least, there have been some discussions in the Exchange admin group as to how to handle this. More often than not, I see it come up in SBS installations. Of course, be sure and keep an eye on things over the course of the next few days, and make sure that the issue really has been resolved. You also might want to disable the “maximum SMTP logging” that we turned on at the beginning, as over time you’ll start filling your application log up.

As a recommended follow-up, it might be a good time to mention the value of installing and configuring IMF to your customer – it’s quite a powerful “free” solution that you can start using immediately in an SBS 2003 installation. This will have a noticeable, and immediate impact for you customer - and it sure beats spending $2000 on a dedicated anti-spam appliance for perimeter filtering.

Exchange: Thank you mailbox migration wizard!

Hey, just wanted to give a big thank you to the team responsible for the Exchange mailbox migration wizard. I can’t tell you just how nice it is when a mailbox migration goes right.

Not that I expect problems, and with a fully tested migration plan that includes contingency planning you really should already know what’s going to happen before it happens. But it’s just a great feeling when things go off without a hitch! The customer is happy, I'm happy, and things get accomplished under budget and ahead of schedule.

I’ve performed mail migrations using the ESM method, Exmerge, and the Mailbox migration wizard (and in some cases a combination of methods : ) … and just have to just say how nice it is when things work out well.

XGen: Exchange Tools for migration
http://support.microsoft.com/default.aspx?scid=kb;en-us;281584

How to use the Exchange Migration Wizard to migrate mailboxes from an Exchange organization
http://support.microsoft.com/default.aspx?scid=kb;en-us;328871

SBS, Exchange, and Circular Logging:

So what’s the deal with Circular logging, and how does this apply to the SBS 2003 world?

First of all, there are quite a number of resources available on the Microsoft Knowledge base that relate to this topic. The problem is that if you read enough of them, you’ll probably end up just as confused as when you started. So let me try and make some sense of this for you.

You might notice that on a fresh install of SBS 2003, that circular logging is actually enabled (and stays that way until you run the backup-wizard). Contrast this to Exchange 2000/2003 Standard or Enterprise, where circular logging is disabled. Why the discrepancy? Probably because enough people called up product support services complaining that they were out of drive space, and that upon further investigation, support determined that they were out of drive space because they were hanging onto all of those transaction logs.

So what is circular logging? Well, it’s basically a log-recycler. After Exchange fills up the first 4 logs, circular logging assumes that it’s okay to start re-writing the first one. So you can see the problem – circular logging sacrifices redundancy in order to preserve drive space. This also breaks differential and incremental backup procedures. So you’ll have to do full backups.

What should you do?

At the very least, use the SBS-supplied wizard-interface to NTbackup. And make sure you are actually getting good backups. Do test restores as part of your Exchange maintenance policy.

What do I recommend?

I recommend Veritas Backup Exec. If you’re in the SBS world, Veritas makes a version specific to SBS, which includes an Exchange agent at a reasonable price ($437 for as of 7/05). You can search for manufacturer part number “A130478-0LB000”. But keep in mind that this will only let you backup your SBS server. You can’t purchase additional agents to backup any member servers that you might have in your environment. So if you have any member servers in your SBS environment that you need to backup (and you should be backing these up), you’ll probably need to get the full version of Backup Exec (which is quite expensive).

How to turn-off circular logging:
http://support.microsoft.com/default.aspx?scid=kb;en-us;314605