Schlagwort-Archive: Troubleshooting

SharePoint Durable Links – Bug oder Feature?

In den letzten Wochen habe ich mich intensiver mit den neuen Durable Links beschäftigt und ich wollte meinen Augen nicht trauen, was dabei heraus kam. Kurz: Diese neuen Links funktionieren nur bei Office Dateien beim Umbenennen. Aber der Reihe nach…

Test-Framwork:

  • SharePoint On-Premises und der entsprechenden Office Online Server Version (früher Office Web Apps)
    – Release Candidate
    – GA inklusive Mai CU
    – GA inklusive Juni CU
  • SharePoint Online in O365
  • Zum Verschieben der Dokumente folgende Ansätze genutzt
    – „Content and Structure“ in den SharePoint Site Collection Settings

    – „Send To“ Locations in der SharePoint Item Ribbon

    – Drittanbieterlösung

NEU: Durable Links

  • Links sollen erhalten bleiben, selbst wenn ein Dokument umbenannt oder verschoben wird
  • es wird eine ID dem Dokument hinzugefügt, an dem es in der Inhaltsdatenbank identifiziert werden soll, egal welchen Namen das Dokument hat oder welche URL davor steht
  • http://intranet2016/sites/RootSite/SubSite/Shared%20Documents/Doc1.docx?d=wc6f9bf88c1a846579992030744063b1b (durable Link)
  • Office Online Server erforderlich, mit dem der durable Link dann automatisch generiert wird

ALT: Document ID

  • Zusätzliche ID von Dokumenten per Site Collection
  • gedacht, um z.B. auf feste IDs per Custom Solution zu verweisen oder mit dem CQWP (Content by Query Web Part) eine Übersicht aus verschiedenen Dokumenten zusammen zu stellen
  • ein Prefix der ID kann konfiguriert werden und auch erneut überschrieben werden
  • Die ID kann auch in einer zusätzlichen Spalte angezeigt und als Link genutzt werden
  • http://intranet2016/sites/RootSite/SubSite/_layouts/15/DocIdRedir.aspx?ID=ROBTHEMSGEEK-680852213-3
  • Das Mapping hinter dem Link beruht jedoch auf dem Search Index
  • Das Umbenennen und eingeschränkte Verschieben erhält die ID und den Link, ABER, die Search muss den neuen Namen oder Ablageort erneut indexieren, damit er funktioniert

NEU am ALTEN:

Vor SharePoint 2016 wurde trotz DocID der normale Link im Kontextmenü („„) erhalten. Somit haben wir einen Link mit DocID in einer extra einzublendenen Spalte und einen normalen Link im Kontextmenü der Datei. Welchen Link nimmt nun wohl der Endanwender, um auf eine Datei zu verweisen? Richtig, den normalen. In SharePoint 2016 wurde das verbessert. Sobald man in den Site Collection Features die Document ID aktiviert, erhalten Dokumente nach durchgelaufenem Timer Service eine zusätzliche (Link-) ID. Außerdem wird der normale Link mit dem DocID-Link (DocIdRedir.aspx?ID=…) im Kontextmenü ersetzt. Damit haben wir nicht mehr zwei verschiedene Links pro Dokument, sondern nur noch den einen (besseren) Document ID Link.

———————–

Soviel zur Theorie. Jetzt spielen wie Myth Busters.

Funktioniert bei… Durable Links Document IDs
Office Dateien
(Word, Excel, PowerPoint, OneNote)
Ja Ja
Anderen Dateien
(pdf, jpg, png, wmv, mp4, etc.)
Nein Ja
Umbenennen Ja Ja*
Nach erneutem Crawl
Verschieben in andere Bibliothek
(per Content and Strcuture)
Nein Ja*
Nach erneutem Crawl
Mit Drittanbieterlösung auch ohne Crawl
Verschieben in andere Site
(per Content and Strcuture)
Nein Nein
Verschieben in andere Site Collection
(per Send To Locations)
Nein Nein

Und ich lege noch einen drauf. Sobald ich die Document IDs aktiviere, verschwinden die Durable Links komplett. Ehrlich gesagt ist das vielleicht auch ganz gut so, denn wir sehen oben, dass ich mit den DocID-Links einfach mehr erreichen kann.

