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.

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

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.

Ich selbst stand bspw. mal vor dem Problem eine Datenbank mit vielen Kategorien zu erstellen. Ähnlich wie in solch einem Blog hier sollten Einträge einer oder mehreren Kategorien zugeordnet werden. Eine einfache Variante dies umzusetzen wäre die Arbeit mit bitorientierten Operatoren. Man verpacke alles in ein Byte und arbeitet mit den Bits, mit einer Art Schalterfunktion.

Im nachfolgenden Beispiel hat jedes Bit die Funktion eines Schalters. Damit ist es möglich in einem Byte bis zu 8 Ein-/Aus-Informationen zu speichern.

Hier werden nur 7 Ein-/Aus-Informationen gespeichert, da hier der elementare Datentyp sbyte genutzt wird.
Dieser ist vorzeichenbehaftet und hat folgenden Wertebereich: -2⁷ bis 2⁷-1 (-128 bis 127).
Vorzeichenbehaftete Datentypen speichern im höchstwertigen Bit das Vorzeichen [+/-].

Die Schaltvorgänge werden mit bitorientierten Operatoren realisiert.

Zum leichteren Verständnis habe das Ganze hier am Beispiel eines Lichtschaltersystems für ein Haus dargestellt. Wir steuern also über die einzelnen Bits die Beleuchtung der Räume und NEIN, Dimmer sind hier keine verbaut.

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.

#Funktion zum Füllen der Datei
function setLogFile ($content) {
Set-Content $CorrIDLogFile $content
}

#Werte von Tastatur einlesen
$corrID = Read-Host -Prompt “Bitte Korrelations-ID angeben:”
$startTime = Read-Host -Prompt“Ab wann soll durchforstet werden? Eingabe-Format dd/mm/yyyy hh:mm”

#Prüfen ob Datum angegeben wurde
if ($startTime) {
$content = Get-SPLogEvent -starttime $startTime | Where-Object {$_.Correlation -eq $corrID}
} else {
$content = Get-SPLogEvent | Where-Object {$_.Correlation -eq $corrID}
}

#Wenn Datei erreichbar ist, schreibe Daten da rein
if (Test-Path $corrIDLogFile) {
setLogFile ($content)
} else {
Write-Host “Datei ” + $corrIDLogFile + ” nicht gefunden!”
}

Log Name: Application
Source: MSExchangeIS Mailbox Store
Date: 04/28/2012 12:32:46 AM
Event ID: 9875
Task Category: Content Indexing
Level: Error
Keywords: Classic
User: N/A
Computer: Ex-01.spielwiese.intern
Description:
Unexpected error “DOC_TOO_HUGE: There are not enough resources to process the document or row” occurred while indexing document.
Mailbox Database: EX01.spielwiese.intern
Folder ID: 34c8-E9F53E
Message ID: 2-260403
Document ID: 611
Error Code: 0x8004364a

oder in Deutsch:

Protokollname: Application
Quelle:  MSExchangeIS Mailbox Store
Datum:         28.04.2012 19:13:07
Ereignis-ID:   9875
Aufgabenkategorie:Inhaltsindizierung
Ebene:         Fehler
Schlüsselwörter:Klassisch
Benutzer:      Nicht zutreffend
Computer:      EX01.spielwiese.intern
Beschreibung: Unerwarteter Fehler “DOC_TOO_HUGE: Es gibt nicht genügend Ressourcen für das Verarbeiten des Dokuments oder der Zeile” beim Indizieren des Dokuments.
Postfachdatenbank: Mailbox Database 2060559779
Ordner-ID: 34c8-E9F53E
Nachrichten-ID: 2-260403
Dokument-ID: 611
Fehlercode: 0x8004364a

