SharePoint Health Check-Up can improve stability and performance of your SharePoint
SharePoint Managed Services to improve system reliability.
This post describes why you might want to use different URLs for your SharePoint portals and the best practices to avoid issues with search, security.
It's a deep dive into AAM (alternate access mappings) and the hidden issues that you may encounter by using different zones. We learned this from trial and error through our SharePoint consulting and we hope this may save you time.
Why would you use multiple URLs? You may have an internal name for your portal such as "ourportal", and a fully qualified name for use externally such as "ourportal.domain.com". Or you may be undergoing a migration where you're trying to use multiple names for one portal. Eventually it will become "ourportal" as you're going from one version to the other but for brief time it may be "newportal" and "oldportal". The use of which zones you use have a lot of behind the scenes consequences for search and other aspects of SharePoint.
Before getting into the nitty-gritty, I want to chat about AAM at a higher level. What is AAM and what does it do? In short it tells SharePoint which URLs are associated with which web applications. You have at least two web applications in your farm (Central admin and your portal site), and probably more. When someone types in ourportal.domain.com, the request gets to SharePoint like so:
If you have everything configured properly except for AAM, SharePoint likely won't know what to do with the requests that you're sending it. At best the site will work very poorly, and more likely won't come up at all.
Every SharePoint web application has a corresponding IIS site. In fact it's possible to have multiple IIS sites associated with one web application if you "Extend" the web application. The URL(s) that you use to access a SharePoint web application need to be listed in AAM. The URL(s) also need to correspond to the correct IIS sites.
We recommend using IIS host headers unless you have a specific reason to not use them (such as a firewall that doesn't handle host headers). Otherwise every IIS site will need to be on a different port, which gets ugly quickly as you will have users browsing sites on alternate ports (such as extranet.domain.com:81). Using host headers allows IIS sites to share a port (such as 80 or 443) and requests are routed based on host header rather than just IP and port combination.
Since we're about to start discussing AAM configuration, it is worth noting that changes made to AAM in Central Admin are not made automatically to IIS bindings. If you're making manual changes in one place, you must make them in both places.
If you're making changes to SharePoint AAM, 95% of the time you want to go to Central Admin > Configure Alternate Access Mappings > Edit Public URLs, and select the web application of interest. For each web application, the default AAM zone should be set to the default internal URL. This can be using a short name (http://ourportal) or fully qualified (http://ourportal.domain.com) as long as the URL resolves directly to the SharePoint server's internal address. (Tangent: If using a fully qualified address, please for the sake of your users configure it in all user's "Intranet Zone" in IE!)
Aside from not having the correct URL configured in AAM at all, the number one mistake is related to search configuration. The search Content Source must be configured to crawl the default zone's URL. Don't try to work around this, it doesn't work properly any other way. As changes are made to default zones in AAM, new URLs will automatically be added to the default search Content Source. Old URLs will not be removed automatically. Be sure to verify the configuration and remove any old URLs from the content source.
The default zone is important for several reasons including search. Set this appropriately for each web application. Now let's say you want to add a second URL to your web application(s). You will be using http://ourportal internally and https://ourportal.domain.com externally. As mentioned above, you will want to edit the public URLs for your web application(s). You have 4 more zones to choose from; Intranet, Internet, Custom, and Extranet. Does it matter where you paste in your external URL https://ourportal.domain.com? These 4 zones are identical. They could be named 1, 2, 3, and 4. The names do not matter and are only a suggestion, so it does not matter where you put your external URL. However, it IS very important that you're consistent with your URLs if you have multiple web applications!
The reason that it matters primarily resolves around search. Let's say you added https://ourportal.domain.com to the "Internet" zone for that web application. If you are browsing that web application on that URL and perform a search, results from other web applications will be returned using the other web application's "Internet" zones as well. If your second web application is misconfigured with an internal-only URL in the "Internet" zone such as http://portal2, the results you see from that web application in ourportal will be using that wrong URL and all links to items will be broken.
As another example, let's say you've configured your AAM as shown in the table below. Now you browse https://ourportal.domain.com and perform a search. You want results from Portal2 to be returned with the address https://portal2.domain.com. However that URL is added to the wrong zone. Results will be returned from Portal2's "Internet" zone. Since this is empty, search will fall back to using Portal2's default zone, and again broken links are returned in Ourportal.
Firewall issues can also require some adjustments to AAM. This is one of the scenarios that falls outside of the 95 percentile above. You will likely need to do this for external users if you terminate SSL at your firewall. See the image below. All 4 URLs are the same except the lower left which is HTTP instead of HTTPS. Here we've made it so that if portal.domain.com is typed in (using either HTTP or HTTPS) it will automatically redirect to https://portal.domain.com. This effectively maps the HTTP URL (being passed to SharePoint by the firewall) to the proper HTTPS URL.
This is done by clicking "Add internal URLs", and adding the HTTP address to the "default" zone. Note that this will make it so that if an internal user types http://portal.domain.com they will also be redirected to https://portal.domain.com, so in this case the HTTPS address needs to work internally and externally. These external address could be listed instead in a different zone with something like http://ourportal for the default zone to work around that problem.
Lastly, it's worth mentioning extended web applications. Microsoft's official stance is that if you are adding a URL to a web application, you should extend the web application to do so rather than directly manipulating AAM. The benefit is that SharePoint handles the IIS binding automatically for you, if you do everything just right. However, extending a web application creates an additional IIS site which adds complexity and uses memory. There is no harm in manually configuring AAM as long as it's configured properly.
We generally do not recommend extending web applications for simple things like adding a URL. There are times however when extending a web application is a requirement. The primary reason for this is different authentication methods. For example, you can (and should, for search) be using Windows Authentication on the default zone. And you could be using FBA or ADFS on the extranet zone. This would require extending the web application to the extranet zone. All topics covered above still apply (zones with multiple web applications, etc).
Mention this post and we'll send you a white paper on all of the ways we can help you use SharePoint more efficiently!