none
SCOM 2016 - WMI is unhealthy RRS feed

  • Question

  • I'm currently in the middle of a side-by-side migration of SCOM 2012 R2 to SCOM 2016.

    I've been receiving quite of few "WMI is unhealthy" alerts in SCOM 2016, in fact 6 of the 12 servers I've moved to SCOM 2016 have reported these errors. The servers in question never had "WMI is unhealthy" errors in SCOM 2012. I also built a fresh Windows 2012 R2 server to troubleshoot, and still received "WMI is unhealthy" errors. I've gone though all the WMI troubleshooting steps listed in scom alert and everything with WMI seems fine. Since these servers never had these issues in SCOM 2012, I lean towards this being a bug.

    Has anyone noticed  "WMI is unhealthy" alerts in SCOM 2016 also? Is this a known bug? Does anyone have any troubleshooting steps that are not under the Resolutions in the SCOM alert? 

    Thanks.

    Friday, December 16, 2016 3:00 PM

Answers

All replies

  • The monitor responsible for this check has been rewritten in scom 2016, from vbs to powershell : 

    2012 r2 : http://systemcentercore.com/?GetElement=Microsoft.SystemCenter.WMIFunctionalCheck.Probe&Type=ProbeActionModuleType&ManagementPack=Microsoft.SystemCenter.2007&Version=7.1.10226.1118

    2016 : http://systemcentercore.com/?GetElement=Microsoft.SystemCenter.WMIFunctionalCheck.Probe&Type=ProbeActionModuleType&ManagementPack=Microsoft.SystemCenter.2007&Version=7.2.11719.0

    That being said, I can't know for sure the reason why it's failing on your environment... do you have any error message on the Operations Manager log on these servers?


    • Edited by CyrAz Friday, December 16, 2016 3:39 PM
    Friday, December 16, 2016 3:39 PM
  • I found the following Event on one of the affected servers:

    Description:

    The PowerShell script failed with below exception

    System.Management.Automation.ActionPreferenceStopException: The running command stopped because the preference variable "ErrorActionPreference" or common parameter is set to Stop: WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred.
    Possible causes are:
    -The user name or password specified are invalid.
    -Kerberos is used when no authentication method and no user name are specified.
    -Kerberos accepts domain user names, but not local user names.
    -The Service Principal Name (SPN) for the remote computer name and port does not exist.
    -The client and remote computers are in different domains and there is no trust between the two domains.
    After checking for the above issues, try the following:
    -Check the Event Viewer for events related to authentication.
    -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
    Note that computers in the TrustedHosts list might not be authenticated.
    -For more information about WinRM configuration, run the following command: winrm help config.At line:106 char:15
    + $checker = Get-CimInstance -ComputerName $ComputerName -Namespace "root\cimv2 ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    at System.Management.Automation.Internal.PipelineProcessor.SynchronousExecuteEnumerate(Object input, Hashtable errorResults, Boolean enumerate)
    at System.Management.Automation.PipelineOps.InvokePipeline(Object input, Boolean ignoreInput, CommandParameterInternal[][] pipeElements, CommandBaseAst[] pipeElementAsts, CommandRedirection[][] commandRedirections, FunctionContext funcContext)
    at System.Management.Automation.Interpreter.ActionCallInstruction`6.Run(InterpretedFrame frame)
    at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)
    at System.Management.Automation.Interpreter.EnterTryCatchFinallyInstruction.Run(InterpretedFrame frame)




    Script Name: SCOMpercentageCPUTimeCounter.ps1

    Monday, December 19, 2016 8:52 PM
  • Hi Sir,

    >>The following error with errorcode 0x80090322 occurred while using Kerberos authentication: An unknown security error occurred. 

    Please confirm that the management server and "agents" are in same domain .

    If yes , have you applied some group policy on these servers ?

    If yes , I'd suggest you to perform "block inheritance " for them and update group policy then try again .

     

    Best Regards,

    Elton


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.

    Tuesday, December 20, 2016 6:59 AM
    Moderator
  • The management servers and all agents are on the same domain.

    Group policy is applied, I blocked inheritance on a group of the servers, no change.

    Thursday, December 22, 2016 1:09 PM
  • In my opinion, it's possible that the existing HTTP/SERVERNAME SPN registered under the domain account is related the error. Please try the action below:
    1. On the server, change IIS application pool to run under Local System.
    2. Run the following commands to remove existing SPN:

        setspn -D HTTP/SERVERNAME <domain account>
        setspn -D HTTP/SERVERNAME.DOMAINAME.COM <domain account>

    3. Then connect to the server again to see what will happen.
    If the issue remains, disable Kernel mode authentication in IIS management console.


    Roger

    Friday, December 23, 2016 3:40 AM
  • On one of the servers I'm having problems with, the issue seems to be with the MBAM web services. The APP Pool user account for MBAM has the HTTP/SERVERNAME and HTTP/SERVERNAME.DOMAIN.COM SPN's on that account. When I remove the SPN's from MBAM and add them to the server account, it fixes the SCOM agent, but breaks MBAM.

    Is there a work around for this situation?

    Tuesday, December 27, 2016 4:54 PM
  • I have this exact issue. The only server I've attempted to manage with that gets this error is an MBAM server. Thanks for any advice SCOM team. 
    Thursday, January 12, 2017 9:50 PM
  • Same "WMI is unhealthy" alert after upgrade from SCOM 2012 R2 to 2016 RTM. Alert raised for agents on Server 2012/R2 systems in workgroups which attached directly to MS (not by GMS) with certificate auth. Can I ignore that or not?
    Wednesday, January 25, 2017 7:10 PM
  • My problem is gone. On the client system I added client server computer NetBIOS name and FQDN to WMI Trusted hosts.
    Thursday, January 26, 2017 11:00 AM
  • Can you tell me the steps to follow? How can I add the NetBIOS and FQDN to WMI trusted hosts?
    Thursday, February 2, 2017 3:48 PM
  • I have the same issue with my MBAM servers as well as all of my Configuration Manager distribution points running Windows Server 2012. Strangely, my distribution points running Windows Server 2012 R2 do not have the problem.

    I have tried the following in PowerShell to add the computer NetBIOS name and FQDN to WMI trusted hosts, but it didn't help:

    Set-Item WSMan:\localhost\Client\TrustedHosts -Value "NetBIOS,FQDN"

    I also tried setting the above value to "*" and rebooting, but it didn't help. I also tried setting the default action account to a domain account that is a local administrator on the server, but I still have the same issue. Has anyone had any success with these steps?

    --Russel

    Tuesday, February 7, 2017 4:15 PM
  • Hi,
    I have the same issue with some of my agents placed in the same domain as the management servers after upgrade from 2012 R2 to 2016.

    It looks like the issue is when HTTP/SERVERNAME and HTTP/SERVERNAME.fqdn is registered to a service account instead of the computer object.

    For some systems/applications this is the correct way to to register SPN, how can i get the SCOM monitoring running without changing the registered SPN?
      
    Anders

    • Edited by andgi Monday, February 13, 2017 11:57 AM
    Monday, February 13, 2017 11:56 AM
  • We moved our environment from SCOM 2012 to SCOM 2016. Servers that were healthy in SCOM 2012 are having WMI is unhealthy" and "Powershell scipts failed to run" in SCOM 2016. All checks I can do to WMI seem to be fine.
    Thursday, February 16, 2017 8:10 PM
  • Got this at a number of customers as well. Cannot really change the HTTP SPN's as that would break their applications.

    We have tried adding port specific SPNs for winrm to use:

    setspn -S HTTP/computername.domain.fqdn:5985 DOMAIN\COMPUTERNAME
    setspn -S HTTP/computername.domain.fqdn:5986 DOMAIN\COMPUTERNAME
    setspn -S HTTP/computername:5985 DOMAIN\COMPUTERNAME
    setspn -S HTTP/computername:5986 DOMAIN\COMPUTERNAME

    But that didn't help.

    Here's some oddities though:

    # This is what the monitor does, FAILS
    Get-CimInstance -ComputerName COMPUTER.domain.fqdn -NameSpace "root\cimv2" -Query "select Status from win32_operatingsystem"
    
    # We tested wsman, WORKS
    Test-WSMan -ComputerName COMPUTER.domain.fqdn
    
    # Same query, different cmdlet, WORKS!
    Get-WmiObject -Query "select Status from win32_operatingsystem" -ComputerName COMPUTER.domain.fqdn

    What's the difference in how Get-CimInstance and Get-WmiObject works? Would it be possible for the MP-devs to use Get-WmiObject instead as that seems to work better when other applications use the HTTP SPN?

    edit: I realize now that Get-WmiObject works because it connects directly to WMI while the Cim-cmdlets connect via WSMAN. 


    Tuesday, February 21, 2017 10:39 AM
  • I'm also having the same errors on my Windows 2016 servers. SCOM is the only servers in Windows 2016. I have the WMI is unhealthy on the DB server and powershell scripts fail to run on both the management server and the SQL database server. Is this a bug?
    Sunday, February 26, 2017 12:49 PM
  • The reason for this happening is if you have set an SPN for the machine name on a domain user account for HTTP. If you have this, the Get-CimInstance call from SCOM will fail as it needs also to use the HTTP SPN. 

    Registering an SPN for WinRM with HTTP/ServerName:5985 will also fail as Get-CimInstance does not send the port with the call. For this to happen the code must be rewritten to take account for this. 

    Here is an example of how the discovery code in SCOM has to change:

    # Will need to fetch a RunAs Account with rights to create the CimSession object
    $Credentials = RunAsAccount
    
    $query = "Select Domain, Name, NumberOfLogicalProcessors, NumberOfProcessors from Win32_ComputerSystem"
    
    Get-CimInstance -ComputerName $strDNSComputerName -Namespace "root\cimv2" -Query $query -ErrorAction SilentlyContinue -ErrorVariable CimError
    
    If($cimError) {
        # Use if SPN with WS-Man port is set on computer object in AD
        Try{
            $CimSessionOption = New-CimSessionOption -EncodePortInServicePrincipalName 
            $CimSession = New-CimSession -Name Win32 -ComputerName $strDNSComputerName -Authentication Default -Credential $Credentials -SessionOption $CimSessionOption
            Get-CimInstance -ComputerName $strDNSComputerName -Namespace "root\cimv2" -Query $query -CimSession $CimSession -ErrorAction Continue
        }
        Catch {
            # Do error stuff
            Get-WmiObject -ComputerName $strDNSComputerName -Namespace "root\cimv2" -Query $query -ErrorVariable WmiError -ErrorAction Stop
        }
        Finally {
            If($CimSession) {
                # Close the CIM session
                $CimSession.Close()
                $CimSession.Dispose()
            }
            $cimError = $Null
        }
        
    }

    Though the easiest fix might be to add in Get-WmiObject as I have done under the catch part. Also this is just an example, for actual implementation I would have written it a bit differently. This is just taken directly from Microsoft.SystemCenter.Internal MP and moved some code around.

    The problem is in the Mirosoft.SystemCenter.2007 (System Center Core Monitoring) and Microsoft.SystemCenter.WMIFunctionalCheck.Probe. One needs to add something of the code changes I suggest above. 

    if($isHigherThanWin08 -eq $true)
        {
    		try{
    			$wbemObjectSet = Get-CimInstance -ComputerName $targetComputer -Namespace $("root\" + $strBaseClass) -Query $strQuery
    		}catch{
    			$error.Clear()
    			import-module cimcmdlets
    			$wbemObjectSet = Get-CimInstance -ComputerName $targetComputer -Namespace $("root\" + $strBaseClass) -Query $strQuery
    		}
    	}
    	else
    	{
    		$wbemObjectSet = Get-WMIObject -Namespace $("root\" + $strBaseClass) -ComputerName $targetComputer -Query $strQuery
    	}



    • Edited by Lerun Monday, March 20, 2017 9:10 AM
    Monday, March 20, 2017 7:25 AM
  • I am having the exact same issue. After upgrade to SCOM 2016 and UR2 I see this 'WMI is unhealthy' on more than 200 servers. Most of them are in a different AD forest, but there is a forest trust. But I also see the error on servers that are in the same AD as SCOM. 

    Is this a bug?

    Thanks.


    Michael Møller

    Tuesday, March 21, 2017 10:30 AM
  • Try to run the following PS code from your SCOM mgmt server against one of the servers that has the WMI error.

    $ComputerName = "server.mydomain"
    
    
    Get-CimInstance -ComputerName $ComputerName -Namespace "root\cimv2" -Class "Win32_Process" -ErrorAction stop

    Tuesday, March 21, 2017 10:41 AM
  • Thanks for the suggestion. I have tried and it works on most servers, but they still have the error 'WMI is unhealthy'. I am getting expected output - a list of processes on the remote server. I do not have any HTTP SPN related to the SCOM mgmt server or the remote computer. 

    On other servers I see this error:

    Get-CimInstance : WinRM cannot process the request. The following error with errorcode 0x80090322 occurred while using
    Kerberos authentication: An unknown security error occurred.
     Possible causes are:
      -The user name or password specified are invalid.
      -Kerberos is used when no authentication method and no user name are specified.
      -Kerberos accepts domain user names, but not local user names.
      -The Service Principal Name (SPN) for the remote computer name and port does not exist.
      -The client and remote computers are in different domains and there is no trust between the two domains.
     After checking for the above issues, try the following:
      -Check the Event Viewer for events related to authentication.
      -Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or us
    e HTTPS transport.
     Note that computers in the TrustedHosts list might not be authenticated.
       -For more information about WinRM configuration, run the following command: winrm help config.
    At line:1 char:1
    + Get-CimInstance -ComputerName $srv -Namespace "root\cimv2" -Class "Win32_Process ...
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo          : AuthenticationError: (root\cimv2:Win32_Process:String) [Get-CimInstance], CimException
        + FullyQualifiedErrorId : HRESULT 0x8033809d,Microsoft.Management.Infrastructure.CimCmdlets.GetCimInstanceCommand


    Michael Møller


    Tuesday, March 21, 2017 11:15 AM
  • Then it might be a access issue, the WMI health script will probably run using what you have set up as the default action account. And this will need to be allowed to do the Get-CimInstance call. 

    Check to see if this can be an issue. 


    Tuesday, March 21, 2017 11:35 AM
  • My default action account is member of an AD group 'AdminsOnAllServers' and that AD group is member of the remote servers local administrators group, so it should have the permissions required. 

    Michael Møller

    Tuesday, March 21, 2017 11:56 AM
  • This is the same error I have, and it is because the Get-CimInstance call from the mgmt server fail to connect to the remote server. This might be caused by multiple authentication related things, just need to find the right one. 

    As you mentioned that this is happening for monitored servers in a different domain. I would start looking at that, just to see that WinRM works as expected across the domain boundary.

    Sorry I cant be of more help.

    Tuesday, March 21, 2017 12:13 PM
  • We were having the same issues and our SCOM Management server and the SQL server are Windows 2016 servers. Our SCOM servers are the only Windows 2016 servers. We noticed the WMI is unhealthy on the Windows 2016 servers. It looks like I was able to resolve the issue by making some changes to the Windows Firewall. This may not be the right way to do it since I did not get a chance to do it in an orderly way. Just wanted to put it out there if it is useful to anyone’s environment.

    Go to Windows Firewall with Advanced Security

    Choose inbound rules

    Find the inbound rules for Windows Remote Management (HTTP-In) there is two of these rules. I am not able to pinpoint which one exactly helped since I did not get a chance to test this step by step.

    If it is enabled, double click the rules and check the advanced tabs

    Under Profiles, I enabled the rules to be applied to all profiles (Domain, Private, and Public)

    Once this changed were applied the WMI errors went away in a few minutes.

    Not sure if this need to be applied to all Windows 2016 servers or just the management and SQL server. Our Windows 2012 servers did not report any errors.



    • Edited by SCOM-PHL Tuesday, March 21, 2017 1:44 PM
    Tuesday, March 21, 2017 1:37 PM
  • Get-CimInstance use WinRM (Windows Remote Management) so I'll bet it is the Windows Remote Management firewall rule that made the call go through. 


    • Edited by Lerun Tuesday, March 21, 2017 1:48 PM
    Tuesday, March 21, 2017 1:40 PM
  • This just explain the change to the WMI test logic, not why so many have problems with the new one. 

    The reason is that they fundamentally changed the technology the logic runs on in SCOM 2016. For new server OS'es than 2012 it will use Get-CimInstance instead of Get-WmiObject. Get-CimInstance is using WinRM, and Get-WimObject (uses WMI) does not. So for OS'es that are older than 2012 the WMI probe will succeed, but for newer the probe might fail depending on how WinRM is set up in your infrastructure. 

    This is a big change from how it has worked in the past. 


    • Edited by Lerun Tuesday, March 21, 2017 2:13 PM
    Tuesday, March 21, 2017 2:00 PM
  • I finally got rid of the 'WMI is unhealthy' problem. At least for the agents running in a different domain than my SCOM 2016 mgmt server. There is a two-way forest trust between the two domains.

    On the other domain a group policy was used with a configuration of WinRM service. The setting 'Allow remote server management through WinRM' has an option to set a filter for IPv6. In my case this option was blank which means that WinRM was not listening on any IPv6 addresses. Not sure why it needs to, because it was listening on all IPv4 addresses? But after adding * to the IPv6 filter and running a gpupdate /force on agents, the 'WMI is unhealthy' errors disappeared.

    Winrm settings can be viewed on agent with this 'Winrm get winrm/config'

    This article got me in the right direction https://blog.workinghardinit.work/tag/the-winrm-client-sent-a-request-to-an-http-server-and-got-a-response-saying-the-requested-http-url-was-not-available/

    I still have 'WMI is unhealthy' on some agents that are running in the same domain as SCOM mgmt server which I do not understand. Any ideas?


    Michael Møller

    Tuesday, March 21, 2017 3:15 PM
  • Yes, this my experience also for single domain. You must have a * for IPv6 on the Windows Components/Windows Remote Management (WinRM)/WinRM Service policy or it will not work.

    You can also set the IPv4 to only allow for the IP ranges of the two domains instead of using *. 

    Another important policy to set is Windows Components/Windows Remote Management (WinRM)/WinRM Client, here you can add in both the domain names on the Trusted Host list (*.thisdomain.com, *.otherdomain.com)


    • Edited by Lerun Tuesday, March 21, 2017 3:25 PM
    Tuesday, March 21, 2017 3:24 PM
  • Just and update this only worked for just one server. My SCOM management server and the SQL server are still having issues. They both are in different VLANS. The errors I get are as follows:

    Powershell scripts times out on the management server and the SQL server

    Gets invalid arguments error after the Windows 2016 management pack is imported on both servers

    WMI is unhealthy

    Is there any additional steps to take if the management server and the SQL server are in different vlans?

    Tuesday, March 28, 2017 1:10 PM
  • I have a workgroup computer connected to a DMZ and was getting WMI Unhealthy along with WMI Event 100 errors int eh Operations Manager log.  How I ended up fixing it was by adding the actual local computer that was getting the error to WinRm Trustedhosts, not the SCOM Server(s)/Gateway.
    Thursday, March 30, 2017 6:30 PM
  • The monitor responsible for this check has been rewritten in scom 2016, from vbs to powershell : 

    2012 r2 : http://systemcentercore.com/?GetElement=Microsoft.SystemCenter.WMIFunctionalCheck.Probe&Type=ProbeActionModuleType&ManagementPack=Microsoft.SystemCenter.2007&Version=7.1.10226.1118

    2016 : http://systemcentercore.com/?GetElement=Microsoft.SystemCenter.WMIFunctionalCheck.Probe&Type=ProbeActionModuleType&ManagementPack=Microsoft.SystemCenter.2007&Version=7.2.11719.0

    That being said, I can't know for sure the reason why it's failing on your environment... do you have any error message on the Operations Manager log on these servers?


    I've actually tried the script manually and when i run this without parameters or with -computername localhost it works as expected.

    The mp calls the script with "$target/host/property[type=Windows!Microsoft.Windows.Computer]/networkname$". If i run the script with -computername "hostname" it fails with the http error.

    This suggests the trustedhost list needs to be fixed, but with the hostname (and fqdn) added it still fails for me. Still i wonder why MS chose to add the "networkname" as localhost seems to work on a default installed win2k16 server.


    Rob Korving
    http://jama00.wordpress.com/

    Tuesday, April 18, 2017 1:41 PM
  • 

    I had a different error (2150859027 or 0x80338113), not being able to connect to the url.

    And i fixed it by disabling ipv6 as i didnt see the ipv6 address in the "listeningOn" list of the winrm/config/listener.


    Rob Korving
    http://jama00.wordpress.com/



    • Edited by rob1974 Tuesday, April 18, 2017 2:26 PM
    Tuesday, April 18, 2017 2:14 PM
  • If you run without the -computername parameter it does not use WinRM but uses COM instead.

    You can also try to use both FQDN and Netbios name after the -computername parameter. For me FQDN fails, but Netbios works.

    Tuesday, April 18, 2017 3:32 PM
  • i had the same thing, but with FQDN it fails because of an access denied, so that must be solvable :)

    I'm not interested in doing so as i just want SCOM to work and it works with a GPO that enables winrm and filters set on both ipv4 and ipv6.

    (disabling ipv6 like i did before is probably not the best idea :))


    Rob Korving
    http://jama00.wordpress.com/


    • Edited by rob1974 Wednesday, April 19, 2017 12:55 PM
    Wednesday, April 19, 2017 12:48 PM
  • I have an active case with MS on the issue so hopefully a solution is forthcoming 
    Wednesday, April 19, 2017 2:19 PM
  • I'm also interested in what MS has to say, we've got the exact same issue on a couple of servers which worked perfectly before the upgrade.
    Friday, April 21, 2017 9:16 AM
  • I'm interested to see what they say as I have also started a case on this. Please do let us know what the outcome is and if they get a resolution for me I will post as well.

    In my case I'm using two Lync Edge servers with proper certificates installed and trusted hosts configured. The Edge Servers show as healthy, but the monitoring agent is showing critical. The Health Scripts are failing with the same error originally posted.

    Friday, April 21, 2017 1:13 PM
  • I think there are multiple issues for this problem. 

    The most common one is not having WinRM correctly configured in the AD domain where SCOM and the monitored servers belong.

    For other scenarios where SCOM and the monitored server is not part of the same domain there will be some specific configurations needed to solve this (not the same as for the domain).

    For my issue it is because I have a domain user account using the same SPN as WinRM needs, and therefore WinRM wil fail. Though as the domain user is only using HTTP/FQDN SPN, it would work if the MP scripts would have used the netbios name of the server in the -ComputerName part of the code logic. Though most of the scripts are using  -ComputerName $strDNSComputerName where $strDNSComputerName = FQDN. So therefore it will fail on all my loadbalanced servers where the HTTP/ServerNodeName SPN is registered on a domain user.

    I believe the only way to solve this is for MS to add more code logic paths that tries different ways of retrieving the data they need using the Get-CimInstance method. 

    Friday, April 21, 2017 1:53 PM
  • I went ahead and changed some of the code in the WMI probe. If anybody with problems want to try it out and see if it works better with the changes it would help in diagnosing the problem everybody has. 

    The monitor is default not active so it will need to be activated using an override. 

    It also logs everything (this can be changed in the override) out of the box to the Operations Manager eventlog, have a look there to see what it does during runtime. This will show if it needs to try a different combination of Get-CimInstance to complete successfully.

    The monitor is located under the Agent scope, and you will need to disable the default one found under Configuration and with the name WMI Health Monitor.  

    <?xml version="1.0" encoding="utf-8"?>
    <ManagementPack SchemaVersion="2.0" ContentReadable="true" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
      <Manifest>
        <Identity>
          <ID>Microsoft.SystemCenter.2007.Addendum</ID>
          <Version>1.0.0.0</Version>
        </Identity>
        <Name>Microsoft.SystemCenter.2007.Addendum</Name>
        <References>
          <Reference Alias="SCLibrary">
            <ID>Microsoft.SystemCenter.Library</ID>
            <Version>7.0.8433.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
          <Reference Alias="Windows">
            <ID>Microsoft.Windows.Library</ID>
            <Version>7.5.8501.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
          <Reference Alias="Health">
            <ID>System.Health.Library</ID>
            <Version>7.0.8433.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
          <Reference Alias="System">
            <ID>System.Library</ID>
            <Version>7.5.8501.0</Version>
            <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
          </Reference>
        </References>
      </Manifest>
      <TypeDefinitions>
        <ModuleTypes>
          <ProbeActionModuleType ID="Microsoft.SystemCenter.WMIFunctionalCheckAddendum.Probe" Accessibility="Internal" Batching="false" PassThrough="false">
            <Configuration>
              <xsd:element minOccurs="1" name="ComputerName" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
              <xsd:element minOccurs="1" name="TimeoutSeconds" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
              <xsd:element minOccurs="1" name="LogLevelText" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
            </Configuration>
            <OverrideableParameters>
              <OverrideableParameter ID="TimeoutSeconds" Selector="$Config/TimeoutSeconds$" ParameterType="int" />
              <OverrideableParameter ID="LogLevelText" Selector="$Config/LogLevelText$" ParameterType="string" />
            </OverrideableParameters>
            <ModuleImplementation Isolation="Any">
              <Composite>
                <MemberModules>
                  <ProbeAction ID="Probe" TypeID="Windows!Microsoft.Windows.PowerShellPropertyBagProbe">
                    <ScriptName>WMIFunctionalCheck.ps1</ScriptName>
                    <ScriptBody><![CDATA[#Copyright (c) Microsoft Corporation. All rights reserved.
    # Addendum by: Morten Lerudjordet
    #*************************************************************************
    # $ScriptName:  "WMIFunctionalCheck" $
    #
    # Purpose:      This script runs a WMI functional check. 
    #
    # $File:        WMIFunctionalCheck.ps1 $
    #*************************************************************************
    Param(
    	[String]$ComputerName,
    	[String]$LogLevelText
    )
    
    #OS version for Win 2012
    $WIN_OS_2012_Ver = "6.2"
    $OSRegistryKey = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\"
    
    #******************************************************************************
    #   FUNCTION:       CheckMinOSVer
    #   DESCRIPTION:    Returns True if the Registry Key for CurrentVersion
    #                   is equal or Higher than the Minimum OS Versions Number.
    #   PARAMETER:      DblMinVer Minimum Version Number to use
    #   RETURNS:        Boolean: True, if build is greater or equal than the given number
    #******************************************************************************
    function CheckByOSCurrentVersion #As Boolean
    { 
        $strCurrentOSVer = Get-ItemProperty $OSRegistryKey
        $strCurrentOSVer = $strCurrentOSVer.CurrentVersion
        if($strCurrentOSVer -ge $WIN_OS_2012_Ver)
    	{	
    		return $true
    	}
        return $false
    }
    
    #==================================================================================
    # Func:		LogEvent
    # Purpose:	Logs an informational event to the Operations Manager event log
    #			only if Debug argument is true
    #==================================================================================
    function LogEvent 
    {
    Param(
    	[Int]$EventNr,
    	[Int]$EventType,
    	[String]$LogMessage
    )
       
    $LogMessage = "`n" + $LogMessage
    if($EventType -le $LogLevel) 
      {
    	$SCOMapi.LogScriptEvent($SCRIPT_NAME,$EventNr,$EventType,$LogMessage)
      }
    }
    
    #---------------------------------------------------------------------------
    # Retrieves the script output.
    #---------------------------------------------------------------------------
    function ReturnResponse 
    {
    Param(
    	[Bool]$ErrorFlag,
    	[String]$Message
    )
    
        if($ErrorFlag -eq $true)
        {
            $propertyBag.AddValue("Status", "FAIL")
            $propertyBag.AddValue("ErrorMessage", $Message)
        }
        else
        {
            $propertyBag.AddValue("Status", "OK")
        }
        LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage $Message      
        $propertyBag
    }
    
    
    #---------------------------------------------------------------------------
    # Execute a WMI Query.
    #---------------------------------------------------------------------------
    function ExecuteWMIQuery
    {
    Param(
    	[String]$targetComputer,
    	[String]$BaseClass,
    	[String]$Query,
    	[String]$PropertyName
    )
    
    	if($isHigherThanWin08 -eq $true)
      {
    	    try{
    		    # Check if CIM methods are loaded
            if (! (Get-Module -Name cimcmdlets -ErrorAction SilentlyContinue) ) 
            {
    		    # Stop if one cannot use Get-CimInstance CMDlet
                Import-Module -Name cimcmdlets -ErrorAction Stop
    	      }
            LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "Trying to connect through WinRM using computer name:  $targetComputer to get data from WMI"		
            $wbemObjectSet = Get-CimInstance -ComputerName $targetComputer -Namespace $("root\" + $BaseClass) -Query $Query -ErrorAction SilentlyContinue -ErrorVariable wbemError
                
            if($wbemError) {
                $error.Clear()
                # Log Error as Info in eventlog        
                LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage $wbemError            
                $wbemError = $Null
                # Get netbios name from FQDN
                $targetComputerNetbios = $targetComputer.split(".")[0]
                LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "Trying to connect through WinRM using computer name:  $targetComputerNetbios to get data from WMI"			
                # Try to use netbios computer name instead of FQDN/DNS
                $wbemObjectSet = Get-CimInstance -ComputerName $targetComputerNetbios -Namespace $("root\" + $BaseClass) -Query $Query -ErrorAction SilentlyContinue -ErrorVariable wbemError
                    
                if($wbemError) {
                    $error.Clear()
                    # Log Error as Info in eventlog
                    LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage $wbemError 
                    $wbemError = $Null
                    LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "Using DCOM to get WMI data instead of WinRM"				
                    # Use DCOM instead if all WinRM connection attempts fail
                    $wbemObjectSet = Get-CimInstance -Namespace $("root\" + $BaseClass) -Query $Query -ErrorAction Continue
                }
            }            
    	  }
        catch{
    			# Log unhandeled execption
    			LogEvent -EventNr $EventId -EventType $EVENT_ERROR -LogMessage $_.Exception.Message			
    		}
    	}
    	else
    	{
    		$wbemObjectSet = Get-WMIObject -Namespace $("root\" + $BaseClass) -ComputerName $targetComputer -Query $Query
    	}
        foreach($objItem in $wbemObjectSet)
        {
            $temp = $objItem.$PropertyName
        }
        return $temp
    }
    
    
    #---------------------------------------------------------------------------
    # Gets WMI Status.
    #---------------------------------------------------------------------------
    function GetWMIStatus
    {
    Param(
    	[String]$ComputerName
    )
    
        $status = ExecuteWMIQuery -targetComputer $ComputerName -BaseClass "cimv2" -Query "select Status from win32_operatingsystem" -PropertyName "Status"
        
        if($status -eq "OK")
        {
            return "OK"
        }
        else
        {
            return "FAIL"
        }
    }
    
    #Check the OS version
    $isHigherThanWin08 = CheckByOSCurrentVersion 
    
    #Define local event constants
    $SCRIPT_NAME    = 'WMIFunctionalCheck.ps1'
    $EVENT_ERROR 	= 1
    $EVENT_WARNING 	= 2
    $EVENT_INFO     = 4
    $EventId        = 150
    
    Switch($LogLevelText) 
    {
        'Error' {
            $LogLevel = 1 
        }
        'Warning' {
            $LogLevel = 2
        }
        'Information' {
            $LogLevel = 4
        }
        Default {
            $LogLevel = 1
        }
    }
    #Create PropertyBag object
    $SCOMapi = new-object -comObject "MOM.ScriptAPI"
    LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "Script has started, loglevel is set to: $LogLevelText"
    # Alternate way to write to eventlog for SCOM
    Write-EventLog -EventId $EventId -LogName 'Operations Manager' -Source 'Health Service Script' -EntryType Information -Message "$SCRIPT_NAME loglevel is set to: $LogLevelText translated to number: $LogLevel"
    
    $propertyBag = $SCOMapi.CreatePropertyBag()
    
    $error.Clear()
    
    #Set variables 
    LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "Retrieving WMI Status"
    $strWMIStatus = GetWMIStatus -ComputerName $ComputerName
    LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "WMI Status: $strWMIStatus"
    if($error.Count -ne 0)
    {
        $strMessageToUse = "Error Details: " + $error[0]
        ReturnResponse -ErrorFlag $true -Message $strMessageToUse
    }
    else
    {
        $strMessageToUse = "Script WMIFunctionalCheck executed Successfully"
        ReturnResponse -ErrorFlag $false -Message $strMessageToUse
    }
    LogEvent -EventNr $EventId -EventType $EVENT_INFO -LogMessage "Script Finished"
    ]]></ScriptBody>
                    <Parameters>
                      <Parameter>
                        <Name>ComputerName</Name>
                        <Value>$Config/ComputerName$</Value>
                      </Parameter>
                      <Parameter>
                        <Name>LogLevelText</Name>
                        <Value>$Config/LogLevelText$</Value>
                      </Parameter>
                    </Parameters>
                    <TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>
                  </ProbeAction>
                </MemberModules>
                <Composition>
                  <Node ID="Probe" />
                </Composition>
              </Composite>
            </ModuleImplementation>
            <OutputType>System!System.PropertyBagData</OutputType>
            <InputType>System!System.BaseData</InputType>
          </ProbeActionModuleType>
        </ModuleTypes>
        <MonitorTypes>
          <UnitMonitorType ID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" Accessibility="Internal" RunAs="System!System.PrivilegedMonitoringAccount">
            <MonitorTypeStates>
              <MonitorTypeState ID="WMIError" NoDetection="false" />
              <MonitorTypeState ID="WMISuccess" NoDetection="false" />
            </MonitorTypeStates>
            <Configuration>
              <xsd:element name="IntervalSeconds" type="xsd:unsignedInt" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
              <xsd:element name="TimeoutSeconds" type="xsd:integer" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
              <xsd:element name="LogLevelText" type="xsd:string" xmlns:xsd="http://www.w3.org/2001/XMLSchema" />
            </Configuration>
            <OverrideableParameters>
              <OverrideableParameter ID="IntervalSeconds" Selector="$Config/IntervalSeconds$" ParameterType="int" />
              <OverrideableParameter ID="TimeoutSeconds" Selector="$Config/TimeoutSeconds$" ParameterType="int" />
              <OverrideableParameter ID="LogLevelText" Selector="$Config/LogLevelText$" ParameterType="string" />
            </OverrideableParameters>
            <MonitorImplementation>
              <MemberModules>
                <DataSource TypeID="System!System.Scheduler" ID="Scheduler">
                  <Scheduler>
                    <SimpleReccuringSchedule>
                      <Interval Unit="Seconds">$Config/IntervalSeconds$</Interval>
                    </SimpleReccuringSchedule>
                    <ExcludeDates />
                  </Scheduler>
                </DataSource>
                <ProbeAction TypeID="Microsoft.SystemCenter.WMIFunctionalCheckAddendum.Probe" ID="Probe">
                  <ComputerName>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</ComputerName>
                  <TimeoutSeconds>$Config/TimeoutSeconds$</TimeoutSeconds>
                  <LogLevelText>$Config/LogLevelText$</LogLevelText>
                </ProbeAction>
                <ProbeAction ID="PassThrough" TypeID="System!System.PassThroughProbe" />
                <ConditionDetection ID="ErrorFilter" TypeID="System!System.ExpressionFilter">
                  <Expression>
                    <SimpleExpression>
                      <ValueExpression>
                        <XPathQuery>Property[@Name='Status']</XPathQuery>
                      </ValueExpression>
                      <Operator>NotEqual</Operator>
                      <ValueExpression>
                        <Value Type="String">OK</Value>
                      </ValueExpression>
                    </SimpleExpression>
                  </Expression>
                </ConditionDetection>
                <ConditionDetection ID="SuccessFilter" TypeID="System!System.ExpressionFilter">
                  <Expression>
                    <SimpleExpression>
                      <ValueExpression>
                        <XPathQuery>Property[@Name='Status']</XPathQuery>
                      </ValueExpression>
                      <Operator>Equal</Operator>
                      <ValueExpression>
                        <Value Type="String">OK</Value>
                      </ValueExpression>
                    </SimpleExpression>
                  </Expression>
                </ConditionDetection>
              </MemberModules>
              <RegularDetections>
                <RegularDetection MonitorTypeStateID="WMIError">
                  <Node ID="ErrorFilter">
                    <Node ID="Probe">
                      <Node ID="Scheduler" />
                    </Node>
                  </Node>
                </RegularDetection>
                <RegularDetection MonitorTypeStateID="WMISuccess">
                  <Node ID="SuccessFilter">
                    <Node ID="Probe">
                      <Node ID="Scheduler" />
                    </Node>
                  </Node>
                </RegularDetection>
              </RegularDetections>
              <OnDemandDetections>
                <OnDemandDetection MonitorTypeStateID="WMIError">
                  <Node ID="ErrorFilter">
                    <Node ID="Probe">
                      <Node ID="PassThrough" />
                    </Node>
                  </Node>
                </OnDemandDetection>
                <OnDemandDetection MonitorTypeStateID="WMISuccess">
                  <Node ID="SuccessFilter">
                    <Node ID="Probe">
                      <Node ID="PassThrough" />
                    </Node>
                  </Node>
                </OnDemandDetection>
              </OnDemandDetections>
            </MonitorImplementation>
          </UnitMonitorType>
        </MonitorTypes>
      </TypeDefinitions>
      <Monitoring>
        <Monitors>
          <UnitMonitor ID="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum" Accessibility="Public" Enabled="false" Target="SCLibrary!Microsoft.SystemCenter.Agent" ParentMonitorID="Health!System.Health.ConfigurationState" Remotable="true" Priority="Normal" TypeID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" ConfirmDelivery="false">
            <Category>StateCollection</Category>
            <AlertSettings AlertMessage="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum.AlertMessage">
              <AlertOnState>Error</AlertOnState>
              <AutoResolve>true</AutoResolve>
              <AlertPriority>Normal</AlertPriority>
              <AlertSeverity>Error</AlertSeverity>
              <AlertParameters>
                <AlertParameter1>$Target/Host/Property[Type="Windows!Microsoft.Windows.Computer"]/NetworkName$</AlertParameter1>
              </AlertParameters>
            </AlertSettings>
            <OperationalStates>
              <OperationalState ID="WMISuccess" MonitorTypeStateID="WMISuccess" HealthState="Success" />
              <OperationalState ID="WMIError" MonitorTypeStateID="WMIError" HealthState="Error" />
            </OperationalStates>
            <Configuration>
              <IntervalSeconds>86400</IntervalSeconds>
              <TimeoutSeconds>300</TimeoutSeconds>
              <LogLevelText>Information</LogLevelText>
            </Configuration>
          </UnitMonitor>
        </Monitors>
      </Monitoring>
      <Presentation>
        <StringResources>
          <StringResource ID="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum.AlertMessage" />
        </StringResources>
      </Presentation>
      <LanguagePacks>
        <LanguagePack ID="ENU" IsDefault="true">
          <DisplayStrings>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum">
              <Name>WMI Health Monitor Addendum</Name>
              <Description>This monitor checks whether WMI is healthy by periodically performing a WMI query</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum" SubElementID="WMIError">
              <Name>WMI functionality Error</Name>
            </DisplayString>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum" SubElementID="WMISuccess">
              <Name>WMI functionality Success</Name>
            </DisplayString>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalMonitorAddendum.AlertMessage">
              <Name>WMI is unhealthy</Name>
              <Description>WMI on computer {0} is unhealthy</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType">
              <Name>WMI functional Monitor Type</Name>
              <Description>Monitor type for the WMI health monitor</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" SubElementID="WMIError">
              <Name>WMI functional Monitor Type - WMI Error</Name>
              <Description>Error state for this type of monitor</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" SubElementID="WMISuccess">
              <Name>WMI functional Monitor Type  - WMI Success</Name>
              <Description>Success state for this type of monitor</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" SubElementID="IntervalSeconds">
              <Name>Interval (Seconds)</Name>
              <Description>Interval time expressed in seconds</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" SubElementID="TimeoutSeconds">
              <Name>Time out (Seconds)</Name>
              <Description>Time to wait until cancel execution of script expressed in seconds</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.OperationsManager.WMIFunctionalAddendum.MonitorType" SubElementID="LogLevelText">
              <Name>Level to log</Name>
              <Description>Use Information, Warning or Error to set the level of logging for probe script</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalCheckAddendum.Probe">
              <Name>WMI functional Check Probe</Name>
              <Description>Probe for the WMI Functional Check</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalCheckAddendum.Probe" SubElementID="TimeoutSeconds">
              <Name>Time out Seconds</Name>
              <Description>Time to wait until cancel execution of script expressed in seconds</Description>
            </DisplayString>
            <DisplayString ElementID="Microsoft.SystemCenter.WMIFunctionalCheckAddendum.Probe" SubElementID="LogLevelText">
              <Name>Level to log</Name>
              <Description>Use Information, Warning or Error to set the level of logging for probe script</Description>
            </DisplayString>
          </DisplayStrings>
          <KnowledgeArticles></KnowledgeArticles>
        </LanguagePack>
      </LanguagePacks>
    </ManagementPack>

    Saturday, April 22, 2017 6:19 PM
  • The code changes I did for the monitor has now been tested on the servers where I had problems. It is working after falling back from using FQDN for -ComputerName to using Netbios name. There is still one level that can be used, and if anybody else can test it would be helpful.

    I have also done the same changes to the Agent CPU performance monitor. The updated code can be found from my post above.

    Monday, April 24, 2017 9:06 AM
  • For everyone with the SPN rootcause (Domain Username registered HTTP SPN):

    The workaround is to disable wmi health monitor and some other workflows that use SCOMpercentageCPUTimeCounter.ps1 like Microsoft.SystemCenter.HealthService.SCOMpercentageCPUTimeMonitor for example for the specific machines. MS will release an update of the SCOM MP (System Center Core Monitoring) with UR4, maybe earlier to adress this issue.

    Wednesday, April 26, 2017 1:13 PM
  • This is great work, Morten. Are you able to create an MP including your monitors and disable the default ones?

    Martin

    Thursday, May 11, 2017 1:22 PM
  • Hi Martin, I'll publish the MP in the gallery over the weekend. Have also added in the rule that collects the agent cpu information as a bonus. The MP will also disable the built in rules as monitors. 
    Thursday, May 11, 2017 5:29 PM
  • If anybody are interested I have posted the MP here:

    https://gallery.technet.microsoft.com/SCOM-2016-System-Center-1611d6c8

    Friday, May 12, 2017 4:02 PM
  • I would like to add my voice to this issue, and also say thanks to Lerun for the amazing workaround.

    Jason TheZolon

    Tuesday, May 16, 2017 1:58 PM
  • New refactored code is up. Gives much more logging and can be run directly from the PS console to see what it will return. 

    Core Monitoring MP replacement

    https://gallery.technet.microsoft.com/SCOM-2016-System-Center-1611d6c8

    Internal MP replacement

    https://gallery.technet.microsoft.com/SCOM-2016-System-Center-d9fc238b


    • Edited by Lerun Friday, May 26, 2017 3:07 PM
    Friday, May 26, 2017 3:07 PM
  • Hi Morten,

    Do you know of this will fix the problem for non-domain joined computers as well? These have problems running remote powershell after all certificates etc are imported.

    Martin

    Friday, June 2, 2017 9:00 AM
  • Hi Martin, it should I have it running on workgroup servers without problems.

    I have removed all usage of WinRM, it's only connecting locally through COM now so this removes the usage of remoting completely. 


    Friday, June 2, 2017 10:16 AM
  • Hi Martin, it should I have it running on workgroup servers without problems.

    I have removed all usage of WinRM, it's only connecting locally through COM now so this removes the usage of remoting completely. 


    Just imported. Seems to be working :)

    Thank you, you have done alot of work here.

    Friday, June 2, 2017 11:33 AM
  • Created it to help out a client of mine, happy others find it useful.
    Friday, June 2, 2017 2:05 PM
  • So was this ever officially fixed in UR3 of SCOM?
    Thursday, July 20, 2017 9:38 PM
  • You can check by going to the site below and choose the newest version on top (dropdown list) to display.

    http://systemcenter.wiki/?GetElement=Microsoft.SystemCenter.WMIFunctionalCheck.Probe&Type=ProbeActionModuleType&ManagementPack=Microsoft.SystemCenter.2007&Version=7.2.11878.0

    From the code there seem to be no changes yet to fix the problem. Maybe they will do something for UR4.

    Friday, July 21, 2017 7:16 AM
  • I'm trying to understand the scope of this issue. I'm seeing this on Windows 2016 boxes monitored by SCOM 2016. Is it the only case?
    Friday, July 21, 2017 1:45 PM
  • If you would have read this thread, it would become apparent that this issue is only on SCOM 2016 as they changed some of the code to powershell. This change could have been though a bit more about before committing, and we would not have had to deal with this issue.
    Friday, July 21, 2017 7:07 PM
  • If you would have read this thread, it would become apparent that this issue is only on SCOM 2016 as they changed some of the code to powershell. This change could have been though a bit more about before committing, and we would not have had to deal with this issue.
    My question was not wether prior version of SCOM are affected but wether monitoring down level OSes from SCOM 2016 is also affected. That is if monitoring Windows 2012 OS from SCOM will show the same issue since I don't see consistent behavior and so far so only Windowws 2016 OS being affected.
    Friday, July 21, 2017 7:26 PM
  • Sorry misunderstood, downlevel uses another powershell function and is not affected. It uses Get-WMIobject instead of Get-CimInstance, and does not use WinRM.
    Friday, July 21, 2017 8:00 PM
  • I logged a Premier Advisory case on this and they have given me a Private fix which I have tested in two environments and it resolves the WMI unhealthy and PS script faiure alerts, which were only present where the system alerting had an SPN on http:80. I am now waiting for them to advise when the Public fix (UR4 perhaps) is going to be released.  I will post when I know more.

    Steve

    Tuesday, July 25, 2017 1:21 AM
  • I also had a support case with Microsoft on the issue and they informed that the issue will be fixed in Update Rollup 4 for SCOM 2016.


    Michael Møller

    Monday, July 31, 2017 6:40 AM
  • Hi everyone,

    So I've just migrated one of my clients to OpsMgr 2016 and deployed UR3 as part of the migration. As you would have guessed we started seeing this issue on some of the Windows Server 2012 R2 clients but not others.

    I've done some digging and found that running the following command resolves this particular issue without having to make changes to the existing MP:

    netsh winhttp reset proxy

    Now this is only a workaround and it is still strongly recommended to deplou UR4 (If it includes the fix that is).

    I hope this helps :)

    • Proposed as answer by Joli venom Friday, September 8, 2017 1:16 AM
    Wednesday, August 2, 2017 1:08 AM
  • Hi!

    Does anyone have any info when can we get Update Rollup 4 for SCOM 2016 to fix this issue?

    Tuesday, September 5, 2017 5:57 AM
  • Hi,

    This should be fixed in this MP hotfix

    https://www.microsoft.com/en-us/download/details.aspx?id=55792&WT.mc

    • Proposed as answer by antsel Tuesday, September 5, 2017 12:03 PM
    • Marked as answer by nrsc1 Thursday, October 5, 2017 3:06 PM
    Tuesday, September 5, 2017 8:38 AM
  • Yep the public fix resolved this - it was not UR4 but instead it was:
    "System Center Operations Manager 2016 inbox MP hotfix for WMI health monitor issue"
    • Proposed as answer by Kiwifulla2 Monday, September 25, 2017 9:32 PM
    • Marked as answer by nrsc1 Thursday, October 5, 2017 3:13 PM
    Monday, September 25, 2017 9:30 PM
  • I've also confirmed that this hotfix resolves the issue.

     I would not wait for MS to release UR 4 to fix this issue, it is unclear whether MS will even release UR 4 for SCOM 2016. They are hard at work on SCOM 1801.

    Thursday, October 5, 2017 3:13 PM
  • Did Microsoft Ever resolve your issue?  I am having a similar issue 

    I have 180 Clients in my SCOM Operations Manager Agent Managed Group.  Roughly 60 of them are showing Critical.  The rest are showing Healthy.  I am getting 22406 Event errors on the Critical machines, mostly Windows 10 Client systems.  The failure is showing the SCOMpercentageCPUTimeCounter.ps1  Script Fails to run.  I can't seem to find anything that helps to resolve this issue.

    Anything you can assist with would be appreciated.

    Thanks


    Thank You

    Thursday, December 21, 2017 7:43 PM
  • When I looked at the script it has a lot of bugs, so I would just disable both the rule and monitor that targets the script.
    Thursday, December 21, 2017 8:47 PM
  • Thank You.  I will give that a try and see what happens.

    Thank You

    Thursday, December 21, 2017 9:19 PM
  • I know this is an old post, but this fixed my problem monitoring Windows Server 2019 cluster nodes.  (The non-cluster nodes were being monitored without any problems.)

    Thanks!

    Friday, February 8, 2019 3:20 PM