Although my keep steep drop in amount of K2 posts from my side with more than high probability in the future, I’m keep jotting little things for now. The other day I was a bit perplexed by K2 Platform Classic setup manager which blocked me from adjusting K2 service account like that:
What it actually does is forcing you to use currently logged in user. And addressing why part it happens when you have developer license – in that case setup manager forces you to use currently logged in user as a “service” account (remember that Developer license requires you to run your K2 service in a window within interactive user session). Just though it may be useful to write this down and share.
In some scenarios you may have empty K2 roles with no users added, and in the past it was possible to create new role in K2 Management without adding any users into it or delete all users from the role (this is not the case in current versions of K2). When you have K2 role with no users K2 will be logging error shown below on each attempt to resolve this role (look at Interval configured for this role in DestQueue table to get an idea about error frequency, and the same will be logged every time when role used as a destination etc.):
“1 The K2.net 2003 Destination Queue SecurityLabel provider ” does not exist at K2DestQueue.RunDestQueue(Object obj)”
To address/remove that error you need to identify empty role first which can be done with help of the following SQL query run against K2 DB:
Once empty role identified you either delete it or add some user into it to get rid of error message, or as a third option you can increase its refresh interval in DestQueue table to decrease frequency with which this error will be logged in K2 host server logs.
When you run current versions of K2 Setup Manager it saves trace file in %temp%\K2 Setup Log directory and you may also find trace files in your K2 installation directory in Setup\Log subfolder. Trace files which you can find there named InstallerTraceDDMMYYY_N.log. Quite often it is necessary to confirm what mode (Install, Upgrade, Configure, Repair) was selected during last run of K2 Setup Manager. To do that based on installer trace you need to search trace files entries containing this string:
Last entry will tell you selected mode – Configure, Install etc.
Hopefully this tip can save you some time or clarify doubts on what action was selected during last run of K2 Setup Manager.
This is a bit of a blast from the past type of post, but I would write about this anyway.
In 4.6.11 you may observe the following error logged on K2 service startup:
“Error”,”System”,”2010″,”TypeLoadError”,”SourceCode.Hosting.Server.Runtime.HostTypeLoader.LoadHostableTypes”,”2010 Type Load Error, Method ‘get_DisplayName’ in type ‘SourceCode.Hosting.Runtime.Group’ from assembly ‘SourceCode.Hosting.Runtime.IdentityService, Version=184.108.40.206, Culture=neutral, PublicKeyToken=16a2c5aaaa1b130d’ does not have an implementation.”
This error gets logged on K2 service startup and only in case you have certain rollups/coldfixes in place – it does not appear if you use 4.6.11 RTM.
This error can be caused by by the presence of SourceCode.Hosting.Runtime.IdentityService.dll in “C:\Program Files (x86)\K2 blackpearl\Host Server\Bin\HostedServers” – whereas this file is only supposed to be located in “C:\Program Files (x86)\K2 blackpearl\Host Server\Bin\HostedServices”. It’s a very good example of pitfalls related with use legacy K2 patching model involving manual files replacement – error prone and slow process. Luckily starting from 4.7 there are CU and FP with which installers almost fully addressed such type of problems.
I recently run into interesting issue with K2 4.7 – non working K2 Designer was displaying the following error:
The server is not licensed (MachineName: , MachineCode: ).
(values for Machine Name and MachineCode are removed from the sample error message text above, but the latter value was system key).
Interestingly Licensing section of K2 Management was showing 2 licenses in good standing (Blackpearl and SmartForms), but if I remember correctly System Key mentioned in error message in K2 Designer was associated with blackpearl key. Long story short client somehow end up entering/applying SF license key against blackpearl system key – not sure exactly how it was possible and where K2 4.7 is not full proof enough, but resolution here was basically request new license key and apply SF one through SF Setup Manager, and then do the same for blackpearly using BP Setup Manager. In my case environment was using trial keys, but I can’t tell for sure if such problem can only occur if you use trial keys.
I’ll just leave this here in case someone run into the same error.