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.
Common ExMerge Scenarios
ExMerge has most often been used to facilitate mailbox moves in migrations and company mergers and divestitures, discovery in legal investigations, search-and-destroy operations, backup and recovery, and archiving. Although Microsoft never intended ExMerge as a be-all-and-end-all solution for any of these areas, many companies typically keep ExMerge in their toolkits to use in such scenarios.
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.
Exchange Management Shell
Microsoft has reengineered Exchange 2007 to include the Exchange Management Shell command-line interface, which is based on the Windows PowerShell scripting language. PowerShell provides Exchange administrators with a scripting language, an interactive shell, and a means for producing task-oriented commands. These commands are called cmdlets (pronounced “command-lets”) and take the form of a verb-noun combination; the English-language equivalent would be a phrase such as “reboot-computer” or “sell-car.” Also new in Exchange 2007 is the Exchange Management Console (which replaces Exchange System Manager—ESM), which Microsoft architected such that the functionality available in the GUI is really a subset of the functionality available within the command line. In fact, all administrative actions for Exchange 2007 are now scriptable through the management shell. Exchange Management Shell gives Exchange administrators access to a powerful set of PowerShell cmdlets that enable most of the commonly used functionality you're familiar with in ExMerge.
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.
Now let’s launch Exchange Management Shell and take a quick look at how it works. You should see a blinking cursor on a black DOS-like screen, next to a prompt like this: \[PS\] C:\Documents and Settings\Aslan>. Now let’s try a few things. Type
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.
Migrations, Mergers, and Divestitures
As you've seen, many companies used ExMerge in various migration scenarios, such as in smaller organizations or in cases where data was exported to PST, then reimported into a target set of mailboxes as part of the migration. Exchange 2007 supports the following migration scenarios from within EMS.
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.
Another common use of ExMerge has been to extract mailbox data in response to a legal investigation. To perform this function in Exchange 2007, you can use the export-mailbox cmdlet, as the example in Figure 6 shows. The command first uses get-mailbox -database to determine which mailboxes exist in Mailbox Database, then pipes that list of mailboxes to the export-mailbox cmdlet. The command then searches those mailboxes for all attachments with a filename containing “money” and copies all the messages it finds into the Investigator mailbox in the Inbox folder. The export-mailbox cmdlet creates a folder for every mailbox in which it finds matching data and automatically names this folder according to the current date and time. Figure 7 shows an example of several folders created by the export-mailbox cmdlet. Export-mailbox supports searches based on these parameters: -StartDate, -EndDate, -AttachmentKeywords, -SubjectKeywords, and -ContentKeywords.
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.")
Search and Destroy
You can also use the export-mailbox cmdlet to perform search-and-destroy tasks (i.e., removing a message from multiple mailboxes or multiple messages from a mailbox). Simply append a -DeleteContent parameter to export-mailbox, as the command in Figure 8 shows. This command finds all content in Aslan’s mailbox containing the word "resume" and deletes it, placing a copy of the deleted items in the Investigator mailbox. Keep in mind, of course, that performing content-sensitive search operations will cause a hit on your production Exchange servers because, as part of the process, you’re querying the full-text index on each server. Indexing has been dramatically enhanced in Exchange 2007, and full-text indexing is now turned on by default on all your Exchange 2007 servers. Since full-text indexing is based on IFilters, any attachment-content search results will depend on the IFilters present on every Exchange 2007 server searched.
Secondary Backup and Recovery
As mentioned earlier, organizations sometimes use ExMerge to provide a secondary backup by simply exporting mailboxes to a PST on an automated, regular basis. Because Outlook provides the only means to export to PST in Exchange 2007, this secondary-backup scenario is no longer possible in Exchange 2007, at least until SP1 ships. For now, organizations that use ExMerge for secondary backup will need to keep ExMerge around for this purpose.
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.
Archiving Terminated Employees' Mailboxes
To archive mailboxes of terminated employees or consultants after they leave an organization, you can use a method similar to the options used for discovery. The simplest method, for now, is to continue to use ExMerge. If doing so isn't an option, you can either simply log on to the mailbox and export its contents to PST or use export-mailbox (as I explained in Discovery section) to export mailbox contents to a folder in another mailbox, then use Outlook to save that content to PST. After Exchange 2007 SP1 ships, this process will be possible without performing the manual save-to-PST operation from within Outlook.
For better or for worse, ExMerge has come to the end of its life with Exchange 2007, and sooner or later we'll all need to roll up our sleeves and take a crash course in using Exchange Management Shell to manage our Exchange servers. In Exchange 2007’s new world order, Exchange admins have, of course, gained a boost in search capabilities, including previously unheard-of abilities to search all levels of Exchange content throughout an organization and to move, export, restore, or search and destroy items of interest. You can now also simply string multiple, relatively intuitive PowerShell cmdlets together to pipe output from one cmdlet into another, then automate the entire set of commands so that you can reuse them.
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.