Why Exchange Online Dehydrates an Organization Configuration

The Enable-OrganizationCustomization Cmdlet

Apparently the Enable-OrganizationCustomization cmdlet for Exchange Online has been around for quite a while without me noticing it. Some say it’s been in the Exchange product code since the earliest days of Business Productivity Online Services (BPOS), the predecessor of Office 365. That’s a long time.

According to the documentation, “In the Microsoft datacenters, certain objects are consolidated to save space” and tenant administrators might be asked to run the cmdlet before they can add or modify certain configuration objects for Exchange Online.

In other words, new tenants use an out-of-the-box configuration for settings like role assignment policies, OWA mailbox policies, mailbox retention policies, and some Exchange Online Protection settings. Before these tenants can alter their configuration, the Enable-OrganizationCustomization must be run to move the tenant configuration to a customizable state. This can be done explicitly (an administrator runs the cmdlet) or implicitly (Exchange Online runs the cmdlet when an administrator changes a standard setting for the first time).

Hydrated Exchange Organizations

After running the cmdlet, the IsDehydrated setting in the organization configuration is set to False. This is a one-time operation and there’s no way to reset IsDehydrated.

In this context, a dehydrated tenant is one using the standard Exchange Online configuration settings while a hydrated tenant has a customized configuration. According to Microsoft, most tenants are in a dehydrated state, which is what you’d expect across the spectrum of Office 365 tenants where many are small tenants who never need (or want) to change anything.

Get-OrganizationConfig | Select isDehydrated

IsDehydrated
------------
       False

My tenant is heavily customized, but I have never run Enable-OrganizationCustomization. In fact, unless I missed it in passing, I have never run Enable-OrganizationCustomization in any tenant I have worked in, but people have told me that they have, such as when updating an OWA mailbox policy to allow users to access the Moca preview. Figure 1 shows what you see when EAC rehydrates tenant settings (the cmdlet is run to effect the change).

Avoiding Azure AD Bloat

Exchange Online uses standard settings whenever possible and only expands objects holding those settings when they are customized. Apparently, at the scale which Exchange Online runs, this approach makes a real difference for Azure Active Directory. If every Exchange Online stored every setting for every tenant, it would create significant directory bloat.

Outside directory bloat, the assertion that objects are consolidated to save space is less believable. The storage consumed by Exchange Online mailboxes and its use by the Microsoft 365 substrate to store data belonging to other applications is such that saving a few megabytes of configuration data per tenant would seem like a rounding error. Maybe the rounding error becomes more important when you’re dealing with 250,000 mailbox servers.

No Need for the Cmdlet

Doubtless Exchange Online gains some goodness from using standard configurations but I still don’t know why the cmdlet exists. It seems like an unnecessary barrier to tenants which could be removed if Exchange automatically upgraded a tenant to a hydrated state when the first customized configuration object was saved.

Teams also uses standard policies (and Teams has lots of policies). Microsoft manages the default versions of those policies. Organizations get their own copies if they change the default (global) policy for the tenant and the customized version takes precedence over Microsoft’s version. There’s no warning issued and the switch from default to custom objects is seamless.

Stopping Unnecessary Customizations

Since the introduction of PowerShell support in Exchange 2007, the customizability of the product has been one of its strengths. Tenants can still customize Exchange Online, albeit after running an annoying cmdlet to enter a hydrated state.

A cynic might say that putting a barrier in front of administrators might prevent some errors in configuration customizations which ultimately lead to support calls and increased costs for Microsoft. There doesn’t seem to be another good reason for the Enable-OrganizationCustomization cmdlet, especially as becomes a dead, useless cmdlet after it is run.

Using a centrally managed standard configuration for a complex application like Exchange Online is a good thing. Advising people to walk away slowly before making changes they might not understand is sensible. However, forcing the use of a cmdlet where a seamless background switch from dehydrated to hydrated state is possible is just over the top.

---

Learn more about Exchange Online in the Office 365 for IT Pros eBook.