Plan a Smooth Migration

When migrating to a completely new Exchange Server 2003 organization, one of the biggest challenges is figuring out how to group people into batches for migration. You might first think of grouping users according to business unit, geographical location, or server. You might also consider who's already been trained on Exchange 2003 and how many new users the Help desk can support at once.

There might also be technology factors to take into account. For example, if your organization uses BlackBerry Enterprise Server (BES) or a Voice over IP (VoIP) integration server; you might need to migrate all the users on these servers together (regardless of their other affiliations) because these servers can be integrated with only one Exchange system at a time.

Another factor that increases migration-scheduling complexity is the access rights one mailbox can grant to another. Exchange and Outlook make it easy for administrators and users to grant other mailboxes access to all or part of a mailbox or calendar. For example, administrative assistants often need access to their supervisor's calendar so that they can schedule meetings for the supervisor, or subordinates might need read-only access to a team leader's task list. Just as you need to migrate together all the mailboxes associated with a service such as BES or VoIP, you often have to migrate as a group people and resources linked together by access rights.

Let's explore how permissions and access rights affect migration planning and discuss some tools and techniques you can use to develop migration schedules. I'll focus mainly on tools and techniques for moving from Exchange Server 5.5 to Exchange 2003. Most of the techniques also apply to migrations from Exchange 2000 Server to Exchange 2003.

Defining and Using Access
Exchange 5.5 stores mailbox access permissions in two places: the Directory Service (DS) and the Information Store (IS). Permissions applied in the DS give someone all rights to an entire mailbox and are generally referred to as user-level access.

Permissions applied in the IS can be much more granular than those applied in the DS and can apply to subparts of a mailbox, such as the Calendar and Tasks folders. Not only can you limit access to a specific folder within a mailbox, you can limit what actions can be taken in that folder, as listed in Table 1. For example, you could specify that one person can read, create, edit, and delete tasks (Editor), while another can read tasks but not change them (Reviewer). Access is typically assigned by using one of the nine predefined roles listed in Table 1. You can also choose from the eight types of access in the Permissions column to define custom roles, such as an editor who can also grant other accounts permissions on a folder.

You can grant permissions in three ways. The first uses user-level access via the DS; the rest set folder-by-folder permissions in the IS:

The first two interfaces let you specify permissions by using either roles or a custom selection of access rights. But when assigning permissions to a delegate, you're limited to four roles—None, Reviewer, Author, and Editor—which provide the same access as the roles with the same names listed in Table 1, and you have no customization capability.

After people have been granted access, they use that access in four ways: First, people with user-level access to a mailbox can define an Outlook profile and open the mailbox directly—the same way they do when they open their own mailbox. Second, after people with user-level access to multiple mailboxes have opened their own mailbox, they can right-click the root Mailbox folder in Outlook's folder tree, select Properties from the context menu, and click Advanced to configure Outlook to open the multiple mailboxes at the same time. Third, people with user-level access can open Outlook and select File, Open, Other User's Folder to open one of the six top-level folders—Calendar, Contacts, Inbox, Journal, Notes, and Tasks—and access items as defined by their role (e.g., Reviewer, Editor).

Fourth, people who've been specifically assigned as delegates by the mailbox owner (using the Delegates Tab under Tools, Options) have extended capabilities to manage all or part of another person's or resource's mailbox (in addition to using the File, Open, Other User's Folder capability as described earlier). For example, when someone sends a meeting invitation to a delegated mailbox, the delegate receives a copy of that invitation in his or her own mailbox. When the delegate opens the invitation, Outlook reads the delegated mailbox's calendar to see whether the meeting time is available. If the delegate clicks Accept or Tentative, Outlook writes the meeting to the delegated mailbox's Calendar folder. An example of when a delegate might use this functionality is controlling the use of some resource such as a conference room or vehicle.

Assessing Access
Now that you have this background on user access to mailboxes, you can see that permissions can create a close relationship between mailboxes. I refer to the mailboxes as associated when such a relationship exists.

It's important for associated mailboxes to be on the same system at all times. If a user needs to access two mailboxes on different systems during an extended migration process, the only viable access option is the dual-profile method, which isn't really a workable solution. Imagine a resource mailbox for a conference room that's accessed by hundreds of people. After this resource has been migrated to another system, nonmigrated users would have to create a secondary Outlook profile. Then whenever they wanted to schedule the conference room, they'd have to exit their primary Outlook session, use the secondary profile to start Outlook again, open the conference room's calendar to see when the room was available, exit Outlook, restart Outlook with the primary profile, and compare the room's availability to that of the attendees. That's a lot of back and forth between Outlook sessions to perform what was previously an easy task; hopefully, by the time this back and forth is done, the room isn't booked by someone else! Imposing this type of workaround on users during migration will only result in user frustration.

