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.
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.
Problem 01: 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.
Problem 02: 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 03: 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 04: 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.