Jump to content

Deen

Hornbill Staff
  • Posts

    782
  • Joined

  • Last visited

  • Days Won

    30

Everything posted by Deen

  1. The recovery process is now complete and all instances have been fully restored. We will be in touch shortly with an RCA and apologise for the disruption.
  2. For any instances still affected by missing files, the recovery process is still ongoing and we expect this to be complete in the next 30 minutes or so. I will confirm here when this has been completed.
  3. After additional tests this appears to be an issue with Office365 where intermittently it is unable to complete a valid connection. Any emails stuck in your Outbox will have 9 retry attempts, if any of these are successful they will leave the mailbox as expected - you will see from your Sent Items folder that emails are sending, it is a few specific ones that fail. You can also manually resend affected mails using the envelope icon if they are time sensitive. We have had reports from a number of other Customers with the same issue, so there does seem to be a problem with Office365 mail at the moment.
  4. A number of users are reporting intermittent issues with outbound email stuck in the Outbox. We are currently looking into the root cause and I will have a further update shortly.
  5. @Paul Morrow If the LDAP import was working fine yesterday (and I presume it has been fine for some time) has their been any changes to the import in the last day or so that might have caused this?
  6. @BobbyB If you can show me how the report has been set up I'll see what I can suggest.
  7. @Martyn Houghton This may possibly be a defect, it would be worth raising a support request to confirm this one way or the other.
  8. All, we will be performing an update at 11.30am which should correct all the issues that have been reported this morning. However this will result in a temporary outage of a couple of minutes. We apologise for the inconvenience this will cause.
  9. All, we are aware that some may be having further issues here this morning. We are looking at this with the highest priority.
  10. @Martyn Houghton I've asked our developers to look into adding these, and also to add additional content rather than mirroring the name of the right in question.
  11. @Martyn Houghton I'll look to make the requested additions to the wiki over the coming days for Application Rights.
  12. @Caroline @Martyn Houghton @John C @Rashid.Ahmed We have now corrected this issue and are in the process of deploying a patch which will be done shortly. Apologies for any inconvenience caused by this.
  13. @Sam P Have you completely flushed your browser cache? you should not be seeing the problem after that.
  14. All, we have pushed out a fix for this, it would be worth flushing your browser cache then checking to see if this remains a problem.
  15. Hi Tracey, thanks for the update. Good to hear your back up and running. Apologies for the disruption yesterday.
  16. We currently have a patch available for this issue. Some downtime, possibly 10 minutes or so will be required to apply the patch and as a result it would probably be preferable to apply this later this tonight. If anyone feels however that this cannot wait please let me know.
  17. A patch was applied to all instances yesterday that should have resolved this issue for all affected instances. Please let me know however if any issues persist.
  18. As a further update to this, we have temporarily upped the column limit to 200 and there will also be a fix in the next ESP release as the column restriction was not meant to apply to all report types.
  19. @RobW @Dan Munns @HGrigsby This is a change that is covered in the latest ESP release notes: Stops the system from processing the reports further when the maximum is reached and to return an error report as the output. Updated the HTML templates for the reports so that the error message can be produced and displayed. Now I believe that previously these reports would fail silently, if you correct the column count to match the configured limit there shouldn't be a problem.
  20. @John C I believe she did. Although I am not yet sure of the root cause.
  21. This was added in error to the release notes and the notes have been corrected this morning to reflect this, as the feature is not actually present in the current release. I suspect it will be in an upcoming release although I don't yet have the details of when that might be.
  22. @Darren Rose I take it we are talking about widgets here rather than actual reports? We have looked at some of the heavier ones and the largest contains the following in the query: h_itsm_requests.h_datelogged >= '2019-04-30 00:00:00' Is there a need for the query to bring back requests from early 2019? If this can be reduced to a weekly or monthly value that should significantly reduce the query time. Also looking at the query two of the fields h_fk_servicename and h_catalog don't have indexes, you could swap them with h_fk_serviceid and h_catalog_id as that should also help to speed up the query and get it under the current threshold.
  23. @Adrian Simpkins If you could provide the details of the two impacted requests we can look into this further. It might be best if you do this via a new request though.
  24. @Caroline I believe if the following Service Manager setting is set as required then the user that created the update should be able to edit it, as long as the conditions in the description below are met:
  25. @Ben Maddams I've sent you an email, if you could reply to that mail with the requested passcode we can take a closer look into this for you.
×
×
  • Create New...