skip to Main Content

Full Access Mailbox permission – Everything You Always Wanted to Know About But Were Afraid to Ask part 1/3

In this article, we will learn about different aspects of the famous mailbox permission: The Full Access. When I needed to get clear information about the concepts and the use of the “Full Access mailbox permission”, I found many articles that deal with this subject, but I could not find a complete and comprehensive article that provides a range of different scenarios and detailed explanations of the variety of options that could be used for the Full Access mailbox permissions.

Full Access Mailbox permission | Article Series

The Full Access Mailbox permission article series includes the following three articles:

  1. Full Access Mailbox permission – Part 1/3 (this article)
  2. Full Access Mailbox permission – Part 2/3
  3. Full Access Mailbox permission – Part 3/3

Permission type in Exchange Online environment

The subject of “permissions” in the Exchange Online (and also in the Exchange On-Premises) environment includes a couple of “permission types” that enable a user to execute a specific operation on another user’s mailbox. The Send As and the Send on behalf permissions enable a specific user to “impersonate” send an email using another user name, the Folder permission enables a user to access a folder (such as calendar or contact)in another user’s mailbox and the mailbox permissions, that enable a user to get access to all the mailbox content of the other user’s mailbox.

In this article, we review in the details the subject of Mailbox permission.

Graphic interface vs. PowerShell interface

Exchange Online (and the Exchange On-Premises MMC) enable us to use a simple graphical interface for managing the mailbox permission. Although many times we prefer the graphic interface, the PowerShell has a huge advantage when we need to implement more complex and advanced tasks.

In this article, I would like to cover a broad range of possible scenarios of – managing mailbox permission using PowerShell and additionally, provides more background details about the available option that we can use to improve specific PowerShell commands.

Mailbox permissions PowerShell commands basic structure

The basic structure of the PowerShell mailbox permissions command, is written by using the following syntax:

Mailbox permissions PowerShell command basic structure-03

In our example, we want to enable Alice to get Full Access permission to hear manager mailbox. The -Identity parameter, relates to the user who wants to “share” his mailbox (provide other users the option to access the content of his mailbox) and the –User parameter, represent the user who will get the access to the mailbox.

Technically, there is no mandatory demand to use this “order”, and we can reverse the order by specifying first the user who will get the Full Access permission (Alice) to the “destination” user mailbox (John). For example, the following PowerShell syntax will provide the same result:

Mailbox permissions PowerShell command basic structure-04

In most of the technical article that includes code samples of PowerShell syntax, the first scheme is used so, in this article, we will stick to the “standard” syntax order that used most of the time.

The “identity” parameter

The identity parameter describes the object (the user) that “want” to enable other users to have Full Access permission to his mailbox (in our example: John).

The use of the Identity parameter is not mandatory because, in some scenarios (like the Mailbox permission’s command syntax), The PowerShell syntax enables us to use a shorter version of command syntax.

In simple words, the use of the Identity parameter is optional and most of the time,

I allow myself to “drop” the use of the identity parameter to make the task of writing the PowerShell simplest.

Note: The parameter that specifies the user who will have Full Access permission is user we cannot avoid from specifying the parameter because this parameter is not optional.

The PowerShell mailbox permissions command and additional parameters

Inheritance and Inheritance Type

When we use PowerShell commands for providing mailbox permissions, most of the time, we will add parameter that relates to the subject of “Inheritance.” The basic PowerShell command that enables mailbox permissions to provide permission only to current mailbox folders that exist in the user mailbox. In case that the user adds folder to his mailbox, the user that has Full Access permission will not be able to access this “new folder.”

To avoid from this scenario, we usually add to the basic command structure the following parameter: -InheritanceType All. By using this parameter, we enable to a user that has Full Access permission to have the ability to access all of the additional folders that will be added by the user.


AutoMapping is a feature that automatically adds to Outlook (and OWA) mail profile an “additional mailbox” which the user has Full Access permission.

For example: when we provide Alice Full Access permission to John’s mailbox, the additional mailbox will be added automatically to the Alice Outlook mail profile.

The purpose of the AutoMapping was to simplify the administrator (and the user) life. In former versions of Exchange server, after providing a Full Access permission to a user, the user was required to add the additional mailbox manually to his Outlook profile.

When we provide a Full Access mailbox permission, the default PowerShell command is using the AutoMapping feature (the AutoMapping value is set to “True”).

In some scenarios, we want to avoid this default. For example: in a scenario in which we provide to the Administrator Full Access permission to all the user’s mailboxes, most of the time, we don’t want to use the AutoMapping feature because when the administrator opens Outlook, his Outlook profile will have to connect to tens or hundreds of additional mailboxes. Later in this article, we will review additional scenarios that relate to the future of AutoMapping.

