Back to blog

Office 365 Permissions Inventory: Send As

Mar 15, 2017 by Vasil Michev

This series of blog posts will explore the different types of permissions, and the scripts and cmdlets that can return this information. Previously, I have written about getting user’s permissions across all Office 365 Recipients, but this time around it’s a little different. The idea here is that you’re not trying to find out which permissions a specific user has, instead you want to get the complete inventory of permission types assigned. This blog will focus on the easiest permission type: Send As.

What makes getting Send As permissions so easy is the fact that you only need to call the Get-RecipientPermission cmdlet once. That’s not even the best part – you don’t actually have to loop over all recipients or pipe them to the cmdlet! Simply run the cmdlet without specifying the Identity parameter and all Send As entries configured across the service will be returned. Including some “hidden” ones.

Let’s see what this looks like in practice:


The list will probably go on, as other system mailboxes are included by default. The point however is that you don’t have to get the list of recipients beforehand and pipe them or do cycles – it’s both faster and simpler to use the Get-RecipientPermission cmdlet directly! Now, we can modify it a bit to make sure only relevant entries are included.

Here’s an example:

Get-RecipientPermission -ResultSize Unlimited | ? {$_.Trustee -ne “NT AUTHORITY\SELF” -and $_.Trustee -ne “NULL SID”}

As you can see, things start to look much simpler now, and multiple entries across different recipient types were returned. To get this exported to a CSV file, use:

Get-RecipientPermission -ResultSize Unlimited | ? {$_.Trustee -ne “NT AUTHORITY\SELF” -and $_.Trustee -ne “NULL SID”} | Export-Csv -nti SendAsReport.csv

So there you have it – fast and easy. If only other types of permissions could be queried like this!

It’s worth bearing in mind that the people who use permission inventory reports such as the one generated above often need more detail – for example, they might need the exact recipient type, and the email address of the recipient (as the identity/display name is often not enough to identify the object). As a result, you might need to try and modify the output. Unfortunately, as the cmdlet returns string output instead of the actual object, this will mean executing additional cmdlets, and thus increasing the complexity and time to run.

Here’s an example which includes the recipient type and email address:
$list = @(“UserMailbox”, “SharedMailbox”, “RoomMailbox”, “EquipmentMailbox”, “MailContact”, “MailUser”, “MailUniversalDistributionGroup”, “MailUniversalSecurityGroup”, “DynamicDistributionGroup”, “RoomList”, “PublicFolder”, “TeamMailbox”, “GroupMailbox”, “GuestMailUser”, “DiscoveryMailbox”)
Get-RecipientPermission -ResultSize Unlimited | ? {$_.Trustee -ne “NT AUTHORITY\SELF” -and $_.Trustee -ne “NULL SID”} | Select @{n=”DisplayName”; e={$global:temp = Get-Recipient $_.Identity -RecipientTypeDetails $list ;$temp.DisplayName}}, @{n=”EmailAddress”;e={$temp.PrimarySmtpAddress}}, @{n=”RecipientType”;e={$temp.RecipientTypeDetails}}, Trustee, AccessRights, AccessControlType, IsInherited, InheritanceType | Export-Csv -nti SendAsReport.csv

The $list variable is used in order to enumerate all the available recipient types. This is necessary because the Get-Recipient cmdlet does not return Office 365 group mailboxes by default (or Team mailboxes for that matter), and you have to explicitly specify the type if you want to include the additional details for objects of that type. To reduce the run time of this report (especially for large organizations) the temporary variable $temp is used for all three newly added properties. Otherwise, you would have to run the Get-Recipient cmdlet three times, which significantly increases the report run time.

The more additional properties you need to include in your report, the more cmdlets you will have to run, and the more complex the script becomes. Therefore, at a certain point it makes no sense doing this with one or two-liners. Instead, you should try to use a full script solution with proper reuse mechanisms, error handling and so on. The one thing I would say is that adding additional properties is certainly possible, but it does have a cost. Personally, I prefer to stick with the simple cmdlet we used in the first few examples.

Finally, it’s worth showing a couple of examples using the Trustee parameter. The idea is that you can get a list of all recipients showing users that have Send As permissions granted, without having to loop over them. So again, this is faster and simpler than the usual methods.

Here’s how to do it:

Get-RecipientPermission -Trustee vasil

and the same format can be used against other object types:

Get-RecipientPermission -Trustee secgrp

About Vasil
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