When running Microsoft's SharePoint Portal Server Home Site, you have the option of using the Sites Directory to create embedded site collections in the portal or Central Administration to create stand-alone site collections. Knowing why you would want to do one over the other is important, because each method offers benefits and drawbacks. At Mindsharp, we like stand-alone site collections for four reasons:
¨ URL Independence
¨ Database Independence
¨ Security Independence
¨ Portal Independence
URL independence is achieved because a stand-alone site collection created through Central Administration can be given its’ own URL that is independent of the portal URL. Now it is true that you can use the Alternate Portal Access Mappings to create an intranet URL for an embedded site collection that appears as independent of the portal URL, and if you need the advantages of an embedded site collection with a unique, intranet URL, then this is a great solution. But in some situations, politics and other considerations will indicate your need to create a real stand-alone site collection.
When you create a site collection through Central administration, you’ll need to assign the site collection its’ own database. For obvious reasons, this is often preferable in a disaster recovery scenario. If a SQL database goes bad, it will only affect the one site collection. If a SQL database goes bad that is hosting a portal plus many embedded site collections, then the outage of the database has a pervasive effect on the entire organization.
Because stand-alone site collections can be created in their own virtual server, you can achieve security independence via a unique security context created for a unique application pool for that virtual server. While there is security enforced in embedded site collections, the additional security at the virtual server may be attractive in development and high security environments.
Finally, because stand-alone site collections are not connected to a portal, there is no automatic navigation to a portal site. This also means that the site collection is not included in any portal’s sites directory nor is it crawled by a portal search engine unless this is manually setup. Some will not think these are features of stand-alone site collections, but in reality, for many teams, this is a real advantage: their work cannot be crawled unless the gatherer service is manually instructed to do so via a manually created content source.
Now, we don’t hate embedded site collections. They obviously have their advantages. Here are the reasons you would want to create embedded site collections:
¨ Automatic indexing of content in the portal
¨ Automatic navigation to the parent portal
¨ Easier ability to add the site collection to the Sites Directory taxonomy
¨ Default ability to publish from the sites to portal areas
We don’t mean to imply that you cannot do these things from a stand-alone site collection – you can! But a stand-alone site collection will require manual configuration of the site collection to connect it back to the portal. It’s not difficult, but we recognize that some will not want any more manual administrative effort than is absolutely necessary.
Everyone’s scenario is different. Some will like the ease of using embedded site collections. The URL, database, security and portal independence will not be of benefit to them and in fact, may be reasons to not use stand-alone site collections. Others will be in scenarios where the exact opposite applies.
However, we feel that most will use a combination of both embedded and stand-alone site collections. Furthermore, we feel that many will choose more often stand-alone site collections over embedded site collections because of the advantages they offer.