Lets first look at the critical results.
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.
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.