Windows Server, AD, Exchange und mehr…..

Welcher Admin, der sich mit dem Skripting befasst, kennt das nicht. Man möchte eine Aufgabe mit einem Skript automatisieren, um sich das Leben einfacher zu machen. Meistens wird dann Google eine Suchmaschine genutzt, um im Internet nach bereits fertigen Skripten oder Codeschnipseln zu suchen, die dem eigenen Problem sehr nahe kommen. Vielleicht hat man ja aber selber schon ein ähnliches Skript erstellt und findet es einfach nicht mehr.

Für genau diese Probleme hat Microsoft ein neues Werkzeug mit dem Namen “Microsoft Script Explorer for Windows PowerShell” zur Verfügung gestellt. Mit diesem Werkzeug kann man online (z.B. im Technet Skript Center) nach Powershell Skripten oder auch Codeschnipseln suchen.

Nach der Installation des Skriptexplorers kann man diesen eigenständig aufrufen oder direkt aus der Powershell ISE starten, in die sich der Skriptexplorer als Addon installiert.

Im Skriptexplorer selbst kann man die Powershellskripte dann nach Kategorien suchen oder eine Freitextsuche durchführen.

Eine ausführliche Anleitung für den Skriptexplorer finden man hier: http://social.technet.microsoft.com/wiki/contents/articles/8056.microsoft-script-explorer-for-windows-powershell-user-guide.aspx

Den Download für den Skriptexplorer findet man hier: http://www.microsoft.com/en-us/download/details.aspx?id=29101

Das Tool befindet sich noch in der Betaphase. Ich hatte beim Testen ein paar kleinere Probleme, aber im Großen und Ganzen funktioniert das gute Stück recht ordentlich.

Das Tool “logparser” setze ich schon eine längere Zeit für die Auswertung von IIS Logfiles ein. Das Abfragen von Logfiles wird über SQL Statements realisiert. Wer also über grundlegende SQL Kenntnisse verfügt, kann mit diesem Werkzeug schon sehr interessante Auswertungen erstellen. Allerdings ist das Erstellen von komplexen Abfragen nicht gerade einfach und kostet unter Umständen sehr viel Zeit.

Microsoft stellt seit März 2012 einen grafischen Aufsatz für Logparser zur Verfügung, der die Arbeit mit Logparser erheblich vereinfacht. Das Logparser-Studio ermöglicht es, das Werkzeug “Logparser” über eine grafische Oberfläche zu steuern. Zusätzlich liefert Microsoft gleich noch eine große Anzahl von vordefinierten Abfragen mit, die sofort eingesetzt werden können. Gerade für einen Exchange Administrator, der Informationen über die Clientaufrufe, die verwendenten Clientversionen oder auch die verbrauchte Bandbreite gewinnen möchte, ist das Logparser Studio ein cooles Werkzeug.
Eine sehr knifflige Angelegenheit ist es zum Beispiel, die Benutzer herauszufinden, die Ihre aktive Throttlingpolicy ausreizen. Auch diese Frage kann man mit dem Logparser Studio recht schnell beantworten.

Wenn es um Fragen geht, wie z.B.: “Welche Iphones mit welchem iOS greifen auf meinen Exchange zu?”, dann wird es meist auch schwierig, diese Fragen zu beantworten. Auch dafür liefert Microsoft zwei vordefinierte Abfragen mit:

Wer die ganze Auswertung dann noch grafisch bekommen möchte, der kann mit Logparser Studio die Auswertung als Diagramm ausgeben lassen.

Um Auswertungen über die gesendeten und empfangenen Daten zu erstellen, ist es notwendig, an den Protokollierungseinstellungen des IIS Anpassungen vorzunehmen. In den Standardeinstellungen protokolliert der IIS die gesendeten und empfangenen Daten leider nicht. Das bedeutet, dass die Abfragen über die Bandbreitenauslastung des Exchange Servers leider ergebnislos bleiben.

