Understanding Move Requests
Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2
When you move a mailbox, you're moving it from a source mailbox database to a target mailbox database. The target mailbox database can be on the same server, on a different server, in a different domain, in a different Active Directory site, or in another forest.
Note
This topic doesn't cover moving mailboxes to or from Microsoft Office Outlook Web App.
Contents
Cautions
Changes in Exchange 2010 SP1
Limitations to Moving Mailboxes in Previous Versions of Exchange
Advantages of Move Requests
Reasons for Moving Mailboxes
Supported Scenarios for Moving Mailboxes
Services Used in Move Requests
Basic Move Request Process
Remote Mailbox Moves
Mailbox Moves Using a Script
Soft-Deleted Mailboxes
Personal Archives
Shared Mailboxes and Resource Mailboxes
Mailbox Moves During Server Failures
Client Experience
Looking for management tasks related to move requests? See Managing Move Requests.
Cautions
When moving mailboxes, consider the following:
You can't use the Exchange System Manager or Active Directory Users and Computers to move mailboxes from Microsoft Exchange Server 2003 to Exchange Server 2010.
You can't use the Move-Mailbox cmdlet in Exchange Server 2007 to move mailboxes from Exchange 2007 to Exchange 2010.
When you move mailboxes, users won't be able to view their message tracking information.
Return to top
Changes in Exchange 2010 SP1
The following changes were made to move request functionality in Exchange 2010 Service Pack 1 (SP1):
Exchange 2010 SP1 now soft deletes the mailbox on the source database, so that you can recover the mailbox in the event of a Mailbox server failover or data loss. You can restore a soft-deleted mailbox by using the MailboxRestoreRequest cmdlet set. To learn more, see Soft-Deleted Mailboxes later in this topic.
Note
Soft-deleted mailboxes require that both the source Mailbox server and the Client Access server performing the request be running Exchange 2010 SP1.
The MoveRequest cmdlet set has been updated to support moving archives to a separate database.
Return to top
Limitations to Moving Mailboxes in Previous Versions of Exchange
Exchange 2007 uses the Move-Mailbox cmdlet to move mailboxes between mailbox databases. There are limitations to using this cmdlet:
Mailbox moves are offline. While you move a mailbox, which can take several hours, the user can't access the mailbox.
Moving mailboxes is synchronous. The cmdlet does the actual move, and you can't close the Exchange Management Shell session while the move is being performed.
The Dumpster folder isn't moved with the mailbox.
Content indexing doesn't begin until after the move is completed. This results in a poor search experience for users until the indexing is completed.
Move throttling is manually controlled by administrators.
Moving mailboxes across forests requires direct access to Active Directory and the mailbox database.
Return to top
Advantages of Move Requests
Move requests are a new feature in Exchange 2010. There are multiple advantages to using move requests:
Mailbox moves are asynchronous and are performed by the Microsoft Exchange Mailbox Replication service (MRS). To learn more, see Asynchronous Mailbox Moves later in this section.
Mailboxes are kept online during the asynchronous moves. To learn more, see Online Mailbox Moves later in this section.
The items in a mailbox's Recoverable Items folder are moved with the mailbox.
Note
The Recoverable Items folder is available only in Exchange 2010. To learn more, see Understanding Recoverable Items.
As soon as the mailbox move begins, content indexing starts to scan the mailbox so that fast searching is available upon completion of the move.
You can configure throttling for each MRS instance, each mailbox database, or each Mailbox server.
Remote mailbox moves work over the Internet by way of the Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service. You don't need to set up a direct back-end server and Active Directory access between the forests.
Mailbox moves can be managed from any Exchange 2010 server within the organization.
Mailbox content doesn't move through an administrative computer. For example, in Exchange 2007, when you run the Move-Mailbox cmdlet, the data move is managed by the computer on which you run the cmdlet. You can't shut down that session of Exchange until the move completes.
The mailbox's move history is maintained in the mailbox.
Asynchronous Mailbox Moves
Using the move request cmdlets in Exchange 2010, you can perform an asynchronous move because the cmdlets don't perform the actual move. The move is performed by MRS, a service that runs on all Client Access servers in your Exchange 2010 organization. Using MRS is beneficial because you can manage mailbox moves from any Exchange 2010 server within your organization after the move request is started. For more information, see Microsoft Exchange Mailbox Replication Service later in this topic.
Online Mailbox Moves
In an online mailbox move, end users can still access their e-mail accounts during the move. The user is only locked out of the account for a brief time at the end of the process (when the final synchronization occurs). Online mailbox moves are supported between Exchange 2010 databases and between Exchange 2007 SP3 and Exchange 2010 databases. You can perform online mailbox moves across forests or in the same forest. The process for local mailbox moves and remote mailbox moves is different from online moves and is discussed later in this topic.
Return to top
Reasons for Moving Mailboxes
You may need to move mailboxes in the following scenarios:
Transition When you transition an existing Exchange 2007 or Exchange Server 2003 organization to Exchange 2010, you move mailboxes from the existing Exchange servers to an Exchange 2010 Mailbox server.
Realignment You can move mailboxes for realignment purposes. For example, you may want to move a mailbox from one database to a database that has a larger mailbox size limit.
Investigating an issue If you need to investigate an issue with a mailbox, you can move that mailbox to a different server. For example, you can move all mailboxes that have high activity to another server.
Corrupted mailboxes If you encounter corrupted mailboxes, you can move the mailboxes to a different server or database. The corrupted messages won't be moved.
Physical location changes You can move mailboxes to a server in a different Active Directory site. For example, if a user moves to a different physical location, you can move that user's mailbox to a server closer to the new location.
Separation of administrative roles You may want to separate Exchange administration from Windows operating system account administration. To do this, you can move mailboxes from a single forest into a resource forest scenario. In this scenario, the Exchange mailboxes reside in one forest and their associated Windows user accounts reside in a separate forest.
Outsourcing e-mail administration You may want to outsource the administration of e-mail and retain the administration of Windows user accounts. To do this, you can move mailboxes from a single forest into a resource forest scenario.
Integrating e-mail and user account administration You may want to change from a separated or outsourced e-mail administration model to a model in which e-mail and user accounts can be managed from within the same forest. To do this, you can move mailboxes from a resource forest scenario to a single forest. In this scenario, the Exchange mailboxes and Windows user accounts reside in the same forest.
Return to top
Supported Scenarios for Moving Mailboxes
The following table lists the supported scenarios for moving Exchange mailboxes and includes links to related topics.
Supported scenarios for moving mailboxes
| Moving from | Moving to | Supported | Online move supported | Related topic |
|---|---|---|---|---|
Exchange 2010 |
Exchange 2010 |
Yes |
Yes |
|
Exchange 2007 SP3 |
Exchange 2010 |
Yes |
Yes |
Move Mailboxes from Exchange 2007 Servers to Exchange 2010 Servers |
Exchange 2007 SP1 |
Exchange 2010 |
No |
No |
Move Mailboxes from Exchange 2007 Servers to Exchange 2010 Servers |
Exchange 2003 SP2 |
Exchange 2010 |
Yes |
No |
Move Mailboxes from Exchange 2003 Servers to Exchange 2010 Servers |
Exchange 2010 |
Exchange 2007 SP3 |
Yes |
No |
Move Mailboxes from Exchange 2010 Servers to Exchange 2007 Servers |
Exchange 2010 |
Exchange 2003 SP2 |
Yes |
No |
Move Mailboxes from Exchange 2010 Servers to Exchange 2003 Servers |
Exchange 2000 |
Exchange 2010 |
No |
No |
Not applicable |
Exchange 2010 |
Exchange 2000 |
No |
No |
Not applicable |
Return to top
Services Used in Move Requests
Move requests are processed by two services:
Microsoft Exchange Mailbox Replication service (MRS)
Microsoft Exchange Mailbox Replication Proxy (MRSProxy) service
Microsoft Exchange Mailbox Replication Service
When you use the move request cmdlets to move mailboxes, MRS processes the move process. As stated earlier, MRS resides on an Exchange 2010 Client Access server and is the service that moves mailboxes from the source database to the target database. In Exchange 2007, the mailbox move is performed by the Move-Mailbox cmdlet. By using a service as the agent of the move, mailboxes can be moved while simultaneously remaining accessible to users. During the move, you can view, cancel, and manage the move request from any Exchange 2010 server in your organization.
You can start and stop MRS as you would any service. MRS constantly checks for all move requests in its own Active Directory site. In addition, there's a sharing mechanism between all instances of MRS so that no two servers will attempt to perform the same move request.
All MRS instances in an Active Directory site work together so that database and Client Access server throttling is handled across all instances of MRS. MRS throttling is controlled by a configuration file. For more information about how to modify the configuration file, see Throttling the Mailbox Replication Service.
Microsoft Exchange Mailbox Replication Proxy Service
In addition to MRS, the MRSProxy service is installed on every Exchange 2010 Client Access server. MRSProxy helps to facilitate cross-forest move requests and runs on the remote forest's Exchange 2010 Client Access server. However, MRSProxy is disabled by default. You need to turn on the MRSProxy service on the remote forest. We recommend that you enable MRSProxy on all Client Access servers in the remote forest.
For more information, see Start the MRSProxy Service on a Remote Client Access Server.
Return to top
Basic Move Request Process
The following figure illustrates the basic process for local move requests.
Basic local move request process
.gif "Local Mailbox Move Dataflow")
In this scenario, Ayla's mailbox will be moved from the source database DB01 on Mailbox server MBX02 to the target database DB02 on Mailbox server MBX01. To do this, you run the following command.
New-MoveRequest -Identity Ayla@contoso.com -TargetDatabase "DB02"
The following steps describe the basic process for local move requests:
The command updates Active Directory, and then places a special message in the system mailbox within that Active Directory site that a move request has been initiated and is set to a status of Queued. Information about the move request is stored in two places: the target database's system mailbox and in Active Directory. If the move is an offline move, the mailbox is locked and can't be accessed until the move reaches a status of Completed.
All instances of MRS periodically check the system mailbox on every database in its Active Directory site to verify if there are any queued move requests. In this example, the MRS instance on CAS01 finds Ayla's mailbox in the Queued status.
Note
The New-MoveRequest cmdlet selects an instance of MRS and requests that the service process the move request immediately. If the selected instance of MRS is available, it starts the move immediately. If not, the mailbox remains in the Queued status until an MRS instance finds the move request.
MRS begins to move the data from DB01 to DB02. MRS updates the mailbox's status in the system mailbox to In Progress.
When the move is almost finished, Ayla's mailbox is locked for a short time while the final mailbox synchronization is completed. At this point, the move request status changes to Completion In Progress.
When the move is complete, Ayla's new mailbox on DB02 is activated, and the old mailbox on DB01 is soft deleted. The move request status changes to Completed. Depending on Ayla's e-mail client, she may need to log off and log on again to access her mailbox. For more information, see Client Experience later in this topic.
The administrator clears the move request information from Active Directory and on the system mailbox on DB02. Until the move request information is cleared, you can't move the mailbox again. For details about how to clear a move request, see Clear or Remove Move Requests.
A record of the move is kept in Ayla's mailbox and can be accessed by running the Get-MailboxStatistics cmdlet with the IncludeMoveReport parameter. For more information, see View Move Request Properties.
Return to top
Remote Mailbox Moves
Remote mailbox moves are also known as cross-forest mailbox moves. Exchange 2010 supports two types of remote mailbox moves:
Remote mailbox moves that have Exchange 2010 in both forests In this scenario, one forest is an Exchange 2010 forest, and the other forest has at least one Exchange 2010 Client Access server. You can use the Exchange Management Console (EMC) or the Exchange Management Shell to perform these mailbox moves. For details, see Create a Remote Move Request That has Exchange 2010 in Both Forests.
Remote mailbox moves with a legacy Exchange forest In this scenario, one forest contains Exchange 2010, and the other forest contains Exchange 2003 SP2, Exchange 2007 SP3, or a combination of both. No Exchange 2010 Client Access server is installed in the legacy forest. You can't use the EMC to perform these mailbox moves. You must use the Shell. For details, see Create a Remote Legacy Move Request Where One of the Forests Doesn't Have Exchange 2010.
Prerequisites for Moving Mailboxes Across Forests
The prerequisites for moving mailboxes across forests are extensive. For details, see Prepare Mailboxes for Cross-Forest Move Requests.
Using the TargetDatabase or the RemoteTargetDatabase Parameters
The New-MoveRequest cmdlet uses the TargetDatabase and the RemoteTargetDatabase parameters to identify the target database to which you're moving mailboxes.
TargetDatabase Parameter
The TargetDatabase parameter specifies the identity of the database to which you're moving the mailbox. Use this parameter to perform local and remote mailbox moves when initiating the move from the target forest. When you initiate the move from the source forest, MRS pulls the mailbox from the source forest to the target forest.
Note
Using the TargetDatabase parameter is optional. If you don't specify this parameter, its usage is implied, and the mailbox provisioning load balancer specifies a target database. If you don't want the load balancer to select a database, either use the TargetDatabase parameter or specify the databases you want to exclude from provisioning by setting the IsExcludedFromProvisioning parameter to $true in the Set-MailboxDatabase cmdlet.
RemoteTargetDatabase Parameter
The RemoteTargetDatabase parameter specifies the identity of the target database in the remote forest. Use this parameter for remote mailbox moves only when you need to initiate the move from the source forest. For example, if you're moving a mailbox from an Exchange 2010 server to an Exchange 2007 or Exchange 2003 server, you initiate the move from the Exchange 2010 forest, which is the source forest. When you initiate a move from the source forest, MRS pushes the mailbox from the Exchange 2010 server to the Exchange 2007 or Exchange 2003 server.
This example pushes Tony Smith's mailbox to the remote forest.
New-MoveRequest -Identity 'tony@humongousinsurance.com' -RemoteLegacy -RemoteTargetDatabase DB03 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'
Remote Mailbox Moves with Exchange 2010 in Both Forests
The following describes a remote mailbox move scenario:
One forest is an Exchange 2010 forest and the other forest has at least one Exchange 2010 Client Access server.
MRS and MRSProxy exist on all Exchange 2010 Client Access servers. MRS processes the cross-forest moves.
The Fourth Coffee and Contoso forests both contain Exchange 2010 Client Access servers, but only Contoso contains Exchange 2010 Mailbox servers. Fourth Coffee contains only Exchange 2007 SP3 Mailbox servers.
Fourth Coffee contains the mailbox for tony@fourthcoffee.com. Contoso contains a mail-enabled user for tony@fourthcoffee.com that has all the prerequisite settings configured.
The following command is run from the target forest, Contoso.com.
New-MoveRequest -Identity 'tony@fourthcoffee.com' -TargetDatabase DBa -RemoteHostName 'CAS01.fourthcofee.com' -RemoteCredential (Get-Credential Atlanta\Administrator) -TargetDeliveryDomain 'mail.contoso.com'
Note
If Tony's mailbox were being moved from an Exchange 2003 server, the move would be offline, and Tony wouldn't be able to access his mailbox until the move was complete.
The following figure illustrates this remote mailbox move scenario.
Remote mailbox move
.gif "Remote mailbox move dataflow")
The New-MoveRequest cmdlet prompts MRS on the Client Access server in the Contoso forest. The cmdlet updates the Contoso Active Directory information and the system mailbox on the target database. At this point, the move request status is Queued.
To initiate the move, MRS in the Contoso forest communicates through MRSProxy in the Fourth Coffee forest. MRSProxy then updates the Fourth Coffee Active Directory information and the system mailbox on the remote database. At this point, the status changes to In Progress.
The MRS server in the Contoso forest pulls Tony's mailbox data from the Mailbox server through the MRSProxy server in Fourth Coffee to the mail-enabled user tony@fourthcoffee.com. At this point, the status is In Progress.
When the mailbox move is almost complete, MRSProxy locks Tony's mailbox at Fourth Coffee for a short time while final synchronization is completed. At this point, the status is Completion In Progress.
In the Contoso forest, MRS converts the mail-enabled user tony@fourthcoffee.com to the mailbox tony@contoso.com. In the Fourth Coffee forest, MRSProxy converts the mailbox tony@fourthcoffee.com to the mail-enabled user tony@contoso.com, and the mailbox is soft deleted. At this point, the status is Completed. Tony can now access his mailbox in the Contoso forest. Depending on Tony's e-mail client, he may need to log off and log on again to access his mailbox. For more information, see Client Experience later in this topic.
The administrator clears the move request information from Active Directory and from the system mailbox. Until the move request information is cleared, you can't move the mailbox again. For details about how to clear a move request, see Clear or Remove Move Requests.
A record of the move is kept in Tony's mailbox and can be accessed by running the Get-MailboxStatistics cmdlet with the IncludeMoveReport parameter.
Note
If you want to move the mailbox back to the remote forest, you must initiate the move in the Contoso forest. This is because the Contoso Mailbox server is running the latest version of Exchange (in this case, Exchange 2010). In addition, you must use the RemoteTargetDatabase parameter when you run the New-MoveRequest cmdlet.
Remote Legacy Mailbox Moves
If you're moving mailboxes remotely to or from Exchange 2007 or Exchange 2003 organizations, and those organizations don't contain an Exchange 2010 Client Access server, MRS in the Exchange 2010 forest will directly access the remote legacy database and the remote organization's Active Directory server. When performing a remote legacy move request, you must supply the following information in the command:
Identity of the mail-enabled user
RemoteLegacy switch
Fully qualified domain name (FQDN) of the remote global catalog server
FQDN of the external e-mail address created in the source forest for the mail-enabled user when the move request is complete
Target database when moving mailboxes to Exchange 2010 or the remote target database when moving mailboxes from Exchange 2010 to the remote legacy database
The following describes a remote legacy mailbox move scenario:
The legacy forest (Humongous Insurance) doesn't contain an Exchange 2010 Client Access server. This scenario is similar to the remote move request process. However, because the remote legacy forest doesn't have an instance of MRSProxy to connect with, MRS in the Contoso forest connects directly to the Humongous Insurance Active Directory server and system mailbox on the Exchange 2003 mailbox database.
When you move Exchange 2003 mailboxes to Exchange 2010, the mailbox move will be offline. During the move, the users won't be able to access their mailboxes. When you move Exchange 2007 SP3 to Exchange 2010 mailboxes, the move will be online, and the users can access their mailboxes during the move.
The following command is run from the target forest, Contoso.com.
New-MoveRequest -Identity 'tony@humongousinsurance.com' -RemoteLegacy -TargetDatabase DB02 -RemoteGlobalCatalog 'GC01.humongousinsurance.com' -RemoteCredential $Cred -TargetDeliveryDomain 'mail.contoso.com'
The following figure illustrates this remote legacy mailbox move scenario.
Remote legacy mailbox move
.gif "Remote Legacy Mailbox Move Data Flow")
Return to top
Mailbox Moves Using a Script
The MoveMailbox.ps1 script in Exchange 2010 provides a synchronous mailbox move management experience similar to the Exchange 2007 Move-Mailbox cmdlet. By default, scripts are installed at C:\Program Files\Microsoft\Exchange Server\V14\Scripts. For more information, see Move Mailboxes by Using the MoveMailbox.ps1 Script in the Shell.
Note
You can use this script for local moves only. You can't use this script for cross-forest moves.
MoveMailbox.ps1 performs the following tasks:
Creates a local move request.
Waits for the mailbox move to complete.
Removes the move request after it's complete.
Return to top
Soft-Deleted Mailboxes
When mailboxes are moved from an Exchange 2010 SP1 database to any other database, Exchange doesn't fully delete the mailbox from the source database immediately upon completion of the move. Instead, the mailbox in the source mailbox database is switched to a soft-deleted state. Mailbox data can be accessed during a mailbox restore operation using the MailboxRestoreRequest cmdlet set. The soft-deleted mailboxes are retained in the source database until either the deleted mailbox retention period expires or you use the Remove-StoreMailbox cmdlet to purge the mailbox.
Note
Soft-deleted mailboxes require that both the source Mailbox server and the Client Access server performing the request be running Exchange 2010 SP1.
To view soft-deleted mailboxes, run the Get-MailboxStatistics cmdlet against a database and look for results that have a DisconnectReason property with a value of SoftDeleted.
Personal Archives
In the release to manufacturing (RTM) version of Exchange 2010, if a personal archive exists for a mailbox that you want to move, the archive gets moved with the primary mailbox. This is because the personal archive and the primary mailbox must reside on the same mailbox database. Before moving mailboxes that have a personal archive, you should consider the size of the archive. Consider database size and how that size might impact the time the move will take to complete.
In Exchange 2010 SP1, personal archives and mailboxes can exist on separate databases. The move request cmdlets and the move request user interface (UI) in the EMC support moving mailboxes and personal archives together or separately. By default, the primary mailbox and the archive are moved together. For more information about moving an archive and primary mailbox separately, see Create a Local Move Request.
If you're moving mailboxes from an Exchange 2010 server to an Exchange 2007 or Exchange 2003 server, you must first disable the personal archive before you can move the mailbox. For details, see Disable a Personal (On-Premises) or Cloud-Based Archive for a Mailbox.
To learn more about personal archives, see Understanding Personal Archives.
Return to top
Shared Mailboxes and Resource Mailboxes
In addition to the default user mailboxes, you can move shared mailboxes and resource mailboxes. A shared mailbox is a mailbox to which multiple users can log on. A resource mailbox is a mailbox that represents a type of resource, such as a conference room or video equipment. Resource mailboxes have additional properties in Active Directory that user mailboxes and shared mailboxes don't have, such as capacity.
Exchange 2003 doesn't support resource mailboxes. Instead, you must use shared mailboxes to represent resources. If you move a shared mailbox from Exchange 2003 to Exchange 2010, MRS creates the mailbox as a shared Exchange 2010 mailbox. After you move the mailbox to Exchange 2010, you can convert it to a resource mailbox. For details about how to convert a shared mailbox to a resource mailbox, see Convert a Mailbox.
Return to top
Mailbox Moves During Server Failures
Move requests can handle transient errors. MRS conducts checkpoints every 5 minutes to make sure that the database to which the mailbox being moved is still operational. If MRS finds that the target database isn't operational, MRS will pause for 30 seconds, and then retry the move. If you experience a failover, the move won't fail. Instead, MRS will detect a database failover, determine the new location of the database, and then restart the move process.
Another error that could occur is if the Client Access server on which MRS is running stops responding. If this happens, the move stops, and one of the other MRS instances will continue the process and complete the move.
For more information, see Troubleshooting Mailbox Moves.
Return to top
Client Experience
The following table lists the different experiences end users will have, based on the version of Exchange that their mailbox is being moved to and from, and based on which client application they're using when the move request begins.
Client experience based on Exchange version and client application
| Moving from | Moving to | Client application being used when the move starts | End-user experience |
|---|---|---|---|
Exchange 2010 or Exchange 2007 SP2 |
Exchange 2010 |
Microsoft Outlook 2010, Office Outlook 2007, or Office Outlook 2003 |
When the move request has a status of Completion in Progress, the mailbox will be locked for a short time. When the move is complete, Outlook displays a message notifying the user to close and restart Outlook. |
Exchange 2010 |
Exchange 2010 |
Outlook Web App |
When the move request has a status of Completion in Progress, the mailbox is locked for a short time. If users are logged on to Outlook Web App when the mailbox is locked, or if they attempt to log on while the mailbox is locked, they will receive an error stating that the mailbox is being moved, and they won't be able to log on until the move is complete. If users aren't logged on at the time, they won't be aware of the move unless the URL that they use to access Outlook Web App changed. If the URL changed, users receive a message similar to the following: "Use the following link to open this mailbox with the best performance: https://mail.contoso.com/owa" When users click the link, they are directed to the new location and can log on using their credentials. |
Exchange 2007 SP3 |
Exchange 2010 |
Microsoft Outlook Web Access |
When the move request has a status of Completion in Progress, the mailbox is locked for a short time. If users are logged on to Outlook Web Access when the mailbox is locked, they are automatically logged off and need to log on again to view their mailbox. If users aren't logged on at the time, they won't be aware of the move unless the URL that they use to access Outlook Web Access changed. If it changed, users receive a message similar to the following: "Use the following link to open this mailbox with the best performance: https://mail.contoso.com/owa" When users click the link, they are directed to the new location and can log on using their credentials. |
Exchange 2010 or Exchange 2007 SP3 |
Exchange 2010 |
Outlook Mobile Access |
When the move request has a status of Completion in Progress, the mailbox is locked for a short time. Users experience an interruption only if the Outlook Web App URL that they use has changed. If the URL has changed, users must modify the URL in their phone's e-mail settings. |
Exchange 2010 or Exchange 2007 SP3 |
Exchange 2010 |
Third-party client application |
When the move request has a status of Completion in Progress, the mailbox is locked for a short time. If users are using a third-party client application (such as Eudora), check with the manufacturer to determine whether users need to log off and then log on again after the move request is complete. |
Exchange 2003 SP2 or SP3 |
Exchange 2010 |
Outlook 2003 and Outlook Web Access |
This is an offline move, and users can't access their mailbox during the move request process. However, users can use Outlook to access mail archived locally. User can't use Outlook Web Access during this time. When the move is complete, Outlook displays a message notifying users to close and restart Outlook. |
Exchange 2003 SP2 |
Exchange 2010 |
Outlook Mobile Access |
When the move request has a status of Completion in Progress, the mailbox is locked for a short time. Users experience an interruption only if the Outlook Web Access URL that they use has changed. If the URL has changed, users must modify the URL in their phone's e-mail settings. |
Exchange 2010 |
Exchange 2007 SP3 |
Outlook 2007 and Outlook Web Access |
This is an offline move, and users can't access their mailbox during the move request process. However, users can use Outlook to access mail archived locally. Users can't use Outlook Web Access during this time. When the move is complete, Outlook displays a message notifying users to close and restart Outlook. |
Exchange 2010 |
Exchange 2003 SP2 |
Outlook 2003 and Outlook Web Access |
This is an offline move, and users can't access their mailbox during the move request process. However, users can use Outlook to access mail archived locally. Users can't use Outlook Web Access during this time. When the move is complete, Outlook displays a message notifying users to close and restart Outlook. |
Return to top
© 2010 Microsoft Corporation. All rights reserved.