Frage

Wir erhalten die folgende Fehlermeldung, wenn wir auf „Sucheinstellungen“ für einen Shared Services Provider klicken:„Die Authentifizierung ist fehlgeschlagen, weil die Gegenstelle den Transportstrom geschlossen hat.“

Dabei handelt es sich um eine neue Serverumgebung mit zwei Web-Frontends, einem Datenbankserver und einem Indexserver, alle unter Windows 2003 x64.

Hat jemand eine Idee, ob dies mit 64-Bit zusammenhängen könnte oder was den Fehler verursachen könnte?

Hier sind die vollständigen Details von ULS:

17.09.2008 16:30:34,13 w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86x4 Hoch Konfigurieren der Suchanwendungs-Webdienst-URL auf „https://mushni-sptwb04q:56738/Shared%20Services%20Portal/Search/SearchAdmin.asmx'.

17.09.2008 16:30:34,14 w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze High Ausnahme im Search Admin-Webdienst-Proxy (Client) gefangen.System.Net.WebException:Die zugrunde liegende Verbindung wurde geschlossen:Beim Senden ist ein unerwarteter Fehler aufgetreten.---> System.IO.IOException:Die Authentifizierung ist fehlgeschlagen, da die Gegenpartei den Transportstrom geschlossen hat.bei System.Net.Security.SslState.StartReadFrame(Byte[]-Puffer, Int32 readBytes, AsyncProtocolRequest asyncRequest) bei System.Net.Security.SslState.StartReceiveBlob(Byte[]-Puffer, AsyncProtocolRequest asyncRequest) bei System.Net.Security.SslState. ForceAuthentication(Boolean retainFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest) bei System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult) bei System.Threading.ExecutionContext.runTryCode(Object userData) bei System.Runtime.Co...

17.09.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) bei System.Threading.ExecutionContext .Run(ExecutionContext, contextCallback callback, Object state) bei System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result) bei System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size) bei System.Net.PooledStream .Write(Byte[]-Puffer, Int32-Offset, Int32-Größe) bei System.Net.ConnectStream.WriteHeaders(Boolean async) --- Ende des inneren Ausnahme-Stack-Trace --- bei System.Web.Services.Protocols.WebClientProtocol.GetWebResponse (WebRequest-Anfrage) bei System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest-Anfrage) bei System.Web.Services.Protocols.SoapHt...

17.09.2008 16:30:34,14* w3wp.exe (0x0E84) 0x030C Search Server Common MS Search Administration 86ze Hoch ...tpClientProtocol.Invoke(String methodName, Object[] Parameters) bei Microsoft.Office.Server.Search. Administration.SearchWebServiceProxy.RunWithSoapExceptionHandling[T](String methodName, Object[]-Parameter)

War es hilfreich?

Lösung

Ich denke, man diese Ausnahme in dem Indexserver findet, nicht wahr?

Sind Sie in der Lage zu ‚ https zu durchsuchen: // mushni- sptwb04q: 56738 / Shared% 20Services% 20Portal / suchen / SearchAdmin.asmx ‘aus dem Index-Server

Es scheint, wie SSL nicht richtig auf dem Front-End-Server bereitgestellt wird. Dies könnte lösen Ihr Problem:

  1. Entfernen Sie das SSL-Zertifikat des Front-End-Servers
  2. Entfernen Sie den Index-Server aus der Farm
  3. Verschieben Sie die Such- und Index Rollen zu einem der Front-Ends
  4. Schließen Sie sich der Indexserver zurück auf die Farm
  5. Fügen Sie die Index / Suche Rollen auf den Indexserver
  6. Wenden Sie das SSL-Zertifikat (Sie können sie erzeugen mit SelfSSL) zu den beiden Front-Ends

Andere Tipps

Seien Sie vorsichtig mit SelfSSL, seinem besseren Nutzung SSLDiag zu verwenden. SelfSSL hat einen Fehler, wenn Sie es verwenden Zertifikate auf mehrere Standorte auf dem gleichen Feld zuweisen, wird nur die letzte Seite arbeiten. Sie können SslDiag von der Kommandozeile ausgeführt wie folgt:

ssldiag / SelfSSL / V: 999 / N: CN = / S:

Verwenden Sie Metabasis-Explorer die Seite zu finden ist.

Könnte ein SSL-Problem sein.
Haben Sie einen Blick in Profilen Einstellungen haben, haben Sie einen Fehler erhalten, wenn der Nutzer Zugriff auf Profileinstellungen für das gleiche SSP?

Ich habe das gleiche Problem.Die Website „Office Server Web Services“ (im Folgenden OSWS) ist auf meinem App-Server über HTTP verfügbar, jedoch nicht über HTTPS.Es spielt keine Rolle, von wo aus ich versuche, auf die HTTPS-URL zuzugreifen, es schlägt einfach fehl (lesen Sie:kein HTTP-Fehlercode).

Allerdings habe ich mir noch einige weitere Informationen einfallen lassen.Als der App-Server der Farm hinzugefügt wurde, gab er OSWS eine andere Site-ID als im Rest der Farm.Ich habe versucht, die Site-ID zu ändern, aber das hat nicht funktioniert.Ich habe auch versucht, das IIS-Diagnose-Toolkit zu installieren.Das wies mich auf das Zertifikat hin, das MOSS installiert hatte, als die Maschine mit der Farm verbunden wurde.Die Linie von Interesse ist diese:

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

Leider sieht es so aus, als hätte Microsoft einige Informationen in das Zertifikat eingebettet, die mich daran hindern würden, SelfSSL oder ähnliche Tools zu verwenden.Hier ist das Thema (entsprechend geschrubbt):

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

Der Parameter „L“ stimmt mit der ursprünglichen (und falschen) Site-ID überein, die der Site zugewiesen wurde, und nicht mit der, die mit dem Rest der Farm übereinstimmt.

Mein nächster Schritt besteht darin, zu sehen, ob ich etwas generieren kann, das angemessen aussieht, und es mit winhttpcertcfg.exe zu installieren

Wir laufen auch x64-Fenster und MOSS 2007 mit .net 3.5 sp1, gleichen Fragen. Ich vermute, dies ist der Schuldige.

Um dieses Problem zu lösen, das IIS6 Resource Kit herunterladen und den folgenden Befehl ausführen SelfSSL / s: (IIS-ID der Web Services-Site Office Servers) / v: 9999

Cheers,

-Ivan

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top