tdanner ✭✭✭✭✭

SWIS has 6 basic operations: Query, Invoke (a.k.a., call a verb), Create, Read, Update, Delete In the REST format, you call Create with a URL like .../Create/[entity type name] You call a verb with a URL like .../Invoke/[entity type name]/[verb name]

Please see the document I linked - replacing the main server does not change the Uris. The system identifier in the Uris does not change. Something else must be going on. What product and version are you using?

> Do you have any idea when a similar function for a Volumes Plugin would be available like the Interfaces plugin you describe in this wiki? I got your +1 for that request, but I have no timeline for you.

Sorry for the long delay! This one fell through the cracks. The arguments for Cirrus.ConfigArchive.Download are: * NodeIDs - this is an array of the values from the NodeID property of Cirrus.Nodes, which is a GUID. You can query Cirrus.Nodes to look up this guid from the regular Orion integer NodeID values (using the…

Unfortunately bulk update is not supported through the rest API at this time.

Do the node/interface/volume IDs match up between your two databases?

Are you authenticating the same way in PowerShell and SWQL Studio?

NCM 7.0.2 now provides a programmatic way to add a node. You can follow the instructions in the SDK to add a new node to the system, then invoke a new verb to add this node to NCM. The new verb is Cirrus.Nodes.AddNodeToNCM, and it takes one argument: the NodeID. From PowerShell, it would look like this: Invoke-SwisVerb…

It may not be on the start menu on the additional web server, but it should be in your installation directory (usually \Program Files\SolarWinds\Orion). Look for CustomPropertyEditor.exe.

Ah - that explains it. These fields were added to that verb in 12.0.

Orion's default behavior is for new agents to automatically add them as nodes and start monitoring. You can change this on the "Global Agent Settings" page (/Orion/AgentManagement/Admin/Settings.aspx).

Correct.

NCM switched to SWISv3 in version 7.3.

Ok, I see what's happening here. You are unintentionally exploiting a loophole - since IPAM groups and subnets are stored in the same database table, updating a "subnet" (but actually providing the ID of a group) does rename it. But since you are going through a subnet API, it then tries to scan the subnet (this is normal…

No, you are not missing anything. I was mixed up on which resource had that option. I opened CORE-8624 to get the option added to Custom Query resource. Just write that bug number on the cases of liquor before you ship them.

Are you using the script I sent or a modified version?

In the "server name" field, put the host name for your Orion server. In the "server type field", choose "Orion (v3)". For the username and password fields, log in the same way you would log in to the Orion website.

Is there a section after this where you add the pollers?

Since this post, many API features have been added to IPAM. Please see this page describing IPAM 4.7's API: IPAM 4.7 API · solarwinds/OrionSDK Wiki · GitHub

Ok, there's a few things going on here. 1. You are using the new alerting system (introduced in NPM 11.5). 2. Orion.AlertStatus.AddNote is the API for adding a note in the older "Advanced Alerting" system. It still works with new alerts through a compatibility layer, but it's not the current API. 3. The current API is…

How did you get this ID from the alert you are testing?

The way to avoid explicit joins is called navigation properties. To add the node name to the query, you can do this: SELECT VolumeID, Volumes.Node.NodeName, Caption, TypeFROM Orion.Volumes WHERE NodeID=123

Not using this approach. If you switch to using the discovery API, you can add a node with all of the interfaces and volumes including the appropriate pollers for whatever device type it is. See this post for details: Triggering discovery of SNMPV2 device through JSON API

"Looking at the SWIS log, I'm not seeing a connection to the BusinessLayer" --> it wasn't the SWIS log that steered me to the NPM BL log. The SWIS log pointed me to the relevant code, which pointed me to the NPM BL. Reading the code gives me an unfair advantage.

We don't provide or support those kinds of SQL scripts. Advanced Alert configurations are an XML blob, so that would be pretty awkward to manually update. Basic Alert configuration in the database is pretty straightforward, so I bet you could figure it out.

This appears to be the problem. In Python, we have this: 'PluginConfigurations': [ {'PluginConfigurationItem': config} ] Which means that in the python dictionary we are building, the key PluginConfigurations should have a value consisting of a list with one item that is a dictionary with one key, PluginConfigurationItem,…

You can use the "CustomProperties" navigation property to access Provider_name. Under the hood this turns into another join, but the syntax is much simpler: SELECT Caption FROM Orion.Nodes orionnode LEFT JOIN NCM.Nodes ncmnode ON orionnode.NodeID=ncmnode.CoreNodeID WHERE orionnode.Vendor='Cisco' AND ncmnode.NodeID IS NULL…

I can't think of any instances of this issue that we successfully traced to a root cause. We either gave up or the poster switched to a different box and the problem went away.

What version of NPM are you using?

Not with GetJobLog. I don't know what larger task you are trying to automate, but have you read https://github.com/solarwinds/OrionSDK/wiki/NCM-Config-Transfer?