PowerShell Integration Issues

[DylanB]

Hi all, I am attempting to run a simple PowerShell script and I'm running into various issues. We have a service account set up and that account has access to the mid-server. When manually remoting into the mid-server as that account, I can run PowerShell commands.

I have set up a connection and credential for this but to be honest, I'm not totally sure the settings are correct. What I'd like to do is use the service account to run PowerShell commands on the mid-server. 

When attempting to run the below script via the PowerShell action, I am getting a couple of different errors depending on my settings. The current error is below. Any help on this would be greatly appreciated. 

This is the inline script I'm running:

Get-ADUser -Filter "employeeid -eq '14892'"
        
    $GUID = Get-ADUser -Filter "EmployeeID -eq '14892'" | Select-Object -ExpandProperty ObjectGuid | Select-Object -ExpandProperty GUID
    $FirstName = Get-ADUser -identity $GUID | select -ExpandProperty GivenName

Write-Host "$FirstName"

These are the connection details I'm using: 

[DylanB]

Update: I was able to clear the user credentials error by updating the host on the connection to 127.0.0.1.

However, now get these errors. 

[DylanB]

Well, I figured out the missing terminator " issue. I can't imagine anyone else will run into this exact problem but if it keeps one person from tearing their hair out trying to solve this same problem, I'll document it here just in case.

I discovered that when running an inline script from ServiceNow, it creates a temporary file on the midserver. That temporary file has other PowerShell code in it, part of which was the username and password of the service account being used to run these commands. So in reality, it was running the following code, in which the randomly generated service account password just happened to have a quotation mark (") in it in plaintext, which was causing the missing terminator issue... Removing the quotation mark from the password removed the missing terminator issue. 

To provide more info on this, the temporary script file is stored here on the midserver in my case: C:\Users\SNowMidServerAct\AppData\Local\Temp

It might be different in your org but the file path and name can be found in the execution logs.

It's important to note that the temporary script file only exists for a couple of seconds while the script is running, and then it's deleted, presumably to remove any trace of the plaintext username and password, so the way I was able to retrieve the full code was to run the script on ServiceNow, immediately refresh the folder on the midserver, then open the temporary file and troubleshoot from there. 

Despite all that, I'm still getting a different error about not having access to the server but I imagine that's a permission issue with the service account. Either way, I'll update this when I figure it out. 

[abelal]

I don't usually criticize a product without trying all features. The service now powershell feature is pain to work with, whoever developed it must be laughing at anyone who tries to use it for anything more than write-host.

I've extensively tested several variations of options and nothing works the way I would expect.

I've discovered depending on the type "Remoting Type" selected service now wraps the scripts with some junk that is not documented anywhere. I managed find it by looking at the logs and saw whilst testing powershell action scripts are created in %userprofile%\appdata\local\temp. They are short lived and are deleted a few seconds but the contents of it differ based on remote type selected.

The "Test powershell step" button is nothing more than MID testing new-pssession command againt the host however, when the actual action is tested MID does some other weird nonsense where RPC firewall need opening, that's not the case with "Test powershell step". So it's if it succeeds.

What you're seeing @DylanB is more than likely what I'm seeing, I selected "Run on MID.." as remoting type and noticed anywhere I put "-credential $cred" the temp script generated by MID removes those parameters from command - what that means is the action is actually being executed by the mid server service account, not the account you defined in connection alias. Why would a product do this?

It would be far simpler if powershell instance started by servicenow ran under credential alias, but there is simply no option for this.

Habing spent several days investigating I've come to a stage where I've almost given up on this. Really hoping servicenow support can help.

[DylanB]

Thanks for the extra info! I may come back to the Powershell action at some point, but for now, I've found a "workaround" of using the actions from the AD v2 spoke. Since those actions also use Powershell and its own credentials, I copied an action that's similar to what I need to do and changed a few parameters. 

Here's the other post I made about this if anyone's curious: Solved: Look up user in Active Directory from Flow Designe... - ServiceNow Community