This month I wanted to elucidate clearly about configuring Work Order Event Notifications when email in your organisation is hosted in Office 365. I’ll also touch on more general notification troubleshooting advice which is valid if you use a mail solution in The Cloud or host your own.


Work Order Event Notifications and Office 365

The conversation we have in support with customers whose email solution is in the cloud is usually along the lines of “Office 365 requires TLS encryption but Track-It! only supports SSL”. I found a white paper, here, which confirms this;


“The use of TLS/SSL establishes a highly secure client-to-server connection to help provide data confidentiality and integrity between the desktop and the data center. Customers can configure TLS between Office 365 and external servers for both inbound and outbound email. This feature is enabled by default.”


If we go to the outbound email configuration, in Track-It! 11.2 this is in;


Tools > Administration Console > Configuration > Administration > E-mail Configuration > Outgoing E-mail Configuration


… indications are that this is not possible. There is not an option listed for a required TLS encrypted connectection (1).

outgoing e-mail configuration.jpg


This appears to be borne out when using the “Send Test E-mail” (2)and the resulting test email fails to be sent to it’s recipient.


Let’s try and clear some of this up.


Authenticate on your SMTP host but do not check the box for SSL and apply the changes. If you choose to click the Send Test E-mail and it fails, do not be disheartened. This is because this button is not using the configuration you have entered in this screen. It is checking whether it is possible to send a message via the SMTP host you have configured but it is doing that using the email settings associated with the Windows account you are logged into the computer with.


So in this scenario, please use this guideline to test your connection to your Office 365 SMTP host… once the above is setup and you have ensured that Track-It! is set to send these messages by its schedule - Tools > Administration Console > Configuration > Help Desk >  Work Order Events > Automated Schedule, then create a test Work Order and send a mail to your designated test recipient via the “Email Requestor” button.

email requestor.jpg

We usually find that notifications are sent successfully using the configuration and test outlined above.

Nb – If you have Track-it! configured to “Email Requestor” via your Outlook client, you will need to test outgoing email by matching a Work Order to the Event Policies.


If you continue to struggle with this setup and wish to engage with your local Support team its really useful for us to have a copy of these logs if you have encountered errors while testing;


More General Notification Troubleshooting via the Track-It! Database

While I am on the subject of logs and Notifications, I thought I would quickly share some bits and pieces about where the Notifications register on the Track-It! database. I have learned to rely on these tables when troubleshooting more challenging notification issues.


Open SQL Server Management Studio and connect to the instance where the Track-It! database resides. Expand it in the Object Explorer and then expand the Tables. Scroll down to the “N’s”.


There are three tables I will summarise in this post, NotificationMessage, NotificationStatus and NotificationError.


NotificationMessage contains a line for every notification email that was sent from Track-It!. For the purposes of today’s post, we are concerned with the NotificationStatusId column.



This is the “Automatically generated primary key of the NotificationStatus table”. Essentially, depending on whether the message is in the process of being sent, gets sent successfully, or fails, the NotificationStatus table holds the various statuses that are entered to this column. It is useful to cross reference NotificationMessage with NotificationStatus;



… so if you see a NotificationStatusID of 4 in your NotificationMessage table, you can see that this means “SendFailure” and that will prompt you to look at the NotificationError table;



Obviously, the NotificationMessageId column correlates to the message in the NotificationMessage table. It is easier to insert the cursor into that row’s ErrorMessage entry and select all its contents, copy and paste into Notepad or similar, rather than trying to read the error in SQL Server Management Studio. Here’s some examples;


The requested notification message failed to send. - The SMTP host was not specified.


The requested notification message failed to send. - Mailbox unavailable. The server response was: 5.7.1 Unable to relay for


These errors may match to errors posted to the Service Management log file in C:\Windows\Temp but this method provides an “electronic paper trail” where you can follow through each step of the way for a specific message, rather than scrolling through up to 10 MBs worth of event logging, much of it not relevant to the errors you are looking for.


  Well that’s it for now but I will be posting again quite soon. I wanted to cover Track-It!’s Rich Text editor for Solutions and Resolutions, which some customers are finding irksome. So I will write that up over the next week or so. I just thought it was confusing to have two unrelated topics in this post. I will also be posting Part 3 in the series about Track-It! reports in the coming weeks. I would appreciate any comments to any of my posts, especially if there is anything you would like me to try and explain… I might even be able to coerce a colleague with a bit more specialist knowledge in that particular area to assist us!