This is more of a story with some hints to look out for when using Content Organizer in an automated way. If you’ve read my previous 3-4 posts on the subject, you can stop reading — almost nothing new here 😊
After my last blog, I assumed it would be smooth sailing. Nothing was further from the truth.
The Client’s Request
The client asked for a migration tool from file shares to SharePoint. Because it was a POC/Pilot, the setup had to be generic enough to easily add additional file shares. Some form of routing was also needed — the filename contained all the info required. Yes, parsing routing info from a filename is asking for trouble, but there wasn’t another option.
SharePoint 2010 had a perfect system for this: Content Processing and Routing. We immediately decided to use it instead of building our own.
Setting It Up Step by Step
- PowerShell to push documents from file shares into the Drop-Off library, with some pre-parsing already done
- Activated the Content Organizer feature — got the Drop-Off library ✓
- Created a content type based on Document, added a metadata field for routing value
- Created a subsite with its own Content Organizer feature and rules for final routing to document libraries
- Created a connection between the root web and the subsite in Central Admin → General Application Settings → Configure Send-To connections (the Content Organizer feature must be activated on the target before this or the URL is rejected)
- Enabled “Allow routing documents to other sites” in Content Organizer settings
- Updated the root web rule to route to the new subsite destination
First Problem: Documents Not Routing
Everything looked correct but documents weren’t being routed. Investigation revealed: SharePoint versioning was adding an incremental number to the filename, creating a new file instead of updating. More critically, the Content Processing timer job requires files to be checked in before routing — checked-out files are in a “locked” state and won’t be touched.
Fix: in the library settings, disable “Require Check Out”. Retesting manually worked fine, and the timer job picked up the documents nicely.
Second Problem: Template Site URLs in Content Rules
A second subsite needed to be created using the first as a template. Content Organizer rules are just list items with string metadata — the URLs in those rules don’t update when a site is created from a template. They still point to the template site’s paths.
Fix: use a WebProvisioned event receiver to update the URL values in the rules list, create the connection to the root web, and set up the content type routing rules for the new location.
End Result
When all this is in place, you have an almost fully automated content routing process. Administrators no longer need to create a connection every time a subsite is provisioned.
I’ve turned this feature inside out. If you have questions, drop me a comment or a mail!