Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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).

share|improve this question
    
could you say more about your SP environment (2007/2010, Foundation/Ent Server, etc) ? –  Supriyo SB Chatterjee Apr 3 '12 at 14:45
    
@sbc111 We are using SP2010 Enterprise (the farm is managed by another group, also). –  Romanulus Apr 3 '12 at 17:17
add comment

migrated from stackoverflow.com Apr 3 '12 at 13:09

This question came from our site for professional and enthusiast programmers.

4 Answers

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)

share|improve this answer
    
Thanks for the answer. :) In theory it works, but is outlandishly horrendous and sounds absurdly redundant to do something which should be doable OOTB (adding retention to the Document content type), no? I may just go with doing a folder/location based retention on a per list/library basis. –  Romanulus Apr 3 '12 at 20:20
    
Like I said it's "doable" :-D. The per list is in this probably the better option. I do suggest you use a base content type for a project that derives from say item or document. It is a best practice and as you see, can save you loads of trouble :-D –  Colin Apr 3 '12 at 20:32
add comment

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

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

Hope the above helps.

share|improve this answer
add comment

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

share|improve this answer
    
Ah yes, that article. Isn't it odd that you can't add retention to just 'Document'. I find it painfully redundant to have to add another level of specificity below it to be able to add a retention policy. Don't you? Also, a slightly shortcoming of doing retention from the very top is not being able to specify a workflow, either. :( –  Romanulus Apr 3 '12 at 18:48
add comment

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

share|improve this answer
    
First, thank you for the reply! I have tried, but with limited success. 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 –  Romanulus Apr 3 '12 at 16:31
    
You probably already concluded this but this is just saying you can't do a retention policy off the Document content type. But if you create a new content based off the document content type, you will be able to do this. Do you use any custom content types? –  RWL01 Apr 3 '12 at 17:27
    
Hi RWL01, yeah... that's what I'm coming to terms with, it seems. :( ALL my documents (thousands of them) across all sites in document libraries by default have the 'Document' content type. How absurd would it be to create a sub-content type for Document and then somehow reclassify all those documents? –  Romanulus Apr 3 '12 at 17:44
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.