Keith Stevenson

All, Note that this only applies to emails downloaded from Microsoft Office 365 or Exchange Online. The Server will then be outlook.office365.com or similar. This does not apply to live.hornbill.com addresses Kind Regards Hornbill Cloud Team

All, In their wisdom, Microsoft have decided to end "Legacy" support for User\Password authentication for POP3\IMAP on the 1st October 2022, forcing everyone to use OAuth. If you are using Office365 you will need to change to this new Authentication Method or email will not be imported after this date. The following details how https://wiki.hornbill.com/index.php?title=How_to_configure_OAuth2_Authentication_for_Microsoft_Office_365_Mailbox_integration Please change this before the 1st October 2022 to avoid disappointment Microsoft announcement - https://www.microsoft.com/en-us/microsoft-365/blog/2022/09/01/microsoft-retires-basic-authentication-in-exchange-online/ Kind Regards Hornbill Cloud Team

Berto The below is a snippet of code that will reset all Out of Office every time its run (so next email will get reply) for all users.. This if scheduled sort of resolves yours issue periodically. However if you use Hornbill ITOM and on receiving an Out of Office message log a call, this can then fire an ITOM job\script which is a variation of the bellow to reset that users (as you have their email) out of office status in realtime so next time you email from this or another call it will get the OOO reply, the call then done can auto close itself [code] $enabled = Get-Mailbox -ResultSize Unlimited | Get-MailboxAutoReplyConfiguration | Where-Object {$_.AutoReplyState -eq "Enabled"} | Select-Object Identity, AutoReplyState$enabled | ForEach-Object { Set-MailboxAutoReplyConfiguration $_.Identity -AutoReplyState "Disabled"set-MailboxAutoReplyConfiguration $_.identity -AutoReplyState $_.AutoReplyState} [/code] ITOM solves all the problems and there would be other options available (including grabbing the Out of Office status and updating the Hornbill record either via script or future package) should you choose that route Kind Regards Hornbill Cloud Team

All, It appears that around 20% of all instances still have the system default of system.administrator@hornbill.com set against the Admin account. This address can be used to email notifications and if a Forgotten password request is made against the account. We often see that this functionality being needed at times of SSO login failure when you need to revert to the Admin account and when used an email sent to the above address (which does not exist). To prevent disappointment or delay in using this functionality you should change this to one of your own addresses. Kind Regards Hornbill

Joshua, Thanks for the post. The Hornbill mail client will do the same every single time we send an email via direct outbound. The rejection message stated is direct from MS (in this case). We have no control over this. The fact that the email address isnt valid and then is would need to be investigated by the owner of that domain in collaboration with MS. That said.. We have watched your traffic for a while and some DNS Probes for NX Lookup do return 0 (This is different to the specifc 550 error above which is still an MS Issue. ) - This appears to be due to a Cloudflare issue and intermittent. Which may explain why you see some emails fail to resolve domains and then work next pass. This can be seen by doing nslookup server 1.1.1.1 set querytype=mx siwfinc.com if you run that several times you will get a timeout on 1 or more and the next time this is fine if you change the domain to hornbill.com it seems to be fine and if you change server to 8.8.8.8 (googles) its also fine. So it appears that you are seeing 2 different issues (1 hard failure - 550 which is the MS issue) and 1 intermittent and merging the two. These are 2 distinct and seperate errors. Kind Regards Keith Stevenson

Josuha Thanks for the post. Ive removed the attachments as they contain personal email addresses and this is an open forum. The emails in the Failed Txt file failed dur to the recipient not existing on the given domain (hosted by MS) and when we try and deliver the email it returns the error 550 5.4.1 Recipient address rejected: Access denied. This is a MS\Recipient problem and not a Hornbill problem (We perform the lookup get the MS server as MX record, connect and try to delivery this as expected) We would suggest that you escalate this to the Domain Admin. Kind Regards Keith Stevenson

@Nikolaj From looking at the DB it appears that when this file was uploaded the comma was not encoded in the DB this will then break the download file name at that point. We can replicate this when the file attachment comes in via email (and is then attached to call.). Will get this resolved and post once fixed Kind Regards Keith Stevenson

@Nikolaj Are you referring to the signing of the email with DKIM? This is the only reason I can see that would prevent your team from inserting the email footer in route (As we sign the email before). If so you can disable DKIM by going into the mailbox domain properties (Under Platform Configuration->Domains ). Kind Regards Keith Stevenson

Euan, Thanks for the post. We can see that from 1033-1101 emails failed to be sent as there was no SPF record for your domain when we did a TXT record lookup (In the code). By the time we looked at 1111 this was again working so unsure as to why it failed during that time. The check is very simple and very robust so unlikely to be a code issue. Did anyone make any changes to your SPF\TXT records today? Kind Regards Keith Stevenson

