Starting from K2 Five 5.1 ability to use SmO methods to populate/determine Role membership was removed and installer will block your upgrade process displaying the following error message:
Error message lists all roles which contain SmartObjects which have to be removed before you can proceed with upgrade (no installer restart required after removal) – this is clear and easy thing to do, and it is documented in KB002145. But in my case my upgrade to 5.2 was complicated by some other fascinating errors and hiccups, I’ll just list them: 5.2 installer was failing to start with unhandled exception (for some reason it didn’t want to work from non system drive / drive which was different from K2 installation drive), it was saying that my installation user does not have required rights (until run using K2 service account), in addition to that all UIs were broken with Invalid Archive type error.
The fact that UIs were broken yet I wanted to move on with upgrade (remove roles) required me to remove SmO from role(s) through the database modification, luckily in this case role membership entries are stored in quite plain and easily readable table – Identity.RoleItem where you can clearly see SmartObject name in FQN column (clearly differs from your regular users and groups in FQN form) with Type 4. To remove SmO from role you just remove entire line from that table, the only thing I would to add: make it your habit to backup K2 DB before you touch it, even if you are super-sure that you know what are you doing 🙂
I hope this information may save some one some time if you run into similar scenario and that’s it for now.
This blog post is just a short
walk-through explaining how to switch your K2 environment from Windows to Forms
authentication. Just to provide you an example of when you may want this – you
can use this configuration when you want to get password prompt on token
expiration while all your forms users working from domain joined workstations
belonging to K2 server domain (that means that STS token refresh will be
happening without any extra password prompts using existing Windows user
credentials to obtain STS token).
Required steps are described in K2 documentation (look under “Forms
Authentication”) but at the moment it does not mention some required steps
which we will cover here.
To switch over to Forms
Authentication you first need to navigate to K2 Management > Authentication
> Claims > Issuers section of K2 Management site:
There you can select K2 Forms STS and Click Edit button to enable “Use for Login” option of this issuer:
Once you enabled this option, switch
over to Authentication > Claims > Realms:
Here you need to edit every realm
and link K2 Forms STS issuers to it (depending on your needs you can do that
only for some realms):
Once you do that your realms should
have K2 Forms STS visible in LINKED ISSUERS column:
At this point if you restart your
browser and try to access K2 sites you will be presented with login method
selection which looks as follows:
If you don’t like this dialog or do
not need to use multiple logon methods just uncheck
“Use for Login” option for K2 Windows STS issuer, with such
configuration you will be getting immediate form authentication prompt on
attempt to access K2 site (and after K2 STS token expiration). This is how it
Up to now we were following steps
from K2 documentation and completed them but if you try to login with correct
credentials you may see the following error:
Error message has the following
Claim mapping configuration cannot be found for this claim. Claim information:
Name='DENALLIX\administrator', Issuer='FormsSTS', Original Issuer='FormsSTS'.
Please ensure that you have configured the K2 server as specified in K2 Help:
Installation and Configuration > Configuration > SharePoint >
tokenXml, ClaimsTokenType tokenType, ClaimsVersion claimsVersion)
sessionCookie, String tokenXml, ClaimsTokenType tokenType, String
connectionString, String authReqSource, ClaimsVersion claimsVersion)
This error and corrective actions to
it do not mentioned in product documentation. To fix this you have to do the
1. Edit K2TokenService.exe.config
located in “%K2_INSTALLATION_ROOT%\Token Service\Bin\” adding your K2
service and K2 application pool accounts into allowedCallers section as
Here is sample of allowedCallers section
2. Save your changes and restart K2
Claims To Windows Token Service aka K2WTS (you can use PoSh command for that –
After performing these steps you
will be able to logon to K2 sites using forms authentication.
K2 versions older than Five rely on MSMQ for task notification emails queuing and processing. Sometimes you may see the following scenario:
You start process which supposed to send task notification. Notification not delivered and there is no error messages logged nor in K2 host server log, MSMQ diagnostic log nor in Eventbus.ClientRecorderError table logged at the time of task assignment. Obviously process does not go into error state as notification delivery performed on “best possible effort” principle and not preventing user from completing assigned task using his worklist which can be exposed through different UIs. At the same time it is possible to see that queue exist and messages gets queued into it (Computer Management snap-in > Services and Applications > Message Queuing > Eventbus > Queue Messages:
If it is not highly loaded production environment you will be able to see that message gets queued per each client event, and you can also see that Message ID gets assigned with increment of 2, with new messages being added to the end of the queue. At this stage you may think that Message Queuing may not run – but this is unlikely as when this service stopped message cannot be placed into queue (that definitely will be logged on K2 side) and you unable to view Queue contents in computer management with the following error:
Other possibility is somehow malformed error message and some glitch in MSMQ service itself – again a bit unlikely as new messages gets queued just fine, but you can try Message Service restart along with removing topmost message from the queue. If that does not help (which most likely will be the case), check the very beginning of your latest K2 host server log (defalut location – “C:\Program Files (x86)\K2 blackpearl\Host Server\Bin”), to verify if it contains the following errors:
In case very beginning of your log contains these error messages:
“7030 Unable to create ‘dlx\EventBus’ queue : ‘Message Queue service is not available.'”
“7030 Unable to create ‘dlx\EventBus Error’ queue : ‘Message Queue service is not available.'”
“EventQueueProcessing.Main”,”7026 Unable to load EventBus Server”
This means that Message Queuing service on K2 server was not running at the time of K2 server start.
To resolve this make sure that Message Queuing service is up and running and restart K2 service – unfortunately there is no other way to reinitialize MSMQ processing thread which gets initialized on K2 service startup.
You may run into this situation after server reboot if K2 service started before Message Queuing service. To prevent this situation from happening you may want to configure K2 service startup to Automatic (Delayed Start) while keeping Message Queuing configured for Automatic start – that will add some delay to K2 service startup as it only will be attempted after all other services configured for Automatic startup will be started, but honestly I don’t see any problem with that – server reboot translates into downtime in any case and slight delay does not make any big difference here. Another, and possible more “fine grained” option to address this is to configure dependency on MSMQ service for K2. To do that run CMD windows in elevated mode and execute the following command:
sc config “K2 blackpearl Server” depend= MSMQ
After successful execution of this command the following dependency for K2 service gets created:
As per MSFT documentation this setting ensures than on machine startup services listed as dependencies are started before attempting to start service which depends on them.
You can find sample PowerShell script for starting multiple process instances in K2 Developer Reference, below you can find just slightly modified version which I am normally using. I’ve only added some variables to specify desired number of instances, project and workflow name along with folio value.
In certain scenarios (for example, when you changed your K2 administrative accounts) you may see the following error when trying to add or remove Environment Field in Environment Library:
This may happen even for user which has been assigned K2 Administrator role in Setup Manager when custom security was configured on Environment Library and it didn’t include this specific account.
To resolve this (providing you have account with administrative rights) just look into Security settings available under list of variables themselves when you navigate to Environment Library > %Environment Library Name%:
Just add required user assigning him Modify rights to resolve this issue.