Validating the Exchange 2003 build with ExBPA

For the next step in the lab build I wanted to look at performing a ExBPA scan, and correct any issues that show up.  It's often easy to pass off certain results of an ExBPA scan with X is expected because of Y or X isn't actually a problem due to Z. However, I find it's generally a good idea to clear down as many of the issues as possible, to minimise the time it takes to review future scans, and make it less likely that something that could be an issue getting overlooked should it show up in the future.  I first downloaded and installed the latest version of ExBPA designed for Exchange 2003 available here.

Lets first look at the critical results.

Now the backup critical error will be resolved when I implement a backup solution, and there's not a lot that can be done about the VMware detected error. But I should be able to correct the Missing FQDN in service principal name.
The setspn tool was installed as part of the support tools that were installed prior to Exchange, so it was just a case of navigating a command prompt window to the support tools folder, and running the setspn tool.

Next lets look at everything that showed up as a warning.

The network and storge drivers are the defaults than get installed with VMWare, I had a little bit of a hunt around but it doesn't appear to be anything newer around, however, given the size of the install base of VMWare, and even the drivers specifically being used here I would have expected any performance, bugfix or security updates to be readily available, so I'm not particularly concerned about these four warnings.

The SMTP configuration warning on RSMSGE11FE01 relates to the msExchSmtpMaxMessageSize being modified from it's default value of 0.  As per the technet article here, this can be ignored as this server is configured as a bridgehead for Internet mail.

The two IMAP4 fast message retrieval errors aren't an issue as I'm not planning on enabling IMAP for Exchange 2003 in this lab, however, enabling fast message retrieval on the (disabled) IMAP4 virtual servers will provide an easy win to get the warning count down.
This seems to be a Bug in this version of ExBPA, as apparently no warning should be shown unless all of the following are true;

• The computer is running Exchange Server 2003.
• The computer is not configured as an Exchange Server 2003 front-end server.
• The IMAPv4 service and virtual server are running.
• IMAP4 Fast Message Retrieval is not enabled on the Exchange Server.

Now in the case of the back end here, there is one criteria is the list that isn't met, and in the case of the Front-End, there's two. Anyway, Fast message retrieval on the Back-End can be easily enabled by going into properties of the IMAP4 virtual server in ESM, and ticking enable fast message retrieval.

The problem with the Front-End is that, being a Front-End, this option isn't relevant and ESM the tick box is greyed out.  There is however, a ADSIEDIT hack, you need to connect to the configuration partition and navigate through the tree to the IMAP4 virtual server instance.

Once there, you need to go into properties and find the returnExactMsgSize attribute and change this to False.

The SMTP performance warning on the Back-End is down to the Mail Queue being located on the system drive.  For this particular setup, I'm really not expecting mail queues, and even if there were, they would be much more likely to occur on the Front-End.  The level of concern over this really doesn't warrant adding an additional disk. The system disk is located on the SSD's so performance wise it would be better there than on the Database disk which is on the SAS storage.  The other option would be to put the queue on the 8GB PageFile disk, which, given a PageFile size of 2058MB has 6GB free. This seems like a reasonable compromise to get rid of the alert, given the low likelihood of significant mail queues forming on the Back-End compared to the Front-End is low, and the fact that I only gave the Front-End a 10GB Queue drive.

So I went into the properties for the SMTP VS on the Back-End and moved the Queue and Badmail directories to the PageFile disk.

Finally the WINS primary is Blank warning can be ignored as per this technet article, as the deployment is simple and on a single subnet, so NetBios name resolution shouldn't be a problem, and deploying a WINS environment just to fix this warning would be overkill.

I'll cover working through the informational alerts that came back in this scan in a subsequent post.