Balkongriller

SharePoint und Office 365 Blog


Hinterlasse einen Kommentar

Reindex einer Liste anstossen

SharePoint bietet die Möglichkeit, bestimmte Listen explizit neu indexieren zu lassen. Beim nächsten Incremental Crawl wird dann der Inhalt dieser einen Listen neu indexiert. Normalerweise geschieht dies nur bei einem Full Crawl. In grossen Farmen kann ein solcher Full Crawl aber Stunden oder gar Tage dauern.

In den List Settings unter Advanced kann man für jede beliebige Liste eine Reindexierung anstossen.

reindex

Ändert man die Konfiguration des Search Schemas (z.B. neue Managed Properties) kann man mit dem nachfolgenden PowerShell Script einfach einen Reindex aller Liste eines bestimmten Typs (hier mit dem Namen „Tasks“) initiieren.

$wa = get-spwebapplication "https://intranet.contoso.com"
foreach($site in $wa.sites)
{
  foreach($web in $site.AllWebs)
  {
    $list = $web.Lists["Tasks"]
    if($list -ne $null)
    {
      Write-Host "Reindex $($web.Title)"
      $version = $list.RootFolder.Properties["vti_searchversion"]
      $list.RootFolder.SetProperty("vti_searchversion", ($version + 1)); 
      $list.Update();                
    } 
    $web.Dispose()
  } 
  $site.Dispose()
}


Hinterlasse einen Kommentar

PDF Check Out funktioniert nicht

Seit dem March 2013 Public Update für SharePoint wird beim Öffnen von Adobe Acrobat PDF Dateien kein Check-Out Dialog mehr angezeigt. Wenn man die PDF nur lesen will, ist das nicht schlimm. Wenn es aber darum geht, die PDF Dateien zu bearbeiten oder Annotationen zu machen, fehlt eine wichtige Funktion. Microsoft hat den Bug bestätigt – wann wir mit einer Lösung rechnen können, steht aber in den Sternen.

In einem Adobe Forum findet man einen Workaround um das Problem zu umgehen. Dabei wir der JSLink auf dem SharePoint Field gesetzt. (Hey Developers, eine gute Gelegenheit, diese tolle, aber ziemlich unbekannte Funktion von SharePoint näher kennen zu lernen).

Zuerst geht es darum, eine JS Datei (wir nennen sie PDFFIX.JS) auf SharePoint zu hinterlegen. Das kann entweder via Module einer SharePoint Farm Solution geschehen. Man kann die Datei aber auch einfach in die Style Library hochladen. Anbei der Code von PDFFIX.JS

(function () {
 if (typeof SPClientTemplates === 'undefined')
 return;

 var PdfCtx = {};
 PdfCtx.Templates = {};
 PdfCtx.Templates.Fields = { 'LinkFilename': { 'View': PdfClientLinkFilenameNoMenu } };
 SPClientTemplates.TemplateManager.RegisterTemplateOverrides(PdfCtx);
})();

function GetExtension(szHref) {
 var sz = new String(szHref);
 var re = /^.*\.([^\.]*)$/;
 return (sz.replace(re, "$1")).toLowerCase();
}

var stsOpen = null;

function IsPdfClientInstalled() {
 if (stsOpen == null) {
 if (Boolean(window.ActiveXObject)) {
 try {
 stsOpen = new ActiveXObject("PdfFile.OpenDocuments");
 }
 catch (e) {
 stsOpen = null;
 }
 }
 }
 return (stsOpen != null);
}

function OpenPdfInClient(pdfFileUrl) {
 var fRet = true;
 try {
 fRet = typeof stsOpen.ViewDocument2 != "undefined" && stsOpen.ViewDocument2(window, pdfFileUrl, '');
 }
 catch (e) {
 fRet = false;
 };

 if (event != null) {
 event.cancelBubble = true;
 event.returnValue = false;
 }
 return fRet;
}

function PdfNewGif(listItem, listSchema, ret) {
 if (listItem["Created_x0020_Date.ifnew"] == "1") {
 var spCommonSrc = GetThemedImageUrl("spcommon.png");
 ret.push("<span class=\"ms-newdocument-iconouter\"><img class=\"ms-newdocument-icon\" src=\"");
 ret.push(spCommonSrc);
 ret.push("\" alt=\"");
 ret.push(Strings.STS.L_SPClientNew);
 ret.push("\" title=\"");
 ret.push(Strings.STS.L_SPClientNew);
 ret.push("\" /></span>");
 }
}

