File Retention Strategies

Question

I'm doing some research into retention strategies on SP2010.

As it stands there seems to be enough functionality here to do what we would like to on our intranet of approx. 1700 users across 40 sites on one SC. We're pretty keen on keeping server space to a minimum (part of a silly contract we're part of), so I've planned on creating retention strategies for all document libraries/pages that kicks in after 4 months prompting the user to 'touch' their file/page to refresh it's modified date... otherwise it gets deleted.

Now, here's my irking issue: Should I just create a site-wide (from the very top) strategy on all desired content types, or should I use retention specifically on each library of interest?

The former seems much easier... just set the thing up once and basically walk away, however the latter puts my mind at ease (despite the initial config time) and I'm afraid of having an otherwise broad policy across the whole site maybe deleting things inadvertently.

Any thoughts or comments are very welcome!

Many thanks! :)

-- EDIT ---

When trying to add retention to the Document content type, I run into odd hindrances.

Top Site -> Site Actions -> Site Settings -> Galleries (Site Content Types) -> Document Content Types (click: Document) -> Information management policy settings -> checkbox: Enable Retention -> Add retention stage.

I get this message (error?): An expiration schedule set on the Document or Item content type cannot be based off of a system generated property such as Date Created or Date Modified. To use a system generated property, create a new content type that is derived from the Document or Item content types

Any idea what may be causing this? I don't really want to create a sub-content type just to do retention (and go through the nightmare, if it's even possible, to respec all those Document content types).

Answer 1

I think this is less of a technical question and more of a policy / information architecture question.

1) You'll need to determine what types of information is being stored within SharePoint

• Documents

  • Invoices
  • Contract
  • Collaborative Documents
  • ...

• List Items

  • Task Items
  • Calendar Items
  • Server Information
  • ...

2) Determine what the retention policy should be for each type of information.

3) Determine how this information is divided. I think an easy way would be by content type but you can also divide this by site or library.

4) Apply the retention policy accordingly.

If you have the same content type in multiple locations you can save the retention policy as a template.

http://office.microsoft.com/en-us/sharepoint-server-help/create-and-apply-information-management-policies-HA101631505.aspx#_Toc262125409

Answer 2

Do it at Site Collection level if the same policy applies for every content type.

Answer 3

I'd like to suggest the following posts that I had used sometime ago for a similar project in document management -

• Retention Policy for document library in SharePoint 2010
• Use custom content types to trigger document retention policies
• Applying Document Retention in SharePoint 2010

An additional feature that was used - EDiscovery in SharePoint Server 2010.

Hope the above helps.

Answer 4

Changing all documents's content type is doable, but has a lot of things to keep track of. To name a few:

You now have a base document content type to which you have added fields (site columns) directly (probably). These need to be moved to the new content type. Doing this means:

• creating a derived content type that inherits all fields (name it something like Document, This is considered a best practice btw as it leaves the based type intact while still giving you a single point of entry for a site wide content type change)
• Add the new content type to your document libraries.
• Change all items to the new content type.
• Then remove the base content type from all libraries (so user HAVE to use the new content type)
• Remove the fields from the base content type (without propagating to child content types, so they won't be deleted from your new document content type).

THe last part is the hardest: instructing your users to use the new content type when creating new doc libs etc.

Using PowerShell you should be able to automate the process, but try it on a test envirnment first (just create a test farm somewhere, backup your production DB and attach it to a webapp in the test farm and start scripting against that, restoring the DB when something breaks until your script works)