| 05/11/2012 update: since writing this, the 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 per Web server
- A per IIS Web site
| One important caveat I would like to add is that I have not yet had a chance to really test the new 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):
Site collections (path based): /marketing /it /sales
|
| Web app 2 (host-named):
Site collections (path based): /projects /adhoc
|
||||
| Web app 3 (host-named):
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 | 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 |
| 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 !) | More complex to manage- need an additional IP per Web application containing HNSCs (or) | 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 | Web app 1 (host-named):
Default zone (Fully qualified domain name):
Intranet zone (host name only):
|
|
| Option 2: HNSC with Cmdlet – 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: