Log File Verzeichnisse aller IIS Sites per PowerShell anpassen

Standardmässig werden alle Logs des IIS auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk voll läuft und das OS somit zum Absturz gebracht wird.

Wie die IIS Logs für einzelne IIS Sites verschoben werden können, ist hier beschrieben: IIS Log Files (mittels PowerShell) verschieben

IIS Logs verschieben
Kopieren Sie nachstehenden Code in ein Textfile (z.B. Notepad) und ändern Sie den Pfad in der zweiten Zeile. Speichern Sie die Datei als PS1, indem Sie die Dateiendung von dateiname.txt auf dateiname.ps1 ändern. Führen Sie die Datei dateiname.ps1 auf dem Server, auf welchem die Log Files aller IIS Sites verschoben werden sollen, als Administrator aus.
Das Script erstellt unter dem angegebenen Pfad - in meinem Beispiel D:\Logs pro IIS Site ein gleichnamiges Verzeichnis. Anschliessend wird der Logpfad für jede IIS Site auf das jeweilige Verzeichnis angepasst. In diesem Beispiel wäre dies somit D:\Logs\SiteName

Import-Module WebAdministration
$LogPath = "D:\Logs"
foreach($site in (dir iis:\sites\*))
{
New-Item $LogPath\$($site.Name) -type directory
Set-ItemProperty IIS:\Sites\$($site.Name) -name logFile.directory -value "$LogPath\$($site.Name)"
}


SharePoint Trace- und Usage-Logs (mittels PowerShell) verschieben

Standardmässig werden alle Logs von SharePoint auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk vollläuft und das OS somit zum Absturz gebracht wird.

Die Logs können sehr einfach per PowerShell verschoben werden. Nachfolgende Befehle sind auf jedem SharePoint Server in der SharePoint 2010 Management Shell auszuführen.

Wie die IIS Logs verschoben werden können, ist hier beschrieben: IIS Log Files (mittels PowerShell) verschieben

Trace Logs verschieben
Die Trace Logs können via Central Administration > Monitoring > Reporting > Configure diagnostic logging verschoben werden, in dem im Abschnitt Trace Logs der Pfad geändert wird. In meinem Beispiel ist der neue Pfad D:\Logs\SharePoint\TraceLogs

Oder Sie führen in der SharePoint 2010 Management Shell folgenden Befehl aus:
Set-SPDiagnosticConfig -LogLocation "D:\Logs\SharePoint\TraceLogs"

Usage Logs verschieben
Die Usage Logs können via Central Administration > Monitoring > Reporting > Configure usage and health data collection verschoben werden, in dem im Abschnitt Usage Data Collection Settings der Pfad geändert wird. In meinem Beispiel ist der neue Pfad D:\Logs\SharePoint\UsageLogs

Oder Sie führen in der SharePoint 2010 Management Shell folgenden Befehl aus:
Set-SPUsageService -UsageLogLocation "D:\Logs\SharePoint\UsageLogs"


IIS Log Files (mittels PowerShell) verschieben

Standardmässig werden alle Logs des IIS auf dem Laufwerk C: abgelegt. Dies ist jedoch nicht empfehlenswert, weil dadurch einerseits Performance verloren geht (je nach Konfiguration) und andererseits besteht die Gefahr, dass das Systemlaufwerk voll läuft und das OS somit zum Absturz gebracht wird.

Wie die SharePoint Logs verschoben werden können, ist hier beschrieben: SharePoint Trace- und Usage-Logs (mittels PowerShell) verschieben

Die Logs können sehr einfach per PowerShell verschoben werden. Nachfolgende Befehle sind auf jedem SharePoint Server in der SharePoint 2010 Management Shell auszuführen.

IIS Logs verschieben
Navigieren Sie im Server Manager zu der IIS Site, für welche Sie die Log Files verschieben wollen. In meinem Beispiel: TechTask

Erstellen Sie am neuen Ort die Verzeichnisstruktur zum Ablegen der Log Files. In diesem Beispiel D:\Logs\IIS

Öffnen Sie die SharePoint 2010 Management Shell und setzen Sie folgenden Befehl ab:
Import-Module WebAdministration

Passen Sie den PowerShell Befehl zum Verschieben der IIS Logs an. Tragen Sie bei <Sitename> den Namen der IIS Site ein und ersetzen Sie <NeuerIISLogsPfad> durch den Pfad, unter welchem die IIS Log-Files künftig abgelegt werden sollen.
Set-ItemProperty "IIS:\Sites\<Sitename>" -name logFile.directory -value "<NeuerIISLogsPfad>"

In diesem Beispiel sieht der Befehl wie folgt aus:
Set-ItemProperty "IIS:\Sites\TechTask" -name logFile.directory -value "D:\Logs\IIS"

Unter Logging im Abschnitt IIS der entsprechenden IIS Site (in diesem Beispiel "TechTask") ist jetzt der neue Pfad für die IIS Log Files hinterlegt. Natürlich kann man auch einfach hier den neuen Pfad eintragen, anstelle von PowerShell...


The following connections failed to refresh: PowerPivot Data

Einer der häufigsten Fehler beim Setup von PowerPivot in SharePoint 2010 ist dieser hier:
The data connection uses Windows Authentication and user credentials could not be delegated. The following connections failed to refresh: PowerPivot Data

Dieses Problem tritt meistens dann auf, wenn SharePoint zur Nutzung der NTLM-Authentifizierung konfiguriert ist. Durch die Anfrage des Clients an den SharePoint Server, welcher wiederum den Reporting Server anfragt und sich authentifizieren muss, entsteht das klassische Double Hop Problem im Zusammenspiel mit NTLM. Eine ausführliche Erläuterung zu NTLM und Kerberos finden Sie hier.

Lösung 1 - Claims to Windows Token Service
Die einfachste Methode ist auf den SharePoint Servern, auf welchen die BI Services (PowerPivot, Excel Services,...) laufen, den Claims to Windows Token Service zu starten. Dadurch wird die Anfrage in eine Claims Identity umgewandelt, wodurch die Authentifizierung über mehrere Stellen ermöglicht wird.

So wird's gemacht
In der Central Administration klicken Sie auf System Settings > Servers > Manage services on server.
Starten Sie den Claims to Windows Token Service auf allen SharePoint Servern, welche einen BI Service (PowerPivot, Excel Services, Performance Point, Reporting Services,...) hosten. Um den Service auf einem anderen Server zu starten klicken Sie rechts oben auf das Server: Kästchen

Lösung 2 - Kerberos aktivieren
Die zweite Lösung wäre Kerberos auf der entsprechenden Web Application zu aktivieren. Diese Methode bietet einige Vorteile gegenüber NTLM (wie z.B. mehr Sicherheit, Delegation von Client Credentials, weniger Traffic), allerdings müssen dazu gewisse Anpassungen im Active Directory vorgenommen werden.
Eine ausführliche Anleitung zur Konfiguration von Kerberos finden Sie hier: Kerberos in einer SharePoint 2010 Umgebung konfigurieren


SharePoint 2010: Welcher load balanced Web Front-end zeigt den Inhalt?

Werden das Load Balancing für mehrere SharePoint Web Front-end Server konfiguriert, ist es oft nicht ganz einfach auf die Schnelle herauszufinden, welcher der Server einem gerade den angezeigten Inhalt zur Verfügung stellt. Natürlich kann man das in den ULS Logs nachschauen gehen. In der Praxis, gerade bei grossen Umgebungen, ist dieser Ansatz zeitraubend und daher nicht unbedingt ideal.

Viel schneller und einfacher ist das Ausnutzen der Tatsache, dass die Inhalte im Verzeichnis C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS nicht mit den anderen Web Front-end Servern synchronisiert werden.
In solchen Situationen erstelle ich deshalb auf jedem Server ein HTML-File mit dem Namen servername.html und folgendem Inhalt:

<html>
<head>
<title>Auf welchem Server bin ich&#063;</title>
<style type="text/css">
body {background-color:#FFFFFF;}
#displaysrvname {font-family:'Segoe UI',Verdana,sans-serif;font-size:25pt;font-color:#0072c6;text-align:center;margin-top:75px;}
</style>
</head>
<body>
<div id="displaysrvname">SERVERNAME</div>
</body>
</html>

Der fett markierte SERVERNAME ist durch den jeweiligen Servernamen zu ersetzen.
Wenn Sie nun http://<ihrewebapplicationurl>/_layouts/servername.html aufrufen, erscheint der Servername des Web Front-ends, der bei dieser Anfrage den Inhalt zur Verfügung gestellt hat.