Well, This is a Fun Bug….

We received a report of bug which had supposedly been fixed in Exchange 2010 SP1, but which is apparently manifesting is the version we are currently running, Exchange 2010 SP2 RU6. We were able to confirm the existence of this bug by reproducing it. Description: This issue manifests with Outlook 2010 (and possibly 2007, but I have not tested this), if one has an Outlook profile configured with an online connection to Exchange and an additional mailbox connecting to an IMAP4 or POP3 server. (The specific examples we have encountered and reproduced are IMAP4 connections to Gmail.) Sending an email with an attachment from the Gmail account results in the send attempt failing, and the following error being thrown:

Task ‘<the POP3 account or the IMAP account> – Sending’ reported error (0X800CCC13): ‘Unable to connect to the network. Check your network connection or modem.’

Additionally, the message which failed to send ends up in the Outbox of the Exchange mailbox. It is necessary to remove this item from the Outbox for other send attempts to work.

Workaround:

The problem does not manifest if the connection to Exchange is configured to run in cached-mode.

The Fix:

We’ve reported the issue to Microsoft Support, and they have responded that this is a known issue, and that it will be corrected in SP3 Update Rollup 1.  (We are already planning for an SP3 deployment, but currently have no ETA on the release of RU1 and the tentative release date for RU1 is May 11.)

Demystifying Mailbox Access Permissions

I frequently encounter confusion over granting access to a mailbox to other users, something which is a particularly important consideration when dealing with resource mailboxes (whose underlying Active Directory account is disabled).

There are three mechanisms for defining who can access a mailbox that is not their own, and two for defining who can send mail from it. Here is a quick overview:
I. Access to a mailbox:

1. “Full Access” rights:
Since true resource mailboxes (room, shared, and equipment mailboxes) are tied to a disabled Active Directory account, upon creation of the mailbox the Exchange admins assign “Full Access” permissions to accounts specified by those requesting the mailbox. Accounts with “Full Access” permissions are able to log directly into the resource mailbox with their own credentials in order to manage it (assigning delegates, setting sharing permissions, etc.).

“Full Access” rights are the highest level of access to a mailbox, and can only be set by the Exchange administrators. Because of this limitation, it is not uncommon to grant “Full Access” permission to mail-enabled group whose membership is managed by the mailbox owners.

Please note that setting delegates should be done through a dedicated Outlook profile, since only the delegate settings of the primary mailbox in a profile can be modified. Also note that having “Full Access” permissions does not grant rights to send mail AS that mailbox. More on this in a bit.

2. Folder sharing permissions:
Similar to sharing permissions in a file system, this is the simplest and most straightforward way to grant someone else access to a specific folder in a mailbox, such as the Inbox or Calendar. Different levels of permissions on each folder may be defined for each specified user. (Note that one of the sharing permissions, as see client-side, is called “Owner.” The same holds true for the delegate permissions discussed below. As such, the term “Owner” is somewhat overloaded.) Sharing permissions can be set by those with Full Access rights on a mailbox or those who themselves have sufficient sharing or delegation permissions on the given folder. Sharing permissions do not grant the ability to send from a mailbox.

3. Delegation
Delegation is a superset of sharing. When someone with Full Access rights to a mailbox assigns someone as a delegate to that mailbox (using a dedicated Outlook profile, since delegate settings can only be modified on the primary account in a given profile), three things happen under the hood:
a) Sharing permissions are set (per delegate, and per default folder) as above
b) The delegate is granted “Send-on-behalf-of” rights on the mailbox, which effectively allows them to send as the mailbox, with the caveat that the FROM field shows that the messages are sent “by USER-X on behalf of USER-Y”.
c) If the delegate is set to receive copies of meeting invites, a special hidden forwarding rule for this purpose is created within the mailbox.

There are several gotchas associated with delegates to be aware of:
a) Delegation tends to be over-used. Don’t use delegation if sharing permissions will suffice.
b) Watch out for delegation loops. (A is delegate of B, who is a delegate of C, who is a delegate of A.) Delegation for people mailboxes should generally follow the organization’s management structure.
c) When someone leaves the department, be sure to remove them from delegate lists before their mailbox goes away. Outlook tends to misbehave (throwing errors during attempts to modify delegations) when someone on a delegate list no longer has a mailbox, and the Exchange admins have to clean it up. (Microsoft’s programmers seem to assume that such individuals would no longer have AD accounts, so they don’t handle the situation very gracefully.)

II. Sending from a mailbox
There are two ways for someone to send FROM a mailbox that is not their own:

1. The “Send As” permission, which can only be applied by the Exchange admins. In much older versions of Exchange, this right came implicitly with “Full Access,” but that has not been the case for several versions now. We try to grant this right rather sparingly, as it is something of a nightmare from a security auditing standpoint. When several users have “Send As” permission on a mailbox, it is quite difficult (depending upon the how the logging level set on the server) to determine which one of them actually sent a given message, which can be problematic in a legal inquiry.

2. The “Send On Behalf Of” right, granted as part of delegation, discussed above.

Note that Exchange administrators have limited administrative visibility into delegation settings (short of actually logging into the mailbox), although we can see who has Send-on-behalf” rights. Delegate settings can ONLY be set by logging directly into the mailbox, and should therefore be set by those individuals who have “Full Access” rights.