To clarify

You said

The only thing that seems to work is adding individual user's to processes, once we do that they can start workflows.

Does this mean that if you assign the "domain users" group to have rights it does not work. But if you assign them directly meaning domainuser it works?

Just curious if other AD groups would work.  To test just create a group and add some users to it to see if it does.

The only thing i can think of is some kind of a domain issues were for some reason we cannot verify the users group membership, or some kind of time out.

Is this a large domain?

Hi Chris,

You are correct, just having all "domain users" with start rights won't allow anyone to start a process.  If we go in an add individual users (domainuser) and give them start rights, they can then start the process.

We thought about other existing ad groups (webdev group for example) and that still didn't work.

It is a medium sized domain (depending on what you consider large).

We do have a custom AD service that was created before I came on site, it just extended the original AD service to return some additional fields back from AD.  We tried recompiling and refreshing that service instance through the service broker but no dice there either.

It does seem like there is some problem with it not being able to resolve a user's group membership, any ideas on where I can look at next?  The client is getting pretty upset and I am trying to quell the potential storm that is coming.

Thanks!

Of course ;]

Now let me state, I am a .NET dev with only 2 years under my belt so far, I have no clue how to do a network trace.  They do have a system's team and a network team here, but I woudn't know what I am looking for myself.

Here is the weirdest thing though.....

I am able to submit any workflow fine, as far as my permissions go with the K2 workspace and start processes:

• 
  
• I am a workspace admin (as is one of the client site employees)
  
• The only 'item' with start rights for all the processes is the AD group of "domain users"

Some other interesting tidbits that just came to light -  it seems like some people are actually able to submit the forms without any issues.  However the bulk of users aren't able to start a process unless we add them in the workspace and give them rights to start the process.

Good morning all, here is some info from the 2 logs on our K2 Server, perhaps this might help some.  The HostServer.log file is particularly interesting, it appears the problem might be related to the UserRoleManager?

From HostServer.log file

"5543594","2008-10-10 10:44:44","Debug","UserRoleManager","5003","GetUser","URM SERVER GetUser]","5003 Username: K2:daominuser , extraData: null","anonymous","0.0.0.0","bpserver:d:program filesk2 blackpearlHost ServerBin","5543594","1f397bd103ac438cb013635cf33fa3cf",""

"5544046","2008-10-10 10:45:03","Info","UserRoleManager","5002","Initializing","URM SERVER Init]","5002 Default label name K2","anonymous","0.0.0.0","bpserver:d:program filesk2 blackpearlHost ServerBin","5544046","89061e62e6ff4ebc869730aefa3378c5",""

From K2Error.txt file

10-10-08 10:46:52    User.Load: Add failed. Duplicate key value supplied.
   at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.RemoteCall(String TypeName, String MethodName, ObjectO] Parameters, Booleano] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteCall(String TypeName, String MethodName, Object,] Parameters, Boolean ] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteSessionCall(String TypeName, String MethodName, Objectm] Parameters)
   at SourceCode.Security.UserRoleManager.Client.UserRoleManagerServer.FindGroups(String userName, IDictionary`2 properties, String labelName)
   at SourceCode.Security.K2UMIInterop.K2UMIWrapper.FindSecurityGroups(String User, String Name, String Description)
   at SourceCode.KO.User.Load()
10-10-08 10:46:52    User.GetAllRights: Add failed. Duplicate key value supplied.
   at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.RemoteCall(String TypeName, String MethodName, Objectn] Parameters, Boolean]] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteCall(String TypeName, String MethodName, Objectr] Parameters, Booleant] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteSessionCall(String TypeName, String MethodName, ObjectS] Parameters)
   at SourceCode.Security.UserRoleManager.Client.UserRoleManagerServer.FindGroups(String userName, IDictionary`2 properties, String labelName)
   at SourceCode.Security.K2UMIInterop.K2UMIWrapper.FindSecurityGroups(String User, String Name, String Description)
   at SourceCode.KO.User.GetAllRights(String name)

