Event-ID: 8313 – A failure was reported when trying to invoke a service application: EndpointFailure

Problem

Event-ID: 8313 – SharePoint Foundation – Topologie – Fehler beim Versuch, eine Dienstanwendung aufzurufen: EndpointFailure

Fehler beim Versuch, eine Dienstanwendung aufzurufen: EndpointFailure.
. . .

Event-ID: 8313 – SharePoint Foundation – Topologie – A failure was reported when trying to invoke a service application: EndpointFailure

A failure was reported when trying to invoke a service application: EndpointFailure
. . .

Details

Beschreibung

Es werden Einträge mit der Event-ID: 8313 in das ULS Log geschrieben.

Die Event-ID: 8313 findet man auch in der Ereignisanzeige (Event Viewer) mindestens einmal täglich (evtl. auf unterschiedlichen SharePoint Servern der Farm).

Es kann auch sein, dass die Event-ID: 8313 auch genau dann im ULS-Log und im Event Viewer generiert wird, wenn gewisse Vorgänge im SharePoint ausgeführt und mit Fehlermeldung beendet werden. Z.B. die Synchronisierung einer Aufgabenliste mit Outlook.

Ist-Zustand

SharePoint Umgebung

• SharePoint 2013 SP1 (On-Premises, 3 Tier Cluster)
• MS SQL-Server 2008 R2 Failover-Cluster
• Backup: AvePoint DocAve 6 SP5
• OWA / WAC
• Workflow-Manager
• BI
  • SSRS (Native & Integrated Mode)
  • SSAS, PowerPivot (Native & Integrated Mode)
• Monitoring
  • SCOM
  • Nagios (Icinga)

Der Server, der in den ULS auftaucht (hier „old-sp-server„) wurde vor längerer Zeit aus der Farm entfernt.

ULS Log

In den ULS Logs findet man folgende Einträge:

Product: SharePoint Foundation

Product: SharePoint Portal Server

Product: SharePoint Portal Server

Product: SharePoint Portal Server

Ereignisprotokoll

In der Windows Ereignisanzeige (Event Viewer) ist folgender Event Log Eintrag mit der Event-ID: 8313 vorhanden (eventuell nicht auf allen SharePoint-Servern der Farm gleichzeitig zu sehen):

Event-ID: 8313

Deutsches System

Event-ID: 8313

Englisches System

Fix

Dies wurde durchgeführt, hat aber zu keiner Lösung geführt

Der Server, der in den ULS auftaucht (hier „old-sp-server„) wurde vor längerer Zeit aus der Farm entfernt.

Benutzerprofildienst neu gestartet

Das Neustarten des Profildienstes auf allen SharePoint-Servern (ZA > Dienste auf dem Server) brachte keine Lösung.

URL im Browser nicht erreichbar

Der Aufruf der URL aus den Logs im Browser

http://sp-server:32843/fea20cf0/ProfileService.svc

Ergab:

Serverfehler in der Anwendung /fea20cf0.
——————————————————————————–

Die Ressource kann nicht gefunden werden.
Beschreibung: HTTP 404. Die gesuchte Ressource oder eine ihrer Abhängigkeiten wurde möglicherweise entfernt, umbenannt oder ist vorübergehend nicht verfügbar. Überprüfen Sie folgende URL, und stellen Sie sicher, dass sie richtig geschrieben wurde.

Angeforderter URL: /fea20cf0/ProfileService.svc

IIS-Site

Die IIS-Site mit der ID „fea20cf0-….“ unter Sites/SharePoint Web Services existiert und ist gestartet.

Der Anwendungspool (unter Grundeinstellungen) existiert und ist mit der Site verknüpft.

Information über TopologyService sammeln

ServiceApplication

ApplicationProxies

Normalerweise muss sich „ServiceEndpointUri“ auf einem Server befinden, der noch in der SP-Farm vorhanden ist. Hier ist es nicht der Fall!

Außerdem müssen normalerweise die Eigenschaften von „ServiceEndpointUri“ gleich den Eigenschaften von „LoadBalancerUrl“ (aus Get-SPTopologyServiceApplication | fl *) sein.

Die Ausgabe der Zeilen:

Get-spserviceinstance | Select TypeName, Server | ft -auto
(Get-SPTopologyServiceApplication).ServiceInstances | ft -auto *


listet nur die vorhandenen sp-server auf – nicht den alten Server.

Endpoint-ListenUris  der ServiceApp

Unter ListenUris werden auch nur die vorhandenen sp-server aufgelistet – nicht der alte Server, der aus der Farm entfernt, aber immer noch als ServiceEndpointUri weiter oben aufgelistet wird.

CA > Manage Service Applications

In der Zentraladministration unter „Dienstanwendungen verwalten“ ist die Dienstanwendung „Anwendungserkennung und Anwendung des Lastenausgleichsdiensts“ bzw. „Application Discovery and Load Balancer Service Application“ ohne Anwendungsproxy aufgelistet.

So würde die normale, funktionierende Konfiguration aussehen:

In diesem Fall wird die Dienstanwendung ohne Proxy aufgelistet – nicht OK:

Der Proxy, der offensichtlich mit dem alten Server verknüpft ist, welcher schon längst aus der Farm entfernt wurde, wird am Ende der Dienstanwendungsliste aufgelistet, allerdings ohne einer Dienstanwendung.

Die ID entspricht der aus den ULS- und Event-Logs.

Timer-Job

Get-SpTimerJob job-spconnectedserviceapplication-addressesrefresh | fl *


