Team blog of MCS @ Middle East and Africa

This blog is created by Microsoft MEA HQ near shoring team, and it aims to share knowledge with the IT community.With its infrastructure and development sides,It brings to you the proven best practices and real world experiences from Subject Matter Experts
Follow Us On Twitter! Subscribe To Our Blog! Contact Us

Divisional Portal (Single vs. Multiple Site Collections)

Divisional Portal (Single vs. Multiple Site Collections)

  • Comments 1
  • Likes

What is Divisional Portal?

A divisional portal is a SharePoint Server 2010 deployment where teams mainly do collaborative activities and some content publishing; for example it can be used for hosting an Intranet Portal with multiple Departments. In general we usual face the choice between using sites or site collections. Below we will go through each scenario in more details:

 

Single Site Collection Portal:

In this scenario the divisional portal will be built using a single site collection, and all the other Teams will be created using sub sites under the root portal. This approach have the following characteristics:

  • The solution has a common navigation
  • Has a single Quota template
  • Has a single content database
  • SharePoint resources can be
    shared among all subsides (like content types, workflows, design … etc.)
  • Security configuration can be inherited
  • Search is easier to configure
  • You can aggregate contents using SharePoint out of the box functionality (like Content Query Web Part, Data View Web Part … etc.)
  • Easier to administer and operate (ex: single backup & restore)

Multiple Site Collections Portal:

In the scenario the divisional portal might have a root site collection to aggregate the contents (like News) coming from other Teams. The Teams here is implemented using separate site collection each. This approach have the following characteristics:

  • Can support dedicated URLs per Team.
  • Supports multiple quota templates.
  • Can be distributed among multiple content databases.
  • Additional effort is needed to aggregate SharePoint resources (ex: create a hub to manage content types).
  • Custom navigation need to be considered.
  • Each site collection has an isolated administration configuration.
  • Each site collection must be added separately to Search.
  • Needs some customization to aggregate contents (.NET Development)
  • Requires additional administration efforts (Backup, Restore … etc.).
     

Conclusion:

Before making the decision to choose one of the above approaches, you need to study and review your solution carefully and make sure that it covers the requirements. In addition you need to consider the operational & administration effort behind each approach.

 

Additional References:

 

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment