Sharepoint 2013 : Information Management policy not working
Here is one of the interesting scenarios that we worked recently , where Information Management policy not working on all the record template based document libraries within a specific site collection / content database. The documents that are meeting the policy ,were not getting removed automatically from a specific site collection while the same policy works on other site collections within the same content database.
Before taking a deep dive on the troubleshooting steps , here is the definition of IM policy.
What is IM policy?
An information management policy is a set of rules for a type of content. Information management policies enable organizations to control and track things like how long content is retained or what actions users can take with that content. Information management policies can help organizations comply with legal or governmental regulations, or they can simply enforce internal business processes.
One of the feature is Retention policy feature which lets you define retention stages, with an action that happens at the end of each stage.
Below two links explain this feature in detail.
https://technet.microsoft.com/en-us/library/cc262490.aspx
Ok, now lets come back to the troubleshooting aspects.
The size of the content database in question was about 650GB in size with about 100+ site collections in it. Database maintenance was in place and getting done on a regular basis.
Confirmed that the site feature LocationBasedPolicy activated at site collection level using the following
$site = Get-SPSite https://sp/sites/recordcentertest
$site.Features["063c26fa-3ccc-4180-8a84-b6f98e991df3"]
1. Confirmed that "Send To" option from Central Admin associated with non-working library works fine.
When retention policies are applied on content types, there are 2 timer jobs that run (by default during the weekend) associated with web application:
•Information management policy timer job:
by default, runs on Friday 11 PM. The job goes through libraries that have policies applied.
It calculates the expiration date for every item
•Expiration policy timer job:
by default, runs on Saturday 11 PM. This job executes the action part of the retention policy.
For example, if the action is to move expired documents to the recycle bin, expired documents will be deleted;
if the action is set to move the documents to a send-to location, the expired documents will be moved.
Get-SPTimerJob | ?{$_.name -eq 'PolicyUpdateProcessing'} | Select Name, Schedule, LastRunTime, Id, WebApplication, IsDisabled
should help us get the timer job listing associated with web application.
2. In the logs collected while running the timer job, we should see messages like below
| OWSTIMER.EXE (0x0D90) | 0x1070 | Document Management Server | Information Policy Management | aap0 | Medium | Policy Update: Processing policy updates for list TestDocForMoving on web https://sp/sites/RecordsCenterTest. |
Since the library was not mentioned anywhere in the logs collected from the environment, compared the working and non-working libraries to check if there is a difference in schema.
A library with active retention policies should have the following hidden fields:
_dlc_Exempt
_dlc_ExpireDateSaved
_dlc_ExpireDate
Run the below command-lets on one of the working libraries and non-working one as well
$site = get-spsite https://sp/sites/RecordsCenterTest //Change it to your site collection url
$web = get-spweb https://sp/sites/RecordsCenterTest //Change it to your site collection url
$list = $web.lists["TestDocForMoving"] // Change it to your library name
$list > C:\listschema.txt //Change the filename accordingly
Compare the schema and confirm if “_dlc_ExpireDateSaved” and “_dlc_ExpireDate” fields missing in value.
To confirm ran the below for all 3 fields and make sure that the results are NULL
$web=Get-SPWeb https://sp:90/sites/Test/subsite
$list = $web.Lists['Listname']
$ct2=$list.ContentTypes['contenttype name']
$ct2.Fields | ?{$_.internalname -match '_dlc_ExpireDate'}
To resolve the issue, there are 2 options available to us
A. Try de-attaching and attaching the content database which hosts the site collection
Caution: This step will make other sites in the content DB to be unavailable until the DB is reattached.
If you have Project server instance (PWA sites within the Content DB) , we recommend NOT to proceed with option A
B. Using move-spsite command, move the site collection to another content database
Refer: /en-us/powershell/module/sharepoint-server/move-spsite?view=sharepoint-ps
POST BY : Revathi K [MSFT]