Creating web part pages in a custom Pages library

I just created a new document library called "IS Email Newsletter Pages" and set the content type to Pages with the idea that this would create a new place to store web part pages in my SP site.

When i click on New on the document library toolbar i am redirected to Create Page where we fill in the page title, description, URL name and layout type etc.

I was expecting the URL name to reflect the new document library URL (IS Email Newsletter Pages/testpage.aspx) but it doesn't - it still points to the original Pages library (Pages/testpage.aspx) and when the page is created it is created in the Pages library.



Does anyone know how to create pages in a custom pages library???

SharePoint Web Service Reference

WSS Web Services	Web Reference
Administration Service	http:///_vti_adm/admin.asmx
Alerts Service	http:///_vti_bin/alerts.asmx
Document Workspace Service	http:///_vti_bin/dws.asmx
Forms Service	http:///_vti_bin/forms.asmx
Imaging Service	http:///_vti_bin/imaging.asmx
List Data Retrieval Service	http:///_vti_bin/dspsts.asmx
Lists Service	http:///_vti_bin/lists.asmx
Meetings Service	http:///_vti_bin/meetings.asmx
Permissions Service	http:///_vti_bin/permissions.asmx
Site Data Service	http:///_vti_bin/sitedata.asmx
Site Service	http:///_vti_bin/sites.asmx
Users and Groups Service	http:///_vti_bin/usergroup.asmx
Versions Service	http:///_vti_bin/versions.asmx
Views Service	http:///_vti_bin/views.asmx
Web Part Pages Service	http:///_vti_bin/webpartpages.asmx
Webs Service	http:///_vti_bin/webs.asmx

Problems with Infopath forms using host headers & ISA Servers

Last week I published my first InfoPath form and discovered that some users could not access or submit the form.

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

The form is set to domain trust, published from InfoPath as a site content type and associated with a SharePoint document library (browser compatible) at http://intranet.

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:

1. http://intranet.ourcompany.othercompany.com
   
2. intranet.ourcompany.othercompany.com

The form is now working correctly for all users. Thanks to John Gao, where ever you are, for finding the solution!!