It is sometimes desirable to grant Send on Behalf permissions in Exchange for users who are accessing another mailbox in order to reply to email messages. Some typical scenarios for this may include a personal assistant who manages a company directors mailbox, a group of users who manage a central support mailbox or for ad-hoc scenarios, such as when a colleague is out of the office. Send on Behalf permissions provide the best level of courtesy when responding to an email by letting the person know that someone else is answering an email addressed to an individual, and I would say it is generally the more recommended approach compared to granting Send As permission.
Within Office 365/Exchange Online, we can very easily grant Send on Behalf permissions for a standard user mailbox (i.e. a user that has been granted an Exchange license on the Office 365 portal) via the user interface; just go into the mailbox in question, navigate to mailbox delegation and then simply add in the users who need the required permissions:
Then, give it twenty minutes or so and then the user can then send as this user from the From field in Outlook successfully - nice and easy, just the way we like it 🙂
But what happens if we wanted to grant the very same permissions for a shared mailbox? Say that we had an IT support help desk with a shared mailbox that several different users need Send on Behalf permissions for. Within the Office 365 GUI interface, we have options only to grant Send As and Full Access permissions:
So, in order to accomplish our objective in this instance, we need to look at going down the PowerShell route. Microsoft enables administrators to connect to their Office 365 tenant via a PowerShell command. This will then let you perform pretty much everything that you can achieve via the user interface, as well as a few additional commands not available by default - as you may have already guessed, granting Send on Behalf permissions for a shared mailbox is one of those things.
Microsoft have devoted a number of TechNet articles to the subject, and the one found here is an excellent starting point to get you up and running. The salient points from this article are summarised below:
- Ensure that the latest versions .NET Framework and Windows PowerShell are installed on your 64 bit Windows machine. These can be added via the Turn Windows features On or Off screen, which can be accessed via the search box on your Windows Start Menu or in Control Panel -> Programs and Features -> Turn Windows features On or Off,
- Download and install the Microsoft Online Services Sign-In Assistant
- Download and run the Azure Active Directory Module for Windows PowerShell
Once you’ve got everything setup, open up PowerShell and run the following script, altering where appropriate to suit your requirements/environment:
# Remove result limits due to console truncation
$FormatEnumerationLimit=-1
# Connect to Office 365. When prompted, login in with MSO credentials
Set-ExecutionPolicy Unrestricted -Force
Import-Module MSOnline
$O365Cred = Get-Credential
$O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
Import-PSSession $O365Session -AllowClobber
Connect-MsolService –Credential $O365Cred
# Add additonal users to Send on Behalf permissions for mailbox. add= list if a comma seperate list. Each email address should be in double quoted brackets
Set-mailbox 'MySharedMailbox' –Grantsendonbehalfto @{add="[email protected]"}
# Confirm that user has been succesfully added to send on behalf permissions for mailbox
Get-Mailbox 'MySharedMailbox' | ft Name,grantsendonbehalfto -wrap
# Display exit script (to keep window open in order to view the above)
Read-Host -Prompt "Press Enter to exit"
The nice thing about this code snippet is that you can grant multiple users Send on Behalf permissions at the same time, which is really handy.
Based on my experience, the above has been a pretty regular request that has come through via support in the past. I am unsure whether this is common across different organisations or not; if it is, then I am really surprised that the Office 365 interface has not been updated accordingly. The important thing is that we can ultimately do this in Office 365, as you would expect via an on-premise Exchange Server. As such, organisations can be assured that if they are planning a migration onto Office 365 in the near future, they won’t be losing out feature-wise as a result of moving to the platform. And, finally, it is always good to learn about something new, like PowerShell, so we can also say that we’ve broadened our knowledge by completing the above 😉