You didn't mention which version of Exchange Server you are running, but I'll assume it's either Exchange 2000 or Exchange 2003. You'll want to read the following article for a resolution: Microsoft Knowledge Base article 895949: "Send As permission behavior change in Exchange 2003." You want to set up your group with "Send As" permissions to the shared mailbox.
This user was referred to a Microsoft KB article that didn't really answer their question.
The KB article explained that a fix had been released that alters the "Send As" feature and that "Prior to this change, any user with the 'Full Mailbox Access' permission for a mailbox also had the ability to 'Send As' the mailbox owner." And now with the fix (update), a person with full mailbox rights does not automatically receive the right to "send as" the user.
You can't nest a Global Group into a Local Group and then grant the Local Group Full Mailbox Access and expect the permissions to work. At least that's what I've found from my personal experience. We have only been able to grant Full Mailbox Access to Global Groups and have the permissions work.
Come to think of it, my Global Group is mail-enabled and my Local Group is not, maybe that's why my nesting didn't work. But why should I have to have both a Global Group and a Local Group mail-enabled and both be in the GAL? That wouldn't make sense.
Also, the solution provided in the article to grant a group "Send As" permissions didn't work for me. I'm running Exchange 2003 Enterprise Edition and when you select the General tab (from ADUC), then select Delivery Options, and then select the Send on Behalf location, it only allows you to select user objects and not a global or local group (mail-enabled or not). Am I missing something here?
Could you please revisit this topic and give more explanation as to your solution.
The user I was responding to didn't specify which version of Exchange Server they were running, and the KB article I pointed them to was one that Microsoft had recently been getting a lot of attention on due to the change introduced in Exchange 2003 SP1 and SP2 post-fixes. Without the user providing further details, we're all just speculating on whether this solved their problem or not. Knowing which version of Exchange Server they're running and whether or not the said hotfixes are installed would be a start.
On that note, I just want to remind everyone writing in how important it is to provide *a lot* of detail when posing your questions. Questions such as "I'm getting a 5.7.1 error saying 'you do not have sufficient permissions to send to this recipient'" or something along those lines could end up having literally hundreds of proper answers depending on many other variables. As I've stated in the past, it's really critical that you write in with the following information as a minimum:
- What version of Exchange Server are you running?
- What service packs and/or hotfixes have you applied?
- If a problem has recently started occurring, what has changed on the server or in the environment recently?
- Is a problem reproducible? If so, what are the reproducible steps?
- What other third-party applications are installed on the server (notably antivirus, monitoring agents, etc.)?
- What are the Event ID, description and source of notable errors or warnings in the application event log at the time of the incident?
The degree to which I -- or any experts on SearchExchange.com for that matter -- can provide quality answers that are actually relevant to the original poster's scenario is often directly proportional to the amount of detail provided in the questions.
And, in response to your concern about the Knowledge Base article not working for you -- all I can suggest is that you open a support case with Microsoft and express your concern, or post a suggestion to the Microsoft newsgroups with a title such as "Error in KB Article 895949??" Either will get the attention of the Microsoft user education team and they can verify whether or not there is something which needs to be changed in the KB. I'm not with Microsoft, so can't verify that.
And one final tip... keep in mind that the Exchange Information Store Service (MSExchangeIS) applies permission changes with a two hour lag. So you need to wait two hours (or restart the MSExchangeIS) to confirm whether or not ACL changes are propagated properly.
I hope this helps.
—David Sengupta, Server Administration Expert
Do you have comments on this Ask the Expert Q&A? Let us know.
Related information from SearchExchange.com: