Schlagwort: Error

Kategorien
IT SharePoint

SharePoint (On-Premise) Blob-Cache löschen

Da sich der Markt in den letzten Jahren sehr in Richtung Office 365 bewegt hat, habe ich nur noch selten mit On-Premise SharePoint-Installationen zu tun.

Heute jedoch, musste ich eine (SharePoint 2016) Test-Farm neu aufbauen, zumindest ab Stufe Web-Applikation/Inhaltsdatenbank, welche neu von der Produktion übernommen werden musste und dann als neues Test-System konfiguriert werden sollte, da die alte Test-Farm nach einem missglückten Update korrupt und nicht mehr lauffähig war.

Um zu erkennen, ob man sich auf der produktiven Seite oder auf der Test-Umgebung befindet, hatten wir unteranderem früher via Composed Looks in der Test-Umgebung einen eigenen Look definiert, der im Farbton von der produktiven Seite abwich.

Im Prinzip also ein Look, mit der selben Masterpage, aber einem anderen *.spcolor-File, welches für das Test-System andere Farbtöne enthielt.

Nach dem Einspielen der neuen *.spcolor-Datei und aktivieren des gewünschten Composed Looks stellte sich jedoch Ernüchterung ein, die Seite sah genau so aus wie vorher. In der Preview des Composed Looks war schon zu erkennen, dass sich nichts ändern würde.

Gut, an was könnte das liegen? SPColor-Datei eingecheckt und veröffentlicht? Ja. Composed Look nochmals wegwechseln und dann erneut probieren – brachte nichts. IISReset durchführen – brachte auch nichts? Vielleicht den Object-Cache auf allen Servern (hier gab es nur einen) leeren? Hat auch nichts gebracht.

Eine Überprüfung der SPColor-Datei zeigte, dass sie die richtigen Werte enthielt, sie war auch veröffentlicht. Mit den Developer Tools im Browser wurde dann geprüft, durch welche CSS-Regel dieser Style appliziert wurde.

Der (falsche) Style entstammte von einer Themed-CSS-Datei. Beim Anwenden eines Composed Looks, werden die Werte aus der SPColor-Datei in eine zum Theme zugehörige CSS-Datei geschrieben (/Catalog-Bibliothek), die Datei hatte auch den richtigen Namen, aber die falschen Werte die nicht mit denen aus der SPColor-Datei übereinstimmten.

Ich erinnerte ich mich daran, dass ich so ein Problem schon einmal hatte und es daran lag, dass im Blob-Cache noch alte Versionen der CSS-Dateien (und anderer Dateien) vorhanden waren und diese dann an den Browser gesendet wurden, anstelle der aktuellen/korrekten.

Zuerst habe ich versucht, den Blob-Cache mittels PowerShell (SharePoint Management Shell) zu leeren:

$webApp = Get-SPWebApplication "<WebApplicationURL>"
 [Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp)

Leider hatte auch das nichts gebracht, nach einem erneuten aktivieren des gewünschten Looks, war immer noch alles beim Alten. Auch nach einem erneuten IISReset.

Ich wusste, dass man den Cache auch manuell löschen kann. Um auf Nummer sicher zu gehen, dass es wirklich nicht an diesem Cache liegt, beschloss ich auch dies auszuprobieren.

