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:
- In Exchange Administrator, you can use an object's Permissions tab to grant user-level access. These permissions can be set for any Exchange object.
- In Outlook, you can use the Permissions tab on a folder's Properties page (which Figure 1 shows) to assign custom levels of access or to select a predefined role to apply common permission sets.
- In Outlook, you specify delegates by selecting Tools, Options, then going to the Delegates Tab. After you add a mailbox, the Delegate Permissions interface, which Figure 2 shows, lets you specify the rights and functions the delegate can perform.
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.