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.