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 192.168.0.140 (DomainController Demo1.local.ru) Demo1SP1 192.168.0.141 (SharePoint 2010 Enterprise SP1 + SQL Server 2008 R2 Standard) Farm2:
Demo2DC1 192.168.0.160 (DomainController Demo2.local.ru) Demo2SP1 192.168.0.161 (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 ***220.127.116.11:8080*** 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 ***18.104.22.168:8080***
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.