SharePoint web services "Unable to connect to the remote server"

Question

Hi All,

I'm getting an error when attempting to call SharePoint's webservices on one of our platforms. To start, we have Development (DEV), Testing (QA) and Production (PROD) SharePoint servers. The QA and PROD servers are pretty much identical. We have an ASP.NET web service that sits out as a seperate application on each of them. Our data entry forms hit the web services to insert/update into a SQL database and in some cases make calls to some of SharePoints web services (lists, dws).

We’re having trouble calling SharePoint’s web services on PROD from our web services however, have no problems on QA(or DEV). In our web service code we have a web reference to the SharePoint web services (lists and dws). We attempt to call these web services to create list items/folders when a new entry is made through one of our forms. On QA, there is no problem creating the list items/folder. The form is filled out, calls our web services – which call the SharePoint web services and the list item/folder is created.

On PROD we get the following error when we attempt to call the SharePoint web services:

Unable to connect to the remote server

at System.Net.HttpWebRequest.GetRequestStream() at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters) ...

However, to make it more interesting, if I call the PROD SharePoint web services directly from my personal computer I have no problem creating the list items/folders. We only have the problem when our web service attempts to call the PROD SharePoint web services. We’ve looked through many different web.config files looking for differences on QA and PROD and are yet to come up with anything.

If anyone has any pointers, they would be greatly apppreciated. Thanks.

Update: I just attempted to refactor the above method to use the SharePoint Object Model API and I'm getting an unauthorized error. When using the Object Model API the credentials do not seemed to be passed properly, because it's attempting to use the MOSS Server credentials. Is there any way to tell it which credentials to use as you do with the web service api?

docLibList.Credentials = System.Net.CredentialCache.DefaultCredentials;

Thanks.

Answer 1

This probably is not the problem, but is your reference to the web service pointing to the production server correctly. I had a problem before when trying to access a SP service that was referenced incorrectly. The dev server I was pointing to was on a seperate domain and could not be found.

Answer 2

Sean,

I'm not sure I completely understand your calling pattern, but if you are indeed looping back to web services on the same box, you might be running into the infamous loopback issue:

http://serverfault.com/questions/32345/ie-8-authentication-denied-on-local-sharepoint-site/32485#32485

In short: executing hostname-based HTTP calls that loopback to the server from which they're issued can get blocked. If the loopback issue is in-play, you'll be able to call the web services in PROD from another box ... but not from the PROD box itself (i.e., looping back). I think this is consistent with the behavior you described above.

If Windows patch levels are different between your environments, it might explain why your code is failing in PROD but not in your other environments.

I hope this helps!

Answer 3

Regarding the update to your question about the unauthorized error using the object model:

Depending on the context that your code runs in you will sometimes need to elevate privileges. See this Elevation of Privilege MSDN article for details (also note the community comment at the end). There's also a Visual How-To.

Another method is to create a new SPSite object using a SPUserToken object. There is more information in this blog post by Daniel Larson. For the system account this would be done with the code:

SPSite site = new SPSite(SPContext.Current.Site.ID,
                         SPContext.Current.Site.SystemAccount.UserToken);

By the way, this would be better in its own question next time so that it can be correctly voted and answered.