Ricky

Hi @AndyGilly, It looks there were issue identified during the testing of the fix, and Dev. are currently looking at the issue. I will give then a nudge and get back to you once they have responded. Regards, Ricky

Hi @AndyGilly, thank you for the request, it has been forwarded to development for further discussion and I will inform you off the outcome once they have responded. Regards, Ricky

Hi @AndyGilly, I have not been able to replicate the issue in-house as yet and will have another look at it today and discuss with the development team to see how to best progress this issue. If we are unable to make any further progress, I will raise a support request and organise a remote session to get this sorted asap. Regards, Ricky

@AndyGilly, Have spoken with the dev team and they are hoping to get an SIS release out next week, which will contain the fixes required to resolve the issue. I will post an update as soon as I can to confirm that the update has been pushed for release. Regards, Ricky

Hi @AndyGilly, I am still waiting for confirmation of a date when the fix will become available, but will give the dev team a poke to get some progress with this. Regards, Ricky

Hi @AndyGilly, have not come across that as yet, but will take a look at it and get back to you. Regards Ricky

@AndyGillyI am still waiting for confirmation of the next version of the SIS release date that will contain the fix for the issue you are experiencing. I believe that there were discussions on this late last week, and I am still waiting for further details. Apologies for the delay, and as soon as I get some information, I will let you know. Regards, Ricky

Hi @AndyHillthe development team is currently looking into providing a feature to resume a suspended process. We will post an update as soon as we have further details. Regards, Ricky

Hi @AndyGilly, Apologies for the delay in responding. I am still waiting for an update on this issue. I know that we have been able to identify the root cause of the problem and that the fix will be within the SIS. A release is due soon; however, I am still waiting for confirmation of the timeframe as I believe dependencies are holding back the release. I hope to get more information and hopefully an ETA later this week, and I will update you accordingly. Regards, Ricky

@Mark HarveyThank you for your post, this type of action would be better suited using the Hornbill APIs to create the requests. The API calls can be scheduled in bulk using our Hornbill API Scheduler tool. The following link will provide further details of how the tool is used and where to get access to it: https://wiki.hornbill.com/index.php?title=API_Scheduler Regards, Ricky

@AndyGillyI can see that the Manage Executed Processes feature does not allow resuming a process after failure. I have asked the Dev team to look into the issue and if it is possible to implement the feature. The interface used for both BPM and Runbooks; however, Resuming a process is not supported for Runbooks. I will get back to you as soon as I get a reply. Ricky

Hi @AndyGilly, there a feature to view all Runbook process and is accessible via the following button: Ricky

Hi @AndyGilly, I will chat with the dev team and get an update on any progress. Ricky

@AndyGillyThanks for the update, the only thing i can see that may cause this the process not to set it, may be to do with IT Automation node setting the Policy not waiting for a response before the next node is executed. The execution policy can only be modified by ITOM via an IT Automation, so would not have been modified unless specifically called, and therefore may have been changed by some other mechanism such as a Group Policy setting. Ricky

@AndyGilly Ignore the above comment as it is mis-leading, i should of written it as follows: There looks to be no issue with the execution, the only issue maybe where you are entering the Get-ExecutionPolicy to check the change. The package is built to use the native version of PowerShell and thus the change should be seen in the native console. This can be identified in the logs by the entry: 2021-04-07 13:50:50Z Target platform: win3264 2021-04-07 13:50:50Z Using the native variant of PowerShell 2021-04-07 13:50:50Z Using executable C:\Windows\system32/WindowsPowerShell\v1.0\PowerShell.exe I have notice that when we apply the setting and open the native console that the change is not registered, however the change is registered in the PowerShell (x86) console. When you set the Policy, which version of PowerShell console are you setting it in PowerShell or PowerShell (x86)? Ricky

@AndyGilly There looks to be no issue with the execution, the only issue maybe where you are entering the Get-ExecutionPolicy to check the change. The package is built to use the 32 bit (x86) version of PowerShell and thus the change would not be seen in the 64bit console. This can be identified in the logs by the entry "2021-04-07 13:50:50Z Target platform: win3264". I am unable to get it to fail at my end and the output you have provided in the logs looks as if all was working as expected. When you set the Policy which version of PowerShell console are you setting it in PowerShell or Powershell (x86)? Ricky

@AndyGilly We have updated the ECM package to provide enhanced error messaging (https://community.hornbill.com/topic/20615-new-update-hornbill-itom-content-pack-32/) this should help with any issues going forward. With regards to the Execution policy can you supply the the full debug log and Monitor for the Set-Execution Policy operation? Would also be useful to get the output of following command on the target device Thanks Ricky

@AndyGilly Thanks for the update, I will take a look and see what I can come up with, and get back to you. Thanks Ricky

@AndyGillyCan you also confirm that you are able to manually change to the the drive on the target device using: Set-Location <dirve-name>: This will confirm the package is being executed on the correct device, and I will also get back to the dev team who are currently investigating the error message with your update. Thanks Ricky

@AndyGillyCan you check if the SiteId is correct as it is case sensitive? Regards Ricky

A workaround is available, which can be implemented by turning off the parser within Hornbill Administration Settings:

Hi @AndyGilly, we have now released a Direct email feature that can be utilised within a Hornbill Business Process including ITOM Runbooks: Release Announcement: This feature is accessible via the Hornbill Automation node: Regards, Ricky

@AndyGillyDue to nature of this issue, I think the best approach will be to get an Incident raised and organise a remote session, with possibly a member of the dev team included so that we can get this resolved asap. Ricky

@AndyGillyIn your PowerShell script you have a line that outputs your the content of the variable $output: Write-Output "Mover Output: $output" can you comment that line out and try running it again. Ricky

Hi @AndyGilly have raised it with development and it has been added to the list. Unfortunately I was not able to find another method apart from storing the required data within a custom field on a request and using the Service Manager email via the Hornbill Automation node. Ricky