SQL Probe and WID

DuaneNMore · ‎11-21-2016

When I run a discovery against a Windows 2012R2 server, the SQL Server probe finds the Windows Internal Database and thinks we have a sqlserver. This is because this thing runs as C:\Windows\WID\Binn\sqlserver.exe. I think I'd like to ignore this particular instance, but the way discovery is set up, if it sees sqlserver.exe it thinks you are running sqlserver. Being new to discovery (took the class last week) I know there is a way, but I am uncertain how.

I also have the additional problem of installing the SQL management library (SMO) for when I do discover real sql servers but that is well known.

Ryan Zulli · ‎11-21-2016

Hi Duane,

The process classification is where you'd want to look...Discovery --> Discovery Definition --> CI Classification --> Processes. Click on the Microsoft SQL Server record and you'll see that we look for a condition where Command contains sqlserver.exe. Here you can add another condition, AND where Command IS NOT C:\Windows\WID\Binn\sqlserver.exe.

Of course the proper way would be to copy the OOB code and create a new record that way during the next update you can compare changes (if any).

Let me know if this helps.

Thanks,

-Ryan

View solution in original post

Dave Smith1 · ‎11-23-2016

Okay - just an odd question, but are you using IE? If so, could you try the same thing in Chrome?

I've experienced some situations where callbacks to change a field value don't always work in IE. From what you've said, it is completing, just not reflecting it in the status. Is that right?

DuaneNMore · ‎11-23-2016

Yes it appears as though it is completing but not reflecting the status correctly. I am using Chrome as the browser. Discovery schedules reflecting Active are all of them; not just the ones where I click through "refresh" repeatedly. For example, the Discoveries that ran at 00:30 this morning both appear to be completed, but show status active.

Dave Smith1 · ‎11-23-2016

Okay, that's fairly weird. At least it is completing but just not letting you know!

A few other checks I can suggest:

event log - look for any discovery. events, in particular discovery.complete. See if they're actually getting triggered. If so, perhaps trying to bind some response against this event just to appraise you that it's been complete (but not reflected as such) - just curious if the change in state is triggered by an event somehow.
a different browser, say portable FireFox, just to see if it's something odd with your build of Chrome.
different desktop - Chrome on someone else's machine, for same reasons as above. This should try to narrow it down as a browser issue
different user - create another user and give them discovery_admin role (okay, put them into a group with that role) and have them run the same schedule. See if it's confined to a user account somehow.

Can I also ask: is this a new instance of Helsinki, or an upgraded one? Just wondering if there's some BR or script hangover from a prior change that's found its way through and is affecting this field change. That's simply what it appears to be, just a matter of finding where the "blockage" is.

DuaneNMore · ‎11-23-2016

Just tried Firefox; same behavior. If I go directly to the discovery_status.list table, it is clear that they are all either cancelled or active. So it doesn't really appear to be a browser behavior.

My understanding is that this is a Helsinki instance built from scratch not an upgrade. Also it is an on-premise instance.

I went through the event logs and for example, on the most recent SNMP scan I see the sequence of discovery.started, discovery.phase.completed, discovery.device.completed. all within 45 seconds of each other. For today I see 6 discovery.started, 7 discovery.phase.completed and 3 discovery.device.completed.

Dave Smith1 · ‎11-23-2016

Righty - definitely appears that the event isn't firing. Can you check the events are definitely registered? Mine look like:

Hope that helps!