I'm trying to make the K2 Tasks webpart to work on sharepoint. I add the webpart to a new page, setup the server address and port but is not showing any of my tasks even I do have.
I can see my tasks through K2 Workspace.
If I look in K2 server log I notice that sharepoint is logging each time using anonymous logon while K2 Workspace is using the correct NT account.
Any help would be appreciated,
-Marian Dumitrascu
K2 Tasks webpart not working
+4Hi Marian,
When you export your processes to the K2 Server, it is essential that you grant the "Anonymous" user the "Start" privilege/permission, so that SharePoint can start/plan the process. Depending on what interactions the process is to make with SharePoint, you may need to grant some of the other privileges to the Anonymous user as well.
We've configured our environment for Kerberos authentication/delegation and found that the web part seems to work fine with our configuration.
The following might be useful:
http/[K2ServerName].[DomainName]
K2Server2003/K2[K2ServerName]
K2Server2003/K2[K2ServerName].[DomainName]
Ensure that the K2 Service Account is granted the "Log on as a service" and "Log on as a batch job" user rights on the K2 Server
We've also changed the IIS Application Pool used by the K2 Web Components (DefaultAppPool in our environment) to run as a named user. This user was also added to the "IIS_WPG" group on the K2 server.
We also added the K2 Service Account to the "Administrators" group on the K2 server.
Hope this helps.
Regards,
Dave
When you export your processes to the K2 Server, it is essential that you grant the "Anonymous" user the "Start" privilege/permission, so that SharePoint can start/plan the process. Depending on what interactions the process is to make with SharePoint, you may need to grant some of the other privileges to the Anonymous user as well.
We've configured our environment for Kerberos authentication/delegation and found that the web part seems to work fine with our configuration.
The following might be useful:
- Ensure that the K2 Server Service is configured to run as a Domain Account rather than as "LocalSystem"
Ensure that the K2 Service Account is "Trusted for Delegation"
Ensure that the K2 Server is "Trusted for Delegation"
Add the following values to the K2 Service Account "servicePrincipleName" attribute:- http/
http/[K2ServerName].[DomainName]
K2Server2003/K2[K2ServerName]
K2Server2003/K2[K2ServerName].[DomainName]
Ensure that the K2 Service Account is granted the "Log on as a service" and "Log on as a batch job" user rights on the K2 Server
We've also changed the IIS Application Pool used by the K2 Web Components (DefaultAppPool in our environment) to run as a named user. This user was also added to the "IIS_WPG" group on the K2 server.
We also added the K2 Service Account to the "Administrators" group on the K2 server.
Hope this helps.
Regards,
Dave
Hi
I seem to be having the same problem as marian, It seems that sharepoint is only sending the anonymous user rather than the authenticated user to find the list of tasks for a user. I remember in the k2 training being told that Sharepoint only sends the anonymous users and can not send the authenticated user ???
I've tried the suggestions given by Dave but no luck in getting sharepoint to send the authenticated user rather than the anonymous one
Regards
Rich
Richard Hyams | Global IT Development Mgr| Eidos
> Tel. +44 (0)20 8636 3000
> Fax +44 (0)20 8636 3001
Eidos PLC
Wimbledon Bridge House
1 Hartfield Road
Wimbledon
London SW19 3RU
www.eidos.com
I seem to be having the same problem as marian, It seems that sharepoint is only sending the anonymous user rather than the authenticated user to find the list of tasks for a user. I remember in the k2 training being told that Sharepoint only sends the anonymous users and can not send the authenticated user ???
I've tried the suggestions given by Dave but no luck in getting sharepoint to send the authenticated user rather than the anonymous one
Regards
Rich
Richard Hyams | Global IT Development Mgr| Eidos
> Tel. +44 (0)20 8636 3000
> Fax +44 (0)20 8636 3001
Eidos PLC
Wimbledon Bridge House
1 Hartfield Road
Wimbledon
London SW19 3RU
www.eidos.com
+4Hi,
We've also used the following authentication settings on the various K2 Virtual Directories on the K2 Server's IIS installation:
K2V3
InfoPathService
Basic Authentication: Enabled
SharePointProcessService
Basic Authentication: Enabled
Workspace
WorkspaceService
NOTE: We also have a requirement for Basic Authentication in our environment.
NOTE: We have disabled Anonymous access on all of these Virtual Directories on the K2 Server.
You'll also need to make sure that any virtual directories you've created to host SmartForms also have a suitable authentication method set in IIS - In our environment, this is to enable Basic Authentication and specify a Default domain - See Workspace example above
On our SharePoint Server we also set the following Authentication Methods for the Default Web Site which hosts our SharePoint installation:
Default Web Site
Basic Authentication: Enabled
We also made a change to one of the web.config files for to enable user impersonation - I'll have to check which one it was and post an update.
Regards,
Dave.
We've also used the following authentication settings on the various K2 Virtual Directories on the K2 Server's IIS installation:
K2V3
- Basic Authentication:
- Default Domain:
InfoPathService
- Integrated Windows Authentication:
Basic Authentication: Enabled
- Default Domain:
SharePointProcessService
- Integrated Windows Authentication:
Basic Authentication: Enabled
- Default Domain:
Workspace
- Basic Authentication:
- Default Domain:
WorkspaceService
- Basic Authentication:
- Default Domain:
NOTE: We also have a requirement for Basic Authentication in our environment.
NOTE: We have disabled Anonymous access on all of these Virtual Directories on the K2 Server.
You'll also need to make sure that any virtual directories you've created to host SmartForms also have a suitable authentication method set in IIS - In our environment, this is to enable Basic Authentication and specify a Default domain - See Workspace example above
On our SharePoint Server we also set the following Authentication Methods for the Default Web Site which hosts our SharePoint installation:
Default Web Site
- Integrated Windows Authentication:
Basic Authentication: Enabled
- Default Domain:
We also made a change to one of the web.config files for to enable user impersonation - I'll have to check which one it was and post an update.
Regards,
Dave.
thanks a lot Dave that has helped a lot....
The biggest problem was we forgot to set the SPN for the domain Service account that runs Sharepoint (we had just set it for the account that runs k2) so Kerberos authentication was not being passed correctly to the K2 server
Cheers
Rich
The biggest problem was we forgot to set the SPN for the domain Service account that runs Sharepoint (we had just set it for the account that runs k2) so Kerberos authentication was not being passed correctly to the K2 server
Cheers
Rich
+9Hi,
David, thank you for the advice, this will help many people in the future!
Rich, You are correct by saying process planned by SPS can only pass Anonymous, the reason for this is because SPS raises the event used by K2.net as the SPS service account. This makes it impossible to impersonate the actual user that caused the event to fire.
The issues experienced in the postings was based on the actual account that was impersonated by the Worklist web part to K2.net, because delegation is taking place in a scenario like this it is required that the various machines and accounts needs to be trusted for delegation, refer to the K2.net 2003 Task List Configuration document (available on http://portal.k2workflow.com/downloads/product.aspx)
for more information.
Regards,
R
David, thank you for the advice, this will help many people in the future!
Rich, You are correct by saying process planned by SPS can only pass Anonymous, the reason for this is because SPS raises the event used by K2.net as the SPS service account. This makes it impossible to impersonate the actual user that caused the event to fire.
The issues experienced in the postings was based on the actual account that was impersonated by the Worklist web part to K2.net, because delegation is taking place in a scenario like this it is required that the various machines and accounts needs to be trusted for delegation, refer to the K2.net 2003 Task List Configuration document (available on http://portal.k2workflow.com/downloads/product.aspx)
for more information.
Regards,
R
This makes it impossible to impersonate the actual user that caused the event to fire.
is there any way around? In my case I need to send an email to a user (the originator) when he inserts a document in a document library.
Please help (or confirm it's impossible)
Thanks
+8Hi
You could add a column in the document library that captures the identity of the person who has uploaded the document. Then you can import the value into your process and send mail (or do whatever you need to). Here is a posting that could help you with creating the column:
http://forum.k2workflow.com/viewtopic.php?t=51
You could add a column in the document library that captures the identity of the person who has uploaded the document. Then you can import the value into your process and send mail (or do whatever you need to). Here is a posting that could help you with creating the column:
http://forum.k2workflow.com/viewtopic.php?t=51
+2We are also having a similar problem except we do not use Kebros Authorisation, is this a requirement to get this web part working?
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.