SharePoint 2010: Common Problems When Creating a New “Send To” Connection

Introduction

SharePoint 2010 introduced the ability for SharePoint administrators to create a new “Send To” connection, which is a facility that allows a user to send a document to another location via its action menu.  It specifies the web application from which the document has to be sent and the document repository or records centre that will eventually receive it. 

The screenshot below presents the configuration screen for adding a new connection.

http://www.potravelonline.co.uk/img/SendToConfig.jpg

The point of this article is not to guide an administrator into creating a new connection (see this TechNet article for that) but to provide some guidance into solving any problems that may prevent a successful connection being made. 

http://www.potravelonline.co.uk/img/SendToConfigError.jpg

Problem 1: The Content Organizer Feature has not been activated

In order for a successful connection to be made, the Content Organiser feature (under Site Features) needs to be activated at the target site, whether it is a Record Centre, Document Centre or a normal team site.  Activating this feature will trigger both the Content Organizer Rules and Content Organizer Settings under the Site Administration, which in turn sets up the Web Service URL.

http://www.potravelonline.co.uk/img/SiteAdmin_OrganizerAdmin.jpg

Problem 2: Supplying the correct URL

Once the Content Organiser on the target site has been activated, supplying the URL to the configuration screen within Central Administration should allow a successful connection.  If the invalid routing destination error is still being generated, than double check the URL that is being submitted.  As the configuration screen advised, the site URL should have the OfficialFile Web Service appended to it via “/_vti_bin/officialfile.asmx.”  If there is any confusion over the exact URL to be provided, it can be found within the Content Organizer Settings under the Submission Points header.

Problem 3: The “Records Center Web Service Submitters For” Group

If an administrator still experiences a problem in successfully setting up a valid destination, another place to check is the Site permissions, in particular a little known group known as Records Center Web Service Submitters For <<SiteName>>.   Deleting this group from the Site Permissions page will generate a “401: Permissions Denied” error in the ULS Logs.

 In order for an item to be submitted to your target site the server application pool account needs to be a member of this group and the group must be present.

Problem 4: Windows Loop Back Security Check

Windows Server 2008 (and earlier editions) has a security feature known as a loopback security check.  This particular feature is designed to stop access to a web application via a fully qualified domain name (FQDN) if an attempt to access it happens to occur from a machine that hosts that same application.  This type of attack is known as a reflection attack.

Whilst this is essential to good server hygiene, it is also a feature that is known to interfere with some SharePoint operations as it prevents access to a web application from the server that hosts it.  Some examples of SharePoint functionality that the loop back check can interfere with are Search Indexing, Custom Code deployments.

A typical and well spread solution to this interference is to simply disable the check; not a prudent move on a production environment.  The alternative to this is to instead set up a list of address to be excluded from this check.  This process is detailed in Microsoft kb 896861. 

This list should be installed on each server in the SharePoint farm.

There may be other causes to a Send To Connection not working that are not yet documented.  If so, then please feel free to add them.