Powershell Orchestration Remove User from AD Group

[Ken83]

Hello Community,

        I have a powershell script that is supposed to remove a specified user from a specified group. The problem that I keep running into is that the workflow activity fails with a the message below...

It's telling me that the specified account is not a member of the group but I am certain that it is because I just ran the process to add myself to the group and I can verify in AD that I am in the group. Any suggestions on what the problem could be here? Here is the powershell script that I am using...

Remove-ADGroupMember -Identity ${workflow.scratchpad.or_group} -Members ${workflow.scratchpad.or_user} -Confirm:$false

I am simply passing in the name of the group(the AD equivalent of a group name) and the username of the person I want to remove.

[arturoma]

Hi Ken,

I would suggest you open a Powershell window on the AD server and issue the same command (Remove-ADGroupMember -Identity [actual group name] -Members [actual member] -Confirm:$false) on it and see if it works.

From what you said, it should work. So the only thing left is to verify that the group and the user are correct.

Please try the command on the AD server and see.

[Robert Beeman]

I would look in the ECC Queue for the output of this Orchestration activity. In the payload you should see the actual script being passed to your MID server with the variables fully resolved. Maybe you are sending something different than you expect.

[conmic]

Hello Ken,

Please try this:

Remove-ADGroupMember -Identity "${workflow.scratchpad.or_group}" -Members "${workflow.scratchpad.or_user}" -Confirm:$false

Group and Members needs to be passed as string, especially if there are spaces involved.Therefore you need to put the variables in quotes.

Can I interests you in the PowerShell Utility V2 - execute Powershell scripts directly from your instance?

It might help you to execute and test powershell commands through your ServiceNow instance, without launching a workflow and using its activities.

Kind regards,

Michel

[Ken83 · Accepted solution]

After a lot of investigating and research to understand the PowerShell language, I found the issue. Changing the code in my workflow from looking at my production instance of AD to looking at my test instance of AD apparently isn't the only place I needed to change it. While I modified the code to look at the test instance, the Hostname was still looking at the Production instance of AD which explains the mix up. The code is accurate, just pointing to the wrong place.