Dieser Fehler sollte eigentlich schon seit SP1 UR1 (wie hier von einem MS Mitarbeiter gepostet) gefixt sein. Trotzdem sehe ich bei vielen meiner Kunden ab und an diese Fehlermeldung im Ereignisprotokoll. Das Nervige an dieser Angelegenheit ist, dass Exchange leider nicht verrät, in welcher Mailbox sich die betreffende Nachricht befindet und um welche Nachricht es sich handelt. Deshalb ist für die Fehlersuche etwas Handarbeit erforderlich. Um die entsprechende Nachricht zu finden, die diese Fehlermeldung verursacht, muss man sich dem Tool “Exfolders” bedienen. Dieses Tool kann unter folgender Adresse heruntergeladen werden:

Download Exfolders

Das Tool “ExFolders” ist der direkte Nachfolger von PFDaVAdmin, welches mir schon treue Dienste geleistet hat. Nachdem das Tool heruntergeladen wurde, muss die Datei “ExFolders” in den Ordner “C:\Programme\Microsoft\Exchange\V14\Bin” kopiert werden. Da die Datei “ExFolders.exe” nicht signiert ist und es dadurch bei der Ausführung zu einer Fehlermeldung kommt, muss Sie entweder auf dem Zielsystem mit “sn.exe” signiert werden oder die Überprüfung der Signatur für “ExFolders” deaktiviert werden. Für das Deaktivieren liefert Microsoft in der ZIP-Datei gleich eine entsprechende REG-Datei (“TurnOffSNVerificationForExFolders.reg”) mit, welche die Überprüfung der Signatur für “ExFolders” deaktiviert.

Wenn alle Vorbereitungen abgeschlossen sind, kann man sich an die eigentliche Arbeit machen.  Als Erstes muss man sich mit der Mailboxdatenbank verbinden, in der sich die betreffende Nachricht befindet. Der Name der betreffenden Datenbank ist in der Fehlermeldung ersichtlich.

Nachdem die Verbindung erfolgreich erstellt wurde, muss man die Mailbox bzw. den Ordner ermitteln, in dem sich die betreffende Nachricht befindet. Dazu exportiert man einfach alle in der Datenbank enthaltenen Ordner inklusive ihrer Eigenschaften. Wichtig dabei ist, dass beim Export auch die Eigenschaft “ptagFID: 0×67480014″ mit exportiert wird. In dieser Eigenschaft wird die hexadezimale Kennung des Ordners erfasst. Beim Exportieren sollte man etwas Geduld haben. Wenn sich eine größere Anzahl von Postfächern in der Datenbank befindet, kann der Exportvorgang locker fünf Minuten in Anspruch nehmen.

Nachdem der Export erfolgreich abgeschlossen wurde, kann die Textdatei mit dem Notepad nach der Ordner-ID “34c8-E9F53E” durchsucht werden.

Wie man in der Textdatei erkennen kann, ist der Benutzer Röder “daran schuld” . Um jetzt letztendlich die Nachricht zu ermitteln, muss man sich mit Hilfe von “ExFolders” mit dem betreffenden Ordner verbinden. Im Notepad ist gut zu erkennen, dass es sich um den Kalender des Benutzers handelt. Wenn der Ordner in “ExFolders” markiert ist, können die Eigenschaften der einzelnen Elemente exportiert werden. Bei dieser Aufgabe lauert eine kleine Stolperfalle. In den Standardeinstellungen von “ExFolders” werden die IDs der Nachrichten nicht exportiert. Man muss “ExFolders” anweisen, diese Eigenschaft mit einzubeziehen.

Die ID für die Eigenschaft findet man in der MSDN unter folgendem Link: http://msdn.microsoft.com/en-us/library/ee160871(v=exchg.80).aspx

Es muss also die Eigenschaft pidTagMid mit der hexadezimalen Kennung 0x674A0014 exportiert werden.

Der Exportvorgang kann wieder eine Weile dauern. Nachdem dieser abgeschlossen wurde, kann man jetzt in der Textdatei nach der Nachrichten-ID suchen.

Nachdem die Nachricht identifiziert wurde, kann der User informiert werden, welche Nachricht in welchem Ordner gelöscht werden soll. Sollte das nicht möglich sein, kann die Nachricht auch über die Powershell mit folgender Kommandozeile gelöscht werden:

