Our users access SharePoint sites and our InfoPath form in 1 of 3 different ways:
- Via the Intranet: http://intranet
- Via the Extranet: http://extranet.ourcompany.com
- Via the ISA Server: http://intranet.ourcompany.othercompany.com
Looking at our network configuration i placed a big bet that the problem was something to do with the fact that we were using host headers so i started searching google for anything related.
The following post seemed exactly the same as our scenario: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=2777878&SiteID=17
I toyed with the idea of changing the host headers and tried publishing the form in as many different ways as possible (domain trust direct to a doc library, full trust, administrator approved & managed through Central Administration etc etc). No luck.
Problem 1 Detail:
Intranet & Extranet users could access and submit the form. However there were access problems for ISA server users with the following error message:
The following location is not accessible, because it is in a different site collection: http://intranet.ourcompany.othercompany.com/Infopath/Forms/template.xsn
The solution:
To resolve this I added the http://intranet.ourcompany.othercompany.com URL to the alternate access mappings in Central Administration and users were immediately then able to open the form.
Problem 2 Detail:
The following error message was generated on submitting the form (also for ISA server users):
The form cannot be submitted to the Web server either because your computer is offline or because the host server is currently unavailable. If this problem persists, contact your network administrator.
On closing the form users were then redirected to http://intranet (the URL that the form is published to in InfoPath) which of course they could not access.
The solution:
We had to search high and low for the answer which thankfully came from the following post: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2386461&SiteID=1
Basically we added a Link Translation rule in the ISA Server to replace the FQDN InternalDomain with ExternalDomain (Without http://)
Eg:
- http://intranet.ourcompany.othercompany.com
- intranet.ourcompany.othercompany.com
Only Intranet users could access and submit the form. Extranet users could not access and submit the form.
ReplyDeleteIntranet doesn't have ISA.
Extranet has ISA in between.
The Question is while activating the IP Form we activate only to intranet site ... how the extranet will work?
In otherwords, i need to access for from both intranet and extranet, rt now extranet accessing IP Form is not working
celerity12 were you able to make it work via the extranet?
ReplyDeleteIm having the same issues as described, i've changed the link translation on ISA and the problem is still occuring.
I have two MOSS web front end servers and on one server i am able to open the form from the form library but on second web front end server i receive the following message while trying to open the submitted form.
ReplyDeleteThe following location is not accessible, because it is in a different site collection: /services/testservice/faraztest/Credit Card Tracking - 11112009-04-29T18_13_04.xml.
Thank you so much for the tip on the AAM. I was starting to panic that the solution was going to be a tough one. This saved me a ton of time!!!
ReplyDeleteWhat worked for us was setting a Link Translation Rule....
ReplyDeleteFrom:
http:\u002f\u002fmydomain.com
To:
https:\u002f\u002fmydomain.com
Bizarre, yes? :)
I tracked it down via View Source on the InfoPath web form. There's a javascript array variable in there called "g_objCurrentFormData", which contains some URL strings. I guess InfoPath is using these as part of the submit process.
If these domain strings in "g_objCurrentFormData" don't exactly match the domain in which the form is being viewed, **including the https!** then the submit will be blocked (....browser-level prevention of cross-domain shennanigans, I suppose.)
Cryptically, the forward slashes are encoded by InfoPath as \u002f.... in case you didn't guess :)
In our case, the form was hosted at our SharePoint site https://mydomain.com, but the javascript strings showed "http:\u002f\u002fmydomain.com", i.e. missing the "s". The Link Translation Rule converted these into "https:\u002f\u002fmydomain.com", which did the trick.
Running Fiddler before and after the Link Translation Rule was defined showed....
Before:
No Fiddler traffic on submit.
After
A POST to the SharePoint domain on submit!
Thanks to Hannah and John Gao for getting us as far as you did.
ps: we still had a world of pain after this point, but these other issues were all solved by this excellent post: http://blog.metrostarsystems.com/2009/06/04/anonymously-submit-infopath-form-to-sharepoint-library/
cheers
Merenzo.
same issue here , how to add Link Translation rule
ReplyDeleteThe \u002f Link Translation rule trick works. We were going down the road of thinking we had a data "Submit" problem, when in fact, the whole button array generates the same error message. Even clicking "Close." Once we saw that, we knew it was localized to whatever was going on with those controls. As crazy as the rule looks, it works.
ReplyDeleteAn interesting point of view. I like to read your blog post because it is well written and interesting.
ReplyDeleteThe \u002f Link Translation rule trick works. Thxxx ! Great blog !
ReplyDeleteThis is a nice point of view and the presentation here is too impressing. Really nice to visit this site.
ReplyDeleteweb designing company