243 views

Description

Customers using legacy WMI Discovery are expected to back-out legacy WMI update set (Revert_To_Legacy_WMI) when upgrading to Paris as the out-of-the-box solution will determine WMI use dynamically. This is documented in KB0860580 and in ITOM Visibility release notes under section 'WMI performance host detection'.

To determine WMI use dynamically, from Paris, the probe runs two tests during Windows classification (WMI: Classify) -

1. If the credential/MID can access admin share on the target (\\target\admin$)

2. If #1 is true, invoke a powershell process on the target ("target_powershell_access").

If the check for "target_powershell_access" fails (because the target does not have powershell installed or the credential used does not have permission to invoke powershell on the target), the probe runs legacy WMI queries to fetch results that can be used for classification.

Unfortunately, along with the results returned from legacy WMI queries, the probe also returns an error string from the test for "target_powershell_access". The error string can be seen in input payload for WMI: Classify  probe.

<error>The result file \\<IP address>\admin$\temp\psscript_output_<GUID>.txt can't be fetched because it doesn't exist</error>

Discovery sensor will report this as an error in discovery log and fail Windows Classification even if the payload included information that was required to classify the device.

Steps to Reproduce

1. Run discovery on a Windows host
2. Ensure that the credential used cannot invoke powershell process on the target.
3. Notice that WMI - Classify fails with error
The result file \\<IP address>\admin$\temp\psscript_output_<GUID>.txt can't be fetched because it doesn't exist

Workaround

Upon upgrading to Paris, back out of the update set "Revert_To_Legacy_WMI" and then import the XML attached.

It will override the file ecc_agent_script_file_1ed24b15376001006b882d465abe5dd.xml which is a MID->Script File named "LaunchProc.psm1".

Please remember that after importing this file, it will not be upgraded in future upgrade: make sure you mark it to be upgraded manually by setting the "Replace on upgrade" field value to false for this file in the sys_update_xml table.


Related Problem: PRB1435936

Seen In

SR - IRM - GRC Profiles - Madrid 2019 Q2
SR - IRM - Policy and Compliance - Madrid 2019 Q2
SR - IRM - Risk Management - New York 2019 Q3
SR - ITOM - CMDB CI Class Models - 201909
SR - ITOM - Discovery and Service Mapping - 201908
SR - ITOM - Discovery and Service Mapping - v1.0.35
SR - Security - Integration Framework - Madrid 2019 Q2
SR - Security - Support Common - Madrid 2019 Q2
SR - Security - Support Orchestration - Madrid 2019 Q2
SR - SIR - Security Incident Response - Madrid 2019 Q2
SR - SIR - Store SecOps Setup Assistant - Madrid 2019 Q2
SR - SIR - Store Threat Core - Madrid 2019 Q2
SR - SIR - Store Trusted Security Circles Client - New York 2019 Q3

Intended Fix Version

Paris Patch 4
Quebec

Safe Harbor Statement

This "Intended Fix Version" information is meant to outline ServiceNow's general product direction and should not be relied upon in making a purchasing decision. The information provided here is for information purposes only and may not be incorporated into any contract. It is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. The development, release, and timing of any features or functionality described for our products remains at ServiceNow's sole discretion.

Associated Community Threads

There is no data to report.

Article Information

Last Updated:2020-11-03 12:17:56
Published:2020-10-30
PRB1435936 - workaround.xml[View]