This article provides additional information and appropriate changes when performing a mailbox migration from an M365 Tenant regarding the scoping.
The procedures shown here are the differences in the normal permission assignment and can be used in conjunction with the M365 Mailbox and Archive Migration Permissions, found here.
Some migrations may require only allowing rights to the migration process for a particular set of users. In such cases, use the following procedure that outlines how this can be achieved. To do so, please replace Step Two of those instructions with the ones detailed below.
Replacement Step Two - Changes in API Permissions
In Step Two you must add the additional Application Permissions to the App Registration. In this case, the permission of full_access_as_app should NOT be checked.
When this permission is selected, it will override any of the management scopes and simply provide access to all mailboxes in the organization. So, remove this permission if you had previously included it in your application registration.
Run the Management Scope Details Manually
To assign a management scope only for a particular set of mailboxes, all the commands that make up this assignment need to be run manually.
Decide on the type of filter that you want to apply to the management scope. These can be anything that is used as a 'filter' for normal Get-Mailbox cmdlets.
In this example, the scope is that of a particular Custom Attribute that is a value. You can use the following PowerShell to test this filter after the Custom Attribute is set. get-mailbox -filter "CustomAttribute13 -like 'MigWiz'"
This will produce the following type of result.
In this case, The management scope will be restricted to just two accounts in the source tenant.
To assign the management scope to the tenant perform these next steps
- Connect to the M365 Tenant with the following PowerShell command, using your Admin credentials.
connect-exchangeonline - Run these PowerShell commands, replacing the items in bold with the details from your Enterprise Application.
$applicationId = "ApplicationID from the Enterprise Application"
$objectId ="ObjectID from the Enterprise Application"
$MgmtScopeName="User Mailboxes"
New-ManagementScope -Name $MgmtScopeName -RecipientRestrictionFilter "CustomAttribute13 -eq 'MigWiz'"
New-ServicePrincipal -AppId $applicationId -ObjectId $objectid -DisplayName "MigrationWiz"
New-ManagementRoleAssignment -App $objectId -Role "Application EWS.AccessAsApp" -CustomResourceScope $MgmtScopeName - Check that the management scope is in place by using this command.
Get-ManagementScopeThe results will have a similar output to this.
In the example above, only two mailboxes have been configured to fix this scope. With a project configured and then run inside MigrationWiz, you should expect that only two accounts are migrated and any other source accounts added subsequently fail.
As a result, when you try to perform a migration with MigrationWiz, the behavior shown in the image below is correct in this scenario.
Updating the Management Scope
To update the management scope, you must remove the previous one and re-apply it to the tenant. To do this, follow the next steps:
- Remove the Management Role Assignment.
get-managementroleassignment -Identity "Application EWS.AccessAsApp*" -RoleAssigneeType ServicePrincipal | remove-managementroleassignment - Remove the Service Principal.
remove-serviceprincipal -identity "MigrationWiz" - Remove the Management Scope itself.
remove-managementscope -identity "User Mailboxes"
Afterward, you can rerun the commands from the sections above to recreate the Management Scope with the updated filter.