Exchange Sustained Engineering (Exchange SE) recently fixed a problem regarding “Send As” permissions and “Full Mailbox Access” permissions. Up until now, “Full Mailbox Access” permissions had be...
Updated Jul 01, 2019
Version 2.0
Blog Post
6 MIN READ
BlackBerry and GoodLink users may be unable to send messages after applying latest Exchange 2003 store hotfixes
Thanks for the info Paul.
Hasn't this been something that has switched back and forth a couple of times with E2K as well? I seem to recall running into issues depending on what QFE levels of Exchange was running.
Overall this is an area, permissions, that has been one of much issue for nearly everyone trying to work out minimum permissions properly since Exchange related permissions are stored in at least four places. The config container perms which eventually gets mapped/copied to the msExchMailboxSecurityDescriptor, the domain NC permissions (such as Send As), the publicDelegates attribute, and the actual MAPI folder "attributes" aka permissions in the mailbox folders themselves.
I realize that some of it is for backwards compatability but I would rather see interfaces that thunk the old mechanisms up to new mechanisms and publish some new consistent mechanisms that people can start using. Permissioning shouldn't be this difficult and it is why so many people screw it up or don't have any permissions in place really at all (another form of screwing it up but they don't know until someone does something bad).
While I am at it, the whole trying to segregate and delegate Exchange perms when you have separation of duties is a train wreck as well. I spent weeks in a lab with some good Enterprise level MCS folks trying to work out good minimal perms for Exchange admins that followed good AD best practices for ACLs as well and was unsuccessful at hitting our goals. In the end, we had to give up and allow the Exchange admins more rights than they should have instead of populate AD with a ton of deny ACEs which would have just bloated the 2K DIT and slowed things down due to all the ACEs. Of course that does nothing to help the extra permissions that Exchange admins can also grant themselves by assuming localsystem on an Exchange server and going off doing things (say like adding themselves to the same groups the Exchange servers are in). If I knew then what I know now, there would have been no way Exchange would have been in the main production AD, it would have been in a single domain resource forest.
Anyway, sorry to rant, I didn't intend to. I would like to see this stuff addressed in E12. I don't expect much of a change but I would really hope to see it.
Hasn't this been something that has switched back and forth a couple of times with E2K as well? I seem to recall running into issues depending on what QFE levels of Exchange was running.
Overall this is an area, permissions, that has been one of much issue for nearly everyone trying to work out minimum permissions properly since Exchange related permissions are stored in at least four places. The config container perms which eventually gets mapped/copied to the msExchMailboxSecurityDescriptor, the domain NC permissions (such as Send As), the publicDelegates attribute, and the actual MAPI folder "attributes" aka permissions in the mailbox folders themselves.
I realize that some of it is for backwards compatability but I would rather see interfaces that thunk the old mechanisms up to new mechanisms and publish some new consistent mechanisms that people can start using. Permissioning shouldn't be this difficult and it is why so many people screw it up or don't have any permissions in place really at all (another form of screwing it up but they don't know until someone does something bad).
While I am at it, the whole trying to segregate and delegate Exchange perms when you have separation of duties is a train wreck as well. I spent weeks in a lab with some good Enterprise level MCS folks trying to work out good minimal perms for Exchange admins that followed good AD best practices for ACLs as well and was unsuccessful at hitting our goals. In the end, we had to give up and allow the Exchange admins more rights than they should have instead of populate AD with a ton of deny ACEs which would have just bloated the 2K DIT and slowed things down due to all the ACEs. Of course that does nothing to help the extra permissions that Exchange admins can also grant themselves by assuming localsystem on an Exchange server and going off doing things (say like adding themselves to the same groups the Exchange servers are in). If I knew then what I know now, there would have been no way Exchange would have been in the main production AD, it would have been in a single domain resource forest.
Anyway, sorry to rant, I didn't intend to. I would like to see this stuff addressed in E12. I don't expect much of a change but I would really hope to see it.