Endless loop in OWA with error about incorrect permissions

Another random discovery, this time it’s nothing serious. While I was trying to reproduce the OWA hold issue using only folder permissions, I run into this endlessly looping error message. Not really a major issue, but certainly causes an inconvenience (especially to EO users that might not have access to Outlook). Here’s a description of the issue:

If you grant permissions to some other user in order for him to access say a subfolder of your Inbox, and you forget to grant permissions on the other folders in the path, you will be greeted by the “You might not have permissions to perform this action” error message. This is of course working as expected, the problem is that if you have granted permissions on the Top of information store, but skipped some other folder in the path (say ‘Inbox’), OWA will start replaying the same error message repeatedly and it will loop without giving the user the option to take any other action.

Steps to reproduce:

  1. Pick a random mailbox (called “testmove” in the example below), create a subfolder of Inbox (let’s call it “Test”)
  2. Grant another user, say Vasil, any type of permissions to the testmove:\Inbox\Test subfolder. Do not grant permissions to any other folder in the path
  3. If you test access to the shared folder by logging to OWA as Vasil, you will get the (single) error message every time you try to click the folder
  4. Now, grant Vasil any type of access to the Top of information store, the John:\ folder
  5. If you test access to the shared folder now, after the initial click on the folder OWA will start looping the same error message over and over again, preventing Jamie from taking any action in OWA (such as navigating away from the shared folder)

This is probably best illustrated with showing the actual permissions:

PS C:\> Get-MailboxFolderPermission testmove
FolderName User AccessRights
---------- ---- ------------
Top of Informatio... Default {None}
Top of Informatio... Anonymous {None}
Top of Informatio... Vasil Michev {Owner}

 

PS C:\> Get-MailboxFolderPermission testmove:\Inbox

FolderName User AccessRights
---------- ---- ------------
Inbox Default {None}
Inbox Anonymous {None}

 

PS C:\> Get-MailboxFolderPermission testmove:\Inbox\Test
FolderName User AccessRights
---------- ---- ------------
Test Default {None}
Test Anonymous {None}
Test Vasil Michev {Owner}

With this setup, the moment I click on the “Testmove” tree in OWA, I get the loop. Simply adding permissions on the testmove:\Inbox folder or removing them from the root one will ‘fix’ it. It doesn’t matter what kind of permissions you grant on the root. You can have for example Read permissions on the Root and Owner permissions on the subfolder and you should still be able to replicate this.

The issue is present in both Exchange Online and on-prem versions (tested as far back as CU1). Outlook works fine with this.

I believe the cause behind this issue is the different method OWA uses to access shared folders. With Outlook, you have two different options, the first one being the File -> Open & Export -> Open User’s Folder functionality. It allows you to open one of the default folders of another person. It’s very limited it functionality, it does not allow you to open a subfolder for example, or any other folder no listed in the dropdown. It will also not show you the shared folder in the navigation pane on the left, it will ‘disconnect’ it once you click to another folder and it will only indicates that you are currently working in a shared folder by changing the menu bar text. The benefit of this method is that you only need permissions to the said folder.

The second option Outlook offers is to open it as additional mailbox, using the Account Settings -> More Settings -> Advanced Menu. When you do this, the mailbox will be added in the left pane, and every folder you have been granted access to will be visible. You do not need to have Full Access permissions on the actual mailbox. It’s by far the more convenient solution, however it requires that you have been granted permissions also on the root folder, the Top of Information Store. For this reason, many companies change the Default permissions on the Top of Information store folder to Reviewer upon mailbox creation. On the other hand, having permissions on the Top of Information store folder can be misleading, as the mailbox will be added on the left pane, but if you have not been granted permissions to any other folder, expanding it will give no error message, yet it will also not show any content.

Compared to Outlook, OWA seems more user friendly, since it combines the two methods. It sort of tries to open both as a shared folder and as additional mailbox. It’s a bit strange cause it never asks you which folder you want opened, so I’m guessing it’s preconfigured for Inbox. This allows you to happily browse Inbox and any subfolders in it even if you miss the permissions on the root. Which might as well explain the issue – seems that OWA is constantly trying to enumerate the delegate folders or simply to open the default folders/Inbox, thus triggering this endless loop.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.