dmeiser

rob.hock‌: I currently have up or down as the only 2 options. Is Warning an option?

This is good, but I wish that disabling the agent job monitor in the AppInishgt template freed up the license.

Unfortunately, it's just not that simple. My group doesn't own the jobs that consistently fail, but we do own the backup jobs that run inside the Agent. We need to be able to exclude jobs by name.

I saw those, too. The one that might apply is the first - the last 2 are Server 2003 specific issues. The first one does talk about bad permissions on registry keys. I just have to schedule a restart of the server to see if the permissions worked. I'll update if that works.

mesverrum wrote: I think where people's expectations get messed up here is that the IP solarwinds is polling under blade 1-8 is actually the blades' management IP within the UCS and is not integrated with the OS that is on the blade in any way so they don't see what they are expecting/hoping for. It tells you that a blade…

Right or wrong, the original statement stands: If it's not possible to do this, why is it included in the release product with [incomplete] documentation to get it working? My only thought, then, is that it was working in the lab environment and there must be a way to get it working.

I guess, fundamentally, if no one knows how this works, why is it included in NPM and/or why isn't there a workable walk-through for it?

Right now, when I export UnDP pollers, I lose my custom poller thresholds, so there is 0 portability. By the same token, I cannot easily copy the pollers when moving from iDRAC6 to iDRAC7 to iDRAC8 which may (or may not) change the output of various OIDs. Or, for that matter, copy the App Template when my new server, which…

This is where my insight ends, as well.

cobrien​ and stevenwhunt​ this is what I'm trying to accomplish - I just need to know what SolarWinds did to get this working in a lab. Is it a combination of having the Operating System on the blade under WMI/SNMP monitoring + the SNMP monitoring of the chassis or is it more to do with the SNMP configuration? I'm…

I agree with this - we're still not monitoring SQL Agent jobs because I don't have the rights needed to change the jobs. If we could exclude, it wouldn't be an issue.

Yes. No such luck. The performance counters are loaded, there just isn't any instances. I would manually unload them, but I can't actually figure out what DLL to unload to reload.

naters‌, were you able to successfully get your Meraki to show the number of active clients? Ours show "0" for active clients and current channel.

Using the application template id does not work. I managed to mute them by adding the instance names - we only use a handful of different names.

I thought about this and asked around. Apparently we like the thresholds, but not the alerts. It sounds like maybe a custom group and then exclude the group from the alert may be the way to go.

Thank you!

Did you do anything to setup SNMP on the blade management addresses? Did you change the SNMP defaults on the UCS Manager at all?

What IP address are you polling to get the blade status - the operating system address or the blade management address?

This is exactly where I get confused. I get the Fabric Interconnect info, but I am never able to populate the blade status. For those who get blade status: Are you monitoring the blade IP address (eg - the KVM access address) or the IP address of the Operating System running on the Blade?

Yes, that is the process that doesn't work. I'm wondering if anybody outside their lab has it working.

I had assumed the same. I had assumed that this was something I was doing wrong, too.

I actually need to monitor for that specific error. Unknown can mean a lot of things, for example a momentary spike in CPU usage where the machine just didn't respond (or, since these are old and the application is CPU intensive, that they're actually working on a job). If there's not, we can see if there is other…

I ended up going with SSL Cert Expire Check, which uses Powershell.

Wow... this is old, I had to go check. We never got it working, we just monitor from the originating end, not from the replica end.

I started a feature request to bring it to parity. I just can't see adding 80 disks and then disabling the disks for our other Synology's.

Yes. Just to be 100% clear on what these are for: Only use this method if the roll-up monitoring doesn't work for your specific purposes.

The plot thickens... "DFS Volume State" was also showing as misconfigured, so I did a WMI query via PowerShell (Get-WmiObject -Namespace root\MicrosoftDfs -Query "Select * from DfsrVolumeInfo") and get nothing in response. I thought maybe the whole namespace was pooched, so I queried other objects in the namespace...…

According to support, the only way this happens is to parse them into log files. Since our purpose was to forward to Orion from Kiwi and we want aggregate then forward to a central server, that is not going to work. From our perspective, that is improper handling of forwarded messages, which makes it a bug in the software.

I don't think that it's just displaying the wrong origin, I think it's discarding the origin. Our intention is to use rsyslog to collect at remote sites and then forward to kiwi & logstash, but I don't know that it's going to work if this is a problem. FWIW, Logstash shows the correct origin.

This was actually related to the monitoring user being disabled several days prior. Though it did not start immediately, a reboot of Orion fixed the issue.