KB000165

Introduction

This document will help K2.net administrators and developers better understand the conditions affecting their K2.net 2003 Named User License (NUL) systems. The most common symptom of exceeding NUL conditions is when the following dialog box is displayed:

Although this condition can affect development and testing efforts, understanding why this message is being displayed and how to address the conditions can reduce the impact of exceeding the NUL limits.

Common Misconceptions about K2.net "Named User Licenses"

The items listed below clarify some common misunderstandings about K2.net NULs:

1. NUL conditions are not determined by the number of K2.net Studio applications installed
2. NUL conditions are not evaluated at 'design time' - they are determined at 'run time'
3. NUL conditions are not based on K2.net Service Manager Permissions (Start, View, View Participate, etc.)
4. NUL conditions are not based on the number of K2.net server installations (i.e. when K2.net is installed on separate Dev, QA, and Production machines)
5. NUL conditions are determined at 'run time' based on Destination users involved in all active processes

Examples of how K2.net 'Named User' Licensing allocations are determined

The most common environment affected by the NUL condition is on Development servers. In most cases, 10 licenses is a very low number of users to realistically be involved in many testing scenarios, especially when their Production server uses a CAL or CPU licensing model allowing an unlimited number of users.

Customers most often use their Production AD environment for testing use of Destination Groups/Queues. Because a single production AD group associated to Process Activities will typically contain more than 10 unique destination user accounts, when multiple AD Groups are used across all active instances, a 10 NUL limit is quickly realized. Unfortunately once the error is encountered, it halts further testing. developers must then delete enough process instances to get back within the license limitations which is very disruptive.

Always think of each UNIQUE Destination User account being applied against the K2.net NUL limit regardless of the number of process instances. If a User account is defined as a Destination User for more than one ACTIVE process instance (regardless of the number of Process definitions or Process instances), they only count as one NUL license.

Scenario - Active Directory Groups and K2.net Processes

For this example, consider a system where you have a 10 Named User License (NUL) model and have two Active Directory Groups ("Group A" and "Group B"). Each group has some users unique to each AD group, but there are also some users (Users 6, 7, and 😎 common between the two groups.

The steps listed below explain a common evolution of processes, from design to the generation of instances, which involve K2.net 2003 NUL considerations.

1. Design Time use of Active Directory Groups in K2.net Processes/Activities
   
   Let's say you have three K2.net Process definitions (X, Y, Z) with 1 Activity each (Process X has Activity "X1", Process Y has Activity "Y1", and Process Z, "Z1"). Each process activity can potentially involve either Group A and/or Group B users as Destination Users. Process X has 2 users added outside of using either group (Users 9 and 10).
    
2. Run time Evaluation/Determination of NUL conditions
   
   A new process instance for Process X is launched and loads Activity X1 which includes 10 unique Destination Users: 8 users (Users 1-8) defined in Group A and two explicitly defined user accounts (User 9-10). The K2.net NUL limit will be reached, but not exceeded (therefore, no licensing error).
    
3. Processes Involving Users already counted against NUL
   
   Next, a new instance of Process Y loads Activity Y1 and involves only User 6, User 7, and User 8 as Destination Users. The K2.net license limit will still not be exceeded since these users are already defined within the previous Activity (X1) as part of the original 10 Destination users (no additional unique users).
    
4. New 'Unique' Users added - NUL Conditions Exceeded
   
   However, if Process Z is loaded that has Activity Z1 (which creates Destination Users based on Group B), then the additional users (Users 11-15) will trigger the K2.net licensing limitation message since the number of unique users has been exceeded (over the 10 user limit). Destination Users "User 6" thru "User 10" will still be receive their tasks, and only when K2.net generates tasks for the 'new' unique destination users (Users 11-15) will the NUL error occur.
    
5. Recovering from NUL Exceeded Conditions
   
   K2.net will keep track of the unique accounts and as Processes are completed, K2.net will re-evaluate the user counts at specific time (this is proprietary information however).

To get at or below the limit, you need to delete process instances containing enough unique destination users to get back within the licensing limits. The unique user list is re-evaluated after the K2.net Service is stopped and re-started. If a process has completed, the users are removed from the licensing count after a K2.net Server re-start.

Planning Ahead for Processes to Dynamically Adjust for NUL conditions

There are ways to plan ahead for such NUL conditions. Doing so requires building the functionality into each Process's Activity and the use of String tables. Please refer to KB000163 for details.