Skip to main content

Hello,

Here's hoping that I can get a steer on how to pinpoint the source of a problem with a K2 Blackpoint project incorporating InfoPath forms which use secondary data connections to call web services via udcx files.  Since users don't have Office 2007, I need to have the form open in the browser.  The projects I'm working on are fully operational in the development environment, but not when published to the production server.  The SharePoint Enterprise Edition host runs on Windows Server 2003 SP2, and is itself patched to SP2.  I am using Kerberos in both the production and development environments, though with different user accounts on each.

Before going into all the gory details of the data connections, I'm wondering if the problem is a misconfiguration of the K2 Runtime Services. I mention this because, while configuring the InfoPath process from within K2 Studio, I get to test the Workflow Web Services URL.  This works fine against the development server, but fails against production with the error: Connection failed; the request failed with HTTP status 401: Unauthorized.  Meanwhile the test of the Workflow server succeeds in both cases.

So I experimented a bit and found I could navigate to the development machine's InfoPathService.asmx page just fine from a separate workstation but not to the same page on the production server.  With the latter, I get the tedious Username/Password credentials box three times beofre the standard 401.1 error page.  Meanwhile, if logged on to the production server itself, the page opens fine.

That all suggests a Kerberos problem, but I can't find out what.  I now have a sheaf of papers comparing the development with the production systems, with a page for each of web site authentication methods, SPNs, application pool acounts, web.config authentication settings and udcx authentication settings.  It all looks right, but doesn't work.

Using the simplest possible InfoPath form, I find I can deploy a project to production, open the form via the browser and submit it fine - it sends me a friendly e-mail to confirm it has worked via a K2 MailEvent, so I know K2 has handled the process.  However, as soon as I add a data connection, I can't even open the form.  On the server the message is 'This form is not browser-enabled'; on a client machine without InfoPath 2007, the screen just shows 'The form has been closed'; on a client with InfoPath 2007, the form opens in InfoPath client, complete with secondary data, but then won't submit: I get the IE user credentials dialog 3 times, then an InfoPath user credentials dialog 3 times, then 'the web service request could not be authorized'.  The InfoPath dialog is referencing http://<ProductionServer>/RuntimeServices/InfoPathService.asmx.

Which made me think that perhaps getting the Runtime Services working without error would sort out the data connections.  I'd love to understand why it can handle the processing of a form without a secondary data connection, but not one with.  More practically, it would be a great help to have confirmation about a couple of the recommended settings:

1. If using Kerberos, should the K2 Runtime Services website be explicitly set to use "Negotiate, NTLM" authentication?

2. Should there be separate SPNs for the port on which the K2 Runtime Services website is running?

In my case, on the (working) development system, the top level (w3svcNTAuthenticationProviders) is set to "Negotiate, NTLM" but nothing set at the K2 Runtime Services node.  Nor do I have any SPNs for HTTP/<ServerName>:81 or HTTP/<ServerName>.<FQDN>:81, where 81 is the port for the K2 Runtime Services website.

I'm also not getting any specific error messages, either in the Windows or the SharePoint logs.  I wonder what SharePoint diagnostics Category to set to capture the problems opening the form with a data connection (with just the Forms Services categories set, there are no log entries at all, suggesting a failure earlier in the loading process)?

For the sake of completeness, I should mention that the development site was upgraded from K2 Blackpoint beta 2 to the RTM version, while on the production site, K2 was installed afresh.  I notice a small difference in the names of the applications within the K2 blackpoint Application Pool, being K2 Runtime Services on the production system and K2 Web Services on the development system.  The other application, RuntimeServices, is the same on both.

Any guidance as to what further to check or how to narrow down the problem further will be very much appreciated. With thanks and regards,

Sebastian Crewe

The world can indeed be a wonderful place.  There are waterfalls, giraffes, bird migrations and now a way to help resolve Kerberos errors.  While the problem described above is not wholly solved, the picture is much clearer thanks to the efforts of Brian Booth - please see http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx.  This well-conceived package allows you to create a web application within an existing problematic site so as to see why Kerberos might not be working.  Given that you can go to the next stage as well, diagnosing the next hop, eg to a SQL Server, this is valuable for any site using Kerberos.

Using it within the K2 Runtime Services web site, I was 'told' that I was missing an SPN for my home site.  There is even a button within the Kerberos report to fix the problem automatically.  But I was not out of the woods yet - having set the HTTP/<webserver> SPN to the list for the K2 Runtime Services application pool identity, I then had a duplicate SPN since this entry was already present for the account running the main SharePoint site's application pool.

In earlier conversations with K2 while setting things up, I had been advised to create SPNs for the webserver itself (in particular omitting :80 since that was known to cause problems) and for the specific port on which K2 Runtime Services was running, in my case port 81.  So there were SPNs for HTTP/<webserver> and HTTP/<webserver>:81 (plus their cousins using the FQDN).  On my working development system, in which all services and application pools were running under the same domain account, this hadn't been necessary.

