Discovery not running properly while using MID Server Service credential

[nikhil_agr20]

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?

[sachin_namjoshi]

Please ensure the mid server user is a member of the local admin group on the target host -- and the target host can't be same as the host where the MID server installed. If it is the same you will get failures, which will seem like the user doesn't have access, when it, in fact, does.

Regards,

Sachin

[DaveHertel]

Hello - if the issue really comes down to the 'client not wanting to put credential on the instance' then this implies they are concerned about security -- a common issue.   The client really has 2 choices:  1) Store creds on the instance, validate, test and thru that learn to trust it's an acceptable approaach OR 2)  use an approach for storing accounts locally on-site, using a solution like the CYBERARK plugin.  This allows the important cred info to be retained by the customer onsite vs. in the cloud instance  More info on CyberArk plugin  Its also possible to build your own local storage of accct info, like the cyberark plugin does (but I dont' have any specific info on that alternative)

Hope this helps?

[chuckm]

I was testing discovery patterns in a test lab and was having the same issue.  I was also storing the Windows Credential on the MID Server Service and getting the same access denied errors for several of the Windows OS - Servers pattern steps.

A work around for this issue is to add the same Windows credential to both the ServiceNow MID Server service and the ServiceNow WMI Collector service.

One of the ITOM developers suggested this solution and it resolved the issue.

[DaveHertel]

Thanks for the info chuckm.   Do you know what that service exists versus the MID Server service?  i.e. While its name implies its collecting WMI stuff, I've never heard an explanation of WHY this service is exists, or why the traditional "ServiceNow MID Server" service just can't do the job.  Any ideas?