Guest Author: Michal Pisarek

Firstly sorry for the almost month break between post! It has been a crazy month but we back ready to rock and roll with our Records Management solution in SharePoint 2010.

In constructing our solution let’s begin with the very basics and consider some high level logical architecture advice for those creating an RM solution. Now this is a combination of my own personal opinion, Microsoft best practices, and some experience from out in the field.

User Collaboration Sites

In EUSP Catering, each event has information stored in the form of a site that has certain elements such as a task list, calendar, document libraries and some other out of the box functionality that SharePoint 2010 offers.

Each of these events sites resides in its own Site Collection because of the ability to apply quotas, easier database management and permission management.  I recommend that all collaboration or business process sites should be created in their own Site Collections.

Web Applications

For a highly compliant environment I would suggest splitting out your Records Content (in the form of Records Centers) into its own Web Application with its own Application Pool that is unique.

This might be overkill for some scenarios but from a compliance perspective I like to make sure that it is clearly visible which process, database and users are interacting with records.

In addition by hosting a unique Web Application you can create multiple Site Collections to store Records Centers under a common managed path (nice and user friendly), maybe change the maximum file upload so that users aren’t sending huge files to the Web Application and also tinker with the blocked file types so that nothing will compromise the Records Centre.

Additionally another new feature of SharePoint 2010 is RBS (Remote Blob Storage) which can be perfectly suited to the large scale storage of records. RBS allows us to store SharePoint BLOB content (files, images, videos) on the file system where they can be managed. RBS moves records from fast but expensive databases to slower but much cheaper file shares. For many users this isn’t a real issue, it’s highly unlikely that Records from 5 years ago will need to be accessed with the same speed as current collaboration content.

Site Collections

Every Records Center we will create will reside in its own Site Collection. The reasoning for this has to do with Site Quotas, but more importantly with each Records Centre (and we can have multiple Records Centre’s in SP2010, this is different from MOSS 2007) can be assigned to its own database which is vitally important.
Also we aren’t too concerned with navigation, we want to have unique administrators for each Records Centre we create and we also want to have our own unique search scopes all of which leads to creating a Site Collection rather than a Site.

Database

I can’t emphasize this enough – each Records Centre should have its own database. Each database can be linked to its own Records Centre Site Collection. Make sense?

Remember we could have potentially hundreds of thousands of records so we need the ability to control sizing, having our own database will allow us to do this. But more importantly from a compliance perspective Records are vitally important to an organization so you can assume that this content will be treated slightly differently than other content within the organization. There is no point mixing low priority collaboration and vital Records in the same database, you will just waste valuable storage!

Managed Metadata Service

The Managed Metadata Service serves two purposes in our solution. Firstly it is the vehicle by which we can define Managed Metadata that can be used across our solution. Secondly it acts as the mechanism to publish out Content Types across our Farm.

In our solution, because of its simplicity, we are only going to have one Managed Metadata Service that will hold our metadata and also syndicate our content types. In most cases you may have more than one service but the same principles hold true.

Content Type Syndication

Next article I will go through how to define Content Types and a big part of this is using the new Content Type Syndication feature that allows us to define, control and publish Content Types across Sites Collections and Farms.

However make sure that you use Content Type Syndication, regardless if you think that you need it or not. It will give you a whole host of abilities that you will use in the future, whether you think you need them now or not.

Ok so next time we are going to start the process of defining our Content Types in our Content Type Hub. We will discuss how to start planning your Content Types and what are some of the issues you should consider. After that we will discuss attaching metadata to Content Types using the new Managed Metadata service, what value metadata has and some frequently asked end user questions!

VIEW ALL ENTRIES IN THE SERIES

Guest Author: Michal Pisarek

Michal Pisarek is a solution specialist for Habañero Consulting Group, a Microsoft Gold Partner in beautiful Vancouver Canada. He has been working with SharePoint for 3 years and has a passion for finding the right balance between technology, innovation, governance and fun to meet his client’s needs.

You can find other articles by Michal on his blog SharePointAnalystHQ or follow him on Twitter (@michalpisarek)