AndyGilly Posted November 19, 2020 Share Posted November 19, 2020 Hi we have a active directory group management job in error. It that worked fine previously then has started to get stuck in a 'waiting' state the debug log, monitor & and console views are empty in the job any ideas of what could be causing the issue? thanks Andy @Adam Toms Link to comment Share on other sites More sharing options...
Ricky Posted November 19, 2020 Share Posted November 19, 2020 Hi Andy, This usually occurs when the Job has not reached the SIS, can you check that the SIS is online and able to connect to the cloud. You should be able to check this via the SIS Status web page on the SIS server http://127.0.0.1:11117 Ricky 1 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 19, 2020 Share Posted November 19, 2020 Hi @Ricky, thanks both myself and Andy work in the same team. I'll take a look at this. Many Thanks for your quick response. Adam 1 Link to comment Share on other sites More sharing options...
Graham Posted November 19, 2020 Share Posted November 19, 2020 @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 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 20, 2020 Share Posted November 20, 2020 Hi @Graham and @Ricky Thanks for your posts. Based on the information we have carried out the following: The ESPSisServices.log file has not updated since the 1st May 2020, but we have had a successful automation task since then. The [ERROR ]: [COMMS]: [7148] The BPM Site Integration instance cannot be resumed (Process::Execute: cannot find execution path location) we're surprised the log file has no dates after the 01.05.2020, as the server has been up and available since then. We have been able to successfully browse to http://127.0.0.1:11117 which does take us to SIS page, which is attached to this post. To prevent any problems with the any stuck tasks, we've aborted all tasks that have been unsuccessful. We also weren't happy with the performance of the server, so as a precaution we have rebooted the server, and once back cycled the service, and checked it was running again. The server seems to perform fine after the reboot. We've then tried to start the active directory group management job again, and the ITOM admin portal shows the task as waiting, but again the task is stuck in a 'waiting' state the debug log, monitor & and console views are still empty in the job. We are confident that communication is occurring as the Jobs Queued did change to 1 when we started the active directory group management job again after the reboot, and aborting the job did bring the jobs queued back to zero, but we're still unable to understand why the job is not running successfully. Many thanks in advance and hope this additional detail helps. @AndyGilly for awareness. Many Thanks Adam Link to comment Share on other sites More sharing options...
Graham Posted November 20, 2020 Share Posted November 20, 2020 @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 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 20, 2020 Share Posted November 20, 2020 Hi @Graham I've just logged onto the server and double checked, and can confirm the last entry in that log 01-05-2020 13:07:47. Same as before, even after the reboot. Many Thanks Adam Link to comment Share on other sites More sharing options...
Graham Posted November 20, 2020 Share Posted November 20, 2020 @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 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 20, 2020 Share Posted November 20, 2020 Hi @Graham, Thanks again for you speedy reply. As mention in your previous post the directory on the server where I am looking at the logs is as follows: C:\ProgramData\Hornbill\Site Integration Server\log\EspSisService.log Many Thanks Adam Link to comment Share on other sites More sharing options...
Graham Posted November 20, 2020 Share Posted November 20, 2020 @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 1 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 20, 2020 Share Posted November 20, 2020 Thanks @Graham Much appreciated for looking into this so quickly for us. Hopefully once it can start processing jobs again, the logs might start writing to that file again. But I'd of thought when we cycled the service on the server something would of at least appeared then. I've been having a think and wondered if there would there be any benefit for us to rename the log file and put old in the title, and see if when cycling the service a new EspSisService.log file is created? I won't do anything with until I hear back, and perhaps we'd be better off waiting until the job processing resume before attempting. Thanks again Adam Link to comment Share on other sites More sharing options...
Graham Posted November 20, 2020 Share Posted November 20, 2020 @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 1 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 20, 2020 Share Posted November 20, 2020 Thanks @Graham I've now renamed the log file and cycled the Service. Upon the successful start of the Service I can see a new EspSisService.log file has been created, and has today's date it in, the last log in the new file is at 11:51: [Error]: [GENERAL]: [8052] XMLMCQueue - Failed to store pending queue into disk, this message is then repeated several times. I will await the patch before trying anything else, but at least new logs now appear to be being created again. Many Thanks Adam Link to comment Share on other sites More sharing options...
Adam Toms Posted November 23, 2020 Share Posted November 23, 2020 Good Morning @Graham, I hope you had a good weekend? Just wondered if you had an ETA on the patch for the SIS service executable? Thanks again for all the help so far. Many Thanks Adam Link to comment Share on other sites More sharing options...
Graham Posted November 23, 2020 Share Posted November 23, 2020 @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 Link to comment Share on other sites More sharing options...
Graham Posted November 23, 2020 Share Posted November 23, 2020 @Adam TomsAll done and ready for you. It's a 10.3MB zip. Link to comment Share on other sites More sharing options...
Adam Toms Posted November 23, 2020 Share Posted November 23, 2020 Thanks @Graham Yes you are correct our mail scanners will block a .exe file from an external address. Leave this with me, and I'll look into finding the best option for file sharing an .exe with us. Thanks again. Adam Link to comment Share on other sites More sharing options...
Graham Posted November 25, 2020 Share Posted November 25, 2020 @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 Link to comment Share on other sites More sharing options...
Adam Toms Posted November 25, 2020 Share Posted November 25, 2020 @Graham Graham, My sincere apologies for the delay. I can confirm the service is now successfully communicating with our AD, and we've tested a user, and it works. We're hoping to do some more testing over the next week or so with a couple of customers. Assuming that also proves successful we'll be able to formally offer this as out first piece of automated software deployment. Which we're really excited with. A big thanks to you and @Ricky for helping us with this. Many Thanks Adam 1 Link to comment Share on other sites More sharing options...
Adam Toms Posted December 16, 2020 Share Posted December 16, 2020 Hi all, Just a quick note to say thanks to @Graham @Ricky we went live last night with our first piece of automated software deployment. We couldn't of got there without your help. Here's to start of many more! 4 Link to comment Share on other sites More sharing options...
Ricky Posted December 17, 2020 Share Posted December 17, 2020 Hi @Adam Toms, Great news on your first successful automation, glad that we were able to provide you with some assistance and will be more than happy to provide any further assistance as required. Ricky 1 Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now