Exchange Server Move Mailboxes Guided Walkthrough Version 1.0

Exchange Server Move Mailboxes Guided Walkthrough Version 1.0
Pascal L’Huriec Senior Premier Field Engineer With a big thanks to François Vallet (PFE) for the Hybrid setup Exchange 2007 Exchange 2010 Exchange 2013

What do you want to do ? Move mailboxes within your organization => Here Move mailboxes cross-forest (ie between 2 organizations) => Here Move mailboxes to Office 365 (aka onboarding) => Here Move mailboxes from Office 365 (aka offboarding) => Here All tested with Exchange 2007 SP3 RU12 – Exchange 2010 SP3 RU4 – Exchange 2013 SP1 (aka CU4) – Office 365 Tenant Wave 15.

Move mailboxes within your organization – Generalities 1/2
Home Usually quite obvious as it occurs in the same organization, with the same directory Same AD forest : so permissions (Full Access, SendAs) are not changed Delegations (permissions on folders in the mailboxes) and SendOnBehalf are also preserved Inbox Rules are preserved Outlook profiles updated automatically, via Autodiscover feature OST file is not resynchronized (i.e. no full download of the mailbox) Usually we move from lower to higher version (we pull the mailbox on the target) But it’s possible to downgrade (we then push the mailbox from the source) Next

Move mailboxes within your organization – Generalities 2/2
Home When using the 2010 or 2013 tools, if a Move Request is already associated with the mailbox to move, that Move Request has to be deleted prior to the move. If the Move Request to delete has been initiated by Exchange 2013, it has to be deleted from Exchange But if the Move Request was initiated by Exchange 2010 you can delete it from 2010 or 2013. Also with the 2013 tools, if the mailbox to move is already associated to a Migration Batch in Exchange 2013 you need to delete that Migration Batch prior to the move. Exchange 2007 is using dumpster 1.0 (Recover Deleted Items) and Exchange 2010/2013 are using dumpster 2.0. Only dumpster 2.0 is preserved when moving a mailbox ‘from and to’ dumpster 2.0 => Choose your scenario => Here Back

Move mailboxes within your organization
Home From Exchange 2007 to Exchange 2010 => Here From Exchange 2007 to Exchange 2013 => Here From Exchange 2010 to Exchange 2013 => Here From Exchange 2010 to Exchange 2007 => Here From Exchange 2013 to Exchange 2007 => Here From Exchange 2013 to Exchange 2010 => Here

From Exchange 2007 to Exchange 2010 – 1/1
Home Use the EMC (Exchange Management Console) on 2010 server in order to pull the mailbox (select the ‘New Local Move Request’, local, as the move will occur locally in the forest) Or use the EMS (Exchange Management Shell) on 2010 : New-MoveRequest –Identity –TargetDatabase "DB10" Move occurs online Dumpster (Recover Deleted Items) is lost We can’t push the mailbox from the 2007 server

From Exchange 2007 to Exchange 2013 - 1/2
Home Use the EAC (Exchange Admin Center) on 2013 in order to pull the mailbox with the Migration wizard. Create a new migration batch choosing ‘Move to a different database’ and choose an Exchange 2013 database as the target Next

Home Or use the EMS (Exchange Management Shell) on 2013 : New-MoveRequest –Identity –TargetDatabase "DB13" Or the ‘New-MigrationBatch’ command especially for massive moves Dumpster (Recover Deleted Items) is lost Move occurs online We can’t push the mailbox from the 2007 server, neither use the 2010 tools if any 2010 server in the organization. Back

Home Similar to a move from Exchange 2007 Use the EAC (Exchange Admin Center) on 2013 in order to pull the mailbox with the Migration wizard. Create a new migration batch choosing ‘Move to a different database’ and choose an Exchange 2013 database as the target Next

Home Or use the EMS (Exchange Management Shell) on 2013 : New-MoveRequest –Identity –TargetDatabase "DB13" Or the ‘New-MigrationBatch’ command especially for massive moves Dumpster (Recover Deleted Items) is preserved as both of these versions of Exchange are using Dumpster 2.0 Litigation Hold and Single Item Recovery settings are also preserved during such a move Move occurs online We can’t push the mailbox from the 2010 server Next Back

Home If the source mailbox has an archive associated, you can move it to different database. But in a full on-premise environment the primary and archive mailbox must reside on same version (i.e. both on 2010 or both on 2013) Back

Home Before moving the mailbox: - If Archive mailbox has been associated, you need to disable it (mandatory) - If Litigation Hold was enabled, it has to be disabled (mandatory) - If Single Item Recovery was enabled, it has to be disabled (not mandatory but recommended) - Clear the dumpster (Recover Deleted Items). It can’t be preserved (not mandatory but reco) Use the EMC (Exchange Management Console) on 2010 server in order to push the mailbox (select the ‘New Local Move Request’, local, as the move will occur locally in the forest) Or use the EMS (Exchange Management Shell) on 2010 : New-MoveRequest –Identity –TargetDatabase "DB07" We can’t pull the mailbox in that scenario. Move is offline.

Home Before moving the mailbox: - If Archive mailbox has been associated, you need to disable it (mandatory) - If Litigation Hold was enabled, it has to be disabled (mandatory) - If the mailbox was placed on In-Place Hold, it has to be disabled (mandatory) - If Single Item Recovery was enabled, it has to be disabled (not mandatory but recommended) - Clear the dumpster (Recover Deleted Items). It can’t be preserved (not mandatory but reco) Use the EAC (Exchange Admin Center) on 2013 in order to push the mailbox with the Migration wizard. Create a new migration batch choosing ‘Move to a different database’ and choose an Exchange 2007 database as the target Next

Home Or use the EMS (Exchange Management Shell) on 2013 : New-MoveRequest –Identity –TargetDatabase "DB07" Or the ‘New-MigrationBatch’ command especially for massive moves Outlook prompt for the following when accessing to the rules: If you select ‘Server’ the rules might be empty, then Cancel. And back on that prompt select ‘Client’, check you rules, and then confirm with ‘Apply’. Move occurs offline We can’t pull the mailbox in that scenario Back

Home Before moving the mailbox: - If the mailbox was placed on In-Place Hold, it has to be disabled (mandatory) Use the EAC (Exchange Admin Center) on 2013 in order to push the mailbox with the Migration wizard. Create a new migration batch choosing ‘Move to a different database’ and choose an Exchange 2010 database as the target Next

Home Or use the EMS (Exchange Management Shell) on 2013 : New-MoveRequest –Identity –TargetDatabase "DB10" Or the ‘New-MigrationBatch’ command especially for massive moves The dumpster (Recover Deleted Items) is preserved Inbox rules are also preserved with no prompt Move occurs offline We can’t pull the mailbox in that scenario Back

Move mailboxes cross-organization – Generalities 1/3
Home More tricky as we don’t share the same directory Scenario depends on the directory requirements: Usually we move also the account with SID History => Results might be different if you don’t move the account or move without SID History => Also moving directly to a linked mailbox is not always possible Is a directory replication (eg FIM) in place ? => Accounts change to contacts and vice-versa Does the primary SMTP address change or not ? => Autodiscover may rely on it in multiple forest deployment Next

Home Do you move also the computer account ? What about the Windows profile ? => It contains the Outlook profile => As long as we preserve the MailboxGUID we can maintain the OST Usually we move from lower to higher version (we pull the mailbox on the target) But it’s possible to downgrade (we then push the mailbox from the source) When moving across forest to the same version, both push and pull are possible. In all scenarios covered here, a trust relationship between both forests was in place. Back Next

Home Behavior of SendAs, Delegation, and Full Access permissions is not always exactly the same. Most of the time you will have to prepare all the target objects prior to proceed with any mailbox move, otherwise you will loose permissions on folders/delegations and SendAs. Depending on your environment you might notice that some different behavior with permissions, especially for the SendAs permission. On my lab each time the permissions have been maintained, they were operational. From a supportability point of view, cross forest delegation is not supported. To avoid any issue, and as a best practice: migrate Delegate and Delegating mailboxes together, export the permissions before moving mailboxes, and test on your lab first. => Choose your scenario => Here Back

Move mailboxes cross-organization
Home From Exchange 2007 to Exchange 2007 => Here From Exchange 2007 to Exchange 2010 => Here From Exchange 2007 to Exchange 2013 => Here From Exchange 2010 to Exchange 2010 => Here From Exchange 2010 to Exchange 2013 => Here From Exchange 2013 to Exchange 2013 => Here From Exchange 2013 to Exchange 2010 => Here From Exchange 2010 to Exchange 2007 => Here

Home We can push the mailbox running the following cmdlet on the source: $tcred=get-credential (enter the admin credential in the target forest) Mov box –TargetDatabase "Server\StorageGroup\MailboxDatabase" –Identity jsmith –GlobalCatalog DC1.fabrikam.com –TargetForestCredential $tcred –NTAccountOU "OU=MyOU,DC=fabrikam,DC=com" We can pull the mailbox running the following cmdlet on the target: $scred=get-credential (enter the admin credential in the source forest) Mov box –TargetDatabase "Server\StorageGroup\MailboxDatabase" –Identity jsmith –SourceForestGlobalCatalog DC1.contoso.com -SourceForestCredential $scred –NTAccountOU "OU=MyOU,DC=fabrikam,DC=com" (in these exemples Contoso is the source and Fabrikam is the target forest) Next

Home If you migrated the account with the SID History prior to the mailbox migration, the mov box will find that account as a matched user, and will assign the mailbox to that user. If there is no matching user in the target, the mov box will create a disabled account, and will result in a linked mailbox associated to the account in the original forest. If a contact exists in the target forest, the mov box will remove it at the end of the move. Back Next

Home Inbox rules are preserved Delegations (permissions on folders in the mailboxes) and SendOnBehalf are also preserved, but they will work only if both delegate and delegating are migrated in the same organization Until the remote object is not migrated locally you will see such things on permissions: (here the user Move6 has not been migrated yet) Back Next

Home Permissions (Full Access, SendAs) are also moved to the target forest: If the account or security group having the Full Access or SendAs has been migrated to the target forest (with SID History) prior to moving the mailbox, the mov box will grant the same permissions to the target object. If there is no matching account or security group in the target forest, the Full Access and SendAs are preserved for the source forest account or group, on the target mailbox. In that case if you move the account or security group later (with SID History) the Full Access and SendAs permissions will be given to that target account/group, instead of the source. Back Next

Home Only with Powershell, ie not with the GUI RPC connectivity is required between Mailbox servers source and target It’s an Offline move. But we basically copy the source mailbox to the target organization by default, not exactly a move. It’s possible to delete the source mailbox and/or account or create a contact in the source with the swtich –Sourc boxCleanupOptions. The MailboxGUID is preserved accross forest Dumpster (Recover Deleted Items) is lost X500 address matching the source LegacyExchangeDN is added Back

Home This is a Remote Legacy Move You need to prepare carefully the object in the target forest prior to the move If there is no matching object in the target forest the move can’t occur. Moreover the target object has some requirements: It must be a Mail Enabled User The msExchMailboxGUID attribute must match the source mailbox’s GUID Easy way to do it: Move the account with SID History Create a new MEU from that account Copy/synchronize the msExchMailboxGUID attributes Next

Home You need to push the mailbox running the following cmdlet on the source: $tcred=get-credential (enter the admin credential in the target forest) New-MoveRequest –Identity UserA –RemoteLegacy –RemoteTargetDatabase "Mailbox Database" –RemoteGlobalCatalog "DC1.fabrikam.com" –RemoteCredential $tcred –TargetDeliveryDomain "fabrikam.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. X500 address matching the source LegacyExchangeDN is added on that MEU. Push only, ie it is not possible to pull in that scenario. Only with powershell cmdlet, not possible with the EMC. Back Next

Home By default the source primary SMTP address is set on the target mailbox, still as a primary address. Before moving the mailbox: - If Archive mailbox has been associated, you need to disable it (mandatory) - If Litigation Hold was enabled, it has to be disabled (mandatory) - If Single Item Recovery was enabled, it has to be disabled (not mandatory but recommended) - Clear the dumpster (Recover Deleted Items). It can’t be preserved (not mandatory but reco) - Remove any Move Request associated with the user to move Offline or Online move doesn’t apply here, as the source mailbox is disconnected Back Next

Home Inbox rules are preserved Delegations (permissions on folders in the mailboxes) and SendOnBehalf are also preserved, but they will work only if both delegate and delegating are migrated in the same organization Until the remote object is not migrated locally you will see such things on permissions: (here the user Move6 has not been migrated yet) Back Next

Home Full Access permissions are also moved to the target forest: If the account or security group having the Full Access has been migrated to the target forest prior to moving the mailbox, the move mailbox will grant the same permissions to the target account or group. If there is no matching account or security group in the target forest, the Full Access are preserved for the source forest account or group, on the target mailbox. In that case, if you move the account or security group later (with SID History) the Full Access permissions will be given to that target account/group, instead of the source object. Back Next

Home SendAs permissions are moved to the target forest only if the mailbox having the SendAs permission has a matching object in the target forest. If there is no matching object, the SendAs permission is not maintained for the source mailbox, and NOT granted later, in case you will move the mailbox having the SendAs permisison. Also, SendAs granted to security groups are not preserved in that scenario, regardless if the group has been migrated prior to moving the mailbox or not. Back Next

Home In that scenario you can’t move directly to a linked mailbox. If you want to, you need to move to a regular user mailbox first and then convert it to a linked mailbox after the move. If you have Exchange 2007 servers in the source organization you can’t use that technique (New-MoveRequest) to move a mailbox which is located on an Exchange 2007 server. RPC Connectivity is required between the CAS 2010 performing the move request and the MBX 2007 server hosting the target mailbox. Back Next

Home Takeaway: You have to prepare the MEU in the target forest with the attribute msExchMailboxGUID matching the source Full Access are preserved as long as you move the object with SID History SendAs granted to security groups are not preserved. SendAs granted to account are preserved only if that account has a matching object in the target forest when the move occurs. If the account having the SendAs is migrate after the mailbox move, the permission is lost. To work around that, prepare all the target objects prior to moving any mailbox. Permissions on folders and SendOnBehalf are preserved. Dumpster not preserved. Back

Home This is also a Remote Legacy Move Prior to the move you need to prepare the target object. The best practice to do that, is to use the script ‘Prepare-MoveRequest.ps1’ shipped with Exchange 2010. If there is no matching object in the target forest the move can’t occur. This script will prepare a MEU (Mail Enabled User), it will copy the required attributes, especially the msExchMailboxGUID from the source mailbox’s GUID. It will set a X500 address on the source mailbox and also on the target MEU matching the LegacyExchangeDN of the remote object. In the following example we are moving a mailbox from Fabrikam to Contoso: $scred=get-credential (enter the admin credential in the source forest Fabrikam) $tcred=get-credential (enter the admin credential in the target forest Contoso) Next

Home Prepare-MoveRequest.ps1 –Identity –RemoteForestDomainController DC1.fabrikam.com –RemoteForestCredential $scred –LocalForestDomainController DC3.contoso.com –LocalForestCredential $tcred –TargetMailUserOU "OU=MyOU,DC=contoso,dc=com" If you already have a directory synchronization tool in place between both forests, with existing contacts, check the switch UseLocalObject with that scrcipt. By default the AddressPolicy will apply on the target object, then setting the primary SMTP address. You can change that behavior with the switch Disable AddressPolicy If the script will fail to find a matching object in the target forest (e.g. a SendOnBehalf recipient not yet migrated) it will warn about the failure to populate the corresponding attribute (publicDelegates in that example). Back Next

Home Once the MEU is created you use a tool such as ADMT to migrate the SID History to that object in order to preserve security. And then proceed with the move mailbox using the following command in the target forest: New-MoveRequest –Identity –RemoteLegacy –TargetDatabase MDB –RemoteGlobalCatalog "DC1.fabrikam.com" –RemoteCredential $scred –TargetDeliveryDomain "contoso.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. We pull the mailbox. We can’t push. Only with powershell cmdlet, not possible with the EMC RPC Connectivity is required between the CAS 2010 performing the move request and the MBX 2007 server hosting the source mailbox. Back Next

Home Inbox rules are preserved Dumpster is not preserved Delegations (permissions on folders in the mailboxes and SendOnBehalf) are also preserved, but they will work only if both delegate and delegating are migrated in the same organization SendOnBehalf: if the script Prepare-MoveRequest.ps1 will fail to populate the publicDelegates, permissions are anyway kept as ‘Not Found’ object on the folders, and resolved when object will be migrated. And then publicDelegates gets populated. (here the user Alex4 has been migrated, but not Alex8) Back Next

Home On the folders, if the remote object is not migrated locally you will see such things on permissions: (here the user Alex6 has not been migrated) When the user (Alex6 here) will be migrated later with the SID History, it will be resolved, and the permission available for that user. Back Next

Home SendAs permissions are moved to the target forest only if the mailbox having the SendAs permission has a matching object in the target forest. If there is no matching object, the SendAs permission is not maintained for the source mailbox, and NOT granted later, in case you will move the mailbox having the SendAs permisison. Also, SendAs granted to security groups are not preserved in that scenario, regardless if the group has been migrated prior to moving the mailbox or not. Back Next

Home Takeaway: Use the script ‘Prepare-MoveRequest.ps1’ to prepare the target object Full Access are preserved as long as you move the object with SID History SendAs granted to security groups are not preserved. SendAs granted to account are preserved only if that account has a matching object in the target forest when the move occurs. If the account having the SendAs is migrate after the mailbox move, the permission is lost. To work around that, migrate all accounts with SID History prior to moving any mailbox. Permissions on folders and SendOnBehalf are preserved. Back

Home Similar to moving from 2007 to It’s also a Remote Legacy Move. Prior to the move you need to prepare the target object. The best practice to do that, is to use the script ‘Prepare-MoveRequest.ps1’ shipped with Exchange 2013. If there is no matching object in the target forest the move can’t occur. This script will prepare a MEU (Mail Enabled User), it will copy the required attributes, especially the msExchMailboxGUID from the source mailbox’s GUID. It will set a X500 address on the source mailbox and also on the target MEU matching the LegacyExchangeDN of the remote object. In the following example we are moving a mailbox from Fabrikam to Contoso: $scred=get-credential (enter the admin credential in the source forest Fabrikam) $tcred=get-credential (enter the admin credential in the target forest Contoso) Next

Home Prepare-MoveRequest.ps1 –Identity –RemoteForestDomainController DC1.fabrikam.com –RemoteForestCredential $scred –LocalForestDomainController DC3.contoso.com –LocalForestCredential $tcred –TargetMailUserOU "OU=MyOU,DC=contoso,dc=com" If you already have a directory synchronization tool in place between both forests, with existing contacts, check the switch UseLocalObject with that scrcipt. By default the AddressPolicy will apply on the target object, then setting the primary SMTP address. You can change that behavior with the switch Disable AddressPolicy If the script will fail to find a matching object in the target forest (e.g. a SendOnBehalf recipient not yet migrated) it will warn about the failure to populate the corresponding attribute (publicDelegates in that example). Back Next

Home Once the MEU is created you use a tool such as ADMT to migrate the SID History to that object in order to preserve security. And then proceed with the move mailbox using the following command in the target forest: New-MoveRequest –Identity –RemoteLegacy –TargetDatabase MDB –RemoteGlobalCatalog "DC1.fabrikam.com" –RemoteCredential $scred –TargetDeliveryDomain "contoso.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. We pull the mailbox. We can’t push. Only with powershell cmdlet "New-MoveRequest"; not possible with the EAC, neither with the MigrationBatch. Back Next

Home Delegations (permissions on folders) are migrated only if there is a matching object in the target forest (the MEU with SID History is enough, the mailbox itself doesn’t need to be migrated). On the folders, if the remote object is not migrated locally you will see unresolved SID on permissions: When the user associated to that unresolved SID will be migrate later with the SID History, it will be NOT be resolved. The best workaround is to prepare all target objects before moving any mailbox. Back Next

Home SendOnBehalf are preserved. Even if the mailbox having the SendOnBehalf is migrated after the mailbox granting the SendOnBehalf, that permission is maintained. If the script Prepare-MoveRequest.ps1 will fail to populate the publicDelegates, that attribute gets anyway populated later when the object will be migrate. Inbox rules are preserved. Dumpster is not preserved as we are moving from dumpster 1.0 to 2.0 Back Next

Home Full Access permissions are also moved to the target forest: If the account or security group having the Full Access has been migrated to the target forest prior to moving the mailbox, the move mailbox will grant the same permissions to the target account or group. If there is no matching account or security group in the target forest, the Full Access are not maintained for the source forest account or group, on the target mailbox. But later when you will move the account/group (with SID History) who had the Full Access permissions, that permission will be given to that target account/group. Back Next

Home SendAs permissions are moved to the target forest only if the mailbox having the SendAs permission has a matching object in the target forest. If there is no matching object, the SendAs permission is not maintained for the source mailbox, and NOT granted later, in case you will move the mailbox having the SendAs permisison. The best workaround is to prepare all target objects before moving any mailbox. Also, SendAs granted to security groups are not preserved in that scenario, regardless if the group has been migrated prior to moving the mailbox or not. Back Next

Home Takeaway: Use the script ‘Prepare-MoveRequest.ps1’ to prepare all the target objects and merge the accounts with SID History to the MEU, prior to move any mailbox. With that, permissions on folders/delegations are preserved. SendAs granted to accounts also (otherwise they will be lost). But SendAs granted to security groups are not preserved anyway. Full Access and SendOnBehalf are preserved. Dumpster is lost in that scenario. Move mailbox can be done only with New-MoveRequest powershell command. Back

Home Prior to the move you need to prepare the target object. The best practice to do that, is to use the script ‘Prepare-MoveRequest.ps1’ shipped with Exchange 2010. If there is no matching object in the target forest the move can’t occur. This script will prepare a MEU (Mail Enabled User), it will copy the required attributes, especially the msExchMailboxGUID from the source mailbox’s GUID. It will set a X500 address on the source mailbox and also on the target MEU matching the LegacyExchangeDN of the remote object. In the following example we are moving a mailbox from Testdomain to Contoso: $scred=get-credential (enter the admin credential in the source forest Testdomain) $tcred=get-credential (enter the admin credential in the target forest Contoso) Next

Home Prepare-MoveRequest.ps1 –Identity –RemoteForestDomainController DC1.testdomain.com –RemoteForestCredential $scred –LocalForestDomainController DC3.contoso.com –LocalForestCredential $tcred –TargetMailUserOU "OU=MyOU,DC=contoso,dc=com" If you already have a directory synchronization tool in place between both forests, with existing contacts, check the switch UseLocalObject with that scrcipt. By default the AddressPolicy will apply on the target object, then setting the primary SMTP address. You can change that behavior with the switch Disable AddressPolicy If the script will fail to find a matching object in the target forest (e.g. a SendOnBehalf recipient not yet migrated) it will warn about the failure to populate the corresponding attribute (publicDelegates in that example). Back Next

Home Once the MEU is created you use a tool such as ADMT to migrate the SID History to that object in order to preserve security. And then proceed with the move mailbox. This mailbox move occurs with MRSProxy feature that you need to enable on both the source and target CAS servers: Set-WebServicesVirtualDirectory -Identity “Server\EWS (Default Web Site)" -MRSProxyEnabled $true You can use the EMC to perform the move. You then need to add the remote Exchange forest to your local EMC: A trust between both forests is mandatory to add the remote forest in the local EMC. Also valid certificates are required in both sides to establish SSL channel for the move request to occur. Back Next

Home When the remote forest is added to the EMC you can initiate the remote move request: Here from the EMC on the target CAS I’m browsing the remote forest (the source), to the mailbox to move, and select "New Remote Move Request". The target is the local forest. We are pulling the mailbox locally, from the target forest. Back Next

Home But you can do it from the source CAS: The target is the remote forest. The local forest is the source. It looks like a push mailbox, but the Move Request occurs anyway in the target forest. Back Next

Home To move the mailbox with powershell the commands are: - When running in the target forest: New-MoveRequest –Identity –Remote –TargetDatabase MDB1 –RemoteHostName "e2k10-A.testdomain.com" –RemoteCredential $scred –TargetDeliveryDomain "contoso.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. When running in the source forest: New-MoveRequest –Identity –Outbound –RemoteTargetDatabase MDB1 –RemoteHostName "EX10-CH.contoso.com" –RemoteCredential $tcred –TargetDeliveryDomain "contoso.com" Please note that I’m moving from Testdomain to Contoso. This really a push mailbox. The move request occurs on the source CAS (Testdomain). You can’t achieve this similar behavior with the EMC. Back Next

Home If there is an Archive mailbox associated with the Primary mailbox: - You must move both Primary and Archive together. - You can’t move only the Primary. - You can’t move only the Archive even if the EMC offers it. If you try to move only the Archive, you will be prompted for the following at the next step: You can do it with powershell, same commands as previously. By default Primary and Archive mailboxes will be on the same target database. You can specify a different database for the Archive mailbox with the switch -ArchiveTargetDatabase Back Next

Home If a Move Request is already associated with the mailbox to move, that Move Request has to be delete prior to the move. If Litigation Hold and/or Single Item Recovery are enabled on the source mailbox, these settings are preserved during the move mailbox. Dumpster is preserved, as we are moving from a Dumpster 2.0 to 2.0 Inbox rules are also preserved. Back Next

Home Delegations (permissions on folders) are migrated only if there is a matching object in the target forest (the MEU with SID History is enough, the mailbox itself doesn’t need to be migrated). On the folders, if the remote object is not migrated locally you will see: When the user associated to that account (here Andy6) will be migrate later with the SID History, it will be NOT be resolved. The best workaround is to prepare all target objects before moving any mailbox. Back Next

Home SendOnBehalf are preserved. Even if the mailbox having the SendOnBehalf is migrated after the mailbox granting the SendOnBehalf, that permission is maintained. If the script Prepare-MoveRequest.ps1 will fail to populate the publicDelegates, that attribute gets anyway populated later when the object will be migrate. Back Next

Home Takeaway: Use the script ‘Prepare-MoveRequest.ps1’ to prepare all the target objects and merge the accounts with SID History to the MEU, prior to move any mailbox. With that, permissions on folders/delegations are preserved. SendAs granted to accounts also (otherwise they will be lost). But SendAs granted to security groups are lost anyway. Full Access and SendOnBehalf are preserved. Move Primary and Archive mailboxes together Dumpster preserved. Back

Home Prior to the move you need to prepare the target object. The best practice to do that, is to use the script ‘Prepare-MoveRequest.ps1’ shipped with Exchange 2013. If there is no matching object in the target forest the move can’t occur. This script will prepare a MEU (Mail Enabled User), it will copy the required attributes, especially the msExchMailboxGUID from the source mailbox’s GUID. It will set a X500 address on the source mailbox and also on the target MEU matching the LegacyExchangeDN of the remote object. In the following example we are moving a mailbox from Contoso to Testdomain: $scred=get-credential (enter the admin credential in the source forest Contoso) $tcred=get-credential (enter the admin credential in the target forest Testdomain) Next

