Hi there,

Background:

Sharepoint 2013 - 2010 compatabilty mode is on
This is a Form Library
the form is InfoPath based

althought the history is lost I think developed in either 2010 or 2007 and migrated across...

I think there are two problems.

1) some users have no problems, others have a problem where they open this form, do some action and then when they are saving they get "some rules were not applied" and if they open the details (which most dont) you see info like:

InfoPath cannot submit the form.
 
An error occurred while the form was being submitted.
 
The form cannot be submitted to the following location: http://intranet/branch01/section01/formslib01/FormRequestA 0001 2015-07-31T10_40_56.xml
 
The file "http://intranet/branch01/section01/formslib01/FormRequestA 0001 2015-07-31T10_40_56.xml" is checked out for editing by DOMAIN\myusername.
 
The operation completed successfully.

2) on this same list, users have this issue (which may or may not be related?).

when the users action this item the status is not updated (possibly because of the above error possibly not triggering a workflow?) and so its not removed from the other users "incomplete" view and sometimes people end up actioning things twice or it just floods the view.

I'm not a Sharepoint guru at all, so "be kind" - aka: provide all your workings and don't assume I know anything ;).

ADDITIONAL: Failing anyone "knowing" anything about the above. Is there some way that I can:

• see logs or information about THIS form from either the sharepoint system, sharepoint "Central Admin" site or the logs somewhere - if so, how do you control/filter this - are there tools in sharepoint designer 2013?
• see WHO the system things the CURRENT user actually IS? because the error message says "is checked out for editing by domain\username" but that IS the user that is trying to do the action (... or is it...) is this in IIS logs or SOMEWHERE or do I need other tools?

Thanks in a

Hi noJedi (love that name)- this could be due to several things, and not knowing how your form is set up or what workflow(s) you have on the library makes it hard to troubleshoot. However, here are a few things to start:

1) Are you using the same version of InfoPath and SharePoint? Using different versions can cause issues.

2) SharePoint automatically creates a lock on a file after someone saves it. If you wait for 5 minutes and try again, does it still occur?

3) This sounds eerily similar to something I've come across in the past, usually do to a server lockup or reboot while the form was open. In this case, a temp file is stored on the user's computer and causes an issue for just that user. Check the following location on the computer and delete the files:

C:Documents and SettingsUserNameLocal SettingsTemporary Internet FilesContent.MSO

Hi Cameron,

Firstly, thanks heaps for the response!

1) we are (currently) using SP2013 in 2010 compatability mode, and office 2010 across the desktops.

2) so for some users yes the "try again later" does work, but there are two problems with this:

a) when it happens (for some reason) the list item state still changes and/or the workflows trigger meaning that the items are in a broken state - this might be a bug in the design of the workflow or infopath forms (these were developed waaay back when the site was 2007 (and there is another issue, which I'm not sure of that when I try to "webform" these infopath items the Design Checker complains "Sharepoint libary or list connection must be upgraded to the infopath 2010 format" (not sure what's going on there but this could be contributing to the issue, but its only for a connection that is retrieving data not submitting) - none of these forms are "web" enabled as they use "user roles" and dialog boxes, but I'm thinking of ways to change these things to enable web forms.

b) it doesn't happen for all users, and there are distinct users that this NEVER works for or works only 1 time out of 20.

3) Not sure if this helps but this is the basics of the form and workflow:

sharepoint forms libaray.

infopath form with (essentially) two views "creation" and "office use only"

workflow is essentially an approval workflow (but not the built in one that I understand now exists - this is one that was created back in 2007 and migrated) --> form submission starts workflwo that emails "office users" office users open the link process teh info in the form and complete the "office use only" view and submit the form -> if aproved or rejected send email to creator of the form letting them know.

(from security or windows version I cannot reach that folder path you suggested (access denied)... i suspect there is a AD or GP limitation likely in place...) is it good enough to "clear temporary internet files" or somehting (assuming our users can do tha

No, clearing temp files won't help. I know you don't want to hear this, but you should redo the forms in InfoPath and make a new workflow.

Heh, you're right that I didn't really want to hear that!

But I think your right - I have also just noticed that some of these test submissions approval states are going straight to completed, but the workflow isn't "working" so there might be a few issues there...these forms are quite long in the tooth and need a makeover - are there any, ways to validate "broken workflows" and or are there pros/cons to using the "2010 Approval workflow" vs a custom workflow that does pretty much the same thing? (email "approvers", respond to submitters with approval status?)

As a related question is there some way to script or "relative"ize (or even a best practice on reducing non relative linkages)?

Eg: this InfoPath form (and many others in the site) have a lot of references to the old (and even some now non-existing) URLs such as dev and test servers and so on.

examples:

a Hyperlink to "help" that points to the 2007 server name "http://veryoldservername/someoldsubsite/documents/form20%help.doc".

the submit "target" in the file is bound to the prod site in the dev and test - this is easy to fix with "publish" not the quick publish, bu the servers seem to have these "cross referenced" (possibly content DB restore issue?) to PROD - which has meant that some TEST form submissions actually submit to PROD (because there are no network restrictions in place?!? (I'm guessing a lot of this).

the secondary data sources (lookups for lists and so forth) also point to PROD

are there any recommended ways around this or to minimise the amount or work involved in "changing enviornments"?

Thanks heaps for your advice!

Unfortunately migrating InfoPath forms isn't an easy task. See the following link for steps you'll need to perform to get your old forms updated:

https://blogs.perficient.com/microsoft/2013/03/infopath-and-sharepoint-2013-upgrading-your-forms/

Okay,

I've rebuilt both the form and the workflow and its working almost perfectly (and the same as previously setup).

However there are a couple of users that are still getting the same issue.

I've discovered more information however and this might be pertinent:

a) the users getting the issue are responding NOT to the workflow but to an ALERT that tells them if anything has changed in the list (because the workflow was previously unreliable, some have set this up) when the ALERT happens I've noticed that all the URL in the email refer to the SERVERNAME not the primary alias... I don't know much about this but its basically we have two servers sp01 and sp02 and an alias or hostname or something called "intranet" which goes (somehow -dns entries?) to either server... I noticed that users clicking on this link are taken to the URL "sp02\site\library" rather than "intranet\site\library" and that the FORM SUBMITS to this second address...

b) I also noticed that when accessing via sp01 or sp02, some of the forms "users" info is not being populated... (created date/by and modified date/by information)

I'm guessing that:

sp01 and intranet in the form - something like cross origin policy or XSS protection is stoping the form from sp01 accessing security or services from intranet...

also guessing that this might be how the server can complain from sp01 that the file is already checked out when it tries to submit to "intranet"...

Any thoughts and suggestions welcome...

is this something to do with the site configuration or proxy servers or domain security?

I think Camerons info definately has excellent info - in particular the updating of InfoPath "data connections" and updating using PS script... however I'm (at least at the moment) convinced this has SOMETHING to do with the URL that OUR system is using and POSSIBLY AAM (Alternate Access Mappings) or maybe just hostnames or something to do with internal proxy routings...

My theory is that the users are accessing links that are along the lines of:

servername01/site/list/item

rather than

intranet/site/list/item - which is what would be the INFOPATH address... embedded in the file

and this is causing "servername01" to have the item checked out by "domain/username" and for whatever reason accessing "intranet" from INFOPATH (possibly same as in SSRS without Kerberos? where you cannot impersonate from the webservice... second hop authentication issue?) or something and so infopath gets the "in use by" message... or something... anyway, I'm still investigating, but the amount of problems we are having with infopath forms is causing a lot of issues and since we have no SP guru onsite, I'm thinking that we will need to skill up very quickly or just ditch as many infopath forms as we can and fall back to using lists, which seem to have far fewer issues. (in our site at least)