Create Content Organizer "Connection" Automatically via Code

Hey everyone!

My quest concerning the Content Organizer architecture has come to an end. The solution is working without any problems. For those who don’t know what I’m talking about, please read my previous blog posts about Content Organizer.

The Problem

The main issue: the Content Organizer structure does not automatically create a connection, so the root web can’t send files from the drop-off library to a drop-off library on a subsite. Instead, Microsoft expects the user to contact a farm administrator who then manually creates a connection in General Application Settings → Configure send to connections.

This is a nightmare when sites can be created on the fly — every time a new subsite is provisioned, an admin has to create the connection manually.

The Solution

If a site template is used and the Content Organizer feature is activated in the template, a connection will be made automatically. I put the logic in a WebEventReceiver at the WebProvisioned event.

Here’s the core code:

SPOfficialFileHost tempFile = new SPOfficialFileHost(true);
// The boolean indicates whether a unique ID must be created (done at constructor level)

tempFile.Explanation = "string value";
tempFile.OfficialFileName = web.Title; // or any string value
tempFile.OfficialFileUrl = new Uri(siteUrl + "/_vti_bin/officialfile.asmx");
// I added the _vti_bin part because Central Admin requests it — not sure if it works without it
tempFile.Action = SPOfficialFileAction.Move; // .Move, .Link, or .Copy
tempFile.ShowOnSendToMenu = true;

To add this to the web application:

site.WebApplication.OfficialFileHosts.Add(tempFile);
site.WebApplication.Update();

Important: You must call site.WebApplication.Update(). If you skip it, all your connections disappear on the next application pool recycle. The Update() call serializes the changes and propagates them throughout the farm.

After running this, the new connection will appear in the Central Admin listbox.

The “Access Denied” Catch

If you use .Update(), you may hit a security exception — even in elevation mode — blocking you from pushing changes. A PowerShell workaround (from Stack Overflow):

$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$contentService.RemoteAdministratorAccessDenied = $false
$contentService.Update()

Note: this probably isn’t the correct way to bypass the error — but it works.

Hope this helps someone, because I couldn’t find a single blog post about this subject anywhere!