I would like to thank my friend and ex-colleague Cesar Freschi for his contribution to this article. Below, we will be exploring the techniques that can be utilized to troubleshoot an Orchestration Activity / Workflow
Let me start by stating that typically a customer will be possession of a technical document. If you are fortunate enough to work for an organization that keeps records detailing user accounts required to execute an orchestration activity, bless you, you may never need to use the techniques detailed here. However, if you live in a reality where this document does not exist or, has not been kept up to date, well, you may wish to dive in! Needless to say, we advise that you perform all testing on a sub-production instance.
Login issues:
- Ensure that the system property, mid.server.rba_powershell_v2, is set to true.
- Check the [ecc_agent_issue] table, or the MID Server issues related list when the instance encounters user connectivity issues.
- Check Service Now System Logs. This is always a good starting point for troubleshooting. Still further details can be obtained from the MID server host machine from the MID_SERVER/agent/logs directory from the wrapper.log and .lck file
- A single Service Now account can be employed to authenticate against multiple MID Servers. However, each MID Server account must be granted the mid_server role to access protected tables
- Test your credentials: Ensure that the account that you are utilizing for your orchestration is correctly configured. This can be achieved by utilizing the UI actions in the Orchestration Credential module.
- Depending on how frequent you cloning cycle is between your production and sub-production it may be beneficial to have your orchestration account, and your account that is configured with the mid_server role, be one and the same account.
- Be sure to remove the mid_server role from the account authenticating the MID server on sub-production systems after testing is has been concluded
- Check authentication further in the system config.xml file. Here we will find the properties mid.instance.username and mid.instance.password defined. Ensure the values configured here match those of the account containing the mid_server role.
- Ensure the MID Server has been configured to accept Powershell commands. The mid.property.powershell.command.script.parameter_passing and the mid.property.powershell.log_info property should set to the value true on the [ecc_agent_property] table
- Ensure the target machine you plan to run your Powershell script on is not the same machine as your MID Server host machine
- Ensure the target machine is configured with the services you require to run your script. Use the Get-Command cmdlet to show us all of the cmdlets that use the Get verb available on the target machine
Validation issues:
- If the MID Server is up but still displaying as invalid, I usually attempt to restart MID Server first port of call. If you find that your MID server still persist to remaining invalid, utilize the Rekey UI Action.
- If your MID server continues to fails to validate after the Rekey UI Action has been engaged, try logging in to your MID Server host machine, navigate to the MID_SERVER/agent/keystore directory, Make a copy of this directory
- With the MID_SERVER/agent/keystore backed up, you can remove the this directory
- Back in Service Now execute the Restart UI action for the MID Server, you will find this will generate a new directory on your MID_SERVER/agent/keystore directory MID Server host
Keep your environment clean:
- If you find your orchestration is failing, and the log messages are not drawing closer to resolving the root cause of the issue, check your MID Server configuration follow Service Now best practice naming conventions.
- I have experienced MID Servers behaviour that is totally unexpected and unpredictable. The root cause of this issue was that there were multiple MID servers in our environment and somehow more than one MID Server shared an installation path. You can check the installation path your MID Servers by observing its Windows Service
- It may be prudent to remove unrequired MID servers, particularly in a sub-production environment where multiple developers are testing orchestration activities. You can find the service name of you MID Servers from the Windows services.msc application or from the MID_SERVER/agent/conf directory where wrapper-override.conf holds the value in the wrapper.name property
- The wrapper.name property value should be used in a DOS command window. Type “SC DELETE servicename“, where the servicename == wrapper.name, then press “Enter“
For further troubleshooting techniques please see the following:
https://community.servicenow.com/community?id=community_blog&sys_id=705e2aaddbd0dbc01dcaf3231f961982
Hail Cesar!!!
