Microsoft 365 Enable Organization Customization

原文：Microsoft 365 Enable Organization Customization — theDXT (Daniel Keer)

Right out of the box the initial configuration of Microsoft 365 (aka Office 365) isn’t bad, but there’s a lot more you can do to harden it and to make it fully yours.

By default all Microsoft 365 tenants are in a state that is called dehydrated. Microsoft places all the tenants in this state in order to save space, as there are likely many Microsoft 365 tenants that will never change anything past the defaults, but that’s no fun.

In order to rehydrate our Microsoft 365 tenant to allow for a whole number of customizations we need to enable something that is called organization customizations.

Once we have enabled organization customizations we will be able to customize a lot more things in our Microsoft 365 tenant.

Here’s how to do that.

It is worth slowing down for a moment before you run the cmdlet, because this is one of those rare operations in Microsoft 365 that is effectively one-way, that changes how the service stores an entire class of configuration objects, and that quietly acts as a prerequisite for a long list of features administrators assume are always available. Understanding what happens underneath makes it far easier to justify the change, to schedule it sensibly, and to explain to the business why a single line of PowerShell deserves a change record.

Understanding the Dehydrated State

When Microsoft provisions a brand new tenant, it does not build out the complete Exchange Online object model. Instead the tenant is placed into what the service calls a dehydrated state. In this state, certain rarely used configuration objects simply do not exist yet: the addresses, the managed folders, the organization relationships and the default configuration containers that a heavily customised organisation depends on are simply absent from the directory. Because a very large proportion of the tens of thousands of tenants created every month never move past the defaults — a handful of mailboxes, a couple of distribution lists and the standard set of policies — Microsoft avoids the storage and replication cost of materialising objects nobody will ever touch.

The practical consequence is that when you try to configure something that depends on those missing objects, the cmdlet either fails outright or silently does nothing. This is the single most confusing aspect of working with a fresh tenant: commands that work perfectly in a mature Microsoft 365 environment return errors such as “The operation on mailbox failed because it’s out of the current user’s write scope” or, more commonly, a plain and unhelpful failure while creating a policy, a custom address list, or an organisation-level setting.

Rehydration is the process of materialising those objects. Once it completes, the tenant behaves like the mature environments most documentation was written against.

What Rehydration Actually Unlocks

The list of features that require organization customization to be enabled is longer than most administrators expect. In practice, rehydration is a prerequisite for much of the following:

• Creating custom address lists, global address list segmentation and offline address book customisation.
• Building organisation relationships and sharing policies between tenants, including cross-tenant calendar free/busy.
• Configuring managed folders and retention-related folder structures that rely on the default managed folder mailbox policy.
• Applying organisation-wide configuration objects such as custom transport configuration containers and certain compliance boundary settings.
• Configuring address book policies that create virtual, segmented views of the directory for different populations of users.
• Enabling a number of hybrid and coexistence scenarios, particularly where an on-premises Exchange organisation needs to exchange configuration objects with the cloud.

There is also a subtler benefit. Several cmdlets that appear to work in a dehydrated tenant write their configuration into a temporary or local container, and that configuration can be lost or behave inconsistently later. Rehydrating first removes an entire category of intermittent, hard-to-reproduce faults. If you are planning any substantial hardening work — and the whole point of this exercise is that hardening work — doing the rehydration up front is simply good hygiene.

Prerequisites and Permissions

Before you begin, confirm the following:

• Exchange Online PowerShell. The cmdlets used here ship in the Exchange Online PowerShell module. The modern, supported module is ExchangeOnlineManagement; the legacy remote PowerShell session still works but is deprecated and increasingly restricted.
• Permissions. You need to be a member of the Organization Management role group, or be a Global Administrator. A delegated Exchange administrator with narrower scopes will not be able to run the cmdlet.
• Licensing. Organization customization is available in every Microsoft 365 plan that includes Exchange Online; there is no extra licence or add-on involved, and there is no additional cost.
• Maintenance window. The operation is not instantaneous. Budget at least fifteen to thirty minutes, and understand that during rehydration some administrative operations on the tenant can behave oddly or fail while the service is materialising objects.

The Process

• Connect to Exchange Online with PowerShell
• Double check the hydration status of your Microsoft 365 tenant by running the following command Get-OrganizationConfig | FL isDehydrated

Get-OrganizationConfig | FL isDehydrated

If the returned state is True then we will need to rehydrate it. If the returned state is false you have already enabled organization customizations and no further action is needed.

• To enable origination customizations run the following command Enable-OrganizationCustomization

Enable-OrganizationCustomization

• It takes a bit for the command to finish as Microsoft is rehydrating your tenant. Go have a glass of water while you wait.
• There is no output once the hydration is completed but you can double check that it ran successfully by checking the hydration status again.

That is all it takes to enable organization customizations on your Microsoft 365 tenant.

If you are running the module release that supports it, the same result can be reached from the unified Microsoft Graph side of the house, but the Exchange Online cmdlet remains the simplest and most reliable route, and it is the one Microsoft documents directly.

Verifying the Change Took Effect

Because the cmdlet produces no output on success, verification matters more than usual. There are three checks worth running, in order of increasing confidence:

1. Re-run Get-OrganizationConfig | FL IsDehydrated and confirm the value has flipped from True to False. Note that Exchange Online caching can occasionally return a stale value for a short period; if you still see True immediately after the operation, wait a few minutes and check again before assuming failure.
2. Attempt to create an object that requires rehydration — a custom address list is the classic smoke test. If the cmdlet succeeds where it previously failed, the tenant is genuinely hydrated.
3. Review the tenant audit log for the operation. If you already have audit logging enabled (see the related post below), the administrative event for the rehydration appears alongside other configuration history, which is useful evidence for your change record.

Troubleshooting Enable-OrganizationCustomization

Failures are uncommon but they do happen, and the error messages are not always helpful. The scenarios below cover almost every case I have encountered.

“The operation on the organization failed because the organization is already customizable.” This is not an error in any meaningful sense — it means the tenant was hydrated at some point in the past and something else has already triggered the materialisation of the required objects. Confirm with Get-OrganizationConfig and move on.

A permissions or authentication failure. In the overwhelming majority of cases this is the legacy remote PowerShell session rather than a genuine role problem. Disconnect, switch to the ExchangeOnlineManagement module, connect with Connect-ExchangeOnline, and try again. If it still fails, verify the account is a member of Organization Management rather than a scoped admin role.

The command appears to hang. Rehydration genuinely takes time. The default timeouts on some remote session configurations will give up long before the service has finished, which can produce a misleading error while the back-end work continues. Reconnect and check the hydration status rather than re-running the command repeatedly; running it repeatedly while an operation is in flight will not speed anything up.

The status never flips. A very small number of tenants have been found to require a support case, usually because the tenant is in some unusual provisioning state, is part of a hybrid coexistence arrangement mid-flight, or is subject to a regional constraint. Log a case with Microsoft support and include the exact output of Get-OrganizationConfig; it is a fast piece of triage for them.

Common Misconceptions

“This is reversible.” In theory there is no supported command to dehydrate a tenant again, and Microsoft has never offered a general one. Treat the operation as permanent and plan accordingly. That is not a reason to avoid it — it is a reason to schedule it deliberately rather than running it impulsively at the end of a long day.

“It breaks mail flow.” It does not. Mail keeps flowing throughout. What can break, briefly, is administrative operations that touch the configuration containers being materialised, which is why a quiet window is preferable.

“I do not need it because everything works.” Everything working today does not mean it will work after your next hardening project. The failure mode is a cmdlet that half-works — configuration written somewhere you did not expect, behaving differently after a service-side change. Enabling organisation customization removes that risk for the cost of one command.

“It costs more.” There is no licensing or consumption impact whatsoever. The only cost is the administrative time and the storage Microsoft now has to maintain on your behalf, which is invisible to you.

Customizations Worth Doing Next

Once the tenant is hydrated, the natural follow-on projects are the ones that were blocked before. Turning on audit logging so that configuration changes are attributable is usually the first: it costs nothing and it makes every subsequent change reviewable. Beyond that, tightening how groups are created, branding the sign-in experience so that users are not confronted by an unbranded Microsoft page, and reviewing the message size limits your organisation actually needs are all easy wins that use the objects rehydration just created.

If you are working through a broader Microsoft 365 hardening checklist, treat rehydration as an early step rather than a late one — several of the tasks further down that checklist will fail with confusing errors if you leave it until the end.

Frequently Asked Questions

Do I need to run this more than once? No. It is a one-time operation per tenant. Subsequent runs return a “not dehydrated” message or a harmless error indicating the state is already correct.

Does it apply to Exchange Online only, or to the whole tenant? The cmdlet lives in Exchange Online, but the state it changes is organisation-wide. Features outside of Exchange that depend on the hydrated object model begin to work once the operation completes.

Will rehydration affect existing mailboxes or user data? No. Mailboxes, mail items, calendars, OneDrive content and Teams data are untouched. Only organisation-level configuration containers are created.

How long does it take in a large tenant? Larger tenants take longer, and tenants with a long configuration history take considerably longer. The record I am aware of for a very large enterprise tenant runs into hours, which is a further reason to schedule the work in a maintenance window rather than mid-morning.

Can I automate it in a deployment pipeline? Yes, and it is worth doing. Read IsDehydrated first, and only call Enable-OrganizationCustomization when it returns True. That makes the step idempotent and safe to include in a repeatable tenant build runbook.

Final Thoughts

Enabling organization customization is one of those small, unglamorous tasks that pays for itself repeatedly. It takes one command and a cup of coffee, and in exchange it removes an entire class of “why on earth did that fail?” moments from every future project in the tenant. If you are about to start hardening a Microsoft 365 environment, do this first.

If you want to learn more about the Enable-OrganizationCustomization command you can read about it in Microsoft’s documentation here.

Related reading on this site: if you are working through a wider Microsoft 365 hardening pass, the walkthrough on Microsoft 365 audit logging is a natural next step, and the guide to raising the Exchange Online 150 MB message size limit uses several of the organisation objects that rehydration creates. If your tenant build is still fresh, it is also worth deciding early how you want Microsoft 365 group creation to be controlled.