Mailbox and user identity

When using a mailbox permission, we provide permission to User-A permission to another user’s mailbox (User-B). The reference to the “user” implemented by using an “identity”.

Each of the user objects has a couple of “identities” that we can reference. For example, we can address a user’s identity by using the user Alias name, the user “Display name” or, the user Email address (there is an additional type of identities that we can be used such as proxy address, GUID, etc.).

The easiest to use is the user “Alia’s identity” but the Alias Identity is not a unique value and in some scenarios, two (or more) users can have the same Alias name. In case that we want to avoid a situation that could lead to mistake or errors, the best practice is to use the Email address identity.

Add-MailboxPermission -Identity "" -User "" -AccessRights FullAccess -InheritanceType All

In the code sample that will be provided later in this article, I will use the user Alias as an identity to simplify the PowerShell code sample.

For example: instead of using the email address as user identity, we will use the users. Alias names: such as John and Alice.

Add-MailboxPermission -Identity "John" -User "Alice" -AccessRights FullAccess -InheritanceType All

Access Rights

The AccessRights parameter specifies the type of rights that we want to assign.

We can relate to the “Access Right” as a role or container that holds a subset of specific permissions. For example, the Full Access permission is a collection of permissions such as delete, update, add, etc.

The available permissions that we can use are:

  • FullAccess
  • ExternalAccount
  • DeleteItem
  • ReadPermission
  • ChangePermission
  • ChangeOwner

The most common use permission is – Full Access permission. In the demonstration that will be provided in the article, we will use the Full Access permission.

Assigning permission to group vs. assigning permission to user

In most of the technical article that includes PowerShell code sample of mailbox permissions, the syntax displays a scenario in which we provide User-A Full Access mailbox permission to the mailbox of User-B.

A neglected option that not mentioned most of the time is that instead of providing permissions to a particular user, we can use the option of Security group for providing a mailbox permission. Using a Security group for providing mailbox permissions have two key benefits:

  1. Efficient management – for example: in case that we want to provide mailbox permission to 10 users on a specific user mailbox, we can execute the PowerShell command 10 times or instead, create a Security group that includes this 10 users and assigns mailbox permission to the Security group.
  2. The “dynamic nature” of a Security group – When we assign mailbox permissions to a Security group, the group member automatically inherits the permissions from the group. In case that we want to provide mailbox permission to additional users, all we need to be to add the user to the Security group, and the “new group member” will automatically inherit the mailbox permission that was assigned to the group.

Table Matrix of permissions scenarios

1Assign to a user, mailbox permissions on the other User Mailbox.Assign to a user, mailbox permissions on other User Mailbox--01
2Assign mailbox permissions to a user, on a Security or a Distribution group.Assign mailbox permissions to a user, on a Security or a Distribution group--02
3Assign mailbox permissions to a Security group on a User mailbox.Assign mailbox permissions to a Security group on a User mailbox--03
4Assign mailbox permissions to a Distribution group on a User mailbox.Assign mailbox permissions to a Distribution group on a User mailbox--04
5Assign mailbox permissions to a Security group on a Distribution group Member.Assign mailbox permissions to a Security group on a Distribution group members.--05
6Assign mailbox permissions to a Security group of other Security group Members.Assign mailbox permissions to a Security group on other Security group members.--06
7Assign mailbox permissions to a Distribution group Member on a Security group.Assign mailbox permissions to a Distribution group members on a Security group--07

Windows PowerShell Integrated Scripting Environment (ISE)

PowerShell commands can be very simple or include a couple of “code lines” (PowerShell script). The standard PowerShell consoles have some limitation when we use a more complex code because it’s not so easy to copy and paste a complex structure of PowerShell code to the PowerShell console. A more preferred option that I would like to recommend is using the: ISE (Windows PowerShell Integrated Scripting Environment).

In a nutshell, the ISE is a combination of a graphic and PowerShell console interface. The ISE interface is divided into two sections.

The “top part” (Number 1) enables us to paste or write a more complicated PowerShell command. The different parts of the PowerShell command, such as variables and parameters, automatically color with a different color. When we choose the “run” option, the PowerShell script will be excited to the bottom part (Number 2).

In the following screenshot, we can see the interface of the ISE.


Using WhatIf option

One of the most useful options/tools we can use when working and testing a PowerShell command is the -WhatIf parameter. The -WhatIf parameter enables us to simulate the possible results of a PowerShell command.

In a production environment, it’s critical to test or simulate the results from the PowerShell command that we want to execute. Especially when dealing with bulk mode commands that can influence tens or hundreds of mailboxes.

