Having just received our SharePoint 2010 Evolution Conference DVDs, I couldn't resist browsing through the vast quantity of slide decks provided by Combined Knowledge. Spencer Harbar's deck on Multi-tenancy immediately grabbed my attention given that hosting is a core part of what we do.
Multi-tenancy in the context of SharePoint is Microsoft's term for "hosting". In SharePoint 2007 (MOSS), hosting a SharePoint environment with multiple tenants was a significant challenge. Issues included a limitation on the number of Web applications that could be created, site collection management / isolation problems and URL namespace restrictions.
In SharePoint 2010, Microsoft have to a large extent dealt with the last two issues mentioned above. Creating a large number of Web applications within a single farm still causes resource problems so the preferred scaling approach for hosting companies is likely to be to go with site collections - especially considering they can now be partitioned and managed by tenants themselves.
Host-named site collections in MOSS were generally considered a no-go. On paper, they did not support managed paths or SSL termination. In practise, they were fraught with issues and administrators generally avoided using them.
So what's changed for host-named site collections in SharePoint 2010? In short, they are fixed. By this, I mean:
- · Managed paths are now supported.
- · Off-box SSL termination is now supported.
This makes it entirely possible to have "vanity URLs" on a per site collection basis. For example (domain name ownership issues aside), you could have www.microsoft.com for one site collection and www.ibm.com on another - within the same Web application.
I should mention at this point that there is one limitation around host-named site collections that you should be aware of: they do not support alternate access mappings and are therefore always considered to be in the default zone. Additionally, host headers cannot be applied at the Web application (IIS site) level, and doing so makes it impossible to access host-named site collections (IIS ignores requests that do not match the host binding). Read more on Technet.
Demo: setting up multiple host-named site collections in one Web app
Prerequisites:
- · A SharePoint 2010 test server (foundation will do).
- · Access to PowerShell.
- · A Web application that does not have a host header applied at the IIS Web site level.
DNS Entries for vanity URLs
OK so I dont imagine setting up a couple of DNS entries is going to be tricky for the IT pros out there. However, I will include this step for those who may not be familiar with DNS administration.
Add new forward lookup zones for your vanity URL domains, e.g. "microsoft.com" and "ibm.com".
Within each lookup zone created above, add a new host, e.g. "www" with an IP for your test server. On my test VPC I just added 127.0.0.1.
DNS entries for vanity URLs
Create Web application
If you don't have an appropriate test Web application, go ahead and create one. Ensure that you do not apply a host header at this stage.
Ensure you don't apply a site level host header
Create host-named site collections using PowerShell
Open up the SharePoint 2010 Management Shell and enter the following commands to create a new site collection for each of your desired vanity URLs. In this case I have created a site collection with the host name www.microsoft.com:
New-SPSite http://www.microsoft.com -OwnerAlias DOMAIN\username -HostHeaderWebApplication http://servername
Entering the PowerShell commands; don't forget the dash before HostHeaderWebApplication!
You should now be able to access your new site collections using the vanity URLs you have specified. You have successfully created multiple host-named site collections within one Web application demonstrating the use of vanity URLs to cater for multi-tenant scenarios in a scalable manner.
All done - your new host-named site collections should be accessible
Summary
Host-named site collections are vastly improved in SharePoint 2010 when compared to previous versions. This, combined with the other benefits mentioned above such as improved tenant administration and data partitioning for site collections provides a compelling case for hosting companies to upgrade. If you are interested in multi-tenancy in SharePoint 2010 I would strongly recommend you check out Spencer's post linked at the beginning of this post.
Subscribe to the RSS feed
Follow me on Twitter
Follow my Networked Blog on Facebook
I was hoping to get lucky and use this method to provide seemless single-signon between different domains since the site collections are theoretically in the same web app, but without a proxy server, my tests indicate each domain setup as a separate hosted site collection requires it's own authentication.
ReplyDelete-> https://dev1.company.com
-> https://dev2.company.com
Is that the case? Are my tests accurate? Is a reverse proxy the only way to do single-signon between these different urls? Since I have dozens of these, i can't use alternate access mappings, and multiple web apps also requires multiple logins.
I am assuming that the users are external to your domain if they are being prompted to logon.
ReplyDeleteI am not aware of a means of providing "SSO" in this sense without using a generic domain level cookie - at least not on the server side.
Dependant on your scenario you might want to consider a reverse proxy anyway - especially if these are extranet sites. If it's just for development you could probably get away without one depending on your security requirements.
What steps are required to create a host header after a site collection is already created? We want to go back and create host headers for each department site. Everything I see indicates creating a new site collection and moving the content???
ReplyDeleteBill,
ReplyDeleteAre you referring to MOSS or SP2010?
I don't believe you can "apply" a host header to a site collection - they are either created as host-named or path based.
Also note that you can't use host-named site collections if a host header is set at the IIS site (Web app) level.
You could in theory apply an IIS redirect from a vanity URL if that meets your requirements, but otherwise you will need to move the content.
Thanks, Ben. I used powershell Backup-SPSite and Restore-SPSite and the move was painless and implemented the host header without any issue.
ReplyDeleteHello Ken. The user running the PowerShell command needs permissions on the content database which the site collection will be added to.
ReplyDeleteHi Ben,
ReplyDeleteI came here in desperation after reading all the official documentation about HH sites (which isn't much).
No matter what we do, we continue to receive the IIS7 Welcome screen. The only thing I can think is that we applied a host header to the WebApp root site during provisioning.
You state that this is a no-no but I can't find this in any MS resource. Where did you see this "significant caveat", cos it sure would have been good to know in advance!
Hi Tripwire,
ReplyDeleteThe limitation is that you cannot apply a host header at the IIS site (Web App) level.
This is quite simply because if you do this IIS will only listen to requests sent to that host name.
If this is a brand new Web app the easiest option might be to recreate it, leaving the host name blank.
Otherwise, you could potentially change the host header within IIS manager (not ideal as it will then be out of sync with the SharePoint config DB).
The Technet documentation does cover this (http://technet.microsoft.com/en-us/library/cc288637.aspx#section8):
" Host headers at the IIS Web site level are only intended for path-based site collections. Host headers at the site collection level are only intended for host-named site collections. In most cases, applying a host header binding at the IIS Web site level makes it impossible to access host-named site collections through the IIS Web site. This is because IIS will not respond to requests for host names that differ from the host header binding."
Hope that helps.
Thanks for a great post. The fact that the HH site collections are always in the default zone kind of kills their usefulness for us.
ReplyDeletehello Ben - i have a question regrding the deployment of the Mulit-tendancy host-name collection, specifically how does one enable the external email feature. i can't find it.
ReplyDeleteHi there,
ReplyDeleteDo you mean incoming emails?
As far as I know they are configured in the same manner as any other site collection. You need to enable incoming emails via Central Admin before the option becomes available.
If you are still stuck leave another comment or catch me on Twitter.
Ben