Microsoft releases Exchange Best Practices Analyzer tool

September 21st, 2004

Paul beat me to it, Exchange Security: Microsoft releases Exchange Best Practices Analyzer tool.

just installed it on my management server. Setup is easy (no surprise). Here’s a basic rundown of the steps to run it.

  1. It asks you which DC should it get the Exchange info from.
  2. Select which Exchange servers to run against, and what your network speed is. One intersting thing is it asks you what kind of scan to perform. Right now the only option is Health Check, but it suggests that future types scans will be made available.
  3. Allow it to run, it gives a pretty good progress report, even including how far along it is on each server. Apparently it does a lot more tests on backend servers, since my backends where at least twice as slow as the front-ends.
  4. Review the report

Here are some of the suggestions they had, broken into the ones that make sense, and the ones that do make sense.

Suggestions That Make Sense

  1. SMTP queue directory on system volume. I realize that in theory they should be separated, sometimes (most of the time?) it’s just not realistic (or truly necessary).
  2. Temp folder on system volume. Same as number 1, does anyone really move the temp folder?
  3. Exchange Fatal Error information not sent to Microsoft automatically. I’ve thought about enabling this, but the privacy advocate buried way down deep inside of me resists.
  4. All versions of Outlook are allowed. Good point, I should restrict it to newer versions. I used to do it but just got lazy this time around. My bad, added to my to-do list.
  5. VS API product not enabled. I think this is because I use Antigen in ESE mode. I’ll have to do some research on that though.
  6. SystemPages setting. It says on a Win2k3 box the SystemPages setting should be 0. I’ll have to look into it.
  7. On the front-end servers it says that I have /3gb and /USERVA=3030 set in boot.ini BUT I don’t have 1gb of memory. Well actually I have exactly 1gb of memory. I’ll have to see if I’m getting this message because my 1gb was rounded down to 999.5 mb or if the /3gb switch applies to more than 1gb.

Suggestions That Don’t Make Sense

  1. It complains that the SMTP servers are set to reject messages over 20mb. But I obviously did this for a reason.
  2. WINS is blank. Isn’t that a good thing since then I’m not using WINS.
  3. On my backend server it complains that I’m not allowing authenticated users to relay. Well since nobody should be using the backend as a SMTP server (ie my IMAP users) I figured there was no reason to allow people to use that as a attack point (by brute forcing accounts). Although if someone wants to do that there’s a few front-ends with SMTP open to the world they can knock against.
  4. Suppress OOF’s to distribution lists. It complains that I don’t send OOF’s to distribution lists. I know I don’t, there’s a reason I don’t. When I clicked the more information button to see why they think I shouldn’t get that I got a 404.
  5. You must enable the license logging service to have more than 10 simultaneous SSL connections. Now right now I have about 200 SSL connections per front-end. So I KNOW that this is old information. There was a hotfix to circumvent this in Win2k and it doesn’t apply to Win2k3. (someone correct me if I’m wrong please)

Overall I think it’s a great tool, not perfect, but better than MBSA. I work with Exchange almost full time. When I’m not working with Exchange directly, I’m writing programs and webpages to help my Exchange users perform their job (and mine) better. Even though I consider my self pretty knowledgeable on Exchange, I was still able to be taught (and reminded) about a few subtleties. I’m sure this will be a great asset to jack of all trade admins, and new Exchange admins.

