Skip to main content

Hi,

 

We are facing a strange issue with K2 workflow in production environment. below is the brief description of the issue.

If you have any idea or any previous experience of such issue, then please let us know. Thanks.

 

The AVLS application is built on SharePoint2010 platform and uses K2 workflows for the Approval process. Earlier, the users added to the SharePoint Groups were not able to start the workflows, as the Group Provider was not working. As the users in the SharePoint group were not getting authenticated at the K2 end, they were not able to start the workflow.

On logging a ticket with K2, a patch was installed by K2, resolving the issue.

The users are now facing an issue, wherein the K2 Workflow is not able to update the SharePoint List. This though, works for our credentials; users were not able to complete the workflows, intermittently. Error thrown is ‘401 – Unauthorized’.

This issue is only on the Production environment.

 

 

Action Taken till now:

  1. Checked user permissions:
    1. Checked the SharePoint group permissions on the List (Request List) to have read/write permissions.
    2. Checked and verified that appropriate permissions are applied at the K2 Process (in K2 Workspace). The service accounts are having admin rights on the process and the site collection.
    3. Checked and verified that the SharePoint groups are added on the K2 Process with the correct permission level.

 

  1. Removed and added the users from the SharePoint groups.
    1. As we were getting the 401 unauthorized errors, we removed the users from the SharePoint groups and added them back.
    2. Also the K2 service account was removed and added back.

 

  1. Logged ticket with K2. As per the suggestion, cleared the Identity Cache by running below scripts.

UPDATE lK2].UIdentity]..Identity]

SET ]ExpireOn] = GETDATE()

,TResolved] = 0

, ContainersResolved] = 0

, ContainersExpireOn] = GETDATE()

,TMembersResolved] = 0

, MembersExpireOn] = GETDATE()

 

  1. As per K2, ran the Force Identity Service Refresh Application for each SharePoint Group or Role as below:

    -> Use the 'ForceIdentityServiceRefresh.exe'
    -> Select all 3 checkboxes (E.g Containers)
    -> Ensure servers details are correct
    -> Run the refresh.

    -> Open Smart Object Tester Tool
    -> Execute 'UMUser' Smart Object
    -> Method 'Get Role Users' (Execute it twice)

 

  1. Logged ticket with K2 and as per the suggestion, introduced a 2 min delay in the workflows.
    1. The solution did not work with User’s Credentials hence rolled back. (Though worked with our credentials).

16123iA84054EFE5E7A399.jpg

Hi Prasenjit,


 


Would you please upload a screenshot of the error? Also I see there are tickets logged by you, can you confirm which ones are related to this post? 


 


Many Thanks,


 


Yannick


Hi Yannick,

 

Please check the attached error message and the ticket no. is #65138.

 

Thanks.


15867i01BCEFE1FA146352.jpg

In the K2 workflow, how is the SharePoint list being updated?

 

Is it via a SharePoint integration event or via the SharePoint service object (from a Smart Object)? 


How many Sharepoint WFEs do you have?


 


Do you have "hosts" file entries on the WFE such that traffic originating on the WFE will stay local?


 


e.g.


 


127.0.0.1           portal.denallix.com


Hi, Finally the issue has been resolved.

 

During a live meeting we were able resolve the 401 unauthorized errors received on Production for SharePoint list events.

Action taken during the meeting:
1.We added bindings to the site as it was pointing only to the default port 80 on the WFE’s and the App server.
2.Remove all cached credentials (for Moss- FARM and K2 Service accounts)
3.K2 Service account did not have db_owner rights to the SharePoint Configuration DB, we added the K2 Services account to that group.
4.Ran the setup manager and reconfigure K2 to use the K2 Service account.
5. During K2 for SharePoint configuration we notice that the K2Adminlink did not update.
a.This was due to certain sites being locked.
b.We ran a PowerShell script to unlock all sites.
6. During activation we received the attached error.
a.Seeing that the features were already deployed on the sites we will investigate this issue further on another ticket.
b.This does not affect production negatively.
7. We then Retry all current 401 errors in workspace and all was successful
8. The team did testing on the production site and no 401 errors were thrown


Reply