Exchange Migration first & Mailbox Folder Permissions

In many inter forest migration projects, the mailbox migration to the new Exchange Organization into the new forest is performed first and the user migration is performed in a separate step at a later time. After the mailbox migration and before migrating the user objects, you have a classic Resource Forest scenario. Users are created as disabled user accounts in the target forest, receiving a linked mailbox, connected to the source Active Directory user. Important AD attribute in this scenario is msExchMasterAccountSID. This attribute of the disabled target user object holds the objectSID of the source user account. This allows to connect to the own mailbox and shared mailbox resources (Delegate permissions etc.) with the active source user object.

ExMigirst01

Did you ever thought about mailbox folder permissions in this scenario? 

For every migrated folder permission (e.g. with QMM for Exchange) and also every time a user manually adds mailbox folder permissions for another (not Active Directory migrated) user in the target mailbox, the SID of the source user object is added to the mailbox folder permissions. In this example, we’ve selected the not migrated user UserA from the Global Address list and added him as delegate for the Inbox and the calendar for the Info MBX:  ExMigirst02

At some point, the Active Directory migration will start. During this process, the user account in the target domain will be activated and the Linked Mailbox is converted to a User Mailbox. This action will clear the attribute msExchMasterAccountSID. This is necessary because the target account will now be used to access the own mailbox and resources of other mailboxes. If a migrated user is now added to the mailbox folder permissions, the target SID will be added and no longer the source SID. Let’s use the mailbox example above and add the migrated user UserB as additional delegate for the Calendar of the Info MBX:ExMigirst03

In this example, UserB will of course not have any problems accessing the Info MBX. But what happens if UserA will be migrated and the user starts accessing the Info MBX with TARGETDOMAIN\UserA? The SID of the target account has no permissions on the Inbox and the Calendar folder. Will UserA loose access to these folders now? Generally, the answer is YES, UserA will lose access! But…

In Active Directory Migration projects, it is best practice to migrate the SIDHistory to the target user account. In this case, the objectSID of the source user is copied to the attribute SIDHistory of the target account. For our example, it means that UserA will not lose access to the Info MBX because his Access Token contains the Source SID which has permissions on the Inbox and Calendar folder in the Info MBX.

SIDHistory CleanUp & mailbox folder permissions?

Clearing SIDHistory is part of most of the migration projects. Before clearing the SIDHistory attribute of the target accounts, it is required to replace the source SIDs with the corresponding target SIDs inside the mailbox folder permissions. This process is called ReACLn. Without this action, many users will lose access to shared mailbox resources when the SIDHistory attribute is cleared.


Exchange Processing Wizard (Part of Dell Migration Manager for Active Directory)

Dell migration Manager for Active Directory contains the Exchange Processing Wizard. This wizard is able to replace existing source SIDs with the matching target SIDs for permissions inside the exchange environment. The wizard is using the matching information in the QMM AD LDS database, created during the directory synchronization.

To ReACL permissions inside the mailboxes, we have to select the option “Update client permissions”:

ExMigirst04

Now we can choose to process all Public Folders and Mailboxes or select individual Mailboxes or Public Folder or even skip Public Folders or Mailboxes completely:

ExMigirst05

The wizard provides the possibility to only process one server or process multiple servers in parallel.

Known limitation of the Exchange Processing Wizard:

The wizard is unable to set the Free/Busy permissions Free/Busy time, subject, location. After processing, the permission is changed to Free/Busy time only:

ExMigirst06


Good to know – Check real SID behind folder permissions

Get-MailboxfolderPermission: Unfortunately, as long as the SIDHistory is set for a user, Exchange will always resolve the permissions to the target account. So Exchange will always show the TARGETDOMAIN\User although in fact the source SID has permissions on the mailbox folder. You will also see the same result if you query folder permissions via EWS (e.g. with EWSEditor).

MFCMAPI:

To check which SID is really behind the permission, you can use MFCMAPI to access the mailbox.

  1. Create a new profile for mailbox and disable Exchange Cached Mode.
  2. Start MFCMAPI
  3. Click Session->Logon and choose the profile you’ve created in step 1.
  4. Double Click the Mailbox entry and now navigate to the folder for which you want to display the permissions.
  5. On the right side, now double click PR_NT_SECURITY_DESCRIPTOR

