Question: What to do when the maximum number of licensed users has been reached?

rated by 0 users
This post has 7 Replies | 3 Followers

Top 100 Contributor
Posts 49
Points 106
sirwally Posted: Fri, Oct 17 2008 11:52

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?

Top 10 Contributor
Posts 817
Points 3,408
chrisg replied on Fri, Oct 17 2008 12:20 PM
Do you know what version of bp you are using?  I had thought that the problem you are experiencing was fixed.
  • | Post Points: 7
Top 25 Contributor
Posts 272
Points 904
tbyrne replied on Fri, Oct 17 2008 1:43 PM
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!
Tim Byrne Clarity Consulting http://www.claritycon.com
  • | Post Points: 1
Top 100 Contributor
Posts 49
Points 106
sirwally replied on Fri, Oct 17 2008 1:52 PM

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).

  • | Post Points: 1
Top 10 Contributor
Posts 1,064
Points 3,286
johnny replied on Sun, Oct 19 2008 8:38 PM

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.

  1. "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.
  2. "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:

  1. Shutdown your K2 Host Server service 
  2. Backup the Actioners table
  3. Delete the records in the Actioners
  4. 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.

  • | Post Points: 4
Top 100 Contributor
Posts 49
Points 106
sirwally replied on Tue, Oct 21 2008 12:25 PM

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.

  • | Post Points: 4
Top 10 Contributor
Posts 1,064
Points 3,286
johnny replied on Tue, Oct 21 2008 8:16 PM
No worries, I believe this is a known issue and has been logged to be fixed.
  • | Post Points: 1
Top 10 Contributor
Posts 1,064
Points 3,286
johnny replied on Tue, Jun 8 2010 9:33 PM

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], [ActionerName]
From     _Actioners
Where  [ID] Not In (
                                Select    [ActionerID]
                                From     _WorklistSlot
                ) And
                [ID] Not In (
                                Select    [ActionerID]
                                From     _ActionActInstRights
                )

  • | Post Points: 1
Page 1 of 1 (8 items) | RSS