One of the strengths of the ServiceNow platform is the ability to automate common Active Directory tasks. While the Microsoft AD Spoke is the easiest way to do this, it is not available in production without the proper licensing. This article will look out how to achieve similar functionality using the base platform and a MID server.
Here’s a great support article from ServiceNow outlining the basic steps.
1 Create Powershell Script
Create a Powershell script and create a record for it in the ecc_agent_script_file table (MID Server > Script Files). In this example, the script will simply return information about a user but you would probably want to perform operations like adding a user to a group.
Note the use of the $args variable to get input parameters. Also note the ConvertTo-JSON for the output. This makes parsing it in ServiceNow much easier.
2. Create Flow Designer Action to Parse Results
Create an Action in Flow Designer to parse the output of the script. This will be used in a subflow in the next step.
The input is the a string variable where we will pass the XML payload
The Script step parses the XML and extracts the output of the script.
(function execute(inputs, outputs) {
var res = gs.xmlToJSON(inputs.payload);
outputs.powershell_output = res.results.result.stdout;
})(inputs, outputs);Below is the Output of the Script Step
Map the output of the Script step to the output of the Action
3. Create a Subflow
Create a Subflow which creates an ecc_queue record, waits for the response and then parses the result.
The subflow input will be the username for which we want to retrieve information
Step 1 is to create the ecc_queue record
The Payload field uses the script below
var value = "powershell .\\scripts\\PowerShell\\GetUser.ps1 " + fd_data.subflow_inputs.username;
return '<?xml version="1.0" encoding="UTF-8"?><parameters><parameter name="name" value="' + value + '"/><parameter name="skip_sensor" value="true"/></parameters>';Step 2 sets the try_count flow variable. This variable is used to determine the number of times the sub flow has tried to find the response in the ecc_queue table. I set the max attempts at 5 (we’ll see this below), but you can raise this as needed. This is a circuit breaker to cut off the subflow from trying forever to find the response.
Steps 3 through 8 are a Do the following action. It keeps looking for a response in the ecc_queue table until either 1) a response is found or 2) the maximum number of retries has been reached (“circuit breaker” mentioned above).
Step 4 sets the try_count variable to try_count + 1.
Step 5 waits for 5 seconds. If your script is resource intensive, you should increase this time.
Step 6 looks for the record. The Response to field is the ecc_queue record created in Step 1. Note that Do not fail on error is checked.
Step 7 sets the payload flow variable to the payload field of the record found in Step 6. This variable is used to determine the end of the Do until loop.
Step 8 is the condition to end the Do until loop. There are two conditions that will stop the loop: 1) The payload variable is not empty (a response was found) or 2) We’ve tried 5 times already.
Step 9 checks if there is a value in the payload flow variable and if so, Step 10 calls the Action we created earlier to parse the payload
Step 11 takes the parsed output from the customer action and maps it to the subflow output. When you call this subflow from a flow or from somewhere else, you could then write the output somewhere or use it to perform further actions.
