PDA

View Full Version : Automated Email Handling is not generating tickets (using Kaseya)


acrosser
February 17th, 2009, 06:10 PM
We use Kaseya and CommitCRM on our network. Each is running on Windows Server (Kaseya on 2003 and CommitCRM on 2008), and we're using Exchange Server 2008 on a separate server.

I followed this informative CommitCRM forum post/guide on Kaseya integration:

this link (Kaseya Integration in 30minutes or less)

...which describes how to configure Kaseya's alert emails and CommitCRM to automatically create new tickets from the emails.

Here's a little info about my setup (names changed for anonymity):

- Kaseya sends FROM support@ourcompany.com and it sends TO help@ourcompany.com (which is our CommitCRM email address, and is working fine in all other regards).
- I've set the Sender Email Address in Commit's "Automated Emails Detection Rules" section to support@ourcompany.com.
- I've created the following rule in "Account Record Detection Rules":

Account Name is found between 'Site:xyz-managed.' and '.'

- Automated Email Detection and Handling is ON. Saved/OK, CommitCRM services restarted, etc.

- Kaseya sends an alert email to help@ourcompany.com with the following subject line:

fieldtechpc.xyz-managed.xyz.desktops is offline (CRM Site:xyz-managed.xyz.desktops)

- I've set the File As field for the "xyz" Account in CommitCRM to "xyz" (all lowercase).


When the email comes in from Kaseya and gets sent to help@ourcompany.com (note that this is an internal-to-internal Exchange email... not coming from outside our Exchange server or leaving our Exchange server -- not sure if this is a problem), a ticket is not created byCommitCRM. The email just gets forwarded on to support@ourcompany.com as an unhandled email.

Is there anyway of troubleshooting this? Is there a log that's created/modified byCommitCRM? Is my syntax in the rule incorrect?

We have several customers that are subgroups of the main group in Kaseya: "xyz-managed". So we have subgroups in Kaseya such as xyz-managed.customername. And we have subgroups underneath that, such as xyz-managed.customername.servers and xyz-managed.customername.desktops.

So it's my understanding that CommitCRM should see "Site:xyz-managed.xyz.desktops)" in the subject line, and encounter the string "Site:xyz-managed." then it will start matching the Account File As field (xyz), and then it will see the next dot "." and stop consuming... matching the Account as "xyz". And that should match the File As field in CommitCRM exactly.

Any ideas?? Thanks!!! :-)

Support Team
February 18th, 2009, 07:32 AM
Hi acrosser,

Looks like it's basically configured correctly. The only part which looks suspicious is the Account Detection Rule:

Account Name is found between 'Site:xyz-managed.' and '.'

When using the Account detection rule, you should provide a "static" text, which always appears in the email subject, just before the account name. In your example, the string "Site:xyz-managed" includes the "xyz" which is the company name, and probably changes for each company. This will require a separate rule for each customer, which is not the right way to go about it.

If I understand your example correctly, perhaps a better account detection rule would be:

Account Name is found between 'Site:' and '-'.

Does this make sense?

Neta

acrosser
February 18th, 2009, 09:50 AM
Neta,

Thanks for the reply. This makes sense, however 'xyz' does not change for each customer.

I changed 'xyz' from the actual company name for anonymity's sake, so let's say the customer name is BumbleBee.

And let's say that -our- company name is Awesome Networking Inc., and we abbreviate our company name to ANI.

Using the example above, this is the rule I have (hard-coded):


Account Name is found between 'Site:ani-managed.' and '.'


And here's an example automated email subject line that comes from Kaseya:


fieldtechpc.ani-managed.bumblebee.desktops is offline (CRM Site:ani-managed.bumblebee.desktops)


I currently only have 1 hard-coded rule like the one above in Commit, that is matching one single customer, just to try to get it to work. We have other customers with Kaseya group names (and matching CommitCRM Account File As names) such as:

ani-managed.lawfirm
ani-managed.medicalclinic

And so we get emails from Kaseya that include subject lines with the following text:


... (CRM Site:ani-managed.lawfirm.servers)
... (CRM Site:ani-managed.medicalclinic.desktops)


(So the first part "(CRM Site:ani-managed." never changes, and there's always a dot "." after the customer/account name, and then maybe a different subgroup such as servers, desktops, laptops, etc.)

Is there any way to look through logs or troubleshoot this to dig deeper and understand why the rule isn't getting triggered?

Support Team
February 18th, 2009, 11:27 AM
Yes, in this case the rule seems to be fine. This really should work for you, it's weird... Probably just some minor mis-configuration somewhere.

I'd suggest checking the following:

1) Make sure the company name appears exactly in the same way in the File As field in RangerMSP

2) The test account in RangerMSP which contains this company name in the File As must be unique (make sure you don't have two account records with the same "File As" value).

3) The account in RangerMSP which contains this company name can't be an employee (the Email Connector does not handle employee records as valid accounts) - make sure you are not using an employee records as your "test account" - you should use a regular customer record.

4) Make sure you do not use any quotes in the rule definition (e.g. you should use Site:xyz-managed. in the field definition, without using quotes).

5) Make sure you do not have any Skip rules defined for the automated emails.

6) When you receive the email in the internal address, does it indeed arrive from support@yourdomain.com? Make sure the email defined in the "Automated Email Detection Rules" is correct.

7) Maybe try restarting the service again, just to make sure it is using the most updated settings.

I hope any of these suggestions will help or give you a direction to find what goes wrong. It really should work, especially since you say the regular "email-to-ticket" feature works for you.

Let us know how it goes.

Neta

vsouthmayd
February 18th, 2009, 04:53 PM
A couple random thoughts.

First off there was an update to CommitCRM 4.4 to allow the use of fields other then the File As field. I don't understand why it might be a problem, but since they went through the trouble there must be a reason for that update. I changed my config to use field1 as the Kaseya ID and relabeled the field for my users.

Case does matter and bit me during this process.

Make sure you are restarting the CommitCRM Server service so it picks up your changes immediately.

In the format of each Kaseya alert i changed the format to include <id>.<gr>. with a trailing period to force the period delimiter in each subject. My groups are all in the format tnc.groupname or audit.groupname. If you don't have the period in the Kaseya Email Subject line there may be no period to end the group rule.

So I have two rules:
1. looking for Field1 between tnc. period.
2. looking for Field1 between audit. and period.

Examples

id=pc105 gr=tnc.acme01 <id>.<gr>. format is pc105.tnc.amce01. Field1=acme01

id=server1 gr=tnc.acme01.svr <id>.<gr>. format is server1.tnc.acme01.svr. Field=acme01

I would be glad to help if you forward me a copy of a sample email subject line and screenshot of your rules config to my gmail at vsouthmayd. Just setup a testing record and rule to protect confidentiality.

Vernon Southmayd
Creative Computing, Inc.
http://creativenetcare.com

acrosser
February 19th, 2009, 03:42 PM
Thanks for the tips Neta and Vernon.

I finally got it to work. I followed Vernon's suggestion and used Field1 in the Accounts-Details tab rather than the File As field. (You have to edit the Field1 list and add all the company values, but this has the added benefit of not changing the way the Account name is displayed in both CommitCRM and Outlook Contacts, which is the case when you use File As). This was all I changed to get it to work.

Like Neta said you also have to make sure the Account is set as Type == Customer in the Accounts-General tab.

For anyone else that has this same problem, you can check out 3 screenshots I made of the configuration and a sample email here:

http://www.spacetornado.com/crm/