In the Smart View, you can see which SID is really behind the Access Control Entry.

5 thoughts on “Exchange Migration first & Mailbox Folder Permissions

  1. Excellent Article very informative!

    In regards to the ADPW in the section “Processing Objects” the option Exchange Mailbox Permissions when does this come into play if you would do a mailbox migration to the new Exchange Organization into the new forest is performed first and the user migration is performed in a separate step at a later time. Could you explain it the way you did for this write up?

    Thanks,
    Carlo

    1. Hello Carlo,
      The ADPW option “Exchange Mailbox Permissions” is able to reAssign permissions for the mailbox itself (e.g. Full Mailbox Permissions). In fact, it modifies the AD attribute MsExchMailboxSecurityDescriptor. If you are migrating with the DELL Migration Manager, these permissions will be synchronized to the target Domain via the Directory Synchronization Agent. Meaning if you check the Mailboxpermissions for the target mailbox, source and target accounts with appropriate permissions should be listed. So in this szenario, the ADPW option is only usefull for cleaning up the source permissions from the MsExchMailboxSecurityDescriptor as a cleanUp task at the end of the AD migration. From my experience of the last projects, it is a good idea to perform this cleanUp with the ADPW. The tool is included in the AD Migration Manager package (nothing needs to be scripted), very fast and has a good logging. You can run the cleanUp for the complete target domain or process only dedicated OUs.

      Just to share a little bit of my experience related to that cleanup topic:

      Of course you could also to this cleanup action native via powershell but take care. In case that the sidHistory attribute is still set for the users, it may be that Get-Mailboxpermissions shows wrong information becauce it translates the source SID to the target user because the target SidHistory equals the source SID. If you perform the cleanup with Remove-Mailboxpermission, it may end in removing the permissions for the target user and not as expected for the source user.
      As a tipp: You can always check the TRUTH behind the mailbox permissions by reading the MsExchMailboxSecurityDescriptor using this command: (Get-ADUser SAMACCOUNTNAME -Properties msExchMailboxSecurityDescriptor).msExchMailboxSecurityDescriptor |fl
      The property SDDL shows the SIDs.

      Regards
      Stefan

    2. Hello Carlo,
      The ADPW option “Exchange Mailbox Permissions” is able to reAssign permissions for the mailbox itself (e.g. Full Mailbox Permissions). In fact, it modifies the AD attribute MsExchMailboxSecurityDescriptor. If you are migrating with the DELL Migration Manager, these permissions will be synchronized to the target Domain via the Directory Synchronization Agent. Meaning if you check the Mailboxpermissions for the target mailbox, source and target accounts with appropriate permissions should be listed. So in this szenario, the ADPW option is only usefull for cleaning up the source permissions from the MsExchMailboxSecurityDescriptor as a cleanUp task at the end of the AD migration. From my experience of the last projects, it is a good idea to perform this cleanUp with the ADPW. The tool is included in the AD Migration Manager package (nothing needs to be scripted), very fast and has a good logging. You can run the cleanUp for the complete target domain or process only dedicated OUs.

      Just to share a little bit of my experience related to that cleanup topic:

      Of course you could also to this cleanup action native via powershell but take care. In case that the sidHistory attribute is still set for the users, it may be that Get-Mailboxpermissions shows wrong information becauce it translates the source SID to the target user because the target SidHistory equals the source SID. If you perform the cleanup with Remove-Mailboxpermission, it may end in removing the permissions for the target user and not as expected for the source user.
      As a tipp: You can always check the TRUTH behind the mailbox permissions by reading the MsExchMailboxSecurityDescriptor using this command: (Get-ADUser SAMACCOUNTNAME -Properties msExchMailboxSecurityDescriptor).msExchMailboxSecurityDescriptor |fl
      The property SDDL shows the SIDs.

      Regards
      Stefan

  2. Hi Stefan,

    When running the EPW against a user(s) Mailbox to correct the MAPI permissions does that account have to be disabled? or can it be enabled ?

    Thanks,
    Carlo

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s