Building a good migration schedule can make migrating from Exchange Server 5.5 to Exchange Server 2003 (or even Exchange 2000 Server to Exchange 2003) so much easier. In "Plan a Smooth Migration," March 2006, InstantDoc ID 49001, I describe why you need to consider the permissions relationships between mailboxes when you set out to design a migration schedule. In that article, I also explain how to use Microsoft Exchange Administrator and the Mailbox Information Program (MBInfo) to generate output that can help you assess the permissions-linked relationships between mailboxes.
Now that you've had some time to experiment with the concepts and tools, I want to show you some procedures and a script that you can use to interpret the output that those tools generated. This output will help you establish the permissions relationships between mailboxes, which will help you build and ultimately carry out your migration schedule.
Exchange Administrator Export
When you use Exchange Administrator to export Exchange 5.5 Directory Service
(DS) information, the tool generates output in five fields, as Figure
1 shows. The Obj-Class and Directory Name fields are a required part of
any export but aren't used in assessing permissions. The Obj-Dist-Name field,
which holds the mailbox's distinguished directory name, isn't useful in assessing
mailbox-to-mailbox relationships but is helpful in building lists of users that
you want to migrate together. To assess permissions, we use the Primary Windows
NT Account and Obj-Users fields.
The Primary Windows NT Account field lists the domain account for the mailbox's owner, or primary user. The Obj-Users field lists all domain accounts (including the Primary Windows NT Account and security groups) that have user access to the mailbox. For example, Figure 1 includes entries for conference-room resource mailboxes, including the room 4311 resource WO4311CONF (Row 6) and the room 4322 resource WO4322CONF (Row 7). The primary domain accounts for these entries have the same name as the mailbox's directory name (e.g., HQ\WO4311CONF). By looking at the Obj-Users fields, you can determine that the room 4311 resource is the only account associated with the room 4311 mailbox, but the HQ \MCCARYW domain account has the same level of access to the room 4322 resource as the primary account does. Two other things to note about the Obj-Users field are that the primary user isn't always listed first in the account list, and multiple accounts that have access are separated by a percent sign (%).
The Primary Windows NT Account and Obj-Users fields can also be blank or can contain ?\UNKNOWN. A blank field typically indicates a domain account that's been deleted; ?\UNKNOWN means that Exchange Administrator was unable to match the SID that it extracted from the Exchange directory with a domain account (typically because the account or domain no longer exists).
MBInfo Report
MBInfo details Exchange objects that have access to a mailbox. An MBInfo report
has six fields, as Figure 2 shows. For assessing
permissions, we're interested in the Mailbox Display Name and Folder Permissions
fields.
Unlike the Exchange Administrator export file, MBInfo puts information about each top-level folder in a mailbox object on a separate line. Figure 2 includes output for a conference-room resource that Figure 1 shows and for a user who has given other users access to his mailbox. The Folder Permissions field lists permissions for the corresponding object. This field can include references to Distribution Groups (DGs)—the ALLHANDS group in row 3—and in some cases to deleted mailboxes (as in row 18) in addition to existing mailboxes. To separate multiple sets of permissions, MBInfo simply surrounds each object-permissions pair with a set of apostrophes (').
The last thing to note about the MBInfo data is how the tool specifies permissions. MBInfo typically lists permissions as one of the nine roles (e.g., Reviews, Editor) listed in Web Table 1 (http://www.windowsitpro.com/microsoftexchangeoutlook, InstantDoc ID 49613). If a mailbox owner has granted custom permissions to another account, MBInfo lists those rights individually, as you can see in row 21 of Figure 2.
6 Degrees of Separation
Using the output from MBInfo and Exchange Administrator, you need to determine
how everyone is associated with everyone else through permissions. For example,
someone who has access to the room 4322 conference-room resource has a transitive
association with all other users of that conference room. All those users must
be migrated together so that they can continue to access the conference-room
calendar.
Determining who must be migrated together is a little like playing the game "Six Degrees of Kevin Bacon" (based on the six degrees of separation concept), in which you try to link an actor to Kevin Bacon through the other actors they've worked with. For example, Benjamin Bratt was in Red Planet with Carrie-Anne Moss, who was in The Matrix with Laurence Fishburne, who in turn appeared in Mystic River with Kevin Bacon. By transitive association, you can link Benjamin Bratt to Kevin Bacon in three steps, or degrees.
Let's say we're processing the MBInfo output that Figure 3 shows. To build transitive association groups, you match the mailboxes in an account's permissions list with the mailbox display names of other accounts. Each person is linked to others by the calendar access that he or she grants: Benjamin grants Carrie-Anne access to his calendar, Carrie-Anne gives Laurence access to her calendar, and Laurence grants Kevin access to his calendar. All these people must be migrated together. If you migrate only Benjamin and Carrie-Anne, Laurence can't access Carrie-Anne's new calendar. You can use a similar process to evaluate Exchange Administrator output by linking the domain accounts in the Primary Windows NT Account and Obj-Users columns.
Automation to the Rescue
Even in small organizations, determining the relationships between accounts
can be daunting. To automate the process, I've created the GBPR.vbs ("group
by permissions relationship") script. (To download this script, open the sidebar "Things to Know About GBPR.vbs" and click the .zip file link.) The script can be run on any machine that
has Windows Script Host (WSH) loaded. Copy the .csv export file or the MBInfo.txt
file to the same folder as GBPR.vbs. The script links the display name of an
individual mailbox (e.g., column A in Figure 3)
with the display name listed in the Folder Permissions column (e.g., column
F of Figure 3) to build a matrix of transitive
associations. A similar mapping operation happens if you're processing the .csv
export file. The command to run the script is
cscript gbpr.vbs mode infile.txt outfile.csv
where mode is either mbinfo or exadmin, depending on the file you're evaluating. Infile.txt is the name of the file that contains the permissions information. Outfile.csv is a script-generated comma-separated value (CSV) file that contains the headers Group, Index, Display Name, Directory Name, and Distinguished Name. Before running GBPR.vbs, be sure you export information for all mailboxes, not just those that grant permissions to others. Even mailboxes that don't themselves grant permissions, such as Kevin's mailbox in Figure 3, might have been given permissions to other mailboxes.
Figure 4 shows sample output after processing an MBInfo permissions file. The Group column contains a number—e.g., 0, 1, 2—that represents the association group to which the mailbox belongs. Mailboxes in group 0 aren't linked to any other group. A nonzero group number indicates that the account is a member of the specified group.
The Index column contains a unique index number that the script assigns to each mailbox in the input file; this information is included for debugging and output-verification purposes. When the script runs, it displays general status information on the screen to let you know that it's processing. If you change the DebugOn variable in the script's header from false to true, your screen displays additional information as GBPR.vbs runs. You can redirect this output to a text file and cross-reference it to the index value in the file to better understand how the script works.
The Display Name, Directory Name, and Distinguished Name columns contain the corresponding Exchange directory information. I often use the distinguished name (DN) in conjunction with LDAP-aware tools to build DGs or input files for use with migration tools.
I generated Figure 4 on a real-life Exchange site that contains more than 4400 mailboxes. The script identified 40 groups linked by permissions. Some groups contained only two or three members, and more than 1900 people had no associations. But one group linked 2531 people by association through a group of central conference rooms. The group numbers provide a starting point for determining how to group mailboxes for migration.
To set up our migration schedule, my team and I used GBPR.vbs's output to determine that we needed to migrate 36 groups. We determined that we could migrate about 200 mailboxes per day. Except for the one very large group, each group contained fewer than 200 members. Because some groups were very small, we sometimes combined groups to meet the 200-mailboxes-per-day target.
As we fine-tuned the migration process to meet our target, we added some of the 1900 non-associated mailboxes to other groups. This didn't affect users' ability to access other mailboxes.
The tricky problem was migrating the large group, which contained more mailboxes than we could migrate in one day. We waited until the end of the migration to process this group. Assuming that maintaining access to coworkers during the migration was more important than maintaining access to conference rooms, we split the group into subgroups along operating-division and business-unit lines and gave the Help desk access to resource mailboxes so that support staff could temporarily schedule those resources for people.
Sometimes GBPR.vbs. finds one association group that contains nearly every mailbox. The sidebar "Things to Know About GBPR.vbs" explains how to work around this problem and gives other considerations for using the script.
Ready, Set, Migrate
Migrating a large organization is never easy. The best project plans are flexible
and dynamic. To build a plan, you need to understand how your organization works.
By using the techniques and tools I describe here and in "Plan a Smooth Migration,"
you'll be well on your way to building logical migration schedules and ensuring
a good migration.
