Move to 365 Graph broke Ticket Dispatch

[kkulich]

We just migrated our email from an on-prem service to Microsoft 365 using GRAPH api per the documentation and ALL of our Ticket Dispatching rules (all firing off of variations of: <setdifferenttickettypes>@domain.com) stopped working.  All of them were working with our on prem POP3/SMTP service. 

We have several aliases for <setdifferenttickettypes>@domain.com on the lansweeper email box in Exchange/365.  We have confirmed that the to: field in the lansweeper shared email box  is intact.  Yet none of the Ticket Dispatch rules are doing anything - all inbound tickets ARE being ingested, however they are being set to the default ticket type as though they had been sent to the general helpdesk email (lansweeper) address.

Has anyone else run into this issue?  Opened a support case - but nothing from them as yet.

[DavidPK]

Hi,

Test with Different Conditions: Try setting up a new dispatching rule with minimal conditions to see if it gets applied. This can help identify if the issue is with the specific conditions set in your current rules. 

If that doesn't work then you can contact support and we can investigate further

How to contact support?

Make sure to add screenshots and the GatherLogs output file so our SME's can start investigating the issue straight away. 

Using the GatherLogs tool.

[kkulich]

The only way we were able to get this to work was to set each unique email address up as a Distribution list with the Lansweeper mailbox being checked via the graph api as a member.  Lansweeper then respected the to: field action in the ticket dispatching rules.  It simply would not process the emails to: field correctly if it was an alias to the Lansweeper mailbox - even though the headers preserve to: as the correct aliased email.

This unfortunately created a new issue however as now the ticket-dispatching rule email address (aka the distribution group) is now added to every ticket as a CC  user, which will eventually cause issues.

I did open a ticket shortly after posting this - the response was lackluster.  They acknowledged the problem with the CC user, completely ignored the original problem (sweeper not honoring the to: field), and offered up only to put in a feature request.  Considering Sweeper has stated they aren't developing the on-prem Helpdesk product any further I'm not really sure why that would have been the solution/resolution to an ancillary problem while completely ignoring the actual issue.