How to create an Outlook Profile for a Hidden Mailbox

Suppose you wanted to create an Outlook profile for a hidden mailbox and, for whatever reason, you do not want to unhide it from the Address Book just long enough to create it. All hope is not lost! ( Unless you are using Outlook 2016). You can do it using the LegacyExchangeDN.

1. Use adsiedit or your favorite LDP viewer/query tool and copy the LegacyExchangeDN of the hidden mailbox. ( I still prefer adfind to this day).

The LegacyExchangeDN value is a property of the user’s object in AD and will be in the form of:  /o=Contoso/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA

2. Create the Outlook profile. It will fail and you will be at the dialog box that shows server name and the users’ mailbox.


3. Remove the “=SMTP:”  value of the  “Mailbox:” and paste the LegacyExchangeDN value you copied from Step1.


4. Hit Check Name and it should resolve and allow you to create the profile and access the mailbox.


This is with Exchange/Outlook 2013. This does not work with Outlook 2016 from what I have seen:




On-Premises Mailbox Missing Retention Policy Tags after enabling Archive in Office 365

Consider the following scenario:

You have an on-prem mailbox, but decide to move your online archives to Office 365 to take advantage of the “Unlimited” storage. No problem. That works great for existing mailboxes, but when creating new archives in the cloud, you discover that the policy retention tags are not surfaced to the end-user in Outlook and the ability to archive to a pst remains.


You have a few options:

Run: Start-ManagedFolderAssistant <user>

If that doesn’t work, move the online back on-premises and run Start-ManagedFolderAssistant.  Alternatively, if the archive is unused, disable it, re-enable on-prem  ( and run Start-ManagedFolderAssistant to speed things up). Once the policy tags appear, move it back to Office 365.

P.S. Ensure you have imported all the on-premises tags to Office 365 per the link below. Otherwise the automatic archiving will not work!






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 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”!




Anything that works now with Microsoft Forefront Protection is probably just dumb luck

If you are still using Microsoft Forefront Protection 2010 for Exchange Server (FPE), you are officially out of time. I’m seeing a number of Technet Forum threads about things no longer working as expected or signatures that do not update.  Time to move to another on-prem product or a cloud solution like Exchange Online Protection (EOP).  ( And let’s not even talk about the support for Exchange 2010)

Subscriptions expiring before December 31, 2015 will not be renewed; virus updates and signatures will not be made available after this date and the service will end.

On September 12, 2012, Microsoft announced the End-of-Life date for the following Forefront Server and Forefront Protection products as of December 31, 2015:

  • Microsoft Forefront Protection 2010 for Exchange Server (FPE)
  • Microsoft Forefront Protection 2010 for SharePoint (FPSP)
  • Microsoft Forefront Security for Office Communications Server (FSOCS)
  • Microsoft Forefront Threat Management Gateway Web Protection Services (TMG WPS)

This announcement also applies to earlier versions of these products in the Microsoft Antigen 9 and Forefront Server ranges.

Bogus Public Folder Mailbox Quota Alerts in Exchange 2013

All is not quiet on the Exchange 2013 front if you are running Public Folders. Once you migrate from legacy PFs, ( I assume you aren’t crazy enough to start using Public Folders in a greenfield 2013 org), you may start seeing over Managed Availability Alerts such as:

Log Name:      Microsoft-Exchange-ManagedAvailability/Monitoring
Source:        Microsoft-Exchange-ManagedAvailability
Date:          1/26/2016 8:30:31 AM
Event ID:      4
Task Category: Monitoring
Level:         Error
User:          SYSTEM
The public folder mailbox PFMBX01 is approaching its storage limit. Consider splitting the mailbox using Split-PublicFolderMailbox.ps1. This warning will not be sent again for at least twenty four hours. 
At this point, you may be tempted to move folders from this mailbox to another.

However, before you do that, check the actual quota usage either in EAC:



Or powershell:

Get-MailboxStatistics <PFMBX> |FL totalitemSize

TotalItemSize : 14.2 GB (15,248,828,208 bytes)

So what’s going here? Why are alerts firing when the mailbox quota warning has not been reached? Quite simply, it’s a bug.

The MA service doesn’t or can’t differentiate between individual folders that are nearing their quota and the actual Public Folder Mailbox. For the admin, this can create a lot of confusion. If an individual folder is nearing quota, the folder contacts will get alerted and that is typically sufficient. If the mailbox itself is nearing it’s quota warning level, the admin will obviously want to take action soon.

Hopefully this will be fixed in Exchange 2013 with a future CU.

For 2016, I will update this blog when I have time to test.

If you are concerned about missing actual PF mailbox over quota events, I suggest creating a scheduled PowerShell task that checks the mailbox sizes and fires off an email alert if the quota is approached.




Transport Rules versus Safe Sender Lists in Office 365/EOP: ¿Quien es mas Macho?

One of the great powers of being the messaging guy or girl is the ability to create transport rules in response to business requirements. Seemingly subtle differences in the rule’s logic, however, can make a huge difference.

For example: You craft a rule to block spoofed messages from the internet that appear to come from your SMTP domain. Like all good internet citizens, you have enabled DMARC, so you construct a rule like this:



So, what happens to the message when the rule is applied? Since you are setting the SCL to 9, it will end up in the quarantine by default . Or will it?

Consider this: Since you are marking the message as SPAM, you are also giving the end-user the ability to bypass that rule by whitelisting the sender.

Because EOP honors both the RFC 5321 MAIL FROM: and the RFC5322 FROM:, if the MAIL FROM: just happens to be on an user’s safelist – added through Outlook or OWA – the message will be allowed,  even if the FROM: is a spoofed domain.

If you don’t like the prospect of messages potentially slipping through without hitting the quarantine first, force it instead:


Problem Solved!

Well, maybe. Since you are pushing the message to the quarantine by rule, the end-users will not see the messages in their personal quarantines and will not be able to release the message without administrator intervention as documented here:

But maybe that is what you want.

Regardless, you can craft the rule to meet your needs. And options are always good.






Exchange 2013 Queue Viewer/Toolbox fails to open after upgrading to CU11

Looks like another mailbox anchoring issue!


Note This issue will be fixed in Cumulative Update 12 for Exchange Server 2013.