Mailbox folder permissions are overwritten when importing from a PST file using Import-Mailbox cmdlet
Organizations may create calendar PST files for their organizations or teams. This may include organization / team events, project deadlines, holidays or even birthdays.
After entering all of this information into the calendar of a generic mailbox, you can then export this calendar to a PST file, CompanyHolidays.pst for example. Now an Exchange Administrator can use the Import-Mailbox cmdlet to import this into everyone’s mailbox, thus putting all the events on everyone’s calendar.
When doing this several customers have report the permissions to the calendar folder are being reset or rewritten. After a little research we found out what was going on.
To actual copy the data from the PST to the mailbox the cmdlet uses the IMAPIProp::CopyTo interface. This is used when an item or object should be copied exactly. We use this to ensure all properties are intact. This is where our problem comes in, it copies ALL properties, exactly as they are in the source PST file. One of the properties of a mailbox folder it the ACL (Access Control List) or the permissions.
This is clearly viewable in MFCMAPI:
The PR_ACL_DATA is where permissions to this folder are held. You can see this is the same data from the permissions tab in Outlook.
So we have our PST file that we created with no permissions, just the defaults. But our users have probably added several people to have permissions to their calendar. When we run the import, those custom permission are overwritten by what’s in the PST file. In effect resetting the calendar permissions back to the defaults.
But we don’t want to overwrite all of our user’s permissions. We just want to import the calendar items from the PST. Luckily the CopyTo interface allows for this. There is a parameter for passing a list of properties that should be excluded from the copy operation.
PR_ACL_DATA and PR_ACL_TABLE are already in that list.
Then why are we still overwriting permission? For that we need to look at where the functionality comes from. The Exchange Managment Tools, and thus the Import-Mailbox cmdlet, load and utilize MAPI DLLs provided by Outlook. This is one of the requirements, please see reference link below. In this case, we specifically use OLMAPI32.DLL. This DLL contains most of the core MAPI interfaces and functions.
This means ultimately, the call to copy the properties is really handled by the Outlook DLL. A little research on the Outlook 2007 side reveals that this was not originally handled correctly.
For Outlook 2007 there is an update, which is included in SP2, that adds a registry key that needs to be set so that the DLL knows there are properties to exclude:
HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\Preferences
dword: CopyFolderEx
Value: 1
Once SP2 is installed and this registry key is in place and set on the client system we are running the Import-Mailbox command from, the permissions in the user’s mailbox will no longer be overwritten.
References:
https://technet.microsoft.com/en-us/library/bb691363(EXCHG.80).aspx
To import data from a .pst file, you must use the 32-bit version of the Exchange management tools. You cannot run the 32-bit version of the Exchange management tools on a server that is running Exchange 2007 because it is a 64-bit computer. You must run the Import-Mailbox cmdlet from a 32-bit computer that has the following installed:
- The 32-bit version of the Exchange management tools
- Microsoft Office Outlook 2007 or Outlook 2003 Service Pack 2 (SP2)
IMAPIProp::CopyTo
https://msdn.microsoft.com/en-us/library/cc839922.aspx