Home Prepare-MoveRequest.ps1 –Identity –RemoteForestDomainController DC3.contoso.com –RemoteForestCredential $scred –LocalForestDomainController DC1.testdomain.com –LocalForestCredential $tcred –TargetMailUserOU "OU=MyOU,DC=testdomain,dc=com" If you already have a directory synchronization tool in place between both forests, with existing contacts, check the switch UseLocalObject with that scrcipt. By default the AddressPolicy will apply on the target object, then setting the primary SMTP address. You can change that behavior with the switch Disable AddressPolicy If the script will fail to find a matching object in the target forest (e.g. a SendOnBehalf recipient not yet migrated) it will warn about the failure to populate the corresponding attribute (publicDelegates in that example). Back Next

Home Once the MEU is created you use a tool such as ADMT to migrate the SID History to that object in order to preserve security. And then proceed with the move mailbox. This mailbox move occurs with MRSProxy feature that you need to enable on both the source and target CAS servers: Set-WebServicesVirtualDirectory -Identity “Server\EWS (Default Web Site)" -MRSProxyEnabled $true On the Exchange 2013 side you can enable MRS Proxy in the EAC: (against the CAS role if you have seperated roles) Back Next

Home To move the mailbox you can use the migration wizard in the EAC: Select "Move to this forest" Select the users to move or a CSV file for massive move If there is no existing migration endpoint you will be prompted for remote credentials and MRSProxy server, and Exchange 2013 will create the migration endpoint. Back Next

Home You can’t use the EMC to perform the move on the source forest. It’s not possible to add the remote Exchange forest to your local EMC if the target forest is made only of Exchange 2013 If your target forest has also Exchange 2010 servers (in addition to the 2013 servers) you can add the remote forest to the EMC in the source forest, but anyway it’s not possible to push to an Exchange 2013 database. It’s not a supported target database version for the EMC 2010. Back Next

Home To move the mailbox with powershell the command to run in the target forest is: New-MoveRequest –Identity –Remote –TargetDatabase MDB2013 –RemoteHostName "ex10-ch.contoso.com" –RemoteCredential $scred –TargetDeliveryDomain "testdomain.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. Or with the ‘New-MigrationBatch’ command, especially for massive moves. It’s not possible to Push the mailbox from the 2010 source to the 2013 target, neither with powershell. In other words we can only Pull the mailbox in that scenario (using EAC or PowerShell) Back Next

Home If there is an Archive mailbox associated with the Primary mailbox: (regardless of EAC or PowerShell) - You must move both Primary and Archive together. - You can’t move only the Primary. - You can’t move only the Archive. You can run the move with PowerShell, same commands as previously. By default Primary and Archive mailboxes will be on the same target database. You can specify a different database for the Archive mailbox with the switch -TargetArchiveDatabases Back Next

Home If the mailbox to move is already included in a Migration Batch local to the forest where the Batch is running, you need to remove that Migration Batch. Otherwise the move will not occur. If Litigation Hold and/or Single Item Recovery are enabled on the source mailbox, these settings are preserved during the move mailbox. Dumpster is preserved, as we are moving from a Dumpster 2.0 to 2.0 Inbox rules are also preserved. Back Next

Home Delegations (permissions on folders) are migrated only if there is a matching object in the target forest (the MEU with SID History is enough, the mailbox itself doesn’t need to be migrated). On the folders, if the remote object is not migrated locally you will see unresolved SID on permissions: When the user associated to that unresolved SID will be migrate later with the SID History, it will be NOT be resolved. The best workaround is to prepare all target objects before moving any mailbox. Back Next

Home SendOnBehalf are preserved. Even if the mailbox having the SendOnBehalf is migrated after the mailbox granting the SendOnBehalf, that permission is maintained. If the script Prepare-MoveRequest.ps1 will fail to populate the publicDelegates, that attribute gets anyway populated later when the object will be migrate. Back Next

Home Takeaway: Use the script ‘Prepare-MoveRequest.ps1’ to prepare all the target objects and merge the accounts with SID History to the MEU, prior to move any mailbox. With that, permissions on folders/delegations are preserved. SendAs granted to accounts also. Otherwise they will be lost. But SendAs granted to security groups are lost anyway. Full Access are preserved. SendOnBehalf are preserved. Move Primary and Archive mailboxes together. Dumpster preserved. Back

Home Once the MEU is created you use a tool such as ADMT to migrate the SID History to that object in order to preserve security. And then proceed with the move mailbox. This mailbox move occurs with MRSProxy feature that you need to enable on both the source and target CAS servers: Set-WebServicesVirtualDirectory -Identity “Server\EWS (Default Web Site)" -MRSProxyEnabled $true On the Exchange 2013 side you can enable MRS Proxy in the EAC: (against the CAS role if you have seperated roles) Back Next

Home To move the mailbox in such a scenario: You can’t use the EAC on the source forest to push the mailbox You can’t use the EMC on the target forest to pull the mailbox You can’t use the PowerShell on the target forest to pull to the mailbox You can only use the PowerShell on the source forest to push the mailbox The command: New-MoveRequest –Identity –Outbound –RemoteTargetDatabase MDB1 –RemoteHostName "EX10-CH.contoso.com" –RemoteCredential $tcred –TargetDeliveryDomain "contoso.com" Please note that I’m moving from Testdomain to Contoso. This really a push mailbox. The move request occurs on the source CAS (Testdomain). You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. Back Next

Home You can also use the ‘New-MigrationBatch’ command, especially for massive moves. Prior to create your migration batch you need to create a migration end point. For a target running with Exchange 2010 the migration end point can be: New-MigrationEndpoint –Name EP-Contoso2010 –ExchangeRemoteMove –RemoteServer ex10-ch1.contoso.com –Credentials $tcred Create the CSV file including the mailboxes to move (c:\Migration\ToEx2010.csv in my exemple). Create the migration batch that will use the migration end point and the CSV file: New-MigrationBatch –Name BatchToContoso2010 –TargetEndPoint EP-Contoso2010 –TargetDeliveryDomain contoso.com –TargetDatabases MDB1 –CSVData ([System.IO.File]::ReadAllBytes("c:\migration\ToEx2010.csv")) Start the migration batch: Start-MigrationBatch –Identity BatchToContoso2010 For the migration batch completion, you can add the -AutoComplete parameter to the ‘New-MigrationBatch’ command or use ‘Complete-MigrationBatch’ when it has reached the ‘Synced’ status. Back Next

Home Prior to the move: - If a Move-Request is already associated with the mailbox to move, it has to be deleted. - If the mailbox was placed on In-Place Hold, it has to be disabled. If Single Item Recovery is enabled, it is preserved during the move mailbox. If there is an Archive mailbox associated with the Primary mailbox: - You must move both Primary and Archive together. - You can’t move only the Primary, neither only the Archive. By default Primary and Archive mailboxes will be place on the same target database. You can’t specify a different database for the Archive mailbox with the New-MoveRequest command. You can specify a different database for the Archive mailbox only with the New-MigrationBatch command. The parameter to add is -TargetArchiveDatabases Back Next

Home Dumpster is preserved, as we are moving from a Dumpster 2.0 to 2.0 Inbox rules are also preserved. SendOnBehalf are preserved. Even if the mailbox having the SendOnBehalf is migrated after the mailbox granting the SendOnBehalf, that permission is maintained. If the script Prepare-MoveRequest.ps1 will fail to populate the publicDelegates, that attribute gets anyway populated later when the object will be migrate. Back Next

