URM Service Issue

  • 10 June 2015
  • 6 replies
  • 14 views

Badge +6

When I execute the URM Service's "Find Group Users" method call on one K2 server, I get results for all users who belong to whichever group I provide.  When I execute the exact same call using the exact same group on another K2 server -- this server is in the same domain as the other K2 server that I just mentioned -- I get only one result.  Is there a setting that needs to be provided?  Both servers have the exact same K2 build (4.6.8).


6 replies

Userlevel 1
Badge +8

Hi cjmoran

 

I am assuming that your 2 K2 servers are for different environments (e.g. Dev and Test) and you are using the default AD User Manager.

 

The URM uses the K2 Identity Service, which is a cache that is refreshed on regular intervals. It may be that the cache in one of your servers needs refreshing.

 

Try running the following script agains the K2 database on the affected server (this is taken from the Help file link below).

 

 

UPDATE [Identity].[Identity]
   SET [ExpireOn] = GETDATE()
      ,[Resolved] = 0
      ,[ContainersResolved] = 0
      ,[ContainersExpireOn] = GETDATE()
      ,[MembersResolved] = 0
      ,[MembersExpireOn] = GETDATE()
 
GO

 

http://help.k2.com/onlinehelp/K2blackpearl/ICG/current/webframe.html#User_Manager_Introduction.html

 

 

Badge +6

After I ran the script on the affected server, I executed the method call.  I received no results.  Before I ran the script, I received one row of data.  I waited a day before executing the method call again.  This time, I received only one row of data (the same data I received before running the script).

Userlevel 5
Badge +18

I assume the K2 blackpearl service/console mode is running under a different service account in each environment?  Perhaps there is a difference in AD permission between the two service account?


 


How does the single user that is returned compare to the users that do not get returned in terms of OUsCNs?  Perhaps the different K2 service accounts was denied read access to those objects.


 


Does that group have nested group?  Perhaps it is this nested group setting:


http://help.k2.com/onlinehelp/k2blackpearl/userguide/current/webframe.html#k2_um_settings.html

Badge +6

Tin -

 

Yes, each K2 service is running under a different service account in each environment. However, both accounts have access to AD. 

 

So.  The server on which I'm running into issues uses Service Account #1.  The server on which I'm not running into any issues uses Service Account #2.    If I run the SmartObjects Tester tool as Service Account #1 on the server that doesn't have any issues, I get the expected results.  When I run the tool using the same account (Service Account #1) on the server on which I'm running into issues, I get only one result (my account info - FQN, Username, etc).  My user account has the same OUCN as every one else's.

 

The group does not have nested groups.

 

I ran a query on the SecurityLabel tables on both servers.  I found the following difference:

 

Server with no issues: ResolveNestedGroups=False;IgnoreForeignPrincipals=False;IgnoreUserGroups=False

Server with issues: ResolveNestedGroups=false;IgnoreForeignPrincipals=false;IgnoreUserGroups=false

 

Note "False" vs "false".  Don't know whether case-sensitivity is an issue here.  I assume it isn't.

 

Craig

Badge +6

I notice that every time I run the update script to refresh the cache table, I get either a) no results when I run the SmartObject's Find Group Users method or b) a single result that differs from the result that was returned to be before I ran the update script.  Could the issue be SharePoint-related?

Userlevel 1
Badge +8

I don't think SharePoint will be the issue here, as we are only looking at AD groups.

 

There is a table in your K2 database called [Identity].[Identity], which is the cache that the Identity service creates and updates. Perhaps compare the data in this table for your 2 environments and see if there is any notable difference. Short of that I would probably contact K2 support.

Reply