Auf dem offiziellen und ein paar Monate alten Blog von Bill Bear (https://blogs.technet.microsoft.com/wbaer/2015/09/22/durable-links-in-sharepoint-server-2016-it-preview) werden obige Features aber noch immer uneingeschränkt so beschreiben, wie es funktionieren soll aber (noch) nicht geht. Daher auch der Vermerkt in rot bei obiger Durable Links Beschreibung. Es existieren auch unzählige andere Blogs, die von diesem tollen Feature (falsch) berichten. Denn spätestens ab dem Release Candidate wurde offensichtlich dieses Feature (sowie auch andere Funktionen siehe DLP in einem früheren Blogbeitrag [http://blogs.msdn.com/b/robert_mulsow/archive/2016/03/24/governance-und-compliance-mit-dem-neuen-sharepoint-2016-dlp-im-compliance-center.aspx]) wieder entfernt.

Grundsätzlich bin auch ich von dem Ansatz der Durable Links begeistert und unterstütze diese Idee als absolut notwenidgen Schritt in die richtige Richtung von Microsoft. Aktuell liegen Versprechen und Realität aber leider noch weit auseinander. Wir können nur hoffen, dass mit den nächsten CUs die Funktionalitäten zurück nach SharePoint 2016 kommen und auch die Durable Links wie versprochen in O365 funktionieren.

Bis dahin bleibt wachsam und viel Spaß beim „SharePointen“!

Zero-Downtime Patching nur eingeschränkt mit Distributed Cache Service möglich

Mit SharePoint 2016 wurden die MinRoles und damit auch das Zero-Downtime Patching eingeführt. Aber derzeit kursieren widersprüchliche, gar falsche Aussagen in den Technet Artikeln. Die Dinge möchte ich gerade rücken und Ihnen zeigen, wie Sie mit dem Distributed Cache Service umgehen müssen, um das versprochene Zero-Downtime Patching bestmöglich zu realisieren.

Generell gibt es schon tolle Beiträge von John Peluso und Stefan Goßner über die Eigenarten des SharePoint Patchings in der Vergangenheit und wie dies SharePoint 2016 löst. Eine Kleinigkeit wird dabei jedoch ausgeklammert: Der Distributed Cache Service.

Derzeit ist der Englische Technet Artikel (nach meiner Erfahrung) korrekt:
https://technet.microsoft.com/en-us/library/mt346114(v=office.16).aspx

Darin wird gesagt, dass man acht (8) Server für die Hochverfügbarkeit in einem Zero-Downtime Patching Szenario benötigt. Allerdings wird richtigerweise darauf hingewiesen, dass es Einschränkungen mit dem Distributed Cache Service gibt

Der deutsche, russische und spanische Artikel (nach meinen persönlichen Checks) zeigen aktuell noch eine falsche Aussage. Darin wird gesagt, dass mindestens neun (9) Server erforderlich sind und der Distributed Cache Service dabei eine spezielle Rolle einnimmt mit insgesamt drei Servern, weil es einen Clusterquorum benötigt. Dies ist nicht korrekt, da der Service nicht über eine Quorum-Rolle im Cluster verwaltet wird. Stattdessen müssen die Informationen, die auf einem Cache Server gespeichert sind, für das Patching auf einen anderen Server manuell übertragen werden. Dies erfolgt per PowerShell cmdlet:

Stop-SPDistributedCacheServiceInstance -Graceful

Zusätzliche Details und weiterführende Links, wie Sie den Distributed Cache Service planen und verwalten können, habe ich bereits im letzten SharePoint Adventskalender beschrieben:
http://blogs.msdn.com/b/robert_mulsow/archive/2015/12/16/sharepoint-configuration-best-practices-distributed-cache-service.aspx

Lassen Sie sich also nicht in die Irre führen. Das Problem habe ich an Microsoft reported. Entsprechende Updates sehen Sie dann hoffentlich bald auf den Technet-Seiten. Auch ich werde diesen Artikel nach Aktualisierung anpassen.

Viel Spaß beim „SharePointen“!

Konfigurieren des Windows Performance Monitors

In Anlehnung an das Performance Monitoring aus meinem SharePoint Adventskalender gibt es noch ein paar Dinge, die man beachten sollte, wenn man sich ein Performance Counter Set zusammmen stellt. In diesem Beitrag möchte ich daher erläutern, wie Sie sich ein Set erstellen und worauf man dabei achten muss, um im Anschluss auch valide Daten auswerten zu können.

Auch wenn es natürlich auch 3rd Party Software gibt, welche unsere Rechner-Systeme überwachen kann, so bringt Windows Server aber bereits selbst sehr viele Messgrößen mit, die man ganz einfach mit dem mitgelieferten Performance Monitor (perfmon.exe) überwachen kann. Um sich nun ein Collector Set anzulegen, gehen Sie folgendermaßen vor.

1. Im PerfMon-Fenster navigieren Sie zu den Data Collector Sets > User Definied. Mit einem Rechtsklick oder über den Button oben im Fenster beginnen Sie, ein neues Set anzulegen.

2. Vergeben Sie dem Set einen aussagekräftigen Namen und wählen Sie, ob Sie mit einer Vorlage oder mit einem leeren Set starten möchten. Haben Sie bereits ein Collector Set angelegt (als xml-Datei gespeichert), so können Sie auch dieses als Vorlage auswählen. Hinweis: Ein unter Windows Server 2012 angelegtes Set kann zwar in frühere Serverversionen eingelesen werden, jedoch kann es nicht gestartet werden. Bitte beachten Sie dies, wenn Sie ein Set aus einer Vorlage erstellen möchten.

3. Auf der Folgeseite sehen Sie, dass Sie den PerfMon auch als Werkzeug nutzen können, um sich beim Über- oder Unterschreiten eines Grenzwertes informieren zu lassen. Auch andere Aktionen können ausgeführt werden. Dies ist natürlich ein sehr schöner Ansatz, um pro-aktiv die Systeme zu überwachen.

Ebenso können Sie aber auch re-aktiv z.B. Daten über Registry-Einträge („System Configuration Information“) oder Events verschiedener Dienste wie exemplarisch der Firewall („Event Trace Data“) sammeln und überwachen. Und dies gilt auch für den Performance Counter Fall, den ich beschreiben möchte. Dafür haben wir folgendes Szenario: Unser SharePoint ist bereits langsam und nun wollen wir heraus finden, woran es liegt. Wir wählen also die Performance Counter.

4. Auf der Folgeseite können wir nun unsere verschiedenen Counter auswählen. Welche ich für SharePoint empfehle, können Sie in meinem Adventskalender, Türchen 9-12, nachlesen (Bsp.: http://blogs.msdn.com/b/robert_mulsow/archive/2015/12/09/sharepoint-performance-monitoring-performance-counter-f-252-r-den-prozessor.aspx). Bitte achten Sie darauf, dass Sie in diesem Fenster auch die Intervallzeit einstellen. Ich empfehle bei längeren Überwachungen ein Intervall von 60 Sekunden. Damit wachsen die Logs auf nicht mehr als wenige MB an, wenn Sie einen Überwachungszeitraum von 24 Stunden wählen.

5. Ganz wichtig bei der Auswahl der Counter ist, für welche Quellen die Daten aufgezeichnet werden sollen. Zum Beispiel haben unsere Server mehr als eine Netzwerkkarte oder mehr als ein Laufwerk. Möchte Sie beispielsweise ein Problem bei den Disk I/Ops überwachen und wählen „_Total“ aus, dann wird der Durchschnitt über alle Laufwerke gesammelt. Sind also vier von fünf Laufwerken optimal eingerichtet, aber das Fünfte und vielleicht Wichtigste ist es eben nicht mit einer Disk Queue Length von über 10, dann komme Sie bei der Auswertung leider nicht der Ursache für eine langsame SharePoint Performance auf die Schliche. Achten Sie also darauf, dass Sie wirklich die einzelnen Laufwerke auswählen. In meinem Screenshot sind dies die Laufwerke C: und D:, die ich überwachen möchten.

6. Haben Sie alle Counter ausgewählt, dann können Sie auf der Folgeseite noch den Ort auswählen, wo die Logs gespeichert werden sollen.

7. Im letzten Schritt achten Sie bitte darauf, unter welchem Benutzer die Daten gesammelt werden sollen. Standardmäßig ist dies der lokale System Account.

Die Auswahl des Benutzers ist besonders wichtig, wenn die Daten zusätzlich für andere Computer in einem Set gesammelt werden sollen. Unter Schritt fünf können Sie im Screenshot erkennen, dass die Daten für den „Local Computer“ gesammelt werden. Wenn Sie jedoch auch Daten von anderen Computern sammeln möchten, muss der Benutzer auch über die entsprechenden Rechte auf den anderen Rechnern verfügen. Der lokale System Account hat diese Rechte natürlich nicht. Verwenden Sie also einen Benutzer, der sich auf den anderen Rechnern auch in den Gruppen „Performance Monitor Users“ und „Performance Log Users“ befindet.

 

(Auf älteren Windows Systemen Microsoft .NET Framework 2.0 muss zusätzlich der RemoteRegistry Service auf den Rechnern laufen, auf die „aus der Ferne“ zugegriffen werden soll.)

Damit ist das Anlegen des Performance Counter Sets abgeschlossen. Wenn Sie diese Sets nun zu einem bestimmten Zeitpunkt starten möchten, können Sie dies direkt tun, indem Sie diesen manuell starten. Mann kann dies aber auch takten. Dazu empfehle ich, eine Stopp-Kondition zu deifnieren. Das einfachste Beispiel ist das Stoppen nach 24 Stunden.

 

Anders kann man die Sets auch jeden Tag zu einer bestimmten Zeit starten und nach z.B. vier Stunden stoppen. Ein Szenario, um beispielsweise die Backup Performance jede Nacht zu überwachen.

Welches Szenario Sie auch haben, die zusätzlichen Informationen, die mir der Performance Monitor liefern kann, helfen deifnitiv, um den Ursachen meiner Performance-Probleme auf die Schliche zu kommen. Denn die alte Weisheit „wir brauchen mehr RAM“ löst leider nicht alle Probleme.

 

 

SharePoint Backup & Recovery – Von RTO, RPO und RLO zum fertigen Desaster Recovery Plan (2/2)

SharePoint Adventskalender – 24. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Im zweiten Teil zu unserem Disaster Recovery Plan geht es um

  • Überwachung
  • Recovery Szenarios
  • Dokumentation

Überwachung:
Sind unsere regelmäßigen Backup-Pläne in Abstimmung auf die Unternehmens-SLAs eingerichtet und der benötigte Speicherplatz für die Backupdaten vorbereitet, so kann es nun losgehen. Es würde mich überraschen, wenn alles von Anfang an problemlos läuft.

Es können zum Besipiel plötzlich Ports geschlossen werden oder Datenbanken sind hinzu gekommen oder neue Lösungen wurden ausgerollt etc. Dies müssen wir für die Backup Jobs genau im Auge behalten und gegebenenfalls nachbessern. Denn ein fehlgeschlagenes Backup ist ebenso nutzlos, wie ein erfolgreiches, dass aber entscheidende Komponenten für eine Wiederherstellung nicht berücksichtigt hat. Auch das gestern angesprochene Szenario mit dem mangelnden Backupspeicherplatz führt mich ganz schnell an die Grenzen meiner SLAs. Überwachen Sie daher sehr genau alle Komponenten Ihres Backups und greifen Sie gegebenenfalls pro-aktiv ein.

Recovery Szenarios:
Angenommen, alle Backup Pläne werden stets erfolgreich ausgeführt, sodass wir sichere Backupdaten haben. Was passiert, wenn der Ernstfall eintritt? Wissen Sie sicher, dass die Wiederherstellung aus den Backupdaten reibungslos funktioniert? Wie lange dauert es? Reicht die Zeit aus, um meine RTO einzuhalten?

Um diese Fragen beantworten zu können, müssen Sie sich realistische Wiederherstellungsszenarien schaffen, die Sie auch in regelmäßigen Abständen testen. Ganz wichtig sind dafür standardisierte Prozesse und Verantwortlichkeiten. Beispielhaft möchte ich folgende Szenarien vorschlagen:

  1. Monatliche Tests:
  • Dokument / Listenelement
  • Spalte einer Liste / Dokumentbibliothek
  • Komplette Liste / Dokumentbibliothek
  • Komplette SharePoint Site (SubSite)
  • Eine gesamte Inhaltsdatenbank
  • Quartalstests:
  • Gesamte Web Application (inkl. Datenbanken, IIS, Authentifizierung, etc.)
  • Service Applications (z.B. Search, UPA, MMS, etc.)
  • Halbjährliche Tests:
  • Web Front End Server
  • Application Server
  • Index Server
  • Jährliche Tests:
  • Komplettes Desaster Recovery

Dokumentation:
Dieser Teil ist mit Sicherheit am unbeliebtesten, aber der wichtigste. Denn was bringen all die Bemühungen zuvor, wenn im Ernstfall niemand weiß, wer verantwortlich ist, weil der Administrator krank oder im Urlaub ist, welche Skripte oder Aktionen in welcher Reihenfolge auszuführen sind und was die Endbenutzer erwarten dürfen.

Eine klare Dokumentation – so aufwendig sie auch ist – nimmt diese Ängste und soll im Ernstfall das Handbuch sein, in dem die Antworten auf alle Wiederherstellungsfragen stehen. Im perfektesten Fall sollte man so einen Disaster Recovery Plan einem unbeteiligten in die Hand geben können und dieser weiß dann, was zu tun ist – auch wenn der Administrator im Urlaub ist. Innerhalb der Dokumentation müssen dafür klare und messbare Ziele definiert werden.

Nachfolgend ein paar Vorschläge, was zu den gestern und weiter oben erwähnten Punkten noch Teil eines Disaster Recovery Plans sein sollte:

  1. Stakeholder:
    1. Für welche Personen im Unternehmen hat das Dokument Relevanz
    2. Dies können Kunden, Endnutzer, Administratoren und auch das Management sein
  2. Aktueller Status:
  • Aktuelle Farm Topologie
  • Eingespielte Anpassungen und Einstellungen
  • Abhängigkeiten
  • Richtlinien:
  • RTO (in Abhänigkeit der RLO, denn eine Single-Item-Wiederherstellung kann schneller gehen, als ein komplettes Disaster Recovery)
  • RPO
  • RLO
  • SLA
  • Verantwortlichkeiten (SharePoint, SQL, Plattform, AD, Netzwerk, etc.):
  • Für Backup Pläne
  • Für Wiederherstellung
  • Backup Strategien:
  • Was ist alles Bestandteil (Scope) von konfigurierten Backup-Plänen
  • Für welche Komponenten werden native Werkzeuge, für welche Drittanbieter verwendet
  • Wiederherstellungsprozesse:
  • In welchen Szenarien soll die gesamte Farm wieder hergestellt werden
  • In welchen Szenarien ist eine Single-Item-Wiederherstellung zu verwenden
  • Für welches Szenario werden native, wann werden Drittanbieterlösungen verwendet
  • Schritt-für-Schritt Anleitungen für die wiederherstellung der einzelnen Komponenten
  • Gegebenenfalls Skripte und Konfigurationen
  • Regelmäßige Tests:
  • Idealerweise durchzuführen von Mitarbeitern, die nicht hauptverantwortlich sind und auch nicht den DR-Plan geschrieben haben – so können zusätzlich Ungenauigkeiten aufgedeckt werden
  • Festzuhalten sind:
    • Szenario
    • Zeitpunkt
    • Benötigte Zeit
    • Testergebnis
    • Kommentar

Und das wichtigste zum Schluss:

Ein Disaster Recovery Plan mit all den gestern und heute vorgestellten Komponenten ist ein “lebendes Dokument”! Genauso, wie sich Infrastrukturen, Backup- und Test-Szenarien sowie Ansprechpartner ändern, muss sich auch der DR-Plan anpassen, um stets auf dem aktuellen Stand zu sein. Wenn Sie all diese Tipps beherzigen, dann wird Ihnen ein Disaster Recovery keine Kopfschmerzen oder schlaflosen Nächte mehr bescheren.

Apro pros „bescheren“: Ich wünsche allen ein besinnliches Fest im Kreise Ihrer Liebsten, mit lecker Essen, vielen Geschenken und schönen Momenten auch mal ganz ohne SharePoint! 🙂

————————————————————-

Weitere Türchen:

SharePoint Backup & Recovery – Von RTO, RPO und RLO zum fertigen Disaster Recovery Plan (1/2)

SharePoint Adventskalender – 23. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Backup kann jeder! Nur bei der Wiederherstelung aus einem Backup wird es interessant. Was alles berücksichtigt werden muss und Best Practices für Backup & Recovery Strategien möchte ich Ihnen in den letzten beiden Türchen unseres SharePoint Adventskalenders mitgeben. Wir schauen uns dafür folgende Kategorien an:

Heute: Service Level Agreement (SLA)

  • Verstehen von RTO, RPO und RLO
  • Komponenten und Backup-Umfang
  • Kapazitätsplanung

Morgen: Disaster Recovery Plan

  • Überwachung
  • Recovery Scenarios
  • Dokumentation

Verstehen von RTO, RPO und RLO:
Wenn wir mit SharePoint arbeiten als Kollaborationsportal arbeiten, so generieren wir darin viel Wissen (Intellectual Property – IP). Da immer mehr das IP den Wettbewerbsvorteil von Unternehmen definiert, muss es geschüzt und gesichert werden. Es sind aber häufig die selben Fragen, die mir bei Kunden begegnen:

  • Haben wir überhaupt ein Backup?
  • Wie lange brauchen wir, um ein einziges Objekt wieder herzustellen?
  • Erfüllen wir immer unsere SLAs?
  • Was ist unser Disaster Recovery Konzept?

All diese Fragen müssen in einem Disaster Recovery Plan beantwortet werden. Den Anfang machen die RTOs, RPOs und RLOs.

Recovery Time Objective (RTO):
Dies ist die Zeit, die benötigt wird, um alle Systeme nach einem Ausfall wieder zum Laufen zu bekommen. Darin fallen alle Verantwortlichkeiten und Prozesse, die durchlaufen werden müssen, um den letzten laufenden Zustand wieder herzustellen.

Recovery Point Objective (RPO):
Dies ist der maximal akzeptable Datenverlust und definiert damit, mit welcher Häufigkeit Backups durchgeführt werden müssen.

Addiert man die RTO und RPO, so erhalten wir die Zeitspanne, für die keine produktive Arbeit mit dem SharePoint möglich ist sowie bereits erledigte Arbeiten verloren gehen.

Recovery Level Objective (RLO)
Diese Deifnition wird oft vergessen, aber sie ist eine ganz Entscheidende, da sie die RTO und RPO beeinflusst. Die RLO soll bestimmen, mit welchem Granularitätslevel gesichert und wieder hergestellt werden kann. Sollen beispielsweise auch alle Metadaten, Berechtigungen, Nutzerdaten, etc. gesichert werden, so macht dies den Datenbestand komplexer. Dadurch können sich wiederum die Backupzeiten verlängern und ich muss vielleicht meine Backup-Fenster – das RPO – erweitern. Je komplexer die Daten sind, desto schwieriger wird in der Regel auch die Wiederherstellung. Besonders bei einer Single-Item-Wiederherstellung ist meine RTO unverhältnismäßig groß mit nativen Mitteln.

Somit müssen wir einen geeigneten Konsens finden, der zunächst niedrige RTOs und RPOs ermöglicht, aber idealerweise auch eine kleine Granularität erlaubt. Nähere ich mich diesen Zielen an, so steigen leider die Kosten auf der anderen Seite. Und genau diese Kosten stellen die nächste Variable in unserem Hebel für ein Backup Konzept dar. Eine allgemeingültige Regel über RTO, RPO und RLO, die für alle Unternehmen anwendbar ist, gibt es leider nicht. Die müssen Sie für Ihr Unternehmensrichtlinien selbst bestimmen.

 

Komponenten und Backup-Umfang:

Ein sharePoint besteht nicht nur aus den Inhaltsdatenbanken. Weiterhin sind die Service Applications zu betrachten, Farm-Solutions, InfoPath Formulare, IIS Settings, BLOB Storage und vielleicht noch weitere Anpassungen und Komponenten, wie z.B. Microsoft Project. Exemeplarisch sehen Sie in der Abbilding links die Komponenten einer SharePoint 2013 Farm. Es wird also schnell deutlich, was Ihnen alles fehlt, wenn Sie nur auf die Inhaltsdatenbanken schauen. Dennoch wäre ein nahezu vollständiger Wiederaufbau der Farm nach einem Disaster prinzipiell möglich. Da wir dafür jedoch unzählige (manuelle) Schritte benötigen, läge die RTO weit außerhalb eines akzeptablen Niveaus.

Weiterhin bestehen bei der Wiederherstellung verschiedenste Abhängigkeiten. Einfaches Beispiel: es müssen Farm Solutions ausgerollt werden, bevor die Datenbanken wieder an die Web Application angehängt werden. Wir sehen also, wie komplex so eine Backup Strategie ist. Es gibt Drittanbieter-Lösungen, die Ihnen dabei viel abnehmen, weil sie automatisch verschiedenste Komponenten sichern und wiederherstellen können. Achten Sie dabei besonders darauf, ob diese Lösung SharePoint wirklich „versteht“. Beispielsweise würden wir mit einer Wiederherstellung der Konfigurationsdatenbank einen Zustand erschaffen, der unvorhersehbare Folgen hätte. Zudem würden wir den Support mit Microsoft verlieren. Das Data Protection Modul der Firma AvePoint ist beispielsweise so ein Produkt, dass SharePoint versteht und all die angesprochen Komponenten sichern und wiederherstellen kann. Die Microsoft Support Richtlinien werden dabei nicht verletzt.

Kapazitätsplanung:
Ein Backup von SharePoint benötigt Platz, aber die Speicherlaufwerke haben nur begrenzte Kapazitäten. Daher ist auch die Kapazitätsplanung ein wichtiger Bestandteil von SLAs im Rahmen eines Disaster Recovery Plans. Ist beispielsweise nicht mehr genügend Speicherplatz für ein neues Backup vorhanden, dann befinde ich mich sehr schnell außerhalb der definierten SLAs, weil das RPO nicht mehr eingehalten werden kann. Folgende Punkte müsse für die Kapazitätsplanung berücksichtigt werden:

  1. Wie sichere ich?
    • Full Backup (alles wird zum eingestellten Zeitpunkt gesichert)
    • Differential (nur Änderungen seit dem letzten Full oder Differential werden gesichert)
    • Incremental (nur Änderungen seit dem letzten Full, Differential oder Incremental werden gesichert)
  2. Wie häufig sichere ich?
    • Es ist wichtig zu klären, in welchen Zyklen ich sichere. Ein Zyklus zählt von einem Full Backup zum nächsten. Legen Sie also fest, wie häufig Full Backups durchgeführt werden sollen und welche Art Backups (DIFF oder INCR) Sie dazwischen nutzen möchten.
  3. Wie lange halte ich die Sicherungen vor?
    • Dies hängt von Ihren Unternehmensvorgaben ab, bis zu welchem Zeitpunkt in die Vergangenheit Sie in der Lage sein müssen, Daten wieder herzustellen. Muss es z.B. möglich sein, Dateien wieder auf einen Zustand von vor 45 Tagen zu bringen, dann müssen die dazugehörigen Backups auch mindestens 45 Tage aufbewahrt werden.
  4. Wie hoch ist die Änderungsrate meiner Inhalte?
    • Durchschnittlich kann angenommen werden, dass sich 10% meines Datenbestandes pro Woche ändert. Dies kann aber in Ihrem Szenario auch deutlich mehr oder weniger sein. Auch dies muss für die Kapazitätsplanung geklärt werden.

Basierend auf obigen Annahmen und Erfahrungen bei Kunden kann folgende Allgemein-Regel angwendet werden:

Benötigter Speicherplatz = 1,5 x D x Z + D

D: Datenbestand der gesamten Farm (inkl. Service Datenbanken, etc.)
Z: Anzahl der Backup-Zyklen, die vorgehalten werden sollen

Wenn Sie diese drei Kategorien von heute berherzigen und Sie auf Ihr Unternehmen anwenden, sind Sie bereits sehr gut aufgestellt für das Durchführen von Backups. Damit haben Sie die „halbe Miete“. Noch wichtiger ist jedoch der Wiederherstellungsfall. Dies muss ebenso Teil eines Disaster Recovery Plans sein, was wir uns morgen als finalen Abschluss des SharePoint Adventskalenders genauer anschauen werden.

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Request Management Service

SharePoint Adventskalender – 17. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Bei dem heutigen Thema schauen wir uns einen weniger bekannten Service an, der jedoch sehr interessante Funktionen für uns bereit hält. Die Rede ist vom Request Management Service. Dies ist eine Art Load Balancer hinter dem Load Balancer. Damit kann SharePoint selber bei ankommenden Anfragen entscheiden, ob wirklich der vom Load Balancer zugewiesene WFE die Anfrage bearbeitet, oder ob noch einmal zu einem anderen WFE geroutet wird.

Ein Load Blanacer, wie der F5, arbeitet für ein Netzwerk-Load-Balancing während das Request Management (RM) auf Application-Eben die Last verteilt. Dazu können Throttling Regeln zum „bremsen“ und Routing Regeln zum priorisieren verwendet werden. Der Service ist standardmäßig ausgeschaltet, aber kann pro Web Application über PowerShell konfiguriert werden.

Funktionsweise:
Jedem Server kann über PowerShell ein statischer „Health“-Wert gesetzt werden. Zusätzlich prüft SharePoint alle 5 Sekunden die dynamische „Health“ jedes WFE Servers. Die Skala geht von 0 („am gesündesten“) bis 10. Bekommt ein Server drei mal hintereinander den Wert 10 (z.B. weniger als 20 MB RAM verfügbar), drosselt das RM die Anfragen auf diesem Server. Damit kann verhindert werden, dass ein Routing vom Load Balancer zu einem hängenden Server keine Fehlermeldung beim Endnutzer generiert. Stattdessen wird die Anfrage neu geroutet. Der Request Service fungiert praktisch als Proxy und erstellt eine neue Anfrage, die der alten zwar gleicht, jedoch zu einem neuen WFE geht.

Ablauf:

Zunächst kommt eine Abfrage vom Endnutzer oder vom Load Balancer am SharePoint an.

  1. Dieser evaluiert den Request anhand definierter Regeln. Diese können Eigenschaften (Url, UrlReferrer, UserAgent, Host, IP, HttpMethod, SoapAction, CustomHeader) oder Methoden (StartsWith, EndsWith, Equals, RegEx) überprüfen.
  2. Mögliche Server werden anhand der Regelkriterien und/oder der Server-Gesundheit identifiziert (siehe Bild unten)
  3. Nach Identifizierung des Servers wird der Request dorthin geroutet (bzw. gebremst, bei Throttling Regel).

Regeln werden innerhalb von drei Gruppen (Execution Groups 0 bis 2) zusammengefasst und entsprechend priorisiert. Diese Gruppen repräsentieren Servergruppen, zu denen geroutet werden soll.

  1. Gruppe 0 wird als erste geprüft.
  2. Gibt es keinen Match, werden die Regeln von Gruppe 1 geprüft.
  3. Gibt es ein Match, werden alle Regeln einer niedrigeren Priorität (Execution Group 2) verworfen und der Request direkt bearbeitet.

Gäbe es auch in Gruppe 2 keinen Match, dann wird der Request zu irgendeinem Server geleitet – aber nur dann, wenn ich mindestens in die letzte Gruppe auch eine Art „Catch-All“ Regel definiere, die alle nicht geregelten Anfragen abarbeitet (sollten keine weiteren „freien“ WFE außerhalb der Execution Gruppen existieren).

Vorteile:

  • Ablehnen gefährlicher Anfragen (z.B. von bestimmten Quellen)
  • Priorisieren von Anfragen basierend auf Server-Health und Regeln (z. B OneNote Verkehr immer über Server1; Search Crawler immer auf Server4; neuere Server mit mehr Resourcen können mehr Anfragen übernehmen, etc.)
  • Anfragen können „umgeschrieben“ werden mit beispielsweise sogar einem anderen Port
  • Traffic Isolierung zur Fehleranalyse (z.B. von einer bestimmten Site Collection zu einem bestimmten Server)
  • Regeln kann man auch ein Ablaufdatum mitgeben, sodass spezielle Routings automatisch enden

Nachteile:

  • Zusätzliche Last auf den WFE-Servern durch den RM Service
    Oder besser: Den RM Service auf einem dedizierten Server laufen lassen, z.B. gemeinsam mit einem Distributed Cache Service

Beispiele:

Erstellen einer Routing Regel, um alle Anfragen für Word Dokumente für Web Application http://intranet.contoso.com zum WFE „Server1“ zu leiten.

  1. Request Manager Service auf den WFEs aktivieren:
    1. Central Administration im Browser öffnen
    2. Zu Manage Services navigieren
    3. Request Management Service starten
  2. Scope der Web Application referenzieren
    • $WebApp = Get-SPWebApplication -identity http://intranet.contoso.com
  3. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  4. Erstellen eines neuen Filter-Kriteriumsmit der “Url” Eigenschaft und RegEx für alle Dokumente vom Typ DOCX
    • $Krit = New-SPRequestManagementRuleCriteria -Property Url -Value „.*\.docx“ -MatchType Regex
  5. Sollte dies die erste Regel sein, die wir erstellt haben, müssen wir auch einen Server-Pool erstellen, zu dem diese Anfragen geroutet werden sollen.
    • $Pool = Add-SPRoutingMachinePool -RequestManagementSettings $RM -Name AdventsPool -MachineTargets ($RM | Get-SPRoutingMachineInfo -Name Server1)
  6. Nun kann die Routing-Regel mit obigen Server-Pool und Filter-Kriterium angelegt werden
    • $RM | Add-SPRoutingRule -Name „DOCX Regel“ -Criteria $Krit -MachinePool $Pool
  7. Fertig und testen! (ULSViewer is your friend…)

Erstellen einer Throttling Regel, um Anfragen von OneNote auf die Web Application http://intranet.contoso.com zu bremsen, wenn der Health-Wert 8 ist.

  1. Scope der Web Application referenzieren
    • $WebApp = Get-SPWebApplication -identity http://intranet.contoso.com
  2. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  3. Hinzufügen eines neuen Kriteriums für OneNote 2010 Anfragen. Dies kann über den UserAgent im Request realisiert werden.
    • $Krit = New-SPRequestManagementRuleCriteria -Property UserAgent -Value „.*Microsoft Office OneNote 2010*“ -MatchType Regex
  4. Nun fügen wir die Throttling Regel für die Server-Health 8 hinzu.
    *Hinweis: Throttling Regeln gelten im Gegensatz zu Routing Regeln für die gesamte Farm und nicht für einzelne Server(-Pools). Daher müssen wir hier keinen Server-Pool mit angeben.

    • $RM | Add-SPThrottlingRule -Name „OneNote Throttle Rule“ -Criteria $Krit –Threshold 8

Viel Spaß beim „SharePointen“

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Distributed Cache Service

SharePoint Adventskalender – 16. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Heute wenden wir uns dem in SharePoint 2013 neu eingeführten Distributed Cache Service zu. Dieser basiert auf dem „AppFabric Distributed Caching“ Dienst, der unter der Windows Service Konsole läuft. Er wurde dazu konzipiert, unter anderem Authentifizierungs-Tokens vom Security Token Service (STS) für den „sozialen“ Teil der MySite zu speichern. Diese zwischengespeicherten Daten sind über alle Cache-Server verteilt.

Der Vorteil dieser Technologie ist, dass Daten schnell aus dem Cache geladen werden können. Die Nachteile:

  1. Die Daten sind leider genau so alt, wie die letzte „Cache-Fütterung“. Nämlich der Timer Job mit dem Namen “User Profile Service – Feed Cache Repopulation Job” ist dafür zuständig, den Cache mit aktuellen Feeds zu füttern. Unabnhängig davon wird dieser Vorgang auch immer dann getriggert, wenn auf entsprechende Seiten zugegriffen wird. Gehe ich also auf meine MySite, so wird diese schnell aus dem Cache gerendert. Aber im Hintergrund fragt SharePoint erneut an, ob denn nicht schon aktuellere Daten für die Feeds vorhanden sind. Ist dies der Fall, wird der Cache damit versorgt und bei einem Refresh, bzw. beim nächsten Aufruf der MySite, werden dann eben diese aktualisierten Cache-Daten gerendert. Hinweis: Der Feed-Cache Timer Job läuft zusätzlich alle 5 Minuten nach Standardeinstellung.
  2. Geht ein Cache Server vom Netz, fehlen die dort gespeicherten Daten und müssen erst erneut geladen werden. Den Nachladeprozess all dieser Daten kann man folgendermaßen beschleunigen:
  • Den User Profile Service – Feed Cache Repopulation Job manuell starten oder
  • Folgende PowerShell-Befehle verwenden:
    – Clear-SPDistributedCacheItem
    – Update-SPRepopulateMicroblogLMTCache
    – Update-SPRepopulateMicroblogFeedCache

Sollte einmal bewusst geplant sein, einen solchen Server vom Netz zu nehmen, kann man auch pro-aktiv die gespeicherten Daten auf die anderen Server verteilen:

  • Stop-SPDistributedCacheServiceInstance -Graceful

Infrastrukturplanung:
Zu jeder SharePoint Farm muss auch mindestens ein Cache Host existieren, also ein Server, der den Distributed Cache Service hosted. Der – bzw. in einer größeren Farm mindestens ein – Cache Service sollte auch auf dem gleichen Server laufen, wo die User Profile Application (UPA) läuft. Andernfalls kann es vorkommen, dass sich der oben erwähnte “User Profile Service – Feed Cache Repopulation Job” nicht mit der UPA verbinden kann.

Zudem sollten Sie bei Farmen mit mehr als vier Servern explizit den Distributed Cache Service auf einem oder mehr Servern stoppen. Eine Verteilung von Cache-Daten auf zu viele verschiedene Server würde nämlich im Endeffekt die Performance negativ beeinflussen.

Weiterhin gibt es zur Planung des Distributed Cache Service folgendes zu beachten. Jeder Cache Server benötigt etwa 50% seiner Leistung für einen sogenannten RAM-Speicher-Overhead. Also administrative Aufgaben, um die tatsächlich gecachten Informationen zu verwalten. Damit wird empfohlen, Server mit maximal 16 GB RAM als Cache Server zu hosten. Prinzipiell sind auch größere Speicher möglich, aber durch den Overhead würde es bei einem Cache-Flushing so wirken, als sei der Server „eingefroren“. Dies ist nicht optimal für die „Nutzererfahrung“.

Neben den max. 16 GB RAM sollten auch etwa 2 GB für das Betriebssystem reserviert werden. Als Grundlage haben wir somit 14 GB für den Cache, wovon die eine Hälfte (7 GB) tatsächlich für den Cache und die andere Häfte für den administrativen Overhead genutzt werden soll. Somit teilen wir die gesamte benötigte Cache-Kapazität durch 7 und erhalten die Anzahl für die benötigten Cache Server.

Cache Bedarf / 7 GB = Anzahl nötiger Cache Server

Den Cache Bedarf gibt Microsoft anhand der Nutzer pro Farm mit folgender Tabelle an:

Bereitstellungsgröße Kleine Farm Mittlere Farm Große Farm
Gesamtzahl der Benutzer < 10.000 < 100.000 < 500.000
Empfohlene Cachegröße für den verteilten Cachedienst 1 GB 2,5 GB 12 GB
Gesamtspeicherzuordnung für den verteilten Cachedienst (doppelter Wert der oben empfohlenen Cachegröße, plus Reserve von 2 GB für das Betriebssystem) 2 GB 5 GB 34 GB
Empfohlene Architekturkonfiguration Dedizierter Server oder auf einem Front-End-Server Dedizierter Server Dedizierter Server
Mindestanzahl von Cachehosts pro Farm 1 1 2

Quelle: https://technet.microsoft.com/de-de/library/jj219572.aspx

Berechtigungen:
Weiterhin zu beachten ist die Berechtigung des Service Acconts, unter dem der Distributed Cache Service läuft. Ähnlich wie beim User Profile Service sind temporär erhöhte Berechtigungen (Local Admin) für das Einrichten erforderlich, um die Tokens vom STS ziehen zu können. Danach können diese Berechtigungen wieder genommen werden. Da es beispielsweise hin und wieder vorkommt, dass der Service neu gestartet werden muss oder andere administrative Eingriffe erforderlich sind, empfehle ich, die erhöhten Berechtigungen dauerhaft zu belassen. Dies widerspricht zwar dem „Least-Privilege“ Ansatz von Microsoft, erleichtert aber die Administration und Fehelerbehebung im Störungsfall.

Viel Spaß beim „SharePointen“

Hinweis:
– Die MySite wurde von Microsoft wieder abgekündigt und wird in O365 bereits durch Delve ersetzt.
– Weitere Informationen zum Distributed Cache Service finden Sie hier: https://technet.microsoft.com/de-de/library/jj219613.aspx?f=255&MSPPError=-2147217396

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Super User und Super Reader

SharePoint Adventskalender – 15. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Besondere Funktionen erfordern besondere Einstellungen. Bei einem Feature ist das besonders wichtig. Die Rede ist von dem „SharePoint Server Publishing Infrastructure“ Feature oder auf deutsch, der „SharePoint Server-Veröffentlichungsinfrastruktur“.

Was ist an dieser Funktionalität so besonders? Die Veröffentlichungsinfrastruktur ist dazu gedacht, den SharePoint auch dafür zu nutzen, um reine Intranet- oder sogar Internetseiten zu hosten. Wichtig dabei ist, dass der Inhalt stets auf dem aktuellen Stand ist. Für Aktualisierungen werden von Dateien (Seiten) Zwischenversionen erstellt. Die Änderungen werden erst nach Veröffentlich einer neuen Hauptversion für alle Nutzer sichtbar. Dies ist natürlich auch für normale Kollaborationsszenarien denkbar, aber der Hauptfokus dieses Features liegt auf dem Veröffentlichen von Intranet- oder Internetseiten.

Das wichtigste Kriterium für eine erfolgreiche Intranetpräsenz ist ein schneller Seitenaufbau. Die Veröffentlichungsinfrastruktur nutzt dafür einen dedizierten Objekt-Cache. Wenn nun jeder Besucher durch den Aufruf einer entsprechenden Seite eine Anfrage an den SQL sendet, muss dieser auch jede einzelne bedienen. Erst bei jeder zweiten Anfrage der gleichen Seite würde der Cache tatsächlich greifen. Und dies gilt nun für jeden einzelnen Nutzer. Die Last auf dem SQL ist somit hoch und die Performance dadurch nicht optimal. Außerdem wächst der Cache schnell an, weil Dateien theoretisch doppelt und dreifach zwischengespeichert werden müssten.

Die Lösung liefern der Super User und der Super Reader Account. Bei einem Seitenaufruf werden so nur zwei Anfragen im jeweiligen Kontext der beiden Nutzer an den SQL gesendet. Der Super User („Full Control“) bekommt als Ergebnis auf diese Abfrage alle Entwürfe von Dateien, also die Zwischenversionen. Der Super Reader („Full Read“) bekommt alle veröffentlichten Versionen. Die Dateien aus beiden Abfragen landen im Cache. Für den eigentlichen Endnutzer werden dann die Berechtigungen aus den Zugriffssteuerungslisten (Acces Control List – ACL) geladen und dementsprechend nur die Informationen (aus dem Cache) gerendert und angezeigt, die er mit seinen Berechtigungen sehen darf. Der Vorteil dieses Verfahrens ist der schnelle Cache und es müssen nur die Ergebnisse für zwei Anfragen darin gespeichert werden. Dies ist also eine Performance- und Cache-Speicheroptimierung.

Nun kann es aber bei der Verwendung der Standardeinstellungen, nämlich des Systemkontos einer Website als „Portal Super User“ und des „NT Authority\Local Service“ als „Portal Super Reader“, zu Problemen kommen. Kurz: mit dem Systemkonto als „Portal Super User“ kann es zu Performance-Einbußen kommen, da hierbei manche „Entwurfsdateien“ doppelt abgefragt werden müssen. Da der „Local Service“ hingegen nicht explizit auf die jeweiligen veröffentlichten Seiten berechtigt ist, bekommt auch der Endnutzer eine Zugriffsverweigerung. Eine detailliertere Beschreibung finden Sie hier: https://technet.microsoft.com/de-de/library/ff758656.aspx)

Worauf ich aber eigentlich hinaus möchte, das ist die Authentifizierungsmethode. Microsoft änderte diese von SharePoint 2010 (Classic) zu SharePoint 2013 (Claims). Nun migrieren wir in SP2013 eine Classic-WebApplication zu Claims.

Convert-SPWebApplication -Identity „http://YourWebApp:80“ -To Claims -RetainPermissions -Force

Dies migriert auch alle berechtigten Benutzer dieser WebApplication zu Claims. Dennoch bekommen anschließend alle Nutzer – inklusive der Administratoren – einen „Zugang verweigert“ beim Zugriff auf die Seite. Besonders bei öffentlichen Seiten macht dies sehr viel „Spaß“.

Der Hintergrund ist einfach, dass bei der Classic zu Claims Migrations, auch inklusive der Benutzer, eben nicht der Super User und Super Reader mitgenommen werden. Diese verbleiben mit ihrem Classic Account und können sich daher nicht mehr authentifizieren. Sie müssen daher diese Konten erneut mit ihrer Claims-Nutzerkennung anlegen, um das Problem zu lösen. Bitte denken Sie auch daran, wenn Sie Farmlösungen oder ähnliche Programme nutzen, dass diese entsprechend mitgenommen werden müssen und sich in Zukunft über Claims authentifizieren.

Der Vollständigkeit halber hier noch die PowerShell Befehle, um die User mit Windows-Claims anzulegen:

$webapp = Get-SPWebApplication “http://WebAppURL”
$webapp.Properties[“portalsuperuseraccount”] = “i:0#.w|domain\SuperUser”
$webapp.Properties[“portalsuperreaderaccount”] = “i:0#.w|domain\SuperReader”
$webapp.Update()

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – Benamte SQL Instanzen und dedizierte Ports

SharePoint Adventskalender – 14. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Bei der Installation von SQL kann man sicherlich auch die Standardinstanz ohne eigenen Namen und mit dem Standard TCP/IP Port 1433 verwenden, aber dies ist nicht praktikabel und auch nicht zu empfehlen für produktive Systeme. Schon allein, wenn mehr als eine Instanz auf einem SQL laufen sollen, muss logischerweise mindestens ein Name oder ein anderer dedizierter Port vergeben werden. Zudem können Sie mit dedizierten Namen Ihre Infrastruktur besser verwalten und überblicken. Neben der einfacheren Verwaltung spielt in diesem Kontext aber auch die Sicherheit der Infrastruktur eine Rolle.

Sicherheit:

Da Port 1433 der Standardport ist, wird dieser gern von Hackern als einer der ersten abgefragt, um Zugriff auf die Datenbanken zu erhalten. Es ist daher ratsam, der Instanz einen dedizierten Port zu vergeben, der nicht 1433 ist.

Verwaltbarkeit:

Für SQL können dynamische Ports verwendet werden, sodass wir uns nicht auf einen festlegen müssen. Der Nachteil liegt aber auf der Hand. Eine Firewall-Konfiguration anhand von Ports wird dadurch nahezu unmöglich. Sollte nämlich nach einem Restart der Instanz ein neuer Port vergeben werdnen, weil der vorherige einem anderen Service mit dynamischer Portvergabe zugewiesen wurde, so kann im schlimmsten Falle der SharePoint (weiterhin) nicht verfügbar sein. Der Grund ist, der neue Port wurde vermutlich noch nicht in der Firewall geöffnet. Empfehlenswert ist hierbei eine Firewall-Regel, die programmbasiert ankommende Verbindungen am SQL erlaubt. Dafür müssen Sie aber auch alle Programme kennen, die auf den SQL zugreifen können und dürfen. Dies kann umständlich sein, weshalb ich daher empfehle, einen festen Port zu wählen und die Firewall entsprechend zu konfigurieren.

Denken Sie auch daran, dass Sie bei benamten Instanzen auch den Port 1434 für das UDP Protokoll öffnen – unabhängig davon, ob Sie fixe oder dynamische Ports nutzen. Warum ist das so? Nur bei nicht benamten Standard-Instanzen hört der SQL Server selbst auf Port 1433. Bei allen anderen Szenarien hört der SQL Browser Service auf ankommende Verbindungen und weist diesen dann die jeweiligen dynamischen oder fixen Ports zu. Erst danach kommt die Verbindung am tatsächlichen Port an, auf den die SQL Instanz hört. Logischer Weise muss dafür auch immer der SQL Browser Service laufen, da sonst die ankommenden Verbindung nicht zugewiesen werden können.

Im SQL Konfigurationsmanager empfehle ich daher, den fixen Port für die TCP/IP Konfiguration zu setzen und den Dynamischen Port komplett zu löschen (also auch den standardmäßig hinterlegten Wert „0“ zu entfernen, wie im Screenshot zu sehen ist). Achten Sie auch darauf, dass Sie den Port für den Alias im Konfigurationsmanager oder über das cliconfg.exe Tool korrekt setzen.

Ist dies alles erledigt, so ist auch die Firewall-Konfiguration ein leichtes Spiel und schließt die SQL Instanz- und Portkonfiguration ab.

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen:

SharePoint Configuration Best Practices – SQL Alias

SharePoint Adventskalender – 13. Türchen

Performance Tuning – Performance Monitoring – Best-Practices für SP-SQL-Konfigurationen – BLOB Management – Backup & Recovery

————————————————————-

Einen fröhlichen 3. Advent wünsche ich! Die tief technischen Tipps für eine optimierte SharePoint Performance haben wir nun hinter uns gebracht. Heute und in den nächsten Tagen widmen wir uns ein paar Best Practices in Hinblick auf die Konfiguration von SharePoint und SQL.

Beginnen wir mit einem einfachen Tipp – der SQL Alias. Wie wir wissen, gehört SharePoint und SQL einfach zusammen. Daher muss SharePoint immer wissen, wo sich seine Datenbanken befinden. Diese Referenz wird bei einer benamten Instanz mit „Servername\Instanzname“ angegeben. In einem SQL Cluster referenzieren wir natürlich den virtuellen Hauptknoten der verschiedenen SQL Nodes und den „Windows Listener“ bei einer SQL Always-On-Availability-Group.

Der Vorteil eines Alias ist die Möglichkeit, dass ich das Backend ändern kann, ohne große Konfigurationen am Frontend vornehmen zu müssen. Ist besipielsweise der SQL zu langsam geworden und soll auf einen neuen Server und/oder auf eine neue Instanz, dann muss ich nicht für jede Inhaltsdatenbank und jeden Service in SharePoint die neue Referenz setzen. Stattdessen passe ich nur einmalig den Alias an. Auch eine Änderung des Ports kann so ganz einfach erledigt werden.

Bitte achten Sie auch darauf, sollten Sie noch Systeme im 32bit-Modus haben, dass Sie den Alias sowohl für diese, also auch für die 64bit-Systeme setzen. Das Windows Tool „cliconfg.exe“ setzt für Sie den Alias. Dieses Tool finden Sie hier:

32bit-Mode:
C:\Windows\System32\cliconfg.exe
64bit-Mode:

C:\Windows\SysWOW64\cliconfg.exe

Ob die Einstellungen korrekt am System “angekommen” sind, können Sie in der Registry in folgenden Pfaden überprüfen:

32bit-Mode:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo
64bit-Mode:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo

Achten Sie außerdem darauf, dass Sie diese Einstellungen ebenso auf dem SQL machen, um sich auch von dort lokal mit einem Alias im SQL Management Studio mit der jeweilige Instanz verbinden zu können – dies können Sie auch direkt im SQL Configuration Manager erledigen.

Zusammengefasst ist so ein Alias also ein extrem nützliches Werkzeug, um mögliche spätere Server-, Instanz- oder Portänderungen ohne viel Konfigurationsaufwand am zugehörigen SharePoint erledigen zu können.

Viel Spaß beim „SharePointen“!

————————————————————-

Weitere Türchen: