Two cmdlets that first appear in Exchange 2010 SP2 RU4 help to manage where delegate-sent messages end up. Set-MailboxSentItemsConfiguration and Get-MailboxSentItemsConfiguration solve a problem that has caused some administrators to tear their hair out. They are really rather useful!
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.
SendAsItemsCopiedTo : Sender
SendOnBehalfOfItemsCopiedTo : Sender
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:
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 (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 , the first of which is expected in the New Year. All good things come to those who wait.), nor are they included in
Follow Tony @12Knocksinna