New-MailboxImportRequest raising “Error details: Access to the path is denied”

Importing PSTs to an Exchange on-premises mailbox is a cool feature because it helps you to get rid of old legacy PSTs which can cause you a lot of trouble (e.g. corrupted because saved on a network share, accidentially deleted because of hardware switch, etc etc etc).

But sometimes the command to start a new import can drive you crazy as well:


Follow the official documentation for this command to see how powerful it is and how to use it. So when you execute the command you may face the following error:


The error text says:

Unable to open PST file '\\SERVER\c$\Exported PSTs\PSTNAME.pst'. Error details: Access to the path
'\\SERVER\c$\Exported PSTs\PSTNAME.pst' is denied.
 + CategoryInfo : NotSpecified: (:) [New-MailboxImportRequest], RemotePermanentException
 + FullyQualifiedErrorId : [Server=EXCHANGESERVER,RequestId=078dc502-aecb-4122-8e22-f96c1c6141f8,TimeStamp=28.11.2017 10:
 34:01] [FailureCategory=Cmdlet-RemotePermanentException] 7B1A4B04,Microsoft.Exchange.Management.RecipientTasks.New

So the next thing you do is to check the permissions on the folder and they normally look like this:


If you read the official documentation very careful, there is a small hint:

You need to grant the following permission to the group Exchange Trusted Subsystem to the network share where you want to export or import PST files:

  • To import PST files from the share: Read permission
  • To save exported PST files to the share: Read/Write permission.

If you don’t grant this permission, you will receive an error message stating that Exchange is unable to establish a connection to the PST file on the network share.

Oh looks like reading the documentation was a good idea, because now the request is being created and the import starts. I personally prefer sharing the folder directly with a $-share. Don’t forget to edit the folder permissions and the sharing permissions. In my case it only worked when I set both:


This permission may not be set for a variety of reasons, e.g. a topology with many ActiveDirectory Domains where Exchange is installed in one of the domains, an interrupted permission inheritance or similar.

No matter where it comes from, now you know how to fix it. Happy importing 🙂

Published by Andreas

Founder of M365 Evangelists Cloud-Architect, Strategy Consultant, Consultant for Microsoft technologies, Graph API enthusiast, PowerShell enthusiast
%d bloggers like this: