| 05/11/2012 update: since writing this, the official SP2013 software boundaries article has been updated to include a supported limit of up to 20 Web Applications per SharePoint 2013 farm. This is in line with what I have heard from various SharePoint MCMs. |
|---|
Designing a URL structure for a SharePoint farm sounds like a straightforward task. Surely it’s just a case of creating a few Web apps and corresponding DNS entries, right?
The challenge is balancing simplicity with scalability. Most people who have managed IIS know what a host header is so the traditional approach of creating a Web application for each host-named URL often seems like a good idea when first starting out.
Sooner or later, however, you will probably run into one of the following limitations:
- A limit of around 20 Web apps per farm (a SP2010 recommendation)
- A limit of 10 application pools per Web server
- A unique IP/port/host header binding per IIS Web site
Although I’d like to explore the reasons for the above limitations (as I have done in the past), I thought I’d start with a high-level set of recommendations in the form of a cheat sheet. As you will see, each option will involve some form of compromise but I am slightly biased toward the host-named site collection approach (especially as we now have the Set-SPSite cmdlet). In fact, even Microsoft are biased toward host-named sites – given that they use them for Office 365 that isn’t very surprising.
Note that the options below are not mutually exclusive – it’s entirely possible that your farm will include a mixture of Web applications containing both host-named and path based site collections.
I would really like to hear about your experiences with building scalable SharePoint URL namespaces as it’s something I often get asked. I’m sure you will think of something that I haven’t considered.
| One important caveat I would like to add is that I have not yet had a chance to really test the new Set-SPSiteUrl cmdlet other than briefly on a SP2013 VM I built a couple of weeks ago. Hence, I would strongly recommend that you test your scenario extensively before spending time – and taking the risk – of implementing in a production environment. Heck, the beta has only just been released :-). |
|---|
| Requirement | Capability | Benefits | Drawbacks | Example |
| Only a few unique host named URLs (less than 20/farm) – e.g. a corporate intranet. | Host-named Web applications | Easy to manage; familiar to IIS admins | Doesn’t scale beyond ~ 20 Web apps. | Web app 1 (host-named):http://portals
Site collections (path based): /marketing /it /sales
|
| Web app 2 (host-named):http://teams
Site collections (path based): /projects /adhoc
|
||||
| Web app 3 (host-named):http://extranet.contoso.com
Site collections (path based): / (root)
|
||||
| IIS App Pool isolation between host-named URLs | Host-named Web applications | See above. | Doesn’t scale beyond 10 Web apps (due to a supported limit of 10 application pools) | See above; each Web app resides in its own application pool. |
| Out of the box self-service site creation | Host-named Web applications | See above. | See above. | See above. More info available on Microsoft’s SP2013 IT Pro training site. |
| More than 20 unique URLs per farm – e.g. a hosting scenario or large corporate farm. | Host-named site collections (HNSC) | Hugely scalable (supported limit of 250,000 site collections per Web application!) | More complex to manage- need an additional IP per Web application containing HNSCs (ormanage host headers outside of SharePoint) | Web app 1:No host header, unique IP address
Site collections (host-named):
|
| Web app 2:No host header, unique IP address
Site collections (host-named):
|
||||
| Web app 3:No host header, unique IP address
Site collections (host-named): |
||||
| To make site collections available via multiple URLs – e.g. if hosting content to internal users and customers. | Option 1: Alternate Access Mappings (AAM)
|
Access one site collection with multiple URLs for different use cases | Not compatible with host-named sites | Web app 1 (host-named):http://extranet.contoso.com
Default zone (Fully qualified domain name):
Intranet zone (host name only):
|
| Option 2: HNSC with Set-SPSiteUrlCmdlet – new in SP2013 | Supports multiple URLs in a scalable manner. | Managed via PowerShell only. | Web app 1:No host header, unique IP address
Site collections (host-named):
Additional Site collections URLs:
|
|
| To use standard HTTP ports (80/443) – why wouldn’t you do this? J | All approaches support this. | Sites are easily accessible and managed | – | |
| SSL | All approaches support this. | Transport security | Requires a certificate |
Pingback: SharePoint 2013 Webinar Playback, Web Architectural Changes « Tom Resing's SharePoint Blog