Question

We’re getting the following error message when we click on “Search Settings” for a Shared Services Provider: “Authentication failed because the remote party has closed the transport stream.”

This is a new server environment with two web front ends, one database server, and one index server, all running Windows 2003 x64.

Does anyone have any thoughts related to if this could be related to 64-bit, or what could be causing the error.

Here are the full details from ULS:

09/17/2008 16:30:34.13 w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86x4 High Configuring the Search Application web service Url to 'https://mushni-sptwb04q:56738/Shared%20Services%20Portal/Search/SearchAdmin.asmx'.

09/17/2008 16:30:34.14 w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High Exception caught in Search Admin web-service proxy (client). System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Authentication failed because the remote party has closed the transport stream. at System.Net.Security.SslState.StartReadFrame(Byte[] buffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) at System.Threading.ExecutionContext.runTryCode(Object userData) at System.Runtime.Co...

09/17/2008 16:30:34.14* w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High ...mpilerServices.RuntimeHelpers.ExecuteCodeWithGuaranteedCleanup(TryCode code, CleanupCode backoutCode, Object userData) at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state) at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.PooledStream.Write(Byte[] buffer, Int32 offset, Int32 size) at System.Net.ConnectStream.WriteHeaders(Boolean async) --- End of inner exception stack trace --- at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request) at System.Web.Services.Protocols.SoapHt...

09/17/2008 16:30:34.14* w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High ...tpClientProtocol.Invoke(String methodName, Object[] parameters) at Microsoft.Office.Server.Search.Administration.SearchWebServiceProxy.RunWithSoapExceptionHandling[T](String methodName, Object[] parameters)

Was it helpful?

Solution

I guess you find this exception in the index server, right?

Are you able to browse to 'https://mushni-sptwb04q:56738/Shared%20Services%20Portal/Search/SearchAdmin.asmx' from the index server?

It seems like SSL is not properly provisioned on the front-end servers. This might solve your issue:

  1. Remove the SSL certificate of the front-end servers
  2. Remove the index server from the farm
  3. Move the search and index roles to one of the front-ends
  4. Join the index server back to the farm
  5. Add the index/search roles to the index server
  6. Apply the SSL certificate (you can generate them using SelfSSL) to both front-ends

OTHER TIPS

Be careful with SelfSSL, its better to use Use SSLDiag. SelfSSL has a bug where if you use it to assign certificates to multiple sites on the same box, only the last site will work. You can run SslDiag from the command line like so:

ssldiag /selfssl /V:999 /N:CN=<hostname> /S:<siteId>

Use metabase explorer to find the side it.

Could be an SSL issue.
Do have a look into profiles settings, do you get any error when accessing to the User Profiles settings for that same SSP?

I'm having the same problem. The "Office Server Web Services" (henceforth OSWS) site is available through HTTP on my app server, but not via HTTPS. It doesn't matter where I try to hit the HTTPS URL from, it just flat-out fails (read: no HTTP error code).

However, I have come up with some more information. When the app server was joined to the farm, it gave OSWS a different site identifier than exists in the rest of the farm. I tried changing the site identifier, but that didn't work. I've also tried installing the IIS diagnostics toolkit. That pointed me towards the certificate that MOSS installed when the machine was joined to the farm. The line of interest is this one:

#WARNING: AcquireCredentialsHandle failed with error -2146893043(0x8009030d)

Unfortunately, it looks like Microsoft has embedded some information in the certificate that would prevent me from using SelfSSL or similar tools. Here's the subject (suitably scrubbed):

CN={hostname},L=951338967,OU=SharePoint,O=Microsoft

The "L" parameter matches the original (and incorrect) site identifier that the site was given and not the one that matches the rest of the farm.

My next step is to see if I can generate something that looks appropriate and install it with winhttpcertcfg.exe

We are also running x64 windows and moss 2007 with .net 3.5 sp1,same issues. I suspect this is the culprit.

To resolve this issue download the IIS6 resource kit and run the following command Selfssl /s:(IIS ID of the Office Server Web Services site) /v:9999

Cheers,

-Ivan

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top