There are hundreds of articles online that explain the intricacies of Exchange migrations. However, most of them fail to mention the importance third-party add-ons play in the process.
Many companies use various third-party add-ons, which may or may not function correctly with the version of Exchange they’re upgrading to. So it’s critical to test add-ons prior to the upgrade and to budget for updated versions if necessary. Let’s look at the most common third-party applications you should be aware of.
To adequately protect your organization, you must have Exchange-aware antivirus software running on your Exchange servers. Unfortunately, there’s a good chance your existing antivirus software won’t be compatible with your new version of Exchange.
Think about how Exchange has evolved. In Exchange 2000, certain antivirus applications accessed Exchange data through the M: drive. The software had to be Exchange-aware, because file level scans of the M: drive often led to a variety of problems. In Exchange 2003, Microsoft did away with the M: drive and vendors had to find a different way to interface with the mailbox database. In Exchange 2007, Microsoft redesigned Exchange once again and most of the Exchange 2007 antivirus programs were redesigned to interface with the hub transport rather than the mailbox store.
The point is, as Exchange evolves, so too must your antivirus software. Don’t assume that your existing antivirus solution will continue to work.
Several years ago, my organization was running Exchange Server 2003, and using a product called GFI Mail Essentials to protect it from spam. When I upgraded to Exchange 2007, I discovered that the version of Mail Essentials I was using wasn’t compatible. I didn’t realize that most Exchange antispam products are version-specific.
It’s critical to test your antispam software with your new Exchange Server version before upgrading. If you find that your antispam product isn’t compatible, you may have to hold off on the upgrade until a new version of the software becomes available.
You may be tempted to purchase a competing antispam product rather than wait for the upgrade, but I advise against doing so. Antispam software contains user specific data -- such as white and black lists -- that isn’t easily migrated to a competing product.
Before Exchange Server 2010, most archival products dumped messages either into a .pst file or an external database. Although some vendors still use this approach, others have begun interfacing with the Exchange 2010 archive database.
Of all the types of add-on software discussed in this tip, archival software is probably the software type that’s most likely to continue working properly after an upgrade. That said, it’s still extremely important to see if your archival software can function correctly with the new version of Exchange.
Monitoring software is almost always Exchange Server-version specific. Most of the monitoring applications use performance monitor counters to gauge the health of your servers. Acceptable threshold values for these counters change from one version of Exchange to the next.
Backup software requirements have been dramatically impacted by the evolution of Exchange Server. For years, Microsoft recommended streaming backups of mailbox databases. In Exchange 2007, Microsoft began pushing VSS backups. Streaming backups were still supported, but not recommended. In Exchange Server 2010, Microsoft dropped support for streaming backups altogether.
It’s important to use a backup application that keeps pace with Microsoft’s backup and recovery requirements for Exchange. A lone VSS-aware backup application simply isn’t enough. The backup application must be Exchange-version specific.
VSS backups are supported in Exchange 2007 and Exchange 2010. One of the preferred methods for restoring data in Exchange 2007 is to use a Recovery Storage Group. However, Recovery Storage Groups do not exist in Exchange Server 2010. If you try to use an Exchange 2007 backup application to restore an Exchange 2010 server, you may be in for an unwelcome surprise.
As you test your software in a lab environment, remember to test the new version of Exchange as well as coexistence configurations where multiple versions of Exchange exist on your network. You may find that some add-ons work in coexistence scenarios, but stop working after you uninstall the legacy version of Exchange and vice versa.
ABOUT THE AUTHOR:
Brien Posey is an eight-time Microsoft MVP with two decades of IT experience. Before becoming a freelance technical writer, Brien worked as a CIO for a national chain of hospitals and healthcare facilities. He has also served as a network administrator for some of the nation’s largest insurance companies and for the Department of Defense at Fort Knox.
This was first published in January 2012