In Windows 2003, the local firewall was turned off by default. You could enable it, but you had to be careful about defining all your exceptions; unlike a PC running Windows XP, you presumably want people to be able to connect to your server! Finding a list of all the relevant ports/protocols could be difficult, and Microsoft sometimes advised people not to enable the firewall at all. SP1 introduced the Security Configuration Wizard (SCW), which helps you to configure the firewall, but you have to specifically install this as an extra component.
In Windows 2008, this changed: the firewall is turned on by default, and the SCW is installed automatically. You can still turn the firewall off, but that’s not ideal from a security point of view: it’s better to configure it so that only certain traffic can get through.
The SCW already knows about several programs by default, and you can register extensions for other applications, e.g. Microsoft Exchange 2007. By the way, the information on this page is out of date. Instead, you should follow these steps:
1. Run the Exchange Management Shell as administrator. (I.e. right-click the shortcut and choose “Run as administrator” from the context menu.)
2. Change directory to
C:\Program Files\Microsoft\Exchange Server\Scripts
Unfortunately, I’ve noticed that there are some differences between the RTM version of Exchange 2007 and SP1. These mean that the System Attendant service is blocked, which means that other machines can’t connect to the address list service. This causes two specific problems:
a) You can’t configure your Outlook profile to talk to the mail server. When you click “Check Now”, Outlook just sits there for a long time, then gives up.
b) When you try to move a mailbox between servers, it doesn’t work. In particular, you see an error like this:
“The address list service on the server mail01.example.com is not running. An Exchange 2007 server on which an address list service is active cannot be found.”
I currently have two mailbox servers running Exchange 2007 SP1, i.e. they have the “Mailbox”, “Client Access”, and “Hub Transport” roles. (There’s also another Exchange server with the “Edge Transport Server” role, but that’s not relevant here.) One of them was originally installed with Exchange 2007 RTM, then upgraded to SP1; the other was installed from the SP1 DVD; I’ll refer to these as “MAILRTM” and “MAILSP1” respectively. If I want to move a mailbox from MAILRTM to MAILSP1, I can “pull” it (using the Management Console on MAILSP1), but I can’t “push” it (using the Management Console on MAILRTM). In other words, the address list service is available on MAILRTM, but not on MAILSP1. So, what’s the difference? When I temporarily disabled the firewall on MAILSP1, I was able to push a mailbox from MAILRTM, so that’s where the problem lies.
If you look at the Windows Firewall Settings on Windows 2008, the dialog box is very similar to Windows XP:
Looking at the Exceptions tab, there’s just a single entry for Microsoft Exchange on MAILSP1. Clicking “Properties” doesn’t give any details about the ports/protocols, so we can’t get any more detail about what traffic is being allowed.
On MAILRTM, there’s a much longer list of entries (more than are visible in this screenshot):
Again, though, clicking “Properties” doesn’t reveal any extra information. Fortunately, there’s another program that gives more details. Go to:
Start | Administrative Tools | Windows Firewall with Advanced Security
Here’s an excerpt from MAILRTM:
And here’s the corresponding screen on MAILSP1:
One difference is that there are some extra rules on MAILSP1, e.g. for Unified Messaging, even though this server doesn’t have the UM role installed. Also, the rules on MAILSP1 are all in the “Microsoft Exchange” group, whereas the rules on MAILRTM don’t have a group. Presumably, this is why we just see a single entry for Exchange in the “normal” Windows Firewall dialog on MAILSP1, whereas we get a long list on MAILRTM. Neither of these things are directly relevant here, but they do demonstrate one important point: even though both servers are now running the same version of Exchange, the method of installation determines the rules that are created.
It turns out that the significant rule is for the System Attendant service (C:\Program Files\Microsoft\Exchange Server\Bin\mad.exe). On MAILRTM, this rule is called “MSExchangeSA”, and on MAILSP1 it’s called “Microsoft Exchange – System Attendant (in)”. We can get some more details about this rule by going to the property pages; on MAILRTM we can change the settings, but on MAILSP1 most of them are read-only:
If we go to the “Programs and Services” tab, then click “Settings”, we can see the difference:
So, on MAILRTM this rule applies to all programs and services, but on MAILSP1 it only applies to the service with the short name “MSExchangeSA”. Since that is the System Attendant service, it should be ok, but apparently it’s not; don’t ask me why!
The simplest solution would be to change the settings for this rule on MAILSP1, but we can’t do that because it’s read-only. Instead, we need to create an additional rule. We could do that through the Windows Firewall application, but it’s better to use the SCW; that way, we can save the policy, and re-apply it if we ever need to re-install this server (e.g. in a disaster recovery scenario). So, run the SCW: either create a new policy or modify an existing one as appropriate. I won’t go into all the details here, because the specific rules will depend what your server’s being used for. Basically, go through each step of the wizard until you reach the “Network Security Rules” page. If you scroll down, you should see several rules for Microsoft Exchange:
Again, we can’t edit the significant parts of the System Attendant rule. Instead, we need to add a new rule. Click “Add…”, and fill in the details as follows:
(Leave the “Protocols and Ports” and “Scope” pages on their default settings.) You may want to put in a description to explain why you’ve added this new rule; feel free to refer to this webpage!
When you finish the SCW wizard, save the policy file and apply it. You will then see that the new rule appears in the firewall configuration.
After I made this change, I was able to “push” mailboxes from MAILRTM to MAILSP1, so that’s solved my problem; hopefully it will be useful to someone else too.