Home Delegations (permissions on folders in the mailboxes) are preserved, but they will work only if both delegate and delegating are migrated in the same organization On the folders, if the remote object is not migrated locally you will see such things on permissions: (here the user Bob6 has not been migrated) When the user (Bob6 here) will be migrated later with the SID History, it will be resolved, and the permission available for that user. Back Next

Home Takeaway: Use the script ‘Prepare-MoveRequest.ps1’ to prepare the target object Full Access are preserved as long as you move the object with SID History SendAs granted to security groups are not preserved. SendAs granted to account are preserved only if that account has a matching object in the target forest when the move occurs. If the account having the SendAs is migrate after the mailbox move, the permission is lost. To work around that, migrate all accounts with SID History prior to moving any mailbox. Permissions on folders and SendOnBehalf are preserved. Move Primary and Archive mailboxes together. Dumpster preserved. Back

Home Once the MEU is created you use a tool such as ADMT to migrate the SID History to that object in order to preserve security. And then proceed with the move mailbox. This mailbox move occurs with MRSProxy feature that you need to enable on both the source and target servers: Set-WebServicesVirtualDirectory -Identity “Server\EWS (Default Web Site)" -MRSProxyEnabled $true On the Exchange 2013 side you can enable MRS Proxy in the EAC: (against the CAS role if you have seperated roles) Back Next

Home You need a Migration End Point to perform such a move mailbox. If you don’t create the Migration End Point before moving the mailbox, the Migration Wizard will create one for you. But you can create it manually with the ‘New-MigrationEndPoint’ cmdlet especially if you need a specific type. In a cross-forest move the ExchangeRemoteMove type is suitable: New-MigrationEndPoint –Name EPLab –ExchangeRemoteMove –RemoteServer E2K13-all.testdomain.com –Credentials $scred For that, the certificate must be setup and trusted on all servers (i.e. not only the CAS but also the MBX servers) Use the Test-MigrationServerAvailability cmdlet to help in checking your setup. Back Next

Home To move the mailbox you can use the migration wizard in the EAC in the target forest in order to Pull the mailbox (you can’t Push the mailbox with the EAC): Select "Move to this forest" Select the users to move or a CSV file for massive move Back Next

Home You can also use PowerShell in the target forest, still to Pull the mailbox: New-MigrationBatch –Name Batch5 –SourceEndPoint EPLab –TargetDatabases MDB1 –TargetDeliveryDomain "contoso.com" -CSVData ([System.IO.File]::ReadAllBytes("C:\Data\CrossForestBatch5.csv")) And start the batch: Start-MigrationBatch –Identity Batch5 For the migration batch completion, you can add the -AutoComplete parameter to the ‘New-MigrationBatch’ command or use ‘Complete-MigrationBatch’ when it has reached the ‘Synced’ status. The ‘New-MigrationBatch’ cmdlet is interesting especially for massive moves, but you can still use the legacy move request: New-MoveRequest –Identity –Remote –TargetDatabase MDB1 –RemoteHostName "e2k13-all.testdomain.com" –RemoteCredential $scred –TargetDeliveryDomain "contoso.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. The Migration Batch and associated move requests occur in the target organization Back Next

Home If you want to Push the mailbox from the source organization: First, create the Migration End Point in the source, with the ExchangeRemoteMove type: New-MigrationEndPoint –Name EPLabSource –ExchangeRemoteMove –RemoteServer CAS1.contoso.com –Credentials $tcred And use the following cmdlet: New-MigrationBatch –Name Batch6 –TargetEndPoint EPLabSource –TargetDatabases MDB1 –TargetDeliveryDomain "contoso.com" -CSVData ([System.IO.File]::ReadAllBytes("C:\Data\CrossForestBatch6.csv")) And start the batch: Start-MigrationBatch –Identity Batch5 For the migration batch completion, you can add the -AutoComplete parameter to the ‘New-MigrationBatch’ command or use ‘Complete-MigrationBatch’ when it has reached the ‘Synced’ status. You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. The Migration Batch and associated move requests occur in the source organization Back Next

Home To sum-up: We can only Pull the mailbox using the EAC We can Push or Pull the mailbox using PowerShell If the mailbox to move is already included in a Migration Batch local to the forest where the Batch is running, you need to remove that Migration Batch. Otherwise the move will not occur. This is not an issue if the mailbox to move is already included in a Migration Batch in the remote forest. Back Next

Home If there is an Archive mailbox associated with the Primary mailbox: (regardless of EAC or PowerShell) - You must move both Primary and Archive together. - You can’t move only the Primary. - You can’t move only the Archive. You can run the move with PowerShell, same commands as previously. By default Primary and Archive mailboxes will be on the same target database. You can specify a different database for the Archive mailbox with the switch -TargetArchiveDatabases Back Next

Home If Litigation Hold and/or Single Item Recovery are enabled on the source mailbox, these settings are preserved during the move mailbox. Dumpster is preserved, as we are moving from a Dumpster 2.0 to 2.0 Inbox rules are also preserved. SendOnBehalf are preserved. Even if the mailbox having the SendOnBehalf is migrated after the mailbox granting the SendOnBehalf, that permission is maintained. If the script Prepare-MoveRequest.ps1 will fail to populate the publicDelegates, that attribute gets anyway populated later when the object will be migrate. Back Next

Home Delegations (permissions on folders) are migrated only if there is a matching object in the target forest . On the folders, if the remote object is not migrated locally you will see unresolved SID on permissions: When the user associated to that unresolved SID will be migrate later with the SID History, it will be NOT be resolved. The best workaround is to prepare all target objects before moving any mailbox. Back Next

Home Takeaway: Use the script ‘Prepare-MoveRequest.ps1’ to prepare all the target objects and merge the accounts with SID History to the MEU, prior to move any mailbox. With that, permissions on folders/delegations are preserved. SendAs granted to accounts also. Otherwise they will be lost. But SendAs granted to security groups are lost anyway. Full Access are preserved. SendOnBehalf are preserved. Move Primary and Archive mailboxes together. Dumpster preserved. Back

Move mailboxes to Office365 – 1/14
Home This scenario covers the move mailbox to Office 365 using the hybrid mode (ie not the Cutover, Staged, IMAP migration) Assume that the Hybrid configuration is in-place and properly configured (RemoteDomain, AcceptedDomain, Address Policy, Web Services virtual directory …). Of course the move mailbox feature enabled. The Hybrid Configuration Wizard does most of these settings. We also assume that AutoDiscover is properly configured for the hybrid environment. The on-premises server(s) part of the Hybrid deployment are running Exchange 2013. It could be Exchange 2010 but for ease and best admin integration, we’ll use Exchange 2013. All these moves occur online (as long as the source server is Exchange 2007 SP2 or higher). Providing an almost uninterrupted access to mailbox while moving. Next

