Osman

Morning All, Thanks @EWA, I think this is exactly what I needed: Expire Period [duration] : The length of time to wait based on working time/calendar days until the node expires. So, yes, the 40 hours with an eight hour day would be 5 working days. Appreciate the speedy response. Osman

Afternoon All, I feel a little dense asking this, but need some clarification. We have a suspend node where it has an expire period set to 40 hours. What I wish to confirm is how to calculate the end of these 40 hours. Are the hours counted only during the working day set in our Working Time Calendars? So if we have a working week of Monday to Friday 8am to 8pm, 5 days would require the setting to be 60 hours. If we had a working week of Monday to Friday 9am to 5pm, 5 days would be 40 hours? Thanks in advance Osman

Hi Steve, Apologies for the delay in responding, I didn't get a notification that an update had been posted. Whilst it is an interesting suggestion, updates in this thread state that only the account that created the import.cfg can access the data contained within sync tool. Also, when you say my account, do you mean my standard windows account or my admin account? As I have not, and would never, log on to a server with my standard account. What I would say is that I do not believe that this is an authentication issue, the credential work fine. As I have stated more than once, if I run the command manually from a command prompt, it works without issue, and that is running in the same user context as the Task. Thanks Osman

Morning All, As it has been a few months since our last interaction, I thought I would drop another message to see if anyone had anyone had any further insights into the issue? Thanks Osman

Hi Steve, Thanks for this, are you able to confirm whether this applies to both Requests and Incidents? The response by @lee mcdermott on the 26th suggests that it will be Requests only. Thanks Osman

Afternoon All, Am I the only one perplexed by the idea that it is possible for an end user to Close a Resolved ticket, which the workflow will do automatically after X days anyway, but not able to mark a Request or Incident as either Cancelled or Resolved. I understand that an Incident should never be Cancelled, but I see no reason why an end user should not be capable of Resolving their own issue: 1. User raises a call that Word Won't launch; 2. Ticket logged by email or through Self Service and confirmation received; 3. Before the Agent contacts the user, they decide to restart their device and the issue goes away. Unless the system allows for self-resolution in these scenario's, I see time on the Service side being wasted. I assume that there is no flexibility within the configuration to let the individual organisation decide how they wish end users to respond to their own issues? Thanks Osman

Hi Keith, Thanks for this, I will get it looked into, though I am certain the record exists in the chain. A bit of a related question, as it has frankly baffled me and there is no record of what was done. The setup of HornBill in our environment predates me. How does the email get from our organisation into HornBill? I have found the domain setting, I have found the Shared Mailbox setting. But I can't find the actual setting that gets the emails in the Shared Mailbox in the first place. There is no forwarding on the internal mailbox, nor a Hub Transport Rule on Exchange. I am at a loss. The documentation here: https://docs.hornbill.com/esp-config/email/shared-mailboxes#:~:text=Click on the Create Role,who are assigned this role. States that an Inbound Mail Service needs to be setup, we have it, but it points to a HornBill IP address for live.hornbill.com, so I am a little confused. The answer to this was requested as part of all the DMARC setup that led to this thread in the first place. Thanks Osman

Hi Keith, Basically, we are using an intermediary service to manage our SPF record, it seems thar HornBill is not capable of seeing this. We have added the record back in at the top level and email is now working again. Is there any way to identify what emails have failed so we may resend? Thanks Osman

Morning, We have been looking at this today and I have been advised that a change was made on Tuesday to redirect our SPF records. Is this supported? Thanks Osman

Hi Keith, Thanks for coming back to me so quickly. I have no idea how that has happened. We have reported an issue with the DKIM to completing the setup as it is stuck on verifying, but didn't realise there was also an SPF record issue. Thanks Osman

Afternoon All, As of 4.30pm, approximately, yesterday our instance is no longer sending emails, at all. As far as I am aware, this is all sent from the HornBill servers rather than from our own system. Can you confirm if there is an issue and if anyone else has been experiencing this? Thanks Osman

Hi James, Thanks for the speedy response. Osman

Afternoon All, We set up DKIM on our instance some time ago and it has been drawn to our attention that it does not seem to be working. The setting is stuck on verifying and when an attempt is made to Verify, we get the error: The option 'mail.outbound.dnsServers' was not found. (262 defined) Any ideas what this error means? Thanks Osman

Hi Victor, Thanks for the speedy response. That looks to have sorted out the API Key renewal. Thanks Osman

Morning All, Whilst waiting to get some sort of resolution on the topic: My API key expired. I have created a new one and updated the KeySafe entry with the new API key and am now getting this error: 07/12 09:29:20 [MESSAGE] ---- Hornbill Azure User Import Utility v4.2.3 ---- 2024/07/12 09:29:20 [MESSAGE] Flag - file: conf.json 2024/07/12 09:29:20 [MESSAGE] Flag - logprefix: 2024/07/12 09:29:20 [MESSAGE] Flag - dryrun: false 2024/07/12 09:29:20 [MESSAGE] Flag - workers: 1 2024/07/12 09:29:20 [MESSAGE] Flag - apitimeout 60 2024/07/12 09:29:20 [MESSAGE] Flag - forcerun false 2024/07/12 09:29:20 [MESSAGE] You're running the latest version of this utility: 4.2.3 2024/07/12 09:29:20 [MESSAGE] Successfully decrypted Hornbill instance authentication information 2024/07/12 09:29:20 [MESSAGE] Loading KeySafe Authentication Data: 14 2024/07/12 09:29:20 [ERROR] Error Loading KeySafe Authentication: Invalid API key On the offchance that there was something wrong with the Azure aide of things, I created a brand new Secret for the app, same error. I even recreated the KeySafe entry and updated the conf.json to match, same error. What I have noticed is that every time I make a change to the API key in the KeySafe entry, the Save button is never activated, nor does the Data value change in the h_keysafe_keys db table. Thoughts on the cause would be welcomed. Thanks Osman