joshfoxbuckeye · Sr. Systems Engineer · ✭✭✭✭✭

I think there is something wrong with this specific module right now. You can see my post here: Network Discovery API Change? - SolarWinds SDK - The SolarWinds Platform - THWACK Typically, you can use the PowerShell SWIS as shown below where xxx is the scan ID number: Invoke-SwisVerb $swis Orion.Discovery…

I already have a script that will assign the correct monitors based on the system type. I was just hoping there was a way to avoid making the separate application template for each port. It sounds like there is no way to specify the port at the time of assignment. Your idea to do a script that runs from the Polling Engine…

Any of the SwisPowerShell commands give the error so something they depend on is in a bad state. 

It is definitely a .NET or other software issue, just curious if anybody knows more specifically what it could be. It works on other systems, so I know it is a package issue. I tried doing repairs of the .NET framework that is installed, but there must be something I missed. 

You would have to create a custom property called 'service tag' or something like that and then manually populate them. Alternately, you can create scripts that will use the Orion API to update this field, but you would have to create a method for capturing each device's service tag in order to populate it.

Also, legacy .NET and PowerShell were not required.

Solved : The problem ended up being the VMware image we were using. It was provided by our Security team and must have had some hardening performed. We were never able to identify the exact issue, but using an image from a clean 2019 server install worked fine and resolved this issue.

Ok, thanks Chad! I am removing the system from the domain and rejoining today because of some schannel errors we see. We will see if that helps and then look at some other security settings.

Also, this testing is all done using unencrypted communication, so no certificate issues to troubleshoot.

After discussing this another Windows admin, we think it is related to a difference in the security settings between 2016 and 2019. Not sure what the fix is yet, but I will update if we find it. Also tagging @"chad.every" In case there are any known GPO configurations for WinRM that have to made in newer versions of…

This is the error that appears in the logs on the target system only when I try new-pssession or invoke-command from the new polling engine. We have a one way trust with the administration domain from each customer domain. The old servers are 2016 and the new ones are 2019 server. Log Name: System Source: LsaSrv Date:…

So here is the weird thing about that. There are no trusted hosts configured on the target system. output is below WSManConfig: Microsoft.WSMan.Management\WSMan::localhost\Client Type Name SourceOfValue Value ---- ---- ------------- ----- System.String TrustedHosts Now after doing the same thing and setting trusted hosts…

 @"chad.every" This is the THWACK post I made. Like I said I probably should have posted it somewhere else and not focused on the script/API. The real problem is that Agent nodes do not migrate properly regardless of the method used to change polling engines.