I’ve been involved in a project where SharePoint is hosted by a third party and consists of two front end servers and a back end database server. This site is accessed by a typical Internet style address, https://myapp.companyname.com. Do you spot something that might by caused confusion yet? Yes, it uses https. But that’s not the real fun part, as when it goes through the third party’s load balancer it gets turned into http://myapp.companyname.com.
This caused much teeth gnashing and anguish as this results in all the links from SharePoint being prefaced with http and the the load balancer is only capable of translating some of the links back to https. So some links were prefaced with http and others with https. Fortunately a solution was at hand, Alternate Access Mappings!!!
Reading various blogs and articles gives the impression that this is deeply complex function of SharePoint but in fact it is simply a method to ensure all links point to the correct URL. In my case we needed to make sure that all our links started with https.
Now this is where I start to talk about zones. Zones enable us to access the SharePoint site from different parts of the network.
When the web application is created, the entered URL is used to access the site by default. Unsurprisingly, this URL is entered into the Default zone as the public URL. And all is fine and dandy. But what if the site can be accessed by a second URL?
In most cases, you may simply wish to redirect this second URL to the standard public URL. This can be done by entering it as an internal address to the Default zone and now, when the second URL is entered, all the links returned will be translated to the public URL. And that’s all there is to it.
Our site was being accessed by the public address https://myapp.company.com, (well, obviously, not really, but in that format) so we realised this needed to be the public URL. But the incoming request was to http://myapp.company.com, which was not recognised by SharePoint. Adding it as an internal URL in the Default zone caused all links to be translated back the the public URL and suddenly we had a fully operation site.
Unfortunately we hit another snag. We wanted to add an additional dedicated search indexing server but were unable to access the site using the default public URL from within the hosting companies own network. Alternate Access Mappings to the rescue again!
We needed to use an internal URL to access the SharePoint servers but if we simply added that URL to the Default zone, it would just spit the public Internet address out. We needed another zone.
The names of these zones are irrelevant, although they are conveniently named so it would be churlish to put an intranet address in the internet zone. We chose add the new Intranet URL to the Intranet zone as the public URL.
What this means is that a request sent to the intranet URL is now classed as in the Intranet zone and consequently, the public URL for the Intranet zone will be returned.
And that is that.
The are other advantages to separating your SharePoint site into different zones with their own unique URLs, you can tailor your content according the zone, for instance, offer the complete site to an Intranet address but a more limited access to the extranet, or Internet.
I shall have to look at that in more detail some time.
