Found (the hard way) that SharePoint 2010 is not happy when an Alternate Access Mapping is configured with a port on the public URL that is different than the port on the corresponding Internal URLs.
For an extranet I was creating using SharePoint Foundation 2010, we were using port 80 on the external-facing side of the firewall. The firewall was redirecting those calls to port 81 on an internal IP address. So I had setup the extranet zone in AAM to have [some site]:80 as the public URL, and [some internal ip address]:81 as an Internal URL in that same zone.
[Various reasons for not using host headers in this instance, and for using port 81 for the SharePoint web app!]
Could access the site inside the firewall, but failed to get to the SharePoint pages from outside. Much analysis using Fiddler and the MS Network Monitor 3.4 (great tool, that one - really easy parsing of results) revealed that something was redirecting the client from [some site]:80 to [some site]:81 for the external calls. Still don't know whether IIS or SharePoint was responsible for this - just know that by changing the firewall to pass through on port 81, and calling [some site]:81 from outside, then all was well again.
So what I learnt today - don't mix ports across AAM internal and external URLs
Monday, June 20, 2011
Wednesday, June 1, 2011
Refinement Filtering in the SharePoint Search URL
The refinement filter querystring is the "r" term in a search result page URL. An example of its use is
The value of the “r” term in the querystring decodes to
Some documentation (and the links generated by the refiner web part) use a “=” character, but in my experimentation it seemed that only the “:” character would return results. Further research has shown that the “:” (%3A) character denotes a “contains” comparison whereas “=”(%3D) not surprisingly means “equals” (and yet the “equals” operation does not seem to retrieve any results in my trials)
http://intranet/search/pages/phonelist.aspx?k=christchurch&r=department%3a%22Human%20Resources%22
The value of the “r” term in the querystring decodes to
Department:”Human Resources”
Some documentation (and the links generated by the refiner web part) use a “=” character, but in my experimentation it seemed that only the “:” character would return results. Further research has shown that the “:” (%3A) character denotes a “contains” comparison whereas “=”(%3D) not surprisingly means “equals” (and yet the “equals” operation does not seem to retrieve any results in my trials)
Subscribe to:
Posts (Atom)
