1

Exchange 2013 CU9 MessageCopyForSentAsEnabled Missing

After upgrading an Exchange 2013 CU8 lab to CU9, the Set-Mailbox cmdlet did not present the expected options to configure sent items for shared mailboxes. 

The MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled  parameters as discussed on the EHLO blog were missing. 

This was a little puzzling as this was an expected feature of Exchange 2013 CU9.  None of the issues in the 6 common CU install mistakes were made.  Let’s take a look to see what's going on. 

 

Lab Starting Configuration

This lab consists of three servers.  One Windows 2008 R2 DC,  an Exchange 2013 CU8 CAS server and an Exchange 2013 Mailbox server.  This was a pre-canned lab which is why the roles are split out.  Please note this is not a recommendation to split roles.  Splitting roles goes against the Exchange Preferred Architecture

Using one of the methods in this post, the starting AD Schema version information is shown below:

Exchange 2013 Schema Prior To CU9 Upgrade.   Environment Is Currently At CU8

The above demonstrates Exchange 2013 CU8 was already deployed.  Exchange 2013 Schema information can be verified here.  The account used to perform all of the steps is the built in domain admin account.  This is  a member of domain admins, schema admins and enterprise admins so we should not run into any permission related issues.  The account is shown below:

Account Used Has Plethora Of Permissions

Now we know the starting point, let’s start the upgrade to Exchange 2013 CU9…..

  

Starting CU9 Upgrade

On the DC, setup was executed to prepare all domains.  This should also do the implicit steps to prepare the Schema, AD and all domains.  TechNet documents this process. 

setup.exe /preparealldomains /iacceptexchangeserverlicenseterms

Exchange 2013 CU9 Setup To PrepareAllDomains

The preparation completed, so let’s check the AD schema information again. 

Exchange 2013 Schema After CU9 Upgrade

The values returned are the same as before since Exchange 2013 CU9 does not have any schema changes compared to CU8. Your situation may be different, and you need to compare the version information here

Let’s upgrade CU8 To CU9 on the Exchange server’s themselves.  The mailbox upgrade screenshots are shown first, followed by the CAS server.  The upgrade syntax used is below:

setup.exe /mode:upgrade /iacceptexchangeserverlicenseterms

Mailbox Server Upgraded To CU9 Successfully

CAS server upgrade confirmation

CAS Server Upgraded To CU9 Successfully

The CU9 upgrade completed successfully and in PowerShell we see that both Exchange 2013 servers are now at the CU9 build, this is highlighted below: 

Using  PowerShell To Check Exchange 2013 Version

Much simpler than checking Exchange 2007 and 2010 version information!

Both servers were restarted to complete the upgrade.

 

Post Upgrade Testing

Now that the CU9 upgrade was completed, do we see the MessageCopyForSentAsEnabled and MessageCopyForSendOnBehalfEnabled  parameters?  Let’s take a look at the properties for a mailbox called user-1 do we see these properties? 

Get-Mailbox  user-1 | select  *message*

MessageCopyForSendOnBehalfEnabled  And MessageCopyForSentAsEnabled  Are Listed Using Get-Mailbox

Yes  MessageCopyForSentAsEnabled  and MessageCopyForSendOnBehalfEnabled   are both present.  Now let’s try and set the MessageCopyForSentAsEnabled to $True for User-1. 

MessageCopyForSendOnBehalfEnabled  And MessageCopyForSentAsEnabled  Not Present Using Set-Mailbox

Oh, that was not so good…..

The Set-Mailbox cmdlet does not recognise the parameters  MessageCopyForSendOnBehalfEnabled  or MessageCopyForSentAsEnabled.

 

Correcting The Issue

Depending upon which previous version of Exchange 2013 you are upgrading from, this issue may or not occur.  Exchange 2013 CU9 does not appear to perform all of the necessary steps for PrepareAD if there a couple of specific issues. 

To address the issue, please explicity run the PrepareAD command from an elevated cmd prompt:

Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms

Cheers,

Rhoderick

Rhoderick Milne [MSFT]

Leave a Reply

Your email address will not be published. Required fields are marked *