In earlier articles, we provided details on Dynamics CRM 2011’s internal maintenance operations performed regularly by the CRM Asynchronous Service. With the release of Update Rollup 12/Polaris there have been a few changes introduced. In an effort to keep you updated as the product evolves, we’ve highlighted two specific changes that impact previously issued guidance below:
ReindexAll: This operation has historically performed two functions: 1) reorganize/rebuild fragmented indexes and 2) shrink database/log files. Due to the latter step, we generally recommended disabling this job and implementing your own index maintenance routine. Nevertheless, in UR12/Polaris, the shrink database/log file commands have been removed from the overall operation. Thus, our previous guidance now shifts to a deployment-specific judgment call based solely on the merits of the provided maintenance methodology. If you prefer to implement your own index maintenance routine, continue with disabling this operation, otherwise reschedule it for a non-peak usage hour as with the other available maintenance operations.
Another minor change regarding the job’s maintenance methodology, a fragmentation threshold of 30% has been introduced above which a rebuild of the index will be performed and below which the index will be ignored for the maintenance cycle. Our previous article detailing the maintenance operations has also been updated to reflect these changes.
- DeletionService: We found that a new feature added to the CRM 2011 SDK also presents deletion cleanup implications. The new feature referred to is the metadata change tracking capabilities. With the UR12/Polaris SDK release, you now have the ability to request metadata changes that have occurred since a provided timestamp (See more details on MSDN). One potential metadata change that could occur is the deletion of metadata – attributes, entities, relationships, etc. Since the metadata deletion process performs immediate deletion changes to the metadata definitions and schema elements (similar to physical data deletion), the platform must track the deleted schema elements for a period of time so that future requests for tracked metadata changes can include those elements which no longer exist. To accomplish this, the platform tracks references to deleted metadata in the MetadataSyncTrackingDeletedObject table.
Now, here’s where the DeletionService operation comes into play. At some point, those references are no longer needed and thus, the DeletionService operation will consider them expired and delete them if their CreatedOn timestamp is earlier than the organizationally-defined expiration period (90 days – this is the same value used for determining expired offline sync subscription records). Our previous article detailing the purpose of the DeletionService operation has also been updated to reflect this change.
As always, we will do our best to keep you updated with relevant changes introduced in product updates and upgrades!