Microsoft Exchange Server 2013 : Mailbox management - Setting mailbox permissions (part 2) - Managing Full Access permission

Managing Full Access permission

Assigning Send As permission for a mailbox enables a user to impersonate someone else, but apart from being able to create and send messages, the Send As permission does not grant any further access to mailbox contents. You need Full Access permission to open a mailbox and peruse its contents. To assign Full Access to a mailbox, select the mailbox to which you want to assign permission and edit its properties. Open the Mailbox Delegation section (Figure 3) and scroll to the bottom part of the screen, where you can choose the accounts or groups that need the permission. Notice that the Exchange Servers and Exchange Trusted Subsystem groups are already included in the list of users and groups. This is to allow Exchange access to the discovery mailbox so that it can store search results in it.

Figure 3. Assigning Full Access permission for a mailbox

You can add the names of individual users or the names of security groups, whichever is the more convenient way to assign permissions to mailboxes that need to be shared. You cannot assign permissions to normal distribution groups or dynamic distribution groups because these groups do not possess a Windows security principal. After you’ve entered the full set of users and groups to receive Full Access, click Save.

If you set up additional discovery mailboxes, it’s likely that you will give them names that are a little less obscure than the default one Exchange creates and should therefore be easier to enter. In this example, assign Full Access permission for a new discovery mailbox to the members of the Discovery Management group with this command:

Add-MailboxPermission -Identity 'CN=Legal Action Discovery Mailbox'
-User 'Discovery Management' -AccessRights 'FullAccess'

When you assign permissions to multiple mailboxes or groups, you have to use multiple Add-MailboxPermission commands. After all the permissions are assigned, you can check the permissions on the mailbox as follows. This output shows what you expect. The Discovery Management group is in the list of permissions, and you can see that an account called LegalTeam has been assigned access also. A user who receives Full Access permission can then open the mailbox with Outlook Web App.

Get-Mailbox –Identity 'Legal Action Discovery Mailbox' | Get-MailboxPermission | ? {$_.AccessRights –Like "FullAccess"} 
| Sort-Object Deny | Format-Table User, AccessRights, Deny, IsInherited –AutoSize

User                               AccessRights   Deny    IsInherited
------                              -----------   ------  -----------
CONTOSO\Exchange Servers           {FullAccess}   False          True
CONTOSO\Discovery Management       {FullAccess}   False         False
CONTOSO\LegalTeam                  {FullAccess}   False         False
CONTOSO\Enterprise Admins          {FullAccess}   True           True
CONTOSO\Domain Admins              {FullAccess}   True           True
CONTOSO\Organization Management    {FullAccess}   True           True

Apart from the need to open and access content in discovery mailboxes, Full Access permission is commonly required in other scenarios such as when several users share a functional mailbox. For example, if you want to allow a group of users to open a mailbox belonging to a help desk so that they can see the problems and other issues reported to the help desk, you need to assign Full Access permission for the help desk mailbox to each user who needs access. Granting access to a group rather than individual user accounts makes this process a lot easier to manage.

Remember that the Information Store caches permissions for mailboxes to improve performance. This means that it could take up to an hour before a permission change to allow Full Access or Send As for a mailbox becomes effective. Unfortunately, there are only two ways around this problem. You can restart the Information Store service to force it to reload its cache, or you can reduce the interval the Store uses to reload its cache. The first solution forces all clients to disconnect and isn’t good to do during the working day; the second imposes an extra performance penalty on the server when it reloads the cache. Although some experienced administrators have reported good results when they reduced the logon cache interval to between 15 and 20 minutes, neither option is particularly attractive. The best idea might be to wait for Exchange to take its own good time to discover the amended permissions before attempting to use them—or, if possible, update permissions at a time such as midnight, when the delay enforced by caching won’t affect users.