Updated version of the mailbox permissions inventory script

As I’m continuing the quest of updating old scripts to the latest and greatest, our next step is the mailbox permissions inventory script. Few things have changed since the initial version of said script was released. Most notably, Microsoft cleaned up the output a bit, and “system” entries are no longer returned, apart from the “NT AUTHORITY\SELF” one that is. In addition, the User property in the output now returns a UPN (string) value. If the object is a group, a string value representing the group identity is returned instead. And as service principal objects are now supported for delegating Full access permissions, you might also see the occasional GUID value.

The other significant change is of course the release of the V2 version of the Exchange Online PowerShell module, and specifically the REST-based cmdlets it brings. Thus, the script no longer needs to use a Remote PowerShell session and removes all such dependencies, including the simple anti-throttling measures. Some basic checks for the presence of the V2 module and connectivity to Exchange Online have been added, but given the variety of methods supported, feel free to update those as needed (lines 50-59). On the negative side, the dependence on the V2 module and REST cmdlets means that on-premises Exchange server installs are not supported by this version of the script.

The set of mailbox objects we care about has also changed a bit. As Microsoft has moved away from leveraging Discovery mailboxes for eDiscovery/Content searches, the script no longer includes them in the output. Similarly, Team/site mailboxes have been sunset, and while some such entries might still exist within your organization, you likely don’t care about them anymore. In any case, it’s dirt easy to add them to the list, if needed. Lastly, Group mailboxes are also not included, as there is no supported method for adding mailbox-level permissions on those.

The script now supports enumerating permissions on Booking/Scheduling mailboxes, which are included in the output when you specify the –IncludeRoomMailboxes (or –IncludeAll) switch. In addition, a new switch has been introduced to support soft-deleted mailboxes, namely –IncludeSoftDeleted. If you initiate the script with said parameter, all the soft-deleted mailboxes (of the selected types) will be enumerated and any non-default permission entries on them returned in the output. Some oddities in how different cmdlets handle soft-deleted mailboxes require a different handling to be implemented, do let me know if you run into any issues with that.

With all that said, you can obtain the new version of the script over at my GitHub repo. To generate the Full access inventory report, simply invoke the script with the desired parameters, which include:

  • IncludeUserMailboxes – use it to include User mailboxes in the output.
  • IncludeSharedMailboxes – use it to include Shared mailboxes in the output.
  • IncludeRoomMailboxes – use it to include Room, Equipment and Scheduling (Booking) mailboxes int he output.
  • IncludeAll – use it to include all supported mailbox types. This is the default behavior when you invoke the script without using other parameters.
  • IncludeSoftDeleted – use this parameter to include soft-deleted mailboxes in the output.

For example, if you want to generate a report for only Shared mailboxes, but also make sure to include any soft-deleted ones, invoke the script as follows:

.\Mailbox_Permissions_inventoryV2.ps1 -IncludeSharedMailboxes -IncludeSoftDeleted

The output is stored by default in the $varPermissions variable, allowing you to immediately reuse it or modify it before exporting to CSV. By default, the output will also be exported to a CSV file within the script directory, if you want to avoid that comment the last line.

One other thing that comes to mind – compared to the Get-MailboxPermission cmdlet, the REST-based Get-MailboxPermission one does not include the UserSid property in the output. This is not a big issue, although the property might be useful in some scenarios.

And that’s it. As usual, let me know if you run into any issues.

This entry was posted in Exchange Online, Microsoft 365, Office 365, PowerShell. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

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