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
Thoughtsofanidlemind's Blog 
Very strange why MS has still not implemented this with Ex 2013.
MS should also implement this regarding Deleted Items behavior.
In my lab env, after configuring Ex 2010 MailboxSentItemsConfiguration and moving mbx to 2013: MailboxSentItemsConfiguration is still working.
Martijn
That’s disconcerting, Martjin. While clearly Exchange 2013 seems to support the functionality, you lose the ability to control it post migration. What if you want to change it later? Do you have to stand up an Exchange 2010 database server then move the mailbox there just to change the setting back?
It reminds me a bit of the ShowManagePrivacyRelationships property of the Set-CsClientPolicy cmdlet in Lync 2013. This cmdlet still exists in Lync Server 2013 but it has no effect on Lync 2013 clients. It only affects Communicator 2007 R2 and Lync 2010. You can use it to change your global privacy defaults using the older clients but have no such control with the Lync 2013 client.
Pingback: Weekly IT Newsletter – October 13-17, 2014 | Just a Lync Guy
Hi Tony,
Couldn’t agree more. I wish we could control this behaviour from the server rather than through a messy registry entry. Also, it appears to only work if the user is running outlook in cached mode. I’d like to think there is a valid reason for it being removed, but after 6 CUs it would of been really nice to see the functionality added back in. It seems to burn more when it was available in 2010 but not in 2013.
In order to work around this issue when migrating to Office 365, we have had to revert shared mailboxes to full user accounts – which require a full Office 365 license. Therein I suspect lies MS’s motivation – make shared mailboxes so basic they cease to be useful. With OWA there is no registry hack you can apply. It really infuriates me when MS take away features – how can you ever rely on a particular functionality when might wind it back on the next release? Most of us have better things to do than have to diagnose and workaround this sort of issue.
Agreed!
The thing is kind of exist in Exchange 2013 but hard to recognize, and behaves differently:
Set-Mailbox -MessageCopyForSentAsEnabled $true -MessageCopyForSendOnBehalfEnabled $true
Yep, they changed the behaviour in the final implementation. See http://blogs.technet.com/b/rmilne/archive/2015/06/22/exchange-2013-cu9-messagecopyforsentasenabled-missing.aspx
Rudi – Only for shared mailboxes. Does not work for regular