Kaseya VSA - v5.x Email Configuration - Technical Support Guide














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:


Outgoing Email


1. Kaseya uses the built-in SMTP functionality of the IIS installation on the Kaseya server for

email delivery:


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.


Incoming Email


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


SMTP Delivery


Co-existence with other email products

SMTP Delivery Configuration

SMTP Service Configuration

Configure IIS Logging

Email Reader Polling


Troubleshooting Email Delivery

Reinstalling IIS SMTP

Internal or external mail recipients never receive an email

For external recipients not receiving email

Emails from Alerts not being sent

Troubleshooting the Email Reader

Emails from Notify Policy not being sent



SMTP Delivery


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

the email.


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 ( 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 for details.



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 for details.




2. Configure the Kaseya server to forward all email to another mail server – see 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

( for




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 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



The log entries will be of the form:, OutboundConnectionResponse, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 78, 0,

61, 0, 0, -, -, 220 ESMTP Exim Thu, 08 Nov 2007 22:47:59 +0000,, OutboundConnectionCommand, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 78, 0, 4,

0, 0, EHLO, -, chilli,, OutboundConnectionResponse, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 141, 0,

51, 0, 0, -, -, Hello chilli [],, OutboundConnectionCommand, 08/11/2007, 22:47:55, SMTPSVC1, CHILLI, -, 141, 0,

4, 0, 0, MAIL, -, FROM:<> SIZE=864,, 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 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

addressed correctly.

4. If no email appears in the IIS pickup directory, you have a problem with the processing of

alerts on the Kaseya server. See

for details.

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

functioning properly.



See for details.



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.


See for details.



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 for details.

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 for details.




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:


Assignee Change

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

hidden notes.


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.

To troubleshoot:


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

example C:\Kaseya\KServer\KEmailReader.log.


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




See for details.


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


To Troubleshoot:


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 >

Email Reader.


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

Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request


Article is closed for comments.