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=4.0.0.0, 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.
Once in a while you can bump into a warning from K2 Setup Manager which says: “The selected user needs to have Domain Users privileges to proceed” on K2 Site Application Pool Configuration which looks as shown below:
The selected user needs to have Domain Users privileges to proceed
I was not able to confirm what exactly triggers this, but I do know that it happens while specified user in fact has Domain User group membership and I saw it with both K2 4.6.x and K2 Five installers. Good news that bypass this blocking warning is easy – you just need to edit Product.config file in your installation directory and set domainusercheck value to false as shown below:
Setting domainusercheck key to false
You will need to restart K2 Setup Manager after saving this change and you should be able to proceed without receiving any any warnings.
The other day I’ve been doing installation of K2 4.7 on standalone (i.e. non-joined to domain) Windows Server 2016 machine with SQL Server installed locally on the same box, and bump into MSDT Network Access analysis result failure, receiving error shown below:
MSDTC Network Access Analysis Result: Failed
That’s quite a standard warning which explicitly says you what kind of check boxes you need to tick in Local DTC Properties (be sure to use comexp.msc or dcomcfg commands to open Component Services snap-in). K2 Setup Manager will explicitly tell you what checkbox is not set as shown on sample screenshot below:
Configuration Analysis reporting MSDTC options not configured correctly
But if you look at the first screenshot – there is no incorrectly configured settings, and I was pretty sure that I know these settings quite well, having couple of old posts on the topic (see #1, #2). So I was a bit baffled by this warning. After consulting related K2 documentation section I realized that it also indicates that it is necessary to configure relevant firewall rules :
Enable and Configure the DTC Components
Configure firewall to allow MSDTC access with the following command:
Configure firewall to allow SQL Server access with the following command: netsh advfirewall firewall add rule name=”MSSQLSERVER” dir=in action=allow program=”C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\Sqlservr.exe” enable=yes
These firewall settings must be activated on SQL server in order for MSDTC to work:
Despite in my case SQL and K2 servers very hosted on the side machine I tried to add required firewall settings – and, somewhat naturally, it didn’t resolve the error. So it took me searching a bit more till I found relevant MSFT documentation (New functionality in the Distributed Transaction Coordinator service in Windows) which clarifies that “No Authentication Required” option must be used in the following scenarios:
The network access is between computers that are running Microsoft Windows 2000.
The network access is between two domains that do not have a mutual trust configured.
The network access is between computers that are members of a workgroup.
As you can understand having both SQL and K2 on the same server in workgroup mode translates into “network” access is between computers that are members of a workgroup. So to resolve K2 setup manager warning in this scenario it is necessary to tick “No Authentication Required” option in Local DTC Propertis:
Local DTC Properties – No Authentication Required
I do realize that installation on a member server not joined to domain is not the most frequent scenario (although it is if you install K2 on cloud servers non-joined to domains), it is sad that K2 installer does not report what kind of setting is necessary in the workgroup mode scenario – that goes into nice to have list of additional checks, but until it’s not there you have this post 🙂
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:
Installation Cannot Continue – One or more roles were found that contain SmartObject results
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.
