Jump to content

Graham

Hornbill Developer
 View Profile  See their activity

  • Posts

    66

  • Joined

  • Last visited

  • Days Won

    1

 Content Type 

Everything posted by Graham

  1. Graham
    @Ben Maddams We have now been able to replicate this problem internally, and are currently working on a fix.
  2. Graham
    @Ben Maddams Do you have the latest version of the AD User package installed? You can check by going into the Installed Packages section within ITOM in Hornbill. Version 25 is the latest.
  3. Graham
    @Ben Maddams That's definitely progress! The job is executing, in that the Powershell script is being processed, and it's the Powershell operation that's failing. I'll take a look at the package.
  4. Graham
    @Ben Maddams In that case, as a final check that the SIS service is listening, can you run netstat -a | find "11117" from a command prompt on the machine running the SIS service? I'd expect to see: TCP 0.0.0.0:11117 <name of server>:0 LISTENING TCP [::]:11117 <name of server>:0 LISTENING which means the service is listening on that port, and I would expect http://10.5.1.153:11117/ to produce the status page from a browser local to that machine (if there is one installed).
  5. Graham
    @Ben Maddams This does look like some sort of communications issue. From a machine that should be able to talk to the SIS server (this doesn't have to be the DC), can you start a web browser and visit http://10.5.1.153:11117/ Do you get a status page?
  6. Graham
    @Ben Maddams Thanks for that. The fact that the job doesn't do what it's supposed to isn't a problem - running the job on the SIS service, rather than on the DC, was the key diagnostic. Regarding the "job successful", there are two things in play here: 1) Was ITOM able to process the package? 2) Did the package's processing produce the desired effect? The "job successful" refers only to the first of these. ITOM was able to connect to the target, start the package processing and received notifications that the processing "happened". That does all point to there either being a communications issue, or something else is interfering with how the remote executable is being processed on the DC. Is there any anti-virus on the DC?
  7. Graham
    @Ben Maddams This is proving to be a bit of a puzzle! Can you try two things for me, please 1) Run the job with a target of the machine running the SIS service itself 2) Run the job targettting the DC, but without setting the "RunAs" credentials Hopefully the results from those will shed some light on what's going on. One other thought - is there any anti-virus software on the DC that could be seeing a new executable running and terminating it?
  8. Graham
    @Ben Maddams Thanks for that. It rules out one thing for me. This still appears to be a comms issue. Can I ask that you run the job again (just so we know where to look in the logs) and then, on the machine running the SIS service, look in C:\ProgramData\Hornbill\Site Integration Server\log\EspSisService.log There should be some entries in there tying up with the new job run, and that will hopefully give us a better idea about what's going on. The first entry will be Processing job: <your job number in here>, type=package
  9. Graham
    @Ben MaddamsFor the log you posted at 16:20 yesterday, is that all there is? I would expect to see some further lines after the the last one "2024-03-25 16:13:52Z Logging prologue ...."
  10. Graham
    @Ben Maddams In that case, this is still a communications issue. With the change to the config file, are you now getting just one valid IP listed when you restart the service? Can you run the same job, but use the SIS service itself as the target? That probably won't work, since the RSAT tools probably aren't installed on the machine running the SIS service, but that won't matter. I'm interested in seeing if the job runs at all and reports back.
  11. Graham
    @Ben Maddams Where is the above log from? What output are you seeing in each of the Monitor, Console Output and Debug Log tabs on the job itself?
  12. Graham
    @Ben Maddams The log has been very useful, thank you. That 0.0.0.0 is going to be the problem. The code is making standard Windows API calls to get the list of addresses for the machine. We can override this in the config file, but would you mind checking a couple of things for me? First, as admin on the machine running the SIS service, run ipconfig /all and post the results Secondly, restart the SIS service and review the EspSisService.log file, located in C:\ProgramData\Hornbill\Site Integration Server\log. There will be a few lines in there - the one I'm interested in starts: Starting HTTP responder on port 11117 and should contain a list of IP addresses at the end.
  13. Graham
    @Ben Maddams The admin server (with the SIS service on it, I assume) and the DC won't necessarily be talking directly to each other, because the overall flow is SIS Service <-> EspSisExec <-> (target specified in ITOM job) <-> domain controller Some of those four could be the same machine, of course. Can you share a screenshot of the job that is failing?
  14. Graham
    @Ben Maddams Hello Ben, It is not necessary to have the SIS service on the DC for any of the Hornbill Library packages. It can run on any server on the network, but ideally one that is joined to the domain you are managing. As for your test jobs failing, the way the SIS service works is that when a job is run, an executable (EspSisExec.exe) is deployed to the machine specified as the target of the job, and it is this executable, rather than the SIS service itself, that does the heavy lifting and processes the package. While it is running, it reports back its progress to the SIS server, which then in turn reports activity to Hornbill, so that you can see the activity in real-time within the ITOM application. This communication between EspSisExec and the SIS service is over HTTP, but using TCP port 11117, from the EspSisExec process to the SIS service. The error you are getting is because the SIS service is not receiving any communication from the EspSisExec process. The most common reason for this is an internal firewall, either somewhere on the network path between the two, or on the system running the SIS service, preventing traffic on that port reaching the SIS service. It's also possible, but much less likely, that there is some sort of firewall doing egress filtering on the system running the EspSisExec process.
  15. Graham
    @Berto2002 Our cloud team have told me that they may be able to speed the deletes up for a period over the coming weekend, when the overall system load is lower.
  16. Graham
    @Berto2002 I'm not aware of anything in the development schedule to extend the functionality beyond the Deleted and Sent Items folders, so in this case, an enhancement request would be the way forward.
  17. Graham
    @Berto2002 For the first query, the delete is processed throughout the day, but it will not remove all the messages in one go. Are you seeing the count drop at all? It should be processing approximately 1,000 every hour. For the second query, we do not automatically delete any emails not in Deleted or Sent Items, regardless of their age.
  18. Graham
    Hi @Sam P Unfortunately, we can't add the Outcome column to the job queue. The reason for this is that the Outcome from a job r is not part of ITOM itself, but just one of the output parameters from the some of the packages in the Hornbill Package Library. The column would have no meaning for discovery jobs or any library or customer package that did not include this output parameter. It's been discussed internally, and the problem is that the Powershell scripts inside the packages are returning a success code even if one of the operations fails, and while this might seem incorrect, there are some valid reasons for this implementation. However, all is not lost. There is a change that is being considered that will allow the job to report a failure from an operation within the package. Nothing confirmed yet, but I'll be able to update you in the New Year. Graham
  19. Graham
    Hi @Sam P To follow up on this, it's now with the development team and an update to the package is expected early next week. Graham
  20. Graham
    Hi @Sam P Thanks for the update. It looks like you're doing all the right things, so in the first instance, I think we'll need to take a look at the operations inside the User Update package and make sure those are working as expected. Graham
  21. Graham
    Hi @Sam P So we can best understand what's going on, would you mind clarifying how you're processing the expiry date/time once it's been generated? Are you calling one of the ITOM packages and passing this value as a parameter? Graham
  22. Graham
    Hi @Sam P Yes, it is fully compatible with Server 2022. Apologies for the documentation oversight - this has now been corrected.
  23. Graham
    @JanS2000 The package is calling the Powershell cmdlet "Get-ADUser", passing in the value of the MemberIdentify parameter as the value of the -Identity parameter to the cmdlet and it's that part which is failing. I understand the redactions, and while I'm not asking you to "unredact" them, can you confirm that the value passed into the job is one of: A distinguished name An object GUID A security identifier A SAM account name
  24. Graham
    @JanS2000 No, the Group Management package is the one you need. That's me leading you astray by asking the wrong question! I should have asked about the Group Management package! Assuming that's on version 14 (the latest), then it would appear that the problem is that the user you're trying to add can't found. There's two possible reasons for that: either the user doesn't exist or the package is querying the wrong directory server. Which domain is the user you're trying to add in and which domain is the SIS server itself in?
  25. Graham
    @JanS2000 Let's check the version of the package first, and make sure that's up to date. Within ITOM, if you go to Package Management -> Installed Packages, what version do you see for Active Directory User Management? Graham
×
×
  • Create New...