Kaseya Community

How should i ignore NDRs?

This question is answered

We're testing out the Kaseya Service desk and are having problems. Each time we get a non delivery report (NDR), this creates a new ticket. And when the Service desk tries to send out an acknowledgement that it has received a ticket, that too creates a bounce which in turn creates a ticket.

How should i go on to have these NDRs ignored by the Service Desk?

 ~rL

Verified Answer
  • Hi Robin,

    There is a very simple way to overcome this. On the Service Desk you have a link which reads "Ticket Requets De-Dup". This will monitor tickets coming from a specific address, submitter name, source type, subject and more. When SD detects a new email it will compare it to tickets in the SD, if it detects a duplicate as per they way you have setup the Procedure, it will be deleted.

    I usually select the following tests on the De-Dup procedure:

    Match the submitter name

    Match the submitter Email address

    Match the request subject

    And a comparison time of 2 minutes. This works great.

    Also to ensure that tickets get updated via email, you need to add the following variable to your Tickets or Message Templates

    ~ticid='[$TicketId$]'

    If you have that variable in any part of an email, the replies from your customers via email will update the ticket in SD. This variable ID's each ticket in the SD which is unique.

    Hope this helps.

All Replies
  • instead of ignoring the NDR's, you better search for the reason why these are generated. If the NDR's aren't generated, then you don't have to ignore them.

    So you have to look over all the settings and search for mailadresses. Then change the wrong address which is creating the wrong mails.

  • You are quite right. But when i first started trying out the SD module, we got a mail storm between the module and our mail server when it would not send email to mailer-daemon. This created a ticket which would be acknowledged to mailer-daemon who does not (as an email address) exist, which created an NDR, which created a ticket, et cetera.

    I believe the whole thing started when i wasn't aware of a SD variable with the pre-filled value "your.ticket.review.team@yourcompany.com", but i will also get a new ticket if i for instance mis-spell an email address.

  • (sorry, that would be  enter.review.team.email@yourcompany.com  :)

  • Hi Robin,

    There is a very simple way to overcome this. On the Service Desk you have a link which reads "Ticket Requets De-Dup". This will monitor tickets coming from a specific address, submitter name, source type, subject and more. When SD detects a new email it will compare it to tickets in the SD, if it detects a duplicate as per they way you have setup the Procedure, it will be deleted.

    I usually select the following tests on the De-Dup procedure:

    Match the submitter name

    Match the submitter Email address

    Match the request subject

    And a comparison time of 2 minutes. This works great.

    Also to ensure that tickets get updated via email, you need to add the following variable to your Tickets or Message Templates

    ~ticid='[$TicketId$]'

    If you have that variable in any part of an email, the replies from your customers via email will update the ticket in SD. This variable ID's each ticket in the SD which is unique.

    Hope this helps.

  • Thank you, i shall update my templates. I suppose that was the part that was missing, and caused new tickets to be made when replying to old ones...

  • Whats also nice , is if you have the ~ticid='[$TicketId$]' present in your email templates, and the dedup doesnt work, it will just ammend the duplicate email to the ticket, instead of creating dozens more. When i was configuring our Dedup, I had that in place and it was a life safer. Yes the ticket had like a hundred updates, but rather the hundred updates than a hundred tickets. Good little failover.

  • I use a de-dup which is so very helpful if you also use the email reader for alerts.  But to help with your question, we also make use of mail filters.  Go into the inbox of the email reader account and set up some rules.  One of our rules is for undeliverables to go to a different folder.  The email reader will only process what's at the root of the inbox, not emails from any subfolders.

    By doing that,  you have the option to review them.  This is necessary sometimes, as this can be due to a typo in the submitter email field (when it's being entered manually by a tech and not by the System).

    Another way to keep a copy of your support emails if not already done that I would recommend... forward at the mailbox level all emails to the email reader account to another account so you have copies.  In the off chance the email reader processed emails but didn't create a ticket, you have a backup.

    -G

  • I also use the ~ticid='[$TicketId$]' and the inbox filter to filter out a lot of the common requests. Just a question in regards to de-dup. I looked at the IF statement and it seems pretty straight forward, but what action do I put? Ie I created a If that sets Match Submitter Name, Email address, subject.

    But what action do I put after the IF statement? Or do I just leave it by itself?

    Also, Anyone got any handy incident mapping scripts that map email addresses to customers or machine ID's? Having trouble with this area at the moment.

  • For the if statement, if it matches the criteria you selected, then it's dropped.  Don't need to do anything else.

    For mapping to customers, I created a subprocedure, and map each customer with something like:

    if email contains @domainabc.com, then set Org to abc.

    I then schedule this subprocedure as one of the first steps in the very first stage of the workflow of that service desk.

    -G