MVP - Most Valuable Professional
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft Technologies like Exchange, Office 365, Azure and Cloud Security.

Hashtable-to-Object conversion is not supported in restricted language mode

Lastly I've encountered an interesting PowerShell error after upgrading several servers running Exchange Server 2013 CU9 to Exchange Server 2013 CU11.

After a successful upgrade, the Exchange PowerShell script to redistribute the DAG databases failed with an error.

.\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference -Confirm:$false
Cannot process argument transformation on parameter 'Identity'. Cannot convert value "MAILBOXDB01" to type
"Microsoft.Exchange.Configuration.Tasks.DatabaseCopyIdParameter". Error: "Cannot convert hashtable to an object of the
following type: Microsoft.Exchange.Configuration.Tasks.DatabaseCopyIdParameter. Hashtable-to-Object conversion is not
supported in restricted language mode or a Data section."
    + CategoryInfo          : InvalidData: (:) [Get-MailboxDatabaseCopyStatus], ParameterBindin...mationException
    + FullyQualifiedErrorId : ParameterArgumentTransformationError,Get-MailboxDatabaseCopyStatus
    + PSComputerName        : SERVER01.mcsmemail.de

The interesting part to note is conversion is not supported in restricted language mode

The supported language mode is configured in the application settings of the PowerShell virtual directory of the Exchange Back End website.

Exchange 2013 PowerShell Virtual Directory Application Settings 

The application settings after Exchange Server 2013 CU11 update:

Exchange PowerShell Virtual Directory PSLanguageMode - RestrictedLanguage

Running PSLanguageMode with value RestrictedLanguage is the default setting. You should change this setting only, if you encounter PowerShell issues.

Double-click PSLanguageMode and change the value to FullLanguage.

Exchange PowerShell Virtual Directory PSLanguageMode - FullLanguage

Currently I have not validation why a clean Exchange 2013 CU11 setup does not show this behaviour. A plain Exchange 2013 CU11 setup executes the script without any issues.

 

 



Comments are closed.

Showing 0 Comment