New cmdlets allow server-side control over delegate-sent messages

I was very pleased to receive a reader comment from Daniel Sheehan to my post describing how to handle copies of messages sent by a delegate when using Office 365. Daniel pointed out that Exchange 2010 SP2 RU4 contains KB2632409, which describes a new cmdlet set that is designed to help address the problem, a development that had clean passed me by.

Exchange 2010 SP2 RU4 introduces the Get/Set-MailboxSentItemsConfiguration cmdlets. The Get- cmdlet returns the current setup for a mailbox while the Set- cmdlet allows an administrator to determine how sent items are captured when sent by a delegate to a mailbox.

For example:

Get-MailboxItemsSentItemsConfiguration –Identity ‘CEO Mailbox’SendAsItemsCopiedTo         : SenderSendOnBehalfOfItemsCopiedTo : SenderIdentity                    :IsValid                     : True

This configuration tells us that any delegate message sent on behalf of the CEO Mailbox will be copied to the Sent Items folder of the sender only (SendOnBehalfOfItemsCopiedTo = Sender) as will any messages sent as the CEO Mailbox. The other valid choices are “SenderAndFrom”, which captures copies of outbound messages in the Sent Items folder of both the delegate who sends the message and the mailbox with which the delegate is working, or “From”, meaning that the message is saved only in the delegate’s mailbox. Apparently a bug exists in using “From” in current builds that makes it behave like “SenderAndFrom”. No doubt this will be address in a future build. For now, it’s best to avoid the option.

To change the configuration for a mailbox, we run the Set-MailboxSentItemsConfiguration cmdlet. For instance:

Set-MailboxSentItemsConfiguration –Identity ‘CEO Mailbox’ –SendAsItemsCopiedTo SenderAndFrom –SendOnBehalfOfItemsCopiedTo SenderAndFrom

The KB makes two important points. First, you should remove the DelegateSentItemsStyle registry key from any Outlook client that connects to the mailbox because you don’t want Outlook making decisions about how to handle sent messages that might conflict with the server. On the upside, making the server control how messages are captured means that the previous restriction of Outlook having to work in cached Exchange mode is no longer valid. Second, you have to restart the Information Store service before the changes are effective. This seems rather dramatic to me, even to gain a nice piece of functionality.

Also on the good news front, the settings section of Outlook Web App 2010 is updated to allow users to control how sent items are captured for their mailbox. All Client Access Servers have to be running Exchange 2010 SP2 RU4 or later for this functionality to be exposed.

The bad news is that, at the date of writing (late December 2012), these cmdlets have not yet reached Exchange Online (Office 365), nor are they included in Exchange 2013 RTM. I’m sure that Exchange Online will be updated in the near future and that the same will happen in one of the early updates for Exchange 2013, the first of which is expected in the New Year. All good things come to those who wait.

Follow Tony @12Knocksinna