Skip to main content


 

Symptoms

 


How to obtain a full logging of outgoing e-mails sent from K2 Host Server to Exchange? It seems that we have only SMTP exception lines in HostServer log which are returned by Exchange back to K2, but we need to see all outgoing e-mail details.
 

 

Diagnoses

 


There are two types of email sending implemented in K2:

 

 

 

1) Email Events. For mail event:

 

 

 

- This type of email sending uses generic .NET SMTP class. When email event is not working, check HostServer logs and there always something that able to give you more insights.

 

 

 

2) Tasks Notifications. For notification:

 

 

 

- This type of email sending uses MSMQ component. Two areas to check here:

 

 

 

(1) Check if there are any new error entries added to K2.Eventbus.ClientRecorderError table

 

(2) Stuck entries in EventBus queue (Computer Management -> Services and Applications -> Message Queuing). If there are any, you will need to clear the queue and restart MSMQ service.

 

 

 

To specifically address scenario "we have a huge delays in e-mail delivery in some cases and we need to exclude HostServer "fault" from this delay and transfer this problem at the Exchange admininstrators side for further analysis and resolution but before that we need to proof that we have no delays on the K2 side."

 

 

 

First of all, make sure that it is not process design type of problem. What you can do is just create dummy process with email event and/or default client event with notification enabled (depending on what you are using in your real process) and configured it to send email to me. Then I would start instances to see if there is any delays with delivery, again - delay means that there is nothing logged on K2 side without debug logging enabled, event was fired, next check your Exchange. But to further proof that you may enable logging level All and search for specific event confirming that K2 processed it - but it really will be difficult to find it as logging level All logs loads of stuff and what we have to look for will vary depending on whether you use email event or client event notification.

 

 

 

Alternative would be above mentioned dummy process + Network trace recorded on K2 side - you will be able to see how K2 server connects to your mail server there and specific timings, in a way it would be even easier to search as you have source IP (K2) and destination IP + port (Exchange/SMTP) to filter your trace. In quiet period/when K2 server doesn't send loads of emails you should be able to find what you want in network trace.

 

 

 

Just to make it clear - delays in delivery in most of the cases will occur on your Exchange/SMTP server as K2 does not perform actual sending. Please refer to the following KB describing how to do monitoring on that side: Possibilities for monitoring of outgoing emails sent by K2

 

 

 

From K2 side you will be able to see only failures in email evens/client notifications - successful sending is being logged only in DEBUG mode which you won't want to run constantly.

 

The only "delays with sending" on K2 may arise if your process is designed somehow to add delay or not fires related event - but this is not delay with sending it is process design issue. Other than that email related event either fires successfully (nothing logged on default logged level) and you have to further check on SMTP/Exchange server side as for K2 it is "end of the story" with this event or it will error out - this will be logged in K2 host server log - normally it will be something quite obvious wrong email address or non working MSMQ or something else - unfortunately I don't have full list of possible errors, but if you create such list, then SCOM monitoring can be used to track and report instances of such errors.

 

A lot of email sending errors logged on K2 side will be system wide - i.e. functionality stops working completely and it will be very difficult not to notice this problem. There is probably only one case I'm aware of where failure not logged on K2 and it also looks like no failure happens on Exchange side, please see this KB: Some escalation emails and email events not being delivered with no errors on K2 side

 

Issue mentioned above affects K2 4.6.9-4.6.11 and can be workaround either by increasing EWS throttling policy settings or by applying coldfix on K2 side. This issue resolved in 4.6.7. NOTE: This issue only appears if your K2 server sends out large number of emails simultaneously so that large number of them hit one of Exchange EWS servers (normally there is a farm of those) and hit EWS threshold configured. So it is not super frequent issue and you will see it only if number of emails sent by K2 simultaneously is larger than default EWSMaxConcurrency setting.
 

 

Resolution

For Task Notifications you may check two things:

 

1) Any new error entries in K2.Eventbus.ClientRecorderError table

 

2) Stuck entries in EventBus queue (Computer Management -> Services and Applications -> Message Queuing). If all clear there and message is delivered (albeit with delay) then it is safe to assume that delay happens on Exchange side.

 

 



 
Be the first to reply!

Reply