Problem

Event-ID: 6398

Ausnahme der Methode ‘Execute’ der Auftragsdefinition ‘Microsoft.SharePoint.Administration.SPUsageImportJobDefinition’

Der Zugriff auf den Pfad “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS” wurde verweigert.

Timer-Job “Import der Microsoft SharePoint Foundation-Verwendungsdaten” Fehlgeschlagen

Details

Es werden keine Verwendungsdaten generiert obwohl die Funktion und die Timer-Jobs aktiviert sind.

Es wird ein Windows Event-ID: 6398 generiert.
Die Details lauten:
Ausnahme der Methode ‘Execute’ der Auftragsdefinition ‘Microsoft.SharePoint.Administration.SPUsageImportJobDefinition’ (ID 12345678-1234-1234-1234-123456789). Weitere Informationen finden Sie unten.
Der Zugriff auf den Pfad “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS” wurde verweigert.

Wenn man in die Dienstanwendung “Usage and Health Data Collection Service” reinschaut und auf ” Protokollerfassungszeitplan” drauf klickt, dann sieht man zwei Auftragsdefinitionen:

• Import der Microsoft SharePoint Foundation-Verwendungsdaten
• Verarbeitung der Microsoft SharePoint Foundation-Verwendungsdaten

Wenn man diese anklickt, kann man sehen, dass diese aktiviert sind.

Wenn man “Auftragsverlauf” auf der linken Seite anklickt, dann sieht man, dass viele (wenn nicht alle) Jobs fehlgeschlagen sind.

Klickt man “Fehlgeschlagen” an, dann sieht man in Details folgende Fehlermeldung:

Der Zugriff auf den Pfad “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS” wurde verweigert

Fix

Die Berechtigungen werden in SP mit den lokalen Gruppen WSS_* und nicht mit einzelnen Konten geregelt.

Diese lokalen Gruppen (s.u.) müssen auf allen Servern auf den o.g. Ordner berechtigt sein. Sobald die Berechtigungen gesetzt wurde, sollten auch die Timer-Jobs erfolgreich sein.

WSS_ADMIN_WPG Berechtigungen setzen

• Hat “Ändern” Berechtigungen auf den Ordner C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15 und durch Vererbung auf den darunter liegenden Ordner “LOGS“
• Wenn keine Vererbung aktiviert, dann die Gruppe direkt auf den Ordner LOGS berechtigen

WSS_WPG und WSS_RESTRICTED_WPG_V4 Berechtigungen setzen

Spezielle Berechtigungen s.Bild (zur Not geht wohl auch “Ändern” Recht)

Dienstanwendungsproxy kontrollieren

Überprüfen, ob der Dienstanwendungsproxy (Usage and Health Data Collection Service) “Proxy für die Sammlung von Verwendungs- und Integritätsdaten” in der ZA den Status “Gestartet” hat.

Wenn der Proxy nicht gestartet ist, dann folgende Zeilen ausführen:

$proxy = Get-SPServiceApplicationProxy| where {$_.TypeName-eq"Proxy für die Sammlung von Verwendungs- und Integritätsdaten"}

$proxy.Provision()

Wenn es gar nicht funktioniert, dann hilft vielleicht zur Not folgendes:

Anstatt Windows-Authentifizierung eine SQL-Kennung und db_owner Rechte für die Logging-DB erstellen, und diese SQL-Kennung in der Usage-Dienstanwendung für die Anmeldung an der DB eintragen (dort dann anstatt “Windows-Authentifizierung (empfohlen)” die Option “SQL-Authentifizierung” auswählen.

Hilfreichen CMD-Lets

#Löscht eine Verwendungsanwendung
Remove-SPUsageApplication -Identity "Usage and Health data collection" –RemoveData

#Dieses Beispiel erstellt eine neue Verwendungsanwendung für den angegebenen Namen
New-SPUsageApplication -Name " Usage and Health data collection "

#Die Anwendung muss noch bereitgestellt werden (Proxy wahrscheinlich gestoppt)
$proxy = Get-SPServiceApplicationProxy| where {$_.TypeName-eq"Proxy für die Sammlung von Verwendungs- und Integritätsdaten"}
$proxy.Provision()

#Usage-Dienstanwendung ändern
Set-SPUsageApplication -DatabaseServer <DatabaseServerName> -DatabaseName <DatabaseName> [-DatabaseUserName <UserName>] [-DatabasePassword <Password>] [-Verbose]

#In diesem Beispiel wird die Verwendungsprotokollierung deaktiviert, das Verzeichnis geändert, in dem Verwendungsdateien gespeichert werden, und alle 5 Minuten eine neue Verwendungsprotokolldatei erstellt.
Set-SPUsageService -LoggingEnabled $false
Set-SPUsageService -UsageLogLocation "D:\\testusagelogdir"
Set-SPUsageService -UsageLogCutTime 5

Quellen und hilfreiche Links

1. http://blog.mpecsinc.ca/2011/01/sbs-2011-sharepoint-foundation-event-id.html
2. http://davidmsterling.blogspot.de/2013/01/sharepoint-2013-event-id-2163.html
3. http://guidesharepoint.wordpress.com/2013/12/13/enabling-usage-reportsharepoint-2013
4. http://blogs.technet.com/b/praveenh/archive/2010/11/02/usage-reporting-in-sharepoint-wss-or-moss.aspx

Der Beitrag Timer-Job “Import der Microsoft SharePoint Foundation-Verwendungsdaten” Fehlgeschlagen erschien zuerst auf SharePoint-Wiese.

Problem

ID: 6398

The Execute method of job definition Microsoft.SharePoint.Administration.SPUsageImportJobDefinition (ID 12345678-1234-1234-1234-123456789) threw an exception. More information is included below.

Access to the path ‘C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS’ is denied.

Ausnahme der Methode ‘Execute’ der Auftragsdefinition ‘Microsoft.SharePoint.Administration.SPUsageImportJobDefinition’ (ID 12345678-1234-1234-1234-123456789). Weitere Informationen finden Sie unten.

Der Zugriff auf den Pfad “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS” wurde verweigert.

Details

Ist-Zustand

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

Beschreibung

Es wird eine Meldung mit der ID: 6398 in der Ereignisanzeige (Event-Viewer) angezeigt.

Ereignisprotokoll

In der Windows Ereignisanzeige (Event Viewer) ist folgender Event Log Eintrag mit der Event-ID: 6398 vorhanden:

Fix

Ordnerberechtigungen ändern

Lösung s. Timer-Job “Import der Microsoft SharePoint Foundation-Verwendungsdaten” Fehlgeschlagen

Der Beitrag ID: 6398 – Der Zugriff auf den Pfad “C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\LOGS” wurde verweigert erschien zuerst auf SharePoint-Wiese.

Problem

DocAve Control Service Status Down

Man findet in DocAve Control Service Status Down als roten Pfeil der nach unten zeigt im Control Panel > Manager Monitor

Es war kein an https://<DocAve-Management-Server>:<Control-Port>/ControlCore/ControlCoreService.svc abhörender Endpunkt vorhanden, der die Nachricht annehmen konnte.

Findet man im DocAve-Log unter:
C:\Program Files\AvePoint\DocAve6\Manager\Control\Logs\DocAve-Timer.log

Der Remoteserver hat einen Fehler zurückgegeben: (403) Unzulässig.

Auch diese Fehlermeldung findet man im Doc-Ave-Log unter:
C:\Program Files\AvePoint\DocAve6\Manager\Control\Logs\DocAve-Timer.log

Event-ID: 5407 – Failed to operate the service.

Event-ID: 7034 – Dienst “DocAve 6 Media Service” wurde unerwartet beendet

Details

Beschreibung

Man findet in DocAve Control Service Status Down als roten Pfeil der nach unten zeigt (im Control Panel > Manager Monitor)

Der Web-Dienst des Control Services ist im Browser erreichbar:
https://<DocAve-Management-Server>:<Control-Port>/ControlCore/ControlCoreService.svc

Ist-Zustand

SharePoint Umgebung

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

DocAve-Timer.log

Im DocAve-Timer Log findet man unter
C:\Program Files\AvePoint\DocAve6\Manager\Control\Logs\DocAve-Timer.log

findet man folgende Einträge:

ERROR 11-25 07:55:18,893 ServiceStatusCheckerThread AvePoint.ControlPanel.Service.ServiceStatusChecker.Object.CheckStatusThread 0- Es war kein an https://<DocAve-Management-Server>:<Control-Port>/ControlCore/ControlCoreService.svc abhörender Endpunkt vorhanden, der die Nachricht annehmen konnte. Dies wird häufig durch eine fehlerhafte Adresse oder SOAP-Aktion verursacht. Weitere Details finden Sie unter "InnerException", sofern vorhanden.System.ServiceModel.EndpointNotFoundException: Es war kein an https://<DocAve-Management-Server>:<Control-Port>/ControlCore/ControlCoreService.svc abhörender Endpunkt vorhanden, der die Nachricht annehmen konnte. Dies wird häufig durch eine fehlerhafte Adresse oder SOAP-Aktion verursacht. Weitere Details finden Sie unter "InnerException", sofern vorhanden. ---> System.Net.WebException: Der Remoteserver hat einen Fehler zurückgegeben: (403) Unzulässig.
   bei System.Net.HttpWebRequest.GetRequestStream(TransportContext& context)
   bei System.Net.HttpWebRequest.GetRequestStream()
   bei System.ServiceModel.Channels.HttpOutput.WebRequestHttpOutput.GetOutputStream()
   --- Ende der internen Ausnahmestapelüberwachung ---

Ereignisprotokoll

In der Windows Ereignisanzeige (Event Viewer) sind folgende Event Log Einträge mit der Event-ID: 5407 und der Event-ID: 7034 vorhanden:

Oder auch:

Oder auch:

Fix

Mit Hilfe des Microsoft Network Monitors konnte festgestellt werden, dass die DocAve-Dienste (z.B. ControlTimerService.exe) den Web über Proxy-Server zu nehmen versuchen.

Das funktioniert in unserem System nicht. Deshalb wird versucht die Dienste zum “DirectAccess” (ohne Proxy-Kommunikation) zu überreden.

Die Abfrage des System-Proxy-Servers per netsh winhttp show proxy zeigte, dass hier bereits kein Proxy-Server benutzt wird (DirectAccess).

Der Import der richtigen Einstellungen aus dem IE (die per GPOs gesetzt werden und schon richtige Ausnahmen haben) per netsh winhttp import proxy ie war keine Lösung.

Workaround

Management-Dienste unter Agent-User Account laufen lassen

Die Manager-Dienste (Media Service, Report Service, Timer Service) laufen auf dem DocAve-Management-Server standardmäßig unter der Benutzerkennung “local system”. Diese drei Windows-Dienste können wir auf dem Management-Server in der Dienste-Konsole so einstellen, dass sie unter der Domänenkennung des DocAve-Agents laufen.

Dabei muss dieses Konto entweder in den lokalen Sicherheitsgruppenrichtlinien das Recht sich als Dienst anmelden zu dürfen bekommen, oder Mitglied der lokalen Gruppe der Administratoren werden.

Anmelden und Proxy-Server Einstellungen anpassen

Falls der “Control Service” weiterhin nicht gestartet werden kann und immer noch den Status “down” (roter Pfeil nach unten) hat, dann kann man folgendes durchführen.

1. Auf dem DocAve-Management-Server (dort, wo die drei erwähnten Management-Dienste laufen) mit der Kennung, mit der nun auch die Dienste laufen (DocAve-Agent-User) anmelden.
2. Proxy-Server Einstellungen in den Interneteinstellungen aufrufen.
3. Falls die Proxy-Einstellungen nicht per GPO gesetzt werden, diese per Hand so anpassen, dass kein Proxy-Server benutzt wird (entweder ganz abschalten oder Ausnahmen setzen).
4. Es kann wohl nicht schaden, diese Proxy-Einstellungen dann auch als Systemeinstellungen per netsh winhttp import proxy ie zu übernehmen.

Der Beitrag DocAve Control Service Status Down erschien zuerst auf SharePoint-Wiese.

Problem

Fehler beim PivotTable-Vorgang – Es wurde kein Server gefunden, von dem das Datenmodell der Arbeitsmappe geladen werden konnte

Wenn man in einer PowerPivot-Excelarbeitsmappe auf Elemente klickt, die auf Datenmodell zugreifen müssen.

We cannot locate a server to load the workbook Data Model

Microsoft.AnalysisServices.Streaming.ServerNotFoundException: There are no servers available or actively being initialized

Im ULS-Log

Failed to create an external connection or execute a query. Provider message: There are no servers available or actively being initialized

Im ULS-Log

Details

Beschreibung

Folgender Fehler wird angezeigt, wenn man in einem PowerPivot Excel Workbook auf Dokumentelemente klickt, wodurch auf das Datenmodell zugegriffen wird.

Fehler beim PivotTable-Vorgang
Es wurde kein Server gefunden, von dem das Datenmodell der Arbeitsmappe geladen werden konnte

bzw. auf den auf Englisch installierten Systemen:

We cannot locate a server to load the workbook Data Model

Ist-Zustand

SharePoint Umgebung

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

ULS Log

In den ULS Logs findet man folgende Einträge:

Uncaught CLR exception crossing the Interop boundary: Microsoft.AnalysisServices.Streaming.ServerNotFoundException: There are no servers available or actively being initialized.     bei Microsoft.AnalysisServices.Streaming.OnPremise.ServerPool.Microsoft.AnalysisServices.Streaming.OnPremise.IServerPool.GetAvailableServers()     bei Microsoft.AnalysisServices.Streaming.OnPremise.LoadBalancer.<>c__DisplayClass1.<GetLoadBalancedOperation>b__0()     bei Microsoft.AnalysisServices.Streaming.OnPremise.LoadBalancer.GetLoadBalancedOperation(Func`1 onBegin)     bei Microsoft.AnalysisServices.Streaming.OnPremise.Database.Loading.Create()     bei Microsoft.AnalysisServices.Streaming.OnPremise.ServerPool.<>c__DisplayClass9.<Microsoft.AnalysisServices.Streaming.OnPremise.IServerPool.CreateConnection>b__8(Guid id). . .

Failed to create an external connection or execute a query. Provider message: There are no servers available or actively being initialized., ConnectionName: , Workbook: http://<sp-site>/Dashboards/<PowerPivot-Excel-Workbook>.xlsx.

Verbindung

Die Verbindung mit der Analysis Services (PowerPivot) Instanz per SSMS klappt nur lokal, auf dem Server, auf dem auch die Instanz läuft.

Vom anderen Server klappt die Verbindung per SSMS nicht. Die Fehlermeldung lautet:

Es kann keine Verbindung mit ‘<Server\Instanz>’ hergestellt werden.
Zusätzliche Informationen:
Es kann keine Verbindung hergestellt werden. Stellen Sie sicher, dass der Server ausgeführt wird. (Microsoft.AnalysisServices.AdomdClient)

Ein Verbindunngsversuch ist fehlgeschlagen, da die Gegenstelle nach einer bestimmten Zeitspanne nicht richtig reagiert hat, oder die hergestellte Verbindung war fehlerhaft, da der verbundene Host nicht reagiert hat <IP:DynamicPort> (System)

Oder auf EN:

A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond

Fix

Scheinbar wird per Instanznamen der SQL-Browser (läuft auf 2382) angesprochen, und der gibt den Port zurück, auf welchem die PowerPivot-Instanz läuft (in diesem Fall dynamischer Port 56426 s. Fehler in SSMS oben). Und dieser PowerPivot-Instanzport ist in der Firewall normalerweise nicht freigeschaltet, da diese sich ständig verändern.

Prüfen, welche Ports benutzt werden

1. Im SQL Server Configuration Manager die Prozess-ID der PowerPivot-Instanz herausfinden.
   
2. In der CMD den Befehl netstat -aop TCP ausführen und die ID aus dem SQL-Manger finden. In der gleichen Zeile, in der Spalte “Lokale Adresse” sieht man den Port unter dem der Dienst läuft.
   

Verbindung zum Server prüfen

Verbindung (besonders von den WFEs) zum Server prüfen, auf dem die SSAS/PowerPivot Instanz installiert ist.
Z. B. per Telnet: telnet <PowerPivot Server IP> 2382

Firewalls prüfen

1. Windows-Firewall prüfen (zum Testen kann man eine “Alles erlauben Regel” verwenden).
2. Hardware-Firewall Logs auf Deny-Einträge überprüfen.

Kerberos Einstellung

Wenn SharePoint auf Kerberos-Authentifizierung eingestellt ist, dann muss man die Datei web.config des PowerPivot-Dienstes umstellen.

Siehe: PowerPivot für SharePoint installieren – Anleitung: PowerPivot Kerberos Einstellung

 Excel-Konto auf die Instanz berechtigen

Die Kennung der Excel-Dienstanwendung muss auch als Administrator auf die PowerPivot-Instanz gesetzt werden.

Siehe: Serveradministratoren für die PowerPivot-Instanz

IIS-Reset

Links

1. PowerPivot für SharePoint installieren – Anleitung: PowerPivot Kommunikation konfigurieren

Der Beitrag Fehler beim PivotTable-Vorgang – Es wurde kein Server gefunden, von dem das Datenmodell der Arbeitsmappe geladen werden konnte erschien zuerst auf SharePoint-Wiese.

Problem

Fehler bei der Aktualisierung der externen Daten

Diese Fehlermeldung wird angezeigt, wenn man in einer PowerPivot-Excel-Tabelle folgendes durchführt:
Daten > Alle Verbindungen aktualisieren
oder
Daten > Ausgewählte Verbindung aktualisieren

Fehler bei der Aktualisierung der externen Daten

Beim Bearbeiten des Datenmodells in der Arbeitsmappe ist ein Fehler aufgetreten. Versuchen Sie es bitte erneut.

Mindestens eine der Datenverbindungen in dieser Arbeitsmappe konnte nicht aktualisiert werden.
Die folgenden Verbindungen konnten nicht aktualisiert werden:

DataFeed items
Datenfeed_1_. . .

External Data Refresh Failed

An error occurred while working on the Data Model in the workbook. Please try again.

We were unable to refresh one or more data connections in this workbook.
The following connections failed to refresh:

Failed to create an external connection or execute a query

Im ULS Log findet man folgende Einträge:

Fix

Lokale Sicherheitsrichtlinie – Einsetzen als Teil des Betriebssystems

1. Die Benutzerkennung, unter der die SSAS (POWERPIVOT) Instanz läuft, herausfinden und notieren.
   Das kann man auf dem Server, auf dem die Instanz läuft entweder im “Sql Server Configuration Manager” in der Spalte “Anmelden als” oder in der Konsole für Windows-Dienste tun.
2. Lokale Sicherheitsrichtlinie aufrufen durch ausführen (Tastenkombination: [WIN]+[R]) von secpol.msc oder durch suchen nach “Lokale Sicherheitsrichtlinie”
3. Den Pfad öffnen: Sicherheitseinstellungen > Lokale Richtlinien > Zuweisen von Benutzerrechten
4. Die Richtlinie “Einsetzen als Teil des Betriebssystems” öffnen und dort die Benutzerkennung eintragen, unter der die POWERPIVOT-Instanz läuft.
   

Kerberos Delegierung überprüfen

Eine zusätzliche Fehlerquelle kann auch noch die falsch bzw. unvollständig konfigurierte Kerberos-Delegierung sein.

Diese gilt es zu überprüfen (z. B. SPNs etc. siehe Link Nr.1)

Links

1. blogs.technet.com: PowerPivot 2013 for SharePoint – “External Data Refresh Failed” using Interactive Data Refresh via “Use the authenticated user’s account”
2. msdn.microsoft.com: Power Pivot Data Refresh with SharePoint 2013

Der Beitrag Fehler bei der Aktualisierung der externen Daten – Mindestens eine der Datenverbindungen in dieser Arbeitsmappe konnte nicht aktualisiert werden erschien zuerst auf SharePoint-Wiese.

Problem

Error: Start process failed, The DocAve services on the member agent is down: server Name In Farm: <SP-Server02>

Wird als Comment in Details des Backup-Jobs angezeigt.

Details

Beschreibung

Der DocAve Backup-Job scheitert mit dem Status “Failed”.

In den Job Details sind viele Datenbanken aufgelistet, die nicht gesichert werden konnten.

In der Spalte “Agent” wird immer der gleiche <SP-Server01> aufgelistet.
In unserem Fall ist es der WFE-Server.

In der Spalte “Comment” steht dann folgender Text:
Error: Start process failed, The DocAve services on the member agent is down: server Name In Farm: <SP-Server02>
Wobei der SP-Server02 bei uns der DB-Server ist.

Log “SP2013PRControlBackup.exe_FBxxxxxxxxx_High.log”

In dem Log (Job Details, Download) mit dem Namen ” SP2013PRControlBackup.exe_FBxxxxxxxxx_High.log” findet man folgenden Einträge:

Ist-Zustand

SharePoint Umgebung

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

Fix

Der DocAve-Agent auf dem Server <SP-Server01> kann sich nicht mit dem anderen (vermutlich dem DB-)Server <SP-Server02> verbinden.

SQL-Aliase prüfen

Falls SQL-Aliase benutzt werden, prüfen ob diese auf allen nötigen SharePoint-Servern vorhanden sind.

Firewall prüfen

Wahrscheinlich sperrt die Firewall o.Ä. die Verbindung des Agents vom <SP-Server01> zum <SP-Server02>

Es scheint so, dass für den problemlosen Betrieb nicht nur die Kommunikation zwischen dem Control-Server und den Agents (plus umgekehrt), sondern auch die Kommunikation zwischen den einzelnen Agent-Servern nötig ist.

Als Lösung muss man entweder die Verbindung gestatten (hier wäre dass WFE->DB) oder eine Agent-Group erstellen und für Backups benutzen, in der sich die Server (z.B. die App-Server) befinden, die die Verbindung (in diesem Fall zu den DB-Servern) aufbauen dürfen.

Der Beitrag DocAve – Error: Start process failed, The DocAve services on the member agent is down erschien zuerst auf SharePoint-Wiese.

Problem

All WOPI Signature verification attempts failed

WOPI Proof: All WOPI Signature verification attempts failed

Im ULS-Log in der SP-Farm.

Leider kann das Dokument wegen eines Problems nicht geöffnet werden.

Microsoft Word Web App
Leider kann das Dokument wegen eines Problems nicht geöffnet werden. Sollte dies erneut auftreten, versuchen Sie, das Dokument in Microsoft Word zu öffnen.

Die Fehlermeldung wird im Browser, beim Versuch ein Dokument im SharePoint zu öffnen, angezeigt.

Invalid Proof Signature for file

WOPI (CheckFile) – Invalid Proof Signature for file <Dokument> . . .

Im ULS-Log in der SP-Farm.

HttpRequestAsync

HttpRequestAsync, (WOPICheckFile,WACSERVER) no response [WebExceptionStatus:ConnectFailure, url:http://sp.domain.de/_vti_bin/wopi.ashx/files/<ID>?access_token=. . . , exception:System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.

Im ULS-Log in der OWA-Farm.

Error message from host: Verifying signature failed, host correlation:

Im ULS-Log in der OWA-Farm.

WOPICheckFile,WACSERVER FileNotFound

WOPICheckFile,WACSERVER FileNotFound [url:https://<Sitecollection>/_vti_bin/wopi.ashx/files . . .

Im ULS-Log in der OWA-Farm.

WOPI CheckFile: Catch-All Failure

WOPI CheckFile: Catch-All Failure [exception:Microsoft.Office.Web.Common.EnvironmentAdapters.FileUnknownException: WOPI 404 bei Microsoft.Office.Web.Apps.Common.WopiDocument.LogAndThrowWireException(HttpRequestAsyncResult result, HttpRequestAsyncException delayedException) bei Microsoft.Office.Web.Apps.Common.HttpRequestAsync.End() bei Microsoft.Office.Web.Apps.Common.WopiDocument.GetWopiRequestResultWithRetry(Int32 maxSize, MemoryStream ms, WopiRequest wopiRequest) bei Microsoft.Office.Web.Apps.Common.WopiDocument.CheckWopiFile()]

Im ULS-Log in der OWA-Farm.

FileUnknownException while loading the app

FileUnknownException while loading the app. [FileSourceId: -1088102096] [ClusterId: 0] [ExtraErrorInfo: ]

Im ULS-Log in der OWA-Farm.

Details

Beschreibung

Der Versuch ein Dokument im SharePoint mit Hilfe von Office Web Apps direkt im Browser zu öffnen scheitert mit der Fehlermeldung:

Microsoft Word Web App
Leider kann das Dokument wegen eines Problems nicht geöffnet werden. Sollte dies erneut auftreten, versuchen Sie, das Dokument in Microsoft Word zu öffnen.

Es sind sehr viele ULS-Log Einträge sowohl auf den SharePoint-, als auch auf den OWA-Servern zu finden s. weiter u.

Es gibt keine Vorschau der Dokumente mehr im Browser (normalerweise nach dem Klicken auf die drei Punkte zu sehen).

Im Browser direkt werden nur Excel-Dokumente geöffnet (mit hilfe der Excel-Services – unabhängig von OWA). Man kann aber keine OWA-Unterstützten Dokumente (Word, PDF, PowerPoint) mehr direkt im Browser anzeigen lassen.

Der Fehler tritt wohl auf, wenn die SP-Farm länger nicht verfügbar war.

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)

ULS Log

SP ULS-Logs

In den ULS Logs auf den SharePoint-Servern findet man folgende Einträge:

OWA ULS-Logs

In den ULS Logs auf den OWA-Servern findet man im Ordner “C:\ProgramData\Microsoft\OfficeWebApps\Data\Logs\ULS” folgende Einträge:

Fix

Öffentlichen Schlüssel erneuern

Auf einem der SP-Server in der SharePoint-Verwaltungsshell ausführen:

# Öffentlichen Schlüssel aktualisieren
# owa.domain.de ist dabei der DNS-Name der OWA-Farm (LB) oder der Name eines OWA-Servers.

Update-SPWOPIProofKey -ServerName "owa.domain.de"

Das Update-SPWOPIProofKey-Cmdlet aktualisiert den öffentlichen Schlüssel, der zum Herstellen einer Verbindung mit der WOPI-Anwendung (z. B. ein Server, auf dem Office Web Apps Server ausgeführt wird) in der aktuellen SharePoint-Farm verwendet wird, in der dieses Cmdlet ausgeführt wird. Verwenden Sie dieses Cmdlet wenn die Synchronisierung der Schlüssel zwischen der SharePoint-Farm und der WOPI-Anwendung verloren geht. Sind die Schlüssel nicht synchronisiert, werden Dokumente u. U. im Browser nicht geöffnet, und die Protokolle des vereinheitlichten Protokollierungsdiensts (Unified Logging Service, ULS) enthalten Benachrichtigungen wie z. B. “Ungültige Nachweissignatur für Datei…” oder “Ungültige Nachweissignatur für Ordner…”.

In diesem Fall wird der aktuelle öffentliche Schlüssel von der WOPI-Anwendung (z. B. ein Server, auf dem Office Web Apps Server ausgeführt wird) abgerufen, und der in der SharePoint-Farm gespeicherte Schlüssel wird aktualisiert.

Verbindung zur OWA-Farm trennen und wiederherstellen

Falls der obere Schritt nicht erfolgreich war, dann kann man die Verbindung der SP-Farm zur OWA-Farm trennen und noch mal wiederherstellen.

Dazu folgende Zeilen auf einem der SP-Server ausführen:

# Die Verbindung der SP-Farm zur OWA-Farm trennen
Remove-SPWopiBinding -All

# Die Verbindung der SP-Farm zur OWA-Farm wiederherstellen
New-SPWopiBinding -ServerName "owa.domain.de"

Links

1. technet.microsoft.com: Update-SPWOPIProofKey
2. http://sharepoint-wiese.de: Office Web Apps Installation und SharePoint Integration
3. onpointwithsharepoint.blogspot.de: How to configure Office Web App Server integration with SharePoint 2013
4. wictorwilen.se: Office Web Apps Server 2013 – machines are always reported as Unhealthy

Der Beitrag WOPI Signature verification attempts failed erschien zuerst auf SharePoint-Wiese.

Problem

Invalid Proof Signature for file

WOPI (CheckFile) – Invalid Proof Signature for file <Dokument> . . .

Im ULS-Log in der SP-Farm.

Details

Beschreibung

Der Versuch ein Dokument im SharePoint mit Hilfe von Office Web Apps direkt im Browser zu öffnen scheitert mit der Fehlermeldung:

Microsoft Word Web App
Leider kann das Dokument wegen eines Problems nicht geöffnet werden. Sollte dies erneut auftreten, versuchen Sie, das Dokument in Microsoft Word zu öffnen.

Es sind sehr viele ULS-Log Einträge sowohl auf den SharePoint-, als auch auf den OWA-Servern zu finden.

Es gibt keine Vorschau der Dokumente mehr im Browser (normalerweise nach dem Klicken auf die drei Punkte zu sehen).

Im Browser direkt werden nur Excel-Dokumente geöffnet (mit hilfe der Excel-Services – unabhängig von OWA). Man kann aber keine OWA-Unterstützten Dokumente (Word, PDF, PowerPoint) mehr direkt im Browser anzeigen lassen.

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)

ULS Log

In den ULS Logs auf den SP-Servern findet man unter anderem folgenden Eintrag:

Fix

Öffentlichen Schlüssel erneuern

HowTo: WOPI Signature verification attempts failed

Der Beitrag OWA – Invalid Proof Signature for file erschien zuerst auf SharePoint-Wiese.

Problem

HttpRequestAsync

HttpRequestAsync, (WOPICheckFile,WACSERVER) no response [WebExceptionStatus:ConnectFailure, url:http://sp.domain.de/_vti_bin/wopi.ashx/files/<ID>?access_token=. . . , exception:System.Net.WebException: Die Verbindung mit dem Remoteserver kann nicht hergestellt werden.

Im ULS-Log in der OWA-Farm.

Details

Beschreibung

Der Versuch ein Dokument im SharePoint mit Hilfe von Office Web Apps direkt im Browser zu öffnen scheitert mit der Fehlermeldung:

Microsoft Word Web App
Leider kann das Dokument wegen eines Problems nicht geöffnet werden. Sollte dies erneut auftreten, versuchen Sie, das Dokument in Microsoft Word zu öffnen.

Es sind sehr viele ULS-Log Einträge sowohl auf den SharePoint-, als auch auf den OWA-Servern zu finden.

Es gibt keine Vorschau der Dokumente mehr im Browser (normalerweise nach dem Klicken auf die drei Punkte zu sehen).

Im Browser direkt werden nur Excel-Dokumente geöffnet (mit hilfe der Excel-Services – unabhängig von OWA). Man kann aber keine OWA-Unterstützten Dokumente (Word, PDF, PowerPoint) mehr direkt im Browser anzeigen lassen.

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)

ULS Log

In den ULS Logs auf den OWA-Servern findet man unter anderem folgenden Eintrag:

Fix

Öffentlichen Schlüssel erneuern

HowTo: WOPI Signature verification attempts failed

Der Beitrag OWA – HttpRequestAsync erschien zuerst auf SharePoint-Wiese.

Problem

Error message from host: Verifying signature failed, host correlation:

Im ULS-Log in der OWA-Farm.

Details

Beschreibung

Der Versuch ein Dokument im SharePoint mit Hilfe von Office Web Apps direkt im Browser zu öffnen scheitert mit der Fehlermeldung:

Microsoft Word Web App
Leider kann das Dokument wegen eines Problems nicht geöffnet werden. Sollte dies erneut auftreten, versuchen Sie, das Dokument in Microsoft Word zu öffnen.

Es sind sehr viele ULS-Log Einträge sowohl auf den SharePoint-, als auch auf den OWA-Servern zu finden.

Es gibt keine Vorschau der Dokumente mehr im Browser (normalerweise nach dem Klicken auf die drei Punkte zu sehen).

Im Browser direkt werden nur Excel-Dokumente geöffnet (mit hilfe der Excel-Services – unabhängig von OWA). Man kann aber keine OWA-Unterstützten Dokumente (Word, PDF, PowerPoint) mehr direkt im Browser anzeigen lassen.

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)

ULS Log

In den ULS Logs auf den OWA-Servern findet man unter anderem folgenden Eintrag:

Fix

Öffentlichen Schlüssel erneuern

HowTo: WOPI Signature verification attempts failed

Der Beitrag OWA – Verifying signature failed erschien zuerst auf SharePoint-Wiese.

Problem

Event-ID: 6398 – Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPSqlDeadlockDiagnosticProvider‘

Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPSqlDeadlockDiagnosticProvider‘ (ID <ID>). Weitere Informationen finden Sie unten.

Sie besitzen nicht die Berechtigung zum Ausführen von ‚SP_TRACE_CREATE‚.

Event-ID: 6398 – Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPSqlBlockingReportDiagnosticProvider‘

Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPSqlBlockingReportDiagnosticProvider‘ (ID <ID>). Weitere Informationen finden Sie unten.

The blocking query diagnostics provider could not set the ‚blocked process threshold‘ for the sql instance <SQL-Instanz-Name>.  Blocking queries will not be captured in this instance.  Error Code: Der Benutzer besitzt nicht die Berechtigung zum Ausführen dieser Aktion.
Sie haben keine Berechtigung zum Ausführen der RECONFIGURE-Anweisung.
Die Konfigurationsoption ‚blocked process threshold‘ ist nicht vorhanden, oder sie ist möglicherweise eine erweiterte Option.
Sie haben keine Berechtigung zum Ausführen der RECONFIGURE-Anweisung.

Event-ID: 6398 – Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPIOIntensiveQueryDiagnosticProvider‘

Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPIOIntensiveQueryDiagnosticProvider‘ (ID <ID>). Weitere Informationen finden Sie unten.

Sie besitzen nicht die Berechtigung zum Ausführen von ‚SP_TRACE_CREATE‚.

Event-ID: 6398 – Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider‘

Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider‘ (ID <ID>). Weitere Informationen finden Sie unten.

Aktualisierungskonflikt. Sie müssen diese Aktion wiederholen. Das SPWebService-Objekt wurde von <Farm/TimerService-Account>) im Prozess OWSTIMER (26568) auf dem Computer <SP-Server-Name> aktualisiert. Weitere Informationen zu dem Konflikt finden Sie im Ablaufverfolgungsprotokoll.

Failed to check usage db server Sie besitzen nicht die Berechtigung zum Ausführen von ‚SP_TRACE_CREATE‘.

In den ULS-Logs zu finden.

Oder auf Englisch: Failed to check usage db server You do not have permission to run ‚SP_TRACE_CREATE‚.

Failed to get legacy traces, Sie besitzen nicht die Berechtigung zum Ausführen von ‚SYS.TRACES‘.

In den ULS-Logs zu finden.

Oder auf Englisch: Failed to get legacy traces, You do not have permission to run ‚SYS.TRACES‚.

Unable to write service call usage entry.

In den ULS-Logs zu finden.

The Execute method of job definition Microsoft.SharePoint.Diagnostics.xxxx (ID xxxxx) threw an exception.

In den ULS-Logs zu finden.

… The blocking query diagnostics provider could not set the ‚blocked process threshold‘ for the sql instance …

In den ULS-Logs zu finden.

Details

Beschreibung

Die Beliebtheitstrends bzw. Verwendungsberichte (unter Websiteeinstellungen > Websiteverwaltung > Beliebtheitstrends) sind plötzlich leer.

In der Windows- Ereignisanzeige und in den ULS-Logs ist die Event-ID 6398 mit unterschiedlichsten Beschreibungen zu finden.
In den Windows-Events findet man folgende drei Einträge in unterschiedlichen Events (alle mit der ID 6398):

• Microsoft.SharePoint.Diagnostics.SPIOIntensiveQueryDiagnosticProvider
• Microsoft.SharePoint.Diagnostics.SPSqlDeadlockDiagnosticProvider
• Microsoft.SharePoint.Diagnostics.SPSqlBlockingReportDiagnosticProvider

Unter:
ZA > Dienstanwendungen verwalten > Usage and Health Data Collection Service (Dienstanwendung für die Sammlung von Verwendungs- und Integritätsdaten) > Integritätsprotokollierungs-Zeitplan (bzw.  Health Logging Schedule) > Auftragsverlauf (Job History)
findet man drei Jobs, die den Status Fehlgeschlagen haben. Um sich die Details anzuzeigen, kann man die Statusmeldung „Fehlgeschlagen“ anklicken.

• Diagnostic Data Provider: IO Intensive SQL Querie
  • Sie besitzen nicht die Berechtigung zum Ausführen von ‚SP_TRACE_CREATE‚.
• Diagnostic Data Provider: SQL Deadlock
  • Sie besitzen nicht die Berechtigung zum Ausführen von ‚SP_TRACE_CREATE‚.
• Diagnostic Data Provider: SQL Blocking Reports
  • The blocking query diagnostics provider could not set the ‚blocked process threshold‘ for the sql instance <SQL-Instanz-Name>. Blocking queries will not be captured in this instance. Error Code: Der Benutzer besitzt nicht die Berechtigung zum Ausführen dieser Aktion. Sie haben keine Berechtigung zum Ausführen der RECONFIGURE-Anweisung. Die Konfigurationsoption ‚blocked process threshold‘ ist nicht vorhanden, oder sie ist möglicherweise eine erweiterte Option. Sie haben keine Berechtigung zum Ausführen der RECONFIGURE-Anweisung.

Diese drei Timer-Jobs laufen nicht immer und nicht auf allen SP-Servern gleichzeitig. Aber wenn sie laufen, dann haben sie den Status „Fehlgeschlagen“ und man findet im Windows-Ereignis (Event-Log) mit der ID 6398 folgenden Eintrag:

Ausnahme der Methode ‚Execute‘ der Auftragsdefinition ‚Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider‘ (ID <ID>). Weitere Informationen finden Sie unten.
Aktualisierungskonflikt. Sie müssen diese Aktion wiederholen. Das SPWebService-Objekt wurde von <Farm/TimerService-Account> im Prozess OWSTIMER (26568) auf dem Computer <SP-ServerX> aktualisiert. Weitere Informationen zu dem Konflikt finden Sie im Ablaufverfolgungsprotokoll.

Im Gegensatz zu den drei oben genannten Timer-Jobs laufen die drei folgende Timer-Jobs mit den DE-Namen „Erfolgreich“ durch:

• Diagnosedatenanbieter: E/A-intensive SQL-Abfragen
• Diagnosedatenanbieter: SQL-Deadlocks
• Diagnosedatenanbieter: Berichte zu SQL-Blockierunge

Möglicherweise ist der Fehler (und die drei fehlerhaften Timer-Jobs) nach der Installation von „SharePoint Diagnostic Studio“ (SPDIAG) bzw. von „Microsoft SharePoint 2010 Administration Toolkit“ aufgetreten.

Ist-Zustand

SharePoint Umgebung

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

ULS Log

In den ULS Logs findet man folgende Einträge:

Product: SharePoint Foundation

Product: SharePoint Foundation

Product: SharePoint Foundation

Product: SharePoint Foundation

Product: SharePoint Foundation

Product: SharePoint Foundation

Product: Extended Diagnostic Providers

Product: SharePoint Foundation

Product: SharePoint Foundation

Ereignisprotokoll

In der Windows Ereignisanzeige (Event Viewer) sind folgende Event Log Einträge mit der Event-ID: 6398 vorhanden:

Event-ID: 6398

Event-ID: 6398

Event-ID: 6398

Event-ID: 6398

Fix

Das Problem ist wahrscheinlich aufgetreten, nachdem die Installation von „SharePoint Diagnostic Studio“ (SPDIAG) bzw. von „Microsoft SharePoint 2010 Administration Toolkit“ durchgeführt wurde.

Vielleicht sind auch SharePoint-Datenbanken vorhanden, die sich nicht auf der SQL-Instanz der Farm befinden. (In unserem Fall liegen die SSRS-DBs auf der „SQL-Instanz-Name“ Instanz, die in einem der Windows-Events zu sehen ist.

Die Möglichen Lösungen sind nun entweder die Vergabe der nötigen Berechtigungen oder die Deaktivierung der drei Timer-Jobs.

Möglichkeit Nr. 1 – Deaktivierung der DiagnosticsProvider

Falls die drei DiagnosticsProvider ehe nicht benutzt werden sollen, dann kann man diese auch wie folgt deaktivieren.

Mit folgendem Befehl kann man die DiagnosticsProvider auflisten lassen:

Get-SpDiagnosticsProvider | Sort Name | ft Name, Title, Enabled, Status -Auto


<# Beispielausgabe:

Name                                             Title                                                          Enabled Status
----                                             -----                                                          ------- ------
job-diagnostics-blocking-query-provider          Diagnosedatenanbieter: SQL-Sperrabfragen                          True Online
job-diagnostics-changed-objects-provider         Diagnostic Data Provider: Changed Content Objects                 True Online
job-diagnostics-change-types-provider            Diagnostic Data Provider: Content Change Types                    True Online
job-diagnostics-database-io-provider             Diagnosedatenanbieter: E/A pro Datenbank                          True Online
job-diagnostics-event-log-provider               Diagnosedatenanbieter: Ereignisprotokoll                          True Online
job-diagnostics-io-intensive-query-provider      Diagnostic Data Provider: IO Intensive SQL Queries                True Online
job-diagnostics-io-intensive-query-provider      Diagnosedatenanbieter: E/A-intensive SQL-Abfragen                 True Online
job-diagnostics-performance-counter-sql-provider Diagnosedatenanbieter: Leistungsindikatoren - Datenbankserver.    True Online
job-diagnostics-performance-counter-wfe-provider Diagnosedatenanbieter: Leistungsindikatoren - Web-Front-Ends.     True Online
job-diagnostics-performance-metric-provider      Anbieter Leistungsmetrik                                          True Online
job-diagnostics-site-size-provider               Diagnosedatenanbieter: Websitegröße                               True Online
job-diagnostics-sprequestusage-provider          Diagnostic Data Provider: Usage Statistics                        True Online
job-diagnostics-sql-blocking-report-provider     Diagnostic Data Provider: SQL Blocking Reports                    True Online
job-diagnostics-sql-blocking-report-provider     Diagnosedatenanbieter: SQL-Deadlocks                              True Online
job-diagnostics-sql-deadlock-provider            Diagnostic Data Provider: SQL Deadlocks                           True Online
job-diagnostics-sql-deadlock-provider            Diagnosedatenanbieter: SQL-Deadlocks                              True Online
job-diagnostics-sql-dmv-provider                 Diagnosedatenanbieter: SQL-DMV                                    True Online
job-diagnostics-sql-memory-provider              Diagnosedatenanbieter: DMV-Daten des SQL-Speichers.               True Online
job-diagnostics-sql-performance-metric-provider  Anbieter für Datenbankleistungsmetrik                             True Online
job-diagnostics-uls-provider                     Diagnosedatenanbieter: Ablaufverfolgungsprotokoll                 True Online
Search Health Monitoring - Trace Events          Suchintegritätsüberwachung - Ablaufverfolgung der Ereignisse      True Online

#>

Mit diesem PowerShell-Skript kann man die gewünschten DiagnosticsProvider (Title-abhängig) deaktivieren:

# SnapIn laden
Add-PSSnapin Microsoft.SharePoint.PowerShell

$providers = Get-SPDiagnosticsProvider
foreach($provider in $providers)
{
   if (($provider.Title -eq "Diagnostic Data Provider: IO Intensive SQL Queries") -or ($provider.Title -eq "Diagnostic Data Provider: SQL Deadlocks") -or ($provider.Title -eq "Diagnostic Data Provider: SQL Blocking Reports"))
    {
        Write-Host "$($provider.Title)" -NoNewline -Fore Cyan ; Write-Host " wird deaktiviert"
        $provider.IsDisabled = $true;
        $provider.Update();
    }
}

Nun sieht die Ausgabe der DiagnosticsProvider wie folgt aus (drei sind deaktiviert).

Get-SpDiagnosticsProvider | Sort Name | ft Name, Title, Enabled, Status -Auto


<# Beispielausgabe:

Name                                             Title                                                          Enabled Status
----                                             -----                                                          ------- ------
job-diagnostics-blocking-query-provider          Diagnosedatenanbieter: SQL-Sperrabfragen                          True Online
job-diagnostics-changed-objects-provider         Diagnostic Data Provider: Changed Content Objects                 True Online
job-diagnostics-change-types-provider            Diagnostic Data Provider: Content Change Types                    True Online
job-diagnostics-database-io-provider             Diagnosedatenanbieter: E/A pro Datenbank                          True Online
job-diagnostics-event-log-provider               Diagnosedatenanbieter: Ereignisprotokoll                          True Online
job-diagnostics-io-intensive-query-provider      Diagnostic Data Provider: IO Intensive SQL Queries               False Online
job-diagnostics-io-intensive-query-provider      Diagnosedatenanbieter: E/A-intensive SQL-Abfragen                 True Online
job-diagnostics-performance-counter-sql-provider Diagnosedatenanbieter: Leistungsindikatoren - Datenbankserver.    True Online
job-diagnostics-performance-counter-wfe-provider Diagnosedatenanbieter: Leistungsindikatoren - Web-Front-Ends.     True Online
job-diagnostics-performance-metric-provider      Anbieter Leistungsmetrik                                          True Online
job-diagnostics-site-size-provider               Diagnosedatenanbieter: Websitegröße                               True Online
job-diagnostics-sprequestusage-provider          Diagnostic Data Provider: Usage Statistics                        True Online
job-diagnostics-sql-blocking-report-provider     Diagnostic Data Provider: SQL Blocking Reports                   False Online
job-diagnostics-sql-blocking-report-provider     Diagnosedatenanbieter: SQL-Deadlocks                              True Online
job-diagnostics-sql-deadlock-provider            Diagnostic Data Provider: SQL Deadlocks                          False Online
job-diagnostics-sql-deadlock-provider            Diagnosedatenanbieter: SQL-Deadlocks                              True Online
job-diagnostics-sql-dmv-provider                 Diagnosedatenanbieter: SQL-DMV                                    True Online
job-diagnostics-sql-memory-provider              Diagnosedatenanbieter: DMV-Daten des SQL-Speichers.               True Online
job-diagnostics-sql-performance-metric-provider  Anbieter für Datenbankleistungsmetrik                             True Online
job-diagnostics-uls-provider                     Diagnosedatenanbieter: Ablaufverfolgungsprotokoll                 True Online
Search Health Monitoring - Trace Events          Suchintegritätsüberwachung - Ablaufverfolgung der Ereignisse      True Online

#>

Nach diesen Schritten sollten die Timer-Jobs mit dem Status „Fehlgeschlagen“ und die „Critical“ ULS-Log-Einträge verschwunden sein.

Auch wenn es weiterhin die ULS-Log-Einträge (Level „High“) mit der Message

Unable to write service call usage entry

gibt, so werden trotzdem die Beliebtheitstrends generiert.

Möglichkeit Nr. 2 – SQL-Rolle „sysadmin“ oder „serveradmin“ für das Farm/Timer-Konto

Für das Funktionieren der Software „SharePoint Diagnostic Studio“ (SPDIAG) bzw. „Microsoft SharePoint 2010 Administration Toolkit“ muss dem Farmaccount bzw. dem Benutzer unter welchem der Windows-Dienst „SPTimerV4“ (mit dem Anzeigenamen „SharePoint Timer Service“ läuft) die SQL-Server-Rolle „sysadmin“ oder „serveradmin“ zugewiesen werden (s. Möglichkeit Nr. 3 weiter unten) da die Berechtigungen „SP_TRACE_CREATE“ und „RECONFIGURE“ nicht für die DB-Rolle „db_owner“ verfügbar sind.

Some SPDiag 3.0 diagnostics jobs require that the farm account has the sysadmin or sqladmin role assigned on the SQL Server instance where the SharePoint 2010 Products databases are located [3].

Falls also die drei Diagnostics Provider:

• job-diagnostics-io-intensive-query-provider
• job-diagnostics-sql-blocking-report-provider
• job-diagnostics-sql-deadlock-provider

nicht (wie oben in der Möglichkeit 1 beschrieben) deaktiviert werden können, weil diese gebraucht werden, dann müssen folgende Schritte durchgeführt werden, um den Farm-Dienstbenutzer zu berechtigen.

Farm-Account herausfinden

Falls Sie nicht wissen, welches Konto als Farm-Account benutzt wird, dann kann man das folgendermaßen herausfinden:

Auf einem der SharePoint-Server die Windows-Dienste (Services) öffnen und den Dienst „SharePoint Timer Service“ (Dienstname: „SPTimerV4“) finden. In den Eigenschaften, Reiter „Anmelden“ unter „Anmelden als“ ist das Farmkonto eingetragen. Hier als Beispiel: <Farm/TimerService-Account>

Dieses Konto wurde auch in den Windows-Events (s.o.) mehrfach erwähnt.

Farm-Account berechtigen

Der Farm-Account muss nun auf jeder SQL-Server-Instanz berechtigt werden, auf der sich die SharePoint-Datenbanken befinden.

Es kann sein, dass einige der Sharepoint- bzw. der Diensanwendungsdatenbanken (z.B. SSRS im integrierten Modus o.Ä.) sich auf anderen SQL-Instanzen befinden. Auf diesen SQL-Server-Instanzen muss das Farm-Konto auch die entsprechende SQL-Server-Rolle (s.u.) bekommen.

Es kann sein, dass die Instanz, auf der die Berechtigungen fehlen, in einem der Windows-Event (ID: 6398) erwähnt wird:

The blocking query diagnostics provider could not set the ‚blocked process threshold‘ for the sql instance <SQL-Instanz-Name>.

1. SSMS öffnen.
2. Alle SQL-Instanzen öffnen, die SharePoint-DBs enthalten.
3. Jede dieser Instanzen bis Sicherheit > Anmeldungen aufklappen.
4. Das Farmkonto finden und Eigenschaften öffnen.
5. Auf der linken Seite „Serverrollen“ wählen.
6. „serveradmin“ oder „sysadmin“ aktivieren.
7. Schritte 4-6 für alle SQL-Server-Instanzen wiederholen, die SP-DBs enthalten.

Auch wenn es weiterhin die ULS-Log-Einträge (Level „High“) mit der Message

Unable to write service call usage entry

gibt, so werden trotzdem die Beliebtheitstrends generiert.

Möglichkeit Nr. 3 – SQL Serverberechtigungen „Alter Trace“ und „Alter Settings“ für das Farm/Timer-Konto

1. SSMS öffnen.
2. Alle SQL-Instanzen öffnen, die SharePoint-DBs enthalten.
3. Eigenschaften der SQL-Instanz bzw. des SQL-Servers öffnen (rechte Maustaste auf die Instanz > Eigenschaften)
4. Seite auswählen „Berechtigungen“ > Anmeldenamen oder Rollen: Das Farmkonto finden und auswählen.
5. Im unteren Bereich im Reiter „Explizit“ folgende Berechtigungen aktivieren („Erteilen„)
   1. Alter Trace (Ablaufverfolgung ändern)
   2. Alter Settings (Einstellungen ändern)
6. Schritte 4-5 für alle SQL-Server-Instanzen wiederholen, die SP-DBs enthalten.

(Eventuell sind auch nur die Berechtigungen „Server steuern“ und „Serverstatus anzeigen“ ausreichend.)

Möglichkeit Nr. 4 – SPDIAG deinstallieren

Die Deinstallation von „SharePoint Diagnostic Studio“ (SPDIAG) bzw. von „Microsoft SharePoint 2010 Administration Toolkit“ wurde bei uns nicht ausprobiert, könnte aber möglicherweise auch die Lösung des Problems sein.

Links

1. blogs.msdn.microsoft.com: SharePoint Error 6398 – You do not have permission to run ‘SP_TRACE_CREATE’
2. sharepointsoldiers.wordpress.com: EventID 6398 – You do not have permission to run ‘SP_TRACE_CREATE’
3. technet.microsoft.com: Installing and configuring SPDiag 3.0
4. social.technet.microsoft.com: Usage and health data collection service SQL Permissions
5. msdn.microsoft.com: Anzeigen oder Ändern von Servereigenschaften (SQL Server)

Der Beitrag ID: 6398 – Microsoft.SharePoint.Diagnostics – SP_TRACE_CREATE – SYS.TRACES erschien zuerst auf Die SharePoint-Wiese.

Problem

soap:ServerDieAnforderung konnte vom Server nicht verarbeitet werden

Meldung von Website

soap:ServerDieAnforderung konnte vom Server nicht verarbeitet werden. —> Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

soap:ServerServer was unable to process request

Message from webpage

soap:ServerServer was unable to process reques. —> Object reference not set to an instance of an object.

Failed to handle workflow upload starting event

Englisch ULS:
Failed to handle workflow upload starting event. Error: Object reference not set to an instance of an object.. Stack trace: at Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId) at Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.ProcessStartForm(WorkflowUploadStartingEventReceiverContext eventArgs, Boolean& expectedException) . . .

Deutsch ULS:
Failed to handle workflow upload starting event. Error: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.. Stack trace: bei Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId) bei Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting.ProcessStartForm(WorkflowUploadStartingEventReceiverContext eventArgs, Boolean& expectedException) . . .

Failed to raise event to receiver or the receiver threw an exception

Englisch ULS:
Failed to raise event to receiver or the receiver threw an exception. Type: WorkflowUploadStarting. Receiver assembly: Nintex.Forms.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c52d764dcf7ec883. Receiver class: Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting: System.NullReferenceException: Object reference not set to an instance of an object. at Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId)  . . .

Deutsch ULS:
Failed to raise event to receiver or the receiver threw an exception. Type: WorkflowUploadStarting. Receiver assembly: Nintex.Forms.SharePoint, Version=1.0.0.0, Culture=neutral, PublicKeyToken=c52d764dcf7ec883. Receiver class: Nintex.Forms.SharePoint.EventHandlers.OnWorkflowUploadStarting: System.NullReferenceException: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId) . . .

Error saving from workflow export file

Englisch ULS:
Error saving from workflow export file.: System.Exception: Object reference not set to an instance of an object. at Nintex.Workflow.Publishing.Publish.AR8=(XomlWorkflow Ah8=, SPList Ax8=, WorkflowRepository BB8=, Boolean BR8=, String& Bh8=) at Nintex.Workflow.Publishing.Publish.xB4=(XomlWorkflow 1B4=, Boolean 1R4=, Boolean 1h4=, PublishOperationTrackingCollection 1×4=, Boolean 2B4=, WorkflowRepository 2R4=, Boolean 2h4=, Boolean 2×4=) at Nintex.Workflow.Publishing.Publish.PublishAWorkflow(String wfName . . .

Deutsch ULS:
Error saving from workflow export file.: System.Exception: Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. bei Nintex.Workflow.Publishing.Publish.ViE=(XomlWorkflow VyE=, SPList WCE=, WorkflowRepository WSE=, Boolean WiE=, String& WyE=) bei Nintex.Workflow.Publishing.Publish.HSE=(XomlWorkflow LSE=, Boolean LiE=, Boolean LyE=, PublishOperationTrackingCollection MCE=, Boolean MSE=, WorkflowRepository MiE=, Boolean MyE=, Boolean NCE=) bei Nintex.Workflow.Publishing.Publish.PublishAWorkflowOnPremises(String wfName . . .

Details

Beschreibung

Beim Veröffentlichen eines Nintex Workflows wird oft (nicht immer) folgende Fehlermeldung angezeigt.

Meldung von Website

soap:ServerDieAnforderung konnte vom Server nicht verarbeitet werden. —> Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

Message from webpage

soap:ServerServer was unable to process reques. —> Object reference not set to an instance of an object.

Auch werden ULS-Log Einträge geschrieben (siehe unten)

Ist-Zustand

SharePoint Umgebung

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

ULS Log

In den ULS Logs findet man folgende Einträge:

Product: Nintex Forms

Product: Nintex Workflow 2013

Product: Nintex Workflow 2013

Product: Nintex Forms

Product: Nintex Workflow 2013

Product: Nintex Workflow 2013

Fix

Die Fehlermeldungen könnten folgende Ursachen haben:

• Die Nintex Forms Datenbank existiert nicht.
• Die Nintex Forms Datenbank ist nicht eingebunden.
• Die Datenbank muss aktualisiert werden

Die Zeile
Nintex.Forms.SharePoint.MobileAppForms.NfMobileFormsRepository.MarkFormAsDeletedIfExists(Guid workflowId)
zeigt, dass es versucht wird auf ein „Stored Procedure“ in der Nintentx Forms Datenbank zuzugreifen.

Nintex Forms Datenbank erstellen

Falls die Nintex Forms DB noch nicht erstellt ist, so kann man diese DB in der CA erstellen.

CA >  Nintex Forms Management > Manage Database

Nintex Forms Datenbank upgrade

Falls Nintex Forms DB existiert und ist verbunden, dann muss diese DB wahrscheinlich aktualisiert werden.

Dazu folgendes Kommando in der SharePoint 2013 Management Shell eingeben:

Upgrade-NFservice

Danach sollte der Fehler nicht mehr auftauchen.

Links

1. community.nintex.com: When publishing a workflow you receive the error „soap:ServerServer was unable to process request.“
2. sharepoint-wiese.de: Nintex Workflow 2013 und Nintex Forms 2013 Installation

Der Beitrag Nintex – soap:ServerServer was unable to process request – Object reference not set to an instance of an object erschien zuerst auf Die SharePoint-Wiese.

Problem

Yielding upgrade session on current thread

In der Datei „Upgrade-<Datum>-<Zeit>.log im Ordner „C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS“ werden folgende Log-Einträge generiert:

PSCONFIG (0x2F18)    0x1958    SharePoint Foundation Upgrade    SPManager    aj0ul    INFO    psconfig: Yielding psconfig session on current thread to allow the admin service to run upgrade in the background.    00000000-0000-0000-0000-000000000000

PSCONFIG (0x2F18)    0x1958    SharePoint Foundation Upgrade    SPUpgradeSession    ajxli    INFO    Yielding upgrade session on current thread,    00000000-0000-0000-0000-000000000000

SyncUpgradeTimerJob: sleeping for 10 seconds

In der Datei „PSCDiagnostics_x_xx_xxxx_x_x_xx_xxx_xxxxxxxxxx.log im Ordner „C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS“ werden folgende Log-Einträge generiert:

INF              Starting Service SPTimerServiceInstance
INF              Detected that this is a build to build upgrade. Re-provision the SPTimerServiceInstance service
INF            Leaving function UpgradeTask.StartAllServices
INF            SyncUpgradeTimerJob: sleeping for 10 seconds
INF            SyncUpgradeTimerJob: sleeping for 10 seconds
. . .

Das Update für SharePoint-Produkte wird ausgeführt…

Die Meldung bleibt in der Konsole stehen, bis man die SharePoint Update Aktion abbricht.

Upgrading SharePoint Products and Technologies…

Die Meldung bleibt in der Konsole stehen, bis man die SharePoint Update Aktion abbricht.

Details

Beschreibung

Während des SharePoint Update-Prozesses mit Hilfe von Konfigurations-Assistenten für SharePoint 2013-Produkte oder dem Kommandozeilentools  PsConfig bleibt der Update-Prozess mit folgenden oder ähnlichen Meldungen stehen:

Konfigurationsaufgabe 6 von 7 wird ausgeführt
Das Update für SharePoint-Produkte wird ausgeführt…

oder auf englischen Systemen:

Performing configuration task 6 of 7
Upgrading SharePoint Products and Technologies…

Der SharePoint-Update-Prozess geht auch nach Stunden und Tagen nicht weiter.

Upgrade.log

In der Log-Datei unter

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS\Upgrade-<Datum>-<Zeit>.log

Sind unter anderem folgende Log-Einträge am Ende der Datei zu finden:

PSCDiagnostics.log

In der Log-Datei unter

C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\LOGS\PSCDiagnostics_x_xx_xxxx_x_x_xx_xxx_xxxxxxxxxx.log

gibt es unter anderem folgende Log-Einträge am Ende der Datei:

Ist-Zustand

SharePoint Umgebung

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

Fix

PsConfig Tool mit richtigen Optionen benutzen

Falls das Update mit dem Tool PsConfig gerade durchgeführt wird, dann mit Strg+c den Prozess abbrechen.

Dann die SharePoint 2013 Management Shell als Administrator öffnen.

Und die Updates immer mit folgendem Kommando durchführen:

PSConfig -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
# PSConfig -cmd upgrade -inplace b2b -wait -force -cmd applicationcontent -install -cmd installfeatures -cmd secureresources
# -WAIT = No timer job so the upgrade happens in real time in the psconfig process.
# -FORCE = Removes all existing upgrade jobs incase a timer job is stuck.

Das stoppen der Dienste vorher z.B. mit dem Kommando Stop-Service SPTimerV4, OSearch15, SPSearchHostController, SPAdminV4, SPWriterV4, SPTraceV4, IISADMIN bringt keine Vorteile.

Der Beitrag SharePoint-Update – Yielding upgrade session on current thread erschien zuerst auf Die SharePoint-Wiese.

IIS Log Dateien löschen, die älter sind als X Tage

Es kann passieren, dass der Ordner in dem der Web-Server die Log-Dateien speichert (C:\inetpub\logs\LogFiles) mit der Zeit recht groß wird.

Im Internetinformationsdienste (IIS)-Manager selbst kann man nur auswählen, wie oft eine neue Log-Datei erstellt oder wie groß die Log-Datei werden soll. Auch kann eingestellt werden, dass keine neuen Protokolldateien erstellt werden sollen. Allerdings kann nicht eingestellt werden, dass die neusten Dateien behalten und die alten Log-Dateien gelöscht werden.

Wie die IIS Log Dateien, die älter als X Tage sind, trotzdem regelmäßig gelöscht werden können, zeige ich in diesem kurzen Artikel weiter unten.

Möglichkeit #1 – IIS Log Dateien mit CMD Befehl in der Aufgabenplanung bereinigen

Um die IIS Log Dateien, die sich standardmäßig im Ordner C:\inetpub\logs\LogFiles befinden und älter als X Tage sind zu bereinigen, kann man am einfachsten folgende XML-Datei in die Windows-Aufgabenplanung importieren und als Job regelmäßig laufen lassen.

XML-Datei für den Import erstellen

Folgenden Text mit dem Windows-Editor in eine Text-Datei (z.B. namens „IIS Log Cleanup.xml“) auf dem Desktop speichern.

In der Zeile 46 kann schon an dieser Stelle die Zahl 7 und somit die Aufbewahrungsdauer der Log-Files in Tagen angepasst werden (das geht auch später).

<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.2" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
  <RegistrationInfo>
    <Date>2014-05-09T14:36:04.4840502</Date>
    <Author>Admin</Author>
    <Description>Löscht IIS-Log-Dateien die älter sind als X Tage</Description>
  </RegistrationInfo>
  <Triggers>
    <CalendarTrigger>
      <StartBoundary>2014-05-09T22:00:00</StartBoundary>
      <ExecutionTimeLimit>P1D</ExecutionTimeLimit>
      <Enabled>true</Enabled>
      <ScheduleByDay>
        <DaysInterval>1</DaysInterval>
      </ScheduleByDay>
    </CalendarTrigger>
  </Triggers>
  <Principals>
    <Principal id="Author">
      <UserId>S-1-5-18</UserId>
      <RunLevel>LeastPrivilege</RunLevel>
    </Principal>
  </Principals>
  <Settings>
    <MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
    <DisallowStartIfOnBatteries>true</DisallowStartIfOnBatteries>
    <StopIfGoingOnBatteries>true</StopIfGoingOnBatteries>
    <AllowHardTerminate>true</AllowHardTerminate>
    <StartWhenAvailable>false</StartWhenAvailable>
    <RunOnlyIfNetworkAvailable>false</RunOnlyIfNetworkAvailable>
    <IdleSettings>
      <StopOnIdleEnd>true</StopOnIdleEnd>
      <RestartOnIdle>false</RestartOnIdle>
    </IdleSettings>
    <AllowStartOnDemand>true</AllowStartOnDemand>
    <Enabled>true</Enabled>
    <Hidden>false</Hidden>
    <RunOnlyIfIdle>false</RunOnlyIfIdle>
    <WakeToRun>false</WakeToRun>
    <ExecutionTimeLimit>P1D</ExecutionTimeLimit>
    <Priority>7</Priority>
  </Settings>
  <Actions Context="Author">
    <Exec>
      <Command>forfiles.exe</Command>
      <Arguments>/P C:\inetpub\logs\LogFiles /S /M *.log /D -7 /C "cmd /c del @file"</Arguments>
    </Exec>
  </Actions>
</Task>

Die erstellte XML-Datei kann nun als Windows-Aufgabe importiert werden.

Windows Aufgabe für die Log Bereinigung erstellen

Windows Aufgabenplanung starten

Im rechten Bereich unter „Aktionen“ den Punkt Aufgabe importieren… anklicken.

Die von uns erstellte XML-Datei öffnen.

Einstellungen des Jobs kontrollieren und anpassen

Nun können die Einstellungen kontrolliert und angepasst werden. Z.B. kann das ausführende Konto im Reiter „Allgemein“ verändert werden.

Oder im Reiter „Trigger“ kann die Häufigkeit der Bereinigung eingestellt werden (die importierte Aufgabe ist auf täglich 22 Uhr eingestellt).

Wie alt die Log-Dateien werden dürfen, bevor sie gelöscht werden, kann im Reiter „Aktionen“ eingestellt werden (hier werden sie 7 Tage aufbewahrt).

Dazu die Zeile „Programm starten“ doppelklicken und im Feld „Argumente hinzufügen“ die Zahl 7 zwischen /D -7 /C anpassen.

Wenn alle Einstellungen in Ordnung sind, mit OK  bestätigen, damit die Aufgabe erstellt wird.

Hier ist die eigentliche Magie

Falls man den Job nicht aus dieser XML-Datei importieren möchte, so kann man die Aufgabe manuell erstellen und folgende Zeile als Aktion verwenden (die 7 [Tage] Aufbewahrungsfrist vorher anpassen):

forfiles.exe /P C:\inetpub\logs\LogFiles /S /M *.log /D -7 /C "cmd /c del @file"

Möglichkeit #2 – IIS Log Dateien mit PowerShell-Skript und Aufgabenplanung bereinigen

Alternativ könnte man die alten IIS-Log Dateien mit einem PowerShell Skript und dem Task Scheduler löschen.

Dazu ein PowerShell-Skript mit folgendem Inhalt erstellen

# PowerShell Skript löscht die IIS Log-Dateien die älter sind als 7 Tage

get-childitem -Path C:\inetpub\logs\LogFiles -recurse |
where-object {$_.lastwritetime -lt (get-date).addDays(-7)} |
Foreach-Object { del $_.FullName }

und im Windows Task Scheduler z.B. täglich laufen lassen.

Wenn das PowerShell-Skript IIS_Log_loeschen.ps1 heißen und im Ordner C:\Scripts\ liegen würde, dann wäre die Zeile zum Aufruf in der Aufgabenplanung folgende:

powershell.exe -noprofile -NonInteractive -executionpolicy ByPass -File "C:\Scripts\IIS_Log_loeschen.ps1"

Alternativen

Log-Dateien auf eine zweite Festplatte verlagern oder Log-Erstellung deaktivieren

Falls eine zweite Festplatte zur Verfügung steht, so könnte man im Internetinformationsdienste (IIS)-Manager unter Sites/<Site>/Protokollierung den Standardpfad zu den IIS-Logdateien (%SystemDrive%\inetpub\logs\LogFiles) auf die dedizierte Festplatte einstellen oder ganz deaktivieren.

ISS Log-Ordner „C:\inetpub\logs\LogFiles“ komprimieren

Falls die Web-Server Log-Dateien im Standardpfad (%SystemDrive%\inetpub\logs\LogFiles) liegen, dann könnte man folgendermaßen die Komprimierung dieses Ordners aktivieren.

IIS-Manager öffnen.

Den Server auf der linken Seite markieren und entweder im Kontextmenü (rechte Maustaste) oder auf der rechten Seite „Beenden“ (ansonsten wird später evtl. ein „Fehler beim Übernehmen der Attribute“ angezeigt, da die Log-Files noch im Zugriff sind).

Im Windows-Explorer den Pfad C:\inetpub\logs öffnen.

Eigenschaften des darin liegenden Ordners „LogFiles“ öffnen (rechte Maustaste).

In den Eigenschaften des Ordners „LogFiles“ auf den Button „Erweitert“ klicken.

Im Fenster „Erweiterte Attribute“ die Option „Inhalt komprimieren, um Speicherplatz zu sparen“ aktivieren und mit OK bestätigen.

Im Fenster „Änderungen der Attribute bestätigen“ die Option „Änderungen für diesen Ordner, untergeordnete Ordner und Dateien übernehmen“ aktivieren (bzw. aktiviert lassen) und mit OK bestätigen.

Wenn der Komprimierungsvorgang beendet ist, wird der Name des Ordners LogFiles in blauer Schrift dargestellt.

Den Web-Server im IIS-Manager wieder starten.

Der Beitrag Alte IIS C:\inetpub\logs\LogFiles nach X Tagen bereinigen erschien zuerst auf Die SharePoint-Wiese.

Problem

Das Timeout für Sperranforderung wurde überschritten. (Microsoft SQL Server, Fehler: 1222)

TITEL: Microsoft SQL Server Management Studio
——————————

Ausnahme beim Ausführen einer Transact-SQL-Anweisung oder eines Transact-SQL-Batches. (Microsoft.SqlServer.ConnectionInfo)

——————————
ZUSÄTZLICHE INFORMATIONEN:

Das Timeout für Sperranforderung wurde überschritten.
Das Timeout für Sperranforderung wurde überschritten. (Microsoft SQL Server, Fehler: 1222)

Hilfe erhalten Sie durch Klicken auf: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=10.50.6220&EvtSrc=MSSQLServer&EvtID=1222&LinkId=20476

Lock request time out period exceeded. (Microsoft SQL Server, Error: 1222)

Wird im SSMS angezeigt.

Der Aktivitätsmonitor kann keine Abfragen für den Server SP-DB-Server ausführen

Der Aktivitätsmonitor kann keine Abfragen für den Server SP-DB-Server ausführen.
Der Aktivitätsmonitor wird für diese Instanz angehalten.
Verwenden Sie das Kontextmenü im Übersichtsbereich, um den Aktivitätsmonitor wieder zu starten.

Zusätzliche Informationen:
Timeout abgelaufen. Das Zeitlimit wurde vor dem Beenden des Vorgangs überschritten oder der Server reagiert nicht. (Microsoft SQL Server)
Der Wartevorgang wurde abgebrochen

Details

Beschreibung

Das Timeout für Sperranforderung wurde überschritten. (Microsoft SQL Server, Fehler: 1222)

Beim starten von Microsoft SQL Server Management Studio (SSMS) werden evtl. folgende Fehlermeldungen angezeigt.

TITEL: Microsoft SQL Server Management Studio
——————————

Ausnahme beim Ausführen einer Transact-SQL-Anweisung oder eines Transact-SQL-Batches. (Microsoft.SqlServer.ConnectionInfo)

——————————
ZUSÄTZLICHE INFORMATIONEN:

Das Timeout für Sperranforderung wurde überschritten.
Das Timeout für Sperranforderung wurde überschritten. (Microsoft SQL Server, Fehler: 1222)

Hilfe erhalten Sie durch Klicken auf: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&ProdVer=10.50.6220&EvtSrc=MSSQLServer&EvtID=1222&LinkId=20476

Auf englischen Systemen wird diese Meldung angezeigt:

Lock request time out period exceeded. (Microsoft SQL Server, Error: 1222)

Der Aktivitätsmonitor kann keine Abfragen für den Server SP-DB-Server ausführen

Im SQL-Management-Studio wird folgende Fehlermeldung angezeigt, wenn man versucht den Aktivitätsmonitor zu öffnen:

Der Aktivitätsmonitor kann keine Abfragen für den Server SP-DB-Server ausführen.
Der Aktivitätsmonitor wird für diese Instanz angehalten.
Verwenden Sie das Kontextmenü im Übersichtsbereich, um den Aktivitätsmonitor wieder zu starten.

Zusätzliche Informationen:
Timeout abgelaufen. Das Zeitlimit wurde vor dem Beenden des Vorgangs überschritten oder der Server reagiert nicht. (Microsoft SQL Server)
Der Wartevorgang wurde abgebrochen

Ist-Zustand

Viele SQL-Systemabfragen wie sp_who2 laufen ewig und bringen so keine Ergebnisse oder brechen die Abfrage mit dem o.g. Fehler. 1222 ab.

Im SSMS im Objekt-Explorer sind Elemente wie Agent und Logs nicht vorhanden.

Der Aktivitätsmonitor zeigt die Meldung „Der Aktivitätsmonitor kann keine Abfragen für den Server SP-DB-Server ausführen.“ dafür aber keine Prozesse an.

Es ist nicht möglich im SSMS Berichte anzeigen zu lassen. Es wird folgende Meldung angezeigt: „Die DocumentSite eines WindowFrame kann nur einmal festgelegt werden. (mscorlib)“

SystemUmgebung

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

Workaround

Wahrscheinlich blockieren sich mehrere SQL-Prozesse bzw. Abfragen gegenseitig. In unserem Fall ist überschneidet sich die Zeit der blockierten Abfrage mit dem nächtlichen Schwenk des Failover-Clusters.

Auch wenn die SQL-Server-Protokolle in SSMS nicht zur Verfügung stehen, so kann man diese als Textdateien im folgenden Ordner finden:

Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\ERRORLOG und ERRORLOG.n

Die problematischen Abfragen herausfinden

DBCC opentran()

Mit der SQL-Abfrage

DBCC opentran()

kann die älteste aktive Transaktion herausgefunden werden. Das Ergebnis zeigt die SPID und die Startzeit des Prozesses.

sys.dm_exec_requests

Hiermit lassen sich die Anfragen anzeigen.

SELECT * FROM sys.dm_exec_requests;
GO

Die wichtigsten Spalten sind:

• session_id
• start_time
• status
• wait_type (z.B. LCK_M_SCH)

sys.dm_exec_connections

Mit dieser SQL-Abfrage können die Verbindungen (inkl. der problematischen Verbindungen und der Startzeit) angezeigt werden.

SELECT * FROM sys.dm_exec_connections;  
GO

Die wichtigsten Spalten sind:

• session_id
• connect_time
• client_net_adress (Quell-IP der Abfrage)
• local_net_adress (SQL-Instanz IP-Adresse)

sp_who2, sp_lock, sp_lock2

In diversen Anleitung findet man die SQL-Abfrage

sp_who2

bzw.

sp_who2 <SPID>

bzw.

sp_lock2 <SPID>

die in so einem Fall relevanten Daten zeigen soll. In unserem Fall lief die Abfrage zu lange.

Die wichtigsten Spalten sind:

• SPID
• Status
• Login
• HostName
• BlkBy (blockiert durch)
• ProgrammName

Workaround 1 – SQL-Server Instanz neu starten

Falls die SQL-Server-Instanz in einem Microsoft Failover-Cluster läuft, dann den Dienst im Failovercluster-Manager offline und dann online schalten.

Falls nicht, dann den SQL-Server-Dienst der entsprechenden Instanz im  SQL Server Configuration Manager  „Neu starten„.

Workaround 2 – kill <session_id>

Es ist auch möglich, die oben ermittelten problematischen Sessions zu „killen“.


Die weiter oben herausgefundene, problematische Sessions können mit folgender SQL-Abfrage abgebrochen werden:

kill <session_id>

bzw.

kill <spid>

Bsp.: In unserem Fall waren die Sessions mit den IDs 52 und 72 geblockt.
Diese wurden mit kill 52 und kill 72 „gekillt“

Links

1. msdn.microsoft.com: sys.dm_exec_requests (Transact-SQL)
2. www.simple-talk.com: The DBA as Detective: Troubleshooting Locking and Blocking
3. blog.sqlauthority.com: SQL SERVER – Quickest Way to Identify Blocking Query and Resolution – Dirty Solution
4. blog.wsol.com: SQL Server Locks, Blocked Processes, and Two Easy Ways to Find Them

Der Beitrag Lock request time out period exceeded. (Microsoft SQL Server, Error: 1222) erschien zuerst auf Die SharePoint-Wiese.

Problem

The User Profile Service failed the logon. User profile cannot be loaded.

Bei dem Versuch sich an dem Server anzumelden wird folgende Fehlermeldung angezeigt:

The User Profile Service failed the logon.
User profile cannot be loaded.

Fehler bei der Anmeldung des Diensts „Benutzerprofildienst“. Das Benutzerprofil kann nicht geladen werden.

Der Benutzer kann sich nicht anmelden. Folgende Fehlermeldung wird auf deutschen Systemen angezeigt:

Fehler bei der Anmeldung des Diensts „Benutzerprofildienst“.
Das Benutzerprofil kann nicht geladen werden.

Event-ID: 1500 – User Profile Service

In der Ereignisanzeige ist folgender Eintrag mit der Event-ID: 1500 zu finden:

Sie konnten nicht angemeldet werden, da das lokal gespeicherte Profil nicht geladen werden konnte. Überprüfen Sie, ob eine Netzwerkverbindung besteht und das Netzwerk ordnungsgemäß funktioniert.

 Details - Nur ein Teil der ReadProcessMemory- oder WriteProcessMemory-Anforderung wurde abgeschlossen.

Oder auf englischen Systemen:

Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly.

Details - Only part of a ReadProcessMemory or WriteProcessMemory request was completed.

Event-ID: 1509 – User Profile General

In der Ereignisanzeige ist folgender Eintrag mit der Event-ID: 1509 zu finden:

Die Datei \\?\C:\Users\Default\AppData\Roaming\TfsSQMLog\sqmtfs00.sqm konnte nicht nach \\?\C:\Users\TEMP.DOMAIN\AppData\Roaming\TfsSQMLog\sqmtfs00.sqm kopiert werden. Mögliche Fehlerursachen sind Netzwerkprobleme oder nicht ausreichende Sicherheitsrechte.

Details - Zugriff verweigert

Oder auf englisch:

Windows cannot copy file \\?\C:\Users\Default\AppData\Roaming\TfsSQMLog\sqmtfs00.sqm to location \\?\C:\Users\TEMP.DOMAIN\AppData\Roaming\TfsSQMLog\sqmtfs00.sqm. This error may be caused by network problems or insufficient security rights.

DETAIL - Access is denied.

Details

Beschreibung

Die Anmeldung am Computer bzw. Server funktioniert nur für die Benutzer, die sich schon einmal früher an dieser Maschine angemeldet hatten.

Die Anmeldung für neue Benutzer funktioniert nicht, da kein neuer Profil-Ordner für den aktuellen Benutzer aus dem Default-Ordner erstellt werden kann.

Es wird beim Versuch sich anzumelden folgende Fehlermeldung angezeigt:

The User Profile Service failed the logon.
User profile cannot be loaded.

Oder wenn das Betriebssystem auf deutsch installiert wurde:

Fehler bei der Anmeldung des Diensts „Benutzerprofildienst“.
Das Benutzerprofil kann nicht geladen werden.

Ereignisprotokoll

In der Windows Ereignisanzeige (Event Viewer) sind folgende Event Log Einträge mit den Event-IDs: 1500, 1509, 1511 und 6001 vorhanden:

Event-ID: 1500

Event-ID: 1509

Event-ID: 1511

Event-ID: 6001

Fix

Im Event-Viewer zeigt uns die Event-ID: 1509 die Ursache:

Die Datei C:\Users\Default\AppData\Roaming\<Folder>\<file>.sqm konnte nicht gelesen werden und deshalb kann der Benutzerprofilordner aus dem Standard-Profile nicht erstellt werden.

Die Berechtigungen des aktuellen Benutzers für die o.g. Datei sollten überprüft werden. Normalerweise sollten die Gruppe „Jeder“ und die Gruppe der lokalen „Benutzer“ die (von c:\Users\) vererbten Berechtigungen (Lesen, Ausführen) auf alle Unterordner und Dateien besitzen.

Hier war das nicht der Fall. Die Dateien, die unter den Ordner C:\Users\Default\AppData\Roaming\<Folder>\ lagen, hatten eigene Berechtigungen.

Benutzerberechtigungen anpassen

Eigenschaften des Ordners C:\Users\Default\AppData\Roaming öffnen.

Reiter „Sicherheit“ öffnen.

Unten rechts auf „Erweitert“ klicken.

Falls UAC aktiviert ist, dann auf den Button „Berechtigungen ändern“ klicken.

Unten links die Option „Alle Berechtigungseinträge für untergeordnete Objekte durch vererbbare Berechtigungseinträge von diesem Objekt ersetzen“ aktivieren und mit OK übernehmen.

Damit sollten nun die Berechtigungen Lesen und Ausführen für die Gruppen „Jeder“ und lokale „Benutzer“ auf alle Unterordner und Dateien gesetzt werden.

Alternative Lösung: Default-Profil löschen und neu erstellen

Als Alternative könnte man noch versuchen, den Ordner „C:\Users\Default“ zu löschen und von einer Maschine (mit demselben Betriebssystem) zu kopieren.

Links

1. blogs.msdn.microsoft.com: Issues with user logging in to TFS 2013 Server after installation and restart on Windows 2012 R2

Der Beitrag The User Profile Service failed the logon. User profile cannot be loaded – Windows cannot copy file .sqm erschien zuerst auf Die SharePoint-Wiese.

Problem

System Writers ’system writer‘ do not exist

Das TSM (Tivoli) Server-Backup scheitert. In der Logdatei dsmerror.log findet man folgenden Eintrag:

ANS1512E Scheduled event 'BACKUP_22' failed.  Return code = 12.
ANS1577I The Windows console event handler received a 'Ctrl-C' console event.
ANS1705E System Writers 'system writer'  do not exist.

Details

Beschreibung

Die automatischen sowie manuellen TSM Tivoli Backups eines Servers scheitern.

Deaktiviert man die Option „System-State“, dann läuft das Backup fehlerfrei durch.

dsmerror.log

Im TSM-Log unter „C:\Program Files\Tivoli\TSM\baclient\dsmerror.log“ findet man unter Anderem folgende Einträge:

ANS1512E Scheduled event 'BACKUP_22' failed.  Return code = 12.
ANS1577I The Windows console event handler received a 'Ctrl-C' console event.
ANS1705E System Writers 'system writer'  do not exist.

VSS „System Writer“ nicht vorhanden

In der als Administrator gestarteten Eingabeaufforderung werden alle VSS-Writers mit folgendem Befehl aufgelistet:

vssadmin list writers

Normalerweise muss in der Liste der „System Writer“ vorhanden sein!
Hier war das nicht der Fall.

Fix

Die Ursache für den Fehler ist vermutlich ein Sort-Algorithmus der auf maximal 1000 Verzeichnisse ausgelegt ist.

Wenn der VSS Writer durch ein Verzeichnis (z.B.  %windir%\WinSxS\FileMaps oder C:\Windows\Microsoft.Net )läuft und dort mehr als 1000 Unterverzeichnisse existieren, entsteht dieser Fehler.

Das ist oft auf den Computern/Servern der Falls, auf welchen z.B. das Microsoft Visual Studio oder SharePoint installiert sind.

Hotfix installieren

Die Installation des Hotfixes KB2807849 auf den betroffenen Maschinen sollte die Lösung bringen.

Nach der Installation sollte die Maschine neu gestartet werden.

Berechtigungen

Falls das installieren des Hotfixes nicht die Lösung war, dann hilft evtl. das Kontrollieren bzw. Korrigieren der Berechtigungen nach dieser Anleitung.

Besonders dann, wenn in der Ereignisanzeige (Event Viewer) folgende Event-IDs gefunden werden: ID: 513, ID: 8213, ID: 517.

Nach diesen Schritten sollte der Kommandozeilenbefehl

vssadmin list writers

unter Anderem auch wieder den „System Writer“ auflisten.

Links

1. support.microsoft.com: You cannot back up the system state on a computer that is running Windows Server 2008 R2 or Windows Server 2012
2. support.microsoft.com: System State backup using Windows Server Backup fails with error: System writer is not found in the backup
3. sharepoint-wiese.de: ID: 513 – Fehler beim Kryptografiedienst während der Verarbeitung des „OnIdentity()“-Aufrufobjekts „System Writer“

Der Beitrag TSM Tivoli – System Writers ’system writer‘ do not exist erschien zuerst auf Die SharePoint-Wiese.

CHKDSK Log

In manchen Fällen möchte man sich die Ergebnisse vom CHKDSK Lauf (Datenträger-Fehlerüberprüfung) anschauen.

Das wäre z.B. der Fall, wenn Windows einen Festplattenfehler feststeht und nach einem Neustart anfängt CHKDSK auszuführen. Das Problem dabei ist, dass die Festplatten-Überprüfung recht lange dauert und die Ergebnisse am Ende des CHKDSK-Checks kurz angezeigt werden und der Rechner danach sofort hochfährt. Sitzt man am Ende der Überprüfung nicht vor dem Bildschirm, so hat man scheinbar Pech gehabt. In dem Moment bleibt es erst einmal unklar, ob CHKDSK Fehler gefunden und repariert hat.

In dieser Anleitung zeige ich, wie man das CHKDSK Log auch nachträglich finden und anschauen kann.

Wie komme ich an den CHKDSK-Log ran

Es gibt wie immer verschiedene Wege die nach Rom oder in diesem Fall zum CHKDSK-Log führen.

Bei Fehlerprüfung über die Datenträgereigenschaften

Falls das CHKDSK-Tool bzw. die Fehlerüberprüfung des Datenträgers über die Windows-GUI bzw. über die Eigenschaften von Datenträger gestartet wurde, dann kann man nach der Überprüfung auf den Link „Details anzeigen“ klicken.

Es wird automatisch die Windows-Ereignisanzeige bzw. der Event-Viewer gestartet und der dazugehörige CHKDSK-Log geöffnet.

Der Protokollname ist „Anwendung“ und die Quelle ist dann „Chkdsk“ mit der ID: 26226.

Event Viewer

CHKDSK Log im Event-Viewer suchen

Falls die Überprüfung mit dem CHKDSK durchgeführt wurde, bevor Windows geladen wurde (z.B. die automatische Überprüfung beim Start des Computers), so findet man die Ergebnisse ebenfalls in den Event-Logs.

Event-Viewer starten.

Dazu Windows-Taste drücken, Event schreiben, und wenn Ereignisanzeige markiert ist, Enter drücken.

Alternativ: [Win]+[r], eventvwr.msc tippen und Enter drücken.
Die Ereignisanzeige startet.

Auf der linken Seite Windows-Protokolle > Anwendung (bzw. Application) markieren.

Auf der rechten Seite auf „Suchen…“ (bzw. Find…) klicken. In die Suchmaske „chkdsk“ eintragen und mit Enter bestätigen.

So lange „Weitersuchen“ bis der passende Eintrag (Quelle: Wininit oder Chkdsk) mit entsprechender Uhrzeit angezeigt wird.

Der CHKDSK-Log könnten dann wie folgt aussehen:

CHKDSK Log im Event-Viewer filtern

Auf der linken Seite Windows-Protokolle > Anwendung (bzw. Application) markieren.

Auf der rechten Seite auf „Aktuelles Protokoll filtern…“ (bzw. Filter Current Log…) klicken.

Bei Quellen (Event sources) Folgendes aus der Auswahlliste auswählen: Chkdsk, Wininit

Mit OK bestätigen.

Nun sollten alle CHKDSK Ereignisse gefiltert angezeigt werden.

Benutzerdefinierte Ansicht für CHKDSK Log erstellen

Um den Filter nicht jedes Mal manuell eintragen zu müssen, kann man für CHKDSK-Ereignisse auch eine Benutzerdefinierte Ansicht erstellen (bei Bedarf exportieren und auf den relevanten Servern oder Computern importieren).

Auf der linken Seite Windows-Protokolle > Anwendung (bzw. Application) markieren.

Auf der rechten Seite auf „Benutzerdefinierte Ansicht erstellen…“ (bzw. Create Custom View…) klicken.

Die Option „Per Quelle“ (By source) aktivieren.

Bei Quellen (Event sources) Folgendes aus der Auswahlliste auswählen: Chkdsk, Wininit

Mit OK bestätigen. Es wird nun nach Name dieser Benutzeransicht gefragt. Namen und Beschreibung eingeben und mit OK bestätigen.

Die erstellte Ansicht sollte nun mit dem angegebenen Namen auf der linken Seite in der Ereignisanzeige unter
Ereignisanzeige > Benutzerdefinierte Ansichten > Chkdsk Events
dauerhaft zu sehen sein. Diese Filtert die für uns relevanten Events (hier CHKDSK Logs).

Bei Bedarf kann man diese „Benutzerdefinierte Ansicht exportieren…“ und auf einem anderen Server/Computer importieren.

CHKDSK-Logs per PowerShell auslesen und in eine Datei schreiben

PowerShell starten.

• Methode 1: Windows-Taste drücken, PowerShell eintippen und mit der Maus oder Enter bestätigen.
• Methode 2: Tasten [Win]+[r] zusammen drücken, in das Dialogfeld „powershell“ eintippen, mit Enter bestätigen.

Folgende Zeilen ausführen oder als Skript abspeichern und dann ausführen.
Entscheidend sind die Zeilen 8 und 10.

cls
Write-Host "Es werden alle im Windows-Event-Log vorhandene CHKDSK-Logs ausgegeben."
Write-Host "Der Vorgang koennte etwas laenger dauern. Bitte warten bis das Beenden signalisiert wird"

# Fuer die Ausgabe in eine Text-Datei kann an die get-winevent Zeilen folgendes angehaengt werden: | out-file -Append $home\desktop\$(Get-Date -Format 'yyyy-MM-dd')_$(gc env:computername)_CHKDSK-Log.txt

Write-Host "In Windows gestartete CHKDSK Vorgaenge werden gesucht und unten angezeigt:" -fore Cyan
get-winevent -LogName "Application" | ?{$_.providername -match "chkdsk"} | fl timecreated, message
Write-Host "Beim Reboot gestartete CHKDSK Vorgaenge werden gesucht und unten angezeigt:" -fore Cyan
get-winevent -LogName "Application" | ?{$_.providername -match "wininit"} | fl timecreated, message

Write-Host "Vorgang beendet" -fore Green

Links

1. www.tenforums.com: How to Read Event Viewer Log for Chkdsk (Check Disk) in Windows 10
2. www.sevenforums.com: How to Read the Event Viewer Log for Check Disk (chkdsk) in Vista, Windows 7, and Windows 8

Der Beitrag CHKDSK Log – Ergebnisse der Fehlerüberprüfung finden erschien zuerst auf Die SharePoint-Wiese.

Problem

Excel Web Access – Die Arbeitsmappe konnte nicht geöffnet werden.

Die Arbeitsmappe konnte nicht geöffnet werden.
Die Arbeitsmappe kann nicht geöffnet werden.

Bzw. auf englisch:

The workbook cannot be opened

Event-ID: 3760 – SharePoint Foundation – Cannot open database ‚Content_DB‘ requested by the login. The login failed. Login failed for user ‚Domain\ExcelServiceUser‘

Diese Fehlermeldung wird im Event Viewer (Ereignislog) und im ULS-Log angezeigt:

SQL Database ‚Content_DB‘ on SQL Server instance ‚SQL_Instance‘ not found. Additional error information from SQL Server is included below.

Cannot open database ‚Content_DB‘ requested by the login. The login failed.
Login failed for user ‚Domain\ExcelServiceUser‘.

Event-ID: 3760 – SharePoint Foundation – Die von der Anmeldung angeforderte Content_DB-Datenbank kann nicht geöffnet werden. Fehler bei der Anmeldung.
Fehler bei der Anmeldung für den Benutzer ‚Domain\ExcelServiceUser‘

Diese Fehlermeldung wird im Event Viewer (Ereignislog) und im ULS-Log angezeigt:

Die SQL-Datenbank ‚Content_DB‘ für die SQL Server-Instanz ‚SQL_Instance‘ wurde nicht gefunden. Weitere Fehlerinformationen aus SQL Server finden Sie unten.

Die von der Anmeldung angeforderte Content_DB-Datenbank kann nicht geöffnet werden. Fehler bei der Anmeldung.
Fehler bei der Anmeldung für den Benutzer ‚Domain\ExcelServiceUser‘.

Details

Beschreibung

Die Excel-Dateien können im Browser nicht angezeigt werden.

Excel Web Access zeigt die Fehlermeldung:

Die Arbeitsmappe konnte nicht geöffnet werden.
Die Arbeitsmappe kann nicht geöffnet werden.

Oder auf englisch:

The workbook cannot be opened

Dieselbe Excel-Datei kann aber sehr wohl im Browser editiert werden (mit Hilfe der Office Web Apps)

In der Ereignisanzeige (Event Viewer) und in den ULS-Logs findet man einen Log-Eintrag mit der Event-ID: 3760, Quelle „SharePoint Foundation“ und Aufgabenkategorie „Datenbank“.

Ist-Zustand

SharePoint Umgebung

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

ULS Log

In den ULS Logs findet man folgenden Eintrag mit der Event-ID: 3760:

Product: SharePoint Foundation

Ereignisprotokoll

In der Windows Ereignisanzeige (Event Viewer) ist folgender Event Log Eintrag mit der Event-ID: 3760 vorhanden:

Event-ID: 3760

Fix

Möglichkeit 1 – Den Benutzer auf die Datenbank berechtigen (SSMS)

SSMS offnen. Verbindung mit der im Log-Eintrag erwähnten SQL-Instanz (hier „SQL_Instance„) herstellen.

Den Benutzer aus dem Logeintrag (hier „Domain\ExcelServiceUser„) in SSMS unter Sicherheit > Anmeldungen finden (bei Bedarf neu erstellen) und Eigenschaften öffnen.

Im Fenster „Anmeldungseigenschaften“ auf der linken Seite „Benutzerzuordnung“ auswählen.

Auf der rechten, oberen Seite ein Häkchen für die Datenbank aus dem Log setzen (hier „Content_DB„).

Unten rechts die Mitgliedschaft in Datenbankrolle „SPDataAccess“ aktivieren und mit OK bestätigen.

(Wahrscheinlich würde auch die Datenbankrolle „db_owner“ funktionieren.)

Möglichkeit 2 – Benutzer per PowerShell berechtigen

Hinweis: Diese Schritte haben wir nicht ausgeführt, da wir die Berechtigung per SSMS vergeben haben.
SharePoint 2013 Management Shell mit administrativen Rechten starten.

Folgende Zeilen ausführen (vorher anpassen).

# Alle Web-Anwendungen anzeigen.
Hier die URL merken, die zu der in den Logs stehenden DB gehört (hier: Content_DB)
Get-SPWebApplication

# In dieser Zeile <Web Application URL> durch die URL aus dem vorigen Schritt ersetzen.
$w = Get-SPWebApplication –Identity <Web Application URL>

# Alle Anwendungspools mit dazugehörigen  Account-Namen auflisten.
In unserem Fall müssen wir uns den Account-Namen merken, unter dem die „Excel Services“ laufen (hier: Domain\ExcelServiceUser)
Get-SPServiceApplicationPool

# In dieser Zeile<ProcessAccountName> durch den Account-Namen aus dem vorigen Schritt ersetzen.
$w.GrantAccessToProcessIdentity("<ProcessAccountName>")

Die Schritte führen dazu, dass der Account, unter dem die Excel-Services laufen, in der Datenbankrolle „db_owner“, auf der Inhaltsdatenbank der gewählten Webanwendung, Mitglied wird.

Links

1. www.techtask.com: Excel Services: The workbook cannot be opened
2. stepbistep.net: The workbook cannot be opened – Excel Services error on SharePoint 2010

Der Beitrag Event-ID: 3760 – The login failed. Login failed for user ‚Domain\ExcelServiceUser‘ – SharePoint 2013 erschien zuerst auf Die SharePoint-Wiese.

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.