Forefront for Exchange and Windows built-in Firewall on a CCR cluster

Are you running Exchange 2007 in a CCR configuration with Windows firewall tuned on?

Then you have probably encounter the problem “ERROR: cannot connect to service” when starting Forefront for Exchange administrator.

The solution is to allow some traffic through the Windows firewall as stated in KB929073.
This will allow you to start Forefront admin tool on the node running the Exchange Clustered Mailbox Server (CMS).
But you will still get an error when launching Forefront admin on the passive node and connect over the network to CMS.

The solution is to create two firewall rules that allows the traffic. These can be created with the GUI but its easier to describe

netsh advfirewall firewall add rule name="Forefront for Exchange Controller Service" dir=in action=allow program="C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\FSCController.exe" description="Allow connection to Forefront for Exchange controller service" enable=yes profile=any localport=RPC protocol=TCP security=notrequired

and the second rule

netsh advfirewall firewall add rule name="Forefront for Exchange Admin tool" dir=in action=allow program="C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\FSSAClient.exe" description="Allow connection to Forefront for Exchange admin tool" enable=yes profile=any localport=RPC protocol=TCP security=notrequired

You need to do this on both nodes and also restart the Forefront Controller service, but this will also restart several other services.

You have to change the path in the commands if you have installed Forefront in a different location than default.

You can also narrow down from where connections can be executed with the remoteIP parameter and the network classification with profile parameter.

netsh advfirewall firewall add rule name="Forefront for Exchange Admin tool" dir=in action=allow program="C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\FSSAClient.exe" description="Allow connection to Forefront for Exchange admin tool" enable=yes profile=domain localport=RPC protocol=TCP security=notrequired remoteip=localsubnet

or

netsh advfirewall firewall add rule name="Forefront for Exchange Admin tool" dir=in action=allow program="C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\FSSAClient.exe" description="Allow connection to Forefront for Exchange admin tool" enable=yes profile=domain localport=RPC protocol=TCP security=notrequired remoteip=10.10.10.0/24

Another thing that is important when running Forefront for Exchange in a CCR environment is to have the checkbox ‘Redistribution server” on “General Options” checked, otherwise the passive node will not be able to get updates from the active node.

Exchange 2007 Service Pack 2 backup feature

It has been a lot of disappointment of the missing feature of a native backup solution in Exchange 2007 when running on Windows Server 2008. It has been so much roar out there that Microsoft decided to do something about it. With Exchange 2007 Service Pack 2 the native backup of Exchange capability is back.

It will not be a separate software or anything that is visible in a GUI somewhere, it will just be an added feature of Windows Server Backup since Windows Server 2008 don’t use NTBackup anymore.

The Windows Server Backup is aimed towards small or even medium size organizations and also as test and troubleshooting tool, so don’t expect to much of it.

How to do a backup of Exchange with Windows Server backup?
First you must install Windows Server Backup. This can be done from servermanager, add feature and select Windows Server Backup feature or from command prompt with “ServerManagerCMD.exe -i Backup Backup-Tools”. There is no reboot required and after the installation.
Start Windows Server Backup on your Exchange server. You must do the backup locally, there is no over the network backup capability. A shortcut is created during installation in Administrative Tools or you can run “wbadmin.msc”

After Windows Server Backup has started you can select to create a scheduled backup schema or simply do a single backup. Click the “Backup Once…” link in the Actions pane, The Backup Once Wizard starts. Select “Different Options” and then click “Next >”, Select either “Full Server” or “Custom”, if Custom is selected you are prompted with options of which disk to backup.
There is no option of only doing backup of Exchange databases or only selecting some folders. The granularity is the complete disk and nothing smaller.
Select the disks that you know contain Exchange files. You will not see that Exchange databases and transaction log files are selected for backup, you must know where your Exchange files are located. Click “Next >”.
Next option is to select the destination for the backup. If you select Local drives you must select a destination drive that are not included in the backup. The other option is a Remote shared folder, then you have to enter a shared folder on another server on your network. Backup will be created in a subfolder called WindowsImageBackup with the Access Control of either Inherit or Do not inherit (equals, you specify an account that are granted permission to the backup files).
If the destination location already contain a backup it will be overwritten.
Next selection is to either do a VSS copy backup or a VSS full backup, there is no option of the old traditional streaming or incremental backup.
Copy backup will simply copy the selected disk or disks to the destination, the full backup will do the same but also purge the application log files . This is the Exchange transaction log files and this is the option you should select if you’re not using any other backup software on your Exchange database files.

Backup will be placed in a folder called WindowsImageBackup and consist of a couple of XML files and the selected disks stored as VHD files. Virtual Hard Disc files are pretty cool, it is the native file format for hard disc with Microsoft virtualization technologies and you can copy or transport those files around and mount them on other computers for examination or whatever reason you might have.

Doing recovery of Exchange databases with Windows Server Backup.
When doing a recovery the database in question must be dismounted first. In a real world scenario it is already since you probably lost a hard drive or you did a disaster recovery installation of the server and its now time for recover the databases. Databases will be dismounted if needed by the Windows Server Backup.

Start the recover wizard by clicking “Recover …” in the actions pane in Windows Server Backup.
A recovery of Exchange database and transaction log files can either go to the original location and replace the original files or be destined to the Recovery storage Group (RSG) or even to a different server.
For this exercise select the local server and then select a time when you did the backup you want to recover, next select applications since it is the Exchange application data we want to recover and then select Exchange. If you click on the “View Details” button you will see databases that will be recovered, you cannot select individual databases to be recovered, all databases will be recovered. To have a more granular option; you must create multiple backups with different databases in each backup and for this to work each database and transaction log file must be on separate disk since the smallest option of granularity is the complete disk. The checkbox “Do not perform a roll-forward recovery of the application databases” means that Exchange will not roll forward transaction log files into the the recovered database. Next option is to recover to the original location or another location. Select original location. Recover to a different server or different location will be explained in another article.
Click recover on the Confirmation page if you is satisfied with you selections and to start the recover of you Exchange databases.
If you did not have dismounted the databases before you started the recovery they will be dismounted by Windows Server Backup. Permission to dismount databases is required for this to work as expected.
If everything goes well, database and transaction log files will be read from backup and written back to disk and finally transaction log files will be replayed into the database

Conclusions:
Does it work? The answer is, it depends. It will work if being used for doing backups and doing restore in a disaster scenario. It will not behave as expected when doing restore to a different server or different location, such as the Recovery Storage Group.

Windows Server Backup with Exchange plug-in don’t have granularity when doing backup or when doing a recovery, it will recover whatever there is on the backup. It’s all or nothing type of backup and restore.

Windows Server Backup can be configured to do scheduled backup from the GUI, but you can also use Windows Server Backup from the command line. This gives you more flexibility to make your own schedules with different options. I am thinking destinations here since each destination can only hold one backup, so if doing multiple backups to the same destination, only the last will be preserved.

Command line reference for Windows Server Backup.
http://go.microsoft.com/fwlink/?LinkId=93131

How to use the command line and to do a restore to the Recovery Storage Group is a story for another day.

Exchange 2007 Service Pack 2 is released

Finally the Exchange 2007 Service Pack 2 has left the building and are downloadable by the public.

Of course it contains all bug fixes included in previous rollup’s for Exchange 2007 but it also contains some new features such as a plug-in for Windows Server Backup to natively do Exchange backup without buying any 3:rd party software. This one has been a long standing request that now is fulfilled.

Some other noticeable features included in SP2
* Enhanced Auditing
* Public Folder Quota
* Configure Diagnostic logging via GUI/Exchange Management Console
* Named properties bloat will stop since SP2 don't propagate x-headers to MAPI properties anymore. This is the same behavior as in Exchange 2010. See earlier posting about Named properties bloat part 1 and Named properties bloat part 2
* Dynamic AD schema update

Bu before even installing SP2, you must first extend Active Directory schema. Prepare your AD team for this!!

And if you’re planning on upgrading to Exchange 2010, SP2 for Exchange 2007 is a prerequisite and must be installed on every Exchange 2007 server before Exchange 2010 can be introduced into an Exchange 2007 organization. Read my other article about transition to Exchange 2010. Thinking about Exchange 2010? Understand the Prerequisites

Some more information about Exchange 2007 SP2
http://msexchangeteam.com/archive/2009/05/11/451281.aspx

Download link for Exchange server 2007 SP2. Be to careful to read the “Release notes” and “what’s new in Exchange 2007 SP2” documents on the download page before installing.

Exchange 2010 is starting to look good

Now that the RC (Release Candidate) is out in public Exchange 2010 Release Candidate info page I can only say that it’s starting to look really good. Features that before where only talked about now is in this build and also work pretty good.

