Introduction

When doing a search to add users / groups as participants in the process, the method used to return the search results may result in the specified user not being returned immediately and it appears as though the specified user cannot be found even though they may be known to be in Active Directory.

Error Scenario

When starting a process from within SharePoint, the user added at runtime cannot be matched to an existing user as shown in the image below. This scenario is known to occur when Active Directory has hundreds or thousands of users where user naming may be very similar for example TestUser1, TestUser10, TestUser11 and so on.
When the URM service searches for users within Active Directory, the default setting is to search based on a Starts With criteria and only the first 100 users are returned. This method of searching also returns users based on when they were created in Active Directory from first to last.


 
Even though the user page reports that the user does not exist the user does, and this can be verified by browsing for the user as shown below.


 

 
The primary cause of this error message is system settings that need to be changed to cater for an Active Directory installation where the number of users is very large and the service used to report on the user name has been set to only return a limited number of users. This can be changed by refining the searches by making changes to the manner in which the results are returned.

Performance Resolution

This performance issue can be resolved by making changes to the URM Service (Service Instance of URM Service) which controls the manner in which users are returned to user list.

Note: Making changes to the default settings may change the overall performance of the page when returning users.
Database SettingDescription
 FindUsersDefaultFilter > groupname=null;size=100 The “size=100” will limit any searches done using the URM SmartObjects to 100. So if you have a VERY large AD, you need to either make this bigger or ensure your searches are refined.
 ADUM (RoleInit XML column in K2HostServer DB  SecurityLabels table). Defaults are in ().
 ADCache (10 mins) > Time in minutes. Time that a USER object is stored in memory. This includes group membership for that user. Can be increased if AD not changed often. Can cause memory issues though if made too long and large volume of users use K2.
 ResolveNestedGroups (false) Will resolve nested groups as well. This can have a significant performance impact if you have a complex AD structure. Will be ignored if IgnoreUserGroups is set to True.
 IgnoreForeignPrincipals (false) Will attempt to resolve foreign security principals. Is ignored on a Single domain install.
 IgnoreUserGroups (false) If set to True, will not resolve any groups the user belongs to on “GetUser” call.
 MultiDomain (false) Need to be set to True on multidomain installs.
 OnlyUseSecurityGroups (false) Works in conjunction with IgnoreUserGroups. If set to True, will only resolve security groups. Distribution groups will be ignored. Considerably faster than resolving Distribution groups as well.

Recommended Settings

The following settings are recommended, however since each environment is considered to be unique, the systems administrator may need to adjust the recommended settings or verify their viability before implementing them on an active production system.

Note: The configuration settings are split between two locations namely the [K2HostServer].[dbo].[SecurityLabels] database table and the K2 Workspace Management Console user page.

The following settings can be amended via the ADUM RoleInit table from the K2HostServer Database

  • ResolveNestedGroups=False
  • OnlyUseSecurityGroups=True
  • IgnoreUserGroups=False
  • IgnoreForeignSecurityPrincipals=False

The settings below can be set via the K2 Workspace > Management Console > URM Service

  • Retain the value of 100 for the FindUserDefault setting

[E]