ServiceNow Orchestration - MID Server selection with PowerShell activities

[melissajanuszko]

I have a PowerShell activity that needs to run on a specific MID Server that is not the default MID server, but the MID server is being randomly selected.   Sometimes when I run "Test Inputs", it returns the output successfully and sometimes I get "authentication failed for user".   When I get the "authentication failed" message, I can see messages from the activity in the default MID Server's agent.log that it tried to run there.   Here is what I have read and configured so far:

I have read this post already:   Powershell Orchestration Tips & Tricks   .

I have the desired MID server configured with Supported Application -> All (this is for Orchestration), an IP range set (x.x.x.x/23) with type include, and capabilities ALL, PowerShell, and ResolveDNS.  

I have the default MID server configured with Supported Application -> ALL, IP Ranges -> ALL, and capabilities ALL and PowerShell.

I also have an entry in the cmdb_ip_address_dns_name that translates the target host name in the PowerShell activity from name to IP address.   I have tried using both name and IP on the target host field in the PowerShell activity with similar results.   The IP address of the target host is in the IP range defined on the desired MID Server configuration.

Do I need to define an exclude for the default MID server so that it doesn't try to go there?   How do I configure "everything goes to the default MID server unless the target host is in this IP range?"

Any advice is appreciated.   Thank you!

[Bogdan Moldove5]

Hi Melissa,

I'm sharing with you my trick that always worked. If , say , the powershell script needs to do something remote (e.g restart a process on a remote computer passed in as a param1)

1. First your Powershell script must create a session to the remote target "param1" using the New-PSSession and pass the $cred object as Credential.

$Session = New-PSSession -ComputerName $param1 -credential $cred -Authentication Negotiate -ErrorAction  

2. $cred will contain the Credential information that you pass to the Powershell activity

3. The target of the Powershell activity must be localhost (127.0.0.1) because that's where the Powershell code gets executed (MID Server itself) otherwise you will see those authentication errors. Pass the real target as a parameter ($param1) not target and use step1 to create a remote session

4. Now base your MID server selection on IP 127.0.0.1 in order to execute the activity on the desired MID server and use custom capabilities to differentiate among multiple MID servers that are not in the same cluster.

e.g Create Capability = "Cluster1" , Capability="Cluster2"

5. Assign the capability to the Powershell activity in the Workflow so that Workflow will go through the specific MID cluster

I hope this helps!

Bogdan

[Ian Catley]

This thread is rather old now but just in case anyone stumbles over it - I have a nice little "trick" if you want to run PS on a specific Mid and want to avoid the fact that, if that mid server is part of a load balancing cluster, then Service Now will pick any node in that cluster and not necessarily the specific one you chose. For such cases simply create another load balancing cluster with only that one node as a member. Then in the PS action use "Specific Mid Cluster" instead of "Specific Mid Server" and supply your "dummy" cluster as a parameter.  Just put in the connection details the host as 127.0.0.1 and leave the credential alias empty. It will then run the PS on that specific Mid server node with the credentials of the service account running the Mid server process.