Good morning all, here is some info from the 2 logs on our K2 Server, perhaps this might help some.  The HostServer.log file is particularly interesting, it appears the problem might be related to the UserRoleManager?

From HostServer.log file

"5543594","2008-10-10 10:44:44","Debug","UserRoleManager","5003","GetUser","URM SERVER GetUser]","5003 Username: K2:daominuser , extraData: null","anonymous","0.0.0.0","bpserver:d:program filesk2 blackpearlHost ServerBin","5543594","1f397bd103ac438cb013635cf33fa3cf",""

"5544046","2008-10-10 10:45:03","Info","UserRoleManager","5002","Initializing","URM SERVER Init]","5002 Default label name K2","anonymous","0.0.0.0","bpserver:d:program filesk2 blackpearlHost ServerBin","5544046","89061e62e6ff4ebc869730aefa3378c5",""

From K2Error.txt file

10-10-08 10:46:52    User.Load: Add failed. Duplicate key value supplied.
   at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.RemoteCall(String TypeName, String MethodName, ObjectO] Parameters, Booleano] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteCall(String TypeName, String MethodName, Object,] Parameters, Boolean ] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteSessionCall(String TypeName, String MethodName, Objectm] Parameters)
   at SourceCode.Security.UserRoleManager.Client.UserRoleManagerServer.FindGroups(String userName, IDictionary`2 properties, String labelName)
   at SourceCode.Security.K2UMIInterop.K2UMIWrapper.FindSecurityGroups(String User, String Name, String Description)
   at SourceCode.KO.User.Load()
10-10-08 10:46:52    User.GetAllRights: Add failed. Duplicate key value supplied.
   at SourceCode.Hosting.Client.BaseAPI.BaseAPIConnection.RemoteCall(String TypeName, String MethodName, Objectn] Parameters, Boolean]] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteCall(String TypeName, String MethodName, Objectr] Parameters, Booleant] NullList, MarshalMessageType CallType)
   at SourceCode.Hosting.Client.BaseAPI.BaseAPI.RemoteSessionCall(String TypeName, String MethodName, ObjectS] Parameters)
   at SourceCode.Security.UserRoleManager.Client.UserRoleManagerServer.FindGroups(String userName, IDictionary`2 properties, String labelName)
   at SourceCode.Security.K2UMIInterop.K2UMIWrapper.FindSecurityGroups(String User, String Name, String Description)
   at SourceCode.KO.User.GetAllRights(String name)

This sounds like the duplicate key issue in the initial installer release.  The 4.8210.1.0 version did not properly remove the duplicate entries in the _Actioners table before creating the unique index.

 Could you review your installer/config logs?  This should be in the C:Program FilesK2 blackpearlConfigurationLog folder.

If there is an error relating to the creation of the index, please contact your local K2 support contact for the fix for this.

I checked both the install and config log files, there were no errors in there.  Any other keywords I should search for in there?

 *** EDIT ***

Just FYI I used the 4.8210.1.1 installer. 

Hmm.... I don't think it is related to the _Actioners index issue as that was fixed in the 4.8210.1.1 installer.

First thing I would do is probably log a support ticket on this to get help from K2 suppport.  :)

Second thing I would do is to run a SQL profile trace and capture the SQL statements that are running.

I would try to match the time of the error to the statement that is being executed.  From there you should be able to see which query is causing the issue.

Support ticket has been opened for a while, I am actually going to have a phone call with some of the guys in South Africa to see if we can come to a resolution.  We have tried several things, including re-adding the old ADUM.dll file from the 0803 release, that didn't fix the issue.

I am going to add the most recent patches, I don't think they will fix anything, but you never know!

Fantastic Update Today -

After getting the labs folks in South Africa involved and many emails back and forth we discovered the cause of the problem.

The client site has some groups set up in this format: domain@IT Support Web Apps

Inside ADUM.dll there is a string comparison done on '@' or '', but since we had both it was causing havoc.  They updated the assembly to account for that and now it works fine, what a nice way to end a Friday!

So in the uber rare case someone runs into these sort of errors again, make sure you don't have any wacky AD names.