Microsoft introduced the rather useful cmdlet set of Set-MailboxSentItemsConfiguration and Get-MailboxSentItemsConfiguration a long time ago (Exchange 2010 SP2 RU4 – August 2012). As you might recall, these cmdlets allow an administrator to exert control over where Exchange stores copies of messages sent by delegates.
What’s surprising and genuinely puzzling is that the cmdlets were not included in Exchange 2013 RTM and have not appeared in any version since, including Exchange 2013 SP1 (where you might have expected them to show up) or even the latest Exchange 2013 RU6 update. The cmdlets have also failed to show up in Office 365, at least not in my tenant domain.
When the cmdlets first appeared in Exchange 2010 SP2 RU4, I thought that they were an elegant solution to the need to mess with registry settings to instruct Outlook how to handle messages sent by a delegate. I content that the right place is in the Sent Items folder of the mailbox belonging to the user for whom the message is sent. Outlook prefers to squirrel the message away in the Sent Items folder of the delegate’s mailbox.
The registry hack involves creating a new DWORD value called DelegateSentItemsStyle, setting its value to 1, and then restarting Outlook. I’m not saying that I dislike a ramble through the registry. Sometimes you have to get down and dirty to convince Windows and various programs to do the right thing. Thankfully, we have to resort to RegEdit far less now than in the past, but the same major problems exist. First, registry hacking is extremely prone to errors. Second, the registry is specific to a single PC and usually, to a specific version of a product. In this case, the new value has to be added in different places depending on the version of Outlook you use.
In short, a registry hack is a great way for a developer to influence the way a product works for demonstration environments. It is an awful way to accomplish a long-term change in product behaviour that can be managed centrally and endures across multiple product versions and service packs. The Office products attempt to mitigate the problem by being able to set registry values through group templates, but that’s a workaround that has its own particular charms and flaws.
Exchange has done an awful lot over the Exchange 2010 and Exchange 2013 releases to permit administrators to be able to control mailbox settings for users through EMS cmdlets such as Set-MailboxAutoReplyConfiguration. The appearance of the *-MailboxSentItemsConfiguration cmdlet pair seemed to be just another step along the path to allowing administrators to script the correct configuration of user mailboxes as they were created and was, in my mind, a very good thing.
So I remain puzzled and bemused why these cmdlets have not appeared in either Office 365 (where they would seem to be perhaps even more valuable than in an on-premises deployment) or Exchange 2013. The code still works and functions well inside Exchange 2010. I’m sure that the Exchange developers have their own reasons for not bringing it forward into the latest products but I don’t know why. Strange!
Follow Tony @12Knocksinna