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
- Repair
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
- MSMQ
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.
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.
After that,
- 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