CALL TO ACTION
A change in Exchange permissioning behavior may impact mobile communications and other add-on applications for Exchange. Shared and resource mailboxes may also be affe...
Updated Jul 01, 2019
Version 2.0
Blog Post
FYI - if for some reason your organization uses your user accounts as any of the built-in security group roles (I.E. They are in Domain Admins, Account Operators, etc...) they will break when this STORE update is applied even if you apply permissions to an OU.
Why? Because their permissions inheritence is turned off - and you cannot properly set "Send As" on the AdminSDHolder role (it is a container and not a user object, so the permissions don't match 100%). The only work around I have seen is to basically give the service accounts "full control" over the AdminSDHolder container.
More information can be found here:
http://support.microsoft.com/kb/817433/?sd=RMVP&fr=1
and here:
http://support.microsoft.com/kb/318180/en-us
The proper way to handle this is to NOT user your user mailbox/AD accounts as your administrator accounts. NOTE: if you do undo this at your organization - you will need to go turn permissions inheritence back on for your "cleaned up" users as removing them from the groups does not reset this.
Why? Because their permissions inheritence is turned off - and you cannot properly set "Send As" on the AdminSDHolder role (it is a container and not a user object, so the permissions don't match 100%). The only work around I have seen is to basically give the service accounts "full control" over the AdminSDHolder container.
More information can be found here:
http://support.microsoft.com/kb/817433/?sd=RMVP&fr=1
and here:
http://support.microsoft.com/kb/318180/en-us
The proper way to handle this is to NOT user your user mailbox/AD accounts as your administrator accounts. NOTE: if you do undo this at your organization - you will need to go turn permissions inheritence back on for your "cleaned up" users as removing them from the groups does not reset this.