SharePoint 2010: Probleme bei Suchergebnisseite

Schon wieder ein Problem mit SharePoint, diesmal bei den Suchergebnissen. Grundlage ist eine voll gepatchter SharePoint 2010 Server (September 2014 CU). In einer Subsite sind die Berechtigungen auf einer Dokumentenbibliothek aufgebrochen und ein ein zusätzlicher Benutzer wurde mit Leserechten hinzugefügt.
Dieser möchte nun über das ganz normale Suchfeld oben rechts in der Ecke in der Liste suchen. Klappt aber leider nicht. 😛 SharePoint fragt nach Credentials und bringt dann als Fehler ein „Access denied“. Der Benutzer hat aber Rechte auf die Zielseite (osssearchresults.aspx).

Das Lösung habe ich bei „Surya SharePoint Tips“ gefunden, bin aber nicht so ganz damit einverstanden. Problem ist meiner Meinung nach, das er die Originalseite editiert. Bei einem Update kann es dann passieren, das sie vom Service Pack / CU überschrieben wird und somit das Problem wieder auftritt.

Deshalb würde ich die Seite kopieren und dann die neue Seite als Ergebnisseite der Website-Sammlung eintragen.

Also wie folgt:

  1. Auf einem der SharePoint Web Server eine Kopie von „C:\Program Files\Common Files\Microsoft Shared\Web Server\Extensions\14\TEMPLATE\LAYOUTS\osssearchresults.aspx“ machen. ( benennen z.B. „osssearchresultsFIXED.aspx“)
  2. In der neuen Datei :
    <%@ Page Language="C#" DynamicMasterPageFile="~masterurl/default.master"  
    Inherits="Microsoft.Office.Server.Search.Internal.UI.OssSearchResults"  
    EnableViewState="false" EnableViewStateMac="false"%>

    ändern in:

    <%@ Page Language="C#" MasterPageFile="/_layouts/v4.master"  
    EnableViewState="false" EnableViewStateMac="false"%>
  3. diese Datei auf alle WEB- Server in den gleichen Ordner kopieren
  4. Dann unter http://root/der/WebsiteSammlung/_layouts/enhancedSearch.aspx den Wert im Feld „Zielergenbnisseite der Websitesammlung“ auf die neue Seite abändern (z.B. /_layouts/OSSSearchResultsFIXED.aspx)

Den vierten Punkt für jede betroffene Websitesammlung wiederholen. Damit sollte es auch bei einem Update keine Probleme geben.

 

Mehr

SharePoint 2013: InfoPath Forms Services funktionieren nicht

Ein Problem, das mir bei der Konfiguration eines neuen SharePoint 2013 Server untergekommen ist:
Fehler

Fehler beim Laden des Formulars.
Detailierter Fehler:

Auf den folgenden Speicherort kann nicht zugegriffen werden, da er sich in einer anderen Websitesammlung befindet: ‚https://ServernameDerMaschine/PA/BM/Formulare/Forms/template.xsn?SaveLocation=https://VirtuellerNamederWebApp/PA/BM/Formulare/&
Source=https://VirtuellerNamederWebApp/PA/BM/Formulare/Forms/AllItems.aspx&
ClientInstalled=false&OpenIn=Browser&NoRedirect=true&
XsnLocation=https://ServernameDerMaschine/PA/BM/Formulare/Forms/template.xsn‘.

Auffällig ist, das die Anwendung wild die Servernamen durcheinender würfelt. Und warum es nicht funktioniert ist damit auch klar. Auf dem Namen der Maschine hängt kein WEB- Server. Schon gar nicht dieselbe Websitesammlung. So weit, so einfach, aber warum ist das so?

Nach einigem Forschen hab ich es dann gefunden. Grund ist das in SharePoint 2013 neu eingeführte „Request Management“. Im Detail wird das Ganze bei harbar.net erklärt.

Kurz zusammengefasst kümmert sich die Komponente darum ankommende Anforderungen nach bestimmten Kriterien auf alle WEB Server zu verteilen. Dafür gibt es ein entsprechendes Regelwerk. Nur leider funktioniert das für die Forms Services eben nicht.

Abhilfe schafft das Abschalten der Komponente mit Hilfe der Powershell:

$webApp = Get-SPWebApplication http://webapphostname
$reqSettings = $webApp | Get-SPRequestManagementSettings
$reqSettings.RoutingEnabled = $false
$reqSettings.Update()

War bei mit jetzt kein Problem, da meine Farm eh nur aus einem WEB- Server besteht. Nach einer praktikablen Lösung für eine große Farm suche ich noch….

Mehr