Most commonly the folowing cmdlets are being used during a migration:
Get-MailboxDatabase | Add-ADPermission -User "TARGET\QMMSRV" -AccessRights ExtendedRight -ExtendedRight Receive-As, ms-Exch-Store-Admin
Get-MailboxDatabase | Add-ADPermission -User "TARGET\QMMSRV" -AccessRights GenericAll
Add-ADPermission -Identity "CN=TARGET Org,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=TARGET,DC=LOCAL" -User "TARGET\QMMSRV" -AccessRights GenericAll -ExtendedRights Send-As,Receive-As
Add-ADPermission -Identity "DC=TARGET,DC=LOCAL"-User "TARGET\QMMSRV" -ExtendedRights Send-As -InheritedObjectType User -InheritanceType Descendents
Usually you don’t have to set any permissions directly on the mailboxes. They should be set on the databases, and then in turn get inherited by the mailboxes (when new mailboxes are being created).
But in some situations, when troubleshooting and when the agent is reporting access issues to a particular mailbox, one might want to try the following:
Get-Mailbox | Add-MailboxPermission -User qmm-svc -AccessRights Fullaccess -InheritanceType all
In order to grant the service account the permission to actually open the mailboxes and to and to put content into the mailboxes the following command can be used:
Get-MailboxDatabase | Add-ADPermission -User "TARGET\QMMSRV" -ExtendedRight Receive-As
Note: It was observed that those permissions would sometimes (in some environments) disappear from the database level, eg. when the Generic All is reapplied. Once this happens the agents, when using the service account, cannot open the mailbox anymore.
If this happens one can execute the following Powershell query to show if the previously assigned permissions are still set correctly:
Get-MailboxDatabase DATABASENAME | Get-ADPermission | Where {$_.user -like "*qmm*"} | ft identity,user,accessrights,extendedrights,*inherit*
Notes:
1. The query above can be executed repeatedly and the admin can watch how long it takes for the permissions to be applied or removed by Exchange.
2. It was observed that sometimes, until the mailbox storage is created, the permission do not display when using ESM. But this doesn’t mean that they are not present, if they have been set they will be shown later.
3. In a few cases the service account permissions appears to be set correctly for some mailboxes - they were visible in ADSIEdit, ESM and PowerShell displays the warning that permissions already present. But the service account still couldn't login. After explicitly removing service account permissions and setting them again - the issue was resolved.
