Messaging and Colloboration

Thursday, 21 July 2016

Mailbox Permissions


Mailbox Permissions:
Exchange enables us to assign different levels of control over mailboxes. Exchange has three mailbox permission types under Mailbox Delegations,
  •  Send On Behalf Of
  • Send AS
  • Full Access

Send On Behalf Of:

You can grant someone else to send emails on behalf of you. The delivered email item clearly mentions that the mail has been sent by delegates on behalf of you.

Send As:
‘Send As’ permission will enable you to impersonate other people; it doesn’t have any tag like ‘send on behalf of’. If you have ‘Send As’ permission for others mailbox, then you can send emails by their name, by choosing ‘From’ option while composing emails. This permission works well with ‘Shared Mailboxes’.

Full Access:
Full access permission enables you to grant access to other person’s mailbox or any folders on their mailbox, the only thing is you should have mail-enabled windows user account. Also it has some limitations like you can’t send emails like ‘Send as’. Full Access means full access to complete mailbox.

Comparisons of various permission types
Send On Behalf Of
Send As
Full Access
Delivered email has tag like ‘on behalf of ‘
No tags like ‘send on behalf of’
Can’t send emails when having full access permission alone.
Behind the scene, ‘Send on behalf of’ feature requires Exchange to transport some additional information in message headers, so that recipients can identify the original sender.
‘Send as’ feature requires a user to possess Active Directory permissions to impersonate some else.
When EAC assigns ‘Full Access’ permission, it uses fully distinguished name of the mailbox, but when granting permission via EMS, we can use any identifiers like display name, email address etc.,
Set-Mailbox –Identity  “dbabu” –GrantSendOnBehalfTo “vkarthick”

The above cmdlet grant permission to vkarthick to send emails on behalf of dbabu.
For ‘Send As’ permission we need to manipulate windows permission rather than Exchange property.

Add-ADPermission –Identity “Helpdesk” –ExtendedRights “SendAs” –user “user1”

The above cmdlet assigns ‘send as’ permissions for the “Helpdesk” account to “user1” mailbox

Note: use windows account name instead of Exchange display name.
Add-MailboxPermission –Identity “sharedmx” –user “user1” –AccessRights “FullAccess”

Above cmdlet assigns full access permission to user1 mailbox against ‘sharedmx’ mailbox.

How long it will take to apply permission changes?
Sometimes people can send emails immediately after administrator grant ‘send as’ permission to other mailbox, sometimes people complaining , still they can’t send emails by others name. It’s all because of MSExchange Information Store Cache.

Normally it will take upto an hour or more than an hour to apply the ‘Send as’ or ‘Full Access ‘permission changes. Actually we are applying some changes to the user object in Active Directory, Exchange have to query Active Directory for the changes, also that changes can’t be immediately available for Exchange server. By using ADAccess component Exchange query’s Active Directory in a regular interval of time to get the updated content and caches those changes in it for a certain period of time. This cache is commonly called as Mailbox Information cache (MBI) and how long the content should be available on MBI cache should be determined by the parameter ‘Mailbox cache Age Limit’, default value is 120 mins(2hours).‘Send as/Full Access’ permission changes will apply once MBI cache refreshes itself.

How to avoid complaints from users?
It clearly understood that ‘Mailbox Cache Age Limit’ is responsible for delays.
1. Restart the Information Store service - but it’s not a good practice because it forces all clients to disconnect.
2. Reduce the MBI Cache refreshing time from 2 hours to 30/20 minutes, but it’s also not advisable.
The best practice is to allow the Exchange server to take its own time to apply the changes.
Mailbox Auto Mapping:
Consider the scenario where the user is granted full access to other user’s mailbox, then during Auto Discover process, it brings user’s own mailbox plus additional mailboxes where using is having full access. Basically Auto Discover process query active directory to find whether the account (base) it’s running has access to any additional mailboxes. This is done by looking a user property called “MSExchDelegateLinkList” in Active Directory. 

If user is having access to other mailboxes, then Auto Discover manifest should have xml snippet like this
<AlternativeMailbox>
            <Type>Delegate</Type>
            <DisplayName>Teamexchange</DisplayName>
            <SMTPAddress>teamexchange@ucpro.in</SMTPAddress>
</AlternativeMailbox>
Sometime users don’t want to show their additional mailboxes in outlook, in that situation we can disable auto mapping functionality using Add-MailboxPermission cmdlet,

Add-MailboxPermission – Identity “TeamExchange” –user “Dinesh” –AccessRights ‘Full Access’  -AutoMapping: $False

Abbreviations used:
EAC – Exchange Control Panel
EMS – Exchange Management Shell
MBI Cache – Mailbox Information Cache

No comments:

Post a Comment