To make migration successful, you need to plan to migrate associated mailboxes together. Thus, you need a way to determine which mailboxes are associated. It's relatively trivial to find the "high-visibility" mailbox associations such as that between your CIO's mailbox and his or her assistant's mailbox. What's much harder is finding the associations between the two people in the budget office who monitor each other's inbox for urgent messages when one or the other is out sick or the 10 people with Owner access, 50 people with Editor access, or 150 people with Reviewer access that all use one of 200 resource mailboxes. To find these associations, you'll need to pull information from the DS and IS by using two different tools: Exchange Administrator and the Microsoft Mailbox Information Program (MBInfo).

First, use an Exchange Administrator-export to gather information about people who have user-level access to a mailbox. To create the export, use Notepad to create a file that contains the following text:

Obj-Class,Directory Name,   Obj-Dist-Name,  Primary Windows NT Account,  Obj-Users 

Type all the text on one line with no spaces after the commas. The single spaces between the words in the Directory Name and Primary Windows NT Account elements are important. Save the file as a comma-separated value (CSV) text file named useraccess.csv.

Exchange Administrator will use this file to determine what object information to export from the DS. The Obj-Users header tells Exchange Administrator to list any accounts that have user-level access to an object. In Exchange Administrator, select the Directory Export function from the Tools menu. Select the Recipients container for the site you're scheduling for migration, specify useraccess.csv as the export file, then click the Export button. (For more information about creating CSV files for exporting Exchange information, see the Microsoft articles "XADM: Bulk Import/Export FAQ," http://support.microsoft.com/?kbid=155414, and "XADM: Exporting and Importing Permissions on Objects," http://support.microsoft.com/?kbid=188628.) When the export is complete, you'll have a CSV file like the one that Figure 3 shows (viewed in Microsoft Excel) that lists the primary account associated with a mailbox in the Primary Windows NT Account column. All accounts that have user-level access are listed in the Obj-Users column, separated by a percent (%) sign. The primary account is also listed in the Obj-Users column.

Next, you'll need to use the MBInfo program, which can read per-folder, per-mailbox access settings from the IS for the six primary folders (Calendar, Contacts, Inbox, Journal, Notes, and Tasks). MBInfo reads information about mailboxes on one or more servers in a site and saves the data to a text file. MBInfo is a very useful tool because in addition to extracting folder permissions, it gathers other details such as a mailbox's size, the size of the deleted items folder, the most recent logon and logoff times, and a mailbox's quota state.

MBInfo is available only by calling Microsoft Product Support Services (PSS). MBInfo has evolved through several generations—the most recent version is 3.0.0.3. If you have an older version, you'll need to upgrade to be able to extract the permissions information. MBInfo can run in either batch mode or as a wizard-style GUI. For the purpose of exporting data for migration planning, running the tool in GUI mode is usually sufficient, but if you want to run it from a batch file, doing so is well documented.

MBInfo runs on Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0 Service Pack 6 (SP6). If you'll be using the tool on NT 4.0, make sure the system has Microsoft Internet Explorer (IE) 4.01 or later and Active Directory Client Extensions installed. You'll also need to have Exchange Administrator (for Exchange 5.5) or Exchange System Manager (ESM—for Exchange 2003 or Exchange 2000) installed. To install MBInfo, simply copy the mbinfo.exe and mbinfo.ini files to the folder that contains your Exchange administration software.

To run the tool, start mbinfo.exe under the security context of an account that has Service Account rights. MBInfo will display a set of six wizard pages. The second page asks you to select a procedure—choose Extract mailbox resources and default folder permissions and click Next. The third page, which Figure 4 shows, lets you specify output filenames and select options related to extracting permissions. At the bottom of the page is an option labeled Extract permissions only from folders that allow access to users other than the mailbox owner. Clear this option and click Next. If this option is selected, the export file won't list the names of all the users on the server. The reason you need to clear this option will become apparent when I discuss how to determine mailbox relationships in an upcoming article.

On the fourth page of the MBInfo wizard, specify the name of an Exchange server. If you're using Exchange 2003 or Exchange 2000, you also need to provide domain controller (DC) and LDAP port information. Click Next. MBInfo queries the directory server you specify to find any other servers in the site or administrative group and lists them on the fifth wizard page. One by one, select each server in the Servers Available box and click the Add button to move its name to the Servers Selected box, then click Next. MBInfo now extracts the permission information for the files you specified on the third page of the wizard. The files are tab delimited and can be reviewed in Excel or any text editor. Figure 5 shows a sample file reviewed in Excel. As you can see in the figure, each permission set is surrounded by single quotes and when multiple people have permissions, there is no delimiter between the sets.

These export files contain a tremendous amount of information. Over the next month, try these tools in your environment and get a feel for the file formats and the kinds of data and permissions combinations in your environment. In an upcoming article, I'll show you how to assess these files and determine the relationships created by permissions. Once you have a better idea of the relationships between the mailboxes in your organization, you'll be well on the road toward a better migration plan.

Joseph Neubauer (jneubauer@windows itpro.com) is a senior systems engineer and technologist working to support portions of the US Federal workforce. He specializes in messaging and communications systems.