Discovery Admin Share

Tuna
Giga Guru

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:

find_real_file.png

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

1 ACCEPTED SOLUTION

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.

View solution in original post

20 REPLIES 20

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.

erik_alvarez
ServiceNow Employee
ServiceNow Employee

Hi @Tuna  I found myself with a similar situation, did support mentioned somekind of warning if reverting back to legacy?  For example, no support or further improvements to the pattern?

Thanks.

Hi, no they didn't.

Andrew Westerv4
Mega Guru

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.

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.