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 UPDATE [K2HostServer].[Identity].[Identity] SET [ExpireOn] = GETDATE() ,[Resolved] = 0 ,[ContainersResolved] = 0 ,[ContainersExpireOn] = GETDATE() ,[MembersResolved] = 0 ,[MembersExpireOn] = GETDATE() GO
And second option is to use Force Identity Service Refresh utility available at community.k2.com this one especially convenient if you need to perform more targeted identity refresh affecting only specific user, group or role. For details on how K2 identity cache works and how it can be tweaked you may read section of help.k2.com entitled “Tweaking identity cache performance for the K2 Server.“
Cache also stores information on roles membership and though methods explained above valid for the role there is also an option to do a role Refresh via K2 Workspace interface:
Workspace > Management Console > Workflow Server > Go to the process which uses the Role in question (Processes > [Your Process] > Roles) > Select the Role in question and click on Refresh
There is some evidence that this method may work out when two others didn’t as one K2 community article pointing out.
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.