Discovery not running properly while using MID Server Service credential

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-10-2019 08:01 AM
I have setup a Windows Credential on MID Server Service. When I am running discovery, CI is being created but most of the data is not coming. I checked the logs. I found that it is giving "access is denied" error within "Windows OS - Server" Pattern Steps.But it is classifying the device & Installed Software & ADM Probes are running fine without any error.
Also I setup the same credential in Discovery Credential table & re-run discovery. Now Discovery is working fine & populating all attributes without any error. It means that there is no issue with the credential.
Client doesn't want to set the credential into ServiceNow instance.
So what is the issue when I am using MID Server Service credential?
Any suggestion?
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-14-2019 09:58 PM
I haven't heard an explanation of why the ServiceNow WMI Collector exists either.
Another option to resolve the Pattern step errors (access is denied): for instances with the Service Mapping plug-in installed, set the mid.sa.prefer_powershell Configuration Parameter to true. When this parameter is set to true, Pattern-based discovery should use the credential on the ServiceNow MID Server service only and not ServiceNow WMI Collector service. I haven't had a chance to test this yet, but the solution was provided by a ServiceNow pattern developer at Knowledge 2019.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎05-19-2019 06:39 PM
Additional details on the access denied errors when using the MID Server Service Credential (Log On As)
The errors occur with the following configuration:
1) The Windows Credential is applied to the MID Server Service ONLY (Log On As .\Administrator in this example).
2) The Windows Server is discovered using the Windows OS – Servers pattern.
3) London ServiceNow instance.
It may NOT be obvious that errors occurred during discovery of the Windows server because:
1) The CI was created (Devices TAB)
2) All phases ran and processed (ECC queue TAB):
3) The pattern completed (Discovery Log TAB):
4) All of the Windows OS – Servers Pattern steps completed (green icons):
All of the individual steps within discovery completed with green icons. In this example, the Pattern contains a total of 39 separate step failures (authentication failed/error: Access denied) and all the step icons remained green (normally a pattern step failure has a red icon). To determine which steps failed requires going individually one by one. An example of an error (authentication failure/error: Access denied) is shown for the Get OS address width individual step.
Many of the attributes and related item data do not get updated as a result of the access denied errors from the Windows OS – Servers pattern:
Solution
A work around to resolve the errors is to apply the same Windows Credential to both ServiceNow MID Server service and the ServiceNow WMI Collector service.
After applying the credential and re-discovering the Windows server, the CIs attributes and related data updated correctly the 39 step errors (authentication failed/error: Access denied) cleared as well.