I had been challenged with a major issue. K2 workflows never sent mails. Not via the inbuilt notification for events, or via the “send Mail” activity.
Now the K2 server had been integrated with MS Exchange 2013. From these servers, mails could be sent and received via OWA. However, they never get sent from a K2 workflow.
Find below what I did to resolve this issue.
Steps I carried out OVER AND OVER AGAIN.
I had run
- Configure – re-configure
On k2 black pearl setup manager and when it prompted for the exchange integration I had input the correct EWS url, "from address", and even tested (which passed) for auto discover.
I had inspected the ConnectionStringEditior.exe located at “C:\Program Files (x86)\K2 blackpearl\Host Server\Bin” to ensure the entries were correct.
I copied out the K2HostServer.exe.config file, and inspected the values to be sure the “from address” was not wrongly registered.
None of the above seemed to resolve the issue.
It so happened that my problem had two major culprits.
- Environmental fields
Before now, I resolved to enable exceptions whenever notifications and emails were sent in workkkflows. However I now decided to log them to the event log and server. I found from the error logs, that the “From Address” was actually wrong.
It complained of “mailId@DomainName” (, rather than mailID@DomainName.DomainSuffix) not having a “Send on behalf of” permission on exchange.
Since I was sure I had the correct mail input in K2 Black pearl setup manager, as well as it rightly represented in the connection string editor, I was prompted to look into K2 workspace manager.
From K2 workspace, I navigate thus:
ServerName > Environment Library> Templates > Default templates >Environments > Development/Production >Environment fields
There I corrected the “from address” and redeployed the workflow. That resolved the issue with workflow “Email Event” not sending mails.
Here ended culprit number one.
Notifications still yet to be sent
There however was another issue on ground, notifications not being sent. K2 notifications are handled by the Message Queuing service. Over the time, I kept getting error events in the event logs as regards message queuing. Always unable to create queues (which are meant to push the notifications)
At the final analysis of configuration manager being run all the time, I get an error on MSMQ
“Message Queuing Enabled
Analysis Result: failed
MSMQ Directory Service Integration has been detected on this system
MSMQ Workgroup flag in the registry is incorrect, its value should be 0 for domain machines”
We always went and changed the registry value (which can be found at Computer\HKLM\Software\Microsoft\MSMQ\Parameters) from 1 to 0, but realize it always swung back to 1, and re-analysis always failed. I tried changing from public queues to private queues. That also was as futile as changing the workgroup values, as it always switched back to public. It was almost like a crazy loop of dead end.
In all that is done, it happens that the system runs MSMQ in workgroup rather than domain mode. That’s to say that, MSMQ thinks the computer is a workgroup system(funny ain't it?), while K2 knows the computer is a domain computer. So there went the confusion.
The explaination to this is that that MSMQ was installed before the machine(which was theen a workgroup) was promoted to a domain computer. Hence, there went the “message queuing” culprit that stalled all notification mails. So I granted the NETWORK service full control in AD users n computers.
How to grant Network Service full control
- Open AD Users and computers
- Expand your domain node
- Click on “domain controllers”
- Right click computer name, select “properties”
- Select security tab, under group or user names, add NETWORK SERVICE, and grant full control.
- I uninstalled MSMQ,
- Restarted the machine,
- Restarted it again when the second stage of uninstalling was complete. (I skipped this step severally, and had to perform the entire operation over and over without success)
- Then I installed back the MSMQ.4.
Now the registry value was corrected as 0 (Logic: you can never manually change this value, it automatically changes at each restart. You have to make sure the value is registered correctly at MSMQ installation).
After that, I went back to environment settings and made the “from Address” the default (rather than “mail server” smtp address).
Immediately this was done, the notification mails were sent.
There ended culprit number 2