- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-18-2018 05:36 AM
Hello all,
We are currently using Orchestration to Disable, Enable, Update, Reset PW's, etc.. All of the OOTB functionality and it's working seamlessly. We need to move Disabled users into our Disabled OU and remove when Enabling.
I've created a new orchestration activity designer "Move-ADObject" using a community post that using this function:
Move-ADObject -Identity $userdn -TargetPath $path
When passing information we keep getting an error:
"errorMessages": "Failed to access target system. Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
We had our AD team jack up the accesses of the account we are using to talk to AD and we are still getting this error.
Does anyone know what is going on or have an alternate way of completing this?
Thank you!
Solved! Go to Solution.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-18-2018 06:37 AM
This likely won't be a ServiceNow issue. I was a Windows Server Weenie for a decade plus and AD permissions have become progressively more granular and complex with each Server version and AD patch. You've left out a lot of details so you're not going to get a definitive answer to your question. The best I can give you is some guidance to get you on the right trail. If you're not the AD guy or an admin experienced in AD you'll need to work closely with whomever that is.
First, some recommendations about your AD configuration. I'm assuming you're not running AD Federated Services or Azure AD. If you are then take my answer and raise the complexity 10-fold. I also assume you're not running the deprecated 'Run PowerShell' activity and are using a custom activity template. I'm not going to cover how to employ the template - that's a deep topic in itself.
- Make sure your domain controllers are running the same version/patch. Yes, there are versions supported for backwards compatibility but you remove a lot of potential conflicts this way
- Make sure the version of PowerShell and the AD module are supported for all domain controllers in your site and are preferably the same versions as well
- On your MID server make sure your property 'mid.powershell.path' is pointed to the version you intend to run the AD module in. Beginning with PS 2.0 you can run multiple versions of PS on the same server and with PS 5.0 you can refer to specific PS module versions as well. As long as you're running Server 2008 R2 you can run PS 4.0 on all servers but you'll need everything at Server 2012 R2 to run PS 5.x (you'll need to install WMF 5.1 on Server 2012 R2). Server 2016 runs PS 5.x by default so you might need to bring everything else up. I don't recall but I don't think you can install WMF 5.x on Server 2008 R2 (but you shouldn't be on 2008 by now anyway)
Once you've got everything configured using the guidelines above (or have accepted the potential issues with differing versions - there might not be after all) log onto your MID server using the credentials that you'll be executing the PS commands under (either the MID server credentials object) and execute the AD command/script you'll be using in your PS custom activity.
Resolve any access rights by tweaking your GPOs or AD permissions until it's working. Then, and only then, begin testing your MID server custom activities. <Scowl>Keep in mind running the custom activities with inputs DOES NOT RUN ANY PREPROCESSING SCRIPTS!</Scowl>
I tend to not run PS commands from my PowerShell activities since you have very little control of result handling. Run scripts and format your return values to ServiceNow appropriately. Also, never assume success. Some PS cmdlets do not have a return object but you can still test success/failure by checking $? following the cmdlet execution.
If this reply is helpful or answers your question please mark it so. I'm trying to catch up to Chuck Tomasi sometime in this life span.

- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎06-18-2018 06:37 AM
This likely won't be a ServiceNow issue. I was a Windows Server Weenie for a decade plus and AD permissions have become progressively more granular and complex with each Server version and AD patch. You've left out a lot of details so you're not going to get a definitive answer to your question. The best I can give you is some guidance to get you on the right trail. If you're not the AD guy or an admin experienced in AD you'll need to work closely with whomever that is.
First, some recommendations about your AD configuration. I'm assuming you're not running AD Federated Services or Azure AD. If you are then take my answer and raise the complexity 10-fold. I also assume you're not running the deprecated 'Run PowerShell' activity and are using a custom activity template. I'm not going to cover how to employ the template - that's a deep topic in itself.
- Make sure your domain controllers are running the same version/patch. Yes, there are versions supported for backwards compatibility but you remove a lot of potential conflicts this way
- Make sure the version of PowerShell and the AD module are supported for all domain controllers in your site and are preferably the same versions as well
- On your MID server make sure your property 'mid.powershell.path' is pointed to the version you intend to run the AD module in. Beginning with PS 2.0 you can run multiple versions of PS on the same server and with PS 5.0 you can refer to specific PS module versions as well. As long as you're running Server 2008 R2 you can run PS 4.0 on all servers but you'll need everything at Server 2012 R2 to run PS 5.x (you'll need to install WMF 5.1 on Server 2012 R2). Server 2016 runs PS 5.x by default so you might need to bring everything else up. I don't recall but I don't think you can install WMF 5.x on Server 2008 R2 (but you shouldn't be on 2008 by now anyway)
Once you've got everything configured using the guidelines above (or have accepted the potential issues with differing versions - there might not be after all) log onto your MID server using the credentials that you'll be executing the PS commands under (either the MID server credentials object) and execute the AD command/script you'll be using in your PS custom activity.
Resolve any access rights by tweaking your GPOs or AD permissions until it's working. Then, and only then, begin testing your MID server custom activities. <Scowl>Keep in mind running the custom activities with inputs DOES NOT RUN ANY PREPROCESSING SCRIPTS!</Scowl>
I tend to not run PS commands from my PowerShell activities since you have very little control of result handling. Run scripts and format your return values to ServiceNow appropriately. Also, never assume success. Some PS cmdlets do not have a return object but you can still test success/failure by checking $? following the cmdlet execution.
If this reply is helpful or answers your question please mark it so. I'm trying to catch up to Chuck Tomasi sometime in this life span.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎04-03-2019 04:29 AM
Hi William Busby,
I followed the below URL to create the Move AD Account Activity
I am able to execute the command from the Mid server to the AD Server using the credential used in SNOW it works as expected
PS C:\Users\Exx-srv-snowacc> Move-ADObject -Identity "CN=Z4082405,OU=Users,OU=HQP,DC=<DC>,DC=COM" -TargetPath "OU=Disabled Users,DC=<DC>,DC=COM"
However when I run the same thing with test inputs from SNOW I get the below error. Any clues on why this might be.
errorMessages": "Failed to access target system. Please check credentials and firewall settings on the target system to ensure accessibility: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))\n\nStack Trace: at System.Management.ThreadDispatch.Start()\nat System.Management.ManagementScope.Initialize()\nat System.Management.ManagementObjectSearcher.Initialize()\nat System.Management.ManagementObjectSearcher.Get()\nat Microsoft.PowerShell.Commands.GetWmiObjectCommand.BeginProcessing()\nat System.Management.Automation.Cmdlet.DoBeginProcessing()\nat System.Management.Automation.CommandProcessorBase