SharePoint 2010: Search Service Application issue with Alternate Access Mapping

What is the description of this article?

In this article I am going to describe the setup and configuration required to have the Search Service Application successfully crawl your SharePoint 2013 web application even though you have an Alternate Access Mapping (AAM) setup with a URL which is different from your domain name.

What was issue?

At first the search for the web application worked successfully without any issues. After AAM changes were made the search crawl would complete in a approximately a minute and then give an error as shown below. If you attempted to search on the web application you would either get no results or only the home page.

https://nfukaa.dm1.livefilestore.com/y2pPHSl7sN6RCXSE-Said88mULDOj9tVPSsBdHE0u0ko1oBs-mSLPqPAJdTBNx6r0eDnBFDXmdekNaavEeXRvLUx3SRbUuqGMFgbBYnd793yUc/Capture1.png?psid=1

What AAM changes were made and why?

An intranet web application whose default URL is similar to http://intranet.domain.com was ready to be tested as an extranet i.e. public facing web app. The requirement was that the default URL and the external URL are going to be different. Changes were made using Alternate Access Mapping (AAM). The default URL is similar to http://intranet.domain.com and the external URL is similar to http://www.DomainName2.com. After the AAM was configured, the search crawl for all the other web apps (where no AAM changes have been made) worked except http://intranet.domain.com.

How to fix the issue?

Following are the steps taken to resolve the issue.

• Extend the web application. 
• Edit the Zones of the AAM. 
• Reset the Search Service Application Index. 
• Edit the URLs in the Search Crawl Rules.

Extend the Web Application:

When extending the web application to another IIS website, it is imperative to match the following settings i.e. the settings for the extended web application should be the same.

• Port Number should be the same. 
• Keep the Host Header blank. 
• Security Configuration to be the same. I my case I selected 'Yes' for 'Allow Anonymous'. 
• Claims Authentication Type should be the same. 
• Have a URL that makes sense to you. In my case I kept it as http://SERVERNAME 
• Keep the Zone as 'Intranet' 

Once an extended web application has been setup when you go to Central Administration>Application Management>Manage Web Applications select your web application and click on Authentication Providers, you will see two listed. Below is a screenshot.

https://nfukaa.dm2303.livefilestore.com/y2pn45nhxFof4CxBATgf1741RbJCOzwhvnhBGg4lXbFJFtbx273g-kWV9llcMRdeuSJ9CbCF1TF4OPRvhwLgDCpWxWtYXI6wH3H5ffsFB2XV64/Capture2.PNG?psid=1

Also, go to IIS Manager and confirm that a new Site has been created.

Edit the Zones of the AAM:

 The AAM needs to be re-structured for the Search Service to work.
Go to Central Administration>Application Managed. Under Web Application select 'Configure Alternate Access Mappings'.
In AAM you will see all your web applications. To the top right of the page you will see 'Alternate Access Mapping Collection:' select your web application there.

• Initially you will see the AAM collection as follows- 
• Default: http://intranet.domain.com 
• Intranet: http://servername 
• Extranet: http://www.DomainName2.com 

Click on 'Edit Public URLS' and make changes to match the following mapping.

• Default: http://SERVERNAME 
• Intranet: http://intranet.domain.com 
• Extranet: http://www.DomainName2.com 

Keep the Internet and Custom Zone as Blank.

While changing the Default Zone you may get the following error.

https://nfukaa.dm2304.livefilestore.com/y2pSLZWPm9IVnsCD_aXFvcw5Me0usgAvPYPfyjA_WvGT9F3CkQk-zZ4m2oZlc-OznKbhQuXPFJEF8kixmDJ41P3tC_hVg5vc5tWEuYb-FbOQxM/Capture3.PNG?psid=1

To work around this error make the changes in the following manner:
First, copy the URL from the Intranet zone and paste it in Internet Zone. Delete the Intranet zone and keep it blank.
Next, copy the URL from the Default zone and paste it in the Intranet zone. Delete the Default zone and keep it blank.
Finally, copy the URL from Internet Zone and paste it in the Default zone. Delete the Internet zone.
Click Save

Reset the Search Service Application Index:

Go to Central Administration>Application Management, under Service Applications choose Manage Service Applications, choose Search Service Application.
As shown below, click on Reset Index.

https://nfukaa.dm2304.livefilestore.com/y2pg1QfiGnq5W55FqC1FovR1vCyiMSzxJx-9g4dbkyiWJBbXqCmvUJv7s7xmXFYuTGqncGzHHavHxDfRuB7Zvn0HltSnRuzxFz5svoo5iybufw/Capture3a.png?psid=1

In the Search Service Application, click on Reset Now. Depending on the size of your content database this reset process can take a couple of minutes.

https://nfukaa.dm2304.livefilestore.com/y2psRJLvTXm8HMmN6-wW22RxPeO164gfj1mJNLazZ1NwUOXflakjoPQKam8fn3HzkLixl1ZpHlktFuPcex9bCAdbgKgvhHFHGIgPmu18rMZ2NU/Capture3b.png?psid=1

Once the index reset process is completed go back to Search Service Application and click on Content Sources.

https://nfukaa.dm2304.livefilestore.com/y2pTYWJRahrnkcKFFdifO9yhUh8NPPkktraZRymY-8QC86wkpoyFmqf3O93UtnoW3Brf8F5mp3HFs2XxR5-JJoud_II1EaswTtnGe1uTiRyPZA/Capture7.PNG?psid=1

In Content Sources you have two options.

1. Keep your new web application in the Local SharePoint Sites or
2. Remove your web application from Local SharePoint Sites and add it to a New Content Source.

In my case I created a New Content Source, selected 'SharePoint Sites' as the type of content and added http://SERVERNAME as the URL. You can set the Craw Settings and Crawl Schedule to match your requirements. Keep the Content Source priority as Normal. Start a Full Crawl for your new content source. This time your crawl will run all the way successfully!

Edit the URLs in the Search Crawl Rules.

After the new search crawl had completed I tested the search in my web application at www.DomainName2.com. I quickly realized that the rules I had setup weren't working. Hence I had to edit the rules I had originally setup, in my case I had to replace http://intranet.domain.com with http://SERVERNAME. Run a Full Crawl again for the search filters to take effect.

Conclusion.

Unless you are a large enterprise company with several domain names, the chances of you creating a new AAM with a URL that is different from the Active Director domain name is slim. However, now you know what issues to expect and how to resolve them. Throughout this process I did not make any changes to the existing IIS bindings for the Site. Also, I didn't add any new bindings to the new Site for the extended web application