@Daniella R. Goral Thanks for the Post. There is a known issue with this at the moment that can cause either loss of SM Icon or occasional incorrect 404. A fix has been applied to beta and should be on live this week. In the meantime F5 will fix the problem. Kind Regards Keith Stevenson

All, The fix for Data Preview, Copying Reports, Creating new and saving changes to Reports has been deployed to all instances. Kind Regards Keith Stevenson

All, Thanks for the posts. We have identified the root cause and built a fix. We will look to patch all instances tomorrow at 5am Kind Regards Keith Stevenson

Adrian, Thanks for the post. We can confirm that we can replicate the issue and are investigating. In the meantime you can load the report (dont go to the Data Preview tab), goto Output Formats , Check CSV , then go to Data Preview ... Sadly we also note that the change in Output Format is not correctly saved so it will have to be re-done each time you wish to view the Data Preview.. We are also looking at this. KInd Regards Keith Stevenson

All Please find below the RCA from Cloudflare https://blog.cloudflare.com/cloudflare-outage-on-june-21-2022/ We have also reviewed our processes and given the nature of the error we do not believe we would act differently given same error. We have investigated having a domain that's not proxied via Cloudflare but the benefits this provides far outweigh the risk. (Workarounds existed if you wanted to add the IP of live or the forums to your hosts file and bypass cloudflare but this was a temporary solution and IPs are subject to change and we also considered having a second URL for the forums which didnt go through Cloudflare but how this would be remembered by Userbase and added confusion over URLs was considered, so having status.hornbill.com for ongoing critical issue updates is still preferred) We would also strongly recommend that everyone follows status.hornbill.com and our Twitter feeds which do not go via Cloudflare and are completely separate to our infrastructure. Kind Regards Keith Stevenson

All, Whilst we aim for 99.99% uptime, there are sometimes when the internet may not work as we hope. When this happens, normal support channels and sites may not be available. You should therefore follow and subscribe to: https://status.hornbill.com/ and follow us on Twitter @Hornbill We will always post to the above even when the Forum or other support channels are unavailable. Kind Regards Hornbill Cloud Team

Dear All Please also bookmark and follow https://status.hornbill.com/ . This site is separate to our normal infrastructure and will never go via cloudflare and will always be updated should issues occur. Kind Regards Keith Stevenson

Dear All, This is indeed comming back. We use Cloudflare to cache all from end (none data ) in data centers closer to the end users to increase performance. Sadly it appears that Cloudflare this morning had a configuration issue that prevented routing from a number of their data centers and prevented us from logging in to their portal to Stop the proxying. We are awaiting cloudflares update on the root cause but it does appear to be back for now. Kind Regards Keith Stevenson

Dear All With regards to your Hornbill instance. This morning since around 0740 BST Cloudflare have been having issues. This is effecting large parts of the internet, whilst all Hornbill services are up and running they may not be contacable. Please see https://www.cloudflarestatus.com/ KInd Regards Hornbill Cloud Team

All, The above patch has been deployed to all instances. This should resolve this issue (ERROR on fAQ1,h_type) and hopefully the other 2 issues people have reported this morning.. Can I ask that if you are still suffering the other issues (NOT the FAQ1) that you post in the other existing threads so we dont confuse issues . Kind Regards

All, Thanks for the posts. The patch is currently being rolled out we expect this to be completed in another 10 minutes. We will post once complete Kind Regards

Paul, We can see the issue, identified the root cause and are working towards a patch. Will post once we are ready to apply Kind Regards

Paul, Thanks for the post. We are investigating. Kind Regards

All, A reminder that support for IE will end on the 15th June. After this time users will not be able to access Hornbill using IE, anyone still using IE should remind their end users before this time to avoid disappointment. if you have been directed here from the Hornbill Client stating IE is no longer allowed, then you should contact your IT Team to discuss alternate browsers Kind Regards

Euan, Thanks for the post. The root cause is usually a malformed or incorrect MIME email. Typically this would be a missing embedded image as in the mail header it states there are 3 attachments, but in the actually body 1 or more has been removed (by the sender..). The resolve is to remove the missing email attachment from the list of attachments before trying to apply the request. (in the email this will be displayed as a rectangle or similar without any image) . If you still have issues please PM me the message ID (You will see this in the URL at the top when selecting the message in the mailbox) Kind Regards

Jake, Thanks for the reply. That does sound like it will be loading the 15K records (and as its queried, exported and made into XML which adds a lot of overhead for the list) in Progressive capture this could be quite a lot (without knowing how long your assignment numbers are and what name you give then, it could be 5mb or more every time you open the log call form for that Query type, not sure how browsers will like parsing that. Whats needed is a server side (rather than client side) means to filter or populate from list or "external lookup" feature . Our development team will review this post and look to add something like the above in future if possible. Kind Regards Keith Stevenson