Joel's SharePoint Architecture Blog

SharePoint Server, SharePoint Online and Office 365 Training, Architecture, Administration and Development

WSS 3.0 and MOSS 2007 tips #6 – Popular Misconceptions – Alternate Access Mappings, Web Applications and Zones

by

In this blog post, I’m going to try and address a few misconceptions about SharePoint AAMs, Web Apps and Zones.

Popular Misconception #1: I create a new Web Application for my Intranet site, then to expose it to my Extranet audience I just set up an Alternate Access Mapping Public URL for the Extranet Zone.

Nope. Not really. There’s quite a few moving parts involved.

Web Applications and Zones

Web Applications map on to one or more IIS Sites. When you create a Web Application, you get your first IIS Site for it (IIS Site #1 above) and it creates a mapping called the “Default” Zone. You can then administer Authentication Providers for your Web Application and tell SharePoint how you want your IIS Site and Default Zone to authenticate users:

    • Windows Authentication
    • Forms Authentication
    • Web Single Sign On

    Typically, the Default Zone will be used for local machine-name/domain-name access to a site, e.g. http://server1 or http://intranet. But this really is entirely up to you what Default means. If your intention is to take your Web Application and also expose it via https as intranet.mycompany.com, then you need to “Extend” your Web Application (Central Admin –> Application Management –> Create or Extend Web Application) into a Zone (say, for the sake of the argument, “Extranet”) and give it a Load Balanced (or Public) URL of https://intranet.mycompany.com. Then you can edit the Extranet Zone under Authentication Providers, and enable SSL.

    Note: you probably need to make sure all the domain names you use exist in some DNS server somewhere, and that you can resolve them properly.

    Popular Misconception #2: Alternate Access Mappings are just host headers. I can just add Internal URLs for each host header I want to support in a Zone, and it’ll just work.

    Ah, no. Two problems here:

    1. When you add an Internal URL, it doesn’t automagically configure the Bindings of your IIS Site for you. You’ll need to check that these exist on your Site for in IIS Manager.
      IIS 7 - Adding a Site Binding
    2. This is a fundamental misunderstanding of what Public URLs and Internal URLs are for in AAMs. You have one Public URL per Web Application per Zone. When any user visits a page via that Web Application and Zone, any resources (images, scripts etc) mentioned in the body of the returned HTML of pages, will have hard-coded links to the resource under the Public URL. If you add an Internal URL for someone to use from outside the LAN, all the resources on that page will still be hard-coded to use the Public URL; in other words they’ll get broken images.
      Yes, this is a broken image in IE saved as a JPG which *isn't* broken...

    Which brings me to a pair of misconceptions about Zones in SharePoint.

    Popular Misconception #3: Default Zone, Extranet Zone, Intranet Zone, Internet Zone and Custom Zone have specific meanings. I must choose carefully when I extend my Web Applications!

    And…

    Popular Misconception #4: Default Zone, Extranet Zone, Intranet Zone, Internet Zone and Custom Zone have no specific meanings. I can choose whatever I like when I extend my Web Applications!

    Neither of these extreme views is entirely correct. In fact, you are free to choose. None of these Zones has any intrinsic meaning. A Zone will let you specify a Web Application’s authentication provider, encryption and access details and the collection of URLs that can be used to access the content. The important thing is this: if you decide to use the Intranet Zone to mean SSL access to your Intranet Web Application, then you should use the Intranet Zone to mean the same thing for other Web Applications.

    I’ll give you a “for example”: one of my students had some weird behaviour in her live SharePoint site. The My Site links on her Intranet worked OK inside the company firewall, but over HTTPS outside the firewall, links to My Site were not generated using HTTPS. This is how things were set up:

    • Content Web App #1
      • Default Zone configured to allow requests from https//intranet.mycompany.co.uk
      • Intranet Zone configured to allow requests from http://intranet
  • My Sites Web App
    • Default Zone configured to allow requests from http://mysite
    • Public URL for the Intranet Zone set to https://mysite.mycompany.co.uk

    • Two problems: there was no “Intranet” Zone for the My Sites Web App, and we’ve got Zones with the same name doing different things from each other in each Web App. We had to delete the Public URL for the Intranet Zone of the My Sites Web App, so we could extend the Web App into the “Intranet” Zone without errors and set the URL to http://mysite.mycompany.co.uk. We then set the Default Zone authentication provider to allow SSL.

    • Content Web App #1
      • Default Zone configured to allow requests from https//intranet.mycompany.co.uk
      • Intranet Zone configured to allow requests from http://intranet
  • My Sites Web App
    • Default Zone configured to allow requests from https://mysite.mycompany.co.uk
    • Intranet Zone configured to allow requests from http://mysite

    • So now things work as we expect them to: when you visit the main site at http://intranet, the My Site link is generated as http://mysite; and when you visit https://intranet.mycompany.co.uk, the My Site link is generated as https://mysite.mycompany.co.uk.

    Thanks for reading!