function PdfClientLinkFilenameNoMenu(param1, param2, listItem, listSchema) {
 var ret = [];
 var fileUrl = listItem.FileRef;

 if (fileUrl != null && typeof fileUrl != 'undefined' && TrimSpaces(fileUrl) != "") {
 if (listItem.FSObjType == '1') {
 if (listSchema.IsDocLib == '1') {
 RenderDocFolderLink(ret, listItem.FileLeafRef, listItem, listSchema);
 }
 else {
 RenderListFolderLink(ret, listItem.FileLeafRef, listItem, listSchema);
 }
 }
 else {
 ret.push("<a class='ms-listlink' href=\"");
 ret.push(listItem.FileRef);
 ret.push("\" onmousedown=\"return VerifyHref(this,event,'");
 ret.push(listSchema.DefaultItemOpen);
 ret.push("','");
 ret.push(listItem["HTML_x0020_File_x0020_Type.File_x0020_Type.mapcon"]);
 ret.push("','");
 ret.push(listItem["serverurl.progid"]);
 ret.push("')\" onclick=\"");

 var appInstalled = IsPdfClientInstalled();
 var szExt = GetExtension(listItem.FileRef);
 if (appInstalled && szExt == 'pdf' && browseris.ie) {
 ret.push("return OpenPdfInClient('");
 ret.push(window.location.protocol + "//");
 ret.push(window.location.hostname);
 ret.push(listItem.FileRef);
 }
 else {
 ret.push("return DispEx(this,event,'TRUE','FALSE','");
 ret.push(listItem["File_x0020_Type.url"]);
 ret.push("','");
 ret.push(listItem["File_x0020_Type.progid"]);
 ret.push("','");
 ret.push(listSchema.DefaultItemOpen);
 ret.push("','");
 ret.push(listItem["HTML_x0020_File_x0020_Type.File_x0020_Type.mapcon"]);
 ret.push("','");
 ret.push(listItem["HTML_x0020_File_x0020_Type"]);
 ret.push("','");
 ret.push(listItem["serverurl.progid"]);
 ret.push("','");
 ret.push(Boolean(listItem["CheckoutUser"]) ? listItem["CheckoutUser"][0].id : '');
 ret.push("','");
 ret.push(listSchema.Userid);
 ret.push("','");
 ret.push(listSchema.ForceCheckout);
 ret.push("','");
 ret.push(listItem.IsCheckedoutToLocal);
 ret.push("','");
 ret.push(listItem.PermMask);
 }

 ret.push("')\">");

 var fileRef = listItem["FileLeafRef"];

 if (fileRef != null) {
 var index = fileRef.lastIndexOf('.');
 fileRef = index >= 0 ? fileRef.substring(0, index) : fileRef;
 }

 ret.push(fileRef);
 ret.push("</a>");

 PdfNewGif(listItem, listSchema, ret);
 }
 }
 else {
 ret.push("<nobr>");
 ret.push(listItem["FileLeafRef"]);
 ret.push("</nobr>");
 }

 return ret.join('');
}

Jetzt muss man die Eigenschaft JSLink auf dem SPField LinkName setzen. Am besten geht dies mit PowerShell. Man kann z.B. das Field im Rootweb verändern und setzt damit die Eigenschaft innerhalb der gesamten Site Collection. Nachdem man die Datei z.B. nach „/Style Library/scripts/pdffix.js“ kopiert hat, würde das PowerShell wie folgt lauten.

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

$SPWebApp = Get-SPWebApplication "https://intranet"

foreach($SPSite in $SPWebApp.Sites)
{
 $web = $SPSite.RootWeb
 Write-Host $SPSite.RootWeb
 $field = $web.Fields.GetFieldByInternalName("LinkFilename")
 Write-Host $field.JSLink
 if ($field.JSLink -ne "/Style%20Library/scripts/PdfFix.js")
 {
 $field.JSLink = "/Style%20Library/scripts/PdfFix.js"
 $field.Update($true) #push change down to all lists
 }
}

Aber Achtung. Folgende Einschränkungen:

  • Wenn Microsoft den Bug gefixt hat, muss der Workaround wieder rückgängig gemacht werden. D.h. dokumentieren und die Beschreibung der Public und Cumulative Updates genau durchlesen.
  • Jedesmal wenn eine neue Site Collection erstellt wird, muss auf der neu erstellten Site Collection das PowerShell wieder ausgeführt werden.
  • Workaround ist immer ein anderer Name für Hack.


Hinterlasse einen Kommentar

Multi Farm hilft – Gründe warum eine SharePoint Farm nicht ausreicht

Sobald SharePoint in einem Unternehmen intensiv genutzt wird, stossen verschiedene Interessen oder Anforderungen aufeinander. Gerade wenn unterschiedliche Business Use Cases auf SharePoint abgebildet werden, kommt es zu Interessenkonflikten bezüglich Verfügbarkeit, Flexibilität und Upgradefähigkeit. Die Lösung dieser Konflikte ist häufig ein Verteilen der Use Cases auf verschiedene SharePoint Farmen.

