tdanner ✭✭✭✭✭

When a user with an account limitation loads a view with a view limitation, the set of visible nodes is the intersection of the set allowed by the account limitation(s) and the set allowed by the view limitation. The limitations all are applied simultaneously - there is no notion of one taking precedence over another.

You can do it in one script, but it will need separate statements for reading and writing the custom properties. The line in the original script where it sets the "ImportedByAPI" custom property should get you pointed in the right direction.

In SWIS, custom properties are not properties of the Orion.Nodes entity, even though they are stored as columns in the Nodes table in the database (though they are moved to a separate table in NPM 11.5). This is why you are getting that error when you try to copy CustomProp1 from one instance of Orion.Nodes to another.

See if SDK 1.7 fixes this. We have a fix that relates to this area that might cover what you are seeing.

There are a variety of possible causes for this error. One common one is if the system clocks are not in sync between the client (where you are running the PowerShell script) and the server you are connecting to. Could this be your problem?

This script will copy the SNMPv1/v2 community string (and read/write community string if you have defined it separately), but it does not copy SNMPv3 credentials. This is because SNMPv3 credentials are not available through the API for security reasons.

This is an older post with quite a few comments describing variations. Could you outline what you are trying to do in more detail?

No updates here. This has not been implemented yet.

You can get the day of the week from a date in SWQL using the "WEEKDAY" function. So to exclude weekends, use "WEEKDAY(datetime) NOT IN (0, 6)". This function was missing from https://github.com/solarwinds/OrionSDK/wiki/SWQL-Functions, so I just added it.

The need is well understood and addressing it is in the backlog, but I can't comment on timeframes.

Have you looked at the samples in the SDK? It shows how to add nodes to Orion in several languages.

Ah - I missed that you have already tried SDK 1.7. I'll continue investigating.

This page describes the API features around credential management that we have today: Credential Management · solarwinds/OrionSDK Wiki · GitHub. It doesn't cover NCM connection profiles.

SWIS can be used with .NET 4. In fact, this is how the SolarWinds products use it. The version of SolarWinds.InformationService.Contract2.dll that is shipped with the SDK targets .NET 2 solely for compatibility with PowerShell 2, but it can be used in a .NET 4 process just fine. Could you be specific about what .NET…

Sorry for the late reply, but I think it might be helpful for me to explain what's going on here. In SDK 1.5, the Connect-Swis cmdlet connects to SWISv3 by default. NCM 7.0 does not include SWISv3, so this connection fails. You can cause Connect-Swis to talk to SWISv2 by adding the "-v2" switch to the command line.

Well, I haven't been able to reproduce this error with NPM 10.4.1 and SDK 1.7, so it may be something specific to your node data. Based on what the error is, it must be related to a single-character field. We don't have very many of those. In fact, the only one on the in the "nodePropsToCopy" list is "CMTS" which relates…

Sorry, I haven't worked with this since then. I don't have any additional information.

The intermediate authority certs only matter for validating the final cert. For the purposes of identifying the cert you want the service to use, take the thumbprint of the "bottom" cert at the end of the path.

SwisPowerShell does not support impersonation. The protocol that SwisPowerShell uses to talk to SWIS does support impersonation, it's just not exposed in the powershell module.

There is no "Set-SwisData". That should be "Set-SwisObject". I'll update that old post.

This isn't a timeout issue. When you run "Connect-Swis ..." without saving the result to a variable (as in "$swis = Connect-Swis ...") then PowerShell takes the result of Connect-Swis (a connection object) and just prints out its properties. It just happens that the first property PowerShell prints is called…

ToLocal just makes a time zone adjustment - it doesn't do any formatting. The API returns DateTime values in ISO8601 format. These typographic issues must be coming from whatever tool you are using to display the output.

Nothing really to add to what I posted before. The |§|§| delimiter was just chosen by some developer as a magic string unlikely to occur in normal text.

The API runs on a different port (17778) than the website (usually 80 or 443) and handles authentication differently. It looks like you are using the correct API port in Postman/Insomnia but (incorrectly) the website port number in your ITAM tool.

SwisPowerShell uses only port 17777. This uses TLS but not HTTP, so it may not play well with load balancers. Can't help you there. Giving the client some control over the server-side timeout makes sense to me, but there are no concrete plans at this time.

If you are willing to build compile it yourself, this is available on an experimental basis on this branch: https://github.com/solarwinds/OrionSDK/tree/powershell-core-experiment

There has been no change to the server-side timeout for REST API requests to SWIS.

Excellent!

You have API access. Just run this: Get-SwisData $swis "SELECT EngineID, ServerName, IP, ServerType FROM Orion.Engines"

Latest error: Engine Id 2 does not exist