One of the customers I was working with last week encountered an error whilst attempting an operation in Exchange Online PowerShell. This surprised them, as they were logged on as an account in the Organization Management RBAC Role group.
They received an error running the following cmdlet:
Get-FederationInformation -DomainName Tailspintoys.ca | New-OrganizationRelationship -Name "Tailspin Canada" -FreeBusyAccessEnabled $true -FreeBusyAccessLevel LimitedDetails
This reported failure was due to an error with CmdletInvalidOperationInDehydratedContextException.
This actually a good error message, as it states what the issue is and how to correct it. We need to run the Enable-OrganizationCustomization cmdlet.
They were a little curious as they had not seen this error message before, and they had been working with multiple Office 365 tenants for a while.
The reason the above error occurred is because the tenant is currently in a compressed state. This is called dehydrated or tiny tenant mode. Think about the multitude of customers in Office 365 that have a basic tenant and do not need to make any customisations or configure a hybrid deployment. Those customers can run quite happily in the default dehydrated mode and parts of their configuration are compressed to save on space and resources. The dehydrated state is the default for a tenant.
This can be seen below for a brand new test tenant. This tenant is approximately 5 minutes old at this point.
Get-OrganizationConfig | fl Identity, IsDehydrated
When you try to use Windows PowerShell to modify one of these dehydrated objects for the first time, you may encounter an error message that tells you to run the Enable-OrganizationCustomization cmdlet.
Here are some examples of when you might see this:
Creating a new role group or creating a new management role assignment.
Creating a new role assignment policy or modifying a built-in role assignment policy.
Creating a new Outlook Web App mailbox policy or modifying a built-in Outlook Web App mailbox policy.
Creating a new sharing policy or modifying a built-in sharing policy.
Creating a new retention policy or modifying a built-in retention policy.
The customer had not seen the error before, as their tenant was configured for a Hybrid deployment using the Exchange 2010 SP3 Hybrid Configuration Wizard (HCW). The HCW automatically hydrates the tenant. The below screenshot is from a tenant where the Exchange 2010 SP3 HCW was executed. Notice that the isDehydrated is now False.
This is one of the many manual configuration steps which were required when you had to do all of the steps yourself in Exchange 2010 SP1. Ugly days….
Doing all of that is now unsupported, and we must use the HCW. That support stance is for a very good reason. Doing all of this manually is oh so error prone.
To enable OrganizationCustomization we can connect to Exchange Online using Remote PowerShell and use the Enable-OrganizationCustomization cmdlet.
That’s cool, but how else can this get enabled?
Other Ways OrganizationCustomization Can Become Enabled
We discussed above that running the HCW will also enable the OrganizationCustomization. In addition to the HCW, if you attempt the same operation in the Exchange Admin Centre (EAC) it will enable the Organization Customization for you.
In the same test lab above, EAC was opened. The command logging window was then launched, and then a new organization relationship was created. This is shown below.
In the below command logging window, notice what happened. Initially the command (index 1) failed for the same reason as listed above:
Then the command was automatically re-launched (index 3) and it completed successfully:
And if we now check back using PowerShell, the tenant is no longer dehydrated.
That is interesting. What went on?
We can search the AdminAudit log to see what is in there. In the interests of space, the cmdlet and object modified are the only elements selected for display.
Search-AdminAuditLog | Select cmdletname, objectmodified
This reflects the list of items above where you need to hydrate the tenant. You can see that we are creating new RMS, MRM, RBAC and EOP objects here.
As an interesting aside, note the below underlined IgnoreDehydratedFlag parameter used with the New-HostedContentFilterPolicy cmdlet. This seems to be the magic that works away in the back end.
Thanks for the explanation.
Unfortunately the new normal is the following error:
- The command you tried to run isn't currently allowed in your organization. To run this command, you first need to run the command: Enable-OrganizationCustomization.
Which is no help at all when Get-OrganizationConfig returns:
And Enable-OrganizationCustomization errors out with:
Enable-OrganizationCustomization: This operation is not required. Organization is already enabled for customization.
Office 365/Azure is great when everything works and is documented well, but a complete time waste when nonsense like this happens, or when a new "feature" or "GUI refresh" occurs without the corresponding or comprehensive documentation set to go with it. Oh the fun to be had chasing down useless/semi-useful/useful social media posts in the absence of decent official documentation or adequately trained support staff capable of responding within a reasonable timeframe (a response in under 5 working days would be helpful).
Did you get to the bottom of this?
It's been 7 years since I posted the above and if the error message has changed I should update that.
Hey I also had an error, but when executing the command Enable-OrganizationCustomization I get the result WARNING: An unexpected error has occurred and a Watson dump is being generated: Value cannot be null. Parameter name: rootOrgId Value cannot be null. Parameter name: rootOrgId + CategoryInfo : NotSpecified: (:) [Enable-OrganizationCustomization], ArgumentNullException + FullyQualifiedErrorId : System.ArgumentNullException,Microsoft.Exchange.Management.Deployment.EnableOrganization CustomizationTask + PSComputerName : outlook.office365.com
Thanks for the helpful article - even though it's historic the error message still matches what is shown in Microsoft 365.
I came across it when trying to modify the Outbound Anti-Spam policy to allow forwarding. It initially said organisation customisation had to be enabled and I approved this, however it then failed to change the policy.
Checking via Exchange PowerShell (a new thing to learn!) I found that the customisation had been applied correctly and 'IsDehydrated' is false, however I think it then seems to take some period of time for this to then be processed. From other reports it might be 24 hours, although I'm hoping it'll be sooner.
PS tried after 2h and I've now been able to enable forwarding - shame it doesn't tell you this initially when enabling it!
Yeah, it's still a thing. Generally I don't run into it too much as most of the customers I deal with have already ran the HCW.
Thanks for adding the timing data point - much appreciated!