2

My server name: vshoprspfe The url people use for the farm: http://sharepoint (I'm not familiar with how this has been setup, but I believe it's with a cName) The site collection / library where this from resides: http://sharepoint/travel

I have an InfoPath form that I've published as an Approved Form Template and I've activated it within the host site collection for my library. I've then set this form as the content type for my library.

Unfortunately when I go to create a new item, I receive the following error:

> The following location is not accessible, because it is in a different
> site collection:
> http://vshoprspfe/services/FormServerTemplates/TravelAuthority.xsn?SaveLocation=http://sharepoint/services/Travel%20Authority%20Form/&Source=http://sharepoint/services/Travel%2520Authority%2520Form/Forms/AllItems.aspx&ClientInstalled=false&OpenIn=Browser&NoRedirect=true&XsnLocation=http://VSHOPRSPFE/services/FormServerTemplates/TravelAuthority.xsn.

Now I'm not entirely sure how we configured this as I've been grandfathered into it - but essentially there was a preexisting web application at http://vshoprspfe and then we've added a new one on this same server and then something has been done to make this available as http://sharepoint. This does now mean that SharePoint doesn't appear to be using the correct link for my InfoPath content types - is there a way to resolve this?

Improve this question
2
  • Did you manage to solved this problem?
    – malibeg
    Commented Apr 6, 2015 at 7:51
  • the link is broken. go ahead and just edit the link. this should solve the problem.
    – user44781
    Commented Aug 3, 2015 at 14:07

6 Answers 6

Reset to default
5

I had a similar problem and found it was due to the request management service routing from my web application host header to the server name. I found the following line in the log file:

Request Management Mapping URI from 'http://webapphostname:80/admin/_layouts/15/FormServer.aspx?XsnLocation=http://webapphostname/FormServerTemplates/ExpensesV2.xsn&SaveLocation...' to 'http://servername/admin/_layouts/15/FormServer.aspx?XsnLocation=http://servername/FormServerTemplates/ExpensesV2.xsn&SaveLocation...'

There was a routing rule in my request management settings. I just disabled routing and the problem went away. I used the following powershell to disable it (there is no UI for this):

$w = Get-SPWebApplication "http://webapphostname"
$r = $w | Get-SPRequestManagementSettings
$r.RoutingEnabled = $false
$r.Update()

You may want to configure it rather than disable it. Here's a good resource to get you started:

http://www.harbar.net/articles/sp2013rm1.aspx

Improve this answer
1
  • Thank you @Tom. I disabled Request Management because we didn't need it and now my infpath form is working fine! CHeers
    – Fox
    Commented Oct 29, 2015 at 20:57
2
+50

You mention that the form is stored in http://sharepoint/travel, but the error mentions the form residing in http://sharepoint/services. It could be that /travel and or /services are (in) different site collections using explicit managed paths.

Get a listing of all Site Collections in that Web Application and see if this is the case.

Improve this answer
1

Might be a long shot but doesn't take more that a minute to try: If you have the form template (.xsn) that was created by designer you can save it as the source files (in designer 2010 it's in the publish options). Look at the manifest file in notepad and see if you can find a reference to the bad location. If found, change to the correct location and then republish the form. Again, might be a long shot.

Improve this answer
4
  • Great! This is still something! I'll try it on Monday and let you know the outcome.
    – Michael A
    Commented Mar 21, 2014 at 11:32
  • No luck unfortunately :(
    – Michael A
    Commented Mar 24, 2014 at 23:44
  • In looking at the URL, I do see some issues. You've got the SaveLocation and source pointing to sharepoint/services and the rest is the vshoprspfe. To further narrow down the problem, can you try going to the URL you've listed but remove the SaveLocation and Source from the querystring? Infopath might be looking at either one of these and realizing it's in a different site collection throwing the error. If you remove them and it opens it at least tells us what the offending part is (and then we can figure out how to fix it).
    – Jared McGrath
    Commented Mar 26, 2014 at 15:37
  • Example: vshoprspfe/services/FormServerTemplates/TravelAuthority.xsn? ClientInstalled=false&OpenIn=Browser&NoRedirect=true& XsnLocation=VSHOPRSPFE/services/FormServerTemplates/TravelAuthority.xsn
    – Jared McGrath
    Commented Mar 26, 2014 at 15:38
1

There is a lot that can be wrong (particularly when you inherit a farm like this...)

Have a look at the Alternate Access Mapping for the Web Applications in question. Are they in the same Zone?

Also, looking at the URL it appears that the URL to Forms Server "vshoprspfe" is the part that is tripping up InfoPath. When you Published the form did you use "sharepoint" or "vshoprspfe"? Can you fix the URL by republishing the form?

Improve this answer
2
  • I did have the thought about publication also, and I've tried to republish the form - but this doesn't appear to be it and something is instead getting confused throughout the publishing process. Both zones for Alternate Access for these are set to 'Default' - should this be modified to something more strongly typed?
    – Michael A
    Commented Mar 26, 2014 at 1:42
  • Not necessarily, it depends on your overall architecture. The key is to figure out why the URL is incorrect. Have you looked at the settings for your InfoPath Services Application.
    – Matthew McDermott
    Commented Mar 26, 2014 at 13:02
1

From memory the FormServerTemplates library always gets created in the root site of site collections. The path you have for your template http://vshoprspfe/services/FormServerTemplates/TravelAuthority.xsn makes me think /services is a site collection different than the one the travel library sits in (/). You say you have deployed the admin approved form yourself. That means you have access to the Central Administration site. Go check the site collection list on the relevant web application and confirm the fact.

Improve this answer
0

In my case I did an In place Content database migration from 2010 to 2013.

It is working perfectly in 2010 but not in 2013.

Since the URL changes after updating to new web application the URL changes. That is why you have to go look for the actual form in site content and copy the address and in 2013 give the correct link address.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.