Kaseya VSA v5.x - Email Configuration
Technical Support Guide
Document Owner - Kaseya Support
Version Control - Christine Rodriguez, Dylan Lagi
Authors - Christine Rodriguez, Dylan Lagi
Kaseya VSA v5.x - Email Configuration
Kaseya interacts with email systems in two areas:
1. Kaseya uses the built-in SMTP functionality of the IIS installation on the Kaseya server for
a. When an alert is raised and the email option is checked.
b. When the notification criteria is triggered for a ticket.
c. When a script action is configured to Send Email.
d. When a report is scheduled to be emailed to a customer.
2. An email reader polls an email server account and converts emails picked up from that email account into tickets. Two modules provide emails readers: Ticketing and Service Desk.
The following sections cover Kaseya's Email Configuration
The SMTP delivery process is relatively simple. Kaseya is configured to use the drop box mail facility.
When Kaseya sends an email, it creates the necessary files in the pickup folder configured by IIS on
the same server as the Kaseya VSA. Internet Information Server is then responsible for delivery of
It is important to realise that Kaseya only supports email delivery issues when these files
fail to be created successfully in the pickup folder. If they are correctly created, but are not being
delivered by IIS, you will need to raise a call with Microsoft in order to investigate the technical
issues preventing IIS from delivering the email.
With this in mind, this document provides troubleshooting advice for a number of issues frequently
encountered by Kaseya customers for SMTP mail delivery. The advice given herein is for a 3rd party
product not supported by Kaseya, and any technical queries should be directed to Microsoft when
they fall outside of the scope of Kaseya support.
SMTP should be installed and running prior to your installing the Kaseya server product. See the
Kaseya Server Installation Guide (http://help.kaseya.com/WebHelp/enUS/5010000/index.htm?toc.htm?2187.htm) for details.
Co-existence with other email products
You should not normally install any other email product on the same server as Kaseya server. In
1. Exchange changes the default mail pickup folder from the IIS default. Kaseya will continue to
drop its mail in the IIS default location, which will prevent this mail from being delivered.
You’ll either have to change the IIS metabase settings to the new location, or create a
junction point mapping the IIS mail pickup folder to the Exchange mail pickup folder. This is
not a supported configuration, due to other technical co-existence issues with Exchange
and should not normally be used.
2. Other 3rd party mail products will conflict with port 25 of the IIS SMTP server, preventing the
IIS SMTP service from starting. Because Kaseya only sends mail outbound, and does not
need to listen for inbound mail, you can remap this port number to allow both IIS SMTP and
the other mail product to run on the server. See
SMTP Delivery Configuration
There are two basic approaches to delivery of SMTP mail from the Kaseya server:
1. Use DNS to resolve where email should be sent to and allow the Kaseya server to connect to
any external mail server over outbound over TCP port 25. This is the out of the box
configuration for IIS. You’ll need to ensure that you have DNS resolution working correctly
for both your internal and external mail recipients – see
2. Configure the Kaseya server to forward all email to another mail server – see
http://community.kaseya.com/kb/w/wiki/configure-smtp-to-deliver-mail-internally.aspx for details. If the mailserver is
an Exchange server, it is likely you’ll also have to configure IIS for Smart hosts – see the
SMTP Smart Host Setup section of the Kaseya Server Installation Guide
SMTP Service Configuration
The IIS SMTP service on the Kaseya server takes a long time to detect bad email addresses and time
out attempting to deliver the messages. This can result in queuing of delivery of email from the
Kaseya server, even to a local mail server.
This is due to the default configuration settings of SMTP in IIS. These settings are appropriate for
normal mail delivery, but not necessarily correct for the time sensitive delivery of email that many
Kaseya server configurations require.
See http://community.kaseya.com/kb/w/wiki/iis-smtp-service-on-the-kaseya-server-takes-a-long-time-to-detect-bad-email-addresses.aspx for the recommended IIS Default SMTP Delivery settings.
Configure IIS Logging
To assist in the diagnosis of email delivery issues, you should configure the SMTP service to enable
IIS logging. This will enable you to see text file logging of SMTP delivery, which may be required to
troubleshoot issues with mail delivery. If you have logging enabled in IIS then the files will be located
in C:\WINDOWS\system32\LogFiles\SMTPSVC1 by default. To do so, follow the Enable Logging in
Ascii Format section of http://support.microsoft.com/kb/303738.
The log entries will be of the form:
18.104.22.168, OutboundConnectionResponse, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 78, 0,
61, 0, 0, -, -, 220 relay.plus.net ESMTP Exim Thu, 08 Nov 2007 22:47:59 +0000,
22.214.171.124, OutboundConnectionCommand, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 78, 0, 4,
0, 0, EHLO, -, chilli,
126.96.36.199, OutboundConnectionResponse, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 141, 0,
51, 0, 0, -, -, 250-ptb-relay01.plus.net Hello chilli [188.8.131.52],
184.108.40.206, OutboundConnectionCommand, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 141, 0,
4, 0, 0, MAIL, -, FROM:<firstname.lastname@example.org> SIZE=864,
220.127.116.11, OutboundConnectionResponse, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 219, 0,
6, 0, 0, -, -, 250 OK,
Email Reader polling
The email reader polls the POP account specified on the Ticketing tab > Email Reader screen
periodically (the default is 3 minutes). The email reader downloads any emails in the mailbox when
polled, removing them from the server. The emails are then converted to tickets, using the Email
Mapping rules, and matching against the From field and Subject line filter. The connection and
conversion process is logged in the Email Reader log, which is located at <Kaseya Install
Directory>\KServer\KEmailReader.log, for example C:\Kaseya\KServer\KEmailReader.log.
The Email Reader is installed as a part of the Kaseya VSA.
Preparation Configuring Microsoft Exchange for POP
By default, Microsoft Exchange is not POP enabled. If you want to have a mailbox use the POP
protocol, you’ll need to enable POP on your Exchange server. See http://technet.microsoft.com/enus/library/aa996347.aspx for how to enable POP on Exchange 2007.
Troubleshooting Email Delivery
No emails being sent
In the event that your Kaseya server is not sending any email:
1. Stop the SMTP Server in IIS on the Kserver.
2. Go to System tab > Configure and send a test message.
3. Allow 2 mins for background processing to complete, then check the IIS pickup directory
(C:\inetpub\mailroot\Pickup by default) to see if the message is there and has been
4. If no email appears in the IIS pickup directory, you have a problem with the processing of
alerts on the Kaseya server. See http://community.kaseya.com/kb/w/wiki/alert-does-not-raise-or-delays-alarms-tickets-emails.aspx
5. Start the SMTP server - the message should be taken out of the pickup directory and
6. Check in the SMTP logs (C:\WINDOWS\system32\LogFiles\SMTPSVC1 by default) to see if
the message was delivered and if there are any errors. You may have to enable IIS SMTP
logging if you have not already done so (See Configure IIS Logging).
7. Check the badmail directory (C:\inetpub\mailroot\Badmail) to see if there is any delivery
failure message. Messages in the badmail directory point to a DNS resolution or connectivity
Reinstalling IIS SMTP
You may have to reinstall IIS SMTP in the event that you find one of the following symptoms:
1. The Simple Mail Transfer Protocol (SMTP) service cannot be started from the service control
2. Alert emails, ticketing emails, and test email files from Kaseya appears in the SMTP pickup
directory, e.g. c:\InetPub\mailRoot\Pickup, but are not processed.
3. Application Event Log or System Event Log entries indicate that the SMTP service is not
Internal or external mail recipients never receive an email
This points to either a DNS or connectivity issue or a problem with spam filtering or mail otherwise
being intercepted. If it is a DNS problem, you should see a badmail entry for the particular mails.
For internal recipients not receiving email:
1. The most common problem for internal mails not being received is that the server is
referring to an internal DNS server which does not have an MX record for your domain
which points to the internal mail server. Use nslookup to confirm the presence of an MX
2. Also check whether your internal mail server is configured to allow delivery of emails from
the Kaseya server.
For external recipients not receiving email
1. If you are using DNS resolution, confirm that your Kaseya server can connect to the
destination mail server over port 25 by running telnet mailserver 25 from the Kaseya server
and attempting to send an email.
2. Have the end user check their spam filtering, including the Junk E-mail folder in Outlook, any
antivirus spam folders, and their perimeter spam filtering systems.
Duplicate emails being sent or received
Duplicate emails point to a Kaseya configuration issue, where you have configured the same email
address multiple times as recipients of an Alert, Notify Policy or Report.
It may also be the result of an email loop. If you see the phrase No response text provided appear
repeatedly in a ticket, sending a flood of email responses, you may have configured or triggered a
mail loop somewhere.
Emails from Alerts not being sent
For emails from Alerts, you should initially check the Monitor Action Log for the machine raising the
1. If there is not an action of the following form in the Monitor Action Log then there is an
issue with monitoring or alerting on the machine, which you should troubleshoot as any
other monitoring issue.
2. If there is an action of this form, then diagnose this as any other email delivery issue. Please
note that due to normal SMTP delivery processes, there will be a natural delay between
raising the alert and receiving the email – see
3. If there is a significant delay between the alert being raised and the email being sent, you
may have a problem with the processing of alerts on the Kaseya server. See
Emails from Notify Policy not being sent
For emails not being sent when a Notify Policy should be triggered, the most common problems are
due to misunderstanding the nature of the Notify Policy screen.
Almost all Notify Policies will only send emails to the email addresses listed on the Notify Policy
page next to the policy for the machine group. The notify policy that applies will be that listed for
the machine group a ticket is assigned to.
The exceptions are:
Emails will be sent to the ticket submitter for the following options only:
Send auto response to emails creating new tickets
Notify Ticket Submitter when note added
If you select the send auto responses, emails will only be sent for emails creating new tickets to the
Ticket Submitter; not if the ticket using web interface.
Emails will be sent to the ticket assignee for the following options only:
Received emails send alert to assignee
Although named Received emails, the R option will also send an email to the assignee if a note is
added to the ticket.
Both the N and R options require that a note be added to tickets to generate an email, not any other
change (such as updating a field or closing a ticket). So you have to ensure that the assignee or ticket
submitter can see the note being added to the ticket. This may require that you set the Access Policy
to automatically create notes when a field change occurs and ensure that these are not created as
It is not possible to currently send an email on a specific ticket field change, such as closing a ticket,
and not other changes.
The following Access Policy rules control what notes are visible and added to a ticket:
Enable suppress email notifications when editing trouble tickets.
View hidden notes.
Change hidden notes status checkbox.
Automatically insert new note with every field change.
As hidden note.
Allow admin to suppress auto note add.
The above settings are the defaults for a standard User. So it is possible to ensure that end users can
see field changes occurring to tickets, provided:
1. You configure your admin role policies to Automatically insert new notes with every field
change, but not to add these as hidden notes.
2. You allow standard Users to View hidden notes.
In both instances, your Ticket Submitters will see field changes for fields which they do not
otherwise have access to, so you need to carefully consider if you want to make this available.
With these limitations in mind, if you do not receive an email as expected from a ticketing
1. Ensure that the suppress email notifications when editing trouble tickets is unchecked.
2. There is a known issue with regards to whether a ticket automatically created by an Alert
will subsequently send a notification email. This occurs or does not occur depending on what
alert is raised, and is not currently consistent across the product. Development are currently
investigating this issue.
3. Otherwise debug the issue as per No emails being sent, above.
Emails from Scripts not being sent
If there is a problem running the script, you should see one or more errors in the Script log. If there
are no errors, debug this as per No emails being sent, above. Note that the emails are sent from the
Kaseya server and not the agent you run the script on.
Emails from Reports not being sent
If there is a problem processing the report, the report name will never be replaced with a hyperlink
in the Schedule Reports page. Reapply the Schema, then log a support call indicating report
processing is not running correctly, make the report(s) affected public and include the names of the
reports in the support call you log.
If the report processes correctly, debug this as per No emails being sent, above.
Troubleshooting the Email Reader
Email Reader not connecting
If the status on the Email Reader screen is failed, it indicates that the POP3 reader on the Kaseya
server is not able to connect to the POP3 mailbox.
1. Click the View Log button. The log file should provide a detailed error explaining the
problem. If the View Log button is unavailable (on older versions of Kaseya), open the Email
Reader log, which is located at <Kaseya Install Directory>\KServer\KEmailReader.log, for
2. Some example errors:
a. wodPop3 Error: The current connection has timeout. – indicates that the port the
POP3 reader is connecting to is not responding. Confirm that DNS on the Kaseya
server can resolve the hostname you have provided and the port number of the
POP3 service is correct.
b. wodPop3 Error: Login ERROR: The service has not been started – indicates that the
POP3 reader could connect, and when it attempted to log on, it received the
detailed login error. In this instance, the POP3 service had failed on the Exchange
3. If you are unable to resolve this issue, raise a support call and provide the relevant section of the Email Reader logfile in the call.
Email Reader not creating tickets
1. Configure another POP3 client, such as Outlook Express, on the Kaseya server to connect to
the POP mailbox using the same details you provided. Configure this POP client not to
download emails from the server.
2. When the POP3 client has connected, Disable the email reader from the Ticketing tab >
3. Send an email to the mailbox which you have connected to from wherever the email reader
is unable to create tickets. This verifies that the email system up to the point of mail delivery
to the POP mailbox is working correctly.
4. Restart the email reader and connect to the mailbox from the Email Reader.
5. Verify that the email is downloaded and deleted by the Kaseya ticketing system. Provide the
relevant section of the Email Reader logfile in the call, which should include a log entry of
the form: 01/27/2009 05:03:04 1 Emails, 0 Tickets Added, 1 Tickets Updated