Jump to content

Graham

Hornbill Developer
  • Posts

    74
  • Joined

  • Last visited

  • Days Won

    1

Graham last won the day on June 14 2023

Graham had the most liked content!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Graham's Achievements

Enthusiast

Enthusiast (6/14)

  • Reacting Well
  • Dedicated Rare
  • First Post
  • Collaborator
  • Week One Done

Recent Badges

10

Reputation

  1. @Ben Maddams Hi Ben, Just a quick follow-up on this. Are your jobs now running OK?
  2. @Ben Maddams If you still have them, it would be useful to see what the results were from previous discovery jobs. You can filter the job queue by type and so limit it to just discoveries.
  3. @Ben Maddams That's helpful, thanks. 'Auto' will also try to connect via SSH, but as most Windows servers don't have SSH enabled, that failure can be ignored. The WinRM connection issue is the one we see when running the job, so that too is expected in this case. However, the 'Access denied' for DCOM is interesting. I think the next step is to check the credentials used for the discovery. Have they been changed in Keysafe, or have users/passwords been changed on the target?
  4. @Ben Maddams You won't need to unmanage the device to run the discovery. There's something strange going on with the connection to the target, and I'm hoping that the discovery results will shed some light on what is happening.
  5. @Ben Maddams Can you re-run the discovery of the target, with the Protocol set to Auto? Let's see what that does. It does look like something odd is going on with WinRM, but I'm unable to replicate it here. A discovery protocol of Auto will try using both DCOM and WinRM, so hopefully DCOM will work.
  6. @Ben Maddams That indicates that WinRM is working OK on the target. Do you get problems running jobs against other targets? There's been no SIS software releases recently, so the most likely explanation is that something has changed on your side - we just have to find out what! Can you also run winrm id on the SIS server please, just to check?
  7. @Ben Maddams In that case, what does winrm id say? Again, this is run on the target computer from an elevated prompt.
  8. @Ben Maddams Hi Ben The error code 0x80338005 is coming back from the operating system, specifically the WinRM system. As a first diagnostic, on the machine you are trying to connect to (i.e. the target of the job, not the SIS server itself), can you run, from an elevated command prompt: winrm qc and post what the result is? The ping and DNS checks you mention only apply at the time of device discovery - they are not a "live" check in that sense.
  9. @Ben Maddams We have now been able to replicate this problem internally, and are currently working on a fix.
  10. @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.
  11. @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.
  12. @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).
  13. @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?
  14. @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?
  15. @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?
×
×
  • Create New...