Jump to content

ITOM active directory group management error


AndyGilly
 Share

Recommended Posts

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

  • Thanks 1
Link to comment
Share on other sites

@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

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

 

MicrosoftTeams-image (17).png

Link to comment
Share on other sites

@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

  • Thanks 1
Link to comment
Share on other sites

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

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

@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

  • Like 1
Link to comment
Share on other sites

  • 3 weeks later...

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...