bhumphrey

Without a scope and condition, you'd be required to attach calendars individually to objects, rather than saying something like: Apply this calendar to all nodes where operating system is Windows Server 2016 and environment is PROD and alerting priority is P1. 

We had talked about using custom properties for this, so teams within our organization can manage their own alerts and Orion administrators can simply create a standard set of alerts that reference drop downs on each monitored object. The teams then manage their own drop downs and we don't have to mess with alerts anymore.…

The other issue here is that you can't have a single node be a member of multiple "groups" in the NCM node groups. We ended up just using them like tags and wild card searching for them like "iseDevices, energyWise" then search Node Group LIKE '%iseDevices%', etc.

Great idea - I'd also like to suggest adding a scope and condition statement to the calendar, which would define which object(s) and on what conditions the calendar would apply (would be very similar to the alerting - trigger condition page, where you have the scope of the alert and the trigger condition). Example 1: I…

Turns out, the 'down' condition in my code prevents the statistic value and message from being recorded (not my favorite behavior), but that means I'll just need to update the code to exit critical when errors are encountered and I'll treat, for this alert, critical as down. That said, this query was great. Thank you!

The query seems to be missing the message during a down condition. Here's what I mean: The component went down at 8:43 PM on Sunday. The query shows this: (This assumes UTC - we're UTC -7 - though I did also check if it was toLocal and it's same results). I was expecting to see something like this: Click more (bottom right)

Ah, that makes sense. So the assumption would be, once the tables had the right name, the Configuration Wizard would get the URI value updated to match the new primary polling engine name?

Hey @"yaquaholic", just checking back here. Any chance you know where that first part comes from? The swis:{pollingengine} name?

Hey Tony, I ended up learning that I was doing this wrong. SQL doesn't take regex like I was expecting. The appropriate way would have been something like: [C-Z]:\% Going back to SWQL for this.

Understood, thank you for diving into the weeds here with me on this. I appreciate the time (and getting to walk through the troubleshooting process - which has been a great learning experience so far). We're grateful for all the hard work you and the team put into the product! I'll wait to hear back.

Hey @"tdanner" Here's what I'm seeing in the C:\ProgramData\SolarWinds\Logs\Orion\Core.BusinessLayer.log: 2020-07-01 16:56:37,422 [37] WARN SolarWinds.Orion.Core.BusinessLayer.OrionDiscoveryJobFactory - (null) Plugin SolarWinds.VIM.DiscoveryPlugin.VimDiscoveryPlugin was not able found valid job description.…

Hey @"tdanner", Glad you mentioned those commented lines, I totally forgot to delete those when I switched those into parameters on the function. Those values actually come from here: I tried just commenting out the entire interfaces plugin configuration context section of the function and just copying and pasting the…

Hey @"tdanner" , Sorry on the delayed reply. One of those Mondays... You totally called it. The .ToString().ToLower() did the trick. The discovery now runs, but it looks like the interfaces aren't being added for some reason. Volumes came through perfectly, but on interfaces, I got nothing. I tried setting the $isHidden to…

@"tdanner" - I know this is old, but I'm seeing the same thing and I've got through each of the variables to make sure they're properly set. I've also reviewed the Orion.InformationService.log. It seems like the same thing, but I can't figure out what's going on. Sample of commands: $path = c:\temp\pw_swis.txt…

Ah, that makes sense. I was assuming that all of the values that could be returned were on that list. Thank you for the clarification!

Hey Tim, When we pass on the pipeline, AFAIK, it still runs the process block for each object passed on the pipeline, right? Each of those would technically consume one of the database pool connections? Since we can configure the maximum number of connections, it's not a huge deal, but I was just throwing out there that it…

I'll see if I can push my way through change management and get this done today and get back to you on results. Thanks, Marc!

Hey Marc @"mesverrum" This fixed it, thanks a ton man. Might I be able to ask a related question, now that this is working? I can post on a separate question, if that's better. I was thinking there was a flaw in my logic. I run discovery to find anything that responds to SNMP and then bring in all "up" interfaces and…

Ah, nice, I didn't realize that. Thank you for the quick reply!

This is great. I can build a set of params before the query. That actually makes the script I was working on easier. Thanks!

Hey Tony, I just heard back on a different post on one of the solutions. I was having an issue with certain characters, but that can be gotten around with params. The other, I'm not quite sure on. Essentially, a way to utilize regex in a query. Something like this: SELECT V.VolumeTypeID, V.VolumeType, V.VolumeDescription,…

Is that prefix: swis://{pollingengine} Not required? That was one of my sticking points. The {pollingengine} part is the FQDN of our original primary polling engine. Since then we've upgraded multiple times, migrated to two new domains, and added additional polling engines/HA/etc. But still the URI has the old name for…

@"aLTeReGo" - Is this still the case in 2019.2+? I've got a 'Service Status - SNMP' component and the statistic threshold says 'Warning - not equal to null for a single poll' (since I don't really care about warning) and 'Critical - not equal to 1 for a single poll'. When the value comes back not equal to 1, the status of…

Quick note here. I ended up getting a resolution on the issues I was having with the SNMPv3 $newNodeProps. The SDK works fine, when you don't misinterpret values in the database, haha. This was one of the roadblocks for me publishing to the community, so hopefully you'll see something from me here in a few weeks (of course…

This was exactly what I was looking for (and much simpler than I had thought). Thank you!

@"tdanner" @"dan_jagnow" @"mesverrum" Hey Gents, Sorry, I know this is an old thread. I was hoping to get some clarification on some behavior I'm seeing from the 'add interface' portion of this: $newIntUri = New-SwisObject $swis -EntityType "Orion.NPM.Interfaces" -Properties $newIntProps Here's what the newIntProps looks…

Thanks mesverrum​ - you gave me the clue I needed. I built the expected statement in the UI and then when you select to 'Edit Dynamic Query' In the URL, you can see the HTML encoded version of the filter. Here's the full list of all operators in examples: IP_Address is 192.168.10.10…

Hey surak​ - thanks for the reply. I'm sorry if I'm misunderstanding, but I'm only seeing 7 cmdlets with the SwisPowerShell module and I'm already using that as far as I know. Are you saying there's a different way to use the SwisPowerShell module to perform discovery tasks?

I worked with support on this and it turns out that Windows agents are polled via WMI and the index value provided by WMI does NOT match the index value provided by SNMP. I got around this by not including ObjectSubtype = Agent nodes in any automation that relied on index values matching from SNMP-based discoveries.

Ended up figuring this out. Turns out I had been using a discovery profile with stale data and since that time, a configuration change had been made and the interface index was different. After re-running the discovery and using the current info, I was able to add the interface without issue.