Chat with us, powered by LiveChat

Blog

Back

Office 365 Permissions Inventory: Full Access

26 Apr 2017 by Vasil Michev

Welcome to the next article in the “Permissions Inventory” series. So far, we have covered Send on behalf of and Send As permissions, and in this article we will tackle Full Access permissions.
It’s worth noting that a similar article can already be found on our blog. It was written by Alan, all the way back in 2012, and is accompanied by the Export mailbox permissions from Office 365 to CSV file script – one of the most downloaded scripts on the TechNet Gallery! Now that’s not an easy task to beat, and the intent of this article is not to compete with it, but to give an updated, and slightly different approach, while at the same time building on our “Permissions Inventory” series.
So let’s get started. To get the mailbox permissions in Office 365, we have to connect to Exchange Online and use the Get-MailboxPermission cmdlet, which returns the following output:

You will see a full list of users configured with any set of permissions on the mailbox in question. In most cases however, this is just too much information. Yes, the Domain Admins in the Exchange Online forest will have permissions on your mailbox, but the same will be true for all other mailboxes. Therefore, it makes sense to limit the output to explicitly added permissions. A simple way to do this is to filter out any inherited permissions, using the example below:

Now, the output is much cleaner, and therefore more useful. Alternatively, you can filter out all the individual groups/accounts visible in the previous screenshot. The script included in this blog post uses the first method.
In addition, the Get-MailboxPermission cmdlet might return orphaned entries, indicated by the presence of a SID value instead of the actual user. Excluding those is also possible. As well as this, you might want to limit the output to entries that match the FullAccess level of permissions only. An example of how to get rid of all these entries is included in the script, which you can find here.
Now that we know how to get the mailbox permissions, let’s talk about the actual script. First of all, a script-based solution is needed because the Get-MailboxPermission cmdlet needs to be run individually against every mailbox you’re interested in gathering permissions for. In large organisations, this means running against thousands of mailboxes, which will take a considerable amount of time. To speed things up a bit and minimise the resources used, the script uses the Invoke-Command method to gather the list of mailboxes and a small subset of their properties.
Further improvements to the speed of execution for the script are made possible by the fact that the output of the Get-MailboxPermission cmdlet now returns the UserPrincipalName attribute for user objects. Previously, only the display name was returned – which made it necessary to add additional checks (and therefore additional cmdlets to execute). These were used to ensure that a unique identifier for the user is returned. An example of how to do this can be found in Alan’s script, and although this part is no longer necessary for user objects, it can be used to uniquely identify group-based permission entries (which still only return display name).
A progress indicator has been included to make it easier to estimate the script completion time. As the script might still take considerable amount of time to execute, and output is only written to the console by default, you might consider removing the comment mark from the last line. In case the script fails, (often due to connectivity issues) an alternative approach is to uncomment line 95 so that output is written to a CSV file after each iteration.
Speaking of connectivity issues, the script does not handle connectivity to Exchange Online. As explained in the previous article, there are multiple ways to connect to ExO remote PowerShell nowadays, and most organisations have scripted their own solution. Connectivity is still checked for, and if no active session is detected then the script will fail. If you need help with connecting PowerShell to ExO, this article has all the information you need.
Similar to the ‘Send on behalf of’ script, you can use parameters to specify the type(s) of mailbox(es) you are interested in, including: User, Shared, Resource, Equipment, Team and Discovery mailboxes. Permissions for Group mailboxes are handled via “links” now, so they will be covered in a separate article. In the following example, we are using the script to gather permissions on all user mailboxes:

The output is stored by default in the $varPermissions variable, allowing you to immediately reuse it, or modify it, before exporting to CSV.
And that’s it. This ‘refreshed’ script should be faster and more efficient, but the end result will be pretty much the same as the one from 2012. We introduced a set of parameters to allow you to quickly filter different mailbox types. Alan’s script on the other hand allows you to feed the input objects from a CSV file – avoiding the need to loop over all mailboxes in the organisation. In both cases, the assumption is that organisations will customise the script to better meet their needs, so please feel free to make any modifications and send us your feedback!
Cogmotive is the leading global provider of enterprise level reporting and analytics applications for Office 365. Find out more now.

Vasil Michev has closely followed the evolution of Microsoft's Productivity Cloud offerings since the very beginnings with BPOS. With a career that has spanned the industry, from Frontline Engineer to Consultant, Michev has a unique, and wide-reaching experience, encompassing all stages of the Office 365 adoption lifecycle. In his spare time, he enjoys getting involved in various Office 365 communities, helping like-minded people, and writing blog posts. His contributions have earned him the Microsoft MVP Award three times.
whois: Andy White Freelance WordPress Developer London