Dazu mus man wie folgt vorgehen:

  • web.config Datei der Web-Applikation ermitteln, öffnen und darin den Blob-Cache deaktivieren (Tag „BlobCache“ suchen und das Attribut „enabled“ auf „false“ stellen – dies muss auf jedem SharePoint-Server der Farm durchgeführt werden
  • Den Ordner des Blob-Caches im Dateisystem auf jedem Server löschen (den Pfad zum Ordner findet ihr auch in der web.config, im BlobCache-Tag)
  • IISReset durchführen
  • Nun den Blob-Cache wieder auf jedem Server der Farm aktivieren, dazu die web.config-Dateien erneut anpassen (BlobCache-Tag Attribut „enabled“ nun auf „true“ setzen)
  • Erneut einen IISReset durchführen (sollte durch das Speichern der web.config eigentlich automatisch geschehen)

Nachdem ich diese Schritte durchgeführt hatte, ging ich in den Websiteeinstellungen erneut auf „Aussehen ändern“ (Composed Looks) und wählte den gewünschten Look aus. Im Preview erschien immer noch der falsche Farbton. Ich habe den Look trotzdem angewendet und siehe da, auf der Webseite war dann nun doch der richtige Farbton endlich vorhanden.

Die (themed) CSS-Datei wurde nun korrekt neu erstellt, mit dem gewünschten, angepassten Farbton.

Hier noch weitere Informationen zum Thema Blob Cache, auf dem Blog von Karin Bosch, dort musste ich auch wieder einige der manuellen Schritte nachschlagen, da ich sie selber nicht mehr alle wusste 🙂 :
https://karinebosch.wordpress.com/my-articles/improving-performance-of-sharepoint-sites/part-3-blob-caching-in-sharepoint-2010/

Kategorien
IT SharePoint

SharePoint: Degradierte Search-Index-Komponente korrigieren

SharePoint Search Service Administration

Es kann manchmal vorkommen, dass eine Index-Partition der SharePoint Search Service Application degradiert, sich also in einem nicht mehr funktionstüchtigen Zustand befindet. Versucht man auf einer SharePoint-Seite dann eine Suche zu starten, wird man von einer Fehlermeldung begrüsst.

Der Administrator sieht dann in der Search Service Administration in der Central Administration ungefähr folgendes Bild:

Degraded SharePoint Index ComponentDas Ausrufezeichen signalisiert direkt, dass etwas nicht in Ordnung ist.

Um das Problem zu lösen, kann es genügen, die Index Component neu zu erstellen. Falls es daran liegt, dass die Disk, auf welcher die Index-Partition liegt, vollgelaufen ist, kann man auch eine zusätzliche Index-Komponente für die Partition auf einer anderen Disk erstellen.

Um eine neue Komponente zu erstellen, muss man PowerShell verwenden. Wie bei allen Änderungen an der Search Topology ist das Vorgehen so, dass man zuerst sich die aktuelle Topologie holt, diese dann klont, am Klon Anpassungen vornimmt und dann den Klon zur aktiven Topologie erklärt. Es ist ausserdem nötig, dass für das Vorgehen eine Index-Partition ohne Fehler vorhanden ist, das heisst, wenn nur eine vorhanden ist und diese einen Fehler hat, müsste man zuerst einen Index Reset machen. Die bestehende Index Component kann nicht entfernt werden, wenn sie die Letzte ist – das heisst, dass man zuerst in einem Durchgang eine neue Index Component hinzufügen muss, dann die Änderungen aktivieren muss und erst in einem zweiten Durchgang kann dann die problematische Komponente entfernt werden.

Hier der PowerShell-Code dazu:

# ----- Teil 1, neue Index-Komponente hinzufügen

# Aktive Topologie holen
$ssa = Get-SPEnterpriseSearchServiceApplication
$active = Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa 

# Einen Klon der aktiven Topologie erstellen
$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active

# Search Service Instance des Servers "SERVER1" holen (Namen muss natürlich angepasst werden)
$hostServer1 = Get-SPEnterpriseSearchServiceInstance -Identity "SERVER1"

# Neue Index-Komponente erstellen und zum Klon hinzufügen, Ziel-Instanz auf den gewünschten Server konfigurieren
$newIndexComponent = New-SPEnterpriseSearchIndexComponent -SearchTopology $clone -SearchServiceInstance $hostServer1 -IndexPartition 0

# Verzeichnis für Index (auf der vorhin mitgegebenen Instanz (SearchServiceInstance)) einrichten
$newIndexComponent.RootDirectory = "I:\Index"

# Überprüfung der Konfiguration der Komponenten im Klon (muss nun die neue Komponente und auch die alte anzeigen)
Get-SPEnterpriseSearchComponent -SearchTopology $clone

# Den Klon als neue, aktive Topologie aktivieren (Änderungen werden erst jetzt aktiv!)
Set-SPEnterpriseSearchTopology -Identity $clone

# Überprüfung der aktiven Topologie
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

# ----- Teil 2, alte Index-Komponente entfernen

# Aktive Topologie neu holen
$active = Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

# Einen Klon der aktiven Topologie erstellen
$clone = New-SPEnterpriseSearchTopology -SearchApplication $ssa -Clone -SearchTopology $active

# Search Components für die Topologie anzeigen (Component ID der degradierten Komponente kopieren)
Get-SPEnterpriseSearchComponent -SearchTopology $clone

# Index-Komponente (ID hier ersetzen/eintragen) aus der Topologie (Klon) entfernen
Remove-SPEnterpriseSearchComponent -Identity <Component ID> -SearchTopology $clone

# Den Klon als neue, aktive Topologie aktivieren
Set-SPEnterpriseSearchTopology -Identity $clone

# Überprüfung der aktiven Topologie
Get-SPEnterpriseSearchTopology -Active -SearchApplication $ssa

# ----- Teil 3, alte Topologie (da nun inaktiv) löschen (wird aktuell noch mit dem Namen '$active' referenziert)
Remove-SPEnterpriseSearchTopology -Identity $active<span style="display: inline-block; width: 0px; overflow: hidden; line-height: 0;" data-mce-type="bookmark" class="mce_SELRES_start"></span>

Nun sollte die Search Service Administration wieder eine saubere Topologie ohne Fehlermeldungen anzeigen.

Kategorien
IT SharePoint

SharePoint: Fehler beim Aktivieren einer Enterprise-Lizenz

Ich hatte letzthin einen Fall, wo ein Kunde von einer SharePoint (2013) Standard-Lizenz auf eine Enterprise-Lizenz wechseln wollte, da er neu einige der Enterprise-Features benötigte (z.B. für die Anzeige von Visio-Dateien).

Die Umstellung auf der Test-Farm funktionierte ohne Probleme. „Enable Enterprise Features“ in der „Central Administration“ gewählt, auf „Enterprise“ gewechselt und den Key eingegeben, nach einigen Sekunden Wartezeit kam die Erfolgsmeldung.

Doch als ich die selben Schritte auf der produktiven Farm durchführte, ging auf einmal nichts mehr. Die Websites waren nicht mehr verfügbar. Einige SharePoint-Services (z.B. der Timer-Service oder der Service für die Administration) waren gestoppt. Zur Sicherheit bootete ich die Server neu (es gab ja ein Wartungsfenster) und die Webseiten liefen wieder, allerdings war die Lizenz noch immer auf „Standard“.

Dann habe ich einen erneuten Versuch unternommen und es funktionierte leider wieder nicht. Zumindest brachte die Central Administration nun eine Fehlermeldung und sagte mir, dass ich in den Logs nachschauen sollte für mehr Details – auch stürzten die Webseiten nicht mehr ab.

In den ULS-Logs (zumindest auf dem Application Server) fand ich keine nützlichen Hinweise bezüglich der Fehlerursache. Ein Blick in den „Event Viewer“ zeigte mir einen Eintrag mit Source „SharePoint 2010 Products Configuration Wizard“ (auf einem „SharePoint 2013“-Server 🙂 ) mit der Mitteilung, dass der Wizard mit Erfolg durchgelaufen ist.

Da die Produktion aus 3 SharePoint-Servern bestand (1x App, 2x Web Frontend), ging ich via RDP auch auf die beiden WFE und öffnete auch dort den Event Viewer, auf dem ersten WFE gab es auch einen erfolgreichen „Product Configuration Wizard“-Eintrag, jedoch auf dem zweiten WFE gab es einen Fehler-Eintrag, mit folgendem Text:

„Failed to register SharePoint services.

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. Additional Information: An update conflict has occurred, and you must re-try this action. The object SearchAdminWebService was updated by Domain\AccountXy, in the PSCONFIG (9444) process on machine SERVER01. View the tracing log for more information about the conflict.

…“

Gemäss Fehlermeldung ist also ein Konflikt aufgetreten, es scheint so, als hätte ein Prozess auf dem einen SharePoint-Server den Prozess auf diesen Server gestört, da beide Prozesse etwas mit dem Objekt „SearchAdminWebService“ ändern wollten.

Die Suche im Internet lieferte zu diesem Problem leider nicht viele Lösungsvorschläge, jedoch ein Eintrag war vielversprechend. Ein Benutzer hatte eine Ähnliche Fehlermeldung (zumindest auch mit der Rückmeldung bezüglich „SPUpdatedConcurrencyException„) und er konnte das Problem lösen, in dem er die SharePoint-Timer-Services auf den SharePoint-Servern stoppte und dann (im Erfolgsfall) nach und nach aktivierte, so wurde verhindert, dass sich die Prozesse gegenseitig störten.

Ich habe also auf den beiden WFE-Servern den SharePoint-Timer-Service gestoppt. Dann habe ich auf dem App-Server den Lizenz-Key erneut eingegeben und auf OK geklickt. Sobald im Event-Viewer des App-Servers (Source: „SharePoint 2010 Products Configuration Wizard“) der Eintrag mit der Erfolgsmeldung für den „Product Configuration Wizard“ kam, habe ich auf dem ersten WFE-Server den Timerjob gestartet, als auch dort die Erfolgsmeldung kam, habe ich auf dem zweiten WFE den Timerjob gestartet und nach etwas Wartezeit kam dann auch dort die Erfolgsmeldung im „Event Viewer“.

Nach dem Zurückwechseln auf den App-Server wurde mir dort die Meldung präsentiert, dass die Lizenz erfolgreich eingespielt wurde und die CA fragte mich, ob ich auf den bestehenden Site-Collections das Enterprise-Feature aktivieren wollte – was ich verneinte.

Das Timing-Problem konnte also durch das serielle Starten der Timer-Jobs umgangen werden.

Kategorien
IT SharePoint SQL

Eine „suspect“ Datenbank reparieren

Es ist mir schon passiert, dass ich auf einmal keine SharePoint-Webseite meiner Virtual Machine mehr öffnen konnte. Auch die Central Administration funktionierte nicht mehr. Als Fehlermeldung erschien:

„This operation can be performed only on a computer that is joined to a server farm by users who have permissions in SQL Server to read from the configuration database. To connect this server to the server farm, use the SharePoint Products Configuration Wizard, located on the Start menu…“

Ein Ausführen des SharePoint Products Configuration Wizards war nicht möglich, der Wizard brach nach einigen Schritten ab, mit der Begründung, dass nicht auf die Configuration-Datenbank zugegriffen werden konnte.

Ein Blick in das MSSQL Management Studio zeigte dann, dass die SharePoint-Config-Datenbank im Status suspect, also verdächtig war.

Zum Glück gibt es einen Weg, die Datenbank wieder in einen gesunden Zustand zu bringen, oder zumindest es zu versuchen. Achtung: je nach Schweregrad der zu Grunde liegenden Störung kann es sein, dass bei diesem Vorgang Daten verloren gehen, da hier eine Reparatur der Datenbank mit „REPAIR_ALLOW_DATA_LOSS“ durchgeführt wird.

Via MSSQL Management Studio auf den Datenbankserver verbinden und ein neues Query-Fenster öffnen, danach folgende Zeilen ausführen („DatabaseName“ durch den Namen der „suspect“ Datenbank ersetzen):

EXEC sp_resetstatus [DatabaseName];
ALTER DATABASE [DatabaseName] SET EMERGENCY
DBCC checkdb([DatabaseName])
ALTER DATABASE [DatabaseName] SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB ([DatabaseName], REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE [DatabaseName] SET MULTI_USER

Je nach Grösse der Datenbank, Server-Leistung und Fehler-Anzahl kann der Vorgang zwischen wenigen Sekunden bis hin zu Stunden dauern. Bei mir brauchte es für eine 1 GB grosse Datenbank zum Beispiel ca. eine Minute. Im Ausgabefenster ist ersichtlich, was für Reparaturen vorgenommen wurden und ob diese zu Datenverlust führten.

Nachdem die Operation beendet wurde, kann man versuchen wieder auf die Datenbank zuzugreifen. In meinem Fall konnte ich wieder auf die SharePoint-Central-Administration und die Web-Applications zugreifen.