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

@AndyGilly, I will certainly pass the request onto the Dev team and will also get back to you when I get some feedback regarding any other possible methods that may be available, that I am not aware of.. Ricky

Hi @AndyGilly You are correct in that ITOM variables cannot be used to directly populate a email template, as the template data is sourced from a call record. In order to use a ITOM variable you would be required to store the ITOM variables value within a custom field on the requests record. The email template would then be able to extract the data on generation of the email. As you are intending to deliver password information within the email, it should be noted that the outgoing email would also be accessible via an email copy in the mailbox sent items folder. I am not sure if there is any other mechanism that be used for mail delivery within the Hornbill platform that can be used within the BPM or a Runbook. There is a Cloud Automation that enables emails to be sent via Office 365 that may be feasible. I will also see if I can get some further information from the team with regards to any other options available, as this not an area that I specialise in. Regards, Ricky

@AndyGillyThanks for the confirmation. I have tested this in-house and am unable to replicate the issue, and have now passed this to the dev team for investigation to identify the cause and implement a fix if required, and I will keep you updated with any progress. Ricky

@AndyGilly, Looks all correct, so no issues with the output, however can you confirm that the variable MoverADGroups the same as that configured for the operation (Note that the parameter names are case sensitive). Ricky

Hi @AndyGilly, Looks like your output is in the correct format, however I am unable to verify that as I cannot view the entire string. Could you post the entire string so that I can ensure that format is correct, and run a test in-house. Thanks, Ricky

@AndyGillyCan you confirm that the string you are attempting to store in a variable has the following format? {{SISJobOutputParamenterStart:MoverADGroups}} ... <some text> ... {{SISJobOutputParamenterEnd}} Ricky

Hi @AndyGilly, it looks like you are attempting to store the output of an array into a string, Hornbill variable types currently do not support the use of arrays. In order to store the content of an array into a variable you would need to store each element into a separate variable or concatenate each element into a single string. Regards, Ricky

@AndyGillyThanks for the update. Have spoken with the Dev team and they suggest that the issue must be the result of some form of communication error. I am currently in the process of organising access to the logs from yesterday, in order to investigate this further. I may also require access to the logs located on the SIS sever on you're network, and may require them to sent over. Due to the nature of the investigation I will be requesting that an Incident be raised on your behalf to track future progress, and will advise you of the incident reference. Could you also confirm roughly when you first started to experience the reported behaviour? Regards, Ricky

Hi @AndyGilly, looks like the SIS authorization key is being reported as invalid for some reason, our dev team are looking into the issue and I will get back to you as soon as I get a response. Do you have more than one SIS and what is the pairing status of them in the Admin tool? Regards, Ricky

@AndyGilly, Can you review the SIS log (EspSisService.log), and check that the following lines exist for any of the stalled jobs: 2021-03-10 16:52:00Z [INFO]:[GENERAL]:[1164] Result: Success 2021-03-10 16:52:00Z [INFO]:[GENERAL]:[1164] Setting job 317 status to processingOutput 2021-03-10 16:52:00Z [INFO]:[GENERAL]:[1164] Setting job 317 status to succeeded Regards, Ricky

Hi@AndyGilly, I believe that this is an issue we are currently aware of and is in the development queue for further investigation. I will enquire into any progress they we have made and request that it is given a higher priority. Can you confirm that the issue is consistently exhibits that same behaviour? In that initially it stalls and subsequent executions are successful. Also does refreshing the GUI in the Job queue have any effect? Regards, Ricky

Hi @AndyGilly, You will need to first get the output into a variable, this can be achieved by creating a package operation output parameter in the package creator, and then outputting the value using the following: Write-Output "{{SISJobOutputParameterStart:outputParamaterName}}$($YourVariable){{SISJobOutputParameterEnd}}" further details of this can be found here: https://wiki.hornbill.com/index.php?title=Package_Creator#Output_Parameters Regrads, Ricky

Hi @AndyGilly, Looks like the operation cannot find the path used to import the Configuration Manager PS module. Can you confirm that the Target Device has the module and that the environment variable "SMS_ADMIN_UI_PATH" is set. Regards, Ricky

@AndyGillyI have passed the request through to the Dev team who will add this to the list and will provide an update when I get some further details. Regards, Ricky

@AndyGillyIgnore my last post this has nothing to do with PS 7. From the the last log it looks like the process has executed successfully using Windows PowerShell. Can you clarify what you mean or are interpreting as a parameter error? I can only assume you are getting something like this in the Job Monitor pane: If so the issue is relating to one or more output parameters specified on the Package Operation is set to mandatory and the script is not outputting the parameter or the output is not using the correct format : {{SISJobOutputParameterStart:<param-name>}}<value>{{SISJobOutputParameterEnd}}

@AndyGillyThis is most likely related to the use of PowerShell 7 which is not fully tested with ITOM, am having a look now and will get back to you. I would advise that you roll back to the previous version of PowerShell as our library packages will not have been built for anything above version 5. Regards, Ricky

@AndyGillyThe Command Type shown in the Log show as ps1c, used for PowerShell Core, this should be ps1 for all other PowerShell versions

@AndyGilly The logs show that package operation is still set to use PowerShell Core. Can you check that after you saved the change that you Baseline the package and the Package and Install. Ricky

Hi @james.uppington, in order to see the Wait For Response parameter the package must be configured with one or more output parameters, this behaviour will be the same for both BPM and Runbooks. Regards, Ricky

Hi @AndyGilly, currently investigating the issue, in the meantime could you send me the Debug Log output for the failed job, as I am unable to replicate the fault. Regards, Ricky

@AndyGillyIs it possible that you have set the operation Command Type incorrectly to Powershell Core and not Windows PowerShell? Regards, Ricky

Hi @AndyGilly, Apologies for the delay I am currently investigating, I haven't seen any documentation relating to version requirements, but will investigate further. Can you try adding Set-StrictMode -Version latest to your script? Regards, Ricky

Hi @james.uppington looks like the node you are looking at is from within the Hornbill Business Process Manger which looks to be slightly different, I am currently investigating why this and will get back to you shortly. As a workaround if these features are required you can place the IT automation node in a Runbook Process and reference it from within the BPM. Regards, Ricky

@AndyGilly When executing a job from the Job Queue I have also noted that occasionally the job gets stuck with the "Processing Output" status, and can be resolved by a browser refresh. It would be useful to see if this resolves the issue that you are experiencing.