Unable to use -Trusted or -Certificate to connect to SWIS on main polling engine

Your logic is 100% on point.  Running with -Trusted should pass through the creds and -Certificate should use the localhost's SolarWinds-Orion certificate to authenticate.

I've heard (on very rare occasions) that the SolarWinds Information Service (SWIS) may erroneously mishandle these requests.  You may want to open a support case, but I would (personally) restart that service and try again.

Hi Doug,

I have this exact same issue. I have confirmed that it is a local issue. -Trusted works fine when connecting remotely, but not with localhost, local IP or fqdn of the local machine.

I place this at the top of all of my scripts, regardless of if they are run on my desktop or on a server

Import-Module -Name SwisPowerShell
Add-PSSnapin SwisSnapin 
$swis = Connect-Swis -host YOURORIONSERVERNAME -Trusted

If I'm going to run it on my local machine, I just ensure that the AD account I'm logged in is set up in Solarwinds with appropriate rights. Most of the time this is my own personal AD account and I am an admin on my Solarwinds server.

If I'm going to run the same script on a remote machine I log into that machine with an AD service account that has rights to log into the remote machine, and also has appropriate rights in Solarwinds. When launching Powershell I do a Run As and run it as the AD service account. If I'm running it as a scheduled task I run the task as the AD service account. If it is an alert action is also runs as the AD service account. 

Never had any issues doing it this way but plenty of issues trying it other ways. Makes it way easier to rotate the account password when you need to, not have to get into your scripts to update the security xml file etc. Hope this helps.

That did the trick! Though that raises questions on why we're not able to do this on the same server the script is running from. Single poller environments would benefit from this as well as less complexity having to make sure two pollers are always running for this kind of automation. Still a good start for me. Thanks for the info!

That's one way to tackle it for sure. I'll evaluate this against our access controls to see if it's a better path to take than issuing a prompt for credentials each time the script is run by someone manually. Though this is great for automatic remediation!

Didn't seem to help the issue and it turns out that I can run this on an APE from the Main without any issues. Another user confirmed they have the same issue. I'm wondering if this is by design or a bug maybe? Though it brings up questions on how this would work in single poller environments.

Forgot to add that I'll open a case on this to take a look at it. Nothing urgent since I have a work around now but would be good to get a solid answer on why this happens for anyone else looking to do this in the future.

I have this same issue and to date haven't identified a fix. My workaround is to use certificate locally (its a bad practice as it has limited audit trails) and switched most my scripts to run from remote hosts to avoid hitting the problem...

The interesting piece is if you specify the same creds manually it works. It's just an issue with the Trusted option. I'm happy to open a ticket on this one...

I'll add though if you're unable to use -Certificate that may be another issue when running local.

Are you using the latest version of the SwisPowerShell powershell module and what version of Orion are you using?

Case #01199327 has been submitted for this issue I'll relay any updates as they come.

I am currently using the -Certificate switch at this time. Seems to be working as intended when pointing at a secondary Orion server.

I look forward to any additional info you can get on this topic!