Blog

In the early days of building SharePoint Intranets on SharePoint 2003, many organizations did not have remote access strategies for employees. The choice of a URL for a SharePoint site often reflected a preference for short, user-friendly names that took advantage of automatic domain suffix mapping to auto-complete the fully-qualified domain name. For example:

http://intranet
http://mysites

In this case, the fully-qualified domain name might be “intranet.company.com”, but DNS would resolve the name correctly by assuming a DNS suffix related to the current Active Directory domain. It was assumed that employees would be accessing the Intranet on the company network. For organizations that did support remote access using VPN strategies, this also worked fine.

When SharePoint 2007 was released, it became easier to support additional variations in the site address to accommodate more sophisticated scenarios by using Zones. It would be common to configure sites to use Zones to support short names for the “Default” zone for internal company users, and fully-qualified domain names for corporate WANs and/or secure Internet access.

Originally, there were some technical constraints influencing this design. SharePoint Search could not crawl sites that used Kerberos or were secured by SSL on the default zone.

Fast forward to the beginning of 2010, and the technical constraints are now mostly gone through the release of Service Packs and Hotfixes, and I have been discovering some issues with this strategy:

• Desktop tools that integrate with SharePoint often require the fully-qualified domain name (ex. Colligo Desktop). Users often cut and paste these URLs from the browser, so displaying the fully qualified domain name for the site is becoming more of a necessity.
• In response to a more mobile workflow, organizations are increasing exposing SharePoint sites to the Internet for direct access. Users now have to contend with bookmarked and embedded document hyperlinks that are a mish-mash of unqualified and qualified domain names.

My recommendation to clients now is to standardize on fully-qualified domain names, and restrict the use of alternate Zones to the specific purpose it was designed for – supporting alternate authentication providers.

Thankfully, we can still take advantage of some tricks with Zones to continue to support the user-friendly unqualified domain names by having SharePoint re-write the unqualified names to the fully qualified names when a user browses to the site.

1. Create your SharePoint web application using the fully-qualified domain name for the Public URL. SharePoint will automatically add the appropriate IIS host header. If you have an existing site you want to convert to a fully-qualified URL, then edit the Public URL under Alternate Access Mappings.
2. Open IIS Manager and edit the bindings on the web application you created. Ensure that both the unqualified and fully qualified domain names are included on the web application.
3. Open Alternate Access Mappings and add a new Internet URL to the default zone for the unqualified domain name. The Public URL will remain the fully qualified domain name.

The final configuration in SharePoint will look like this:

Now when the user enters “http://intranet” into their browser, SharePoint will accept the unqualified domain name, but re-write the URL to the fully-qualified Public URL ensuring standardization and consistency.