The Shared Mailbox Dilemma

The Shared Mailbox Dilemma

Microsoft Teams (and Office 365 Groups) whilst having gained serious traction, and by serious – Teams has become Microsoft’s fastest growing App in their history. Shared Mailboxes still have a place in our heart and in the organisation for now, but inevitably they will perhaps fade away, maybe even email will too???

Exchange and Office 365 Shared mailboxes back in the day appeared to be the panacea to all our shared messaging needs, and in some respects they are – often considered as a valid replacement for Public Folders and they do give a genuine collaboration capability, but there are still some gotchas to take into consideration and definitely some advance planning required, particularly around the Security Access Model, Auditing and the actual sender style debate.

The Path of Least Resistance

Our best practice recommendations

For complete end-user ease and drastically reduced complexity and helpdesk calls, here is what we recommend:

• Give your end users FULL ACCESS with SendAs rights
  • Enable Mailbox auditing On-Premises (it’s on by default in Office 365)
• Grant Access via Email Enabled Security Groups
  • Grant the Shared Mailbox owners manager access to these groups
• If you must add users individually then ensure you use –AutoMapping $False
• Add Shared Mailboxes to the Outlook client using “New (Additional) Account”, not “Add additional mailbox”

Trust me, follow those simple 4 rules and you will be thanking me, one more thing for Office 365 users.

Office 365

If your users want to access Shared Mailboxes via the Outlook App on their phone or tablet then make sure that the Mailbox is an actual Shared Mailbox i.e. RecipientTypeDetails = SharedMailbox and is unlicensed, otherwise the App wont let you add a Shared Mailbox.

If you aren’t convinced or don’t want to follow our recommended best practice then…

Consider these points first:

What level of access should you give to the Shared Mailboxes?

• Full Access
• Editor Access
• Reviewer Access

Who should you grant the access to?

• Individuals or
• Groups

Sender Rights

• SendAs or
• Send on behalf of

Life Event Object Management

• Owners
• Decommissioning
• Renames

Outlook functionality like: Rules, Autoreply, Save Sent and Deleted Items

• Must have or
• nice to have

Decisions

In a very small, or even small/medium organisation, often these decisions are very straightforward. More often than not users are in close proximity or on first name basis with the IT Support Teams but for a larger or enterprise size organisations this is simply not practical.

Usually a documented ITIL process is required such as raising a Service Request via the Helpdesk to request a Shared mailbox, or to be given access to it. Sometimes there might even be a front-end style intranet portal to achieve this.

Understanding Access Levels

Full Access

Let’s take Full Access. This can ONLY be granted by an Exchange Administrator either at the Exchange Management Console / Exchange Admin Center or via PowerShell.  So this already generates costly Helpdesk Tickets but Full Access does give significantly more flexibility to your users in how they interact with the Shared Mailbox and if you have the right people and processes in place you can automate this process and in event.

Once a user with Full Access attaches to the Shared Mailbox in Outlook they are able to essentially do everything within it that they can do in their own mailbox “full functionality” if you will – depending on HOW they attach to it in Outlook.  More on this later.

Full Access Mailbox users can:

• See all the Folders and Sub-Folders
• Create Rules
• Set Out of Office
• Set Automatic Replies and
• Delegate to other users
• Grant Folder level Permissions
• Grant Send on Behalf of

Outlook Delegation Wizard

Editor Access (via Outlook Delegation Wizard)

Granting Editor Access can be done by any user that already has Full Access and has attached the Outlook Shared Mailbox in such a way that they can use the Outlook Delegation Wizard.

The Outlook Delegation wizard when granting Editor Access to the Calendar will also grant the use Send on Behalf of Rights.  The Mailbox Owner must also always remember to share out the Folder Root as at least Folder Visible otherwise delegates cannot add the mailbox to their own profile easily.

Using this method does mean that any Editor users/delegates of the Shared Mailbox can ONLY see the Inbox (Task, Calendar and Contacts) and no subfolders – which is often undesirable.  It would again require a Full Access user to diligently share each and every folder out to the additional users/delegates.

This cascading of permissions throughout the Shared Mailbox can be achieved via PowerShell Add-MailboxFolderPermissions – but again it is a task that can only be executed by an Exchange Administrator

