Validating the Exchange 2003 build with ExBPA - Part 2

Next, lets look at the informational alerts that showed up in the ExBPA scan.

Now the Application log size is recommended to be increased to at least 40MB.  For a production platform this is a very good idea, particularly if you ever need to turn up diagnostic logging to troubleshoot an issue.  I'm not really expecting a huge throughput in the application log for this lab environment, although I will be performing a number of tasks that my well require me to turn up diagnostic logging levels, so it's worth doing in this case too.  Rather than individually increase the log size on Exchange servers, I've decided to increase the log size across all servers, via Group Policy.  This option will be particularly useful as the same recommendation applies to Exchange 2007 and 2010, so making the single change in Group Policy will mean not having to worry about this as I add more Exchange Servers.

I won't go into details about how I configured the GPO, as I've done this a couple of times already.
The precess of Tar Pitting is where unauthenticated SMTP connections are artificially slowed if the sending SMTP server addresses an invalid recipient is in an attempt to reduce the effectiveness of dictionary email address harvesting attacks as described in this Microsoft KB article.  It's not really relevant in this deployment as I won't be opening inbound SMTP to the Internet whilst only Exchange 2003 is deployed, however, it's an easy fix to reduce the number of informational alerts.  This is enabled by adding a DWORD value with number of seconds to delay at HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SMTPSVC\Parameters.

The alert for the automatic updates not being enabled for the Intelligent Message Filter appears to be another bug.  The Intelligent Message Filter is not enabled on this server: the reg keys that ExBPA should be checking to verify if this is the case, as documented in this technet article don't even exist on the server.  I could probably fix the alert by enabling the updates for the service, but I'd be concerned that doing so would be more likely to introduce other issues so I'll have to live with this alert.
Basic Auth is enabled on the SMTP VS on the Front-End server by design.  It's not going to be open to the Internet so there is no security concern.  I should be able to disable Basic Auth on the back end SMTP VS though.

The circular logging alert for the Front-End relates to the single (empty) database that needs to exist on an Exchange 2003 Front-End server in order for it to properly function.  Circular logging is fine for this, so I modified the setting at the Storage Group Level in ESM.

Finally, crash upload logging is disabled.  In corporate environments, particularly in the EU, as it is pretty much impossible to know what information may be contained in a crash dump leaving this disabled is pretty much the only viable option.  Enabling it potentially raises concerns around transferring data outside of the EU, and the various data protection regulations that must be considered.  Crash dumps can still be created, and manually submitted to Microsoft after manual review if required.
Finally I re-ran the ExBPA scan to ensure everything I'd intended to fix was now fixed, and the only remaining items were expected.

The scan came back as expected. 13 items remained of the original 21, and the 13 will drop to 12 when I put some backup solution in.