Monthly Archives: August 2014

Beware SharePoint 2013 Search Results and the ListUrl Property

beware-caution-sharepointI was recently looking into the results returned by SharePoint 2013 under the scenario of alternate access mappings. Essentially this boils down to the same SharePoint content being available on different host URLs.

Here’s an example:

I can have a single site which I initially create on http://ourintranet, through the magic of alternate access mappings I can make the same SharePoint site also accessible on

SharePoint serves up exactly the same content irrespective of the URL host the user come in on. In the address bar of the users browser, the host portion of the URL remains constant as they navigate through the site e.g. if the user came in on they would not be switched over to the http://ourintranet host at any time.

These alternate access mappings carry across to search as well. The way this works is that the search processes will crawl the SharePoint site and index content based on one of the URLs (either http://ourintranet or, best practice is to use the access mapping of the default zone). When search results are requested the SharePoint server will find the matching results in it’s search index and then apply alternate access mappings to any of the URLs being returned so that even though the content was crawled and indexed with the URLs starting with http://ourintranet, if a user comes in on the URL and performs a search, then all search results will also use the access mapping.

Now to the issue with the ListUrl property being returned by search. This property simply misses the whole alternate access mapping transformation when the search results are returned and the value is read straight from the search index. Therefore the ListUrl property is fixed with the URL host that the search crawler is configured with. This means that when a user comes in on and performs a search, the ListUrl property will give back a result starting with http://ourintranet. Obviously this is not good and your users may not even have access to the content via the different access mapping.

Here’s an environment demonstrating the problem.

The initial site collection is created on http://vs-server38:83



The site collection is then extended (which creates the alternate access mapping) http://vs-server38:84



Through a browser we can now access the same site on http://vs-server38:83



or on http://vs-server38:84



The search content source is configured to crawl the content based on the default http://vs-server38:83 URL.


The screenshot below shows the results of performing a search query (via PowerShell) on the URL http://vs-server38:83. As you can see all URLs returned begin with http://vs-server38:83



This screenshot performs exactly the same search query only it uses the alternate access mapping of http://vs-server38:84. This time the issue is evident. The Path, OriginalPath and SiteName properties all return URLs that have been mapped to the alternate access URL I used. Note the ListUrl property still returns the http://vs-server38:83 based URL.



Delving further, each managed search property has a property called UseAAMMapping that seems to be the flag that tells SharePoint that the property contains a URL and need to apply alternate access mapping transformation when results are returned. Looking at the UseAAMMapping property through PowerShell we can see that the ListUrl property does not have this flag set while the other URL based properties (that work correctly) do have this flag set.


Running Fiddler with OnePlaceMail – Fixing “The requested site does not appear to have claims enabled or the Login Url has not been set” message

Here’s a workaround to get Fiddler working with OnePlaceMail and SharePoint 2013 where you normally get the following error message in OnePlaceMail as soon as Fiddler is enabled and capturing traffic:

“The requested site does not appear to have claims enabled or the Login Url has not been set”


I went investigating why introducing Fiddler breaks OnePlaceMail and was able to track the problem down to a single call to the native SharePoint 2013 People web service and in particular the IsClaimsMode method of the People web service. Under the default SharePoint 2013 install (Claims mode with integrated Windows NTLM or Kerberos Authentication) this web method return False without Fiddler and True with Fiddler running.

Using Fiddlers AutoResponder feature we can set up a rule to listen for calls to the IsClaimsMode method of the People web service and return a fixed response from a local file instead of getting it from the SharePoint server.

The particular Fiddler AutoResponder rule matching I used requires one of the later versions of Fiddler, here’s the version I was using: v4.4.9.2


First you need to get the following “response” file onto your computer so Fiddler can use it to respond to any calls made to the IsClaimsMode web service. Here’s the contents of the response file:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="<a href=""></a>" xmlns:xsi="<a href=""></a>" xmlns:xsd="<a href=""></a>">
      <IsClaimsModeResponse xmlns="<a href=""></a>">

It’s pretty simple, the web service really only returns a value of true or false. The condition the problem occurs is when the real web service gives back a true when it should be false.

In my example I’ve placed the file on the following path:


Now start up Fiddler and select the AutoResponder tab and check the following options:

– Enable automatic responses

– Unmatched requests passthrough


Click Add Rule and put the following match rule in (this will identify any web service calls to the IsClaimsMode method:



Now in the action to execute line choose Find a file… from the drop down


Select the AutoResponder file we created in the earlier step


The AutoResponder tab should now look like this


Using OnePlaceMail with Fiddler running should now work without raising the error.

%d bloggers like this: