In my previous post, I said that there are three broad phases records managers need to understand if they are planning to use the application to manage electronic documents and other content as records.
Before you start you need to keep in mind a couple of important points about SharePoint 2010:
- It is not a document, records management, or electronic document and records management system (EDRMS). It is, however, a system that can be used to manage electronic documents as records.
- It is not certified, out of the box, to meet most recordkeeping standards, including MoReq2010, DOD 5015.2, and so on, and it seems unlikely that Microsoft would ever bother to achieve this. If you want that certification you will almost certainly need to acquire third party products or add ons.
- It has probably been used for at least a couple of years as the basis for your intranet (or internet) by web content people, or by your IT area. Using it to manage records will be new to most of these people, so you really need to know what you are doing and saying before you engage in conversations about it with them.
- It has storage limits and you need to know what these are and the implications for performance and back up. The primary storage is called a Content Database. Within a Content Database you can have up to 2000 Site Collections (the uppermost point of a series of sites). However, most Site Collections will be limited to 100 GB because backup and restore is only supported for a maximum site collection of 100 GB. Microsoft recommend that sites are no larger than 2 GB.
Microsoft have a nice little formula for working out the total required size of a Content Database:
((D x V) x S) + (10 KB x (L x (V x D)))
Where: D is the number of documents per user (assume 20); V is the number of non-current versions expected; S is the average size of documents (assume 250 KB), and L is the number of list items (assume 60 per user).
Alternatively, assume 250 MB required storage per user.