Executive Summary:
| The Microsoft Exchange 2007 Anti-Spam Migration tool helps Exchange Server administrators migrate antispam settings from a Microsoft Exchange Server 2003 environment to Microsoft Exchange Server 2007. By using this tool, you can ensure that your message hygiene configuration is migrated correctly. |
This tool’s name says it all: The Microsoft Exchange 2007 Anti-Spam Migration tool helps administrators migrate antispam settings from a Microsoft Exchange Server 2003 environment to Microsoft Exchange Server 2007. The tool reads message hygiene settings in Active Directory (AD) and generates an appropriate Windows PowerShell script to execute on your Exchange 2007 server. Applying that script completes the migration of the settings to Exchange 2007. Because antispam settings aren’t automatically migrated from Exchange 2003 to Exchange 2007 during the migration process, the Anti-Spam Migration tool is important if you want to ensure that your antispam configuration is migrated correctly.
Exchange 2003 and Exchange 2003 SP2 Antispam Toolset
Exchange 2003 provided basic antispam devices, including connection filtering and sender/recipient filtering. Before the release of Exchange 2003 SP2, you could also install Microsoft Exchange Intelligent Message Filter (IMF) 1.0 to provide content filtering. To help reduce the time spent preventing spam from overtaking mailboxes in Exchange organizations, Microsoft expanded the layered toolset in Exchange 2003 SP2, with antispam options such as SenderID and IMF 2.0. Exchange 2003 SP2 provides antispam protection through a set of tools and options defining a defense-in-depth approach to message hygiene. Getting all these layers to work well for a specific environment takes time and experience. What works for one organization might not work for another. But by using the Exchange Anti-Spam Migration tool, you won’t need to redo your antispam configuration. Although the tool pulls antispam settings from any Exchange 2003 installation, you get the greatest value from using the tool with Exchange 2003 SP2, because of SP2’s additional antispam features.
Maintaining Antispam Settings through a Migration
How do you maintain antispam settings when migrating to Exchange 2007? Most of the Exchange 2003 SP2 antispam settings, such as Sender/Recipient filtering and the DNS Block List hosts used for connection filtering, can be accessed by querying the Configuration container in AD, typically through a scripting interface such as Active Directory Service Interfaces (ADSI). Since Exchange 2007 administration is built upon PowerShell, you can use PowerShell cmdlets to configure message hygiene settings on an Exchange 2007 Edge Transport or Hub Transport server. (You can also configure some message settings, such as automatic pattern file updates, using the Exchange Management Console GUI.)
Microsoft has consolidated these scripting efforts into the Exchange 2007 Anti-Spam Migration tool. The tool queries AD for antispam settings for Exchange 2003, collects content-filtering information from the IMF XML file, and generates the equivalent PowerShell cmdlets to execute on an Exchange 2007 server with the Edge Transport role or with the Hub Transport role and antispam agents installed. It’s a two-step process of gathering settings from the old server, then applying them to the new one.
Installation and Requirements
You can download the tool (Exchange2007AntiSpamMigration.exe) at www.microsoft.com/downloads/details.aspx?familyid=805eaf35-ebb3-43d4-83e4-a4ccc7d88c10&displaylang=en. The 61KB Windows Installer .msi file extracts the tool and accompanying documentation to %program files%\Exchange2007AntiSpamMigration.The tool doesn’t give you the option to change this location. To run the tool, your computer requires Windows Server 2003 or Windows 2000 Server and Microsoft .NET Framework 1.1 or later. The application doesn’t add a shortcut to the Windows Start menu either, so you must navigate to %programfiles%\.
The Anti-Spam Migration tool also needs access to AD under a security context allowing read access to the AD configuration container. If Exchange 2003 uses custom content filtering with IMF, you can direct the tool to read the latest MSExchange.UCEContentFilter.xml file by providing the path and read access to the file. You don’t need to run the tool on the Exchange 2003 server itself. It can be executed from another Windows 2003 or Win2K server in the domain as long as the user context has read access to AD. The tool doesn’t specifically require Exchange functionality to run, as it just reads configuration information from AD and the IMF .xml file on the Exchange 2003 server, if needed.
The path to the custom content-filter file usually includes the latest IMF Update version. For example, the most current version at the time of writing this article is found in the path %ProgramFiles%\Exchsrvr\bin\MSCFV2\6.5.7918.0\MSExchange.UceContentFilter.xml.
Executing the Tool: Exchange 2003
To run the Anti-Spam Migration tool on an Exchange 2003 server you can either double-click Exchange2007AntiSpamMigration.exe to run it silently using default settings, or enter the following at a command line:
Exchange2007AntispamMigration.exe
/f:<path to MSExchange.UceContentFilter.xml>
/o:<output file custom name>
(The code here wraps to several lines; however, you should enter it on a single command line.)
When executed, the tool gathers the antispam settings and converts them to PowerShell cmdlets, which can be executed later on the Exchange 2007 server by using PowerShell. Figure 1 shows the progress of a command similar to the previous example. Note the path to the MSExchange.UceContentFilter.xml file.
The tool provides two switches. To display usage information for the switches, enter /? (the Help switch). The /f: switch identifies the full path to the custom content-filter file (MSExchange.UCEContentFilter.xml) if the file is in use and you want to migrate the information in it. Be sure to place quotation marks around the full path to avoid errors from spaces in file or folder names in the path. Without quotes around the pathname, custom words or phrases within the path won’t be migrated.
The /o: switch lets you control the name and location of the PowerShell file generated as output from the Anti-Spam Migration tool. In the absence of this switch, by default the command writes the PowerShell file to the same directory as the tool with the name MigratedSettings.ps1. If the output file already exists, the tool overwrites it with the new one.
Filters that Get Migrated
The antispam defense filters have many settings that get translated into PowerShell scripts. In Exchange 2003, you apply connection filtering in Global Settings in Exchange System Manager (ESM). The connection-filtering settings include DNS Block List providers and specific addresses. The PowerShell script implements the DNS Block Lists in the Add-IPBlockListProvider cmdlet and adds addresses that are exceptions via the Set-IPBlockListProvidersConfig cmdlet. The script includes parameters for the DNS Block List service Fully Qualified Domain Names (FQDNs) as well as any custom rejection message returned to the connecting server. Also, the script implements any Global Accept or Deny List addresses by using the Add-IPAllowListEntry or Add-IPBlockListEntry cmdlets.
Some aspects of sender filtering in Exchange 2003 aren’t implemented in Exchange 2007 and therefore aren’t migrated with the antispam tool. These include archiving filtered messages, dropping the connection if the address matches the filter, and accepting messages without notifying the sender of filtering. Sender filtering in Exchange 2007 still can reject messages based on having a blank sender, so the Set-SenderFilterConfig cmdlet will be added to the script with the -BlankSenderBlockingEnabled ($true|$false) parameter included. The Set-SenderFilterConfig cmdlet also includes the migrated setting to block specific senders or domains.
Recipient filtering is similar to sender filtering. The PowerShell script uses the Set-RecipientFilterConfig cmdlet to migrate whether to filter messages addressed to recipients who aren’t in AD, and, if a block list is enabled, will include a parameter to list specific recipients to prevent receiving inbound messages.
SenderID is implemented in Exchange 2003 SP2. The PowerShell script adds the Set-SenderIDConfig cmdlet to migrate the action to take if a message fails SenderID validation. If the source server doesn’t have Exchange 2003 SP2, the script reverts to a default parameter to stamp the SenderID status of incoming messages.
In Exchange 2007, the IMF just becomes an SMTP Content Filter. The Set-ContentFilterConfig cmdlet applies the migrated parameters. These include the Gateway Blocking configuration settings with the parameter -SCLDeleteThreshold:<value>. If IMF1.0 isn’t installed or Exchange 2003 SP2 isn’t applied to the Exchange 2003 server, the script implements default value parameters, including -SCLQuarantineEnabled and -SCLDeleteEnabled set to $false.
As mentioned earlier, the Anti-Spam Migration tool checks the most recent MSExchange.UceContentFilter.xml file for any custom entries that affect the spam confidence level (SCL) rating of inbound messages. Apply the /f switch to identify the location of the .xml file.
The tool can also apply Perimeter IP List and Internal IP Range Configuration information. The Set-TransportConfig cmdlet uses the -InternalSMTPServers parameter to restrict addresses if needed.
Executing the Tool: Exchange 2007
To execute the PowerShell script file, MigratedSettings.ps1, on your Exchange 2007 server, open Exchange Management Shell. From the management shell prompt, enter the filename preceded by a dot and backslash (.\), as Figure 2 shows. Doing so will execute the cmdlets listed in the script. Errors from the script, such as incorrect permissions, will appear as red text on the management shell screen. The shell screen will also display a summary of confirmation or warnings for the scripts, as Figure 2 shows.
Listing 1 shows examples of PowerShell cmdlets that the Anti-Spam Migration Tool generated, through the MigratedSettings.ps1 script. This sample is taken from an Exchange 2003 server with Exchange 2003 SP2 installed. Some of the cmdlet parameters would be set to default values if SP2 weren’t yet installed on the source server. The Exchange 2007 server should now have the same antispam configuration across multiple layers as the old Exchange 2003 server did.
Potential Errors
When you run the MigratedSettings.ps1 script, you might see either or both of the following errors:
ERROR: Access to path "c:\program
files\exchsrvr\bin\mscfv2\MSExchange.UceContentFilter.xml" is denied
This error message appears when the user doesn't have read access to the output.
ERROR: c:\program does not exist
I received this error message when I didn’t enclose the path to the custom content filter file within double quotes when I ran Exchange2007AntiSpamMigration.exe with the /f: switch. The program doesn’t seem to recognize spaces within the folder names.
If you use Notepad or another text editor to create or edit the MSExchange.UCEContentFilter.xml file, be sure to save it as Unicode text. If you save the file as ANSI text with the extension .xml, you’ll get the following error in the output:
ERROR: There is no Unicode byte order mark. Cannot switch to Unicode.
ERROR: Error loading c:\program files\exchsrvr\bin\MSCFv2\MSExchange.UCEContentFilter.xml
Migration Simplified
Migrating compatible message hygiene settings from Exchange 2003 to Exchange 2007 has become a little easier with the release of the Exchange 2007 Anti-Spam Migration tool. The tool converts your Exchange 2003 antispam settings to PowerShell cmdlets that can be run on Exchange 2007 to migrate them. By using these scripts to automate running the tool, you'll be able to simplify your Exchange 2007 migration process.
End of Article
Register