So I fiddled and played for a bit, running the above Kerberos diagnostics page inbetween each change, until I realised I wasn't going to win with two separate accounts on the production system - one for the main SharePoint site, the other for K2 Runtime Services.  Setting SPNs for the different accounts with different port numbers didn't seem to work.  So I reviewed the K2 documentation and ensured that my original SharePoint account had all the necessary permissions for the K2 Service Account, and then switched to use just the one account for both (as well as the database permissions, Farm Admin, Site Collection Admin et al, you need to remember to rehome the K2HostServer and K2Server SPNs to the new account as well).  Lo, things started to work.  I can now access the K2 web service pages from an external client without errors, testing the connection from within K2 Studio works for all elements and love is in the air.

Except for the fact that the freshly deployed K2 solution, initiated by an InfoPath form, resolutely refuses to open within the web browser.   I tried stripping out all K2 related service calls and deployed the form to the production server.  It opens without a murmur in the web browser and executes all the data calls I've specified.  The response when K2-enabled depends on the client being used.  If on the server itself, without any InfoPath client installed, I get "This form template is not currently browser-enabled ...".  On a separate client with InfoPath 2003, I get a page with a box saying "The form has been closed"; meanwhile the URL ends with DefaultItemOpen=1, which seems correct.  On a client with InfoPath 2007, the form opens in InfoPath 2007, my data calls work and populate the form correctly, and I can submit the form.  I know the K2 workflow has worked since I get the requested, formatted e-mail as a result of the submission.  I feel this confirms that the K2 web service authentication is working now.

It occurred to me that my development site has its K2 workflow testing forms libraries in a sub-site and that the udcx data connections are using relative links, up to the parent site's Data Connections library.  So I created a sub-site on my production server to match the hierarchy on development.  No joy.  I've checked that the settings for the library specify to 'Display as Web page'.  The form itself passes all compatibility checks and, indeed, works fine without the K2 elements.  Central Admin has 'Allow cross-domain data access ...' checked, as well as 'Allow user form templates to use authentication ...' and 'Allow users to browser-enable form templates'.  I've also ticked 'Allow embedded SQL authentication' for good measure.

From my experience to date, it seems that if anything is slightly wrong with a form or its data connections, then the K2-enabled form simply refuses to open.  I'm hoping that a future version can incorporate more robust checking prior to deployment since there aren't many clues as to what is wrong.

Any ideas as to what to try next in the current case?

Thanks and regards

Sebastian Crewe

As you can see, I'm answering my own questions here.  Hope it will save pain for others wanting the full goodness of K2.

It turns out there are a couple of problems when deploying a InfoPath form-based project to another server, eg from development to production.  As per the previous post, the forms were working fine in development but wouldn't open via the browser in production.

I think the first thing to confirm is that the form will open OK without any K2 elements - I did this by taking a copy of the template, edited it, stripped out the K2 data connections and published to a testing Forms Library.  This should confirm that your custom data connections, via udcx files, are working properly.

The next thing is to correct the errors in the Site Collection attributes for the K2 data connections (eg Can I Submit Workflow Service, Submit Workflow Service and Get Workflow Task Actions Service).  The attribute is simply missing a trailing slash (/). The solution does require decomposing the InfoPath xsn file, but you can solve two problems here: first, the incomplete K2 Site Collection attributes; secondly, you can amend your custom data sources to point to the new server.  If you don't do this, you'll see errors like 'Relative Links to Data Connection Libraries located on different SharePoint site collections are not supported'.  Yes, you can correct this via editing the InfoPath form in K2 Studio prior to deployment, but changing the data connections to point to the new server means removing them and re-adding, plus re-adding any rules that used those data connections.  Tedious and error prone.

 Here are the steps I used to get things working:



  1. Deploy the project to production from K2 Studio
  2. Go to the relevant Forms
    Library, Settings, Advanced. 
    Right-click on Edit Template and 'Save Target As'.
  3. Open in IP2007 by
    right-clicking the saved xsn file and choosing Design
  4. Immediately do 'Save As Source
    Files'.  Close IP.
  5. Right-click the resulting
    manifest.xsf and edit in a text editor
  6. Find the connectionLinkType
    elements.  Change the Site
    Collection attribute to match the production server. 
    Also add a trailing / to this attribute where missing (in my case all the K2 data connections), eg http://myserver/sites/home/.  This is the site that will have the Data Connections library being used for your udcx files.
  7. Save and close
  8. Right-click the new version
    of manifest.xsf and choose Design. 
    Check the Data Connections.  The K2
    ones will now have a Connection Source line which was absent before.
  9. Save the form using Save As,
    overwriting the xsn file that was saved in step 2
  10. Publish to the Forms Library

 

That got things working for me and hope this will help save time (and hair) for others.

Seems that there is still an issue with the data connections that K2 adds into the InfoPath form, has there been any developments on this.  I am using InfoPath and the K2 for SharePoint designer tool.  Not able to edit the form through InfoPath as described, is there any other options?


Thanks Fiona

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings