--------------------- Module Versions ---------------------
Warning - one or more of your Perl Modules are out of date and this may cause plugin problems. If you are having any problems with Check WMI Plus you must upgrade your Perl Modules before contacting support (since they'll just tell you to upgrade!). You can override this warning at your peril by using the --IgnoreMyOutDatedPerlModuleVersions command line option or the "$ignore_my_outdated_perl_module_versions" setting in the conf file (/usr/local/nagios/libexec/check_wmi_plus.conf). Version Information on the next line.
MODULE_NAME INSTALLED_VERSION STATUS DESIRED_VERSION
Config::IniFiles 2.94 ok 2.58
Perl Version 5.010001 ok 5.01
Getopt::Long 2.38 ok 2.38
DateTime 0.53 BAD 0.66
Number::Format 1.75 ok 1.73
Data::Dumper 2.124 BAD 2.125
Scalar::Util 1.47 ok 1.22
Storable 2.20 BAD 2.22
Net::DNS -
--------------------- Environment ---------------------
ENV=$VAR1 = {
'HOME' => '/root',
# Failed test '$DateTime::IsPurePerl is true'
# at t/39no-so.t line 33.
Can't locate object method "new" via package "DateTime" at t/39no-so.t line 35.
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 2 just after 2.
t/39no-so.t .............. Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/2 subtests
You might get updates to some of those perl modules simply by running yum -y update
If you're concerned about disk space, or compatibility issues, you could run yum update and then get a list of what's going to be installed, but since it sounds like time is of the essence, the -y will speed things up a bit for you.
So, this might actually be a setting on the Windows side. I ran the tests against a different set of servers and came up with the expected results. I didn't think to look at the Windows side because it DOES work when there are events discovered. In any case. I will compare the settings and post what I find here.
Both Servers are Windows 2008R2 Enterprise SP1 servers. Both Versions of WMI are 7601.17514.
It turns out -- ALL of my WMI commands return this error:
OUTPUT: [librpc/rpc/dcerpc_connect.c:329:dcerpc_pipe_connect_ncacn_ip_tcp_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_ncacn_ip_tcp_recv
[librpc/rpc/dcerpc_connect.c:790:dcerpc_pipe_connect_b_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_b_recv
CLASS: Win32_ComputerSystem
running the -d -d options any of the WMI check commands show this error, in ADDITION to the results found. It only shows through in the UI on the CheckEventLog results when there are no OTHER results to display. My research on the c00000b5 error code points to either a DNS issue or a Firewall issue. I will look into these with my network team and see if there is an issue here. I assumed no because I was able to ping the FQDN and since the other queries receive results I was not looking for error messages in them. It Appears WMI communicates intitially on 135, then chooses a random high numbered port to send data.
I will post the results here.
I have not been able to figure this one out. The Network team states there are no restrictions placed between the networks that would prevent WMI communication.
Running a simple WMIC query from the command line produces the same results.
wmic -U DOMAIN/USERNAME%PASSWORD --namespace="root\cimv2" //SERVER.FQDN "select * from Win32_OperatingSystem"
[librpc/rpc/dcerpc_connect.c:329:dcerpc_pipe_connect_ncacn_ip_tcp_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_ncacn_ip_tcp_recv
[librpc/rpc/dcerpc_connect.c:790:dcerpc_pipe_connect_b_recv()] failed NT status (c00000b5) in dcerpc_pipe_connect_b_recv
CLASS: Win32_OperatingSystem
BootDevice|BuildNumber|BuildType|Caption|CodeSet|CountryCode|CreationClassName|CSCreationClassName|CSDVersion|CSName|CurrentTimeZone|DataExecutionPrevention_32BitApplications|DataExecutionPrevention_Available|DataExecutionPrevention_Drivers|DataExecutionPrevention_SupportPolicy|Debug|Description|Distributed|EncryptionLevel|ForegroundApplicationBoost|FreePhysicalMemory|FreeSpaceInPagingFiles|FreeVirtualMemory|InstallDate|LargeSystemCache|LastBootUpTime|LocalDateTime|Locale|Manufacturer|MaxNumberOfProcesses|MaxProcessMemorySize|MUILanguages|Name|NumberOfLicensedUsers|NumberOfProcesses|NumberOfUsers|OperatingSystemSKU|Organization|OSArchitecture|OSLanguage|OSProductSuite|OSType|OtherTypeDescription|PAEEnabled|PlusProductID|PlusVersionNumber|Primary|ProductType|RegisteredUser|SerialNumber|ServicePackMajorVersion|ServicePackMinorVersion|SizeStoredInPagingFiles|Status|SuiteMask|SystemDevice|SystemDirectory|SystemDrive|TotalSwapSpaceSize|TotalVirtualMemorySize|TotalVisibleMemorySize|Version|WindowsDirectory
RESULTS
Actual system results have been removed. If I run the same command with an IP instead of an FQDN, the query executes normally.
I have not been able to trace down the exact cause of the error, but as a work around for now we will likely set Nagios to not notify on the Unknown state of this check. Later, If I get time I might try to update the script to resolve the FQDN to an IP before executing the WMIC query.
If the IP is working, but FQDN is not - I would look to see if it's defaulting to IPv6, or perhaps a bad resolution of the DNS name. Does a nslookup <hostname> show anything? Are you able to run it through an strace and post the result? This might show us some useful information as to why it's failing.
Does ping run successfully? Can you show us the result of a nmap <IP> and nmap <FQDN>?
To run a strace, you'll just need to install it first. yum install strace - this will output more of the process that's actually happening internal to the command you run.
Then, run the checks with 'strace' in front of the, for example, 'strace uptime'. Post the output for the IP, and FQDN.