Deployment Blockers for Upgrading to Exchange Server 2007

Executive Summary: Avoid the gotchas and ensure a successful upgrade. You’ll need to be clear on AD topology, and then deal with deployment issues with public folders, client software, archival and retention, fax, mobility, and coexistence with other Exchange versions.

In a perfect world, IT upgrades would happen automatically and seamlessly—without any human intervention. Despite the effort Microsoft put into building Microsoft Exchange Server 2007, it still can’t perform an upgrade for you; that’s something that you’ll have to do yourself.  But when you take on an upgrade you can smooth the way by understanding and dealing with potential deployment blockers, such as Active Directory (AD) infrastructure, public folders, client software, archival and retention, fax, mobility, and coexistence in a mixed Exchange world.

Active Directory and Exchange 2007 Upgrades
AD topology is the biggest aspect of your environment to consider. There are five scenarios to keep in mind when you choose a topology for your upgraded environment:

• One forest. In this scenario, a single AD forest contains Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003 servers, and you install Exchange 2007 into it. This is the simplest scenario, because you simply install your Exchange 2007 servers and move mailboxes to them.
• Cross-forest. In this scenario, an existing cross-forest AD infrastructure contains previous versions of Exchange and you want to retain multiple forests.
• One forest to cross-forest. This is more complicated than the preceding configurations because it calls for deploying Exchange 2007 in one forest and keeping your existing Exchange infrastructure in its separate forest. This scenario lets you build a completely new forest for your new Exchange deployment, but introduces lots of subtle complexities related to cross-forest Exchange management. If you go this route, I suggest that you read the Exchange 2007 documentation from Microsoft, which has a great deal to say about how to synchronize the global address lists between two forests and how to make Exchange work properly in this environment.
• Resource forest. In this scenario, you’ve deployed a previous version of Exchange  using a resource forest, and you plan to keep the resource forest and replace (or augment) your existing Exchange servers with new Exchange 2007 servers. This is almost as easy as the one-forest scenario; you can install Exchange 2007 servers in your dedicated Exchange forest and move mailboxes to them.
• Single forest to resource forest. This is the most complicated scenario because it requires you to set up a resource forest for Exchange 2007 (which in turn, implies adding a forest for user accounts too), then create a cross-forest relationship between the old and new forests. This scenario is pretty rare, fortunately, but organizations that need it usually need it badly because of legal or regulatory requirements that force them to a multi-forest design.

Keep a few additional caveats in mind. First, after you create an Exchange 2007 organization by installing into a virgin forest, you can’t install older versions into that organization. You’re free to install Exchange 2007 servers into your Exchange 2000 or Exchange 2003 environments (with the proper schema updates). Second, remember that all Exchange 2007 servers will be in their own routing group and their own administrative group. Don’t move them, and don’t move older servers into the Exchange 2007 groups. Third, if you’re using more than one routing group, you’ll need to disable link state routing updates as detailed in the Exchange 2007documentation.

These restrictions aside, which of these AD topologies you plan to use doesn’t matter from an Exchange 2007 standpoint; it will work equally well in any of them. However, if you have to make changes to your AD topology to support your preferred deployment, make those changes before you start your Exchange deployment.

Public Folders
To ensure a successful upgrade, let’s start with the simplest decision point—public folders. When Exchange 2007 shipped, it didn’t have the same public folder functionality that Exchange 2003 did; Exchange 2007 didn’t provide public folder access through Outlook Web Access (OWA), nor did Exchange Management Console (EMC) provide much in the way of public folder management support. Some organizations that heavily use public folders keep Exchange 2003 servers around to support public folders. However, Exchange 2007 SP1 fully restores public folder features. With SP1, you can manage public folders from either Exchange Management Shell (EMS) or EMC, and you have full access to public folders through OWA 2007. Exchange 2007 SP1 also adds a new Public Folder Administrator role that you can use to grant public folder management access to users without giving them access to anything else.

Client Software
One common misconception about Exchange 2007 is that it requires Microsoft Office Outlook 2007. It doesn’t, but watch out for a couple of considerations. The biggest is that Microsoft Office Outlook 2003, and earlier versions, depend on having access to the system free/busy and Offline Address Book (OAB) public folders. These are created automatically when you install Exchange 2003 or earlier versions, and in normal operation they’re invisible. When you install Exchange 2007 into a new organization, the Exchange setup utility asks you if you have older versions of Outlook in your organization. What it’s really asking is “Should I create the system public folders that Outlook requires?” If you say no, the first Exchange server you install won’t get a public folder store, nor will the system public folders be created. Any Outlook 2003 or earlier clients will be unable to download the OAB or get free/busy information. This is a concern for new Exchange 2007 deployments (such as the one-forest to cross-forest AD deployment scenario). However, when you install Exchange 2007 into an existing Exchange 2003 organization, Outlook 2007 clients connect to the Exchange 2007 Client Access server to find the availability service and OAB download point; previous clients will continue to use the system folders. Before you remove the last Exchange 2003 server, you should ensure that at least one Exchange 2007 server has replicas of the OAB and system free/busy folders so that previous versions of your clients will work; you can remove these replicas after the last legacy Outlook client has been removed.