Eine bereits bestehende Farm aufzuteilen ist aufwändig und dadurch teuer. Darum muss eine Multi Farm Strategie früh beim Aufbau einer SharePoint Plattform ins Auge gefasst werden.

In diesem Blog Post nenne ich Gründe, welche für eine Multi Farm Strategie sprechen. Zuerst aber die Gründe welche dagegen sprechen. Denn egal welche Verteilung man nimmt, es sind immer dieselben Argumente:

  • Der Aufbau einer zusätzlichen Farm ist mit Kosten für Hardware, Softwarelizenzen sowie Arbeit verbunden.
  • Der Betrieb von mehreren Farmen ist aufwändiger. So müssen z.B. Updates auf verschiedenen Farm eingespielt werden. Jede Farm muss gesichert und überwacht werden.
  • Aus Usability Sicht ist eine Integration zwingend. Es muss ein Weg gefunden werden, wie Search, Navigation aber auch User Profiles Farm-übergreifend funktioniert.
  • Das Durchsetzen von Regeln (Governance) ist in einer Multi Farm Umgebung anspruchsvoller.

Eine Multi Farm Architektur hat aber auch Vorteile bzw. ist manchmal zwingend notwendig. Nachfolgende die Gründe für eine SharePoint Server Multi Farm Architektur.

Geo Location

Häufig wird für jede geographische Region eine eigene SharePoint Farm betrieben. Am Hauptsitz z.B. in Europa steht eine zentrale SharePoint Farm, während in Amerika sowie in Asien je eine „Regional Farm“ aufgebaut wird. Dokumente, welche Unternehmensweit genutzt werden liegen auf der „Central Farm“. Nur lokal genutzte Daten bleiben auf der „Regional Farm“.

  • Der Zugriff auf die lokalen Daten ist schneller. Man kämpft nicht mit einer hohen Latenzzeit. Davon profitieren vor allem Nutzer aus Asien und Australien.
  • Über das WAN werden weniger Daten übermittelt.

DMZ

Funktionale Trennung

Während auf einer Farm nur die Out-of-the-Box Funktionen genutzt werden, dürfen auf einer zweiten Farm auch Customizations installiert werden. Standard Collaboration läuft somit auf einer SharePoint Umgebung, auf welcher (praktisch) kein Custom Code ausgeführt wird. Eine Multi Farm Architektur für die funktionale Trennung macht vor allem Sinn, wenn Custom Code Lösungen vorhanden sind. Mit dem SharePoint App Model von SharePoint 2013 ist das Thema nicht mehr so relevant.

  • Der Betrieb einer SharePoint Farm ohne Customizations ist einfacher.
  • Custom Code führt nicht zu Fehlern und schlechter Performance beim Nutzen der Out-of-the-Box Funktionen.
  • Service Packs und Cumulative Updates lassen sich auf der SharePoint Standard Farm schneller installieren.
  • Ein Upgrade der SharePoint Farmen kann unabhängig von einender erfolgen. Die SharePoint Standard Farm kann früher aktualisiert werden.
  • Für jede Farm können andere Regeln (Governance) gelten.

Funktionalle Trennung

Verfügbarkeit

Eine Auftrennung der Workloads nach Service Level Agreement (SLA) vereinfacht den Betrieb und senkt das Risiko, eines Ausfalls einer kritischen Anwendung. Zwei oder gar drei SharePoint Server Farm stellen ein anderes SLA zur Verfügung. Auf der „Gold“ Farm laufen nur die Anwendungen mit der höchsten SLA Stufe. Die Serverrollen sind redundant, die installierten SharePoint Erweiterungen werden genau geprüft und die Governance ist sehr streng. Auf der „Silver“ bzw. „Bronce“ Farm wird ein tieferer Service Level garantiert, dafür sind auch die Regeln lascher und, falls eine interne Verrechnung stattfindet, die Kosten tiefer.

  • Kritische Anwendungen haben eine höhere Verfügbarkeit.
  • Side-Effects von unkritische Anwendungen beeinträchtigen nicht die kritischen Anwendungen.
  • Die Komplexität der Farm nimmt ab, da pro Farm weniger Anwendungen betrieben werden.
  • Weniger Custom Code führt zu einem stabileren Betrieb.
  • Ein gestaffelter Upgrade ist möglich.

Hybrid

Auch eine Hybrid Lösung mit SharePoint On-Premise und Office 365 kann aus dem Multi Farm Aspekt betrachtet werden. So kann man auf Office 365 bzw. SharePoint Online unkritische Daten ablegen, während auf der SharePoint Farm On-Premise die sensitiven Daten liegen. Nutzt man Office 365 für die Standard Collaboration, liegen auf der On-Premise Farm weniger Daten, was den Betrieb vereinfacht. Ein typischer Workload für Office 365 ist auch OneDrive for Business.

  • Nutzer der Office 365 Collaboration Bereiche profitieren von den neusten Features wie Mobile Fähigkeit, Delve, Search, Office 365 Video, etc.
  • Auf OneDrive for Business kriegt jeder Nutzer 1 TB Speicher.
  • Sensitive Inhalte bleiben On-Premise auf den eigenen Servern.
  • Datenmenge auf On-Premise Systemen ist kleiner, was den Betrieb viel einfacher und dadurch günstiger macht.
  • Die Betriebsverantwortung für die Office 365 ist kleiner. Die IT kann sich mit anderen Themen beschäftigen.

Sicherheit

Viele Firmen setzen aus Sicherheitsgründen auf eine Multi Farm Architektur. Häufig baut man für die Extranet Funktionalität, manchmal auch für den mobilen Zugriff eine zweite SharePoint Farm in der DMZ. Auch wer eine Public Website auf SharePoint betreibt ist mit einer separaten Farm für die öffentliche Website gut beraten.

  • Zusammenarbeit mit Kunden, Lieferanten und externen Partnern über ein Extranet.
  • Interne Daten sind geschützt.
  • Mobiler Zugriff ist möglich.

DMZ

Compliance

Wenn es der Gesetzgeber verlangt, dass Daten gesondert gespeichert werden, dann hat man keine andere Wahl. Gewisse Daten müssen zwingend innerhalb des Landes liegen. Andere Gesetze und Richtlinien besagen, dass ein Teil der Daten auf separaten Systemen oder innerhalb einer Tochtergesellschaft gespeichert werden müssen. Werden die Vorgaben des Gesetzgebers nicht eingehalten, kann SharePoint nicht genutzt werden. Die Entscheidung fällt in solchen Situationen meistens klar aus.

  • Vorgaben des Gesetzgebers werden eingehalten.
  • SharePoint kann für Business-kritische Anwendungen genutzt werden.

Compliance

Integration

Was aus technischer Sicht Sinn macht, ist für den Benutzer nicht praktisch. Darum muss man den auf verschiedenen SharePoint Farmen verteilte Work Load aus Gründen der Usability wieder integrieren. Eine Integration besteht aus verschiedenen Elementen.

  • Navigation: Es ist ein Konzept notwendig, wie die Top Navigation über alle Farmen identisch oder ähnlich ist. Dazu kann eine Managed Navigation eingesetzt werden oder mit JavaScript eine eigene Lösung realisiert werden.
  • Design: Wird das Erscheinungsbild mit einer eigenen Master Page oder einem Theme verändert, so muss dies auf allen Farmen angewendet werden. Denkbar ist, dass durch ein Detail dem Benutzer angezeigt wird, auf welcher Farm er sich befindet (z.B. Länderflagge für Standort). Ein gänzlich unterschiedliches graphisches Design sollten Farmen aber nicht haben.
  • Search: Die Suche eignet sich sehr gut für eine Integration. Entweder crawlt eine Farm sämtlichen Content auch der anderen Farmen. Es ist aber auch denkbar, mittels „Remote Result Sources“ auf den Resultatseiten auch Suchresultate der anderen Farmen anzuzeigen.
  • User Profile: Die User Profile Service Application lässt sich auch Farm übergreifend einsetzen. Trotzdem erfordert dies einige Planung: Die User Profiles Service Application darf nicht über WAN Links verwendet werden. Andererseits ist es Unsinn einem Benutzer mehr als ein OneDrive for Business anzubieten. Zu beachten gilt auch, dass viele Social Features auf der MySite bzw. auf die OneDrive for Business Site basieren. Dieser Teil schreit quasi nach einen Proof-of-Concrept.
  • Managed Metadata: Die Managed Metadata Service Application kann von mehreren Farmen geteilt werden. Damit kann man erreichen, dass überall dieselben Terms sowie dieselben Content Types zur Verfügung stehen.

Mehr Informationen zur Integration der verschiedenen Service Applications findet man z.B. unter Multi-farm architectures with SharePoint Server 2013.


Hinterlasse einen Kommentar

ShareConf 2014: 10 Gründe warum der SharePoint langsam ist

Ich durfte heute an der ShareConf eine Session zum Titel „10 Gründe warum der SharePoint langsam ist“ halten. Anbei die Slides dazu.


Hinterlasse einen Kommentar

Search Driven Websites

An den Collaboration Days 2014 konnte ich eine Session über Search Driven Websites halten. Die Slides dazu findest du hier.