Home As DirSync is in-place, all on-premises mailboxes are replicated to the Office 365 tenant as MEU (Mail-Enabled User) DirSync does the full preparation of the target objects: - It set the TargetAddress on the MEU to the primary SMTP address of the source mailbox - It set the X500 address on the MEU matching the LegacyExchangeDN of the source mailbox - It set the msExchMailboxGUID on the MEU to the same as the source mailbox (ExchangeGUID) We don’t share the same directory, but offer similar experience. And thanks to that DirSync replication we already have the target object in Office 365 ready to welcome the mailbox. With the msExchMailboxGUID attribute and the Autodiscover, the Outlook profile is updated, and no need to resynchronize the OST (i.e. no full download of the mailbox) Back Next

Home This mailbox move occurs with MRSProxy feature. Make sure that it is enabled on servers part of the Hybrid deployment, and also the ExternalURL set. Set-WebServicesVirtualDirectory -Identity “Server\EWS (Default Web Site)" -MRSProxyEnabled $true On Exchange 2013 you can enable MRS Proxy in the EAC: RPC is used between the on-premises Exchange servers and the Hybrid server running the MRSProxy. And then HTTPS is used between the Hybrid server and the Office365 tenant. Back Next

Home To move the mailboxes you can use the migration wizard in the EAC in Office365: Select "Migrate to Exchange Online" Select "Remote move Migration" (for mailboxes on source servers running Exchange 2007/2010/2013) Back Next

Home Select the mailboxes you want to move, or specify a CSV file, especially for massive move: On that example above, there is one mailbox on Exchange 2007, one on Exchange 2010 and one on Exchange 2013. Back Next

Home If there is no existing migration endpoint with the type ExchangeRemoteMove you will be prompted for on-premises credentials and MRSProxy server. The wizard will then create the migration endpoint. If a migration endpoint (type ExchangeRemoteMove) is already available you won’t see this credential step This is the name specified on the ExternalURL for the EWS virtual directory on the hybrid server(s). Back Next

Home Give a name for your batch and select the TargetDeliveryDomain. If you used the Hybrid Configuration Wizard you have single TargetDeliveryDomain. The move will convert the on-premises mailbox to a MEU (Remot box), and will set the TargetDeliveryDomain on the TargetAddress of that object This is done for messages routing purposes. Back Next

Home Set a recipient to receive the batch report, and settings below: You can use the ‘Manual Complete the batch’ option and then Complete-MigrationBatch manually; or ‘Automatically complete the migration batch’ Back Next

Home You can check the progress with powershell command: If you create a migration batch which includes N mailboxes, that will create N move requests. Not a single move request. Back Next

Home Instead of the EAC, you can use the PowerShell to move the mailbox to Office365 with the MigrationBatch cmdlet: New-MigrationBatch -Name "Batch8-Onboarding" -SourceEndpoint "mail.pfelabs.fr" -CSVData ([System.IO.File]::ReadAllBytes("C:\Data\List8toMove.csv")) -TargetDeliveryDomain "lab01fr.mail.onmicrosoft.com" You must specify the TargetDeliveryDomain. The source mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. And start the batch: Start-MigrationBatch –Identity Batch8-Onboarding For the migration batch completion, you can add the -AutoComplete parameter to the ‘New-MigrationBatch’ command or use ‘Complete-MigrationBatch’ when it has reached the ‘Synced’ status. The ‘New-MigrationBatch’ cmdlet is interesting especially for massive moves, but you can still use the legacy move request for asynchronous move: New-MoveRequest -Identity -Remote -RemoteHostName "mail.pfelabs.fr" –RemoteCredential $scred -TargetDeliveryDomain "lab01fr.mail.onmicrosoft.com" Back Next

Home If there is an Archive mailbox associated with the Primary mailbox: (regardless of EAC or PowerShell) - You can move both Primary and Archive together. - You can move only the Archive. - You can’t move only the Primary. Primary mailbox on Office 365 with Archive on-premises is not a supported configuration. Primary mailbox on-premises (on Exchange 2010 or 2013) with Archive on Office 365 is a supported configuration. If you want to move only the Archive mailbox with the New-MigrationBatch or New-MoveRequest cmdlet, you need to add the switch –ArchiveOnly to the commands previously mentionned. Back Next

Home All of these moves are Pull. We are pulling the mailbox, the batch/request occurs on the Office365 tenant. It’s not possible to Push from the on-premises hybrid server. Inbox rules are preserved. Specifically if source mailboxes are on Exchange 2010 or 2013: - If Litigation Hold and/or Single Item Recovery are enabled on the source mailbox, these settings are preserved during the move mailbox. - If a move request is already associated to the source mailbox, it's not an issue to move the mailbox to Office365. - Dumpster is preserved, as we are moving from a Dumpster 2.0 to 2.0 (if source mailbox is on Exchange 2007 the Dumpster is not preserved) After the move completion, you need to assign a license to the mailbox. And best practise is to remove the completed migration batches. Back Next

Home Delegations (permissions on folders) are migrated. There is a matching object in the target environment (O365), so the permission is effective as soon as the object having the permission is also moved to O365. The recommended approach is to move together the delegate and the delegating mailboxes together. Cross-premises permissions (i.e. between both environment) is not supported. SendOnBehalf are preserved. Even if the mailbox having the SendOnBehalf is migrated after the mailbox granting the SendOnBehalf, that permission is maintain. Full Access permissions granted to mailbox and also to security group are move to O365, regardless of the order you move. Same conclusion for SendAs permissions granted to mailbox and also to security group : they are move to O365 with the mailbox. DirSync is a key factor in that process, because it allows to the move mailbox to find matching target objects. Back Next

Home Takeaway: It is critical to have a correct hybrid configuration (domains, policies, web services…) to succeed with the mailboxes onboarding. Use the Hybrid Configuration Wizard. DirSync allows to have target matching objects in O365 (TargetAddress ,ExchangeGUID, X500) which makes the moves very simple. AutoDiscover operational is also crucial. We pull the mailbox from the O365 tenant. All these moves occur online. Outlook profiles maintain. Delegations, SendOnBehalf, Full Access, SendAs are preserved. Regardless of the source servers version. Dumpster preserved (except if source is Exchange 2007) If you were using AutoMapping feature on-premises, this is not preserved when moving. Back

Move mailboxes from Office365 – 1/14
Home This scenario covers the move mailbox from Office 365 to Exchange 2013 or 2010 on-premises using the hybrid mode (ie not the Cutover, Staged, IMAP migration). Assume that the Hybrid configuration is in-place and properly configured (RemoteDomain, AcceptedDomain, Address Policy, Web Services virtual directory …). Of course the move mailbox feature enabled. The Hybrid Configuration Wizard does most of these settings. We also assume that AutoDiscover is properly configured for the hybrid environment. The on-premises server(s) part of the Hybrid deployment are running Exchange 2013. It could be Exchange 2010 but for ease and best admin integration, we’ll use Exchange 2013. All these moves occur online. Providing an almost uninterrupted access to mailbox while moving. The experience is the same for a target database running Exchange 2010 or 2013. Next

