Multi-Tenancy in SharePoint 2010 using host-named site collections

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.

1. Add new forward lookup zones for your vanity URL domains, e.g. "microsoft.com" and "ibm.com".

2. 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

Administration: Supported Database Operations in SharePoint 2010

Edit (13/08/2010)

@joeloleoson Expands this article by explaining how vendors use Microsoft’s protocol documentation to "do things not readily exposed in the object model" on his blog. I recommend you have a read.

=========

I have seen a few queries recently around which database operations are supported in SharePoint. As SharePoint administrators, we need to be aware of which operations should be run on farm databases in order to ensure good farm health and performance - and which operations we should avoid at all costs in order to keep databases in a supported state.

Whilst I might take a slightly more relaxed approach in development environments with regard to database operations (I don't expect support from Microsoft for my VPC), my rule in a production environment is clear: never, ever perform an unsupported operation unless specifically asked to by Microsoft support. That includes reading from a content database - which might surprise some.

That's right - reading from a SharePoint DB will leave it in an unsupported state. That's confirmed in this KB article that was updated in April of this year and applies to pretty much any SharePoint product since WSS 2.0 up to and including SharePoint Server 2010 (with the exception of the logging database, where customisations are fully supported).

If you a take moment and think about this, prohibiting changes to the DB schema actually makes a lot of sense. Microsoft tests SharePoint based on a specific database schema and could not possibly predict changes that third parties are likely to make. Therefore, it could not practically support those changes. I think of this as analogous to purchasing a new BMW Z4, fitting a supercharger and then expecting the dealer to honour any warranty they may have promised - it just would not be practical nor economically viable.

As regards to preventing read operations (e.g. SELECT statements), I suppose that it's analogous to breaking the warranty sticker on an electrical appliance. OK, you may not have touched anything but it implies you may have done. Similarly, if Microsoft discover that you have been taking a look through a content database they would be inclined to think you have made a few changes along the way.

So we know that reading from a SharePoint database is prohibited. Here are a few other operations that Microsoft specifically list in the above KB article as leaving a database in an unsupported state:

• Adding database triggers

• Adding new indexes or changing existing indexes within tables

• Adding, changing, or deleting any primary or foreign key relationships

• Changing or deleting existing stored procedures

• Calling existing stored procedures directly

• Adding new stored procedures

• Adding, changing, or deleting any data in any table of any of the databases for the products that are listed in the "Applies to" section

• Adding, changing, or deleting any columns in any table of any of the databases for the products that are listed in the "Applies to" section

• Making any modification to the database schema

• Adding tables to any of the databases for the products that are listed in the "Applies to" section

• Changing the database collation

• Running DBCC_CHECKDB WITH REPAIR_ALLOW_DATA_LOSS (However, running DBCC_CHECKDB WITH REPAIR_FAST and REPAIR_REBUILD is supported, as these commands only update the indexes of the associated database.)

I recommend you read the KB article linked above for the most up to date list of (un)supported operations.

So which operations can we perform on a SharePoint database? The SQL DBA's out there will know that routine maintenance is essential for optimum performance - and few areas are as important to SharePoint performance than the SQL back end. Whilst I have not yet seen an equivalent resource for SharePoint 2010, Microsoft published a very useful white paper back in November 2009 called "Database Maintenance for Office SharePoint Server 2007". I encourage you to take a look if you haven't seen this already and are involved in MOSS administration (although I imagine it will be relevant to SharePoint 2010 also).

According to this white paper, the following maintenance tasks are recommended:

• Checking database integrity (ensures that your data and indexes are not corrupted).

• Defragmenting indexes by either reorganizing them or rebuilding them (applies mainly to indexes; fragmentation can be reduced by setting a large database start size).

• Setting the fill factor for a server (allows index performance to be fine tuned).

• Shrinking databases to recover unused disk space (white space caused by deleting documents, libraries, lists etc.).

Note that Microsoft do not recommend configuring auto-shrink operations, and advise only to shrink content databases due to the fact that other types of databases (e.g. SSP) do not typically undergo a large number of deletions.

In conclusion, things haven't really changed much since MOSS with regard to which DB operations are supported - the main message is to keep well away from them! I imagine Microsoft will release a similar resource for SharePoint 2010 with an updated list of recommended DB maintenance operations. For now, I will be implementing the above MOSS maintenance plans on my SharePoint 2010 test environment.

SharePoint 2010 and .NET 4: confused?

I have seen a few queries on the Technet forums recently regarding the use of ASP.NET 4 and SharePoint, an example being this post here.

There appears to be some confusion (myself included) around whether or not ASP.NET 4 is supported for both MOSS and SharePoint 2010 - in short, the answer is that it is not currently supported in either product.

Whilst it is possible to use ASP.NET 3.5 in MOSS by making some modifications to the SharePoint site web.config (instructions for doing that in MOSS here; SP2010 uses 3.5 by default), this is unfortunately not the case with version 4.

The reason? ASP.NET 4 uses a new version of the Common Language Runtime (CLR). Whilst .NET 2.0, 3.0 and 3.5 all used version 2.0 of the CLR, .NET 4 uses version 4. I'm not entirely sure what happened to version 3. There is a decent post on stack overflow with further details.

For those that are wondering, the fact that .NET 3.0 and 3.5 do not show up as options within IIS is also related to the CLR version. IIS knows about that - it does not know about framework and compiler versions and the aspnet_isapi.dll from the version 2.0 is used for version 2.0 through 3.5 for this reason. This post explains that in more detail. Does that mean we will get a new option in IIS for .NET 4? You bet, due to the use of CLR v4.

So does that mean we are destined to use .NET 3.5 for the lifetime of SharePoint 2010? Not necessarily. Aside from the possibility of Microsoft adding support for version 4 in a future service pack, those using ASP.NET Web forms in separate virtual directories will still be able to use .NET 4 so long as said virtual directories are in a separate application pool. I have confirmed this is the case with Microsoft in this post, and believe this to be the case for SharePoint 2010.

I hope that helps clarify things a little.

Subscribe to the RSS feed

Follow me on Twitter

Follow my Networked Blog on Facebook