The use of the -WhatIf parameter is quite simple. All we need to do is add the -WhatIf parameter at the end of the PowerShell command.

For example: In case we what to test what will happen if we use the PowerShell command that will provide Alice, Full Access permission to all of the existing mailboxes, we can test the command by using the -WhatIf parameter.

Get-Mailbox | Add-MailboxPermission -User Alice -AccessRights FullAccess -WhatIf

When we run the PowerShell command, the “possible results” will be displayed on the screen. It’s important to emphasize that when we use the -WhatIf parameter, the operation will not be executed (the mailbox permission will not be assigned) but instead, the result display “what could have happened” if the PowerShell command was executed.

Assign permission, Objects, Array, Filtered lists and groups

Basic terms of the PowerShell environment

Before we start with the “hands on” code samples, it’s important that we take some time to understand a few PowerShell terms and concepts.

Object – In the PowerShell the term “object” is a very wide term. We can use the term object for describing a user, mailbox, group, or even folder.

Array – the term array is not so clear sometimes. We use the term “array” for describing a collection (more than one) object. The simplest example of the term array could be the result of the PowerShell cmdlets: Get-Mailbox

When we type in the PowerShell console, the Get-Mailbox and press the ENTER key, we execute a task in which the PowerShell connects the Exchange Online server, create a query that asks for information about all the existing mailboxes and displays the results on the screen. We can say that the displayed results could described as “Array of mailboxes.”

Group – we can relate to the term “group” also as a type of array. A group is a collection of one or more users. (Technically we can create an empty group, but without any users, the group has no use).

We use the group for two primary purposes: distribution group for “groping a list of users” for optimizing the task of sending mail to a group of recipients and Security group for providing permission to a “group” of users instead of providing permission to each of the users separately.

Just to confuse you a little more, we can define a security group also as a Distribution group. The term that we use in this scenario is Mail-enabled security group.

Filtered list – the term filtered list used for describing an array of objects (most of the time because sometimes the results of a filter list could be a single object). The obvious question could be: why to use a different term if we can use the term “Array”?

The answer is that the term Filtered list, is a little different. The use of Filtered list (as the name Implies (is when we need to “pull out” a particular object that has a common charter.

There could be many examples for this requirement such as: Get a list of all the User mailboxes (in Exchange environment, there are additional type of mailboxes such as shared mailbox, room mailbox, etc.), get a list of all the users who have the rule of a global administrator, get a list of all users who have a specific domain name suffix, get a list of all the users who work in the marketing department and so on.

Later in this article, we will review a couple of examples for the use of the Filtered list, and we will also review that use of a Filtered list that stored in a file (instead of using PowerShell command that creates the Filtered list).

PowerShell cmdlets for: creating a filtered list

The PowerShell environment includes two cmdlets that enable us to filter object that has a specific charter form the array of objects:

The PowerShell Where cmdlets and the PowerShell cmdlets: Filter .

Each of these cmdlets, have unique syntax and besides of the different syntax, there is additional difference between the Filter cmdlets and the Where cmdlets.

In the current article, we will not provide a detailed description of the difference between the two cmdlets, but it’s important to emphasize the main difference between this two cmdlets.

When using the Filter cmdlets for filtering information from an array of objects the “filter” is created on the server side (Exchange Online on our case). When using the Where cmdlets for filtering information, the filter is created on the client side (the desktop in which we use the PowerShell console).

In the Office 365 environment, there is an advantage for using the Filter cmdlets because Exchange Online, use a throttling policy which restricts the amount of data that can be sent to the client. The disadvantage of the Filter cmdlets is that not all the PowerShell cmdlets support the use of the Filter cmdlets.

In the following section, we will demonstrate how to filter information by using the Filter cmdlets. When using a Filter cmdlets, we will need to provide the following parameters:

  • The object type (user, group, mailbox, etc.)
  • The logic operator value such as: equal, grater, etc.
  • The value that we look for ( the common character)

An example for the use of a filter ( for creating a filtered list ) could be a scenario in which we want to assign a mailbox permission to a user with an array of mailboxes but only to mailboxes that define as a user mailbox.

To be able to “pull out” this mailbox from the array of all the mailboxes, we can use the following syntax.

Get-Mailbox Filter {(RecipientTypeDetails -eq 'UserMailbox')}

Another example could be a scenario in which we want to get a list of users but, only users who work in the sealed department.
To be able to “pull out” this mailbox from the array of all the mailboxes, we can use the following syntax.

Get-User Filter {(Department -eq "Sales")}

Assigning permissions options and concepts

Scenario 1: Assign permissions to object on another object

The most basic example could be providing mailbox permission to object A on Object B. For example, providing mailbox permission to Alice (user object) on a John mailbox (user object).

Assign permissions to object on other object-01

Another example could be: providing mailbox permission for a Security group (Group object) on another object such as John’s mailbox. It’s important to notice that the PowerShell environment relates to a Security group as “object” that could have permission on another object because Security group is a security object. Although the security group is a collection of one or more users, PowerShell relates to the Security group as a single entity that could have permissions on other objects such as a user.

Scenario 2: Assign permissions to object on a Collection\Group of objects

Another common scenario is when we want to assign permissions to object (such as a user) on a Collection\Group of objects. For example, we want to assign to a specific user, mailbox permissions, to all the mailboxes (collection of mailboxes).

Luckily, the PowerShell environment enables us to implement this task very easily by using the pipe (“|”) character.

Assign permissions to object on a Collection-Group of objects-02

The PowerShell sentence begins with a command that will create a list object. In our example, a collection of all the mailboxes (later on we will review different option for creating a custom list of objects based on a filter that we will define). The simplest option is using the PowerShell cmdlets: Get-Mailbox

We position the pipe (“|”) character after the Get-Mailbox cmdlets. By doing so, we are telling PowerShell that the next part of the PowerShell sentence will be applied to each of the members in the list (or array) that what created by using the Get-Mailbox cmdlets.

In our example, we use the Add-MailboxPermission cmdlets for providing Alice a Full Access mailbox permission for all the mailboxes.

Assign permissions to object on a Collection-Group of objects-02A

When we use the pipe cutters, the PowerShell is smart enough to understand that we want to provide the mailbox permission for each of the mailboxes that included in the array that created when we use the PowerShell cmdlets: Get-Mailbox

The PowerShell sentence that we write is:

Get-Mailbox | Add-MailboxPermission -User "Alice" -AccessRights FullAccess

Let’s review a variety of this scenario vs. the former scenario. We want to provide all of the users access to Alice’s mailbox. Based on the logic of the former scenario, all we need to define the array of mailboxes by using a command such as: Get-Mailbox and provide the “collection of mailboxes” the required permission to Alice’s mailbox.

The less good news is that in this scenario, we cannot use the simple option of the pipe character. In this case, the PowerShell is not smart enough to understand that we want to provide the mailbox permission for each of the mailboxes that included in the array to the user mailbox. To be able to accomplish this task, we will need to use an additional PowerShell cmdlets named: Foreach

The PowerShell cmdlets Foreach enables us to loop through – and perform an action on – each item in a collection (all of the users who include in the array that is created when using the command Get-Mailbox.

In simple words: the PowerShell cmdlets Foreach we scan all the members in the list (all of the mailboxes that include in the array) and start to provide the required permission separately for each of the mailboxes.

For example: in case that the Get-Mailbox output will include a list of 20 mailboxes, the PowerShell cmdlets Foreach will run 20 times.

Assign permissions to object on a Collection-Group of objects-02B

Providing permission for each of the group members

Additional scenario in which we will need to use the PowerShell cmdlets Foreach is when we want to provide a permit for each of a group’s members.

The PowerShell environment enables us to provide a permit to a Security group on another user’s mailbox.
We cannot assign a user’s mailbox permission to a security group, and we cannot assign permission to a Distribution group of a user’s mailbox. To overcome this limitation, we will need to use PowerShell cmdlets Foreach for “extracting” the content that we get from a list of mailboxes, so we can relate separately to each of the user\mailbox options separately instead of relating to a group object.

I know that at this stage all of this description sound a little bit confusing, but if you have patience, I will become clearer later.

Scenario 3: Assign permissions to Collection\Group of objects on a Collection/Group of objects

This scenario is less common but still, there will be times when we need to use this option and additionally by getting to know this kind of scenarios, we will learn additional aspects of the PowerShell sentence logic that will enable us to deal with other or variations of this scenario.
Assign permissions to Collection -Group of objects on a Collection -Group of Objects 03

To implement this scenario, we will need to use the PowerShell cmdlets Foreach twice. The first time that we use the PowerShell cmdlets Foreach is for extracting the members in a group (or a filtered list), and the second time is for extracting the group members from the “destination group” (the group that includes the members whom we will like to assign permissions to their mailboxes).

In the next article, we will look into Full Access Mailbox permission – Everything You Always Wanted to Know About But Were Afraid to Ask part 2/3.

The o365info Team

The o365info Team

This article was written by our team of experienced IT architects, consultants, and engineers.

This Post Has 2 Comments

  1. thanks for this information!


    Is it possible to use a distribution group / security group for Full Access permissions on one of our room resources ?


    I can only find information on adding individual users

Leave a Reply

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