tdanner ✭✭✭✭✭

When making /Invoke/ calls, the POST body is always a JSON array of the arguments. In this case the verb only has one parameter, so this will be an array of one item. Wrap it in [ ] and try again.

This API has not changed.

Think of "entity" like the name of a class and "verb" like the name of a static method on that class. There are many verbs you can through this interface. The exact set depends on what products you have installed. Our "all products" test server shows over 400. What you need to pass for *args depends on which verb you are…

How about this? swis.invoke('IPAM.SubnetManagement', 'ChangeIPStatus', '1.1.1.1', 'Used') If you want to use requests.post, then the body should be an array, like ['1.1.1.1', 'Used']

It does

Two SWJobEngineWorker.exe processes is normal. And to answer your question, UnDP polling will run from whatever poller the node is assigned to.

I don't have a date to give you, but it will be sooner than the next full release. When that comes out, I'll post in this forum.

Have you tried passing the username in "domain\username" format and the password? That ought to work.

The SOAP equivalent to Set-SwisObject is Update. So the perl call would look like this: $swis->Update('swis://localhost/Orion/Orion.Nodes/NodeID=1/CustomProperties', {'Comments'=>'Custom comment'});

In another thread, you mentioned that you have two pollers. Is that one SLX and one Additional Poller? This log is from the SLX, right?

It is not currently scheduled for implementation. I have added your vote to the internal feature request. If you want, you can lobby jpetkevich​ (NCM Product Manager) to boost the priority of this.

What is the specific timeout error you are hitting? There are multiple levels of timeout between the browser, IIS, and various backend services that contribute to the report.

You are correct. To install 8.5 on a non-Internet connected server, you will need to get .NET 3.0 installed first.

Can you remember where you found the incorrect example? I'd like to fix it if I can.

Could you tell me more about why it didn't work? Did you talk to support?

No. In general an older SolarWinds.InformationService.Contract2.dll will still connect to a newer SWIS just fine. The SNMPV3 property errors have nothing to do with the SWIS Contract DLL. That's a server side problem. You would have the same errors regardless of how you send the request.

Parsing and correctly applying all of the possible scope conditions from the xml would be very challenging. There's no great solution to this. One way you might be able to tackle it would be borrow the web service that populates the "all alerts this object can trigger" resource. Use your browser's dev tools to look at the…

Now that you mention it, I don't know of a way to edit the DNS name of a dynamic IP node after it's been added. I guess you could edit in the database directly if you need to. Or just delete the node with the old DNS address and add a new one with the new DNS.

If you are not writing code, why not just do the search in the NCM web console?

SolarWinds sales can take care of you for issues you encounter while evaluating. If you want to investigate further yourself, the next step would be to find out more about spid 77. I would start with "exec sp_who2" and look at the info for spid 77, especially the HostName and ProgramName columns.

Can you tell us more about your deployment? What version of the product, what time zones machines are in, and a concrete example of what API call you make (with actual values) and what the observed behavior is?

In general there is no need to worry about matching up versions of the product and the SDK. They are forwards and backwards compatible.

If you just want the MAC addresses for things that are monitored as Nodes in Orion, you can get that with a query like this: SELECT N.NodeID, N.Caption, N.Interfaces.Name, N.Interfaces.MACFROM Orion.Nodes NWHERE N.Interfaces.MAC NOT LIKE ''

The IP address (or hostname) should be where the Orion server is installed. This may or may not also be where the SQL database is.

With SWQL Studio, are you connect with the "Orion (v2)" or "Orion (v3)" server type?

From these version numbers I can see that you are running NPM 11.5 RTM. The specific error you are seeing is a known issue in that version. I don't know how it could have worked for the prior two months if that's the version you were running then as well. The solution is to upgrade to NPM 11.5 SR2.

The API is on a different port than the web UI. The URL you should hit is: https://solarwinds.mydomain.com:17778/SolarWinds/InformationService/v3/Json/Invoke/Orion.AlertStatus/Acknowledge And you'll need a few options for curl: -k (to accept the self-signed certificate Orion uses on port 17778) -u admin:password (for HTTP…

So the web browser just says "page cannot be displayed" - not a certificate error? What version of NPM are you running? You can email the log to me. Address in my profile.

Is the Orion Module Engine service running?

When you add a node using the discovery API, its volumes are added automatically.