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.


About Cameron Dwyer

Architect and developer at OnePlace Solutions. Passionate about delivering compelling solutions on the Office 365/SharePoint platform. Addicted to coffee.

Posted on August 4, 2014, in Office 365, PowerShell, SharePoint and tagged , , , , , . Bookmark the permalink. 3 Comments.

  1. So, were you able to update the property and fix the issue? The post I’ve linked to below indicates that this doesn’t work in 2013. I tested as shown in the SP 2010 blog post that he linked to and indeed it didn’t work as expected in 2013.


    • Hi Tommy, I wasn’t able to find a way to change this property. In the context under which I was using it (a remote application) I was able to take one of the other URL type properties (that does adhere to AA mapping) and do some URL manipulation to change the problematic URL before I used it. This may not be an option for you though.


      • Hi Cameron, what other URL type properties are you speaking of? I tried setting UseAAMMapping for my managed property and it showed = true but then I rechecked it and it reset back to = false. Definitely weird.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: