MVP - Most Valuable Professional

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.

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        :

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.



Read More »

The Outlook on the web S/MIME implementation supports a variation of encryption algorithms like

  • RC2 (supported key lengths are 40, 56, 64, and 128)
  • DES (56-bit)  
  • 3DES (168-bit)
  • AES128  
  • AES192  
  • AES256

When you want to configure the OWAEncryptionAlgorithms or OWASigningAlgorithms attributes to support more than one algorithm, you have to follow a certain format. The attribute itself is stored as String and not being validated when using Set-SMimeConfig. Beware of this when you configure S/MIME settings and the S/MIME Plugin is not available in your Outlook on the web client.

TechNet states clearly:

“If the encryption algorithm or minimum key length is not available on a client, Outlook on the web does not allow encryption.”


The string to used when configuring the OWAEncryptionAlgorithms for AES256 and AES128  is

Set-SmimeConfig –OWAEncryptionAlgorithms "6610;660E"

When not using quotation marks, you will receive an error message. But the cmdlet will accept a comma separated list. A comma separated list results in the follow Get-SMimeConfig output

Set-SmimeConfig –OWAEncryptionAlgorithms 6610,660E

OWAEncryptionAlgorithms                          : 660E 6610

This setting results in S/MIME not being available in Outlook on the web.


To successfully apply S/MIME configuration changes, restart the application or restart the Exchange server.

Get-ExchangeServer | ? { $_.AdminDisplayVersion -like '*15.*'} | % { Invoke-Command -ComputerName $_.Name -ScriptBlock {Restart-WebAppPool MSExchangeOWAAppPool} }


Read More »


When you install the Exchange Server Security Update KB 3087126 on a server running the Exchange Server 2013 management tools only, you might receive an error message when starting the Exchange Management Shell.

The error might look like this:

PowerShell Error KB3087126

The error message indicates that WinRM is having issues.This is not the case.

The problem occues due to registry changes performed by the patch setup and due to the way how ConnectFunctions.ps1 (used by RemoteExchange.ps1) determines the Exchange Server to connect to.

The script tries to connect to the local FQDN, if any Exchange role is installed on the local server. This is determined by querying the registry using the following command:

if (@(get-item HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\*role -erroraction:silentlycontinue).length -gt 0)

The queried registry does not exist prior to installation of KB 3087126.

Regustry Keyy added by KB3087126 on a Management Tools only server


When having installed the Exchange Server 2013 management tools only, which might be the case on a monitoring or scheduled task server, do the following:

  • Delete the registry key ClientAccessRole
  • Open a new Exchange Power Shell session

Enjoy the Exchange Management Shell.



Mailscape 365 - Hybrid Exchange & Office 365 Monitoring and Reporting
Many organizations are choosing to use a mix of on-premise Microsoft Exchange and hosted Office 365 to meet their staff needs. These deployments, however, are challenging to support, with several 'moving parts' that need to be monitored in order to ensure reliable messaging and calendaring services - Test Drive Mailscape for Exchange Online


Read More »

Uninstalling Exchange Server 2013 will fail, if the PowerShell MachinePolicy or UserPolicy is set by GPO.

You will receive an error message referencing Microsoft KB article 981474, which refers primarily to Exchange Server 2010.

Screenshot showing the PowerShell Execution Policy Error

The following PowerShell command removes the GPO setting.

Set-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\PowerShell -Name ExecutionPolicy –Value ""

After setting the ExecutionPolicy attribute to an empty string, Exchange Server 2013 can be uninstalled successfully.




Do you plan to deploy Exchange Server 2016 or do you plan go hybrid with Office 365? Check out the enterprise technology services provides by Granikos

Read More »