Keith Stevenson

Paul, Thanks for the post. Sadly this is a known issue. Once you make the change and it works (First time) do not go back in and retest as this will cause the password to be lost. The email will flow as expected after the initial save. Kind Regards Keith Stevenson

@Andrew Tasker This appears to be a problem with your Email Server. It initially accepts the connection, allows us tp send the message then says SmtpCmdResp: 400 Temporarily unable to process mail (leaveContext) This is from the SMTP Host smtp_host: mx4.mywatchtower.co.uk smtp_port: 25 You will need to contact the owner of that service. We are not seeing any other issues Kind Regards Keith Stevenson

@Salman Excellent news Kind Regards

@Salman Thanks for the reply. Cant think of anything that would cause that other than firewall\virus scanner or proxy In Windows if you add a program - ie ldap_user_import.exe, it takes a MD5 or similar so that if you overwrite it with a newer version it wont be allowed through. Can you try adding an exception for this specific program. Same for any Virus scanner etc on the machine. Kind Regards

@Salman That looks like your local firewall or network firewall (Guess would be Windows firewall) blocking and you only allowed the OLD exe Kind Regards

All, We have pushed a 2nd patch. Please confirm that this now functions as expected. Kind Regards

@Haroon We have reindexed that search. Can you confirm that this is now functioning as expected KInd Regards

@Haroon Thanks for the post. We are looking at this. Kind Regards

Yelah,nodrog, Even if staff leave the PC on for 24/7 you dont have to leave the session logged in. If you set the idle timeout to 1 hour it will time out, forcing them to re-login to Hornbill. Kind Regards Keith Stevenson

@Adrian Simpkins Great news. Thanks for the Reply @sprasad Can you run perform these actions in Chrome with Dev tools (F12 open) and then we can get the waterfall for the actions to see which APIs are "slow" .. As we can see no issues our side. Kind Regards

@Nikolaj That is now fixed. The root cause was a deployment issue when multiple applications (in this case 3) were released in the same minute. We will add a check to ensure that this will not occur again in future Kind Regards Keith Stevenson

@Nikolaj Thanks for the post. We can replicate this and are investigating. Kind Regards

Dave As outlined https://wiki.hornbill.com/index.php?title=FAQ:Instance_Provisioning - You can. If you wish to proceed please contact our Customer Success team. Kind Regards Keith Stevenson Can we Change our InstanceName It is possible should you wish to change your InstanceName at a later date, however the following must be considered. Change will be made and old InstanceName retired. There is no redirection from old to new. Any @live.hornbill.com email address will also be changed to include the new InstanceName. There is no redirection from old to new. Any not relative Hyperlinks contained within comments or calls may not function. Any not relative Hyperlinks contained within comments or calls may not function. (Note all Hornbill added links will be OK) Downtime is required. Normally this is around 30 minutes, however the more data you have the longer this takes. Any SSO profile may need to be updated. Any Push data imports may need to be reconfigured. BPMs should be checked to ensure they do not contain any hardcoded URLs Email templates should be checked to ensure they do not contain any hardcoded URLs Hornbill allows 1 change of InstanceName without cost, subsequent changes will be charged. It should be noted that InstanceNames are provided on first-come first-served basis and Hornbill retains the right to reject an Instance Name if it is felt to be inappropriate. Although it is possible to undergo a Instance Name change without any professional services, we do recommend engaging with the team as they can then perform a full review of your system to highlight any of the above areas that may be of concern.

@sprasad @lee mcdermott @Adrian Simpkins Regarding the slowness. Can you provide more specifics and in what area\view\action. Ideally with browser timings. All our monitoring shows no issues (Infact today has been one of the best days since records began for Server\Node performance) Kind Regards

@AndyHill Thanks I can see the search but no good reason for it not to show. The query is checking for the phrase you entered and your TEAM ID or SERVICE ID IN (LONG LIST OF SERVICE IDs you support. ) .. Can you confirm that both the SR and Incident are with the same team.. Can you also PM me the SR and Incident references above so I can compare (We dont see these on the log). I have also increased logging again (This time to MAX .. ) Can you run it once more and let us know when done. Kind Regards

@AndyHill, Thanks for the reply. From a indexing point of view we dont care what type of requests they are, we treat them all the same, so if it works for one it should work for all. Maybe something in the rights checking. We have enabled additional debug Can you search again and post with the screenshot like in first post and the date\time Kind Regards

Andy, This appears to be due to a corrupted index file. The good news is that we are in the process of migrating to the new Indexer and all of its benefits outlined in the Customer presentation\roadmap last week. We will bump your instance to the top of this list and perform this tonight. Kind Regards Keith Stevenson

@nasimg@sprasad - Not sure why you are still seeing the error. Have escalated to our general Support team to contact you and to check that its the same issue. KInd Regards Keith Stevesnon

@nasimg in the admin tool goto Home-App-Store Service manager and click the refresh icon @NikolajYou may need to do this as well as you have IP restrictions which prevent us from performing this via API Kind Regards

@nasimgSorry to hear that. Can you try a app cache reload in the admin tool for Service Manager app whilst we investigate. kind Regards Keith Stevenson

All, The patch has now been deployed to all instances (New process is much faster.) . You should no longer see any error. We will post a full RCA later. Can you all confirm that this is now resolved. Kind Regards Keith Stevenson

All, We have a patch and are rolling this out. It will take about 30 minutes to get to all. This is probably quicker than changing the right manually. Will post an update in 15 minutes. Kind Regards

All, The issue is caused by stricter rights checking against the given mailbox from which the email is being sent. Whilst we are working to create a patch you should be able to workaround the issue by adding the right [mangeMailbox] against the mailbox that is used to send email for the Analysts having the issue. Kind Regards Keith Stevenson.

All, Thanks for the posts. We are aware of an issue with sending email this morning following the update. We are investigating and will post an update in the next 15 minutes Kind Regards

Ben, This would be possible via API . If you have experience with our APIs it wouldn't take long, alternativity our Success team will be able to assist. Kind Regards