From now on to RTM version, it is mostly bug checking and performance tuning.

For you that seek for the 32bit version of Exchange 2010, the answer is, there will not be any 32bit version of any kind, no demo version, no admin tools no nothing.

Sign up for download here http://technet.microsoft.com/en-us/evalcenter/dd185495.aspx

Here is the Exchange team info msexchangeteam blog

Some thoughts about applications sending SMTP messages to Exchange

Most organizations have applications that need to send mail, either to internal recipients or to have a SMTP server to relay there mail destined for external recipients.

Common configuration is that they figure out the server IP address where the application runs on and then enter the IP on the allow relay list on Exchange 2003 virtual server, if then run Exchange 2007 they often are a little bit puzzled until someone shows them MSExchangeteam 'Allowing application servers to relay off Exchange Server 2007'.

Why do I think this is bad?
First, most applications don't need the relay permission, admins often think so but the truth is that they don't need it.
Servers are not static, IP changes, name changes both on the application side and the Exchange side. If the server get infected with something bad, it is not just the application running on the server that are allowed to relay but everything running on the server since its the IP that are allowed to relay.
Remember this: IP restrictions are not authentication.
Have seen applications that are hardcoded to connect to a specific IP or names meaning that either IP or name can be changed on the Exchange server.
Resolution is of course to have applications easy to reconfigure with destination SMTP server’s name.

Another problem is when there is some kind of anti spam software running on Exchange. This will often make the applications mail end up being classified as spam and make Exchange admins trying to configure the anti spam software to white list some mail. Sometimes this cant be done and sometimes it can making admin workload bigger than before.
Resolution here is to educate developers in SMTP. They often doa good job of building applications but are very often bad at SMTP. They find a free SMTP engine on Internet and they stick it in there applications and in the end they manage to send a SMTP mail but it is often bad formatted in various way making the anti spam software react and classify it as spam.
Resolution here is of course knowledge about SMTP.

Back to the relaying part of sending mail. One very good solution here is to have the submitting application to authenticate SMTP session. By sending authenticated SMTP mail to Exchange, it will get the permission to relay, it will most likely bypass antispam software depending of software of course. It will also make the application easier to move to another server without reconfigure Exchange. Another thing with authentication and SMTP is that if I authenticate as ‘application 1’ I am only allowed to use ‘application 1’ email address, I cannot use another SMTP sender address..

My recommendations to developers, building applications sending SMTP mail.
* Use a good SMTP engine that do work. Have encountered one that didn’t like the tarpit time you can configure in Exchange 2003 and are default activated on Exchange 2007. This engine simply could not work with tarpit.
* Use authentication when submitting mail. NTLM is of course better than Basic, but if using basic authentication, use it over TLS.
* Ability to easy change SMTP configurations such as server name, sender and receiver SMTP address, TCP port etc.
* Have redundant SMTP server configuration. The SMTP server that you’re using may not be up and running. If mail are critical, consider having some queue functionality in the application that can try to resend mail. One queue functionality would be to use the local windows SMTP service, but this will only work if application run on Windows boxes and the local SMTP service is working.
* Use only valid sender and destination SMTP addresses. If there is NDRs, they should go back to an existing mailbox that someone can monitor and act upon.

There are of course recommendations to Administrators as well.
* Clearly communicate to developers what the rules are for submitting SMTP mail to Exchange. No hardcoded configuration, no anonymous submission etc.
* Add a good name for your SMTP servers, such as ‘smtp.ADdomainname’ for developers to use instead of giving them the real servername or IP. With a standardized name across all applications you can make them use another server when there is need. If you internal Active Directory name is company.local your smtp server name would be SMTP.company.local
* Set up internal MX records for the AD name space. Same advantage as above.
* If you have multiple HUB server, Load balance TCP port 587 across those servers and make applications use SMTP submission port 587 (this is the client receive connector that are default created on Exchange 2007)  instead of the default 25. Don’t load balance port 25 since it will break functionality in Exchange such as authentication.
* Be very careful of what mail you let through to internet, maybe you should block applications to send to Internet on connectors to maintain your good name on Internet. Companies have ended up on various blacklists because developers have built bad SMTP mail or have a buggy application that spray mail across Internet.

There are probably many more options/alternative/thoughts around this, but these are just some that regularly pops up.