Using check_ncpa to check MS Exchange Queue

[shoreypu]

We have a request to monitor our Exchange 2016 Queue. I've tried calling a couple different PowerShell scripts, including NagiosMonitoring_Exchange2016QueueHealth_V2.2.ps1, but I'm getting the same error attempting to load the SNAP-IN (see below). I've seen a number of posts about setting up the Exchange Queue checks, but it looks like that's been with NSClient. We are using NCPA. I believe this is a credentials/access issue. Thanks in advance for your help.


-M "plugins/NagiosMonitoring_Exchange2016QueueHealth_V2.2.ps1"
Add-PSSnapin : No snap-ins have been registered for Windows PowerShell version
5.
At C:\Program Files
(x86)\Nagios\NCPA\plugins\NagiosMonitoring_Exchange2016QueueHealth_V2.2.ps1:62
char:4
+ Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (Microsoft.Excha...werShell.Sna
pIn:String) [Add-PSSnapin], PSArgumentException
+ FullyQualifiedErrorId : AddPSSnapInRead,Microsoft.PowerShell.Commands.Ad
dPSSnapinCommand

Get-Queue : The term 'Get-Queue' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or
if a path was included, verify that the path is correct and try again.
At C:\Program Files
(x86)\Nagios\NCPA\plugins\NagiosMonitoring_Exchange2016QueueHealth_V2.2.ps1:74
char:20
+ ForEach ($Queue in Get-Queue -Server $env:computername)
+ ~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Get-Queue:String) [], CommandNo
tFoundException
+ FullyQualifiedErrorId : CommandNotFoundException

OK: All mail queues within limits. |queue=;10;20;0

[ssax]

Please make sure that you run the PowerShell on the Exchange Server host.

Please run this command on the system you're running it on and send us the full output:

Code: Select all

get-pssnapin –registered

Please attach your ncpa.cfg file from the remote NCPA host as well. This may be a 32 vs 64 bit powershell issue.

[shoreypu]

get-pssnapin –registered

Name : EnginePSSnapin
PSVersion : 2.0
Description : Register cmdlets for Content Engine

Name : HostControllerPSSnapIn
PSVersion : 2.0
Description : Register cmdlets for Host Controller

Name : InteractionEnginePSSnapIn
PSVersion : 2.0
Description : Register cmdlets for InteractionEngine

Name : JunoPSSnapin
PSVersion : 2.0
Description : Register cmdlets for Juno

Name : Microsoft.Exchange.Management.PowerShell.E2010
PSVersion : 1.0
Description : Admin Tasks for the Exchange Server

Name : Microsoft.Exchange.Management.PowerShell.Setup
PSVersion : 1.0
Description : Setup Tasks for the Exchange Server

Name : Microsoft.Exchange.Management.PowerShell.SnapIn
PSVersion : 1.0
Description : Admin Tasks for the Exchange Server

Name : Microsoft.Exchange.Management.Powershell.Support
PSVersion : 1.0
Description : Support Tasks for the Exchange Server

Name : Microsoft.Forefront.Filtering.Management.PowerShell
PSVersion : 2.0
Description : Microsoft Forefront Filtering PowerShell Interface

Name : SearchCorePSSnapIn
PSVersion : 2.0
Description : Register cmdlets for SearchCore

I've attached the ncpa.cfg. It is set to 32-bit (default), but I did try switching to 64-bit as described in the file,
Since windows NCPA is 32-bit, if you need to use 64-bit powershell, try the following for
# the powershell plugin definition:
# .ps1 = c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -ExecutionPolicy Unrestricted -File $plugin_name $plugin_args

Of note, we have a policy set to allow PowerShell in RemoteSigned.

[ssax]

Is your ncpa_listener service running as Local System or something else? If Local System it should have permissions to do it.

I can't really think of any other reason that it would be failing, it has to be the 32/64 thing. I found through some searching it requires 64 bit powershell.

Please try doing it again, edit your ncpa.cfg and change this:

Code: Select all

.ps1 = powershell -ExecutionPolicy Bypass -File $plugin_name $plugin_args

To this:

Code: Select all

.ps1 = c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -ExecutionPolicy Unrestricted -File $plugin_name $plugin_args

Then restart the ncpa_listener service and test.

Let us know the results.

[shoreypu]

I assume that the changes to the ncpa.cfg needed to be made on the the Windows client, not the Nagios server.
I updated the ncpa.cfg as suggested, but I get the same error.
So I then created a custom PS script to give me the bit version of PowerShell using the following command:
[System.Environment]::Is64BitProcess
If I run it on the local system, I get back true, however, if I run the script from the Nagios command line, I get false.
I then tried changing the path in the ncpa.cfg to system32, instead of sysnative, still false.
I then tried changing powershell.exe into something random and it still ran powershell and returned false.
So its as if the path is in the ncpa.cfg isn't being recognized.
We are running NCPA version 2.1.8.

[ssax]

I just labbed it up with both 2.1.8 and 2.2.0 and they are both working.

Please create a ticket for this and include a link back to this forum thread so we can get a remote session setup:

Code: Select all

https://support.nagios.com/tickets/

[cdienger]

If you run that exectuable onthe command line:

Code: Select all

c:\windows\sysnative\windowspowershell\v1.0\powershell.exe

and then

Code: Select all

[Environment]::Is64BitProcess 

does it return true?

What if you try running:

Code: Select all

%SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe 
[Environment]::Is64BitProcess

[shoreypu]

So I believe I have resolved the powershell problem with ncpa.cfg. It looks as though puppet was not disabled, as expected. I was able to correct the issue and run some further testing on my test system:

puppet agent --disable "testing"
Stop the NCPA Listener
Update the ncpa.cfg
Start the NCPA Listener

.ps1 = powershell -ExecutionPolicy Bypass -File $plugin_name $plugin_args
Result: False
.ps1 = c:\windows\sysnative\windowspowershell\v1.0\powershell.exe -ExecutionPolicy Unrestricted -File $plugin_name $plugin_args
Result: True

I'm still working with our Exchange admin to verify that this resolves the issue on his system and that the script will report results.

[ssax]

Sounds good, let us know the results.