SAM Microsoft Windows Server 2008 R2-2012 R2 Failover Cluster (Advanced) template fails with errors and node status switches to Down

11/16/2018 9:53 PM

11/16/2018 9:53 PM

This article describes a scripting workaround to use if SAM polling fails for the Microsoft Windows Server 2008 R2-2016 Failover Cluster (Advanced) template, the node status switches to Down, and you receive the following error:

The return code is different than expected. Testing on node failed with "Down" status. ('Down' might be different if script exits with a different exit code.)

The assembly 'C:\Windows\Cluster\FailoverClusters.ObjectModel.dll' was not loaded because no assembly with that name was found. Verify the assembly name, and then try again.

You may receive a similar error if you run this template via an agent: 
 

import-module : The specified module 'failoverclusters' was not loaded because no valid
module file was found in any module directory.

The assembly 'C:\Windows\Cluster\FailoverClusters.ObjectModel.dll' was not loaded because no assembly with that name was found. Verify the assembly name, and then try again. 

 

Server Application Monitor

The 64-bit FailoverClusters module conflicts with PowerShell bitness so polling fails.

As detailed in this THWACK post, PowerShell sessions start from within the Windows PowerShell Monitor (WPsM). To execute WPsM, SAM uses an Orion Job Engine Worker Process (JEP) to open a new PowerShell runspace. In Local Host or Agent execution mode, this can cause the PowerShell runspace to use the same .NET runtime version as the JEP, regardless of which PowerShell version is installed. 

Another consequence is that the PowerShell runspace follows the bitness of JEP so it can pass objects between .NET assemblies code and PowerShell scripts. Because the FailoverClusters module is 64-bit only, it fails with errors and the node status switches to Down. 

Create a copy of the Microsoft Windows Server 2008 R2-2012 R2 Failover Cluster (Advanced) template and modify it by adding a script within another script to launch an external PowerShell process while using a x64 PowerShell executable that matches the bitness of the FailoverClusters module.

The following example uses an EXE in a different directory when it detects a 64-bit running environment: 
 

write-host "Statistic.WorkerProcessPID : $pid"  
  
if ([IntPtr]::size -eq 4){  
     Set-Alias ps64 "$env:windir\SysNative\WindowsPowerShell\v1.0\powershell.exe"  
}else{  
     Set-Alias ps64 "$env:windir\System32\WindowsPowerShell\v1.0\powershell.exe"  
}  
  
ps64 {  
     write-host "Statistic.InnerPowerShellPID : $pid"  
       
     $test1 = ([IntPtr]::size -eq 8)  
     write-host "Message.Is64BitProcess : Is 64bit Process? $(({Yes}, {No})[!$test1])"    
     write-host "Statistic.Is64BitProcess : $([int]$test1)"  
  
     $test2 = ([IntPtr]::size -eq 4)  
     write-host "Message.Is32BitProcess : Is 32bit Process? $(({Yes}, {No})[!$test2])"     
     write-host "Statistic.Is32BitProcess : $([int]$test2)"  
}  

To download a template with code samples like this one, see https://thwack.solarwinds.com/docs/DOC-189738.

Disclaimer: Please note, any content posted herein is provided as a suggestion or recommendation to you for your internal use. This is not part of the SolarWinds software or documentation that you purchased from SolarWinds, and the information set forth herein may come from third parties. Your organization should internally review and assess to what extent, if any, such custom scripts or recommendations will be incorporated into your environment.  You elect to use third party content at your own risk, and you will be solely responsible for the incorporation of the same, if any.