Firstly I am looking for an OOTB way on premises for SP2013 - I can do this by hacking around with additional headers. The purpose is to have multiple web apps using AAM all have a single global search centre. After all what is the point having a global search centre if you need multiple search centres? - I have done it that way for the interim

Okay here is a topology:

Internal users use:

  • intranet.companyname.net -> default zone

External users come through a trusted provider on

  • extranet.companyname.net -> internet zone

The Intranet has some sites that cannot be accessed from the Extranet address but all of the Extranet can be accessed from the Intranet. So far simple.

There are three web apps:

  • Portal
  • MySites
  • SearchCentre

Each web app has AAM for the two addresses intranet and extranet

  • intranet.companyname.net / extranet.companyname.net
  • my.intranet.companyname.net / my.extranet.companyname.net
  • search.intranet.companyname.net / search.extranet.companyname.net

But I cannot for the life of me find a way of telling the Search Service Application it has to send internet zone users (Extranet) to the Extranet form of the search address and change the search results accordingly (Links to items are the links in which they were indexed and are absolute)

SO how do you achieve this in 2013, how do I tell all the sites to dynamically alter the global search URL according to zone, and how do I dynamically change the results per user.

I'm hoping that the zone will be picked up by the search but I am doubting it.


To answer the comment from Mike Oryszak the only way to achieve that surely would be to use one web application for all three site collections. As we know best practice for MySites dictates to separate it on a separate web application. This also doesn't fix the issue with item urls and different zones. (Although you could force it to use the extranet address all the time with server name mapping to get around this).

So what would the solution for this now become? Moving to a single web application is a less than desirable solution, so would be creating a SearchCentre on the MySite application and having to application. A 3 web app solution for this in my book as stated above be the best practice period. One web app per site collection type and keep full segregation of sites.

To answer tereško I have 2 WFEs, Crawl server acting as fail over WFE, a Distributed Cache Server, 2 Application servers and a Database cluster. Total of 98GB ram and 20 CPUs over the boxes for a medium deployment, the design is scalable quickly being able to add further to the farm.

[update for bounty reward]

The answer should comply with the topology and outline (Out of the box only) procedures to solve the issue at hand. This has already been done with a little slight of hand on my part with some code to control the search urls from the search controls and the search results. BUT this should not have to be done with something that should be OOTB. 500pt. Let's do this.

[update] Half the issue sorted: Extend the webapps to the new addresses instead of using AAM to solve the url issue.

  • 1
    What is the reasoning behind putting the search center on its own web app? There are no real benefits, and really only added complications especially for external users that will have to authenticate multiple times. Putting the search center in a site collection for the intranet/extranet web app should resolve your issues. Commented Jun 21, 2013 at 16:20
  • out of curosity What is your server topology looks like and did you follow microsoft logical topolgy then which one ? thanks.
    – tereško
    Commented Jun 21, 2013 at 16:24
  • Typically MySites is not exposed to external users both for licensing reasons and for security reasons since you wouldn't want external users viewing details about internal users. When working with external users, typically I work to minimize the web applications for the external users. The zone should be handled automatically for search centers on those web apps. Commented Jun 21, 2013 at 16:37
  • Both Intranet and Extranet users would be licensed for MySites and this is a strict requirement.
    – Hugh Wood
    Commented Jun 21, 2013 at 16:42

2 Answers 2


This can be achieved by Extending each of the web applications instead of specifying AAMs only. The steps from where you are now would be:

  • On each web app, remove the AAMs leaving the default one only
  • On ISS Remove IIS bindings for the deleted AAMs on each of the SharePoint servers for the respective web sites
  • On Central Administration => Manage Web Application, select one Web App at a time and Extend them to each zone specifying the respective AAM
  • Make sure you have a Content Source point to the Default AAM urls for each web app and that you have NTLM auth provider enabled on them
  • Run a Full Crawl

That should be it. You search results will return links matching the AMM you are coming from. This solution has nothing to do with topology and will work for any.

  • Basically the "fix" would be to have one website per zone (For the search results anyway. Also could you cite an official set-up page for this stating how this works if possible?)? While I check the configuration I will say, if this sorts one issue and it is indeed just a simple configuration missing in the environment, can I ask how do you set up the search centres so they work with the multiple addresses?
    – Hugh Wood
    Commented Jun 24, 2013 at 8:12
  • Yes, SharePoint will create new IIS web sites for each extended web app you create.You do not have to worry about how you setup your search centre as the URL are sorted at indexing time. Just make sure it is setup against the right scope. It can also be deployed to its own web app as long as it is associated with the right service application proxy group. Commented Jun 24, 2013 at 9:19
  • Okay half the issue sorted, if you can solve the other half a full 500, or I will reopen with 250 afterwards for you.
    – Hugh Wood
    Commented Jun 24, 2013 at 9:44
  • 3
    Hugh, I don't think what you are trying to do is possible without custom code. If I were you I would reconsider the current design to an OOTB supported one, such as creating a Search Center site collection per web app. Create an explicit managed path called Search for each web app and set you new Search site collection Url to <Default Zone AAM>/Search. Go back to your site collection search settings and specify a relative path to /Search/..Get rid of your current search web app and you are done. No custom code, whole solution, fully supported, working as expected no matter where you come from. Commented Jun 24, 2013 at 12:30
  • 1
    Hugh, we might have to rely on reverse proxies such as ISA Server to translate urls from the External zone back and forth. This is an excellent blog post that can be used as a reference. This will get you to a single search web application experience you are after. Commented Jun 30, 2013 at 16:08

It's not going to be possible from the SharePoint side without code. You can do it via IIS and the URL Rewrite Module. You would still utilize the same extended web app topology @Miguel Lima provided.

Microsoft doesn't support re-writing SharePoint URL's but you can use the redirect function to achieve this.

Simple create a rule that when you access an the internal Search address from external you are redirected to the external page and vice versa. Your Search Center URL is already extended with proper AAM's so results should come back properly after the redirect.

The redirect also happens pretty quick so users will probably in most cases not even notice.

all that being said, I favor the dedicated search center approach per site collection. The long term care and feeding is pretty easy and I don't have to worry about backing up the IIS configuration separate from what I have stored in my content database.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.