I previously posted a request for assistance about this issue and thought I should blog about what combination of solutions ended up working. So here’s the scenario:
We’re running MOSS2007 with Office 2010. Most users are running Windows 7 with either Internet Explorer 8 or 9. (Some are not able to run IE9 due to a conflict between IE9 and another our internal student information systems). In preparation for our upcoming upgrade to SharePoint2013, We had begun to install Office 2013 on users desktop computers across our 7 campus locations.
We suddenly began to get intermittent reports of users not being able to open new InfoPath forms. Of the 7 InfoPath forms that we are currently running, all but 2 are browser-enabled. The users who were not able to open new forms were only unable to open the forms that required the InfoPath client. They could open the 5 browser-enabled forms from Firefox or Chrome without a problem. Not all users who had Office 2013 were experiencing the issue. I had 2 separate machines running Office 2013 (one with IE8, one with IE9), neither one experienced the problem.
Those who do experience it get the same messages:
InfoPath cannot submit the form.
Some rules were not applied.
An error occurred while the form was being submitted. The form cannot be submitted to the following location: https://URL (Full URL is listed correctly)
The site may be offline, read-only, or otherwise unavailable.
The parameter is incorrect.
So one of our IT techs and I began looking for similarities/differences in setups. Our standard setup has our SharePoint URL set as the Local Intranet Site. We installed a security certificate on the SharePoint server earlier this year, and we found that users who did not have SharePoint set as the Local Intranet site were unable to submit or approve forms. In resolving issues caused by the security certificate install, we also found that enabling “Display Mixed Content” in the custom levels on the Local Intranet security settings also eliminated the constant messages about allowing secure (or insecure) content.
We verified that the users having the issues did have the Local Intranet site settings with Display Mixed Content. We cleared browser history and restarted the computers. It took a couple of days of testing to find a solution.
Of the users who could not submit forms, there were two issues.
One was the Compatibility settings in IE. To “fix” the issue two options were available: turn compatibility settings off or uncheck the setting to have local intranet site display in compatibility view. Either one seems to work.
The bigger issue, that I’m still not sure how/why it was happening, is that those users who were experiencing issues were getting login prompts when they submitted. The problem with these login prompts was that they were not pointing to the correct domain, even though the user was logged into the computer with the correct domain. Once we had the users login (going to Login in as another user entering the correct domain login\password combo and clicking to remember credentials) the problem went away.
While we still don’t know what caused users logins to suddenly show up differently, we have shared this information across our campuses to all of our IT folks.
Ironically, rolling Infopath back from 2013 to 2010 also fixed the issue for some users. Which makes me think that there may be some kind of caching issue between InfoPath 2013 and IE8/IE9. We tried rolling to IE10 and found that users couldn’t access SharePoint, Nolij, or DegreeWorks (so for now we are advising users against upgrading to IE10).
Maybe sharing our recent experiences will help someone else in the community.
Thanks to all the community members who provided suggestions in researching the problem. Just knowing there were people to ask who would respond made a really tense situation more bearable. That’s what makes this community unique in my opinion… the level of participation and knowledge abounding here!