Office 365 Command You Tried To Run Isn’t Currently Allowed Due To DeHydration

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.

La Raison

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.

Enabling OrganizationCustomization

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.

 

Cheers,

Rhoderick