[Job Queue - Enhancement]

@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

[Automation not running.]

@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

[Automation not running.]

@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

[ITOM Output Variables]

@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

[Add X-header to emails sent from Hornbill instance]

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

[ITOM active directory group management error]

@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

[ITOM active directory group management error]

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

[ITOM active directory group management error]

@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

[ITOM active directory group management error]

@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

 

[ITOM active directory group management error]

@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

[ITOM active directory group management error]

@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

[ITOM active directory group management error]

@Adam Toms Adam
 

34 minutes ago, Adam Toms said:

we're surprised the log file has no dates after the 01.05.2020

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

Graham

[ITOM active directory group management error]

@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

 

[Automation Triggers]

@AndyGilly

Andy,

The sisRunJob API is what you need: https://api.hornbill.com/docs/automation/?op=sisRunJob

Graham

 

[Service Build updates]

@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

[Service Build updates]

@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

[ITOM Option gone in instance]

@AndyGilly

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

Graham

[Error message on LDAP discovery]

@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!

[a scheduled job is failing]

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

[Error message on LDAP discovery]

@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

[Error message on LDAP discovery]

@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

[Unable to create runbook]

@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

[Unable to create runbook]

@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

[Allow inventory to be added by AD alone]

@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.

[Install software constant failure]

@Dan Munns This looks like an internal firewall issue. The remote job calls back to the computer running the SIS service on port 11117. Can you check that TCP traffic is allowed from the remote computer (the one on which the software is being installed) to the computer running the SIS service?