In Exchange 2007, you can use PowerShell cmdlets to perform most ExMerge functions
If you’ve been working with Exchange for any length of time, no doubt you've become accustomed to the Exchange Server Mailbox Merge Wizard (ExMerge). ExMerge originally shipped in 1997 as part of Exchange Server 4.0 and has evolved over the years to include more and more functionality. (You can download ExMerge at http://www.microsoft.com/downloads/details.aspx? familyid=429163ec-dcdf-47dc-96da-1c12d67327d5&displaylang=en.) Of all the tools I’ve seen come out of the Exchange team over the past decade, none has had ExMerge's passionate following.
With the release of Exchange Server 2007, you might wonder whether ExMerge still exists. Although the familiar ExMerge UI is indeed gone, many of the most frequently used features in ExMerge have actually been rewritten as part of Exchange Management Shell—a powerful command-line scripting environment that's based on Windows PowerShell technologies and is a core part of Exchange 2007. That said, export-to and import-from personal folder file (PST) capabilities are completely gone from the release to manufacturing (RTM) version of Exchange 2007. The Microsoft Exchange team has stated publicly that it will introduce PST support in the Exchange 2007 Service Pack 1 (SP1) timeframe. Microsoft won’t block ExMerge access to Exchange 2007 until at least that time (if ever), so companies will be able to use ExMerge for Exchange 2007 operations as long as ExMerge isn't installed on the Exchange 2007 server itself. Nevertheless, Microsoft is no longer investing in ExMerge, and the tool's days are numbered. I'll review the most common scenarios for using ExMerge in pre–Exchange 2007 versions, then explore to what degree the Exchange Management Shell functionality in Exchange 2007 supports these uses.
For migrations, mergers, and divestitures, administrators have used ExMerge as a sort of primitive migration tool in certain inter- or intraorganizational mailbox moves—especially in low-bandwidth environments or when no trust exists between two merging organizations. ExMerge permits bulk export-to-PST from the source organization, then bulk import-from-PST into the target organization. For divestitures, ExMerge enables export of all content after a specific date (e.g., acquisition close date), enabling a method for splitting data off when part of an organization is severed for some reason.
Organizations have relied increasingly on ExMerge as a basic discovery solution to respond to various types of investigations (e.g., audit, legal, security, human resources). Typically in such investigations, an Exchange administrator is requested to produce all email from a given mailbox or set of mailboxes, export mail to personal folder files (PSTs), then hand the PSTs off to the requesting party. (For more information about email discovery, see "Build an Email-Discovery Plan," April 2006, InstantDoc ID 49896.) ExMerge was convenient because it let an administrator perform these exports in bulk; supported deleted-item retention; allowed for specific folder selection; and permitted filtering by subject line, attachment filenames, delivery time, or last-modification time.
Additionally, ExMerge is commonly used for search-and-destroy operations, namely when an email message needs to be removed from multiple mailboxes across an organization because the message was sent mistakenly (e.g., a sensitive report). Although not an enterprise search solution by any means, ExMerge at least enables search and destroy on a server-by-server basis. Similarly, organizations sometimes need to remove potentially damaging content such as unusually well-written phishing messages or virus-infected messages that have somehow circumvented antivirus and antispam scanning engines.
For backup and recovery, organizations sometimes use ExMerge to automate a second layer of "backup" that exports all or, more commonly, a subset of mailboxes to PSTs regularly. Administrators use this export to supplement existing backup software in case a regular backup and recovery doesn't work as intended, or, in some cases, to provide item-level recoverability when costly and time-consuming brick-level backups aren't in use. Another less common recovery scenario that I’ve heard some organizations keep ExMerge around for is to salvage data from a corrupt Exchange database, should doing so become necessary. And although Recovery Storage Groups (RSGs) have greatly simplified recovery processes, ExMerge has still found its place in scenarios where item- or mailbox-level recovery is required in the context of RSGs, since RSGs lack inherent filtering capabilities.
Finally, for archiving, ExMerge has typically been used to archive mailboxes of terminated employees to PSTs for safekeeping, should an employee return to the organization unexpectedly or the mailbox data is needed for any reason. Many organizations include "ExMerging" a mailbox to PST as part of the user-deprovisioning process when employees or consultants leave an organization.
To get started with Exchange Management Shell, you’ll need an Exchange 2007 server to connect to that has mailboxes containing data. I'll assume that you already have one installed and properly configured. I'll walk you through the steps to install Exchange Management Shell on a separate administrative workstation, since many administrators will probably want to work in a similar manner as they did with ExMerge, without having to work directly on an Exchange server.
On the machine where you want to install Exchange Management Shell, run the Exchange 2007 setup, accept the license terms, and launch a Custom Exchange Server Installation. Either accept the default path of C:\Program Files\Microsoft\Exchange Server or choose another location. Then in the Server Role Selection dialog box, ensure that only the Management Tools check box is selected, as Figure 1 shows.
After your installation is done, both Exchange Management Console and Exchange Management Shell should be installed locally. You can confirm this by clicking Start, Programs, Microsoft Exchange Server 2007 and verifying that Exchange Management Shell and Exchange Management Console are available.
\[PS\] get-exchangeserver
You should get output similar to what Figure 2 shows. Basically, you've quickly retrieved some default metadata about the Exchange server that you're connected to. Now type
(This and other commands in this article may wrap to multiple lines because of space limitations; you should type the command on one line.) Essentially what you're doing is called "piping" the get-exchangeserver output to the get-mailbox-database cmdlet to find the names of all databases on the server you're connected to. The output should look similar to that in Figure 3.
Now let’s see how much of ExMerge's functionality exists in Exchange 2007. You'll use three cmdlets: move-mailbox, restore-mailbox, and export-mailbox. We'll walk through the ExMerge scenarios discussed earlier and see how to use Exchange Management Shell cmdlets in Exchange 2007 to achieve ExMerge-like functionality.
Interorganizational (crossforest) or intraorganizational (intraforest) mailbox moves. In this situation, an organization typically uses either the Move Mailbox option within Exchange Management Console’s Recipient Configuration\Mailbox node or uses Exchange Management Shell to run the move-mailbox cmdlet. Both mechanisms are supported in the interorganizational (crossforest) model, as long as network connectivity to both forests is available and as long as source and target servers are running Exchange 2007, Exchange Server 2003 SP1 or later, or Exchange 2000 Server SP3 or later. (For more information about crossforest mailbox moves, see Paul MacKnight's posts "Exchange 2007 migration overview" and "Exchange 2007 Cross Org Mailbox Migration" on the Microsoft Exchange Team Blog, http://msexchangeteam.com/archive/2006/10/27/429522.aspx and http://msexchangeteam.com/archive/2006/11/02/430289.aspx, respectively.)
You can also use the Move Mailbox option within Exchange Management Console’s Recipient Configuration\Mailbox node to perform intraorganizational moves. However, you must use the move-mailbox cmdlet to perform interorganizational (crossforest) moves; Exchange Management Console (at least in Exchange 2007 RTM) doesn't provide this capability.
Low-bandwidth or no-trust migrations from legacy environments to Exchange 2007. In this scenario, organizations can continue to use ExMerge at least until Exchange 2007 SP1 ships, or as long as Microsoft allows unblocked access to the Exchange 2007 databases. As stated earlier, the only caveat is that you can't run ExMerge from the Exchange 2007 server itself. Exchange Management Shell provides no mechanism for this usage scenario, although this will change when Exchange 2007 SP1 ships with the PST-handling capabilities.
Low-bandwidth or no-trust migrations from Exchange 2007 to Exchange 2007. To accomplish such migrations, Microsoft recommends moving an entire database from the source to the target organization. Let’s say you want to move a database called Mailbox Database from the Exchange 2007 server NARNIAEXMBX01 to another server called ARCHENLANDEX01 on the other end of a really slow link. First you need to create a new database on the target server that has the same name as the original database (e.g., “Mailbox Database”) and ensure that the Allow this Database to be Overwritten by a Restore check box is selected. You can do so manually through Exchange Management Console, or you can issue the Exchange Management Shell commands that Figure 4 shows, but you must make sure to use the same name for the new database as the original database.
Next, you’ll want to manually copy all the database files (.edb, transaction-log files, and content-indexing catalog) from NARNIAEXMBX01 to the correct locations on ARCHANLANDEX01. Now mount the database by running this command:
Finally, you’ll need to ensure that all mailboxes on this store are reconfigured in Active Directory (AD) to reflect their new location, by running the command that Figure 5 shows. I used the get-MailboxStatistics cmdlet initially to obtain a list of all the mailboxes on the database, then piped the results into the move-mailbox -ConfigurationOnly cmdlet to reset the configuration for every mailbox found.
Historically, organizations have addressed discovery requests by having their IT administrators use ExMerge to dump mailbox contents to PSTs, then hand the PSTs off to the legal department. With Exchange 2007, IT administrators can still dump mailbox contents to PSTs themselves (manually by using Outlook), or they can simply provide an investigator’s mailbox to the legal department and use export-mailbox to respond to discovery requests as they arise. Investigators can then use Outlook to export either each folder (corresponding to a mailbox) or messages and attachments of interest to a PST, if desired. In most cases, investigators or attorneys aren't given direct access to the mail system, so IT administrators will likely still be a part of the process until the export-to-PST functionality ships in Exchange 2007 SP1.
Keep in mind, of course, that this set of discovery technologies is simple and doesn’t address requirements around maintenance of chain of custody, which are key for situations in which evidential weight is paramount, notably legal discovery scenarios. (For more information about chain of custody and email discovery, see "Build an Email-Discovery Plan.")
Organizations also use ExMerge to recover data from a corrupted database on an as-needed basis. In Exchange 2007, you can accomplish this by using the restore-mailbox cmdlet in conjunction with dial-tone recovery. If, for example, Mailbox Database is corrupt, you can take the following steps:
1. Move the corrupt files to another location.
2. Mount an empty database in the original location to establish dial tone.
3. Restore the original database from backup.
4. Swap the recovered database with the dial-tone database to give users their original mailboxes to the point of the backup.
5. Move the dial-tone database to the RSG and use restore-mailbox to merge newly received data into the original mailboxes. You can do this by using a command similar to the one in Figure 9.
This procedure in effect merges all mailboxes in Mailbox Database if they're also found in the dial-tone database.
Organizations also use ExMerge when they want to achieve item- or mailbox-level recovery by using RSGs. You can use the restore-mailbox cmdlet to accomplish such recovery, specifying the mailbox identity, subject, or content keywords of interest, as the examples in Figure 10 show. The usual caveats around RSGs still apply.
ExMerge functionality is still available to Exchange 2007 users, for the time being. No one knows yet (including Microsoft) whether Microsoft will decide to block ExMerge access once Exchange SP1 ships. Fortunately, most of the key capabilities that were available in ExMerge are also available in Exchange 2007, with the somewhat-painful exception of export-to-PST and import-from-PST, so I recommend that you start familiarizing yourself with the new way of doing things.