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.
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.
Under certain circumstances K2 requires forced user cache refresh (e.g. cache contains stale data due to recent changes or failed cache refresh during previous cache refresh cycle). This can be done by executing following SQL script against K2 database:
--Use this script with caution against large scale production installations
--Try to filter out things you trying to refresh instead of refreshing entire table
--For large-scale multi-domain environments full refresh may have performance impact
SET [ExpireOn] = GETDATE()
,[Resolved] = 0
,[ContainersResolved] = 0
,[ContainersExpireOn] = GETDATE()
,[MembersResolved] = 0
,[MembersExpireOn] = GETDATE()
When investigating issues with K2 identity cache you may see that valid and active AD user or group becomes disabled, i.e. gets its Enabled flag set to 0. It will occur whenever an identity can’t be resolved or when disabled in AD.
This could be due to a lot of reasons, but it comes down to the fact that it couldn’t be resolved – either it couldn’t be found because it doesn’t exist in the places it was looked for, or an error occurred while trying to get the details (think of weird characters in LDAP path, locked down permissions on some OU level etc.). The cause of error could be due to anything – either configuration or permission issues, or simply due to someone tripping over a network cable – The bottom line is, we didn’t get the required details back and thus disable the identity and this requires extra in affected environment.