Problems with the EXBPA on using CCR Clustering on Windows 2008

Whilst on the subject of the EXBPA (previous rambling here I thought that I would pass on a couple of (probably well known) tips on why the BPA can fail or generate warnings when being run against a Windows 2008 based Exchange 2007 server using the “Health Check” option. The Two most common errors that can be encountered when running the BPA against Windows 2008 servers which are as follows: Exchange Server cannot be contacted: The above error typically manifests itself as a red cross during the scanning process and indeed as a part of the final report:


This can be caused by the two following issues;

  1. The remote registry service has not been started on the Windows 2008 Exchange server – “Remote Registry” is disabled by default on non-clustered Exchange 2007 instances running on Windows 2008 – you will need to enable and start the service.
  2. The Windows 2008 Firewall Service is enabled you will need to create an exception rule or disable it (not recommended) in order for the BPA scan to complete.

Cannot connect to port 25 on the Routing Group Master: Another interesting error that can be displayed after the BPA has performed its analysis is the above error – which looks like the following: BPA-NW-2

This can be caused by:

  1. An Antiviral program running on the server which the BPA is run from blocking traffic on port 25
  2. An Antiviral program running on the Exchange server that the BPA is testing

In either case of the above you will need to configure your antiviral program / firewall to allow port 25 traffic from the BPA (and obviously the Exchange Transport Service).

General Tips for the BPA:

The BPA is an essential tool for any Exchange administrator, it can locate, suggest and help troubleshoot issues with Exchange before, during and after they manifest. Therefore I would like to suggest the following tips for people whom are not familiar with the tool:

  1. Keep you BPA server updated

    As many of you may know Exchange 2007 installs a copy of the BPA on every server it is installed upon – in an ideal world you would try to keep the XML definitions up to date on every server – however sometime’s this is not convenient – therefore I suggest that you nominate one server in your environment that you intended to run the Exchange BPA from (this in many cases might actually be a workstation with the Exchange Management or indeed the BPA installed upon stand alone) – ensure that you check for updates to your BPA definitions every 3 weeks.

  2. Run the BPA when it makes sense

    As part of a robust change control process run your BPA before and after every major change to Exchange – this will help verify changes and help you spot errors in your configuration and roll back if required.

  3. Keep copies of you BPA reports

    Very useful if you need to track back through changes or review the evolution of your Exchange environment – great for audits or DR scenarios.

  4. Trust and don’t Trust the BPA – even when it is right or wrong

    This might seem like a weird statement – but the BPA flags issues for a reason, even if settings that are correctly configured are reported as wrong check them – this will give you an understand as to where they are and what the BPA reports on. Also bear in mind that the BPA is purely a “Best Practices” tool – therefore you might not be able to correct everything it says as you own environment is unique – use your own judgement.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.