Notifications

2983 views

Description

The problems and host requirements mentioned on this page no longer apply to Paris and later versions. The code for launching WMI probes in Paris has been refactored in response to customer feedback related to these issues.

The updates sets on this page will break Discovery in Paris and later. To remove the customizations made by the update sets described on this page, and the symptoms seen when these are still present in a Paris instance, see:
KB0860580 Removing customisations of Discovery Windows WMI probes, that had been applied for the changes in Madrid Patch 3/New York.

As part of our general Discovery performance enhancements, a new Windows Discovery method was implemented which uses PowerShell and the admin$ share folder on remote targets. This method was already implemented and used in ADM and ADME.

The new Windows Discovery shows performance increases with speeds up to 8x times faster on the MID Server, with less CPU utilization and memory consumption.
This means fewer MID Servers are now required by customers to discover their Windows infrastructure. The resources used on the target hosts have not significantly changed from the old Discovery method.

Most customers have some Windows machines in their infrastructure, and most of these use PowerShell, installed by default.

Below is a comparison of discoveries in the London and New York versions on a set of 20 Windows servers in the ServiceNow lab:

  • London took 35.78 minutes.

  • New York took only 4.41 minutes.

It is worth noting that most customers (over 84%) have some Windows servers in their infrastructure, and most of these have Windows with PowerShell installed by default (Windows version is greater than 2008).

These changes are documented in PRB1308592

Why we changed how Discovery works

As Discovery progresses and discovers new resources, we noticed that the legacy method of discovering a Windows host was taking longer and longer.
Many customers had complained that their discoveries were timing out, particularly the "Windows - Installed Software" probe.

Some customers could not discover some of their Windows hosts when there was a timeout on the "Windows - Classify" probe.

PRBs referenced for this issue:


PRB numberFound inFixed inDescriptionEffectNotesWorkaround
PRB1308592Pre-existingLP9, MP3Performance with Windows Classify and Installed SoftwareSlow performanceThis PRB was backported to Madrid to improve performance but requires PowerShell and access to admin$ share. 
PRB1348026 /KB0751599MP3MP5WMI fails when no PowerShell or access to $adminCannot use PowerShell on remote target host (due to PRB1308592)Allows customers to revert to using legacy WMI Windows Discovery after applying attached update set.In MP3 and MP4, pin the MID server to MP2 and apply the attached update set. In MP5 and above, just apply the update set.
Do not apply this update set to Paris and later versions. Back-out the "Revert_To_Legacy_WMI" update set immediately before or after upgrade.
PRB1350180 /KB0754189MP3MP6No Windows credentials, hostname of MID Server is returned by WMI ClassifyCannot discover Windows host with MID Server service accountIf only using the service account on MID Server service and no Windows credentials, then MID Server details are returned instead of the intended target.In MP3, MP4, and MP5, apply the attached update set.
Do not apply the update set to Madrid Patch 6 or later versions.
Back-out the "New_WMI_Discovery_Support_Service_account" update set immediately before or after upgrade.

PRB1349945MP3NYWMI Runner output can be larger than 10k characters, causing new lineJSON parse issue "<results error="JSON.parse (script_include:JSON; line 42)""Happens when parsing a large payload, and PowerShell v2 is installed on the MID.Workaround is to install PowerShell 3, 4, 5.0, or 5.1 on the MID Server.
This is an Orlando requirement now, due to WMI Collector Service related changes.
PRB1335598MP5NYLaunchProc.psm uses admin$ by defaultCannot use admin$ share folder on remote target.Allows admin$ share to be replaced with any other shared folder name, applies to all Windows targets.
PRB1345839NYWon't fixUNC path not supportedCustomer can change admin$ with any other shared folder name except UNC pathsKnown limitation, no plan to fix.
PRB1357296MP6MP7Updated MID Server script files not synced to MID Server
PRB1350180 modified two MID Server script includes but didn't change the timestamps on them.Apply the attached update set. PRB1350180 update set is also updated with correct timestamps now.
Do not apply the update set to Madrid Patch 6 or later versions.
Back-out the "New_WMI_Discovery_Support_Service_account" update set immediately before or after upgrade.

PRB1367498Existed earlier than MadridTargeted for ParisCredential affinity not cleaned up when auth fails and MID Server falls back to service account userProbe has a probe parameter with the credential that has affinity, even though the service account is actually being used instead of the attached credential.



Release or Environment

We changed the requirement to support the new Windows Discovery method (described here KB0752537) when using the WMI protocol.
For WinRM, we require PowerShell versions 3.0 to 5.1 on the target host.

WMI Protocol requirements:

  • Remote Windows systems must run PowerShell versions 3.0 to 5.1.

  • The default file system to access from the MID Server is admin$ share. 

  • 10 MB free disk space on the target to write the temporary file.


Cause


This section describes each known issue, lists the PRB where the information is documented, and explains how to handle the issue (depending on the patch level).


Cannot discover Windows host with MID Service account

Some customers complained that for every Windows Discovery, they are receiving the MID Server details. This was recently documented in PRB1350180 / KB0754189 and was fixed in Madrid Patch 6.

Workaround: Apply the update-set that is attached to PRB1350180 / KB0754189. This solution is for Madrid Patches 3-5 only.

Do not apply the update set to Madrid Patch 6 or later versions. Back-out the "New_WMI_Discovery_Support_Service_account" update set immediately before or after upgrade.


JSON parse issue "<results error="JSON.parse (script_include:JSON; line 42)"

When a very large payload is being processed, and PowerShell version 2 is installed on the MID Server, you might see this JSON error:

"results error="JSON.parse (script_include:JSON; line 42)"

We logged PRB1349945 to fix this.

Workaround: Install a PowerShell version from 3.0 to 5.1 on the MID Server.


Cannot use admin$ share folder on remote target (The result file can't be fetched because it doesn't exist)

Some customers reported that they cannot access admin$ on the target host, but they do want to use the new Windows Discovery. As of Madrid Patch 5, we have not backported any solution for this.

In the New York release, we introduced PRB1335598, which enables a customer to change admin$ with any other shared folder name. However, every Windows target host must have that shared folder name to allow the MID Server to access it.

In PRB1345839 we attempted to enable UNC support (example: \\<IP address>\<folder name>. Unfortunately, we could not accomplish this due to Windows OS limitations.

Workaround: Until the PRBs mentioned above are backported to Madrid, the solutions are:

  • Enable admin$ for the Discovery user(s).

  • Use legacy Discovery. There are no performance benefits, but you do not need admin$.

  • For Madrid Patch 3 and 4, pin the MID Server to Madrid Patch 2, and then apply the update-set that is attached to PRB1348026 / KB0751599 .

  • For Madrid Patch 5 and higher, apply the update-set that is attached to PRB1348026 / KB0751599 (no need to pin the MID Server). 

Do not apply this update set to Paris and later versions. Back-out the "Revert_To_Legacy_WMI" update set immediately before or after upgrade.


Cannot use PowerShell on remote target host (Error: powershell is required to complete this operation)

Some customers had complained that they cannot run PowerShell at all on the target hosts for various reasons. To accommodate customers with these limitations, we created PRB1348026 / KB0751599  to allow them to revert to legacy the WMI Windows Discovery. This options is available in Madrid Patch 5 and higher.

Workaround:: To revert to the legacy WMI Windows Discovery:

  • Madrid Patch 3 and 4: Pin the MID server to Madrid Patch 2 and apply the update-set attached to PRB1348026 / KB0751599 .

  • Madrid Patch 5 and higher: Apply the update-set attached to PRB1348026 / KB0751599 (no need to pin the MID server).

Do not apply this update set to Paris and later versions. Back-out the "Revert_To_Legacy_WMI" update set immediately before or after upgrade.


Discovery of Windows results in discovering MID Server information:

If you are using the MID service account to discover Windows servers, there was a bug affecting this beginning with Madrid Patch 3 and fixed in Madrid Patch 7. Apply the update-set attached to PRB1348739 to fix this issue. PRB1357296 was created to supplement this fix.

If the problem persists after applying the update-set, there might be some date/time issue with the file sync. This was fixed in PRB1357296 for Madrid Patch 7.

Introduce a new whitespace somewhere in the following files, and save them. This forces the files to be synced to the MID Server.

Navigate to MID Server > Script Files:

  • WMIFetch.psm1

  • ExecuteRemote.psm1

Resolution

Can I use the new Windows Discovery on some MID Servers and the legacy Windows Discovery on other MID Servers? (Hybrid approach)

Yes and no. You can but may have some failures.

To create a hybrid approach:

  • Apply the update-set that is attached to PRB1348026 / KB0751599.
    Do not apply this update set to Paris and later versions. Back-out the "Revert_To_Legacy_WMI" update set immediately before or after upgrade.

  • Navigate to ecc_agent_property.list and locate the mid.use_legacy_wmi MID Server property.

  • Configure this property with a "true" value only for specific MID Servers. These MID Servers will use the legacy WMI Windows Discovery.

Caveats for the "Windows - Installed Software" probe:

  • You would need to revert this probe to the default probe (the update-set modified this probe).

  • All target hosts discovered with the legacy WMI Windows discovery will fail with this probe.


Article Information

Last Updated:2020-10-01 04:46:39
Published:2020-10-01