Graham

@AndyHill For your first point, would you mind expanding on the nature of the problem you're having with the Resume operation? Once we understand the issue we can apply a fix and release an updated version.

@AndyGilly Unfortunately, this isn't something that the job queue can support. The issue is that the Outcome is an output parameter from the library PowerShell scripts you are running, not something inherent to every job, and so for jobs that don't produce that parameter, the column will be blank. By design, the processing only parses the overall output of the job, populating the values for the configured output parameters, if the job itself succeeds. The thinking here is that if the job itself fails, then the output won't contain any valid information anyway. The reason it works this way is that if the job itself succeeds, in that the PowerShell script was able to run, regardless of whether it achieved the intended results or not, the Outcome parameter, which does contain this information, can then be tested in workflows. Graham

@AndyHill Apologies for this - it appears that a setting was not correct at our end. It's been updated, and I would expect that jobs will now be able to run again. Graham

@AndyHill Andy, Where are you seeing the message about the automation limit? What's the status of the automation jobs in the ITOM job queue? Graham

@AndyGilly This is proving to be a bit of a head-scratcher! Would you mind posting the complete output from the Console Output tab, rather than the Monitor tab, from the job? Graham

Scott It would be useful if you could expand on the nature of the problems that you're experiencing with the antispoof protection, and if I could get a clearer idea what you mean by "use an smtp smart host to filter and capture all emails". I'm assuming that the smart host is storing Hornbill emails in a mailbox as well as forwarding them on to their final destination, but you know what they say about assumption... Graham

@Adam TomsAdam Wanted to follow up on this - are you back up and running now, or do we need to do some more diagnostics? Graham

@Adam TomsAll done and ready for you. It's a 10.3MB zip.

@Adam Toms It's building even as I type... Will I be able to e-mail it to you, or will your front-end scanners strip off any executable attachments? Graham

@Adam Toms I'm certain that these are two separate issues, so a file rename and a service restart would be a very useful diagnostic. We're currently preparing a patch for your SIS service executable. Graham

@Adam Toms That's the right place... Very strange. The service writes to that log on startup, even if it can't talk to Hornbill at all, so there's something very odd going on there. However, let's get it processing jobs first. It looks like it's a problem our end, and not something that can easily be corrected by changing a setting on your end, and we're working on a resolution now. Graham

@Adam TomsAdam I might have managed to replicate the issue here, but even so, you should still be getting log entries, if it's the problem I think it is, so we might have two problems. What directory are you looking in for the log files? Graham

@Adam Toms Adam You and me both! Are you still not getting anything in the log file, even after a reboot? Graham

@AndyGilly This may be due a configuration change in the Hornbill cloud. Can you look at the last few lines of the file C:\ProgramData\Hornbill\Site Integration Server\log\EspSisService.log? Do you have any lines that start, after the timestamp: [ERROR]:[COMMS] and if so, what does the rest of that line say? Graham

@AndyGilly Andy, The sisRunJob API is what you need: https://api.hornbill.com/docs/automation/?op=sisRunJob Graham

@AndyGilly I think I see what's happened here. We've made some architectural changes to the update processing, and currently your out of date SIS service is now unable to communicate with the Hornbill back-end successfully in order to update itself. The best way to resolve this is to download the latest SIS service (the download button is on the same page as your screenshot), and install that. If you manually stop the EspSisService, and then delete the contents of C:\Program Files\Hornbill\Site Integration Server, that will allow a fresh install to proceed. Once that's done, if you then re-pair, everything should be up to date and working. I realise this is all a bit of a hassle, and I'd like to apologise for the trouble we're causing you, but it's a one-off thing. Once the new SIS service is up and running, it will then auto-update correctly in the future. Graham

@AndyGillyThe ITOM service should be auto-updating. Can you post a screenshot of where you're seeing the outdated build number? Build 3345 is the latest live release. Graham

@AndyGilly Something's clearly gone wrong there! We'll take a look at that for you this morning. Graham

@AndyHill Andrew, I've just run a quick test here to be sure and yes, that has now been fixed.If it still doesn't work, then there's something else weird going on!

Guiseppe Thanks for bring this to our attention. We've now managed to replicate this issue in our development environment, and are looking at a solution now. I would expect a fix to be included in the next scheduled release. Best regards Graham

@AndyHill Andy, We've now identified the problem, and the fix is undergoing internal testing. I would expect this to be included in the next release. Graham

@AndyHill Andy, Thanks for bringing this to our attention. It's not an issue we're aware of, but we are investigating it now, and I'll post back when we have some more information for you. Graham

@Dan Munns We think we've found the underlying cause of the problem, and we're currently determining the best way to resolve it. Unfortunately, the error message itself is misleading, in that the problem is not actually related to the uniqueness or otherwise of the name. As yet, we don't have a firm date for when a fix would be available, but I'll update you when we do. Graham

@Dan Munns Dan, we'll take a look at this. I've had a quick try in one of our test instances, and I'm able to create one. I'll let you know what we find. Graham

@Dan Munns Currently, as part of discovery, we are doing more than just checking that the computer is on the network. We are also querying it via WMI to ascertain some detailed information about it (hardware, operating system configuration and installed software). If we can't connect to the computer, we can't determine this information, so we don't add it to the inventory. However, I can see the benefit of having a computer in the inventory, even if the detailed information is incomplete, so that it can be the target of automation jobs at a later date and we can then update the inventory as and when the computer is available.