Archival and Retention
Archival and retention systems pose an interesting set of problems for Exchange upgrades. Archive systems tend to have a high degree of stickiness—once a company adopts one, it’s often difficult to switch to another one, and the longer one is in use the more difficult switching becomes (especially because most archiving vendors don’t place a premium on the ability to export or move data from one archive system to another). Exchange 2007 doesn’t provide archiving functionality, although its journaling capabilities are significantly improved. A particular big win in efficiency is the ability to journal individual mailboxes or distribution groups (which requires purchase of Enterprise client access licenses—CALs—for the mailboxes you want to journal).This capability lets you journal (and thus archive) only the mailboxes you need. Exchange 2007 also supports journaling to arbitrary SMTP addresses, which might eliminate the requirement to use an archiving agent on your Exchange servers. Ensure that your archiving vendor supports Exchange 2007 before you migrate mailboxes that have to be archived.

Fax
Exchange 2007 provides inbound fax answering capabilities if you deploy the Exchange Unified Messaging (UM) server role, but fax is a funny thing. Some organizations rely on it heavily and some rarely use it. Most companies that want integrated fax capability have already deployed a third-party solution that provides two-way fax capability so users can both send and receive faxes from their desktop computers. If a company already has one of these systems, a move to Exchange’s receive-only capability may not make sense. Organizations that don’t need this capability enough to have deployed it already are probably not likely to view receive-only fax capability as a compelling reason to upgrade, either. This is one case where your best choice might be to maintain your existing Exchange 2003–based fax capability. If you’ve already deployed a fax solution, and it’s already working, adding Exchange 2007 Mailbox, UM, and Hub Transport servers can give you some worthwhile functionality without requiring that you junk your existing fax investment. For most customers, the value of Exchange UM primarily comes from the voicemail and automated attendant functionality, not inbound fax.

Mobility
Mobility is one of Microsoft’s key investment areas in Exchange 2007. In particular, SP1 adds more than 30 device management policies that you can apply to control things such as whether managed devices can use their onboard cameras. The new System Center Mobile Device Manager further extends management capabilities for compatible devices by allowing them to be joined to AD domains and managed using Group Policy Objects. Of course, device management solutions such as SCMDM or Sybase iAnywhere are primarily of interest to companies that are using Windows Mobile devices, not BlackBerry devices. If you’re using the BlackBerry Enterprise Server, you may find it more economical to move to Windows Mobile as your primary device platform so you don’t need to buy more BlackBerry Enterprise Server licenses or maintenance. On the other hand, in a large device deployment, the cost of replacing your devices may outweigh the savings. (Note that as of this writing, Research In Motion is shipping version 4.1.4 of BlackBerry Enterprise Server, which has limited support for Exchange 2007; the forthcoming 4.1.5 version is expected to offer full support.)

Peaceful Coexistence
You can deploy Exchange 2007 to add specific functionality without necessarily moving your organization to it wholesale. For example, you can deploy the Edge Transport server role to provide message hygiene in front of an Exchange 2003 deployment, or you could deploy a single Exchange 2007 server with the Hub Transport, Mailbox, and UM server roles to provide Outlook Voice Access (OVA) and UM capability to selected mailboxes. Keep one simple rule in mind: If you want an Exchange 2007 feature for a user, the associated mailbox will need to be on an Exchange 2007 server. For example, even if you have an Exchange 2007 UM server deployed, you’ll only be able to UM-enable mailboxes stored on an Exchange 2007 Mailbox server. This rule has a few exceptions. One is that you can use EMS to manage mailboxes anywhere in your organization, even if they’re on Exchange 2003 servers (although you won’t be able to manage Exchange 2007–specific mailbox properties). Another exception is that in a mixed organization, you can create multiple SMTP connectors for sending and receiving messages. If you have connectors on Exchange 2003 servers, you can see the connector settings in EMC, but you can’t change them—for that, you’ll have to use Exchange 2003’s management tools. (Speaking of which, installing the Exchange 2003 and Exchange 2007 management tools on the same workstation isn’t officially supported.)

Is an Upgrade for You?
Microsoft walks a fine line when it introduces new versions: Time spent on backward compatibility and coexistence takes away from time available for new feature (and bug fix) development. But spending too little time on these things aggravates customers (thus reducing their desire to upgrade) and damages their ability to upgrade when they do want to. In most circumstances, Exchange 2007 servers can coexist happily with older versions; the specific circumstances I outlined in this article may influence your decision on when to upgrade, but the basic process of installing Exchange 2007 servers and moving mailboxes to them will remain the same no matter what other deployment blockers you face.

 

End of Article