Microsoft AD Spoke – Common Issues & their workaroundsIssue Issues Solution/Workaround Additional Comments If the response is huge for any AD step then will run into the error(com.snc.process_flow.exception.ProcessAutomationException: unable to deserialize process plan from JSON). The fix for this is in progress for Paris. Plan failure due to multiple plan execution. Break the flow into multiple sub-flows and call them using scriptable API. Permission related issues https://support.servicenow.com/kb_view.do?sysparm_article=KB0829224 Action type definition df96f9b293f70300eb08925cf67ffb67 is missing. Publish the action "Is User Account Locked" with sys_id "b08639b293f70300eb08925cf67ffb1b" and change it with "df96f9b293f70300eb08925cf67ffb67". Content not allowing in Prolog Typically mid-server issue, upgrading the mid-server might fix the issue. Unable to publish action. 1. Remove the snapshots and publish the action2. Copy the action and publish. The specified module 'activedirectory' was not loaded because no valid module file was found in any module directory." 1. Cross check DC if it as AD role and module is installed, if yes then AD roles is to be enabled in MID-Server.2. ADWS also needs to be installed on DC. Multiple Accounts are present in their env. Fixed in Paris The following workaround is not thread safe.The following is a way to do for multiple connections.AD spoke to work with multiple Connections:1) Only single alias - AD is shipped2) Create 2 connections in the alias , with each having own credential.3) Set active=false in the 2 connections (Set_all_connections_false.jpg)4) Create flows where each connection is active only when the steps related to that connection are executing. PFA the Flow design (Flow_With_Multiple_connections.jpg) To stop the hung flow. Use background script to change the state. Unable to find Adutils script. Pre-Processing scripts should run on Instance and not on MID. Update the script step. Flow Designer is getting the following error: "Failed to get plan from instance for context" The issue was resolved by changing the wrapper-override.conf file on the MID Server adding the following line:wrapper.java.additional.xx+1=-Dfile.encoding=UTF-8Where xx is the last active java.additional configuration.This instructs the MID Server to use the UTF-8 encoding which resolves the issue encountered.Please note the MID Server needs to be restarted after the wrapper-override.conf change. The Flow context is retrieved from the MID Server and serialised as a JSON payload that represents the Flow.When the MID Server tries to deserialise it in order to execute it the deserialisation fails.This could be failing because of a wrongly encoded special character that appears in the Flow Invalid UTF-8 start byteThe MID Server Agent log should be tracking the issue with the following error message:Caused by: com.fasterxml.jackson.core.JsonParseException: Invalid UTF-8 start byte <UTF-8-Code> at [Source: (ByteArrayInputStream); line: 1, column: 9517] 1500 Users unable to retrieve more than that. Fix is already provided. Authentication Issues. 1. Hostname must have the IP or the hostname of the AD rather than the MID server IP.2. Ensure proper credentials are provided with sufficient access rights.3. Check if firewall is off or ports are open.https://support.servicenow.com/kb_view.do?sysparm_article=KB0549828 Unable to retrive the data from mid. Mid server not validated. Or No Valid MID is available. Validate the MID server New York only : Oauth 2.0 cred created and AD cred created too and try to validate. It will fail due to decryption credentials. Fixed in Orlando (PRB1342894). Other workaround : Deactivate the Oauth credentials. Lookup user is having issue in verifying the use, If the result has "Error" keyword. Removing the condition where it checks for the error keyword from the post-processing script will fix the issue. Upgrade taking time Azure and AD spoke take lot of time during upgrade because the actions and flows table extend from sys metadata. Access denied even with Admin rights. Upgrade it NY patch 3 However, please note that the dev team confirmed this workaround only works for some customers but not all. If this workaround does not work for you, then you would have to either create a copy of each action and add "credType = AD" in each action or upgrade to Madrid Patch 9 or New York Patch 3.1) Go to Administrative tools2) Open Component Services3) Expand Computers4) Right click on My Computer and click on Properties5) Go to Default Properties Tab6) Select option "Enable Distributed COM on this computer"7) Click on Apply and OK8) Select Yes on the DCOM Machine wide settings modal window9) Come to Service-now instance.10) Execute the Flow in the flow designer Flow action being run multiple times when Ask for approval is used in a flow and followed by a Action executed in mid. Add sleep in between two actions. Technical details:After the approval is granted by the user, we restart the execution of the flow. Since ActionAddUserToADGroup is executed in mid, it takes a few seconds to complete and respond back to the flow. If the response is not received in a certain time, the flow will place another message in the ECC queue to perform the same action step (in this case its a Powershell step which adds a user to the AD group).We also have a PRB for this issue - PRB1357413 - https://support.servicenow.com/problem.do?sys_id=eb00b539db1fbb442be0a851ca9619a8 Access denied issue for inline scripts which customer was trying to execute which had command to set-executionpolicy. 1. GPO was set in the customer's environment which was not allowing to update execution policy setting.