The site was then successfully accessible on the internet, though I did notice that the full path had to be entered in the browser address bar, including the page name itself - for example, https://[siteurl]/default.aspx rather than just https://[siteurl].
Further testing revealed that the links in the breadcrumbs all led to a "Page cannot be diaplayed" IE error, and submitting a search on the site gave an error message on the results page that stated:
"If the URL should be serving existing content, the system administrator may need to add a new request url mapping to the intended application"
The cause was all in the AAM entry - I had a port number (80) in the extranet URLs from some early trials, and had not removed this port number when setting https. By setting the Extranet zone AAM internal URL and public URL to be simply https://[ssiteurl], these problems were solved.
Interesting that the pages were still accessible with an incorrect Access Mapping!
2 comments:
Hi Gary,
Have you ever come across similar issues relating to some functions on published portals not "mapping" everything correctly?
Specifically in document libraries - manage permissions, checkin/out. I have recently seen the case where the extended/mapped application still uses the internal URL's sometimes...
I did come across one instance of some strange rendering behaviour for certain elements in a site, and it turned out to be caused by some incorrect permissions set on one of the SharePoint web applications within IIS.
The authorisation settings for the web application had been manually changed, causing problems around access to some of the standard virtual folders in each of the SharePoint sites. Sounds a little different that your issue, though
Post a Comment