Outlook Error: Remote Server returned ‘554 5.6.0 STOREDRV.Submit.Exception ! – FIXED

UPDATE: It appears that this is fixed in Exchange 2013 CU13:



Full NDR:

Remote Server returned ‘554 5.6.0 STOREDRV.Submit.Exception:TextConvertersException; Failed to process message due to a permanent exception with message data truncated TextConvertersException: data truncated’

This is not a common problem, but crops up occasionally.

If you see this message bounce back when responding to a meeting invitation, try the following:

  1. Set your Outlook profile to cache mode/ Create a new Outlook profile.
  2. Disable any 3rd party add-ins and/or anti-virus.

From what I have seen, switching to cache mode always fixes this.

<Rant>Cache mode is actually the default and preferred mode. Online mode is only recommended in certain scenarios such as a kiosk or regulated environment that forbids a local cached copy of the mailbox. There is no real advantage to online mode. </End Rant>

As to why this happens? Hard to say, but while you are at it, make sure you are running the latest Outlook build. Or use OWA? 🙂


On-Premises mail-enabled Modern Public Folders are not visible in the GAL from Office 365 Mailboxes

Just a reminder. If you are in hybrid mode and using public folders on-premises, the mail-enabled PFs will *not* be visible via the Outlook Address Book for 365 mailboxes – even if they are not hidden from the GAL. All you will see is:


This also means the display name will not be resolvable when creating or receiving a message from the folder.

One work-around is described here under the section “Configure Directory Synchronization” that allows you to create mail-enabled contacts in 365 that represent the PFs.

In the meantime, you will have to wait for one of two solutions:

  1. True mail-enabled PF synchronization.
  2. Supported Modern Public Folder Migration to Office 365. ( Yea, that’s right  – The migration of 2013/2016 Public Folders to Office 365 is not supported right now.




I can’t disable a resource mailbox? Sez Who?

Well, according to https://technet.microsoft.com/en-us/library/jj863434(v=exchg.150).aspx you can not.

Mailbox type Disable? Delete?
Archive mailbox Yes No *
Linked mailbox Yes Yes
Resource mailbox (Room or Equipment) No Yes

If you use PowerShell, you most definitely can!

PS C:\temp> get-mailbox TestRoom |FL *rec*
RecipientType                : UserMailbox
RecipientTypeDetails         : RoomMailbox

PS C:\temp> Disable-Mailbox TestRoom

Are you sure you want to perform this action?
Disabling mailbox “TestRoom” will remove the Exchange properties from the Active Directory user object and mark the
mailbox in the database for removal. If the mailbox has an archive or remote archive, the archive will also be marked
for removal. In the case of remote archives, this action is permanent. You can’t reconnect this user to the remote
archive again.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is “Y”): Y


What you can not do is disable a resource mailbox via EAC. The disable option simply isn’t there for some reason. Seems like an odd oversight.



Do I have to be on the latest Exchange Cumulative Update to be supported?

I can’t tell you how many times I have admonished posters in the forums about not being on the latest Cumulative Update (CU) for Exchange 2013. After all, it has all the latest fixes and you want to be supported right?

It’s generally good advice, but is one really not supported if not on the latest and greatest? Yes and No.

When the original 2013 Servicing Model was announced back in, well, 2013, the support requirements were pretty clear:

Q: How long is a CU supported?

A: A CU will be supported for a period of three (3) months after the release date of the next CU. For example, if CU1 is released on 3/1 and CU2 is released on 6/1, CU1 support will end on 9/1.

This was met with some resistance as many on-premises orgs worried about the cadence schedule and their ability to keep up and still allow for proper testing, roll-out etc… Paul lays this out much better than I could here.

As Paul mentions in his post, Microsoft will not simply turn you away if are running an older CU, though they may suggest you upgrade.

But where is that actually officially stated for all the world to see?  It was some time ago beginning with the release of CU2 in July of 2013 and linked in TechNet:

In the new Exchange servicing model customers will continue to receive assistance from Microsoft Support for the lifecycle of the Exchange server product – a customer is not required to be at the most current CU to receive assistance. There are two scenarios that we would like to clarify though:

  1. If during the course of a support incident it is determined that the solution is available in a published CU (e.g., CU2), the customer will be required to install the update that contains the fix. We will not be building a new fix to run on top of a CU published earlier (e.g., CU1).
  2. If during the course of a support incident it is determined that you have discovered a new problem for which we confirm a fix is required, that fix will be published in a future CU that you can then install to correct the problem reported.

Note an important exception:

You will see this blurb on every CU release:

“Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the most current (e.g., 2013 CU15, 2016 CU4) or the prior (e.g., 2013 CU14, 2016 CU3) Cumulative Update release.”


Maybe you already knew this. But it’s a reminder to myself to always qualify my answer when I tell a forum poster they need to be on the latest CU “to be supported”!