Skip to main content

For reference this is on our DEV server, so it is a 10 named user license.


I thought this would be easy.  This is what I did, but I _still_ can't initiate a new process instance (they all enter an error state because the server keeps telling me that we have reached the maximum number of licenced users). 


1) In the workspace I went to License Management > Licensed Users and removed all users who don't need access to our DEV enrivonment.  This didn't help.  I restarted the service and it still didn't help.  There were 10 and now there are 5.


2) I removed all active process instances for all processes.  This didn't help.  I restarted the service again and it was still a no-go.


3) I removed all users except myself and a couple of testers from the roles defined in the workspace, restarted the service...no help.


Between server rights, process rights, roles and Licensed Users we only have 8 unique users.  It is my understanding that you can go over the number of licenses a little bit (about 10%, or 2 users, I forget -- not many at any rate), so we should be able to hit about 12 users.  At this point I can't do any work.  The process I am starting assigns a workitem in the first activity to 2 roles and a single user.  At this point I am the single user, and I am the only member of the two roles, and I am a licensed user.  I don't get it.


On a side note, you lose at least 1 or 2 of the user licenses to the service accounts which is fair enough, especialy given the allowable overrage (if that is indeed true).


Anybody have any ideas?

Do you know what version of bp you are using?  I had thought that the problem you are experiencing was fixed.
I had experienced that same problem pre-0803, since then the steps you took are the correct steps to rectify the problem.  Please verify the version you are running.  Thanks!

The other licensing problem we ran into was resolved (it was due to the home drive defined for service account being a network drive, which caused a problem when determining what the system key should be).


We are using the latest release -- K2 blackpearl 0807 (4.8210.2.0).  We just upgraded the DEV server last week, and went straight from 0803 (we skipped 4.8210.1.0).

At this point, there is an issue with the K2 license management panel as it only shows Form user licenses.


There are two types of licenses.




  2. "Form" license - Users who connect to K2 server (Regardless of whether they participate in the process or not).  Any connections made to the K2 server will be logged as a form user.  e.g. to submit a new workflow request.



  3. "User" license - "User" licenses are calculated from users participating in the workflow.



The total number of users is calculated both from "Form" and "User" licenses.  For "User" licenses, this is calculated from the Actioners table. 


If for some reason, there are invalid entries in the Actioners table, this might cause your K2 dev server to hit the license limit.


 What you can do is:



  2. Shutdown your K2 Host Server service 
  3. Backup the Actioners table
  4. Delete the records in the Actioners (see query in the bottom post)
  5. Start your K2 Host Server service

This will cause the K2 server to recreate the Actioner records again based on the destinations in your active processes.

Clearing out entries in the _Actioners table solved the problem.  Thanks!


On a side note, are there plans to add support for clearing Actioners from the workspace?  It's not really a problem in a production environment if you have a CPU license, but for small organizations this could become a problem if they have high turn-over as old employees will clog up the _Actioners table.  Perhaps a way to cross-reference those entries with people that have process rights.  I am curious why licensing is affected by this, though.  If a user has no process rights an entry in the _Actioners table does nothing other than take up a license slot (it appears).  I'm sure SourceCode has a good reason for it working this way and I am not seeing the bigger picture.

No worries, I believe this is a known issue and has been logged to be fixed.

Just to add on to my previous post.  Clearing the entire _Actioners table is not the correct method as there might be linked worklistitems.  This can cause worklistitems to get orphaned.


The following query gets the entries that can be safely cleared.


Select    ÂID], IActionerName]
From     _Actioners
Where  /ID] Not In (
                                Select    ÂActionerID]
                                From     _WorklistSlot
                ) And
                 ID] Not In (
                                Select     ActionerID]
                                From     _ActionActInstRights
                )

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings