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.

Conrad Murray

Conrad Murray has been working in IT for over 15 years specializing in the Messaging Arena and in particular IBM Domino and Microsoft Exchange and now of course Office 365. Working with like minded colleagues now specializing in very large scale complex migrations from Lotus Notes and On-Premise Microsoft Exchange to Office 365.

This Post Has 14 Comments

  1. What if a group has full access and a user within that group then has reviewer access to the top information store folder, do they end up with only reviewer access to the inbox or full access to the inbox?

    1. Hi, actually not sure if I detailed that here on in another blog, but mixing permissions and also mixing Send on Behalf of and SendAs never goes well. I have seen mixed behaviour depending on the version of Outlook and Exchange.

      Now, for your question I’m not 100% sure, would need to be tested. I assume that Reviewer is either being granted by the Mailbox Owner delegated through the Outlook delegation wizard? (how are they doing this for a Shared Mailbox, are they creating a dedicated Outlook profile) or are you saying someone is adding Reviewer to the root folder by Right Clicking and adding? (my guess this question has arisen becuase you want to change your delegtaion model and are worrying about the knock on affect?)

      Mailbox permissions don’t cascade like NTFS style folder Persmissions with Automatic Inheritance so Reviewer won’t flow to the Inbox. If you look at this blog: https://www.neroblanco.co.uk/2017/07/outlook-personal-mailbox-delegation-wizard-ins-outs/ you will see taht I advise users that use Outlook Delegation for their own Inbox, even using EDITOR, will alos need to grant at least “Folder Visible” on the root folder and that does NOT affect the Inbox, Calendar etc.

      I’ll probably go off and test this myself shortly, but would be testing in Office 365.

        1. Maybe this information will be useful too in this case – we user enterprise office 365 exchange admin center. We use outlook 2016 on all employee pcs.
          We have an On Premises to exchange online organization relationship. And we have on-premises to O365. If any of this matters or makes sense. Just thought i would pass along.

          1. Are you in Hybrid as well. Is this normal Office 365 of Office 365 Dedicated (formerly known as BPOS-D). Dedicated had a different behaviour as it was essentially treated as a cross-forest relationship. We found that we actually had to grant SendAs and Send On Behalf of permissions to both the On-Premise and Cloud object and make sure that the leagcyExchangeDNs were sync’d in as x500 addresses in the proxyAddresses attribute.

      1. What would be the best practice if a company wants the exchange admin to control the access of a shared mailbox? The way it currently is – somebody in company requests a shared mailbox be created that certain people have access to this and should be able to reply or forward emails from the shared mailbox. Most of the time they want any reply’s or forwards or any emails created in the inbox to be sent with the send on behalf of permission. The intent is to create the shared mailbox but for the exchange admin to control the access so that not just anyone that has the full delegation access can also delegate others or also give access to the shared mailbox by using shared permission and folder permissions. Most of the time the people that have access to the mailbox are put in a ad group and then the group is assigned full access thru the mailbox delegation in the EAC.
        So my department is responsible for audits and we get many requests from auditors that want to know who has access to a certain shared mailbox and what type of access and do they have send as or send on behalf of. This information seems to be hard to decipher what was done because some groups may be assigned delegation of full access and send on behalf of. However I have also noticed that on top of that the exchange admin gives folder permissions of owner to the top level. Which to me would mean that anyone in that group would than own the shared mailbox and could delegate and give others shared permissions. So since I am providing the auditor this information I want to make sure they are getting the correct info. So for example, I ran my powershell script and looked at the delegation access in EAC. In EAC it assigned a group of users full access. But after running the script it also shows the same group has owner access to the mailbox. And some other group has reviewer access to the mailbox. So with the groups having the EAC delegation permission of Full and the shared folder access of owner or reviewer, what would the end result be for each group. What would be the best practice for a large company creating shared mailboxes be, With the exchange admin having the control over the access? The way it is set up is very confusing to me but I want to make sure I am not giving out wrong info to the auditor. Especially when the administrator says that only two people have actual access when I can prove and have tested that more than two people have access and at that they even have owner access. This is becoming very long but it is hard to explain but I hope you get the gist of what I am saying and can provide some suggestions as to best practice.

        Thank you

        1. Hi, well as per my blog we “Best Practice” is: Full Access + SendAs + Mailbox Auditing, and in fact in Office 365 that is the default, SendOnBehalfOf does not appear in the EAC GUI (only Full Access and SendAs are under mailbox delegeation. Any variation from this and you have a usability problem in Outlook generating umpteen helpdesk tickets especially depending on how users connect to it in Outlook. If you just grant Send on Behalf Of then you don’t even need to attach the Mailbox – you can just change the “From” option in the Outlook dropdown, but where does that Sent Item go? You need to configure it, otherwise it goes in the users’ own mailbox (and EXO and On-Premise treat that differently option differently). When you start having a mix of permissions you have Sent Item and Deleted item issues. With SendOnBehalf of the users have to remember to use the From Dropdown, even when they are in it (unless they attach it correctly in Outlook or have a dedicated profile to switch back and forth with)

          At the last very large Enterprise Deployment we delivereda solution, we actaully ended up writing a very large Shared Mailbox Request Portal with SQL backend that PowerShell scripts would use for all the requist information like Owners, Regions, Naming Convention, OUs etc. We also used to track the owner of a Shared Mailbox via the Owner attribute and also the Owner of the Full Access and SendAs Group. They had to have three users (to account for leavers). The Group Owner/Administrator could then control the access via the Group Membership. Users could NOT create dedicated Outlook profiles due to the way we GPO’d Outlook with the ZeroConfig option for the Outlook wizard, so Full Access people could not use the Outlook Delegation Wizard.

          Yes, I agree that they would be able to grant other folder permissions, but that does NOT flow through to SendAs or SendOnBehalfOf so those other people would only ever be able to “look” in the Mailbox. The Owner and Full Access attributes are different by the way, the Mailbox Owner attribute doesn’t do much compared to Full Access. Haven’t played much with giving Ownner permissions on the Root, but that would only let the user attach the mailbox and as the permissions are not cascaded I’m not sure that would even allo them to then given themselves access to sub-folders?

          For your Audit I would be treating:
          – SendAs and SendOnBehalfOf as different reports
          – Full Access as a different Report
          – MailboxFolderPermissions as a different report

          Simply becuase users could have only one of the above, or a combination of all 4. e.g you can have FULL ACCESS but not the ability to Send and vice versa.

          Granting Exchange FULL ACCESS would trump all other folder permissions I think (not 100% sure, that is not a mix I have ever tested). FULL ACCESS allows you to see all folders and content. A users could be cranted all manner of varying Foldder Permissions and that is the nature of the beast, e.g. of my 100s of Folders I could share just one of my folders to a collegaue “Project X” and nothing eles, so like i say your reports would need to account for that, but I would mainatin that having OWNER Access on the Root and Inbox, does not mean a user could elevate their permissions on my sub folder “Project X” – again, never tested.

          Hope that helps, Conrad

          1. I apologize for all the questions. You have been very helpful. I was wondering if a group has send as and a person within that group also has send on behalf of permissions, does the Send As override the Send on behalf of?
            What if only a few people are supposed to have “Send On Behalf of” out of a group that has been delegated “Send As” permissions. How is this accomplished? Do you have to remove the people that need Send on Behalf of from the group?

            Thanks

          2. If you use a mixture of SendAs and Send on Behalf of you will get a mixed outcome depending on versions of Exchange and Outlook. This is one of the reasons we moved away from it.

            Note that SendAs is an AD permission Send on Behalf if is an Exchange Mailbox Permission.

            Now, with pure Office 365 and Outlook 2016 I would expect SendAs to trump Send on Behalf of – but I don’t know for sure as it has been a while since we encountered this.

            Also, often where this does manifest itself is delegation of an normal Owner mailbox in a ‘Boss/Admin’ relationship, because the owner may have delegated their mailbox, before or after the SendAs is granted by an Administrator.

            The downside of Full Access plus SendAs is that it has to be set by an Exchange Admin. A user cannot do this. Also, SendAs means that the recipient (and an Auditor) cannot easily see the true sender of the email, this is why we say set Mailbox Auditing. Interestingly this is partially now on by default in Office 365 and does not have to be set manually now. Although for mailboxes created previously you would have to set it.

            Enable mailbox auditing in Office 365
            https://docs.microsoft.com/en-us/office365/securitycompliance/enable-mailbox-auditing?redirectSourcePath=%252fen-us%252farticle%252fenable-mailbox-auditing-in-office-365-aaca8987-5b62-458b-9882-c28476a66918

  2. Here is just one example.Say the mailbox name is “Sample Mailbox”. Full access was given to Security Group (lets say named ACL-sample-Fullaccess). In “ACL-Fullaccess” security group on the members tab another Security Group is added, lets say “GRP-sample shared mailbox users”. If you open the “GRP-sample shared mailbox users” there are about 7 AD User accounts added to the members tab. So with this layout, I am assuming it trickles down and the 7 users have Full Access to the “Sample Mailbox”. Then if you look at the group that was given full access in EAC (“ACL-sample-fullaccess”) and pull that group up in AD, on the Managed By tab it lists a group that includes the exchange admin. So now, if a run a powershell script to show what permissions are assigned to sample mailbox, It says “fullAccess” to ACL-sample-Fullaccess. And it says FolderName: Top of Information Store has Access Rights of Owner which is assigned to another group, lets say “GRP-Samplesharedmailbox-owner” that has 2 other people in that AD Group listed that are not in any of the previous groups mentioned. So now, who are the actual owners. Is what was listed on the Managed By tab in the ACL-sample-Fullaccess security group (which exchange admin is listed) the owner of this share mailbox, or is the 2 people in the security group GRP-Samplesharedmailbox-owner that are the owners. Can you see why I am soooo confused. And our employees do not know enough about shared mailbox folder permissions to have do anything themselves. Is it possible that the exchange admin assigned the folder permission of owner to that group?

    And, from what you said when you tested the reviewer and full access thing, Full access must override any folder permissions at the root then? Am I understanding the correctly?

    I am soooo sorry for all this back in fourth. But you have been a tremendous help in me understanding all this. I am thinking the way that our shared mailboxes was set up is completely messed up and was not done by best practice.

    Thank you

    1. OK, it depends on what you define as Owner, there is no Owner attribute on a Mailbox. There is Owner only of Folders and you can’t really do much within reason except mess with data in that folder, create sub folders etc. As such, there is not an “Owner” of a Mailbox, without drifting into “Self” AD Permissions. For Users Mailboxes it is safe to assume that the Owner is the AD Account and primary address associated with it to whom it is licensed. So ownership of Shared Mailboxes is more of a process driven logical decision. We always use the Managers of the Full Access Group assigned to that Shared Mailbox are the true owner. For “Owner” ask yourself this, if no one sent or received an email from that nailbox in 12 months, who would you contact to approve it’s deletion/or archive?

      Now, at the enterprise client mentioned in my other response we had political restrictions on granting Full Access and SendAs in certain geo / project circumstances so we went with the following groups (I think from memory) with appropriate naming convention where the mailbox is named in the group:
      – Full Access
      – SendAs
      – Send on Behalf Of

      E.g
      SMBX-SampleMailboxt-FA
      SMBX-SampleMailbox-SA
      SMBX-SampleMailbox-SOBO

      Users could NOT be in both of the last two groups. I think we actually had a daily script that checked for the presence.

      This method of course creates 3 groups per shared mailbox in your AD. In the Group we also used an extensionAttribute to reference it back to the Shared Mailbox name so we could see if the SMBX got deleted, the Groups could then also be deleted. And, if the Owners of the Full Access Group (ergo the Mailbox owner) fell below three we could contact them. We used the an attribute I can’t think of right now that is a multi-value attribute to capture the three owners. You could probably also conclude the Members of teh Full Access Groups are owners, but perhaps not able to make a decision whether to delete it or not. Project X could have had 10 people on teh gig all in that group, but they are not necessarily well placed to decide the future of that mailbox.

      That is possibly overkill and that whole side project took MONTHS to get right as well as the front end portal request system – but when it was done, it was cool.

      So in your case I would:
      – Remove any individuals that have access and put them into groups
      – only use Groups (never individuals) to grant access so that -auto mapping is not invoked (that caused more problems than it solves)
      – Have a Full Access ONLY Group. You can deem the members to be the Owners
      – Have separate SendAs and Send on Behalf of Groups (decide on managers of these groups)
      – Consider how the mailbox owner(s) can self manage the groups
      – Enable mailbox auditing
      – have a ‘one pager’ on your intranet or that can be emailed to New shared mailbox requestors on how to attach and use a SMBX

      Are your Full Access users sharing out ad-hoc Folders for a reason? Get them to stop doing that unless there is a very good reason for sharing a specific folder with someone – don’t do it. I like classic working myself, but have you considered Microsoft Teams?

      If you do all that, have the users create new Outlook profiles if something is still wrong.

      What my colleague Twan (check out his awesome blogs on here) did in the last year at one of our current clients is to run a script to parse out all the access on shared mailboxes and extract the delegates (individuals and groups) and remove all the send on behalf of and replace with Mail enabled Security Groups (hidden form the GAL) with Full Access and SendAs. I think we added the groups before a period of time passed to remove the legacy individuals and bad groups.

      By the way I’m not dead set against using Send on Behalf of completely, but it does require a certain level of IT Maturity from the Mailbox owner and the Delegate how to use it, and what their expectations are. If they want to be able to file and see all folders (lets face it, there could be 100s for the new joiner) and set Out of Office and Rules and so on, then they need Full Access. If they have Full Access, they might as well have SendAs (with auditing). Send on Behalf of for me should be relegated to casual delegation of your own mailbox for say a PA managing a calendar (IMHO)

      One other issue is to be aware of PAs / users that have been granted access to ‘many’ mailboxes. They can end up with a huge OST depending on how they connect and performance issues depending on how they cache.

      With Full Access and Send on behalf of there is also a ‘known issue / working as intended’ issue in Outlook with Office 365 whereby a user cannot add the Shared Mailbox as an Extra Account in Outlook as it caused email to fail to send. They HAD to use the additional account option which means they have to use the FROM option, and often users simply forget to do this.

Leave a Reply

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

Search