Wenn diese beiden Informationen in die IIS Protokollierung mit aufgenommen wurden, dann gelingen auch die Abfragen für die transferierte Datenmenge. Wer jetzt neugierig geworden ist, kann das Tool hier herunterladen bzw. den originalen Artikel lesen:

Link zum Exchange Team Blog

Jeder Administrator kennt das: die Benutzer verfallen in das Schema “Jagen und Sammeln”, wenn es um Daten geht, verschwenden wertvollen Platz auf dem Fileserver und belasten durch ihr Verhalten ganz nebenbei auch die Kapazitäten der Datensicherung. Für viele der Anwender ist ein Server eine unendliche Ressource, die niemals ausgeschöpft werden kann. Als Administrator versucht man dann, mit den Benutzern zu sprechen und zu hinterfragen, ob sie denn wirklich noch die Powerpoint Präsentation aus dem Jahr 2000 benötigen. Meistens bekommt man als Administrator dann die Antwort, dass es sich dabei um “hochwichtige” Daten handelt und diese keinesfalls aus dem Netzlaufwerk entfernt werden dürfen. Auch das Implementieren von Kontingenten gestaltet sich meist schwierig, da in den meisten Firmen die einzelnen Benutzer unterschiedliche Anforderungen an einen Fileserver stellen. Was aber tun, wenn der Platz auf dem SAN oder den internen Datenträgern des Servers langsam knapp wird und das Budget für Neuanschaffungen sehr begrenzt ist. Sehr schnell wird hier das Buzzword “Deduplication” in den Raum geworfen. Dieses Feature musste man sich bis jetzt entweder mit einem Windows Storage Server oder als Software von einem Drittanbieter teuer erkaufen. Mit Windows Server 2012 integriert Microsoft dieses Feature in das Betriebssystem.

Folgende Aspekte gilt es beim Einsatz zu beachten:

• Data deduplication ist clusterfähig
• Komprimierte oder auch verschlüsselte Dateien können nicht verarbeitet werden
• Das Bootvolume oder auch das Systemvolume kann nicht dedupliziert werden
• Die Datenträger, auf denen Daten dedupliziert werden, müssen mit NTFS formatiert werden
• Custer Shared Volumes werden nicht unterstützt
• Dateien, die kleiner als 32 KB sind, werden keiner Deduplizierung unterzogen

Wo sollte das Feature eingesetzt werden?

Deduplication kann auf allen Servern eingesetzt werden, auf denen relativ statische Daten abgelegt sind. Dazu zählen die klassischen Fileserver, die Freigaben für Datenlaufwerke, Profilverzeichnisse oder Homelaufwerke bereitstellen oder auch Server, auf denen z.B. Backups liegen.

Für alle Server, die z.B. als Exchange Server oder Datenbankserver wie MS SQL  dienen, sollte keine Deduplication aktiviert werden. Dies würde zu enormen Performanceverlusten führen.

Wie arbeitet die Deduplication unter Windows Server 2012?

Das ist relativ einfach erklärt. Windows Server 2012 zerlegt die Dateien auf dem Volume in kleine Segmente variabler Größe (32KB – 128KB). Alle Segmente, die mehrfach vorhanden sind, werden entfernt und nur ein einzelnes Segment wird im “Chunk Store” abgelegt. Für die entfernten Segmente werden “Reparse Points” im Dateisystem angelegt, die auf das abgelegte Segment im “Chunk Store” referenzieren.

Der Dienst für die Depluzierung läuft als ständiger Prozess im Hintergrund und evaluiert alle 60 Minuten die Dateien auf den Datenträgern. Sollte in solch einem Zyklus der Server gerade Leistungsengpässe (kein Speicher verfügbar, hohe CPU Last) aufweisen, dann wird der Zyklus abgebrochen. Zusätzlich zu dem Hintergrundprozess, kann ein Administrator aber auch eine Deduplizierung durch einen geplanten Task auslösen. Dies könnte dann z.B. in den Nachtstunden ausgeführt werden. Microsoft selbst gibt an, dass ca. 1,5TB an Daten in einem 24 Stunden Zyklus gescannt werden können.

Bevor man aber mit dem Umstellen der Fileserver auf Windows Server 2012 wegen diesem Feature beginnt, sollte man als Erstes prüfen, ob sich die Investition überhaupt lohnt. Dafür liefert Microsoft das Tool “ddpeval.exe”, was auch unter Windows Server 2008 R2 ausgeführt werden kann. Für das Auswerten eines bestehenden Fileservers sollte man allerdings etwas Geduld mitbringen. Ich habe das Tool auf meinem Fileserver gestartet und die Auswertung für ein Laufwerk durchgeführt, auf dem etwa 1,2TB an Daten liegen. Für die Auswertung hat das Tool 28 Stunden benötigt. An Systemressourcen hat das Tool ca. 300MB an RAM benötigt und die CPU ungefähr mit 17% ausgelastest. Das lange Warten hat sich allerdings gelohnt. Auf dem betreffenden Volume kann ich ca. 75% durch die Deduplizierung zurückgewinnen. Da auf diesem Fileserver sehr viele VHD Dateien für Demoumgebungen liegen, ist 75% auch ein verständlicher Wert.

In meiner Windows Server 2012 Testumgebung habe ich einen Fileserver mit wesentlich weniger Daten aufgesetzt. Auf dem Testsystem existiert ein Laufwerk mit einer Größe von 127GB und davon sind ca. 105GB mit Daten belegt. Da es sich um ein Testsystem handelt, habe ich mit “fsutil” einfach Testdateien erstellt. Da diese Testdateien alle gleich sind, sollte sich durch die Deduplizierung auch ein hohes Einsparpotential ergeben.

Auch für dieses Laufwerk habe ich das Tool “ddpeval.exe” ausgeführt. Bei diesem Laufwerk hat die Ausführung des Tools ca. 13 Minuten gedauert. Als mögliches Einsparpotential hat mir “ddpeval.exe” ca. 104,31 GB gemeldet. Das ist laut “ddpeval.exe” ein Einsparung von ca. 99%.

Installation und Konfiguration der Deduplizierung

Die Installation der Deduplizierung erfolgt über das Hinzufügen von Rollen und Features über das Dashboard des neuen Servermanagers.

Diese Rolle kann man natürlich auch sehr einfach mit der Powershell installieren.

import-module ServerManager
add-windowsfeature fs-data-deduplication

Wenn die Rolle erfolgreich installiert wurde, müssen die einzelnen Volumes für die Deduplizierung aktiviert werden. Dies kann wieder wahlweise über die GUI oder über die Powershell realisiert werden.

Wie man in dem Screenshot sehen kann, läuft die Deduplizierung permanent im Hintergrund. Zusätzlich habe ich noch eine Aufgabe definiert, durch die Samstags ab 1 Uhr morgens eine sogenannte “Throughput optimization” für eine Dauer von sechs Stunden durchgeführt wird. Dadurch wird der Vorgang der Deduplizierung optimiert.

Natürlich lässt sich die Deduplizierung auch über die Powershell konfigurieren. Mit der Installation der Deduplizierung steht auch ein Powershell Modul für die Verwaltung der Deduplizierung zur Verfügung. Um auf die cmdlets der Deduplizierung zugreifen zu können, muss als Erstes das Modul importiert werden.

import-module Deduplication

Nach dem Import des Moduls stehen folgende cmdlets zur Verfügung:

get-command -module deduplication
disable-dedupvolume
enable-dedupvolume
get-dedupjob
get-dedupmetadata
get-dedupschedule
get-dedupstatus
get-dedupvolume
new-dedupschedule
remove-dedupschedule
set-dedupschedule
set-dedupvolume
start-dedupjob
stop-dedupjob
update-dedupstatus

