cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post
Level 8

Powershell Scripts not inheriting credentials in 2020.2

Jump to solution

I just upgraded to SAM 2020.2 last Friday and immediately after upgrading all of my Powershell Script monitors that require inherited credentials to run no longer appear to be inheriting the credentials correctly. I have an open support case, but I'm not getting much communication and have a significant amount of monitors that continue to be in an unknown state. Anyone encountered something similar before?

Example:

kschmalz_0-1592412308531.png

 

From the log it appears to be able to retrieve the correct username:

2020-06-15 08:47:48,383 [18] [C8950] [WU:RegularBatch(PowerShellProbe)(65590)] DEBUG SolarWinds.APM.Probes.NetworkUser - Init called: userName = (Username), domainOrMachine = (Domain), logonType = (NewCredentials), LogonProvider.DefaultProvider = (DefaultProvider)

 

Further in the log it looks like it is not actually running powershell as the inherited user.

Exception calling "Open" with "0" argument(s): "Login failed for user 'DOMAIN\POLLINGSERVER$'."

 

1 Solution
Level 8

Support provided me with 2 repaired dlls which I imported into my installation yesterday that appear to have resolved the issue.

I had to ensure all templates with powershell scripts were set to agentless polling, but have not had any issues since applying the fix.

View solution in original post

15 Replies
Level 9

I ran into this issue also in my environments after upgrading to 2020.2. Solarwinds provided two dll files, but you have to go through support to get them.  Here's what you need to do to have the information support needs:

1) Enable debug logging on the application template that's having the issue via https://support.solarwinds.com/SuccessCenter/s/article/Turn-on-application-debugging-for-SAM?languag....  This article will also show you how to figure out where the log file is.

2) Open a case with support and let the know you're running into the issue.  They will provide a secure ftp link to you to upload the debug file.

3) Solarwinds will provide the dll link download that has instructions on how to implement it.

Hope this helps..

 

0 Kudos
Level 8

Support provided me with 2 repaired dlls which I imported into my installation yesterday that appear to have resolved the issue.

I had to ensure all templates with powershell scripts were set to agentless polling, but have not had any issues since applying the fix.

View solution in original post

I had many tickets open for several weeks but didn't hear anything back on the WMI polling issue, certainly no ZIP files to fix the problem, even thought I added this url to the ticket.  In the end I gave up and closed all the tickets as none were getting anywhere.

I started re-writing all my scripts as a workaround.  My problems only occur if polling via WMI.  In that case the data which is returned related to the poller, I'm monitoring memory/cpu (to note when they change over time), local certificates, last time the server was patched, but the data being returned when polling via WMI is the values which related to the poller, not the node being monitored.  95% of all our Windows boxes have agents, so it's very annoying but not devastating for us.  Powershell scripts with an agent installed work fine and return the correct data.   I took the node name and credentials from the template (inherit credential from node) then passed those to Get-WMIObject.  That way it works whether polling via agent or WMI.

$sysname = '${Node.SysName}'
$creds = '{$creds}'
write-host 'Message.SystemName:'$sysname
write-host 'Statistic.SystemName:0'

$cs = Get-WmiObject -class Win32_ComputerSystem -ComputerName $sysname -Credential $creds | select *
if ($cs.numberoflogicalprocessors -eq $null)
{
$cores = $cs.numberofprocessors
}
else
{
$cores = $cs.numberoflogicalprocessors
}

write-host 'Message.LogicalCPUs:'$Cores
write-host 'Statistic.LogicalCPUs:'$Cores

In another case, to get the Powershell version, I did similar but used an Invoke-Command.

$sysname = '${Node.SysName}'
$creds = '{$creds}'

$fullpsversion = Invoke-Command -Computername $sysname -Credential $creds -Scriptblock {$PSVersionTable.psversion}
$majorversion = $fullpsversion.Major
$minorversion = $fullpsversion.Minor
$powershellversion = -join($majorversion,".",$minorversion)

Also, please do not be tempted to use the Microsoft Edge Chromium browser to edit templates - I did and it was a big mistate.  I ended up with the same template added multiple times to nodes (who knew that was even possible!), and also component monitors in a template duplicated randomly.  Stick to Chrome, please.  I ended up writing writing a ton of Powershell to clear everything up.  But now I have Powershell to add templates to any nodes where they don't already exist.

Hopefully this may help others.

0 Kudos

It's worth mentioning I've just updated this - some machines which had agents didn't like doing the Invoke-Command remotely - don't know why just now, so now I check if it's running as the agent (if so it's runs as SYSTEM, and that is typically run as the [None] credential.

$sysname = '${Node.SysName}'
$creds = '{$creds}'

if ($creds -eq "$creds")
{
$fullpsversion = $PSVersionTable.psversion
}
else
{
$fullpsversion = Invoke-Command -Computername $sysname -Credential $creds -Scriptblock {$PSVersionTable.psversion}
}
$majorversion = $fullpsversion.Major
$minorversion = $fullpsversion.Minor
$powershellversion = -join($majorversion,".",$minorversion)

When it runs the Solarwinds language processing will try to replace '{$creds}' with the credential, but if it's set to [None] then it won't replace it, so if the string is literally {$creds} we know the credential used was [None] and you typically use this when you run using the agent - some people may do things differently.  Either way, it cleared remaining errors, so for me this is the way to go - only use Invoke-Command if there is a credential, and there is only a credential when I'm not using the agent.

 

0 Kudos

It is indeed a bug. Depending on the cmdlets you are using, you may be able to pass the Credentials from SAM like this

 

2020-06-25 12_27_48-Edit Application.png

MVP
MVP

It's a bug in the new version and SolarWinds is aware of it. I'll see if I can get some more information.

Level 7

I'm having the same issue. Any fix yet?

0 Kudos

maybe try adding this to the start of the script and testing it

[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Tried this without any success.

0 Kudos

The scripts I wrote for muting nodes and other management tasks fail as well with the error "Get-SwisData : An error occurred when verifying security for the message." The scripts work fine if I use the built-in SolarWinds Admin account, but get this error if any AD user runs the script. I did try the suggestion above as well as the -V2 switch and this didn't help. It seems AD accounts are the problem.

0 Kudos

are you using URL Rewrite for your website? I've read that if you're doing that SDK fails to work with AD accounts. I'll try and dig up the article for it, idk if it still a limitation. *EDIT*. What I've had to do in the past when using URL Rewrite is just stick to local Orion accounts, launch the script from a polling engine and use the "-Certificate" flag for authenticating (this is my preferred method), or turn off the rewrite

Thanks for the reply. We are not using a URL rewrite. We do use a wildcard cert and an Additional Web Server,. The web server uses the wildcard URL while the main polling engine does not. I tried making the URL used for the connection to the primary polling engine match the wildcard cert and it didn’t seem to help.
0 Kudos

can you connect using the SWQL studio using an AD account?

0 Kudos
No, looks like that broke too.
0 Kudos

Sorry for not updating this sooner. We finally got some help on this and it turns out that the issue has to do with our specific setup. The main application server is joined to a different AD than the SolarWinds application uses for authentication. This is causing a problem because it is looking for the machine object and cannot find it. We are planning a maintenance window to get this corrected and I expect it to be resolved soon. 

0 Kudos