Reviewer Access (via Outlook Delegation Wizard)

Much like above with Editor Access, granting Reviewer Access can be done by any user that already has Full Access and has attached the Outlook Shared Mailbox in such a way that they can use the Outlook Delegation Wizard.

Again a Mailbox Owner must also always remember to share out the Folder Root as at least Folder Visible otherwise users/delegates cannot add the mailbox to their own profile.

Again, using this method does mean that any Reviewer users/delegates of the Shared Mailbox can ONLY see the Inbox and no subfolders.  Per above. it would again require a Full Access user to diligently share each and every folder out to the additional users/delegates.

This cascading of permissions throughout the Shared Mailbox can be achieved via PowerShell Add-MailboxFolderPermissions – but again it is a task that can only be executed by an Exchange Administrator.

Individual v Groups

Who should you grant access to individuals or groups? Best practice would always say use a Group.  So let’s think about that.

In Exchange we can create Mail-Enabled Security Groups.  Users that are granted Manager Rights to a Group can edit the membership themselves either through the ECP when they are logged into OWA, (e.g. https://outlook.office365.com/ecp/  ) or even through Outlook by editing the Group properties.

Group Deployment Questions

• What OU will you create the Groups in?
• What naming convention will you give the Groups?
• How will you manage the Group Membership?
• How will you manage the Group life cycle?
• How will you define the owner of the Group?
  • Use the “Manage this Group” option in EAC?
• If you rename the Shared Mailbox, will you also rename the Group?
• If you delete the Shared Mailbox, will you remember to delete the Group?
• Do they need to be Mail-Enabled?
  • Yes for Office 365
• If they are Mail-Enabled Groups, will you hide them from the GAL or restrict who can send emails to the Groups
• Does your Information Security and Risk Management teams have a view on these Email-Enabled Security Groups?

Automation

At a previous On-Premise customer we actually designed and implemented a browser based front-end User Portal to create Resource Mailboxes and Shared Mailboxes.

We used a SQL back end, that PowerShell would interrogate on a schedule looking for new requests and automate the whole process including creating the necessary Security Groups plus three Owners for the Groups and the Mailboxes themselves.

Often the Owner of Groups and Mailboxes (usually the Project Sponsor or Business Unit leader) is not the same as the Administrator granting the actual access either.  Periodically the Owners of the Mailboxes and Groups would be emailed to confirm they still required the Resources.  If after 3 requests to flag it as still in use, it would be deleted.

We wanted to capture all this information on one go as well as the requestor and the actual owners to maintain the integrity of the lifecycle of these objects.

Often Organizations relocate and leave buildings thus the Rooms become redundant.  Much like Equipment, it breaks and depreciates.  Shared Mailboxes tend to have a life expectancy, especially project specific ones, and then these stale objects are just left hanging around cluttering up the place.

Sender Information

Send on Behalf of and Send As

Send on Behalf of and Send As are similar in fashion

Send On Behalf of

Send on Behalf will allow a user to send email from another user while showing the recipient that it was sent from a specific user on behalf of the Mailbox. What this means, is that the recipient is cognitive of who actually initiated the sending message, regardless of who it was sent on behalf of.

This may not be what you are looking to accomplish. In many cases, you may want to Send As another person or Shared Mailbox and you do not want the recipient to be cognitive about who initiated the message. If someone replies, it will go directly to the Shared Mailbox.

SendAs

It should be noted that Send As is essentially impersonation, so it is strongly advised to enable Exchange Mailbox Auditing so that you can track who actually sent emails:  https://technet.microsoft.com/en-GB/library/ff459237(v=exchg.150).aspx

Often organisations have an Information Security policy on the use of Send As.

Accessing a Shared Mailbox

Microsoft Outlook

In Microsoft Outlook there are potentially 4 different ways that you can access your shared mailbox

1. Open Other Users Folder

This method simply allows a user to see just a single folder.

2. Add Additional Mailbox

This method adds the Mailbox to your Outlook profile and is the legacy method used by previous versions of Outlook (2007 and prior).  The main issues with this method are:

• You can’t create Outlook Rules
• You can’t utilise Out of Office
• You can’t access Delegation
• You can’t create Custom Search Folders
• Sent and Deleted Items do not go into the Shared Mailbox (there are some workarounds for this)
• You need to always use the From button on the ribbon

3. Add additional Account

Using this modern method of connecting Outlook to a Shared Mailbox ensures that users can:

• Create and Manage Rules
• Set Automatic Replies
• Sent and Deleted Items are saved in the Shared Mailbox so other users can see them
• Shared Mailbox gets its own OST file with an OST slider option need to use the From option, providing they are in the Mailbox
• You do not need to use the FROM option if you are in the mailbox that you are sending from

4. Create an additional Outlook Profile

The use of a dedicated Outlook Profile NOT work for a user if they have the Group Policy Object that has the setting for Outlook ZeroConfig enabled.  Zero Configuration ensures that the Outlook Configuration auto-completes with zero user interaction and no screen prompts.  This is desirable in most cases, but when a user needs to manually configure Outlook to point at a different mailbox then this would not be possible as none of the configuration screens will appear.

Assuming that Outlook Zero Configuration is NOT enabled, then a user has a nicely logically separated secondary mailbox to work in without any confusion.  Of course it does also mean that users cannot work concurrently in multiple mailboxes.

A standalone Outlook Profile means that users can:

• Create and Manage Rules
• Set Automatic Replies
• Sent and Deleted Items are saved in the Shared Mailbox so other users can see them
• Shared Mailbox gets its own OST file with an OST slider option
• No need to use the FROM option, providing they are in the Mailbox

Outlook Web App

You can also open a Shared Mailbox in OWA – IF you have Full Access, and you know how to manipulate the URL. e.g. https://outlook.office365.com/owa/sharedmailboxname@yourdomain.co.uk

OWA does allow you to do certain things like create Server based Rules and set Out of Office / Auto Responses.  Plus obviously your Sent & Deleted items will be in the correct place.

Conclusion

In my personal opinion, for ease of use and manageability create a Mail-Enabled Security Group, put all users of the Shared Mailbox in that Group, and then grant that Security Group Full Access with SendAs rights. Enable Exchange Mailbox Auditing.

When granting Full Access do NOT use the -AutoMapping=$True as this will negate the ability for users to add to Outlook manually (that creates the dedicated OST file).  I do appreciate that the -AutoMapping feature is very convenient, but also doesn’t allow any granular management over the Outlook Client configuration.

On the Mail-Enabled Security Group in the Manage this Group settings list THREE users that will be known as the “Owners” of the Shared Mailbox and therefore have the ability to grant access by updating the Group and the “go to” people for queries.

Users / Delegates of the Shared Mailbox should then add the mailbox as an Additional (New) Account to their own profile this ensures that:

• They can use Rules
• Set Automatic Replies
• They can create Custom Search Folders
• Sent and Deleted Items are saved in the Shared Mailbox so other users can see them
• Shared Mailbox gets its own OST file with an OST slider option
• No need to use the From option, providing they are clicked in the right Mailbox

Lastly, for Office 365 Hybrid Deployments, always create the Shared Mailbox (and Rooms) On-Premise first then migrate it.  In this way the correct attributes are set on the AD object so that any users on Premise will see it listed correctly in the GAL.

*** Updated 26 May 2016 ***

One of the reasons that I had advocated the use if “Add Account” to add a mailbox to your profile was the unreliability of Save Sent items, and the fact that Microsoft had deprecated it after Exchange 2013 On-Premise and fully from office 365… well it looks like they have relented and brought it back.

https://blogs.technet.microsoft.com/exchange/2015/03/03/want-more-control-over-sent-items-when-using-shared-mailboxes/

https://support.microsoft.com/en-gb/kb/2843677

That said there are still many compelling reasons for using the “New (Additional) Account” method, plus the above requires Registry Key settings and clean-ups if you have used them, PowerShell configuration per mailbox and of course if you are in a Hybrid Environment or a Merger/Aquistion scenario you need to ensure a consistent experience across the board so users don’t get confused.

Updated 7 November 2019 to tidy up flow, spelling and other typos for clarity.