Compartilhar via

Exchange Management Shell Scripts and Update Rollup installations start failing in Exchange 2010

  • Artigo

Throughout the last few months, we had several customer support cases and escalations on failing Update Rollup (UR) installations and failing DAG maintenance scripts (or other scripts) in Exchange 2010. Several Exchange 2010 PowerShell scripts, including scripts that are contained within the UR installer, stopped working as expected. Customers started to see errors like:

 

==========================================================

[PS] D:\Program Files\Microsoft\Exchange Server\V14\scripts>.\RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution -Confirm:$false

At C:\Program Files\Microsoft\Exchange Server\V14\scripts\RedistributeActiveDatabases.ps1:1928 char:3

+         return $moveSuccessful

+         ~~~~~~~~~~~~~~~~~~~~~~

Control cannot leave a finally block.

At C:\Program Files\Microsoft\Exchange Server\V14\scripts\RedistributeActiveDatabases.ps1:2538 char:5

+                 return $success

+                 ~~~~~~~~~~~~~~~

Control cannot leave a finally block.

    + CategoryInfo          : ParserError: (:) [], ParseException

    + FullyQualifiedErrorId : ControlLeavingFinally

================================================

 

or an Update Rollup installation might fail with EventID 1024, Source: MSIInstaller, Error Code 1603

================================================

Product: Microsoft Exchange Server - Update 'Update Rollup 8-v2 for Exchange Server 2010 Service Pack 3 (KB2986475) 14.3.224.2' could not be installed. Error code 1603. Windows Installer can create logs to help troubleshoot issues with installing software packages. Use the following link for instructions on turning on logging support: https://go.microsoft.com/fwlink/?LinkId=23127
================================================

 

It turned out that these errors appear when the Exchange scripts (either run by the administrator or run automatically in the background by the UR Installer) were run with Version 4.0 of the PowerShell Engine, instead of Version 2.0.

You can check what version of PowerShell is running in the Exchange Management Shell by running:
$PSVersionTable.PSVersion

 

PowerShell Version 4.0 is included in the Windows Management Framework 4.0 (WMF4.0), which is supported on an Exchange 2010 Server, however: Windows Management Framework 4.0 can be used to perform operating system-related management tasks on a computer that's running Exchange 2010 SP3 RU5 or later. However, Exchange 2010 cmdlets and Exchange 2010 scripts require Windows PowerShell 2.0. Using Exchange 2010 cmdlets and scripts with Windows Management Framework 4.0 isn't supported.

Reference: Exchange Server Supportability Matrix

But why is the Exchange Management Shell (EMS) running on PowerShell 4.0?

Checking the shortcut for the EMS, we can see that we want to use Powershell Version 2.0 explicitly:

================================================
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 2.0 -noexit -command ". 'C:\Program Files\Microsoft\Exchange Server\V14\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto"
================================================

 

Using Process Monitor we found out that there is another file involved during EMS startup:

================================================
11:38:20.5522502 AM powershell.exe 140 QueryDirectory C:\Program Files (x86)\Common Files\NetApp\powershell.exe.activation_config SUCCESS Filter: powershell.exe.activation_config, 1: powershell.exe.activation_config
================================================

It turned out that this is an XML file and part of NetApp’s “SnapDrive for Windows 7.x” and “SnapManager for Exchange 7.x”. Once these products are deployed in version7.x on your Exchange Server, every PowerShell session is forced to start in version 4.0. That’s the root cause of your failing scripts and Update Rollup installations.
If you are affected or if you are using the product versions mentioned above to backup Exchange 2010, please check the NetApp KB-article 2026403 for a solution:

Exchange 2010 PowerShell scripts fail to run after installing SnapManager for Exchange 7.1 https://kb.netapp.com/support/index?page=content&id=S:2026403&actp=LIST

Ralf Leistner (MSFT)