In recent versions of K2 installer team introduced a feature which blocks installation in case of critical failure leaving you no choice but address the issue and perform repair. It basically blocks all the other options leaving you with Recover as an only available option as shown below:
This option is here for a reason and unless you 100% sure that you need to exit out of this mode you should analyze error and perform repair, if necessary involving vendor support. But in case of throw away test box or initial installation you may want to unblock all the other option, let’s say to perform removal and start from scratch. To do that you just need to delete contents of the Setup State folder (default location is “C:\Program Files\K2\Setup\State”) which in this case will contain json files with the state of failed installation. Those files contain sections like “ComponentActions”, “FailedTarget”, “CompletedTargets”, but to the best of my knowledge support will ask you for installer trace to investigate any type of installer failures.
Like I said in case you understand what you are doing and need to exit out of “Recover” mode you can just use folder clear up approach explained above.
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=22.214.171.124, 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.