我部署的环境是:2 WEF,1 Index/Query,1 SQL

问题:
1. Server 链接设定好后,我就开始配置SSP,SSP是在一个单独的WebApplication上,也可以正常开启.
    但是,在SSP中开Search Setting,提示:   "Authentication failed because the remote party has closed the transport stream "
    我查了一下,这个错误很多地方都说是跟SSL 有关,可是我在创建SSP的时候,都没有选过启用SSL 啊.
2. SSP中开启:User profiles and properties
    也提示报错:An error has occurred while accessing the SQL Server database or the Office SharePoint Server Search service.
=======================================
Solution:

·         Server1 - Web Front End / Query

·         Server2 - Index

I started hitting problem when attempting to configure search using Search Settings within the SSP administration site, it generated the following error:

Authentication failed because the remote party has closed the transport stream

After much investigation including reviewing the Application and ULS logs I found the cause of the issue being the fact that Server1 could not connect to the search web service on Server2 using the following URL https://server2:56738/SharedServices1/Search/SearchAdmin.asmx

To rule out an issue with a firewall or intermediary networking device I ran the following command using cmd.exe from server1 to test connectivity to server2

telnet server2 56738

This connected successfully, which meant that the issue was likely to be caused by the SSL certificate that is created during installation/configuration and is used by the Office Server Web Services site.

To resolve the issue, I used the IIS 6.0 resource kit tool SelfSSL to re-create the SSL certificate used for the Office Server Web Services site on both servers. This tool is available from http://www.microsoft.com/downloads/details.aspx?FamilyID=56fc92ee-a71a-4c73-b628-ade629c89499&displaylang=en.

I ran the following command on both servers to do this:

Selfssl /s:(IIS ID of the Office Server Web Services site) /v:(length of validity for the certificate in days – I opted for 1000)

This then replaced the existing certificate with the newly created SelfSSL certificate and Search Settings now worked.

My investigation into the root cause of this continues….I’ll keep you all posted!

UPDATE 08/01/09 - This issue can potentially be caused when MOSS 2007 is installed on a server running .NET 3.5 SP1. This can be worked around by applying SP1 for .NET 3.5 after MOSS 2007 has been installed a KB article is now live at http://support.microsoft.com/?id=962928