Outlook and Office 365: Where do SendAs items go?

Exchange allows users to assign delegate access to other people to send messages on their behalf. In an on-premises deployment of Exchange 2007, Exchange 2010, or Exchange 2013, you can use the Exchange Management Console (EMC) for Exchange 2007 and Exchange 2010 or the Exchange Administration Center (EAC) for Exchange 2013, or run the Add-MailboxPermission cmdlet in the Exchange Management Shell (EMS) to set up the necessary permission.

For example, we could run the following command to allow Tony Redmond to send messages on behalf of Deirdre Redmond:

Add-MailboxPermission -Identity 'Deirdre Redmond' -User 'Tony Redmond' -AccessRights 'SendAs'

Of course, you might have guessed that Add-MailboxPermission associates Active Directory permissions to a mailbox, which is what you’d expect as Exchange uses Active Directory permissions behind the scenes to ensure that users can do what they should. But Office 365 does not use Active Directory permissions in the same way as on-premises Exchange does and therefore a different approach is necessary, which is why Microsoft provides the Add-RecipientPermission cmdlet instead.

To delegate SendAs permission for a mailbox, we need to run PowerShell, connect to Office 365, and run a slightly different command:

Add-RecipientPermission -Identity 'Deirdre Redmond' -AccessRights SendAs -Trustee 'Tony Redmond'

So good so far . . . but then you might just have noticed that my PowerShell screen shot reveals that I also ran the Add-MailboxPermission cmdlet to assign full access to the mailbox (the Add-MailboxPermission cmdlet is available for both on-premises Exchange and Office 365). This is because having the delegated access to send messages on behalf of another user does not provide the ability to access that user’s mailbox. Exchange quite rightly separates the two abilities so as to provide granular control over the access that someone might be assigned to a mailbox. However, in practical terms it’s often necessary for someone such as an administrative assistant to have full access to another person’s mailbox and as we’ll see, that ability also affects where “sent as” messages end up.

If you make a mistake and need to remove full access, run the Remove-MailboxPermission cmdlet as follows:

Remove-MailboxPermission -Identity "Deirdre Redmond" -User "Tony Redmond" -AccessRights FullAccess

Getting back to the real point in this discussion, for years, one of the real pain in the rear quarter that Outlook has inflicted on Exchange users is its determination to store messages sent by a delegate in the Sent Items folder of the delegate’s mailbox instead of where nature intends, which is in the Sent Items folder of the mailbox belonging to the user for whom the message is sent. (For information about using VBA to move sent items, see "Outlook 2010: Move MailItems After Sending.")

This might not sound like the issue is too serious until you attempt to explain to a user who is a delegate that they get to keep all the messages that they send for other people, at which time it just does not make any sense. At least, I have never managed to construct a coherent explanation for Outlook’s behaviour (this could be a personal failing on my part). In any case, the nice people at Microsoft have decided to provide a method to instruct Outlook to do the right thing. Unfortunately, you have to add a new DWORD value to the system registry, but I guess you can’t expect perfection.

The fix works on Outlook 2010 SP1, Outlook 2007 (provided you install KB972148), and Outlook 2003 (in which case you need KB959628). After you have the right software on your PC, open REGEDIT and add a new DWORD value at:

Key: HKEY_CURRENT_USERSoftwareMicrosoftOffice14.0OutlookPreferences
Name: DelegateSentItemsStyle
Type: DWORD
Value: 1

Substitute “11.0” for Outlook 2003 and “12.0” for Outlook 2007 (logically then "15.0" should be the right value for Outlook 2013) to determine the version-appropriate registry key. Of course, Office 365 doesn't support Outlook 2003 clients so this fix is only useful if you want to connect Outlook 2003 clients to on-premises Exchange.

In my case, I use Outlook 2010 and edited the registry as shown above. I then restarted Outlook to make the change effective. The next time I sent a message on behalf of someone, Outlook stored the message in the Sent Items folder of that user’s mailbox and left not a trace in my mailbox. Success!  Note that if I had only SendAs permission for a mailbox and didn’t possess FullAccess permission, Exchange won’t have the necessary permission to open the other user’s mailbox to store the sent item there. That’s why I went through the two-stage process of adding both SendAs and FullAccess as described above.

I was not able to make the technique work with Outlook 2013. However, a case can be argued that the fix is no longer required because both Outlook 2010 and Outlook 2013 allow you to add multiple mailboxes to your profile. Thus, when you start Outlook, you open each mailbox in the profile and can send messages from any of the mailboxes in the profile. When you do this, copies of any outgoing messages are kept in the Sent Items folder in the mailbox used to send the messages.

A similar issue exists with items that are deleted by a delegate from a shared mailbox. Logically, you might think that these items would go into the Deleted Items folder of the shared mailbox. In fact, Outlook’s default behaviour is to move them into the Deleted Items folder of your mailbox! Fortunately, another registry fix is available (described in the Microsoft Support article "Items that are deleted from a shared mailbox go to the wrong folder in Outlook") that forces Outlook to move items into the Deleted Items folder of the shared mailbox. You’ll need to insert another new DWORD value called DelegateWastebasketStyle, at HKEY_CURRENT_USERSoftwareMicrosoftOffice[version]OutlookOptionsGeneral and insert the value 4 (four). Once again, you insert 14.0 for [version] for Outlook 2010 and 12.0 for Outlook 2007. It would be nice if Microsoft had used the same registry location for the keys that control both aspects of delegate behavior.

As a final point, the wonders of AutoDiscover for both on-premises Exchange 2010/2013 and Office 365 means that you don’t have to mess with Outlook profiles when you have full access to another person’s mailbox. When Outlook starts up, it receives details of that mailbox in the XML data returned by AutoDiscover and will open the mailbox automatically.

Follow Tony @12Knocksinna