I am trying to test how the Content Deployment process works across separate SharePoint 2010 farms.

There are 4 virtual servers in my test lab running on Hyper-V:


Demo1DC1 (DomainController Demo1.local.ru) Demo1SP1 (SharePoint 2010 Enterprise SP1 + SQL Server 2008 R2 Standard) Farm2:

Demo2DC1 (DomainController Demo2.local.ru) Demo2SP1 (SharePoint 2010 Enterprise SP1 + SQL Server 2008 R2 Standard) There is not trust relationship between DC's and I don't think there should be one, according to MSDN articles on Content deployment.

When I'm running the Conent Deployment timer job, I receive the error in ULS like this one:

Publishing: Content deployment job failed. Error: 'System.Web.Services.Protocols.SoapException: Unable to connect to the remote server ---> System.Net.WebException: Unable to connect to the remote server ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond ******    
 at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)    
 at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket, IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)     -
 -- End of inner exception stack trace ---    
 at System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)    
 at System.Net.HttpWebRequest.GetRequestStream()    
 at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)    
 at Microsoft.SharePoint.Publishing.Internal.Administration.ContentDeploymentRemoteImportSoapClient.InvokeInternal(String methodName, Object[] parameters)     -
 -- End of inner exception stack trace ---    
 at Microsoft.SharePoint.Publishing.Internal.Administration.ContentDeploymentRemoteImportSoapClient.InvokeInternal(String methodName, Object[] parameters)    
 at Microsoft.SharePoint.Publishing.Internal.Administration.ContentDeploymentRemoteImportSoapClient.CreateJob(String description, Guid sourceId, String destinationServerUrl, String destinationSiteCollection, SPIncludeSecurity includeSecurity, SPImportUserInfoDateTimeOption includeUserInfoDateTime, Boolean enableEventReceivers, Boolean fileCompression)    
 at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.DoServerToServer()    
 at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.ExecuteJob(String callingTimerJobName, Guid timerJobId)    
 at Microsoft.SharePoint.Publishing.Administration.ContentDeploymentJob.InternalRun(Boolean runAsynchronously, String timerJobName, Guid timerJobId)'

notice the IP address:

"...connection failed because connected host has failed to respond ****** 

I have no idea why my provider Farm is trying to access this weird IP address instead of the one I've specified, although the port 8080 matches the right one.

  • I have configured Content deployment without encryption.
  • Receiving Site collection was created without specifying Site template.
  • I have added the line for host files explicitly mapping IP address to the destination name.
  • Consuming Farm allows incoming deployment jobs.
  • I can successfully access both CA sites from both farms.
  • Firewall on all servers is turned off.
  • ping command works for all servers from any server.
  • I've tried adding Alternative Access Mapping for Central Admin and Content applications in both farms.
  • I have removed all Alternative DNS' from network adapter settings leaving only Farm's domain controllers.

Any help will be greatly appreciated!


I haven't exactly fixed it. Unfortunately, I had to rename Domain controllers and reinstall SharePoint on two servers. It was the easiest solution in my case.

My mistake was to use ".ru" in my domain names. Secondly, I had two forests with no trust between each other and they could not use each other's DNS. Even though Content Deployment does not require trusts, server names have to resolve correctly no matter how you set up your C.D. paths. In my case I also had trusts between two SharePoint farms and a shared Metadata Service that worked perfectly well even without the need to resolve the IPs. However, Content deployment turned out to be a bit different in this aspect.

2 Answers 2


It seems as if you haven't set up DNS entries for the other server in the providing servers DNS or haven't configured Default GateWay correctly.

If I do a nslookup Demo1sp1.local.ru on my machine it returns as the IP.

So I guess the same happens for you.


I agree with the lines of Per. Except that if the ping is resolving to the right server, so should the sharepoint service. Could you confirm the IP resolved during the ping? Also, what happens when you ping or run a tracert on demo1? There should be consistent behavior. Is there a DNS entry on your DC for demo1 or demosp1?

  • tracert and ping are resolving Demo1sp1.local.ru the the right IP. Then I've tried nslookup and it actually resolves to the wrong one! I feel much closer to the solution now, thank you. I will let you know when I finally fix it. Commented Apr 17, 2012 at 17:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.