Hi,
we have an issue with an Alternate Access Mapping and Forms Server.
We defined the AAM, so the SharePoint / Forms Server site is available from external by a FQDN. Additionally the form is also available from an internal hostname.
When a user opens the form with Forms Server with the internal name and saves the form data, the template connection to the XSN file is set to a path http://hostname/FormServerTemplates/.../formfile.xsn.
When an external user tries to open this form by using the FQDN, the xml file is not displayed with forms server. Instead the browser will try to download or open the xml file to the local drive.
The same happens the other way around, when an external users creates a form xml file in the forms library through the FQDN, the template connection is set to the path http://fqdn/FormServerTemplates/.../formfile.xsn. And when I try to open the form by the internal hostname, the data is not displayed with forms server. IE displays only the default "Open with" / "Save as" dialog (the FQDN is not reachable from internal LAN).
When I go to my forms library and choose the "Repair" view (http://server/.../formlibrary/form/repair.aspx) to reconnect the files manually with the forms template, the template path is adjusted to the path value from where I'm currently accessing the forms library. So when I'm going to the forms library with the hostname-URL the template path is adjusted to a hostname based path. And when I'm repairing the forms library by the FQDN-URL the template path is adjusted to a FQDN based path.
Is there a way to get forms server working with all Alternate Access Mappings without manually repairing / changing the existing xml files So that it does not matter if the file is created by an internal user which used the hostname to access the form-library or if the user created the file by the FQDN path.
Frank
Alternate Access Mappings and Forms Server
Davids Learning
Hi Frank,
did you manage to solve the above problem or find a workaround for it
We have the same exact issue:
Forms created from the external IP do not open in the browser when trying from the internal IP, and vice versa.
The forms do open up in the InfoPath client (with a security warning) though.
This only concerns the admin-deployed forms. Domain level forms (published as a content type) started working properly after I changed the content type's template URL to use the external IP.
Best Regards,
Ilkka Vallinkoski