Share via

Send to… Other Location feature, MOSS & Office clients

  • Article

Have you used this feature before? I see a lot of people on the internet using this feature and there are a couple of scenarios in which this feature won’t work “as expected”. I recently had a chance to spend some time on this and here are my observations after hours of testing.

If you attempt copying a document from one document library to another and the source and target libraries are in different web applications, then this feature won’t work with Office 2003 clients and MOSS 2007. My guess is that this behaviour occurs because, when Office 2003 was released, it wasn’t built to support features that MOSS 2007 provides. MOSS 2007 was released 4 years later!

This feature will work with Office 2007 clients, though. However if you are copying from one library to another which are located in different site collections AND there does not exist a root site collection at the target, then this feature won’t work. If you see these symptoms, creating an empty root site collection should resolve the problem. It appears to me that it may have something to do with not being able to find the path to the child if the root site collection does not exist.

The way the Send to... Other location works is by using a ActiveX Control (Multiple Document Upload Control) installed with Microsoft Office 2007. After you provide the destination URL (BTW, the destination URL must end with the library name and not the view name such as AllForms.aspx) and click OK, the Jscript on the web page invokes this control with a call to new ActiveXObject("STSUpld.CopyCtl");. To successfully instantiate the control, the following registry keys must be present.

  • HKCR\STSUpld.CopyCtl
  • HKCR\STSUpld.CopyCtl.CLSID\(Default)
  • HKCR\STSUpld.CopyCtl.CLSID

The control itself is located in the DLL present @ C:\Program Files\Microsoft Office\Office12\STSUPLD.DLL

When instantiated, this control contacts a web service on the SharePoint server to copy the contents from source to destination. It first makes a request to the source to get the document and its properties and then POSTs the data to the target location. Now, if the Multiple Upload control cannot be loaded for some reason, SharePoint will attempt to perform this operation via server side by sending a POST to CopyResults.aspx. This is what you see in the browser address bar. Now, the CopyResults.aspx page is capable of copying of documents only if the source and destination are in the same web application. The functionality appears to be by design – In other words, the page restricts copying across application boundaries. The API that causes this behaviour is also documented on MSDN.

ValidateDomainCompatibility Method

Also, the posting and responses from the Program Manager @ the SharePoint Designer Team blog has mentioned that calling Cross applications is not allowed. Here’s the link. FYI, there isn’t a setting to change this behaviour. This is probably something that the development team knows about and may fix in the later versions of MOSS, hopefully.

When application domain boundaries need to be crossed, only the web service - Copy.asmx works because it completely extracts all the contents (encrypted of course!) and the properties of the document before posting it to the target document library. I am still not sure why this functionality cannot work from server side code though; but that appears to be what is going on.

Coming back to problems instantiating the Multiple Upload control installed with Office 2007 clients, the best way to fix it will be to run a repair installation of Microsoft Office because the DLL in question is not something you can register using regsvr command. Also, when running the Office Setup, ensure Windows SharePoint Services support component is selected.

I hope the information shared above was helpful to people who have/are running into this behaviour.