Sunday, August 7, 2016

Exchange 2010 (SP3) - PowerShell 4 and scripts

PowerShell 4.0 (PS4) is now compatible with Exchange 2010 SP3 provided that Rollup 5 (or above) is installed.

This is a welcome change for those using NetApp storage, as the most recent versions of the SnapDrive and Snap Manager for Exchange (backup) software require PS4 as a pre-requisite.

However, some users have noticed that although PS4 is now supported, scripts like the StartDagMaintenance.ps1 script will not execute:

StartDagServerMaintenance fails during checkdatabaseredundancy

Indeed, this is stated in the Exchange 2010 Supportability Matrix:

Exchange Server Supportability Matrix

Windows Management Framework 3.0 and 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 3.0 or Windows Management Framework 4.0 isn't supported. 

Note: PowerShell is part of the Windows Management Framework (WMF). If we want to have PS4, for example, we install WMF4.

Having observed some problems with the Exchange DAG maintenance scripts myself (besides the discussion in the link above), I wanted to study the interaction between PowerShell 4 and these scripts in a test environment. If the problem is confirmed, I intend to elaborate a workaround solution (probably executing the cmdlets in the script manually).

***

Here is the status quo of my two Exchange 2010 servers...

The PowerShell version is 2:




I have installed Rollup 14 (Exchange 2010 SP3 Rollup 5 is the lowest version compatible with PS4):




The Exchange servers are named EX13-1 and EX13-2 (despite the "13" these are indeed Exchange 2010 servers).

We have a Database Availability Group (DAG) configured. EX13-1 and EX13-2 are both members. At this time, EX13-2 holds both the "active" copy of the mailbox database "DB1" and the "Primary Active Manager" (PAM) role:

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | fl name,status

Name   : DB1\EX13-1
Status : Healthy

Name   : DB1\EX13-2
Status : Mounted


Get-DatabaseAvailabilityGroup -s | fl *primary*

PrimaryActiveManager : EX13-2



Let's verify that the DAG script works now (with PowerShell 2.0):



That seems to be the case (no news - or error messages - is good news with PowerShell).

Note: click on the images to enlarge.


Also notice the change concerning the mailbox database, now mounted on EX13-1, and the PAM:

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | fl name,status

Name   : DB1\EX13-1
Status : Mounted

Name   : DB1\EX13-2
Status : Healthy


Get-DatabaseAvailabilityGroup -s | fl *primary*

PrimaryActiveManager : EX13-1


So the script functions perfectly fine with PowerShell 2.


***


Now we'll install PS4 and see what happens.

PowerShell 4 (PS4) is part of the Windows Management Framework 4.0 package (WMF4), so we obtain PS4 by installing WMF4 on the server.

We can download WMF4 at this link:

Windows Management Framework 4.0

This is the file that is appropriate for Windows 2008 R2 (SP1):



Note: if you have Windows 2012, there is a different file.

Once again, WMF 4.0 is presented as being compatible with Exchange 2010 SP3 (if Rollup 5 - or above - is installed):


I will not illustrate each step of the installation with screenshots. It's essentially a matter of clicking "OK", "Next", etc., and restarting the server.


What version of PowerShell do we have now?

Surprise...

In the Exchange Management Shell (EMS), it is still PS2 but in the "regular" PS, it is now PS4:



Note: the same is true on the other Exchange server after installation of WMF4.

I noted that the shortcut to the EMS does refer to PS2:

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"

Moreover, our DAG scripts seem to execute.

In fact, they do execute, consistently (numerous attempts were made), on both Exchange servers.



Note: It looks like new versions of PS uninstall previous versions - with a particular exception for PS2:


So PS4 can still run scripts in "PS2 mode" but PS2 is no longer present as an autonomous program or set of commands.


***


This is a good result but not consistent with what others have reported (even though, supposedly, they have a rollup equal or superior to RU5) and what I have observed elsewhere myself.

At this point, I am going to proceed as I would have, if the scripts did not run.

How could we perform each of the operations (manually) if the script will not execute for some reason (or not completely)?

Besides finding a workaround, useful if we encounter the problem elsewhere, this is also an opportunity to understand the function of the DAG script better.

What actually happens?

I will use these directions:

StartDagServerMaintenance.ps1 script fails in an Exchange Server 2010 environment


Step 1

We first determine if there is another "healthy" (and "non-lagged") Exchange server to which we can fail over the mailbox databases:

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | fl name,status

Name   : DB1\EX13-1
Status : Mounted

Name   : DB1\EX13-2
Status : Healthy


Yes, the mailbox database DB1 is "mounted" on EX13-1 and we have a healthy copy on EX13-2 that we can make active (that, essentially, is the "fail over" process).


Step 2

We move the active copy of the mailboxes off the server (that will undergo maintenance) with this cmdlet:

Move-ActiveMailboxDatabase -Server EX13-1



Note: we could also use this cmdlet that specifies the database, the server on which we want to activate the database, and the override setting:

Move-ActiveMailboxDatabase -Identity 'DB1' -ActivateOnServer 'EX13-2' -MountDialOverride 'None'


Step 3

We move the PAM role with this command:

cluster dag1.mynet.lan group "Cluster Group" /moveto:EX13-2



We can confirm the PAM was moved:

Get-DatabaseAvailabilityGroup -s | fl *primary*

PrimaryActiveManager : EX13-2


Some notes on this command (not a PS cmdlet although we can execute it in the EMS):

Do I need to move my cluster core resources?




Step 4

We suspend activation on the mailbox copies on the server that will undergo maintenance. We want to prevent activation of these mailboxes while maintenance is taking place.

Here is the status quo:

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | fl name,status

Name   : DB1\EX13-1
Status : Healthy

Name   : DB1\EX13-2
Status : Mounted


I execute this cmdlet (suspending activation only):

Get-MailboxDatabaseCopyStatus -Server EX13-1 | Suspend-MailboxDatabaseCopy -ActivationOnly:$true


I notice that the "Status" of the mailbox does not change but the "ActivationSuspended" value does:

Get-MailboxDatabase | Get-MailboxDatabaseCopyStatus | fl name,activation*

Name                : DB1\EX13-1
ActivationSuspended : True

Name                : DB1\EX13-2
ActivationSuspended : False



Step 5

I pause the cluster node (Exchange server) where maintenance will take place:

cluster dag1.mynet.lan node EX13-1 /pause




Step 6

Lastly, I block activation of the (mailbox) server itself:

Set-MailboxServer EX13-1 -DatabaseCopyAutoActivationPolicy:Blocked



Now the server in question cannot host the active copy of a mailbox database, which we want to prevent during maintenance.


***


At this point, we perform maintenance (install updates, etc.) restart the server if necessary and are ready to resume normal operations.


Step A

We resume cluster operations on the node in question:

cluster dag1.mynet.lan node EX13-1 /resume




Step B

We unblock activation on the server:

Set-MailboxServer EX13-1 -DatabaseCopyAutoActivationPolicy:Unrestricted



Step C

We resume mailbox database copy operations (in fact, it was only activation that we suspended so that is all that needs to be resumed):

Get-MailboxDatabaseCopyStatus -Server EX13-1 | Resume-MailboxDatabaseCopy


***

Even though the DAG maintenance scripts seemed to function just fine, I was able to test the manual procedure above and everything seemed to work there as well.



No comments:

Post a Comment