Home As DirSync is in-place, all on-premises mailboxes are replicated to the Office 365 tenant as MEU (Mail-Enabled User), but that is not a two-ways replication. If the mailbox to move from Office 365 to on-premises has been initially created on-premises and subsequently moved to Office 365, the contact in the on-premises Active Directory has already the appropriate attributes (especially the msExchMailboxGUID aka ExchangeGUID), and that object is ready to welcome the mailbox. But if the mailbox to move from O365 to on-premises has been directly created in O365 as an ‘’Office 365 mailbox’’ the attribute msExchMailboxGUID is not populated. You will need to synchronize that attribute back to the on-premises object, or manual copy / script to have it (Set-Remot box with –ExchangeGUID). It has to match the ExchangeGUID from the source. With the msExchMailboxGUID attribute and the Autodiscover, the Outlook profile is updated, and no need to resynchronize the OST (i.e. no full download of the mailbox) Back Next

Home This mailbox move occurs with MRSProxy feature. Make sure that it is enabled on servers part of the Hybrid deployment, and also the ExternalURL set. Set-WebServicesVirtualDirectory -Identity “Server\EWS (Default Web Site)" -MRSProxyEnabled $true On Exchange 2013 you can enable MRS Proxy in the EAC: HTTPS is used between the Office 365 Tenant and the Hybrid server. And then RPC is used between the Hybrid server running the MRS Proxy and the other on-premises Exchange servers. Back Next

Home To move the mailboxes you can use the migration wizard in the EAC in Office365: Select "Migrate from Exchange Online" Back Next

Home Select the mailboxes you want to move, or specify a CSV file, especially for massive move: Back Next

Home If you don’t have any Migration End Point already created (this might be the case if it is the first mailbox migration in any way) you should have an additionnal step prompting for an account / password with privileges. Check the FQDN of the MRS Proxy: This is the name specified on the ExternalURL for the EWS virtual directory on the hybrid server(s). Back Next

Home Give a name for your batch and specify the TargetDeliveryDomain. The MRS will convert the Office mailbox to a MEU, and will set the TargetDeliveryDomain on the TargetAddress of that object. This is done for messages routing purposes. The Target Database can be an Exchange or 2013 database. Back Next

Home Set a recipient to receive the batch report, and settings below: You can use the ‘Automatically start the batch’ option or Start-MigrationBatch manually when you want. Same for completion, you can use the ‘Manual Complete the batch’ option and then Complete-MigrationBatch manually (to control the moment that require the Outlook restart) or ‘Automatically complete the migration batch’. Back Next

Home You can check the progress with powershell command: If you create a migration batch which includes N mailboxes, that will create N move requests. Not a single move request. Back Next

Home Instead of the EAC, you can use the PowerShell to move the mailbox to on-premises with the MigrationBatch cmdlet: New-MigrationBatch -Name "Batch02-Offboarding" -TargetEndpoint "mail.pfelabs.fr" -TargetDeliveryDomain "pfelabs.fr" -TargetDatabases "MDB2013-A" -CSVData ([System.io.File]::ReadAllBytes("C:\Data\List1toOffboard.csv")) The TargetDatabase can be either 2010 either 2013. You must specify the TargetDeliveryDomain. The Office 365 mailbox is converted to a MEU after the move has completed, and that domain is used for the TargetAddress. And start the batch: Start-MigrationBatch –Identity Batch02-Offboarding For the migration batch completion, you can add the -AutoComplete parameter to the ‘New-MigrationBatch’ command or use ‘Complete-MigrationBatch’ when it has reached the ‘Synced’ status. The ‘New-MigrationBatch’ cmdlet is interesting especially for massive moves, but you can still use the legacy move request for asynchronous move: New-MoveRequest -Identity -Outbound -RemoteHostName "mail.pfelabs.fr" -RemoteTargetDatabase "MDB2013-A" -RemoteCredential $cred -TargetDeliveryDomain "pfelabs.fr" Back Next

Home If there is an Archive mailbox associated with the Primary mailbox: (regardless of EAC or PowerShell) - You can move both Primary and Archive together. - You can move only the Primary. - You can’t move only the Archive. Primary mailbox on Office 365 with Archive on-premises is not a supported configuration. Primary mailbox on-premises (on Exchange 2010 or 2013) with Archive on Office 365 is a supported configuration. If you want to move only the Primay mailbox with the New-MigrationBatch or New-MoveRequest cmdlet, you need to add the switch –PrimaryOnly to the commands previously mentionned. Back Next

Home These moves are in Push mode. We are pushing the mailboxes, the batch/request occurs in the Office365 tenant. It is not possible to Pull from the on-premises servers. Best practise is to remove the completed migration batches. Inbox rules are preserved. Dumpster is preserved, as we are moving from a Dumpster 2.0 to 2.0 If a move request is already associated with the mailbox to move in the Tenant, you need to clear that request prior to move the mailbox. If Litigation Hold and/or Single Item Recovery are enabled or disabled on the source mailbox, these settings are preserved during the offboarding. Back Next

Home Delegations (permissions on folders) are migrated. The permission is effective as soon as the object having the permission is also moved to on-premises. The recommended approach is to move together the delegate and the delegating mailboxes. Cross-premises permissions (i.e. between both environment) is not supported. SendOnBehalf are NOT preserved in that scenario. Full Access permissions granted to mailbox and also to security group are move to on-premises, regardless of the order you move. Same for SendAs permissions granted to mailbox and also to security group : they are move to on-premises with the mailbox. This is true if the object having the permissions (Full Access or SendAs) is present in the on-premises target Active Directory. As an example, if you grant Full Access or SendAs to a security group which is present only in the O365 tenant and not on-premises, when moving the mailbox to on-premises, the permission for that group is NOT preserved. Back Next

Home Takeaway: It is critical to have a correct hybrid configuration (domains, policies, web services…) to succeed with the mailboxes offboarding. Use the Hybrid Configuration Wizard. AutoDiscover operational is also crucial. If the mailbox to offboard has been initially created on-prem and subsequently moved to Office 365, the target object in the on-prem AD is ready. But if the mailbox has been initially created as an Office 365 mailbox, you need to set/copy/replicate the ExchangeGUID value to the MEU in your Active Directory. We push the mailbox from the O365 tenant. All these moves occur online. Outlook profiles maintain. Dumpster preserved. Delegations, Full Access, SendAs are preserved (even for security group, as long as it is present in the target on-premises Active Directory when moving the mailbox) SendOnBehalf is NOT preserved in that scenario. If you were relying on AutoMapping feature, this is not preserved when moving. Back

Exchange Server Move Mailboxes Guided Walkthrough Version 1.0

Similar presentations

Presentation on theme: "Exchange Server Move Mailboxes Guided Walkthrough Version 1.0"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Exchange Server Move Mailboxes Guided Walkthrough Version 1.0

Similar presentations

Presentation on theme: "Exchange Server Move Mailboxes Guided Walkthrough Version 1.0"— Presentation transcript:

Similar presentations

About project

Feedback