3 Responses to “Microsoft releases Exchange Best Practices Analyzer tool”

  1. Anonymous Says:
    April 21st, 2005 at 6:43 am

    Steve-

    On number 5, you’re correct. http://support.microsoft.com/default.aspx?scid=kb;en-us;264908 />Looks like it also got rolled up in Win2000 SP2
    http://support.microsoft.com/default.aspx?scid=kb;en-us;282524

    I keep seeing references to this limit in a bunch of docs on Exchange 2000. Sure would be nice if someone went through and cleaned it up. -Hunter (hunter -at- huntercoleman dot net)

  2. Anonymous Says:
    April 21st, 2005 at 6:57 am

    Regarding number 2: WINS

    We have been running a no WINS world wide WAN over a VPN with mixed Exchange 2000 and 2003 servers for about 1 year now. We have not exhibited any of the problems listed. And most or our clients are Outlook XP.

  3. Anonymous Says:
    April 21st, 2005 at 7:45 am

    Hi Steven,

    Thank you for the kind words on your EHLO World blog regarding the recently released Exchange Server Best Practices Analyzer Tool (http://www.planetevans.com/blog/2004/09/microsoft-releases-exchange-best.html). I’d like to comment on the section in your blog entry entitled ‘Suggestions That Don’t Make Sense’ in hopes of making sense of some of the issues you have raised. :-)

    I’ve numbered my comments to correspond to the issues you have raised:

    1. I believe this refers to ‘The msExchSmtpMaxMessageSize value has been altered from its default of 0.’ This issue is logged as a warning because there are known problems that can occur if the size limits for internal SMTP messages are set too low. One such issue, which is described in this article, is a failure to replicate the offline address book between Exchange Server computers. Basically, what we are saying here is that some organizations need to be aware that setting the size limit too low might cause problems. Setting the size limit to 20MB may make sense for your organization, but some organizations require greater size limits. For this reason, this is logged as a warning and not an error.

    2. I believe this refers to ‘The primary WINS server address is blank.’ This issue is logged as a warning because some environments can successfully run Exchange Server without WINS, while many environments cannot. We state the following in this article to let folks know that this may or may not be an issue that needs to be addressed, which is one reason it is a warning and not an error:

    Exchange Server 2003 and Exchange 2000 Server have several NetBIOS dependencies. Additionally, Microsoft® Office Outlook® clients that are earlier than Microsoft Office Outlook 2003 also require NetBIOS name resolution. For example, the following Exchange functionality depends on NetBIOS name resolution:

    · The Exchange Server 2003 and Exchange 2000 Server Setup programs, especially on clustered servers.

    · Exchange Mailbox Merge Wizard (ExMerge) on an Exchange Server 2003 or Exchange 2000 Server computer.

    · Changing a password for an Exchange Server 2003 or Exchange 2000 Server mailbox through Outlook Web Access.

    · Exchange System Manager on an Exchange Server 2003 or Exchange 2000 Server computer.

    Depending on your organization’s network topology, you may be able to safely ignore this warning. On networks that are made up of a single subnet, NetBIOS broadcasts typically can handle the NetBIOS name resolution requirements of an Exchange deployment.

    3. I believe this refers to ‘The msExchSmtpRelayForAuth value has been changed from its default of True.’ This is logged as a non-default configuration message. One of the benefits of using the Exchange Server Best Practices Analyzer is its ability to identify changes made to the out-of-box settings on an Exchange Server. In this case, the tool is pointing out something you already knew that you changed. The article does not suggest that you change anything; it is simply identifying a change you already made. For the convenience of those customers who were not aware that the setting was changed on their system, the article includes instructions for view and changing the setting back to its original default.

    4. I believe this refers to ‘Suppress out-of-office messages to distribution lists has been set.’ This is also logged as a non-default configuration message. Here, too, we don’t suggest that you change it, but we do provide details on how to change it for those customers that might want to.

    5. I believe this refers to ‘License Logging service is not running.’ There is some confusion regarding the need to have the License Logging Service running in order to have more than 10 concurrent SSL connections. There was a bug that was found and fixed with respect to this issue. However, that fix was for anonymous SSL connections. The bug was that anonymous SSL connections were decrementing available license counts. Licenses should only be decremented for authenticated SSL connections, and that is what was fixed. In order to get more than 10 concurrent authenticated SSL connections (which are the kind used by an Exchange front-end server) the License Logging Service does need to be running.

    Thanks again for blogging the release of this tool, and for your time and feedback. It is most appreciated! If you have any questions about the above, or wish to provide additional feedback about the Exchange Server Best Practices Analyzer, you can send an email to exbpadoc@microsoft.com, or use the TechNet article feedback mechanism.

    –
    scott schnoll
    technical writer – Exchange user education