- Post History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
on 06-08-2018 10:54 AM
This article came from our experience with troubleshooting Service Mapping login failures.
It took a while but we were finally are able to get service mapping working.
It will be good to understand that we do not store Windows discovery credentials in the ServiceNow Credential store. We chose the alternative option to run discovery by having the windows' mid-service service account 'RUN AS' the Windows domain account that has 'LOCAL ADMIN' privileges on the target windows computers/servers.
The reason service mapping was failing was that there is another windows service which requires 'LOCAL ADMIN' access on the target device called the "ServiceNow WMI Collector Service” that runs on the mid server host. It too needs to run under a domain account that has local admin privileges on the target device. We set it to the same account as the Mid Servers. After that, all is well. 🙂
We learned it's needed because service mapping does all querying through the WMI collector service.
Learning this took some time. Even when we created a HI ticket, this information was not known to the L1 or L2 technicians. It seems that this alternative method may not be common knowledge.
So moving forward, all our Service Mapping mid servers will be configured in the following way:
- Mid Server Host
- Change The windows service ‘ServiceNow WMI Collector Service’ needs to run under the domain account with local admin, [DOMAIN\DOMAIN_ACCOUNT]
- Mid Server
- The mid server service needs to run under the domain account with local admin, [DOMAIN\DOMAIN_ACCOUNT]
- The system proper, mid.server.sm_default, needs to be set to a ServiceMapping enabled mid server
- Mid server needs to be given ServiceMapping capabilities or All
- Mid Server needs to be given an allowable IP Range
I hope you find this helpful.
Perry
- 304 Views