<# Ausgabe:
Description                 : Synchronisiert Verbindungsinformationen für Remotedienstanwendungen.
DisplayName                 : Aktualisierungsauftrag für Anwendungsadressen
Service                     : SPTimerService Name=SPTimerV4
WebApplication              :
Server                      :
LockType                    : Job
Schedule                    : every 15 minutes between 0 and 0
Title                       : Aktualisierungsauftrag für Anwendungsadressen
LastRunTime                 : 12.05.2016 14:15:00
Retry                       : False
IsDisabled                  : False
VerboseTracingEnabled       : False
HistoryEntries              : {, , , ...}
EnableBackup                : False
DiskSizeRequired            : 0
CanSelectForBackup          : False
CanRenameOnRestore          : False
CanSelectForRestore         : False
Name                        : job-spconnectedserviceapplication-addressesrefresh
TypeName                    : Microsoft.SharePoint.SPConnectedServiceApplicationAddressesRefreshJob
Id                          : 5051c829-8723
Status                      : Online
Parent                      : SPTimerService Name=SPTimerV4
Version                     : 2880
Properties                  : {}
Farm                        : SPFarm Name=<SPFarm Name>
UpgradedPersistedProperties : {}
#>

Offensichtlich läuft der Timer-Job für die Aktualisierung der Endpoints ohne Probleme.

(Get-SpTimerJob job-spconnectedserviceapplication-addressesrefresh).HistoryEntries | Select -first 10


<# Ausgabe
JobDefinitionId    : 5051c829-8723
JobDefinitionTitle : Aktualisierungsauftrag für Anwendungsadressen
WebApplicationId   : 00000000-0000-0000-0000-000000000000
WebApplicationName :
ServiceId          : 40c02ff4-17c0
ServerId           : a022786d-518c
ServerName         : sp-server02
Status             : Succeeded
StartTime          : 12.05.2016 12:30:00
EndTime            : 12.05.2016 12:30:00
DatabaseName       :
ErrorMessage       :

JobDefinitionId    : 5051c829-8723
JobDefinitionTitle : Aktualisierungsauftrag für Anwendungsadressen
WebApplicationId   : 00000000-0000-0000-0000-000000000000
WebApplicationName :
ServiceId          : 40c02ff4-17c0
ServerId           : a022786d-518c
ServerName         : sp-server02
Status             : Succeeded
StartTime          : 12.05.2016 12:15:00
EndTime            : 12.05.2016 12:15:01
DatabaseName       :
ErrorMessage       :

JobDefinitionId    : 5051c829-8723
JobDefinitionTitle : Aktualisierungsauftrag für Anwendungsadressen
WebApplicationId   : 00000000-0000-0000-0000-000000000000
WebApplicationName :
ServiceId          : 40c02ff4-17c0
ServerId           : a022786d-518c
ServerName         : sp-server02
Status             : Succeeded
StartTime          : 12.05.2016 12:00:00
EndTime            : 12.05.2016 12:00:00
DatabaseName       :
ErrorMessage       :
. . .
#>

DB-Abfrage

In PowerShell die ID des ServiceApplicationProxy herausfinden und kopieren.

Im SSMS wurde folgende Abfrage gestartet („SP_Configuration_DB“ und „089ce7de“ mit eigenen Werten ersetzen):

In der Spalte „Properties“ wird eine klickbare XML generiert.

Unsere Beispielausgabe sieht wie folgt aus (alle IDs wurden gekürzt):

Workaround

Im SSMS folgende Abfrage starten („SP_Configuration_DB“ und „089ce7de“ mit eigenen Werten ersetzen):

SELECT [Properties]
FROM [Configuration_DB].[dbo].[Objects] WITH (NOLOCK)
WHERE [Id] LIKE '089ce7de'

Der Inhalt der Spalte kann nach einem rechten Maustastenklick in die Zwischenablage kopiert, in einen Texteditor eingefügt und dort passend verändert werden (also den alten Server durch einen neuen ersetzen).

Mit folgenden SQL-Zeilen könnte man den Inhalt des Feldes verändern (<YOUR UPDATED COLUMN CONTENT> muss durch den veränderten Inhalt aus dem Editor ersetzt werden)

UPDATE [Objects]
FROM [Configuration_DB].[dbo].[Objects] WITH (NOLOCK)
WHERE Id = '089ce7de'
SET Properties = '<YOUR UPDATED COLUMN CONTENT>'

Links

1. sharepoint.stackexchange.com: Application Discovery Load Balancer Service EndpointFailure (topology.svc)
2. networksteve.com: Topology.svc – Endpoints – Web Services High Availability
3. blogs.msdn.microsoft.com: Increasing Service Application Redundancy
4. social.technet.microsoft.com: Load Balancer Error Mesaage
5. gai3kannan.wordpress.com: A failure was reported when trying to invoke a service application: EndpointFailure – Solution Step by Step
6. blogs.msdn.microsoft.com: Troubleshooting App Management WCF Endpoint Failures
7. blogs.msdn.microsoft.com: How I Learned to Stop Worrying and Love the SharePoint Topology Service
8. sharepoint.stackexchange.com: Application Discovery Load Balancer Service EndpointFailure (topology.svc)
9. blogs.msdn.microsoft.com: SharePoint 2010 Service Application Load Balancer

Der Beitrag Event-ID: 8313 – A failure was reported when trying to invoke a service application: EndpointFailure erschien zuerst auf Die SharePoint-Wiese.