Search-Mailbox -Identity "f.roeder" -SearchQuery 'Subject:"Besprechung Exchange Migration"' -DeleteContent

Danach sollte der Fehler mit der EventID 9875 endlich Geschichte sein.

Diese Fehlermeldung ist erst einmal nichtssagend. Der nächste Blick ging in das Ereignisprotokoll des entsprechenden Servers. Dort findet man eine Fehlermeldung mit der EventID 108 und der Quelle “MSExchange OWA”. Als Fehlertext bekommt man “Outlook Web App konnte aufgrund eines Konfigurationsfehlers keine Verbindung zu den Exchange-Webdiensten herstellen. Antwortcode= ‘null, webExceptionStatus = SendFailure’.

Leider wird man aus dieser Fehlermeldung auch nicht unbedingt schlauer. Wenn man Google mit dieser Event-ID füttert, dann kommt eine Vielzahl von Ergebnissen. Ein Ergebnis zeigt auf folgenden KB-Artikel:

http://support.microsoft.com/kb/2249852

Allerdings trifft dieser Artikel nicht zu und das System war auch aktuell gepatcht. Als Nächstes gingen meine Gedanken in Richtung IIS. Ich habe mir also einmal die Konfiguration der Website angesehen. Genau dort bin ich fündig geworden. Der Kunde hatte auf diesem Server noch weitere Webseiten im IIS Konfiguriert. Damit das funktioniert, hatte er die “Default Web Site” fest an eine IP gebunden und die anderen Webseiten mit einem Hostheader konfiguriert. Die Bindungen für die “Default Web Site” sahen in etwa so aus:

Genau darüber stolpert Outlook Web App. Nachdem die Einstellungen korrigiert wurden, funktionierte Outlook Web App wieder wie gewohnt.

Lessons learned: Niemals an den Bindungen der Exchange Website fummeln und andere Webseiten haben im IIS des Exchange Servers nichts zu suchen. Leider war dieses System ein SBS 2011, wo schon durch die Installation mehrere Webseiten eingerichtet werden.

Bei der DNS Variante gibt es allerdings seit Windows Server 2008 eine kleine Stolperfalle. Microsoft hat beschlossen, das der Eintrag “wpad” besonders schützenswert ist. Das bedeutet, selbst wenn in einer Forward-Lookup Zone ein A-Eintrag mit dem Namen “wpad” existiert, wird dieser bei einer DNS Anfrage nicht von einem Windows Server 2008 bzw. 2008 R2 mit einer korrekten IP aufgelöst. Werfen wir einmal einen Blick in den DNS-Server:

Wie man sehen kann, ist der A-Eintrag für “wpad” korrekt gesetzt. Wenn jetzt ein DNS-Client versucht diesen Namen in eine IP-Adresse aufzulösen, wird das in einer Fehlermeldung enden.

Auf dem DNS Server selbst wird durch eine DNS-Abfrage für den Host “wpad.domaene.intern” eine Warnung im Eventlog verzeichnet:

Leider kann man dieses tolle “Feature” nicht über die GUI oder über eine Gruppenrichtlinie deaktivieren. Um es letztendlich deaktivieren zu können, kommt dnscmd zum Einsatz. Mit dem Kommando

dnscmd /info /globalqueryblocklist

kann man die Einstellung anzeigen lassen.

Bei einer Standardinstallation sind also die Hostnamen “isatap” und “wpad” in der globalen Abfragesperrliste enthalten. Um jetzt zum Beispiel den Hostnamen “wpad” zu entfernen, setzt man über dnscmd folgendes Kommando auf jedem DNS-Server ab:

dnscmd /config /globalqueryblocklist isatap

Um das “Feature” komplett zu deaktivieren, kann man folgendes Kommando einsetzen:

dnscmd /config /enableglobalqueryblocklist 0

Wer jetzt mehrere DNS Server in seiner Domäne hat, der muss dieses Kommando auf allen DNS Servern absetzen, weil diese Konfiguration nicht zwischen den DNS Server repliziert wird. Der dafür ist, dass diese Einstellung in der lokalen Registrierung jedes DNS Server eingetragen wird. Folgende Schlüssel bzw. Werte sind für die Konfiguration verantwortlich:

