.msg Dateien in einer SharePoint Dokumentenbibliothek mit Outlook öffnen

Eine neue Installation von SharePoint ist nicht unmittelbar in der Lage E-Mails, welche im Format .msg gespeichert wurde, direkt in Outlook zu öffnen. Stattdessen erhält man beim Öffnen der Datei nur die Option zum Speichern angeboten. Dieses Verhalten wird durch die Einstellungen des Browser File Handling in SharePoint gesteuert. Diese Einstellungen sind immer für eine WebApplication gültig und müssen daher ggf. in mehreren WebApplications vorgenommen werden.

Es gibt zwei Methoden die Einstellungen des Browser File Handling zu verändern. Mit der Einstellung „Strict“ werden MIME Typen, welche nicht in der SharePoint Property „AllowedInlineDownloadedMimeTypes“ eingetragen sind, nicht im Browser dargestellt und müssen heruntergeladen werden. Mit der Einstellung „Permissive“ wird es jedem nicht registrierten MIME Typ erlaubt, im Browser dargestellt zu werden.

Die Quick & Dirty Methode

Als Softwareentwickler will man so schnell wie möglich die IDE anwerfen und den ersten Proof of Concept fertigstellen. Leider führt dieser Drang auch dazu, dass die eigene Entwicklungsumgebung nicht so konfiguriert ist, wie es vielleicht der IT-Professional täte. Daher auch die Bezeichnung als Quick & Dirty.
Diese Methode geht sehr einfach an das Problem ran, in dem es die Standard Einstellung von Strict auf Permissive ändert. Für diese Einstellung gibt es aber eigentlich keinen Grund, da hiermit die Sicherheit von SharePoint geschwächt wird. Es sollte daher immer die sichere Methode den Vorzug gegeben werden. Dazu gleich mehr.

•    In der Zentraladministration unter dem Bereich Application Management den Punkt Manage Web Applications auswählen.
•    Die Web Application auswählen die konfiguriert werden soll.
•    Im Ribbon Menü den Punkt General Settings auswählen
•    Bis zur Einstellung Browser File Handling scrollen und die Einstellung auf Permissive ändern.

Nach Änderung Web Application Einstellungen muss noch der verknüpfte Application Pool recycled werden. Alternativ kann auch ein iisreset.exe /noforce ausführen.

Die sichere Methode

In einer Produktionsumgebung will man den Server möglichst Sicher betreiben. Daher ist es möglich die Einstellung für das Browser file handling auf Strict zu belassen und stattdessen den MIME Type zu registrieren. Hierfür sind zwei Schritte notwendig.

Als erstes muss der MIME Type im IIS registriert werden:

•    Start der Internet Information Manager Konsole
•    Den Server der Konfiguriert werden soll in der linken Spalte auswählen
Die Einstellung kann entweder für den ganzen Server oder nur für eine Web Application vorgenommen werden.
•    Die Einstellung für die MIME Typen öffnen und ein neues hinzufügen
•    Bei „File name extension“ die Endung .msg eintragen
Den Punkt vor der Endung mit angeben
•    Bei „MIME Type“ den Wert application/vnd.ms-outlook eintragen

Die Einstellungen müssen auf allen Web Frontend Servern in der SharePoint Farm vorgenommen werden.

Als nächsten Schritt muss man mittels der Powershell die Dateiendung .msg der Eigenschaften der Web Application hinzufügen. Am besten ist es man erstellt sich hierfür ein kleines Skript. Diese Einstellungen muss dann nur auf einem der Server in der Farm ausgeführt

$web = Get-SPWebApplication http://<eigene WebApplication eintragen>
If ($web.AllowedInlineDownloadedMimeTypes -notcontains "application/vnd.ms-outlook")
{
    $web.AllowedInlineDownloadedMimeTypes.Add("application/vnd.ms-outlook")
    $web.Update()
}

Als letztes werden alle Web Frontend Server über iisreset.exe /noforce neu gestartet.

Keine Verbindung mit dem SharePoint Administration Service - Windows Event ID 6398

Das Leben mit SharePoint ist immer spannend und abwechslungsreich. Das merkt man vor allem daran, dass man bei der Arbeit immer wieder mit Fehlern konfrontiert wird, welche man so noch nicht kannte. Vor allem dann, wenn die Fehlerbeschreibung einen erst einmal auf die falsche Fährte lockt.
Bei einem meiner Kunden habe ich im Windows Event Log folgenden Fehler vorgefunden:

Log Name:	Application
Source:	Microsoft-SharePoint Products-SharePoint Foundation
Date:	16.04.2013 05:10:30
Event ID:	6398
Task Category:	Timer
Level:	Critical
Keywords:
User:	Farm account
Computer:	Only for me to know ;)
Description:	The Execute method of job definition Microsoft.SharePoint.Administration.SPTimerRecycleJobDefinition (ID dd6757f2-1684-4834-b419-8dafc87cdffc) threw an exception. More information is included below. This operation uses the SharePoint Administration service (spadminV4), which could not be contacted.  If the service is stopped or disabled, start it and try the operation again.

Wie sich herausstellte, wurden auf dem SharePoint Server, auf dem auch der Microsoft Project Server installiert wurde, die Content Datenbanken und die Project Server Datenbanken, mittels des SQL Servers, wieder hergestellt. Dabei wurden die Datenbanken in die Farm eingespielt, ohne vorher den SharePoint Timer Service anzuhalten.

Nach einigem Suchen, habe ich schließlich ein Beitrag im Microsoft Forum gefunden, welcher genau mein Problem beschrieben hat. Leider gibt es im Netz eine Vielzahl verschiedener Ursachen für den Event Eintrag 6398. In meinem Fall hat es sich herausgestellt, dass durch das Wiederherstellen des Backups ein Timer Job zurückgeblieben ist, welches die Probleme verursachte. Mit folgendem Powershell Skript konnte ich schließlich den Timer Job isolieren und löschen.

PS C:\> $job = Get-SPTimerJob | where {$_.DisplayName -eq $null} PS C:\> $job Name                 Schedule             Last Run ----                 --------             -------- PWASSP_bd110576-8... daily between 00:... 01.01.0001 00:00:00 PS C:\> $job.Description Project Server Shared Timer Job PS C:\> $job.Delete()

Nachdem ich den alten Timer Job gelöscht hatte, konnte ich wieder auf die Liste der Timer Job zugreifen und die Fehler sind nicht mehr im Windows Event Log aufgetreten.

Ermitteln der IO Leistungsfähigkeit eines Windows Servers

Für den Betrieb einer SharePoint Farm ist ein funktionierender Microsoft SQL Server unabdingbar. Ohne geht es nicht. Deshalb bin ich der Meinung, dass es für uns Administratoren wichtig ist sich mit den Grundlagen des SQL Server vertraut zu machen. Wer einen DBA im Haus hat, der ihm die Arbeit abnimmt, ist an dieser Stelle fein raus ;) Der folgende Beitrag richtet sich daher vor allem an SharePoint Administratoren, die keinen SQL Speziallisten zur Hand haben.

Über die Installation und Konfiguration des Servers gibt es ausreichende Informationen. Sei es auf den TechNet Seiten, in Blogs, Zeitschriften oder Bücher. Eine Situation die ich aber häufiger einmal antreffe ist, dass das Thema Performance der SharePoint Farm viel zu spät oder gar nicht betrachtet wird. Da bei einer SharePoint Farm die Leistungsfähigkeit des SQL Clusters, im besonderen die der Festplatten, maßgeblich die Leistungsfähigkeit der SharePoint Farm beeinflusst, lohn es sich in jedem Fall hier zu Überprüfen ob alles so ist wie es sein soll.

Natürlich gibt es bei einer SharePoint Farm noch eine ganze Reihe weiterer Stellschrauben um die Performance zu verbessern. Ziel in diesem Beitrag soll es aber sein, die IO Leistung der Festplatten im SQL Server zu ermitteln. Dazu muss auf den Servern ein Last-Test durchführen und die durchschnittlichen Lese- und Schreibegeschwindigkeit, die IOPS Leistung und Latenz erfasst werden.

Überwachung der Leistungswerte

Warum ist es aber für den späteren Betrieb wichtig diese Werte im Vorfeld zu erfassen und zu dokumentieren? Bei der Überwachung eines Servers kann die Überwachung in zwei Kategorien unterteilt werden:

• Reaktiv
• Progressiv

Bei der reaktiven Überwachung wird auf die Änderung eines Indikators reagiert und z.B. eine Benachrichtigung versendet. Icinga ist so eine Lösung. Dabei werden in festgelegten Intervallen ein oder mehrere Dienste überwacht. Wenn sich dieser dann außerhalb der vordefinierten Parameter bewegt, wird Alarm ausgelöst.

Auf der anderen Seite haben wir die progressive Überwachung. Progressiv bedeutet in diesem Fall nicht, dass die Werte in der Überwachung immer weiter steigen, sondern der Begriff bezieht sich auf den zeitlichen Verlauf der Überwachung, also der fortlaufenden Überwachung. Dabei werden verschiedene Leistungswerte eines Servers langfristig protokolliert. Dies wird gemacht um langfristige Trends des Servers erfassen zu können. Die Windows Leistung Sammelungssätze sind ein sehr gutes Beispiel hierfür. Erst durch die Langzeiterfassung können wir erkennen potenzielle Probleme erkennen, dass z.B. die Netzwerkschnittstelle über Monate hinweg immer mehr und mehr Daten transportieren muss und bald die Kapazitätsgrenze erreicht ist.

Nun ist die Leistungsgrenze einer Netzwerkkarte verhältnismäßig  einfach zu ermitteln, da sich diese errechnen lässt. Eine 1Gbit/s Karte wird im Schnitt nicht mehr als 100MB/s transportieren können. Wie sieht es aber bei den Laufwerken aus. Auch hier könnten wir anhand der Datenblätter des Herstellers des SAN bzw. der Platten ungefähr ausrechnen was unser System leisten kann. Bei einem Festplattenspeicher spielen aber noch viel mehr Faktoren eine Rolle, welche sich auf die Leistungsfähigkeit auswirken können. Es ist daher einfacher das System aufzubauen und dann die Gesamtleistung, im Rahmen eines Lasttests, zu erfassen. Diese Leistungsgrenze wird im Englischen auch als “Baseline” bezeichnet. Mit Hilfe der Baseline können wir also in Zukunft, bei der progressiven Überwachung der Server, feststellen ob unser System an seine Leistungsgrenze kommt.

Festlegen der Indikatoren

Um die Baseline erfassen zu können, müssen wir überhaupt erst einmal festlegen, welche Leistungswerte in Zukunft aussagekräftige Informationen über die Leistung unseres Servers bereitstellen. Die Werte ermitteln wir mit Hilfe des Windows Leistungsindikatoren. Wer noch nicht mit den Leistungsindikatoren gearbeitet hat, dem empfehle ich die Artikel zur Einrichtung im TechNet vorher durchzuarbeiten.

Erste Schritte mit der Leistungsüberwachung (http://technet.microsoft.com/de-de/library/dd744567(v=ws.10).aspx)

IOPS

Die Abkürzung IOPS steht für den englischen Begriff “Input/Output Operations” per Second. Diese Angabe beschreibt die Fähigkeit des Datenbusses Kommunikationsbefehle zwischen dem Betriebssystem und dem Speichermedium zu transportieren. Die Angabe für sich alleine ist noch nicht sehr aussagekräftig, denn es gibt viele verschiedene Faktoren die berücksichtigt werden müssen. Ein wesentlicher Faktor ist die Größe der übermittelten Datenblöcke, welche bei einer I/O Operation transportiert wird. Um z.B. 100 MB in 16 kB Blöcken zu übertragen, muss das System doppelt so viele IOPS ausführen als wenn 32 kB Blöcke verwendet werden.

Indikator	Beschreibung
Durchschnittl. Warteschlangenlängenlänge des Datenträgers-Lesend	Die durchschnittliche Anzahl der Leseanforderungen, die für den gewählten Datenträger während des Abtastintervalls in der Warteschlange aufgenommen wurden.
Durchschnittl. Warteschlangenlängenlänge des Datenträgers-Schreibend	Die durchschnittliche Anzahl der Schreibanforderungen, die für den gewählten Datenträger während des Abtastintervalls in der Warteschlange aufgenommen wurden.
Lesevorgänge/s	Die Rate von Lesevorgängen auf dem Datenträger.
Schreibvorgänge/s	Die Rate von Schreibvorgängen auf dem Datenträger.

Transportleistung

Mit der Transportleistung wird die Fähigkeit beschrieben eine Anzahl an Daten in einem Zeitraum zu transportieren. Diese Werte werden für gewöhnlich mit Bytes oder Megabyte  pro Sekunde angegeben.

Indikator	Beschreibung
Bytes gelesen/s	Die Rate, mit der Bytes während Lesevorgängen vom Datenträger übertragen werden.
Bytes geschrieben/s	Die Rate, mit der Bytes während Schreibvorgängen auf den Datenträger übertragen werden.
Mittlere Bytes/Lesevorgang	Die durchschnittliche Anzahl der Bytes, die während Lesevorgängen vom Datenträger übertragen wurden.
Mittlere Bytes/Schreibvorgang	Die durchschnittliche Anzahl der Bytes, die während Schreibvorgängen auf den Datenträger übertragen wurden.
Mittlere Sec./Lesevorgang	Die durchschnittliche Zeitdauer in Sekunden für das Lesen von Daten auf dem Datenträger.
Mittlere Sec./Schreibvorgang	Die durchschnittliche Zeitdauer in Sekunden für das Schreiben von Daten auf den Datenträger.
Teil-E/A/s	Gibt die Teilungsrate der E/As auf dem Datenträger an. Ein E/A kann geteilt werden, wenn Daten angefordert werden, die zu groß für einen einzelnen E/A sind oder wenn der Datenträger fragmentiert ist.

 

Andere relevante Messwerte

Zusätzlich zu den Indikatoren die sich mit dem Speicher System beschäftigen, ist es ratsam  auch die Indikatoren der CPU und ggf. der Netzwerkkarte zu Protokollieren. Bei der CPU interessieren uns vor allem die Prozessorzeit (%), die Menge der Interrupts/s und DPC in Warteschlange/s je Core. Bei intensiver Last der Speichermedien sollte die Prozessorzeit nicht sonderlich ansteigen. Dies könnte zum Beispiel beim Einsatz von iSCSI passieren, wenn der HBA kein TCP Off-Load unterstützt. Dann nämlich muss die CPU den zusätzlichen TCP/IP Overhead bearbeiten. Wenn iSCSI verwendet wird kann man die Netzwerkkarte, die mit dem Target verbunden ist, mit in die Überwachung aufnehmen.

SQLIO

Nachdem jetzt festgelegt wurde welche Werte wir ermitteln wollen, müssen wir uns noch Gedanken machen wie wir Last auf das System bringen. Microsoft bietet uns hierfür ein eigenes Tool an, welches auf den Downloadseiten kostenfrei heruntergeladen werden kann.

SQLIO Disk Subsystem Benchmark Tool (http://www.microsoft.com/en-us/download/details.aspx?id=20163)

Nachdem man SQLIO installiert hat, befindet sich im Programme-Verzeichnis ein neuer Ordner mit den Dateien. Da SQLIO von der Befehlszeile aus gestartet wird, öffnet man am besten eine neue Eingabeaufforderung und navigiert in das entsprechende Verzeichnis.

Parameter

Damit SQLIO funktionieren kann, müssen noch einige Parameter konfiguriert bzw. bei Start mitgegeben werden. Alle notwendigen Informationen, damit man brauchbare Ergebnisse erzielen kann, sind in der Datei readme.txt nachzulesen.

Da SQLIO immer nur ein Test zurzeit durchführen kann, muss man wenn unterschiedliche Parameter getestet werden sollen, den Vorgang mit einer Batchdatei automatisieren. Hierfür legt man am besten im Verzeichnis von SQLIO eine neue .bat Datei an und öffnet diese zum Bearbeiten. In jeder Zeile schreibt man dann die Parameter mit der man sein Test ausführen möchte. Beim Schreiben des Logs sollte man darauf achten, dass diese unterschiedliche Namen erhalten. SQLIO überschreibt die vorhandene Logdatei anstatt sie anzuhängen.

Beim festlegen der Größe der Testdatei, sollte man außerdem darauf achten, dass diese größer ist als der im SAN eingesetzte Cache. Grade beim sequenziellen Lesen der Data können sonst die Ergebnisse verfälscht werden.

...und Los

 Sobald die Windows Leistungsindikatoren konfiguriert sind und die Berichte aufgezeichnet werden, kann der SQLIO Batch gestartet werden. Das Ergebnis der Protokollierung kann zu kontrollzwecken ggf. ein zweites Mal gestartet werden. In jedem Fall sollte man die Leistungsdaten aufheben und in der Dokumentation des Servers protokollieren.

Fazit

Bevor eine neue SharePoint Farm in Betrieb genommen wird, sollte die Ermittlung der gesamten Leistungsfähigkeit des Datenspeichersystems erfolgen. Bei der Problemverfolgung, können diese Informationen dem Administrator helfen, zu verstehen wo ggf. ein Engpass vorliegt. Die Ermittlung der Leistungsfähigkeit kann mittels SQLIO, einem Tool von Microsoft, kostenfrei erfolgen.

Zusätzlich bietet der Einsatz von SQLIO die Möglichkeit, beim Server ein Burn-In Test durchzuführen. Dies sollte erfolgen, bevor Produktionsdaten eingespielt werden. Somit wird das Risiko gesenkt, fehlerhafte Festplatten zu verwenden.

Weitere interessante Artikel zum lesen:

• Benchmarking SQL Server IO with SQLIO


• SAN Performance Tuning with SQLIO


• THE SQL Server Blog Spot on the Web


• Disk Subsystem Performance Analysis for Windows