Zum Aktivieren eines Volumes für die Deduplizierung ist folgendes Kommando notwendig:

enable-dedupvolume E: | set-dedupvolume -minimumfileagedays 0

ACHTUNG: Den Parameter “minimumfileagedays” habe ich nur zu Demozwecken auf 0 gesetzt!
Damit das System sofort mit der Deduplizierung beginnt, muss explizit der Deduplizierungsvorgang gestartet werden. Dafür gibt es über die Powershell zwei Möglichkeiten. Zum Einen kann man die Deduplizierung im Hintergrund – also asynchron – ausführen oder man führt die Deduplizierung synchron aus und muss in der Powershell auf die Fertigstellung warten.

Asynchrone Ausführung

Synchrone Ausführung

Während der der Deduplizierung kann man den Status sehr gut mit den cmdlets “get-dedupjob” und “get-dedupstatus” nachverfolgen.

Wenn das cmdlet “get-dedupjob” keinen aktiven Job mehr zurückliefert, ist die Deduplizierung beendet. Durch das cmdlet “get-dedupstatus” kann jetzt ermittelt werden, wie effektiv die Deduplizierung für das Laufwerk E: vorgenommen wurde.

Zusätzlich verzeichnet die Deduplizierung einen Ereignisprotokolleintrag mit der Event ID 6153, in dem die erfolgreiche Deduplizierung des Volumes E: gemeldet wird.

Ein Blick in den Explorer bestätigt die Angaben von “get-dedupstatus” und des Ereignisprotokolls.

Vor der Deduplizierung

Nach der Deduplizierung

Die Deduplizierung der Daten auf dem Testlaufwerk hat ca. 20 Minuten in Anspruch genommen. Für knappe 105GB ist das eine ordentliche Geschwindigkeit. Allerdings sollte man dabei nicht vergessen, dass es sich bei den Testdateien immer um die gleiche Datei handelte. Deshalb hatte die Deduplizierung bei dieser Aufgabe relativ leichtes Spiel.

Zusätzlich gibt es für die Fans der guten alten cmd.exe auch ein separates Kommandozeilenprogramm für die Verwaltung bzw. Konfiguration der Deduplizierung. Dieses Kommandozeilenprogramm kann über die Eingabe von “ddpcli” aufgerufen werden.

Wartung, Pflege und Überwachung der Deduplizierung

Zur Wartung und Pflege der Deduplizierung muss man als Administrator eigentlich nichts tun. Die notwendigen Wartungsarbeiten werden während der Installation automatisch als geplante Aufgaben auf dem betreffenden Fileserver angelegt. Im Standard handelt es sich dabei um drei geplante Aufgaben. Da ich in meiner Demoumgebung bei der Konfiguration des Volumes einen Zeitplan für die “Throughput Optimization” angelegt habe, wurde auf meinem Testsystem eine vierte Aufgabe hinzugefügt.

Für die Wartungsaufgaben werden im Wesentlichen zwei Aufgaben erstellt. Einmal handelt es sich um die Aufgabe “WeeklyGarbageCollection” und zum Anderen um die Aufgabe “WeeklyScrubbing”.  Beim Scrubbing wird eine Integritätsprüfung durchgeführt. Dadurch wird geprüft, ob alle Daten im Chunkstore konsistent sind. Sollten Inkonsistenzen festgestellt werden, dann wird durch diese geplante Aufgabe auch eine Reparatur versucht. Wer das Scrubbing interaktiv durchführen möchte, kann dies auch über die Powershell mit folgendem Kommando anstoßen:

start-dedupjob e: -type scrubbing

Nachdem das Kommando abgeschlossen ist, wird im Ereignisprotokoll ein Eintrag mit der Event ID 12803 verzeichnet. In der Meldung werden auch eventuelle Probleme gemeldet.

Bei der Garbage Collection wird, wie der Name schon sagt, der ganze Müll eingesammelt. Wenn zum Beispiel auf einem Laufwerk, auf dem die Deduplizierung aktiviert ist, eine Datei gelöscht wird, dann werden die referenzierten Elemente aus dem Chunkstore nicht gelöscht. Das führt dazu, dass nicht referenzierte Daten, die nicht mehr benötigt werden, auf dem Volume liegen bleiben . Deshalb ist es zwingend notwendig, dass diese Aufgabe regelmäßig ausgeführt wird. Wenn man auf einem Volume eine größere Löschaktion durchführt, kann man den GarbageCollection Prozess auch manuell ausführen.

start-dedupjob e: -type GarbageCollection

In meiner Testumgebung habe ich auf dem Datenlaufwerk eine größere Anzahl von Dateien gelöscht. Danach habe ich den Garbage Collection Prozess angestoßen. Auch hier findet man im Ereignisprotokoll einen entsprechenden Eintrag, der die erfolgreiche Ausführung der Garbage Collection meldet. Leider findet man in der Meldung keinerlei Hinweise auf die entfernten Daten.

Datensicherung von Volumes, die für die Deduplizierung aktiviert sind

Generell sollte es mit Datensicherungen keine Probleme geben, wenn ein Volume gesichert wird, auf dem die Deduplizierung aktiv ist. Allerdings gibt es einen Unterschied zwischen einer dateibasierten Sicherung, wie z.B. ein einfaches xcopy, und einer blockbasierten Sicherung, wie z.B. Windows Server Backup. Bei einer dateibasierten Sicherungsmethode muss die reale Größe aller Dateien gesichert werden. Das bedeutet, dass bei dieser Sicherungsmethode ein Sicherungslaufwerk in entsprechender Größe vorgehalten werden muss. Ein XCopy kann also nicht von der Deduplizierung profitieren. Bei der blockbasierten Methode sieht das ganz anders aus. Bei dieser Methode kann auch die Sicherung von der Deduplizierung profitieren, da diese Sicherungsmethode keine Dateien sichert, sondern nur die einzelnen Blöcke.

Fazit

Die Deduplizierung ist ein sehr nützliches Feature der neuen Servergeneration, die der Speicherplatzverschwendung in Unternehmen durchaus Einhalt gebieten kann. Der Administrator freut sich, dass er endlich wieder Platz auf den Fileservern bekommt und den Controller freut es, dass er der IT Abteilung das Budget kürzen kann .
Trotz aller technischen Möglichkeiten sollte aber der erste Schritt für eine erfolgreiche Deduplizierung beim Anwender liegen, der mit Sinn und Verstand seine Daten auf einem Fileserver bzw. Netzlaufwerk ablegt und nicht durch “Jagen und Sammeln” von Daten die Fileserverressourcen unnütz verschwendet.

Meist ist es ja so, dass man mit relativ geringem Aufwand ein größtmögliches Ziel erreichen möchte. Aus diesem Grund möchte ich im folgenden Artikel ein Beispiel für bitorientierte Operatoren unter C# etwas näher erläutern.

Read the rest of this entry »

Wer mit SharePoint arbeitet, der weiß , dass die Logs sehr hilfreich sein können, da manche Fehlerursache nur so zu finden ist. Der schnellste Weg die Logs zu durchforsten ist per PowerShell. Wer lieber Fenster mag, der kann sich ruhig mal den ULS Viewer ansehen.

Ich habe hier ein relativ einfaches aber nützliches PowerShell-Script gebaut, das die SharePoint-Log-Datei nach der eingegebenen Korrelations-ID durchforstet und dabei nur die Einträge, die größer oder gleich dem eingegebenen Datum sind, durchsucht. Das Ergebnis wird dann in eine Datei geschrieben. Read the rest of this entry »