Aktivieren bzw. Deaktivieren der globalen Abfragesperrliste:

Key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Name
EnableGlobalQueryBlockList

Typ
REG_DWORD

Daten
Enable: 1; Disable: 0

Eintragen bzw. Löschen von Hostnamen aus der globalen Abfragesperrliste:

Key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters

Name
GlobalQueryBlockList

Type
REG_MULTI_SZ

Data
wpad isatap

Wenn man jetzt aber mehrere DNS-Server verwalten muss, dann kann das Konfigurieren der globalen Abfragesperrliste eine zeitaufwendige Angelegenheit werden. Microsoft bietet dafür auch keine ADMX Datei an, mit der man diese Funktion bequem über eine Gruppenrichtlinie konfigurieren kann. Zum Glück gibt es ja die Gruppenrichtlinieneinstellungen, mit denen man einzelne Registrykeys verteilen kann.

Damit wirklich alle DNS Server konfiguriert werden, empfiehlt es sich, dass die Richtlinie auf der Ebene der Domäne erstellt wird.

Damit sich die Einstellung nur auf die DNS Server der Domäne auswirkt, prüfe ich über die Zielgruppenadressierung, ob der Schlüssel “HKLM\SYSTEM\CurrentControlSet\Services\DNS\Parameters” existiert. Nur wenn dieser Schlüssel vorhanden ist, soll die Einstellung in der Registrierung vorgenommen werden.

Nachdem die Einstellungen erledigt sind, sollte es im Gruppenrichtlinieneditor so aussehen:

Damit sollte dann die globale Abfragesperrliste deaktiviert sein und die Auflösung des Namens “wpad” zu einer IP-Adresse gelingen. Dieses “Feature” gibt es auch unter Windows Server 2003R2. Allerdings war es dort im Standard nicht aktiviert.

Weitere Infos:

• Verwalten der globalen Abfragesperrliste
• Whitepaper Gobal Query Block List

##########################################
#Import des Servermoduls
import-module ServerManager
#Installation IIS
add-windowsfeature AS-WAS-Support,AS-TCP-Activation,AS-Named-Pipes,Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Health,Web-Http-Logging,Web-Request-Monitor,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Performance,Web-Stat-Compression,Web-Mgmt-Tools,Web-Mgmt-Console,NET-Framework,NET-Framework-Core,NET-Win-CFAC,NET-HTTP-Activation,NET-Non-HTTP-Activ,RSAT,RSAT-Role-Tools,RSAT-Web-Server,WAS,WAS-Process-Model,WAS-NET-Environment,WAS-Config-APIs

Nachdem der IIS installiert wurde, muss die Webseite auf den Server kopiert werden. Zur Vereinfachung nutze ich die “Default Website” und kopiere die Webseite einfach unter “C:\inetpub\wwwroot”. In der Web.config muss noch die Windowsauthentifizierung aktiviert werden. Die folgenden Einstellungen müssen unterhalb von <system.web> gesetzt werden.

<authentication mode="windows"/>
<identity impersonate="true"/>

Wenn die Webseite auf einem Mitgliedsserver läuft, was durchaus eine gute Entscheidung wäre, muss für das Computerkonto im Active Directory die Delegierung aktiviert werden:

Jetzt müssen im IIS noch ein paar Einstellungen gesetzt werden.

Sollte unter “Anbieter” noch die NTLM Authentifizierung aktiv sein, kann es zum Double-Hop Problem kommen. Eine genaue Beschreibung zu diesem Problem findet man auf der MSDN.

Wenn alles erledigt ist, kann die Seite aufgerufen werden. Wichtig: Der Internet Explorer sendet nur für die Zone “Intranet” die Windows Anmeldeinformationen an den IIS. Es muss also sichergestellt werden, dass der Internet Explorer diese Seite der Zone Intranet zuweist und nicht der Zone Internet. Wenn FireFox, Safari etc. eingesetzt werden, funktioniert diese Lösung nicht. Damit die Webseite auch mit anderen Browsern funktioniert, müsste man unter Umständen eine weitere Seite erstellen, an der sich die Benutzer mit Browsern von Drittanbietern als Erstes entsprechend authentifizieren müssen und erst danach auf die Formularseite weitergeleitet werden.

