- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-11-2019 12:58 AM
Hi Guys,
Since we've upgraded our instance to New York, Discovery requires a admin share on Windows Servers to work properly. Right now we do not have an admin share on our Windows Servers which results in failing discoveries because of following error message:
Is there a way to switch back to the old Discovery method without the necessity to have an admin share on the target system?
This is currently very critical for us and I am assuming that it can't be the only solution to set up an admin share on every Windows Server that needs to be discoverd.
See also following link to the doc: https://docs.servicenow.com/bundle/newyork-release-notes/page/release-notes/summary/rn-summary-chang...
Any help is appreciated.
Best Regards
Solved! Go to Solution.
- Labels:
-
Discovery
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-22-2019 12:36 AM
Following steps are required to switch back to the legacy WMI Discovery:
Contact ServiceNow Support and ask for the Update Set "WMI_Revert_To_Legacy_Discovery". Load and Commit this Update Set on your instance. The Update Set already contains the MID Server Property mid.use_legacy_wmi. It also contains some changes to the Probes to prevent WMI to use the admin share.
After committing the Update Set the first Discovery run takes a bit longer than usual but the second one then works as expected.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-22-2019 12:36 AM
Following steps are required to switch back to the legacy WMI Discovery:
Contact ServiceNow Support and ask for the Update Set "WMI_Revert_To_Legacy_Discovery". Load and Commit this Update Set on your instance. The Update Set already contains the MID Server Property mid.use_legacy_wmi. It also contains some changes to the Probes to prevent WMI to use the admin share.
After committing the Update Set the first Discovery run takes a bit longer than usual but the second one then works as expected.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-15-2020 11:25 AM
Hi
Thanks.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-26-2020 11:56 PM
Hi, no they didn't.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-11-2019 05:21 AM
admin$ is built into the Windows operating system. It's simply the shared folder for the OS's directory, which is typically "C:/Windows".
It's more likely you have some security permissions that is disallowing your Discovery account from writing to the temp folder.
I haven't tested this out, but you could possibly change it to a different share by modifying the Discovery property: glide.discovery.adme.base_dir_windows. The ADM and ADME probes use the same path as the new enhancements for software probes.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎10-15-2019 02:42 AM
Thaks for your hint. I already tried setting the path but it didn't really help. Probably because of the mentioned security permissions. It would be too much effort to grant access on every Windows Server. Therefore, best solution is still to switch back to the old WMI method.