Im Browser sieht die fertige Lösung so aus:

Self Service Formular für das Active Directory Teil 1

Self Service Formular für das Active Directory Teil 2

Self Service Formular für das Active Directory Teil 3

Wenn das Benutzerkonto über kein Bild verfügt, dann soll ein Dummy-Bild zur Anzeige kommen. Ich habe dafür ein einfaches Bild (dummy.jpg) gezeichnet. Das wird dem Image-Steuerelement zugewiesen, wenn in dem Attribut “thumbnailphoto” kein Wert vorhanden ist. Um das Image-Steuerelement mit einem Bild zu befüllen, greifen wir auf eine separate Seite zu, die für einen entsprechenden Benutzernamen das Bild aus dem Active Directory ausliest. Wenn kein Bild vorhanden ist, gibt die Seite das Dummy-Bild zurück. Sourcecode der “getPictureFromAD.aspx”

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.DirectoryServices;
 
namespace ITeach_ADSelfService
{
    public partial class getPictureFromAD : System.Web.UI.Page
    {
        private readonly string[] arrProperties = new string[] { "department", "sn", "title","thumbNailPhoto" };
        protected void Page_Load(object sender, EventArgs e)
        {
            //Auslesen des samAccountName und BaseDN fuer die Suche im AD
            String strSamAccount = Request.QueryString["samAccountName"];
            String strDN = Request.QueryString["strLDAP"];
            Response.ContentType = "image/jpeg";
            Response.Clear();
            if (strDN == null | strSamAccount == null)
            {
                Response.Redirect("dummy.jpg");
            }
            DirectoryEntry adDomain = new DirectoryEntry(strDN);
            string strSearchfilter = "(SamAccountName=" + strSamAccount + ")";
            System.DirectoryServices.DirectorySearcher search = new System.DirectoryServices.DirectorySearcher(adDomain, strSearchfilter, arrProperties);
            DirectoryEntry user = null;
            user = new DirectoryEntry(search.FindOne().Path.ToString());
            try {
                byte[] binaryPicture = (byte[])user.Properties["thumbNailPhoto"][0];
                Response.BinaryWrite(binaryPicture);
            }
            catch {
                Response.Redirect("dummy.jpg");
            }
 
        }
 
    }
}

Jetzt müssen wir dem Benutzer nur noch die Möglichkeit geben, sein eigenes Bild auch zu verändern. Dafür müssen wir nur in der Funktion “SetADData” folgenden Code einfügen:

if (thumbUpload.FileName != null && thumbUpload.PostedFile.ContentLength <= 102400)
             {
                 byte[] imageBytes = new byte[thumbUpload.PostedFile.InputStream.Length + 1];
                 thumbUpload.PostedFile.InputStream.Read(imageBytes, 0, imageBytes.Length);
                 //Bevor das Attribut neu befuellt wird, muss es geleert werden.
                 user.Properties["thumbnailphoto"].Clear();
                 user.Properties["thumbnailphoto"].Add(imageBytes);
             }

In diesem if Statement wird einfach geprüft, ob das Fileupload-Steuerelement einen Dateinamen enthält und die Dateigröße nicht größer als 100KB ist (Beschränkung des Attributs “thumbNailPhoto” im Active Directory). Wenn diese Bedingungen erfüllt sind, wird das Attribut “thumbNailPhoto” des Benutzers entsprechend mit dem neuen Bild befüllt. Der Quellcode der “default.aspx” sieht dann so aus:

using System;
using System.Collections.Generic;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.DirectoryServices;
 
namespace ITeach_ADSelfService
{
    public partial class _Default : System.Web.UI.Page
    {
        const string LDAP = "LDAP://dc=spielwiese,dc=intern"; //Anzupassen!
        static DirectoryEntry ADUser;
        private readonly string[] arrProperties = new string[] { "department","sn", "title"};
        protected void Page_Load(object sender, EventArgs e)
        {
            //Caching totlegen
            Response.ExpiresAbsolute = DateTime.Now.AddDays(-1d);
            Response.Expires = -1500;
            Response.CacheControl = "no-cache";
            if (Page.IsPostBack)
            {
                GetADData(ADUser);
            }
            else
            {
                string strUserName = GetCurrentWindowsUserLogin().ToString();
                ADUser = GetUser(strUserName);
                GetADData(ADUser);
                //Thumbnailimage fuer den entsprechenden Benutzer holen
                thumbNailImage.ImageUrl = "getPictureFromAD.aspx?samAccountName=" + strUserName + "&strLDAP=" + LDAP;
 
            }
 
        }
 
        private string GetCurrentWindowsUserLogin()
        //Diese Funktion ermittelt fuer uns den aktuellen Benutzernamen damit wir die Suche durchfuehren können
        {
            string strSamAccountName = "";
            string login = Page.User.Identity.Name;
            int intLogin = login.IndexOf(@"\");
            if (intLogin > 0)
            {
              strSamAccountName = login.Remove(0, intLogin + 1);
            }
            return strSamAccountName;
        }
        private DirectoryEntry GetUser(string loginName)
        {
            string strSearchfilter = "(SamAccountName=" + loginName + ")";
 
            DirectoryEntry entry = new DirectoryEntry(LDAP);
 
            System.DirectoryServices.DirectorySearcher search = new System.DirectoryServices.DirectorySearcher(entry, strSearchfilter, arrProperties);
            DirectoryEntry user = null;
            user = new DirectoryEntry(search.FindOne().Path.ToString());
            return user;
        }
         private void GetADData(DirectoryEntry user)
         {
              if (user.Properties["sn"].Value != null)
              {
                  txtSurname.Text = user.Properties["sn"].Value.ToString();
              }
              else
              {
                  txtSurname.Text = "";
              }
              if (user.Properties["department"].Value != null)
              {
                  txtDepartment.Text = user.Properties["department"].Value.ToString();    
              }
              else
              {
                  txtDepartment.Text = "";
              }
              if (user.Properties["title"].Value != null)
              {
                  txtPosition.Text = user.Properties["title"].Value.ToString();
 
              }
              else
              {
                  txtPosition.Text = "";
              }
 
         }
         private void SetADData(DirectoryEntry user)
         {
             if (txtSurname.Text != null)
             {
                 user.Properties["sn"].Value = txtSurname.Text.ToString();
             }
             if (txtPosition.Text != null)
             {
                 user.Properties["title"].Value = txtPosition.Text.ToString();
             }
             if (txtDepartment.Text != null)
             {
                 user.Properties["department"].Value = txtDepartment.Text.ToString();
             }
             if (thumbUpload.FileName != null && thumbUpload.PostedFile.ContentLength <= 102400)
             {
                 byte[] imageBytes = new byte[thumbUpload.PostedFile.InputStream.Length + 1];
                 thumbUpload.PostedFile.InputStream.Read(imageBytes, 0, imageBytes.Length);
                 //Bevor das Attribut neu befuellt wird, muss es geleert werden.
                 user.Properties["thumbnailphoto"].Clear();
                 user.Properties["thumbnailphoto"].Add(imageBytes);
             }  
             user.CommitChanges();
         }
 
         protected void Button1_Click(object sender, EventArgs e)
         {
             SetADData(ADUser);
         }
 
    }
}

Nachdem das alles erledigt ist, kann man schon einen vorsichtigen Test im Visual Studio wagen.

Der dritte Teil, inklusive dem Dummy-Bild, kann hier heruntergeladen werden (ITeach-ADSelfService-Teil3 (24)).

Self Service Formular für das Active Directory Teil 1

Self Service Formular für das Active Directory Teil 2

Self Service Formular für das Active Directory Teil 4