 TechNet Magazine November 2007

TechNet Magazine November 2007

Windows-Verwaltung: Änderungen an Offlinedateien in Windows Vista

Es ist ein allseits bekanntes Problem: Wie können Sie Benutzer mit Dateien arbeiten lassen, die bei unzuverlässiger oder nicht vorhandener Konnektivität im Netzwerk gespeichert werden, und trotzdem Probleme bei der Versionsverwaltung vermeiden? Diese Kontinuität ist unerlässlich, um eine nahtlose Verwendung zu gewährleisten. Entdecken Sie, wie Sie dank der Verbesserungen in Windows Vista besser mit Offlinedateien arbeiten können.

Jeremy Moskowitz Desktopbereitstellung: Einfache, skalierbare Bereitstellung mit BDD 2007

Sie verfügen nicht über SMS 2003? Keine Sorge, es gibt eine andere Lösung zum Erstellen einfacher Desktopbereitstellungen. Im Folgenden erhalten Sie eine ausführliche Anleitung zur Verwendung von BDD 2007 und SQL Server, um skalierbare Bereitstellungen zu erstellen, die wenig oder keinen manuellen Aufwand erfordern.

Adam Shepherd Kommunikation: Exchange-Edge-Transport-Server bei Microsoft: Teil 2

Exchange-Edge-Transport-Server sind Ihnen beim Erstellen einer zuverlässigeren und sichereren Messagingumgebung behilflich. Nachdem in Teil 1 die Serverkonfiguration behandelt wurde, wird jetzt anhand einiger ausführlicher Beispiele aufgezeigt, wie sich Ihre Messagingumgebung mithilfe der wichtigsten Features verbessern lässt.

Kay Unkroth Netzwerk: Konfigurieren von VPN-Remotezugriff mit ISA Server 2006

Durch ein virtuelles privates Netzwerk (VPN) kann die Konnektivität verbessert und somit die Produktivität erhöht werden. Implementierung und Verwaltung eines VPN müssen nicht unbedingt schwierig sein. Erfahren Sie, wie Sie mithilfe von ISA Server 2006 zwei häufige VPN-Szenarios behandeln können.

Alan Maddison SQL Server: Optimieren der SQL Server-Abfrageleistung

Für die Optimierung der Datenbankleistung ist die Optimierung einzelner Abfragen ebenso wichtig wie die Optimierung der Serverhardware- und Softwarekonfiguration. Bereits eine einzige problematische Abfrage kann eine Datenbank in die Knie zwingen. In diesem Artikel wird das Erzeugen, Analysieren und Optimieren von Ausführungsplänen für die Verbesserung der Leistung von SQL Server-Abfragen behandelt.

Maciej Pilecki Mitteilung der Redaktion: Mehr Leistung für Sie

Joshua Hoffman Toolbox: Neue Produkte für IT-Experten

Greg Steen Exchange Fragen & Antworten: Sichere E-Mail-Protokolle, rätselhaftes Spam und mehr

Im Artikel für diesen Monat wird vom Exchange-Team die Transport Layer Security für SMTP behandelt. Außerdem wird besprochen, wie Sie verhindern können, dass Ihre Warteschlangen von gefälschten Unzustellbarkeitsberichten überschwemmt werden, und wie Sie verschiedene Installationsherausforderungen meistern können.

Nino Bilic and Scott Landry Schwerpunkt Dienstprogramme: SMS-Cmdlets für Windows PowerShell

Finden Sie heraus, wie Sie Windows PowerShell-Cmdlets zur Verwaltung von SMS 2003-Clients über die Befehlszeile verwenden können.

Don Brown The Cable Guy: Drahtloses einmaliges Anmelden

Einmaliges Anmelden (Single Sign-On, SSO) bietet sowohl Endbenutzern als auch Administratoren viele Vorteile. Im Folgenden wird erläutert, wie einmaliges Anmelden die Implementierung der Drahtlosauthentifizierung für Ihr Netzwerk erleichtern kann.

Joseph Davies Forschungsberichte: Verwenden von High Performance Computing im Kampf gegen HIV

Machen Sie sich ein Bild davon, wie das eScience-Team von Microsoft Research mit der medizinischen Forschung zusammenarbeitet und High Performance Computing (HPC) einsetzt, um bei der Suche nach einem Mittel gegen HIV zu helfen.

Kristin Firth and Mia Matusow Windows PowerShell: Schreiben regulärer Ausdrücke

Über einen gut geschriebenen regulären Ausdruck kann ein Windows PowerShell-Skript bestimmen, ob Daten einem gültigen Format entsprechen. Verschaffen Sie sich einen Überblick über die Verwendung regulärer Ausdrücke in Windows PowerShell.

Don Jones Hey, Scripting Guy!: Desktopverwaltung aus dem Jenseits

Die Scripting Guys führen vor, wie Sie mit der Windows-Remoteverwaltung die Eigenschaften und Instanzen von Klassen auf einem Remotecomputer abrufen. Dabei gibt es auch ein nettes Rätsel.

The Microsoft Scripting Guys Sicherheit auf dem Prüfstand: Sicherer Zugriff an jedem Ort

Machen Sie sich mit dem Entwurf von Netzwerken und entsprechenden Sicherheitsmechanismen für einen ortsunabhängigen Zugriff mithilfe von Terminaldienstkomponenten vertraut, und erfahren Sie mehr über praktische und bewährte Methoden zum Erstellen einer Lösung mit Windows Server 2008.

John Morello Die Desktopdateien: Die Wahrheit über Defragmentierung

Falsche Vorstellungen über die Fallen der Defragmentierung haben schon viele Administratoren von der Durchführung dieser wichtigen Wartungsaufgabe abgehalten. Finden Sie heraus, welche Probleme tatsächlich vorkommen, welche unwahrscheinlich sind und wie Sie sie vermeiden können.

Wes Miller Berichte aus der Praxis: Der Verhaltenskabeljau

Wenn Communitymitglieder aufmüpfig werden, ist möglicherweise nur ein großer Fisch erforderlich. Erfahren Sie, wie Social Engineering zur Rettung von Live QnA beigetragen hat.

Betsy Aoki Windows Confidential: Das Dateisystemparadox

Haben Sie sich jemals gewundert, warum Sie einen Miniaturdateisystemtreiber benötigen, der in diese kritischen Startdateien integriert ist?

Raymond Chen


 Windows-Verwaltung: &#196;nderungen an Offlinedateien in Windows&#160;Vista
Windows-Verwaltung Jeremy Moskowitz

Änderungen an Offlinedateien in Windows Vista
Kurz zusammengefasst:
  • Kontinuität zwischen Online und Offline
  • Dateiverfügbarkeit
  • Weiterentwicklung von Offlineordnern

Eines der schwierigsten Probleme bei der Desktopverwaltung besteht darin, dass Offlinebenutzer genauso arbeiten können, als ob sie online wären. Die Notwendigkeit ist größer, als Sie vielleicht denken: Benutzer sind viel mobiler als noch vor fünf Jahren. Obwohl es eine Reihe von Situationen gibt, in denen Sie möglicherweise offline arbeiten müssen,
treten die drei folgenden am häufigsten auf: wenn Sie Ihren Laptop vom Büronetzwerk trennen, um im Außendienst zu arbeiten, wenn Sie die Verbindung über einen langsamen oder nicht ständig verfügbaren Link herstellen, und wenn Ihre Zweigstelle die Verbindung zur Zentrale verliert.
Wie verwalten Sie unter diesen Umständen die Kopie einer Datei auf dem Offlinecomputer, während sich das Original auf dem Hauptserver befindet? Noch wichtiger: Wie gehen Sie mit dem Konflikt um, wenn jemand die Datei auf dem Server im Büro ändert, während jemand anders sie im Außendienst ändert? Glücklicherweise gibt es für diese Probleme das in Windows® 2000, Windows XP und Windows Vista® integrierte Offlinedateimodul.

Die Antwort heißt Zwischenspeicherung
Das Offlinedateimodul ist für die Zwischenspeicherung wirklich großartig. Intern (und innerhalb von Microsoft) wird es als clientseitiges Zwischenspeichern (Client Side Caching, CSC) bezeichnet. Das Offlinedateimodul ist konfigurierbar und so flexibel, dass Benutzer selbst entscheiden können, was zwischengespeichert werden soll, sowie das System zu veranlassen, die gewünschten Dateien zwischenzuspeichern. Es ermöglicht Ihnen, auf dieselben Dateien offline wie online zuzugreifen, und der Namespace ändert sich dabei nicht. Auf Dateien kann demnach mithilfe desselben UNC-Pfads oder Laufwerkbuchstabens zugegriffen werden, unabhängig davon, ob Sie online oder offline arbeiten.
Sie können die Dateien so einrichten, dass sie entweder manuell oder automatisch zwischengespeichert werden. Wenn Sie wissen, dass Sie bestimmte Dateien oder Ordner oft unterwegs verwenden, können Sie eine Datei oder einen Ordner einfach entsprechend kennzeichnen. Hierzu klickt ein Windows XP-Benutzer mit der rechten Maustaste auf eine Datei, die lokal oder auf einer Netzwerkfreigabe gespeichert ist, und wählt die Option aus, mit der Dateien offline zur Verfügung gestellt werden (siehe Abbildung 1). In Windows Vista heißt diese Option „Immer offline verfügbar“. Eine Datei manuell offline verfügbar zu machen wird manchmal Festhalten einer Datei genannt.
Abbildung 1 Eine Datei offline verfügbar machen
Abbildung 1 Eine Datei offline verfügbar machen
Abbildung 1a Der Offlinedateienordner
Abbildung 1a Der Offlinedateienordner
Die von Ihnen verwendete Freigabe kann über einen UNC-Pfad verbunden oder einem Laufwerkbuchstaben zugeordnet werden. Tatsächlich muss die Datei nicht einmal auf einem Computer gespeichert sein, der Windows Server® ausführt. Sie kann sich auf einem beliebigen Gerät befinden, das das SMB-Protokoll (Server Message Block) unterstützt, z. B. auf einem Samba-Server oder auf NAS-Geräten, die (von ganz wenigen Ausnahmen abgesehen) auch das SMB-Protokoll unterstützen.
Wenn Sie zum ersten Mal beschließen, eine Datei festzuhalten, führt Windows XP Sie schrittweise durch eine Reihe von Assistentenbildschirmen, in denen Sie gefragt werden, wann die Synchronisierung stattfinden soll. Wenn Sie auf allen Bildschirmen auf „Weiter“ klicken und die Standardeinstellungen übernehmen, erfolgt die Synchronisierung jedes Mal, wenn Sie sich an- oder abmelden, und auch im Hintergrund im Leerlauf. Wenn der Assistent abgeschlossen ist, ändert sich das Symbol, und die Datei ist jetzt offline verfügbar.
Wenn Sie die Verbindung zum Netzwerk trennen, sind nur noch die für Offlineverwendung ausgewählten Dateien der Freigabe verfügbar. Das ist manchmal problematisch: Das Symbol zeigt an, welche Dateien immer offline verfügbar sind, aber es ist vor der Trennung der Verbindung nicht sofort klar, dass nicht alle anderen Dateien verfügbar sein werden. Dies wird später in diesem Artikel ausführlicher behandelt.
Es hat durchaus Vorteile, Dateien manuell offline verfügbar zu machen, aber manchmal es ist sinnvoll, den Vorgang stärker zu automatisieren. Dieses Szenario soll als Nächstes untersucht werden, und zwar unter Verwendung eines Vorgangs, der oft Autocaching genannt wird.

Wenn automatisches Zwischenspeichern dem manuellen Zwischenspeichern überlegen ist
Autocaching wird auf einem Server für jede Freigabe einzeln eingerichtet. Wenn also eine Freigabe mit dem Namen „Vertrieb“ vorliegt, und Sie wünschen, dass Außendienstmitarbeiter ihre Dateien mit auf Reisen nehmen können, können Sie das CSC-Modul entsprechend anweisen. Abbildung 2 zeigt das Dialogfeld „Offlineeinstellungen“, das beim Klicken auf die Registerkarte „Zwischenspeichern“ in Windows Server 2003 angezeigt wird. Die Einstellungen werden in Abbildung 3 erklärt.
Figure 3 Autocaching-Einstellungen (Close Figure 3)

Einstellung | Beschreibung
Nur die von den Benutzern angegebenen Dateien und Programme sind offline verfügbar. | Ermöglicht Benutzern, manuell die Dateien anzugeben, die offline verfügbar sein sollen. Dies ist die Standardeinstellung.
Alle Dateien und Programme, die Benutzer auf der Freigabe öffnen, sind automatisch offline verfügbar. | Ermöglicht Autocaching aller Dateien und Programme, die von Windows Explorer angesprochen werden. Die Einstellung „Für hohe Leistung optimieren“ wird eher für die Zwischenspeicherung von Programmen als von Dokumenten verwendet, wirkt sich aber in der Regel nicht auf die Leistung aus und kann in den meisten Fällen ignoriert werden. Diese Einstellung wird von Windows Vista vollständig ignoriert.
Dateien oder Programme auf der Freigabe sind nicht offline verfügbar. | Sperrt den Benutzerzugriff auf das Element „Offline verfügbar“, wenn ein Windows 2000-, Windows XP- oder Windows Vista-Client verwendet wird.
Abbildung 2 Dialogfeld „Offlineeinstellungen“ in Windows Server 2003
Abbildung 2 Dialogfeld „Offlineeinstellungen“ in Windows Server 2003
Um zu verstehen, wie Autocaching funktioniert, wird angenommen, dass eine Freigabe „Vertrieb“ mit 10 Dateien vorliegt – von Sales01.txt bis Sales10.txt – und dass die Einstellung „Alle Dateien und Programme, die Benutzer auf der Freigabe öffnen, automatisch offline verfügbar machen“ aktiviert ist. Die Folgen dieses Szenarios sind nicht sofort ersichtlich. Für den Benutzer gibt es kein äußeres Anzeichen, dass plötzlich mehr Dateien offline verfügbar sind. Außerdem sind nur solche Dateien später für die Offlineverwendung verfügbar, die von Windows geöffnet (und daher zwischengespeichert) werden. Kurz gesagt, Sie müssen, bevor Sie die Verbindung zum Netzwerk trennen, tatsächlich alle Dateien online öffnen, die Sie offline verwenden wollen. Andernfalls sind sie offline nicht verfügbar.
Darüber hinaus bleiben automatisch gespeicherte Dateien nicht unbedingt für immer im Cache. In Windows XP und Windows Vista wird dieser vorläufige Speicherplatz etwas unterschiedlich behandelt, aber der wichtigste Punkt ist, dass Dateien bei mangelndem Speicherplatz entfernt werden können. Dateien werden in Abhängigkeit von ihrer Verwendung aufbewahrt. Die Dateien, die eine Zeitlang nicht geöffnet wurden, werden entfernt, um Platz für neue Dateien zu schaffen, wenn diese geöffnet werden. Es besteht daher zwar eine hohe Wahrscheinlichkeit, dass eine kürzlich verwendete Datei noch im Zwischenspeicher vorhanden ist, Sie sollten sich aber nicht darauf verlassen, dass Autocaching die Verfügbarkeit von Dateien garantiert. Wenn Sie sicher sein wollen, dass eine Datei verfügbar ist, muss sie festgehalten werden. Als Administrator können Sie auch Gruppenrichtlinien verwenden, um Dateien mit der vom Administrator zugewiesenen Einstellung für Offlinedateien festzuhalten.
Sehen Sie sich im Folgenden ein Beispiel aus der Praxis an. Angenommen ein Windows XP-Benutzer namens EastSalesUser1 öffnet eine Datei namens Sales05.txt, und ein Windows Vista-Benutzer namens EastSalesUser2 öffnet eine Datei namens Sales05.txt auf der Freigabe \\Server\Vertrieb.
Da auf der Freigabe „Vertrieb“ Autocaching festgelegt war, als EastSalesUser1 (unter Windows XP) und EastSalesUser2 (unter Windows Vista) offline gingen, konnten diese Dateien weiterhin bearbeitet werden. Windows hat eine Kopie der Dateien im Offlinedateicache zwischengespeichert. Was aber geschieht mit den anderen Dateien, die die Benutzer noch nicht verwendet haben?
Windows XP und Windows Vista gehen unterschiedlich mit Dateien um, die im Büro zurückgelassen werden, wie Sie in Abbildung 4 und 5 sehen können. In Windows XP gibt es nicht einmal einen Hinweis darauf, dass überhaupt Dateien ohne Zwischenspeicherung zurückgelassen wurden. Wenn Sie offline gehen, verschwinden die Dateien einfach, was möglicherweise verwirrend ist. Windows Vista hingegen besitzt eine Symbolüberlagerung und markiert nicht zwischengespeicherte Dateien mit einem kleinen ausgeblendeten X. Dies ist ein riesiger Fortschritt bei der Anzeige, welche Dateien offline verfügbar sind. Das einzige Problem ist, dass Sie dies erst nach dem Trennen der Verbindung sehen, nicht schon während einer Onlinesitzung. Daher wäre die deutlichere Darstellung des Status einer Datei eine willkommene Verbesserung.
Abbildung 4 Windows XP zeigt nur die Dateien, die nach dem Trennen der Verbindung verfügbar sind
Abbildung 4 Windows XP zeigt nur die Dateien, die nach dem Trennen der Verbindung verfügbar sind
Abbildung 5 Windows Vista zeigt die Dateien, die offline nicht verfügbar sind
Abbildung 5 Windows Vista zeigt die Dateien, die offline nicht verfügbar sind

Verfügbar oder nicht verfügbar
Einige Administratoren sind bei der Verwendung von Offlinedateien zurückhaltend, gerade deshalb, weil möglicherweise Folgendes unklar ist: welche Dateien ganz sicher offline verfügbar sind und welche nicht, und woran dies ersichtlich ist. In Abbildung 5 zeigt das grüne Kreissymbol über sales01.txt an, dass die Datei garantiert verfügbar ist. (Auch hier gilt, dass Dateien, die festgehalten werden, garantiert offline verfügbar sind.)
Wie jedoch erläutert wurde, ist die Datei Sales05.txt, die sowohl unter Windows XP als auch unter Windows Vista über Autocache offline verfügbar gemacht wurde, nicht unbedingt wirklich offline verfügbar. Bedenken Sie, dass nur die Dateien, die Sie verwenden, offline verfügbar sind. Es wäre also besser, wenn das System anzeigen könnte, dass die Dateien vorübergehend oder möglicherweise offline verfügbar sind. Da es keine unterschiedlichen Symbole gibt, kann nicht klar festgestellt werden, welche Dateien offline verfügbar sind. Die Benutzeroberfläche in Windows Vista ist besser, aber man muss immer noch sehr genau hinschauen. Eine Explorer-Eigenschaft in Windows Vista mit dem Titel „Offlineverfügbarkeit“ liefert solche Verfügbarkeitsinformationen. Diese Eigenschaft wird bei der Auswahl eines Elements im Vorschaufenster angezeigt. Bei festgehaltenen Elementen lautet der Wert „Immer verfügbar“. Bei nicht festgehaltenen, aber zwischengespeicherten Elementen lautet der Wert „Verfügbar“.
Das Konzept von vorübergehend verfügbaren Offlinedateien ist in Windows XP und Windows Vista ähnlich, aber die Implementierungen sind etwas unterschiedlich. Abbildung 6 zeigt, wie Windows XP und Windows Vista Offlinedateien behandeln.
Abbildung 6 Bereiche für Offlinedateien in Windows XP und in Windows Vista
Abbildung 6 Bereiche für Offlinedateien in Windows XP und in Windows Vista
Einfach ausgedrückt, besitzen sowohl Windows XP als auch Windows Vista einen bestimmten Speicherort für Offlinedateien, aber die immer verfügbaren Offlinedateien und die vorübergehend verfügbaren Offlinedateien werden in jedem der beiden Betriebssysteme etwas unterschiedlich gespeichert.
In Windows XP werden die immer offline verfügbaren Dateien (gekennzeichnet durch die Symboländerung wie in Abbildung 1 dargestellt) für immer an einem Ort abgelegt. Wenn Sie Dateien von insgesamt 10 GB manuell festhalten, wodurch sie offline immer verfügbar werden, wären alle 10 GB immer verfügbar. Es gibt keine Beschränkung der Anzahl an Dateien, die festgehalten werden können (außer der maximalen Partitionsgröße). In Windows XP gilt jedoch eine Maximalgröße von 2 GB für automatisch zwischengespeicherte Dateien. Dadurch werden nur die Dateien, die regelmäßig geöffnet werden, zwischengespeichert, während eine Zeitlang nicht verwendete Dateien bei Bedarf entfernt werden. Standardmäßig wird dem vorübergehend verfügbaren Zwischenspeicher 10 Prozent des freien Speicherplatzes auf der Festplatte zugewiesen, wie in Abbildung 7 dargestellt. Diese Einstellung ist in Windows XP nur für Administratoren verfügbar.
Abbildung 7 Einstellen des Speicherplatzes für Offlinedateien in Windows XP
Abbildung 7 Einstellen des Speicherplatzes für Offlinedateien in Windows XP
In Windows Vista können Dateien ebenfalls permanent oder vorübergehend gespeichert werden. Allerdings gibt es dabei einen Unterschied. Der Zwischenspeicher für temporäre Dateien ist im Gesamtzwischenspeicher enthalten. Standardmäßig wird der gesamte Zwischenspeicher (temporäre Dateien und immer verfügbare Offlinedateien) auf 25 Prozent des freien Speicherplatzes der Festplatte begrenzt. Dies wurde geändert, weil ein Benutzer in Windows XP ständig Dateien manuell zwischenspeichern konnte (womöglich mehrere tausend Gigabyte), sodass irgendwann nicht mehr genügend Festplattenspeicherplatz vorhanden war. Im neuen Modell reserviert der Administrator eine bestimmte Menge an Speicherplatz für den gesamten Zwischenspeicher, um dies auszuschließen. Bei näherer Betrachtung von Abbildung 8 stellen Sie fest, dass 25 Prozent des freien Speicherplatzes auf dem Laufwerk merkwürdigerweise als 15,2 Prozent des gesamten Laufwerks dargestellt sind. Außerdem kann der zweite Schieberegler, mit dem der vorläufige Speicherplatz festgelegt wird, nie höher als der erste Schieberegler eingestellt werden, mit dem der maximale Speicherplatz für alle Offlinedateien festgelegt wird. Der Zugriff auf diese Schieberegler für Datenträgernutzungslimits für Offlinedateien erfolgt durch Klicken auf die Option „Limits ändern“. Beachten Sie aber, dass Sie hierfür als Administrator angemeldet sein müssen.
Abbildung 8 Für Offlinedateien in Windows Vista verfügbarer Speicherplatz
Abbildung 8 Für Offlinedateien in Windows Vista verfügbarer Speicherplatz

Verhindern von übermäßigem Zwischenspeichern
Ordnerumleitung ist ein weiteres Windows-Feature, um zu gewährleisten, dass bestimmte, normalerweise lokal auf dem Computer gespeicherte Schlüsselordner tatsächlich auf Servern gespeichert werden. Folglich brauchen Sie sich um einen Absturz dieses lokalen Computers keine Sorgen zu machen: Sie haben ja eine Kopie aller wichtigen Dateien auf einer Netzwerkfreigabe.
Angenommen es liegt Ihnen ein umgeleiteter Ordner „Eigene Dateien“ in Windows XP oder Windows Vista vor. In diesem Fall (und bei Umleitung eines beliebigen Ordners) nimmt das Betriebssystem an, dass diese Dateien immer offline verfügbar sein sollen, und jede Datei innerhalb des umgeleiteten Ordners erhält das in Abbildung 1 gezeigte Symbol. Wenn Sie allerdings in einem gut verbundenen Netzwerk, das ständig online ist, zu einem neuen Computer wechseln, wird der gesamte Inhalt des umgeleiteten Ordners auf dem neuen Rechner zwischengespeichert, selbst wenn Sie ihn für nur eine einzige Sitzung verwenden wollen. Dies ist nicht nur Verschwendung von Speicherplatz, sondern auch ein Sicherheitsrisiko, wenn dies nicht ordnungsgemäß erfolgt.
Ein weiterer Fall, in dem Dateien automatisch und unwissentlich zwischengespeichert werden, ist gegeben, wenn Sie mithilfe von Windows Explorer die Dateien auf einer Freigabe durchsuchen. Wenn Sie sich mit Explorer beispielsweise einfach nur eine Reihe Grafikdateien auf einer Netzwerkfreigabe anschauen und Autocache dabei aktiviert ist, werden diese Dateien höchstwahrscheinlich automatisch heruntergeladen und in Ihrem Zwischenspeicher abgelegt. Das bloße Ansprechen einer Datei mit Explorer reicht nämlich schon völlig aus, damit die Datei im Zwischenspeicher für vorübergehend verfügbare Offlinedateien abgelegt wird. Oft wird jede Datei in der Freigabe angesprochen, um Metadaten wie Dateigröße oder die Vorschau eines Abbilds abzurufen. Wenn dies über einen schnellen, gut verbundenen Link erfolgt, ist es kein Problem. Windows erledigt die Zwischenspeicherung der Datei für die spätere Verwendung schnell und automatisch. Wenn Sie jedoch die Verbindung zu dieser Netzwerkfreigabe mit Autocache über einen langsamen Link hergestellt haben, können große Probleme auftreten. Die Situation ist im Grunde genommen bei Windows XP Explorer und Windows Vista Explorer standardmäßig unverändert. Die gute Nachricht ist, dass das Offlinezwischenspeicherungsmodul in Windows Vista so eingestellt werden kann, dass ein langsamer Link besser erkannt wird.

Offlinedateien mit Gruppenrichtlinien
Wichtigste Änderungen bei Offlinedateien in Windows Vista
Das Team für Offlinedateien möchte Ihnen die wichtigsten Änderungen mitteilen, aber aus Platzgründen lassen sich nicht alle in diesem Artikel erläutern. Deshalb hier in Kurzfassung die Hauptänderungen bei Offlinedateien:
  1. Nahtlose Übergänge von offline zu online bedeuten, dass offene Handles den Übergang nicht mehr blockieren.
  2. Dateigenaue Offlineauflösung, sodass eine Offlinefreigabe nicht mehr den ganzen Server offline übernimmt.
  3. Erzwungener Offlinemodus über eine Schaltfläche zum Online/Offline arbeiten in Windows Explorer.
  4. Benutzerspezifische Verschlüsselung zwischengespeicherter Inhalte.
  5. Neues Synchronisierungsmodul, das Änderungen viel schneller erkennt und analysiert.
  6. Integration in Windows Search, sodass umgeleitete Ordner indiziert werden können.
  7. Synchronisierung zwischen Lokal und Remote zur wirksamen Verbesserung der differenziellen Bitmusterübertragung.
  8. Zurückgestellte Konfliktauflösung über das Synchronisierungscenter.
  9. Keine den Benutzer störenden Sprechblasen mehr im Infobereich.
  10. Neuer umfassender COM-API- und WMI-Support für die Verwaltung, dokumentiert in MSDN® unter msdn2.microsoft.com/bb530662.
  11. Skriptunterstützung durch einen WMI-Anbieter (wird demnächst in MSDN dokumentiert).
  12. Neue Shelleigenschaften „Offlinestatus“ und „Offlineverfügbarkeit“.
  13. Ghosting, um offline nicht verfügbare Namespaceelemente darzustellen. Explorer zeigt diese als ausgeblendete, mit einem grauen X überlagerte Elemente an, was dazu beiträgt, dass sich die Ansicht des Shellordners beim Übergang von Online zu Offline nicht drastisch ändert.
  14. Neues Systemsteuerungsapplet.
Wenn Sie an diesem Thema interessiert sind, finden Sie weitere Informationen in meinem Buch und in der Microsoft-Dokumentation.

Wie bereits erwähnt, wird jedes Mal, wenn ein Benutzer (oder Explorer) eine Datei anspricht, die gesamte Datei im Zwischenspeicher gespeichert. Dies passiert selbst, wenn die Datei ein Visio®- oder Word-Dokument von 80 MB ist. Sowohl Windows XP als auch Windows Vista sind in der Lage, einen langsamen Link zu erkennen. Standardmäßig geht Windows XP davon aus, dass ein langsamer Link 64 KBit/s bedeutet. Wenn die Verbindungsgeschwindigkeit größer und der Client Windows XP ist, wird diese Datei zur Anmeldezeit durch diese langsame Pipeline abgerufen. Windows muss also so konfiguriert werden, dass alles, was über diesen langsamen Link erfolgt besser verwaltet wird. Dies kann über Gruppenrichtlinien erreicht werden, indem Sie ein Gruppenrichtlinienobjekt (GPO) erstellen, das mit einer Organisationseinheit verknüpft wird, die die Zielkonten – Windows XP oder Windows Vista – enthält.
Wenn der Benutzer die Verbindung über einen langsamen Link herstellt, versucht Windows XP, zunächst die lokal zwischengespeicherten Dateien zu verwenden, bevor versucht wird, die Netzwerkkopie zu verwenden. Dies ist sinnvoll. Aber Windows XP führt noch einen anderen, vielleicht vom Benutzer nicht erwarteten Vorgang aus: Große Dateien, die sich noch nicht im Zwischenspeicher des Benutzers befinden, werden heruntergeladen, wenn der Benutzer diese vom Netzwerk öffnet oder Explorer sie anspricht. Autsch! Wenn dann versuchsweise die Synchronisierung so geplant wird, dass sie bei Abmeldung (Standardeinstellung) erfolgt, wird der Rest dieser Dateien dann über den langsamen Link heruntergeladen und in den Zwischenspeicher gestellt. (Nochmal autsch!)
Windows Vista verhält sich hier anders. Eine langsame Verbindung wird in Vista standardmäßig nicht erkannt. Selbst wenn Sie die Verbindung über eine Netzwerkdose herstellen und 1 Bit pro Sekunde abrufen, behandelt Windows Vista diese Verbindung als schnell und verwendet die Kopie der Dateien im Netzwerk. Aber Windows Vista kann so eingestellt werden, dass erkannt wird, welche Freigaben überführt werden sollen, wenn die Verbindung langsam ist. In einem solchen Szenario verhält sich Vista besser. Windows Vista verhält sich (nach Konfiguration mittels Gruppenrichtlinien) nämlich so, dass der Inhalt von Freigaben, die als Langsamlink definiert sind, über einen langsamen Link mithilfe normaler Datei- und Explorer-Vorgänge einfach nicht verfügbar ist.
Die vom Offlinedateiendienst durchgeführte Hintergrundsynchronisierung findet über eine langsame Verbindung einfach nicht statt. Es ist jedoch anzumerken, dass eine manuelle Synchronisierung über das Synchronisierungscenter durchgeführt werden kann.
Soll Windows Vista so konfiguriert werden, dass langsame Links anders behandelt werden, so kann dies über die Gruppenrichtlinieneinstellung „Modus für langsame Verbindungen konfigurieren“ erreicht werden (nicht zu verwechseln mit der Windows XP-Einstellung mit dem ähnlich Namen „Übertragungsrate für langsame Verbindungen konfigurieren“). „Modus für langsame Verbindungen konfigurieren“ nimmt folgende Werte an: Die Namen der Server und Freigaben, die Sie bei langsamer Verbindung automatisch in den Offlinemodus überführen wollen, und die Angabe, wie langsam diese Verbindung sein muss, damit die betreffende Kombination „Server\Freigabe“ offline geht. Die Kombination „Server\Freigabe“ kann eine beliebige Kombination von „\\Server\Freigabe“ oder sogar nur ein einziger Stern (*) sein, um alle Freigaben auf allen Servern anzuzeigen. Der zweite Satz von Werten ist eine Deklaration des Durchsatzes (in KBit/s) und der Wartezeit (in Millisekunden), die unterschritten werden müssen, damit eine Verbindung als langsam deklariert wird. Der Haken dabei ist: Das nützlichere Element des Paares (Durchsatz) wird beim Herunterladen von Dateien nicht geprüft. Wenn Dateien mit 10 GB in einem umgeleiteten Ordner „Eigene Dateien“ vorliegen und Sie über einen langsamen Link mit einem Laptop arbeiten, der noch keine dieser Dateien enthält, dann stellen Sie sich besser auf eine lange Wartezeit ein. Wenn Sie jedoch den Durchsatz mit der Wartezeitprüfung kombinieren und die Wartezeit den vorgeschriebenen Wert unterschreitet, geht die Freigabe in den Offlinemodus über und erspart so dem Benutzer die unangenehme Verzögerung durch das Warten auf diese Dateien.
Der Windows Vista-Hotfix im Knowledge Base-Artikel 934202 (eine Änderung, deren Aufnahme in Windows Vista Service Pack 1 vorgesehen ist) dürfte bei bestimmten langsamen VPN-Bedingungen die Leistung verbessern. (Dieser Artikel ist online unter support.microsoft.com/kb/934202 verfügbar.) Dieser Hotfix dürfte beim Herunterladen über einen langsamen Link die Prüfung des Durchsatzwerts ermöglichen.

Synchronisierungskonflikte
Sie fragen sich wahrscheinlich, was geschieht, wenn eine Datei offline geändert wird (z. B. auf einer Flugreise), während jemand anders sie online ändert (bei fester Verbindung mit der Zentrale). Diese Situation wird auf der Clientebene behandelt. Beim Übergang von Offline zu Online findet sofort die Hintergrundsynchronisierung von Windows Vista für Offlinedateien statt. Anschließend werden Sie zu einer Aktion aufgefordert (über eine Eingabe in das Synchronisierungscenter, nach Anzeige eines Symbols im Infobereich der Taskleiste). Die Benutzeroberfläche wurde dahingehend neu gestaltet, dass sie anzeigt, welche Datei neuer zu sein scheint, und weitere Informationen über den Konflikt liefert. Ein Benutzer kann konfliktbeladene Dateien beibehalten, indem er die derzeit nur auf seinem Computer vorhandene Datei beim Rückspeichern auf den Server umbenennt, wie in Abbildung 9 dargestellt.
Abbildung 9 Hinweis auf Konflikt bei einer Dateiänderung in Windows Vista
Abbildung 9 Hinweis auf Konflikt bei einer Dateiänderung in Windows Vista

Wünschen Sie weitere Informationen?
Offlinedateien sind für Sie und für Ihre Benutzer ein nützliches Feature. Wenn Sie Ordnerumleitung verwenden, nutzen Sie dieses Feature ja bereits und sind daher an Informationen über einen intelligenteren Umgang mit dieser Technologie sicherlich interessiert. In diesem Artikel wurden eine Reihe von Änderungen bei Offlinedateien in Windows Vista erwähnt, aber nicht alle. Weitere Informationen hierzu finden Sie in der Randleiste „Wichtigste Änderungen bei Offlinedateien in Windows Vista“.
Ein breites Spektrum zusätzlicher Informationen über Offlinedateien finden Sie online unter go.microsoft.com/fwlink/?LinkId=98141 für Windows XP und unter go.microsoft.com/fwlink/?LinkId=98138 für Windows Vista.
Den Offlinedateien ist auch ein umfangreicher Abschnitt in meinem Buch gewidmet, einschließlich aller Einzelheiten zu jeder Gruppenrichtlinieneinstellung (siehe Biografie am Ende des Artikels). Wenn Sie noch mehr Informationen wünschen und Ihre Erfahrungen mit Offlinedateien mit anderen austauschen wollen, nehmen Sie sich etwas Zeit für das Gemeinschaftsforum unter GPanswers.com, wo es zu diesem Thema einen speziellen Abschnitt gibt.

Jeremy Moskowitz ist MCSE und MVP für Gruppenrichtlinien und leitet GPanswers.com, ein Gemeinschaftsforum zum Thema Gruppenrichtlinien. Außerdem organisiert er Intensivseminare zum Thema Gruppenrichtlinien. Sein aktuelles Buch heißt „Group Policy: Management, Troubleshooting, and Security“ (Sybex, 2007). Sie erreichen Jeremy Moskowitz unter www.GPanswers.com und erfahren dort mehr über dieses Thema.
© 2007 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


 Desktopbereitstellung: Einfache, skalierbare Bereitstellung mit BDD&#160;2007
Desktopbereitstellung Adam Shepherd

Einfache, skalierbare Bereitstellung mit BDD 2007
Kurz zusammengefasst:
  • Zentrale Funktionen von BDD 2007
  • Integration in SQL Server
  • Erstellen einer skalierbaren Bereitstellungslösung

Die meisten Menschen, die an der Bereitstellung von Windows beteiligt sind, haben schon von „Microsoft Solution Accelerator for Business Desktop Deployment“ gehört. Es ist auch als BDD bekannt und stellt eine Reihe von Anleitungen zu bewährten Methoden und
Tools dar, die entwickelt wurden, um Ihnen beim Bereitstellen von Windows® auf Clientdesktops zu helfen. Windows Vista® umfasst ein Update für Solution Accelerator in Form von BDD 2007. Diese Version enthält eine neue Microsoft® Management Console (MMC) und einen Task Sequencer, der aus System Center Configuration Manager 2007 stammt, dem Nachfolger von Systems Management Server (SMS) 2003.
Eines der weniger bekannten Features von BDD 2007 ist seine Eignung als vollständige Bereitstellungslösung. In früheren Versionen konnten Sie mit BDD Desktopabbilder in einer überschaubaren und wiederholbaren Weise erstellen und warten. Jetzt bietet Ihnen BDD 2007 die zusätzliche Fähigkeit zum Erstellen einer skalierbaren Bereitstellungslösung durch die Kombination von BDD mit den Windows-Bereitstellungsdiensten (Windows Deployment Services, WDS), SQL ServerTM und Windows Server® 2003 Distributed File System Replication (DFS-R).
Aber ist das Verwenden von SMS 2003 mit dem OSD-Feature Pack (Operating System Deployment) nicht die empfohlene Methode für die Windows-Clientbereitstellung?
Das stimmt. Falls Sie bereits über eine SMS 2003-Infrastruktur verfügen, sollten Sie auf die Verwendung von BDD 2007, SMS 2003 und dem OSD-Feature Pack für die Bereitstellung hinarbeiten. Dies ist derzeit die umfassendste Möglichkeit, eine Zero Touch-Bereitstellung zu erreichen, und kann die Kosten, die mit dem Konfigurieren, Installieren und Verwalten von Windows in Ihrer Organisation verbunden sind, wirklich senken.
Viele Kunden verfügen jedoch nicht über SMS 2003 oder eine gleichwertige Softwarebereitstellungslösung. Für diese Kunden gibt es eine andere Option, die in diesem Artikel näher erläutert wird.

Grundbegriffe von BDD 2007
BDD 2007 bietet grundsätzlich zwei Bereitstellungsmethoden. Die erste Methode, die Lite Touch-Installation, verwendet für die Bereitstellung des Clients nur BDD 2007. Beim Erstellen wird ein einsatzbereiter Satz von Assistenten bereitgestellt, um die Informationen zur Bereitstellung zu erfassen, zum Beispiel welcher Computername dem Client zugeordnet werden soll (siehe Abbildung 1), welches Tastaturlayout und welche Zeitzone verwendet werden sollen und so weiter. Diese Methode wird als „Lite Touch“ bezeichnet, weil in der Regel ein geringer manueller Aufwand erforderlich ist, um diese Informationen vor dem Start des Buildprozesses zu erfassen.
Abbildung 1 BDD 2007-Lite Touch-Bereitstellungs-Assistent
Abbildung 1 BDD 2007-Lite Touch-Bereitstellungs-Assistent
Die zweite Methode, die Zero Touch-Installation, beruht auf den Funktionen von SMS 2003 mit dem OSD-Feature Pack durch Integration in BDD 2007. Diese Konfiguration kann eine vollständig automatisierte, skalierbare und überschaubare Bereitstellungslösung bereitstellen.
Beim Erstellen werden von BDD 2007 in einem der ersten Schritte einer Clientbetriebssystembereitstellung Informationen von verschiedenen Quellen abgerufen. Diese Quellen umfassen WMI-Aufrufe und die BDD 2007-Konfigurationsdateien „Bootstrap.ini“ und „CustomSettings.ini“. Die Informationen werden als Variable erfasst und gespeichert. Diese Variablen werden während der gesamten Bereitstellung verwendet. Für ein Lite Touch-Szenario ermöglichen die Bootstrap.ini- und CustomSettings.ini-Dateien die Vorausbestimmung aller Informationen, die sonst durch manuelle Eingabe an die Bereitstellungs-Assistenten vermittelt werden würden.
Die Möglichkeit, vorab alle Informationen anzugeben, die andernfalls von den Lite Touch-Assistenten zur Buildzeit erfasst werden müssten, erlaubt es Ihnen, den gesamten Lite Touch-Prozess zu automatisieren und in den von SMS 2003 nicht unterstützten Umgebungen auf eine Zero Touch-Lösung hinzuarbeiten. Informationen, die vordefiniert werden können, umfassen beispielsweise „ComputerName=RDG0001VST“, um dem Computer einen Namen von RDG0001VDT oder TimeZoneName=GMT Standard Time zuzuweisen, um sicherzustellen, dass die Computerzeitzone auf GMT (Greenwich Mean Time) festgelegt ist. Alle verfügbaren Eigenschaften, die während einer Bereitstellung mit BDD verwendet werden können, sind in einem Konfigurationsverweis, der unter technet.microsoft.com/library/bb490302.aspx verfügbar ist, ausführlich dokumentiert.
Weitere Informationen zum Einrichten und Verwenden von BDD 2007 erhalten Sie im Artikel „Bereitstellen von Windows Vista mit BDD 2007" in der Ausgabe des TechNet Magazins vom September 2007 (technetmagazine.com/issues/2007/09/BDD).

BDD und SQL Server
Gründe zum Verwenden einer Datenbank mit BDD 2007 Die Gründe hängen davon ab, wie Sie während einer Bereitstellung die Details dynamisch bereitstellen, die Sie sonst manuell durch die Lite Touch-Installations-Assistenten eingeben müssten. Wie schon angemerkt, kann dies durch die CustomSettings.ini-Datei erreicht werden. Das Problem ist, dass sich diese Details in einer tatsächlichen Bereitstellung ändern werden, je nachdem, für welchen Computer Sie bereitstellen. Außerdem kann die CustomSettings.ini-Datei schnell unhandlich werden, wenn Sie versuchen, bestimmte Optionen und Einstellungen für 500 verschiedene Computer zu definieren. Durch Anfügen einer Back-End-Datenbank an die BDD-Konsole fügen Sie eine weit überschaubarere Lösung hinzu, die sowohl dynamisch als auch erweiterbar ist.
Im Folgenden wird näher untersucht, wie die Integration von SQL Server in BDD 2007 aussieht. Zuerst müssen Sie sicherstellen, dass SQL Server (vorzugsweise SQL Server 2005 oder höher) auf Ihrem Bereitstellungsserver installiert ist. Erfreulicherweise sind die Schritte zum Erstellen einer Datenbank in BDD 2007 einfach: Sie klicken mit der rechten Maustaste auf den Datenbankknoten in der BDD 2007 Deployment Workbench, klicken auf „Neu“ und folgen den Anweisungen (siehe Abbildung 2). Das BDD-Team hat sich viel Mühe gegeben, um Ihnen Assistenten zu bieten, mit denen Sie schnell und problemlos anfangen können.
Abbildung 2 Konfiguration der Bereitstellungsdatenbank für BDD 2007
Abbildung 2 Konfiguration der Bereitstellungsdatenbank für BDD 2007
Nachdem die Datenbank erstellt ist, können Sie ihre Funktionen untersuchen. Die Einträge in der Datenbank sind in vier Hauptkategorien unterteilt: „Computer“, „Role“ (Rolle), „Location“ (Standort) sowie „Make and Model“ (Marke und Modell). In jeder Kategorie können Sie Einträge definieren und für jeden definierten Eintrag die BDD 2007-Variablen auffüllen, Anwendungen zuordnen und andere wichtige Einstellungen bereitstellen (siehe Abbildung 3).
Abbildung 3 Zuweisen von Bereitstellungseigenschaften
Abbildung 3 Zuweisen von Bereitstellungseigenschaften
Es lohnt sich, diese vier Kategorien in zwei unterschiedlichen Gruppen zu betrachten. Die Kategorien „Computer“, „Standort“ und „Marke und Modell“ bieten Ihnen beim Erstellen verschiedene Methoden zum Identifizieren eines Computers. Jeder identifizierte Computer kann dann einer bestimmten Rolle in der Datenbank zugeordnet werden, damit er für einen bestimmten Zweck vorgesehen ist, wie zum Beispiel Vertrieb, Marketing oder Finanzen. Dabei stellt jede Rolle sicher, dass die relevanten Branchenanwendungen installiert werden.
Verwenden Sie den Abschnitt „Computer“, um Computer mithilfe einer MAC-Adresse, eines Bestandskennzeichens, des universellen eindeutigen Bezeichners (universal unique identifier, UUID) oder der Seriennummer zu identifizieren. Fügen Sie wegen der wahrscheinlich großen Anzahl der Einträge, die in diesem Abschnitt erstellt werden (ein Eintrag für jeden Computer in Ihrer Organisation), jedem Eintrag nur ganz bestimmte Eigenschaften wie „ComputerName“ hinzu.
Verwenden Sie den Abschnitt „Standort“, um Einträge für bestimmte geografische Orte in der Nähe Ihrer Organisation zu erstellen. Jeder Eintrag wird vom Standardgateway am jeweiligen Ort identifiziert. Dies kann besonders dann nützlich sein, wenn in Active Directory® ortsbasierte Organisationseinheiten enthalten sind und die Computer an einem Ort erstellt werden sollen, die der Domäne in der Organisationseinheit hinzugefügt werden sollen, die diesem Ort entspricht.
Verwenden Sie den Abschnitt „Marke und Modell“, um die Einträge für jeden Hardwaretyp zu erstellen, den Ihre Bereitstellung unterstützen muss. BDD 2007 stimmt diese mit Informationen ab, die es über WMI-Aufrufe einholt. Der Abschnitt „Marke und Modell“ in Entwicklungsumgebungen wird häufig dazu verwendet, einen Eintrag zu erstellen, der überprüft, ob es sich beim Computer um einen Virtual PC 2007- oder Virtual Server 2005-Computer handelt, indem er nach den entsprechenden „Marke und Modell“-Eigenschaften „Microsoft Corporation“ und „Virtueller Computer“ sucht. Wenn diese Eigenschaften zur Buildzeit zutreffen, können Sie BDD veranlassen, die Anwendung „Virtual Machine Additions“ zur Bereitstellungszeit einfach durch Hinzufügen der Anwendung zum „Marke und Modell“-Eintrag hinzuzufügen.
Nachdem Sie nun die Methoden zur Identifizierung der Computer bereitgestellt haben, verwenden Sie den Abschnitt „Rollen“, um die Einträge für jede Bereitstellungsrolle zu erstellen, die Sie festlegen möchten. Dazu gehört beispielsweise ein Eintrag für eine Windows XP-Rolle und eine Windows Vista-Rolle, die durch Hinzufügen der BuildID-Eigenschaft konfiguriert werden. Diese Eigenschaft entspricht dem Windows XP- oder Windows Vista-Build, der in BDD für jeden Eintrag definiert ist. Ein andere Vorgehensweise besteht darin, Abteilungsrollen anzugeben, z. B. Buchhaltung, Vertrieb oder Finanzen. Ich neige dazu, die Mehrzahl der BDD-Eigenschaften in diesem Abschnitt aufzufüllen (Zeitzone, regionale Einstellungen, Organisationsinformationen usw.). Dadurch fällt nur eine minimale Datenbankverwaltung an, da die Einträge nicht an einen bestimmten Computer, Standort oder eine bestimmte Hardware gebunden sind.
BDD 2007 muss mitgeteilt werden, dass es die Datenbank zur Bereitstellungszeit nach allen Einträgen durchsuchen soll, die mit dem Computer übereinstimmen, den es derzeit erstellt. Um BDD so zu konfigurieren, dass es während einer Bereitstellung die Datenbank verwendet, klicken Sie mit der rechten Maustaste auf Ihren Bereitstellungspunkt, und klicken Sie auf „Configure DB“ (DB konfigurieren). Sie werden als Nächstes durch eine Reihe von Assistenten geführt, von denen die CustomSettings.ini-Datei mit den Einträgen aufgefüllt wird, die dazu führen, dass der Lite Touch-Installationsvorgang Informationen in der Datenbank abfragt.

Erzielen einer skalierbaren Bereitstellung
Jetzt liegt Ihnen ein Bereitstellungsserver vor, der die Lite Touch-Installation automatisieren und jeden Computer dynamisch so bereitstellen kann, dass er in einer bestimmten Geschäftsrolle funktioniert. Doch wie kann diese Lösung skaliert werden?
Die Architektur der Lösung ist, wie in Abbildung 4 illustriert, um eine Hub-and-Spoke-Topologie herum aufgebaut. Der erste Bereitstellungsserver, den Sie einrichten, wird zum Hub und zum übergeordneten Bereitstellungsserver. Die untergeordneten Bereitstellungsserver dienen als Spokes.
Abbildung 4 Hub-and-Spoke-Bereitstellungsarchitektur
Abbildung 4 Hub-and-Spoke-Bereitstellungsarchitektur
Zum Aktivieren dieser Architektur müssen Sie DFS-R verwenden, um die Distributionsfreigabe für die jeweiligen Bereitstellungsserver zu replizieren. Verwenden Sie anschließend die SQL Server-Snapshotreplikation, um eine Kopie der BDD-Bereitstellungsdatenbank für die untergeordneten Bereitstellungsserver bereitzustellen. Diese Lösung ist großartig, weil die Anforderungen für die untergeordneten Bereitstellungsserver nur minimal sind. Sie müssen auf jedem Computer nur SQL Server Express, WDS und DFS-R installieren, um die Bereitstellung zu ermöglichen.
Aufgrund der großen Datenmenge, die in der BDD 2007-Distributionsfreigabe gespeichert werden kann, lege ich die Verwendung von DFS-R in Windows Server 2003 R2 statt der Dateireplikationsdienste in einer früheren Version von Windows Server fest. DFS-R verwendet Remotedifferenzialkomprimierung (Remote Differential Compression, RDC), um nur differenzielle (Delta-)Änderungen der Dateien unter den Mitgliedern der Replikationsgruppen zu replizieren. Dies kann große Auswirkungen auf den Umfang des Replikationsdatenverkehrs haben, wenn eine kleine Änderung wie ein neuer Treiber zu Ihrer benutzerdefinierten Abbilddatei gemacht wird. Bei DFS-R entspricht der Replikationsdatenverkehr nur der Größe der Änderungen, die statt der Neuverteilung der gesamten Abbilddatei vorgenommen werden.
Umfangreiche Informationen zu DFS erhalten Sie auf der Microsoft-Webseite. Einen guten Anfang stellt microsoft.com/windowsserver2003/technologies/storage/dfs dar, doch die grundlegenden Setup- und Konfigurationsschritte, die für einen Überblick über den Prozess im Kontext der BDD-basierten Bereitstellung notwendig sind, werden im Folgenden erläutert.
Beachten Sie Folgendes: Falls Active Directory von Ihren Servern auf Grundlage einer Installation von Windows Server 2003 vor R2 ausgeführt wird, muss das Active Directory-Schema möglicherweise aktualisiert werden, um DFS-R zu ermöglichen, da der Replikationsdienst neue Objektklassen erfordert. Umfassende Informationen zum Erweitern des Active Directory-Schemas in Windows Server 2003 R2 erhalten Sie unter go.microsoft.com/fwlink/?LinkId=99936.
Der erste Schritt besteht darin, die DFS-Komponenten auf Ihrem Windows Server 2003 R2-Bereitstellungsserver zu installieren. Dies kann auf unterschiedliche Weise erfolgen. Die einfachste Möglichkeit stellt der Standardassistent „Windows-Komponenten hinzufügen/entfernen“ dar. Sobald dies erfolgt ist, müssen Sie mithilfe der in Abbildung 5 dargestellten DFS-Verwaltungskonsole eine Replikationsgruppe einrichten.
Abbildung 5 DFS-Verwaltungskonsole
Abbildung 5 DFS-Verwaltungskonsole
Zum Skalieren Ihrer BDD 2007-Bereitstellungslösung gibt es zwei spezielle Ordner, die repliziert werden müssen. Der erste Ordner ist die BDD 2007-Distributionsfreigabe, die alle BDD-Quell- und Konfigurationsdateien enthält. Diese Dateien müssen auf jedem Bereitstellungsserver verfügbar sein.
Der zweite zu replizierende Ordner ist der Startordner, in dem WDS die LiteTouch_x86.wim-Datei speichert. Das ist die BDD-Startumgebung, die von WDS für Ihren Desktopclientcomputer bereitgestellt wird, um den Bereitstellungsprozess zu starten. Sie müssen diese Datei replizieren, damit die Änderungen, die auf Ihrem übergeordneten Bereitstellungsserver an der Startumgebung vorgenommen werden, für die restliche Bereitstellungsinfrastruktur repliziert werden.
Die zu replizierenden Pfade sind: „X:\Distribution“ (wobei X den Laufwerksbuchstaben darstellt, den Sie zur BDD 2007-Installationszeit angeben) und „Y:\RemoteInstall\boot“ (wobei Y den Laufwerksbuchstaben des Datenträgers darstellt, der die WDS-RemoteInstall-Freigabe enthält).
Die Replikation in DFS-R ist eine Multimasterreplikation. Deshalb ist es unmöglich, eine unidirektionale Replikationstopologie zu erstellen. Für eine zentrale Verwaltung der Distributionsfreigabe müssen Sie deshalb den Distributionsordner auf jedem untergeordneten Bereitstellungsserver so konfigurieren, dass er schreibgeschützt ist. Dadurch wird nur die DFS-R-Replikation in den Ordner geschrieben (da sie die Sicherungs- und Wiederherstellungsberechtigungen verwendet). Die Clientcomputer, die von diesen untergeordneten Servern abhängen, werden nie in diesen Ordner schreiben müssen. Es gibt also keinen Grund, die Leseberechtigung für die Konten zu erweitern.
Der letzte Konfigurationsschritt zum Abschluss der Datenreplikation mithilfe von DFS-R besteht darin, die Richtlinie für das Aktualisieren der Startkonfigurationsdaten in WDS festzulegen. Dadurch wird gewährleistet, dass alle Änderungen, die an Ihrer Startumgebung vorgenommen werden, auch in den einzelnen untergeordneten Bereitstellungsservern enthalten sind. Diese Konfigurationsänderung muss auf allen WDS-Servern festgelegt werden. Ich empfehle Ihnen, dies in Ihren Build- und Konfigurationsprozess für die Bereitstellung eines Bereitstellungsservers zu integrieren.
Führen Sie auf jedem Bereitstellungsserver den folgenden Befehl aus:
WDSUTIL /set-server /BCDRefreshPolicy /Enabled:yes /RefreshPeriod:<time in minutes>
Das Aktualisierungsintervall hängt davon ab, wie oft Sie die Daten auf den Bereitstellungsservern aktualisieren. Wenn Sie DFS-R so konfigurieren, dass jede Stunde repliziert wird, liegt es nahe, die Richtlinie für die Aktualisierung des BCD-Speichers so zu konfigurieren, dass die Aktualisierung alle 60 Minuten erfolgt.

SQL Server-Replikation
Bisher ging es um die Skalierung von BDD 2007 zur Replikation der BDD-Distributionsfreigabe und des WDS-Startabbilds von Ihrem primären Bereitstellungsserver auf die einzelnen untergeordneten Bereitstellungsserver. Sie müssen jetzt den Prozess abschließen und die BDD 2007 Deployment Workbench-Datenbank replizieren, damit sie lokal auf jedem Bereitstellungsserver verfügbar ist.
SQL Server verwendet eine Replikationsmethodik, die gemäß der Beschreibung in der Produktdokumentation der Art und Weise ähnelt, in der Zeitschriften veröffentlicht werden. Bei einer Zeitschrift gibt es einen Verleger, der die Zeitschrift herstellt, es gibt die Vertriebsabteilung, die die Zeitschrift für den Verleger vertreibt, und die Abonnenten, die die Zeitschrift abonnieren und erhalten. SQL Server verwendet die gleiche Terminologie für seine integrierten Replikationsfunktionen.
Beachten Sie Folgendes: Um ein SQL Server-Datenbankverleger zu sein, darf der Server nicht SQL Server Express Edition ausführen. Er muss eine Vollversion von SQL Server verwenden. Für den primären Bereitstellungsserver verwende ich SQL Server 2005 (obwohl SQL Server 2000 ebenfalls unterstützt wird). Für jeden untergeordneten Bereitstellungsserver können Sie entweder SQL Server 2005 oder SQL Server 2005 Express verwenden.
Vor dem Start der SQL Server-Replikation gibt es einige Schritte, die Sie ausführen sollten, um sicherzustellen, dass SQL Server ordnungsgemäß eingerichtet ist, um die Replikation zu unterstützen. Stellen Sie beim Bereitstellen Ihrer Bereitstellungsserver sicher, dass die Installation von SQL Server 2005 oder von SQL Server 2005 Express Edition die Replikationskomponenten einschließt. Standardmäßig installiert SQL Server Express die Replikationskomponenten nicht.
Als Nächstes muss gewährleistet sein, dass die Remoteverbindungen in SQL Server aktiviert sind, damit die Lite Touch-Startumgebung eine Remoteverbindung zu SQL Server herstellen kann. Starten Sie zum Konfigurieren von SQL Server für Remoteverbindungen das SQL Server-Tool zur Konfiguration der Oberfläche, wählen Sie „Oberflächenkonfiguration für Dienste und Verbindungen“, und konfigurieren Sie den Server, um sowohl lokale Verbindungen als auch Remoteverbindungen von TCP/IP und Named Pipes anzunehmen.
Erstellen Sie anschließend auf dem primären Bereitstellungsserver einen freigegebenen Ordner für die Replikationssnapshotdaten, die von den Replikationsagents auf jedem untergeordneten Bereitstellungsserver gelesen werden. Dieser freigegebene Ordner wird weiter unten näher erläutert. Ich erstelle diesen Ordner in der Regel auf dem gleichen Datenträger wie den Rest meines Bereitstellungsinhalts.
Die endgültigen Setupschritte sind nur für SQL Server Express Edition auf Ihren untergeordneten Bereitstellungsservern erforderlich. Standardmäßig ist der SQL Server-Browserdienst deaktiviert. Um die Replikation zu ermöglichen, muss dieser Dienst als automatisch festgelegt und gestartet werden. Verwenden Sie das SQL Server-Konfigurations-Manager-Tool, um diesen Dienst zu konfigurieren. Sie müssen außerdem eine Datenbank auf den untergeordneten Servern erstellen, auf die Sie den Inhalt replizieren werden. Behalten Sie für diesen Datenbanknamen denselben Namen wie für die BDD 2007-Datenbank auf dem primären Bereitstellungsserver bei, da dies die zusätzlich erforderliche Konfiguration minimiert.

Einrichten der Replikation
Sie sind jetzt bereit für das Konfigurieren der SQL Server-Replikation. Starten Sie als Erstes auf dem Masterbereitstellungsserver, auf dem die Vollversion von SQL Server 2005 ausgeführt werden muss, SQL Server Management Studio. Der erste Schritt besteht im Erstellen und Konfigurieren einer Distribution. Navigieren Sie dazu zum Replikationsordner der Verwaltungskonsole (siehe Abbildung 6). Klicken Sie mit der rechten Maustaste auf den Replikationsordner, und wählen Sie „Verteilung konfigurieren“ aus, um den Verteilungs-Assistenten zu starten.
Abbildung 6 SQL Server Management Studio: Replikation
Abbildung 6 SQL Server Management Studio: Replikation
Bestätigen Sie im Assistenten, dass der primäre Bereitstellungsserver als sein eigener Verteiler agieren soll. Legen Sie den Stammsnapshotordner als UNC-Pfad der SQL Server-Replikationsfreigabe fest, die zuvor erstellt wurde. Legen Sie schließlich fest, dass der primäre Bereitstellungsserver als Verleger konfiguriert wird.
Wenn dieser Assistent den Server erfolgreich als Verleger und Verteiler konfiguriert hat, müssen Sie SQL Server mitteilen, welche Datenbank veröffentlicht werden soll. Klicken Sie dazu mit der rechten Maustaste auf den Replikationsordner und dann auf „Verlegereigenschaften“. Wählen Sie im Dialogfeld „Eigenschaften“ die Veröffentlichungsdatenbanken und Ihre BDD 2007-Datenbank für die Transaktionsreplikation aus (siehe Abbildung 7). Genau genommen verwenden Sie jetzt die Transaktionsreplikation nicht, doch diese Option wird unabhängig davon, ob Sie eine Snapshot- oder Transaktionsreplikation planen, ausgewählt.
Abbildung 7 Veröffentlichen Ihrer Datenbank
Abbildung 7 Veröffentlichen Ihrer Datenbank
Sie müssen jetzt eine Veröffentlichung erstellen, die Ihre untergeordneten Bereitstellungsserver abonnieren können. Klicken Sie im Replikationsordner mit der rechten Maustaste auf „Lokale Publikationen“ und dann auf „Neue Publikation“, um den Veröffentlichungs-Assistenten zu starten. Wählen Sie die BDD-Datenbank als zu veröffentlichende Datenbank aus. Wählen Sie Snapshotreplikation als Veröffentlichungstyp aus, und geben Sie alle zu replizierenden Tabellen, gespeicherten Verfahren und Ansichten an. Es empfiehlt sich, sofort einen anfänglichen Snapshot erstellen zu lassen. Zum Planen des Snapshotagents ist es völlig ausreichend, ihn einmal pro Tag standardmäßig auszuführen, es sei denn, es sind häufige Änderungen an der Datenbank absehbar.
Der letzte Schritt besteht darin, diese Veröffentlichung für jeden untergeordneten Bereitstellungsserver zu abonnieren. Dadurch wird SQL Server aufgefordert, in den angegebenen Abständen mittels Push jedem untergeordneten Bereitstellungsserver eine Kopie der Datenbank zukommen zu lassen. Gehen Sie im Replikationsordner, unterhalb des Unterordners „Lokale Publikationen“, zur gerade erstellten Veröffentlichung, klicken Sie mit der rechten Maustaste darauf, und wählen Sie „New subscriptions“ (Neue Abonnements) aus, um den Abonnement-Assistenten zu starten. Wählen Sie in diesem Assistenten die BDD-Veröffentlichung aus, die in den vorherigen Schritten als die ausgewählte Veröffentlichung erstellt wurde. Aktivieren Sie die Option zum Ausführen aller Agents bei der Verteilung, wodurch die Replikationstopologie als Pushabonnement ermöglicht wird. Fügen Sie dann jeden untergeordneten Bereitstellungsserver als Abonnenten hinzu, und geben Sie die auf jedem Server erstellte Datenbank an, die eine Kopie der replizierten Daten erhalten soll. (Denken Sie daran, dass die Namen der Datenbank und der primären Bereitstellungsdatenbank identisch sein müssen.) Konfigurieren Sie schließlich ein Konto für die Verbindungen, und definieren Sie den Zeitplan für die Replikation. Er sollte den Zeitplan widerspiegeln, den Sie für den Snapshotagent ausgewählt haben. In diesem Artikel wurde eine ganze Reihe von Anforderungen erörtert, die Sie benötigen, um mit der SQL Server-Replikation loslegen zu können. Sie werden jetzt sicher erkennen können, wie die Daten im Handumdrehen repliziert werden.

Konfigurieren von BDD 2007
Bislang haben Sie BDD 2007 so konfiguriert, dass es eine Datenbank verwendet und die Replikation der Datenbank und der BDD 2007-Distributionsfreigabe auf Ihre untergeordneten Bereitstellungsserver einrichtet. Zum Abschluss der Bereitstellungslösung müssen Sie BDD 2007 konfigurieren, sodass es automatisch eine Verbindung zu seinem entsprechenden lokalen Bereitstellungsserver herstellt, wenn ein Client die BDD-Startumgebung herunterlädt.
Wenn Sie in der Lite Touch-Windows PE-Umgebung starten und falls der Client von einem WDS-Server gestartet wurde, wird ein Registrierungswert in Windows PE festgelegt, der den Namen des Servers speichert, von dem der Client gerade die Startumgebung heruntergeladen hat. Dieser Wert wird von den anfänglichen BDD 2007-Bereitstellungsskripts abgerufen und in einer Umgebungsvariablen namens „%WDSServer%“ gespeichert.
Beachten Sie Folgendes: Wenn Sie die anfängliche BDD 2007-Version verwenden, wird dieser Wert möglicherweise nicht ordnungsgemäß in der Windows PE-Registrierung aufgefüllt. Ein Update zur Korrektur dieses Verhaltens ist unter support.microsoft.com/kb/937191 verfügbar.
Bearbeiten Sie zum Konfigurieren von BDD 2007 nur die Konfigurationsdateien „BootStrap.ini“ und „CustomSettings.ini“, damit alle Verweise zum Bereitstellungsserver durch „%WDSServer%“ ersetzt werden. Dazu gehört in der Regel, dass Sie die Werte für den SQL Server-Instanznamen dabei durch den Wert von DeploymentRoot (dem Server, der die Distributionsfreigabe enthält) ersetzen. In Abbildung 8 und Abbildung 9 werden eine Bootstrap.ini-Beispieldatei und ein Auszug aus der CustomSettings.ini-Datei angezeigt.
Figure 9 CustomSettings.ini (Close Figure 9)
[Settings]
Priority=MMSettings, MMApps, CSettings, CRoles, RSettings, RApps, Default
Properties=Manufacturer

[Default]
OSInstall=Y
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234

[CSettings]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerSettings
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR

[CRoles]
SQLServer=%WDSServer%
Database=BDD_DB1
Netlib=DBNMPNTW
Table=ComputerRoles
Parameters=UUID, AssetTag, SerialNumber, MacAddress
ParameterCondition=OR
Figure 8 Bootstrap.ini (Close Figure 8)
[Settings]
Priority=Default

[Default]
DeployRoot=\\%WDSServer%\Distribution$
UserDomain=BUILDLAB
UserID=BddAdmin
UserPassword=Password1234
SkipBDDWelcome=YES
Beachten Sie, dass diese Lösung vorschreibt, dass sich WDS auf dem gleichen Server befindet, auf dem die replizierte BDD 2007-Datenbank und die replizierte BDD 2007-Distributionsfreigabe gespeichert sind. Die Gründe dafür sind leicht nachvollziehbar: Dadurch können Sie mithilfe der %WDSServer%-Variablen eine einfache zuverlässige Methode bereitstellen, um Ihrem Clientcomputer den Standort seines Bereitstellungsservers mitzuteilen und ein Talk Back über WAN zu verhindern.

Weitere Überlegungen
Das Gute an BDD 2007 ist, dass es erweiterbar ist. Es gibt also noch viele weitere Aspekte dieser Lösung, die erweitert werden könnten. Zum Beispiel könnten Sie die integrierten Funktionen zum Überwachen von SQL Server und DFS-R, zum Entwerfen von Methoden für das Auffüllen der Computer Ihrer Umgebung mit Informationen aus einer Ressourcenverwaltungs-Datenbank oder sogar für den Einsatz eines gespeichertes SQL-Verfahrens zum Abrufen solcher Informationen verwenden. Leider können diese Themen in diesem Artikel nicht behandelt werden, doch es bleibt zu hoffen, dass Sie hier eine Vorstellung von einigen der Möglichkeiten erhalten haben, wie Sie die Fähigkeiten von BDD innerhalb Ihrer eigenen Organisation nutzen können.

Adam Shepherd ist als Berater für Microsoft Consulting Services in Großbritannien tätig. Sein technischer Schwerpunkt ist das Bereitstellen, Warten und Verwalten des Windows-Clients. Sie können Adam Shepherd unter adamshep@microsoft.com erreichen.


 Kommunikation: Exchange-Edge-Transport-Server bei Microsoft: Teil&#160;2
Kommunikation Kay Unkroth

Exchange-Edge-Transport-Server bei Microsoft: Teil 2
Kurz zusammengefasst:
  • Verwenden von Edge-Transport-Protokollen und -Ablaufverfolgungen
  • Antispamkonfiguration mit Skripts
  • Testen typischer Spamszenarios
Laden Sie den Code für diesen Artikel herunter: Edge2007_11.exe (161KB)

Wie können Sie angesichts einer Flut von Spam und anderen schädlichen Inhalten, die das Internet überschwemmen, für die Benutzer innerhalb Ihrer Organisation ein zuverlässiges und sicheres Messaging gewährleisten? Eine Möglichkeit, die im letzten Monat im ersten Teil dieser Reihe beschrieben wurde, besteht darin,
Edge-Transport-Server für Exchange Server 2007 und Forefront Security für Exchange Server in einem Umkreisnetzwerk zwischen dem Internet und der Produktionsumgebung bereitzustellen.
In diesem zweiten und letzten Teil der Artikelreihe wird erläutert, wie sich aktuell ausgeführte Edge-Transport-Agents durch Standardfeatures von Exchange Server 2007 für Agentprotokollierung und -ablaufverfolgung analysieren lassen. Dabei wird auch eine benutzerdefinierte Methode verwendet, um alle Ereignisobjekte aus der Transportpipeline in XML-basierten Dateien zu sichern. Danach wird aufgezeigt, wie Antispameinstellungen gemäß der von Microsoft in der eigenen unternehmensinternen Produktionsumgebung verwendeten Konfiguration auf eine Edge-Transport-Testumgebung angewendet werden. Zum Schluss wird anhand einiger realistischer und interessanter Testszenarios vorgeführt, wie Edge-Transport-Agents auf verschiedene Spamsituationen reagieren.
Weitere Informationen zur Installation der Edge-Transport-Testumgebung und zur allgemeinen Edge-Transport-Architektur finden Sie im ersten Artikel dieser Reihe in der im Oktober 2007 erschienenen Ausgabe des TechNet Magazins, der unter technetmagazine.com/issues/2007/10/Edge verfügbar ist.
Zur Automatisierung der wichtigsten Konfigurationsaufgaben wurden zahlreiche Skripts und Batchdateien verwendet. Diese Skripts finden Sie im Codedownload zu diesem Artikel (unter technetmagazine.com/code07.aspx). Empfehlenswert für ausführlichere Hintergrundinformationen zur von Microsoft verwendeten IT-Konfiguration von Edge-Transport-Agents ist das technische Whitepaper „Microsoft® Exchange Server 2007-Edge-Transport und -Messagingschutz“, das für Microsoft IT Showcase erstellt wurde. Sie können dieses IT Showcase-Whitepaper von microsoft.com/technet/itshowcase/content/edgetransport.mspx herunterladen.

Protokollierung und Ablaufverfolgung
Exchange Server 2007 umfasst eine Reihe von Protokollierungs- und Ablaufverfolgungsfeatures einschließlich der Protokollprotokollierung, der Agentprotokollierung und der Pipelineablaufverfolgung, durch die Diagnose und Problembehandlung von Transport-Agent-Problemen erleichtert werden. Obwohl sich dieser Artikel eigentlich nicht mit der Fehlerbehebung von Transport-Agents beschäftigt, sind die Protokollierungs- und Ablaufverfolgungsinformationen nützlich, um die Funktionsweise von Edge-Transport-Agents zu verstehen.
Wenn Sie Informationen zu SMTP-Sende- und -Empfangsaktivitäten verfolgen möchten, müssen Sie für Sende- und Empfangsconnectors die Protokollprotokollierung aktivieren. Unter Verwendung der im ersten Teil dieser Reihe eingerichteten Testumgebung (siehe Abbildung 1) wurde über die folgende Einstellung in den New-SendConnector- und New-ReceiveConnector-Cmdlets die Protokollprotokollierung aktiviert:
Abbildung 1 Die Testumgebung
Abbildung 1 Die Testumgebung
–ProtocolLoggingLevel: Verbose
Die generierten SMTP-Protokolldateien sind standardmäßig in Unterordnern des Ordners %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\ProtocolLog zu finden.
Die Protokollprotokollierung ist für eine Analyse des SMTP-Nachrichtenaustauschs nützlich, denn Antispam-Agents greifen nicht immer in die SMTP-Sitzung ein. So kann es beispielsweise vorkommen, dass der Inhaltsfilter-Agent nur eingehende Nachrichten mit einem SCL (Spam Confidence Level)-Wert versieht. Solange der SCL-Wert unter einem festgelegten Grenzwert (Standardeinstellung: 7) liegt, veranlasst der Inhaltsfilter-Agent nicht, dass die Nachricht vom Edge-Transport-Prozess zurückgewiesen wird. Daher wird der SMTP-Nachrichtenaustausch unbeeinträchtigt fortgesetzt.
Um die Aktionen zu analysieren, die diese Antispam-Agents (Verbindungsfilter, Inhaltsfilter, Edge-Regeln, Empfängerfilter, Absenderfilter und Absender-ID) an den Nachrichten durchführen, die die Transportpipeline durchlaufen, müssen Sie statt der Protokollprotokolle die Agentprotokolle überprüfen. Die Agentprotokollierung wird normalerweise über den AgentLogEnabled-Parameter in der Datei „EdgeTransport.exe.config“ aktiviert. Standardmäßig befinden sich Agentprotokolle im Ordner %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\AgentLog. Sie können die Protokolle zwar auch in Editor öffnen, aber das Get-AgentLog-Cmdlet zeigt die Informationen der Agentprotokolle intuitiver in der Exchange-Verwaltungsshell an.
Ein weiteres nützliches Feature ist die Pipelineablaufverfolgung, die es ermöglicht, Snapshots der von einem bestimmten Absender gesendeten Nachrichten aufzuzeichnen, während die Nachrichten die Transportpipeline durchlaufen. Diesem Vorgang liegt eine relativ einfache Idee zugrunde: Der Edge-Transport-Prozess erstellt von jeder Nachricht einen Snapshot, bevor und nachdem die für die Ereignisse „OnEndOfHeaders“, „OnEndofData“, „OnSubmittedMessage“ und „OnRoutedMessage“ registrierten SMTP-Empfangs- und Routing-Agents aufgerufen werden. Durch einen Vergleich der Nachrichtensnapshots können Sie erkennen, wie jede Nachricht von den einzelnen Agents verändert wird. Natürlich sollte dieses nützliche Feature unbedingt in der Testumgebung aktiviert werden.
Durch Verwendung des Set-TransportServer-Cmdlets wie hier gezeigt wird die Pipelineablaufverfolgung für einen Testbenutzer aktiviert. Wie zu erwarten ist, aktiviert der auf „$true“ eingestellte PipelineTracingEnable-Parameter die Pipelineablaufverfolgung. Die E-Mail-Adresse des Testbenutzers wird über den PipelineTracingSenderAddress-Parameter festgelegt:
Set-TransportServer –Identity EDGE01
–PipelineTracingEnabled $true
-PipelineTracingSenderAddress Contoso.User@contoso.com
Wenn die Pipelineablaufverfolgung aktiviert ist, sind im Ordner %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing\MessageSnapshots Nachrichtensnapshotdateien für jede vom festgelegten Absender (in diesem Fall heißt der Benutzer „Contoso.User@contoso.com“) gesendete Nachricht verfügbar Dies ist der Standardordner. Die Snapshotdateien für jede Nachricht befinden sich in einem Unterverzeichnis, das gemäß einer der betreffenden Nachricht zugewiesenen GUID benannt wurde. Beachten Sie, dass die ursprüngliche Nachricht in einer Datei namens „Original.eml“ und Kopien der Nachricht in .eml-Dateien zu finden sind, deren Dateinamen abhängig von den aufgetretenen Ereignissen und den installierten Agents mit „SmtpReceive“ oder „Routing“ beginnen. Überprüfen Sie zum Analysieren der für die SMTP-Empfangsereignisse „OnEndofData“ und „OnEndOfHeaders“ registrierten Antispam-Agents die mit „SmtpReceive“ beginnenden .eml-Dateien. Wenn Sie die Verarbeitung von Antivirus-Agents und anderen Agents analysieren möchten, die für die Routingereignisse „OnSubmittedMessage“ und „OnRoutedMessage“ registriert sind, dann überprüfen Sie stattdessen die mit „Routing“ beginnenden .eml-Dateien.

Benutzerdefinierte Pipelinesicherung
Die Standardfeatures von Exchange Server 2007 für Agentprotokollierung und -ablaufverfolgung erfüllen trotz der Tatsache, dass die Standardfeatures nicht alle Transportereignisse abdecken, sämtliche Problembehandlungsanforderungen. So kann die Pipelineablaufverfolgung beispielsweise keine Informationen zu „OnConnectEvent“, „OnEhloCommand“, „OnMailCommand“, „OnRcptCommand“, „OnDataCommand“ und ähnlichen Transportereignissen aufzeichnen, weil der sendende Host noch keine Nachrichten übertragen hat, die in den Ordner %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineTracing geschrieben werden könnten. Wenn Sie ausführliche Informationen zu diesen Ereignissen aufzeichnen möchten, müssen Sie einen benutzerdefinierten Agent implementieren, der die Ereignisdaten in Dateien auf dem Dateisystem sichert.
Wie im vorherigen Artikel erläutert wurde, ist das Erstellen benutzerdefinierter Agents nicht schwer, und daher bot es sich an, einen SMTP-Empfangs-Agent und einen Routing-Agent zu erstellen, um alle Ereignisobjekte aus der Transportpipeline in XML-Dateien zu sichern. Im Download für diesen Artikel finden Sie ein entsprechendes Microsoft Visual Studio® 2005-Projekt namens „PipelineXMLDump“. Wichtig sind zwei Dateien, „DumpAgents.cs“, von der die Agent-Factorys und Agents implementiert werden, und „XMLDump.cs“, die eine Hilfsklasse implementiert, um mithilfe von System.Reflection-Methoden die Felder von Ereignisquell- und Ereignisargumentobjekten in XML-Dateien zu schreiben. Wenn Sie den Quellcode kompilieren und die dadurch entstehende Datei „PipelineXMLDump.dll“ in einen Ordner namens C:\PipelineXMLDump auf dem Edge-Transport-Testserver kopieren, können Sie die benutzerdefinierten Agents mithilfe der RegisterPipelineXMLDump.ps1- und EnableDumpAgents.ps1-Skripts registrieren und aktivieren. Die Skripts sind im Download im PipelineXMLDump-Projektordner enthalten. Die benutzerdefinierten Agents dienen natürlich lediglich zu Demonstrationszwecken, wurden nicht ausreichend getestet und sollten nie auf einem Produktionsserver installiert werden. Die Verwendung dieser Agents ist auf eigene Gefahr.
In der Datei „DumpAgents.cs“ wird aufgezeigt, wie Sie alle SMTP-Empfangs- und Routing-Ereignishandler implementieren können, die von der Transportpipeline unterstützt werden. Sie ist eine gute Ausgangsbasis, wenn Sie Ihre eigenen benutzerdefinierten Agents implementieren möchten. Die Sicherungsagents in diesem Beispiel schreiben XML-Dateien in Unterordner des Ordners %ProgramFiles%\Microsoft\Exchange Server\TransportRoles\Logs\PipelineXMLDump, die dem Bezeichner der SMTP-Sitzung (SMTP-Empfangs-Agent) oder dem Nachrichtenbezeichner (Routing-Agent) entsprechen. Abbildung 2 enthält ein Beispiel für Ereignisargumentinformationen, die im OnConnectEvent-Handler dem SMTP-Empfangs-Agent übergeben werden. Dieses Beispiel zeigt den lokalen IP-Endpunkt (IP-Adresse und Port), der eine eingehende Verbindungsanforderung akzeptiert hat.
Abbildung 2 Während des OnConnect-Ereignisses gesicherte Argumentinformationen
Abbildung 2 Während des OnConnect-Ereignisses gesicherte Argumentinformationen

Vorbereiten der Testläufe
Doch damit genug der Theorie des Protokollierens, der Ablaufverfolgung und des Sicherns. Im Folgenden werden einige Testläufe ausgeführt, um Ihnen die Antispam-Agents in Aktion vorzuführen. Zunächst folgt ein kurzer Überblick der Konfiguration Ihrer Testumgebung, die der IT-Konfiguration von Microsoft so weit wie möglich entspricht. Wie bereits erwähnt sind im technischen Whitepaper „Microsoft Exchange Server 2007-Edge-Transport und -Messagingschutz“ Hintergrundinformationen verfügbar.
Deaktivieren Sie zunächst durch Ausführen des im begleitenden Download enthaltenen Skripts „EDGE01_disable_agents.ps1“ die Agents Address Rewriting Inbound (eingehende Adressumschreibung), Attachment Filter (Anlagenfilter) und Address Rewriting Outbound (ausgehende Adressumschreibung). Eine Adressumschreibung ist nicht erforderlich, weil die Empfänger sowohl intern als auch extern dieselben E-Mail-Adressen verwenden. Ich verwende den Anlagenfilteragent deshalb nicht, weil in Forefront Security vorrangige Anlagenfilterfunktionen verfügbar sind.
Die Testumgebung ist nicht mit dem Internet verbunden. Dies erschwert die Aufgabe, den Verbindungsfilter-Agent zu testen. Um dieses Problem zu beheben, können Sie auf dem Internethost eine IP-Sperrliste erstellen, indem Sie die Datei „INTERNET01_create_IP_block_list.bat“ ausführen. Stellen Sie sicher, dass die Windows®-Supporttools installiert sind, da sie das DNS-Befehlszeilentool (dnscmd.exe) enthalten. Andernfalls müssen die DNS-Einträge zeitaufwändig über die DNS-Konsole manuell erstellt werden.
Nun können Sie den Verbindungsfilter-Agent durch Ausführen des Skripts „EDGE01_add_block_list_provider.ps1“ konfigurieren. Dieses Skript fügt ip-bl.consolidatedmessenger.com einen IP-Sperrlistenanbieter hinzu. Dies ist die IP-Sperrliste von Consolidated Messenger, die in der Testumgebung bereits erstellt wurde, indem auf dem Internethost, wie bereits erwähnt, die Datei „INTERNET01_create_IP_block_list.bat“ ausgeführt wurde. In der IT-Konfiguration von Microsoft wird ebenfalls die lokale IP-Sperrliste und die lokale IP-Zulassungsliste verwendet, aber diese Features erfordern keine manuelle Konfiguration. An dieser Stelle ist es wichtig, darauf hinzuweisen, dass bei Microsoft keine IP-Zulassungslistenanbieter verwendet werden.
Konfigurieren Sie im nächsten Schritt durch Ausführen des EDGE01_recipient_filter.ps1-Skripts den Empfängerfilter-Agent so, dass sowohl Nachrichten an nicht existierende Empfänger als auch Nachrichten an Postfächer und globale Verteilerlisten, die nur zur internen oder ausgehenden Verwendung vorgesehen sind, blockiert werden.
Die Konfiguration des Absenderfilter-Agent muss ebenfalls aktualisiert werden. In der IT-Konfiguration von Microsoft wird als Gegenmaßnahme zum Schutz gegen Angriffe durch eine Überschwemmung mit E-Mails von bestimmten Absenderadressen und zum Blockieren bestimmter Listenserver und ähnlicher Quellen, die für das Unternehmen als irrelevant erachtet werden, ebenfalls Absenderfilterung verwendet. Absenderfilterung wird in der IT-Konfiguration von Microsoft auch dafür eingesetzt, Nachrichten mit ungültigen oder fehlenden Absenderangaben zu blockieren. Wenden Sie diese Konfiguration auf die Testumgebung an, indem Sie auf dem Edge-Transport-Server das EDGE01_sender_filter.ps1-Skript ausführen.
Sie müssen auch SPF (Sender Policy Framework)-Datensätze im DNS konfigurieren, wenn Sie die IT-Konfiguration von Microsoft nachahmen möchten. Zum Generieren eines SPF-Datensatzes, der die Befugnis Ihres Edge-Transport-Servers für Nachrichten aus Ihrer Domäne (adventure-works.com) attestiert, können Sie den SPF-Datensatzassistent von Sender ID Framework (SIDF) von Microsoft verwenden, der über die Website microsoft.com/mscorp/safety/content/technologies/senderid/wizard verfügbar ist. Geben Sie versuchsweise einen existierenden Internet-Domänennamen an. In der Testumgebung können Sie die Datei „INTERNET01_create_SPF_record.bat“ auf dem Internethost ausführen.
Das ist schon alles. Es müssen keine weiteren Parameter konfiguriert werden, weil die meisten Agents sinnvolle Standardeinstellungen besitzen. Um eine schnelle Überprüfung der wichtigsten Standardeinstellungen für den Edge-Regeln-Agent, den Absender-ID-Agent, den Protokollanalyse-Agent und den Inhaltsfilter-Agent durchzuführen, führen Sie das EDGE01_check_defaults.ps1-Skript auf dem Edge-Transport-Server aus.

Edge-Transport-Agents in Aktion
Nun werden die Edge-Transport-Agents in einigen realistischen Messagingszenarios eingesetzt. Um Testnachrichten an den Edge-Transport-Server zu senden, wird als Messaging-Client der in Windows Server 2003 und Outlook® Express enthaltene SMTP- und POP3-Dienst verwendet, wobei in den meisten Fällen die Standardeinstellungen beibehalten werden, die Protokollierung allerdings immer aktiviert ist.
Doch zunächst eine Warnung: Führen Sie keinen der in diesem Abschnitt beschriebenen Schritte und keines dieser Skripts aus, wenn Ihre Testumgebung mit einem Produktionssystem oder dem Internet verbunden ist. Sie testen auf eigene Gefahr.
Der erste hier getestete Agent ist der Verbindungsfilter-Agent. Dieser Agent verdient es, an erster Stelle zu stehen, weil er auf einem Edge-Transport-Server die Schwerarbeit leistet. Bei Microsoft blockiert der Verbindungsfilter-Agent ungefähr 88 Prozent aller Internet-Nachrichtenübermittlungen. Von 13 Millionen Übertragungsversuchen, die an einem normalen Arbeitstag unternommen werden, stammen nur ungefähr 1,5 Millionen von legitimen Absendern.
Senden Sie also als „Fabrikam.User@Fabrikam.com“ eine E-Mail an „Administrator@adventure-works.com“. Wenn alles richtig funktioniert, dürfte der Administrator die Nachricht nicht erhalten. Stattdessen müsste „Fabrikam.User“ eine Benachrichtigung über den Zustellungsstatus (Delivery Status Notification, DSN) erhalten, die besagt, dass die Zustellung der E-Mail an diesen Empfänger fehlgeschlagen ist. Der Benutzer „Fabrikam.User“ überprüft die Richtigkeit der E-Mail-Adresse, sendet dieselbe Nachricht erneut und erhält wieder eine DSN. Danach ruft „Fabrikam.User“ den Helpdesk an und meldet das Problem. Er ist nicht der erste Benutzer, der sich an den Helpdesk wendet. Tatsächlich kann überhaupt niemand mehr bei Fabrikam mit Adventure Works kommunizieren. Es ist ein Problem aufgetreten, das dringend behoben werden muss. Für eine schnelle Problemlösung überprüfen Sie die SMTP-Protokolle im Ordner %systemroot%\system32\Logfiles\SMTPSVC1 auf INTERNET01 und stoßen auf das, was der rote Text in Abbildung 3 zeigt.
Figure 3 SMTP-Protokolle machen das Problem sichtbar (Close Figure 3)
... 220 mail.adventure-works.com Microsoft ESMTP MAIL Service ready at Thu,
31 May 2007 12:21:33 -0700,
... EHLO, -, INTERNET01,
... 250-mail.adventure-works.com Hello [192.168.1.100],
... MAIL, -, FROM:<Fabrikam.User@fabrikam.com> SIZE=840,
... 250 2.1.0 Sender OK,
... RCPT, -, TO:<Administrator@adventure-works.com>,
... 550 5.7.1 E-mail rejected because your IP address is listed by
ip-bl.consolidatedmessenger.com. Please visit
http://www.consolidatedmessenger.com/ip-bl for more information.
If you still need assistance, contact cmipbl@adventure-works.com.,
... RSET, -, -,
... 250 2.0.0 Resetting,
... QUIT, -, -,
... 221 2.0.0 Service closing transmission channel,
Fehler 550 besagt, dass Consolidated Messenger die IP-Adresse Ihres Internethosts in eine IP-Sperrliste aufgenommen hat. Das erklärt natürlich die Sache. Sie kontaktieren Consolidated Messenger, um aus dieser Liste entfernt zu werden. Wie es sich herausstellt, ist es leichter, in die Sperrliste von Consolidated Messenger aufgenommen als aus ihr entfernt zu werden. Es wird Tage oder vielleicht sogar Wochen dauern, um hier wieder Ordnung zu schaffen.
Sie müssen jedoch schneller Abhilfe schaffen, und deshalb wenden Sie sich über die E-Mail-Adresse „cmipbl@adventure-works.com“ an Adventure Works. Sie senden eine E-Mail als „Fabrikam.Admin@Fabrikam.com“, beschreiben die Lage und bitten darum, die Blockierung der Internet-IP-Adresse Ihres Hosts (192.168.1.100) aufzuheben. Nach Überprüfung Ihrer Identität hebt Adventure Works mithilfe des folgenden Befehls, der eine nach 30 Tagen automatisch endende temporäre Ausnahme gewährt, die Blockierung der Adresse auf:
Add-IPAllowListEntry -IPAddress 192.168.1.100
-ExpirationTime (get-date).AddDays(30)
Dreißig Tage müssten genügen, um das Problem mit Consolidated Messenger zu regeln, und Adventure Works muss keine Zeit dafür aufwenden, die Ausnahme manuell zu warten. Durch Gewähren von Ausnahmen, die automatisch beendet werden, hält Adventure Works den mit der Verwaltung von IP-Zulassungslisten verbundenen zusätzlichen administrativen Aufwand so gering wie möglich.

Sicherer Absender
Testen Sie im nächsten Schritt die Fähigkeit der Inhaltsfilterung, sichere Absender zu erkennen, denn dies ist ein interessantes neues Feature, durch das die Spamfilterung präziser arbeitet. „EdgeSync“ überträgt aus der internen Umgebung Informationen über sichere Absender in auf Hashwerten basierendem und verschlüsseltem Format an Edge-Transport-Server. Der Inhaltsfilter-Agent verwendet diese Informationen während des Filterungsprozesses, um auf Daten basierende intelligente Entscheidungen zu treffen. Sie müssen lediglich die Informationen über sichere Absender (d. h. die Liste der sicheren Absender, die Liste der sicheren Empfänger, die Liste der blockierten Absender und die externen Kontakte) mithilfe des Update-SafeList-Cmdlets in Active Directory® einlesen und diese Informationen anschließend mithilfe des Start-EdgeSynchronization-Cmdlets auf dem Edge-Transport-Server replizieren. In der IT-Konfiguration von Microsoft wird in Zeiten mit geringem Arbeitsaufkommen regelmäßig das Update-SafeList-Cmdlet ausgeführt. In Ihrer Testumgebung genügt es, ein entsprechendes Skript (HUB-MBX-01_update_safelist.ps1) manuell auszuführen.
Bereinigen Sie zunächst die Testumgebung, indem Sie das EDGE01_clean_up.ps1-Skript auf dem Edge-Transport-Server ausführen, um den zuvor erstellten IP-Zulassungslisteneintrag zu entfernen. Dies ist erforderlich, weil der Inhaltsfilter-Agent auf Nachrichten aus Quellen, die in dieser Liste eingetragen sind, nicht reagiert. Entfernen Sie danach den IP-Sperrlisteneintrag für 100.1.168.192.ip-bl.consolidatedmessenger.com aus der Consolidated Messenger-Sperrliste, indem Sie die Datei „INTERNET01_clean_up.bat“ auf dem Internethost ausführen. Andernfalls kann der simulierte Internethost, wie bereits demonstriert wurde, keine Nachrichten senden.
Senden Sie zum Schluss eine Nachricht, die der Inhaltsfilter-Agent mit fast absoluter Sicherheit als Spam betrachten wird. Dies ist schwierig, da der Inhaltsfilter-Agent zum Zustellen der meisten Nachrichten an die Benutzer den standardmäßigen SCL-Zurückweisungsgrenzwert verwendet, um die Anzahl falscher Positivdiagnosen möglichst gering zu halten. Nach einigen Tests habe ich jedoch eine Nachrichtenversion gefunden, die die SCL-Bewertung bis auf die Zurückweisungsstufe hochtreibt. Um die Nachricht als „Contoso.User@Contoso.com“ zu senden, führen Sie das Skript „INTERNET01_contoso_msg.vbs“ auf dem Internethost aus.
In diesem Skript wird eine anonyme SMTP-Verbindung verwendet, um die Nachricht an den SMTP-Dienst auf INTERNET01 zu senden. Damit es funktioniert, müssen Sie den SMTP-Dienst so konfigurieren, dass Nachrichten anonymer Benutzer weitergeleitet werden. Öffnen Sie in IIS Manager die Eigenschaften für den virtuellen SMTP-Standardserver. Klicken Sie auf der Registerkarte „Access“ (Zugriff) auf die Schaltfläche „Relay“ (Weiterleiten), und wählen Sie danach die Option „All except the list below“ (Alle außer der unten stehenden Liste) aus. Die Auswirkungen dieser Konfiguration werden etwas weiter unten erläutert.
Wenn Sie das Skript ausführen, um diese Nachricht zu senden, müsste „Contoso.User“ eine DSN erhalten, die besagt, dass die Zustellung aus folgendem Grund fehlgeschlagen ist: Diagnostic-Code: smtp;550 5.7.1 Message rejected due to content restrictions (Nachricht aufgrund von Inhaltsbeschränkungen zurückgewiesen). Diese Antwort ist auch im SMTP-Protokoll auf dem Internethost aufgeführt, und wenn Sie den Befehl „Get-AgentLog“ | „Select-Object -Last 1“ auf dem Edge-Transport-Server ausführen, um den letzten Eintrag des Agentprotokolls anzuzeigen, erkennen Sie, dass die Nachricht zurückgewiesen wurde, weil sie die SCL-Bewertung 7 besitzt, wie in Abbildung 4 zu sehen ist.
Abbildung 4 Aufgrund von Inhaltsbeschränkungen blockierte Nachricht
Abbildung 4 Aufgrund von Inhaltsbeschränkungen blockierte Nachricht
Allerdings ist „Contoso.User“ kein Spammer. Bedauerlicherweise wurde die Nachricht in diesem Fall nicht durchgelassen, aber normalerweise kann „Contoso.User“ mit Empfängern bei Adventure Works kommunizieren. Daher informiert „Contoso.User“ in einer weiteren E-Mail den Administrator, dass die ursprüngliche Nachricht versehentlich blockiert wurde. Der Administrator kennt „Contoso.User“ und nimmt „Contoso.User“ in die Liste der sicheren Absender auf, um sicherzustellen, dass seine Nachrichten zukünftig nicht mehr durch Spamfilter blockiert werden. Um dies in Office Outlook 2007 durchzuführen, klicken Sie mit der rechten Maustaste auf eine von „Contoso.User“ eingetroffene Nachricht, richten Sie den Mauszeiger auf „Junk-E-Mail“, und klicken Sie auf „Absender zur Liste sicherer Absender hinzufügen“.
Das Update-SafeList-Cmdlet wird zum normalen Intervall ausgeführt, um in Active Directory die Informationen der Liste der sicheren Absender zu aktualisieren, und nach der nächsten Edge-Synchronisierung kann „Contoso.User“ mit dem Administrator kommunizieren, ohne eine falsche Positivdiagnose auszulösen. Um diesen Vorgang zu simulieren, führen Sie das Skript „HUB-MBX-01_update_safelist.ps1“ aus.
Führen Sie nun das Skript „INTERNET01_contoso_msg.vbs“ aus, um die Nachricht von „Contoso.User“ erneut zu senden. Überprüfen Sie danach mithilfe des Befehls „Get-AgentLog“ | „Select-Object -Last 1“ das Agentprotokoll auf dem Edge-Transport-Server. Wie Sie unter „ReasonData“ sehen können, wurde jetzt die Inhaltsfilterung umgangen. Für „Contoso.User“ wird es keine falsche Positivdiagnose mehr geben!

Spamangriff
Ziehen Sie zum Abschluss der Testläufe alle Register. Wie Sie zweifellos bemerkt haben, wurde während des vorherigen Tests der Internethost als offenes Relay konfiguriert, was den Spammern Tür und Tor öffnet. Sehen Sie sich jetzt an, was geschieht, wenn „Spam.Sender@cohovineyards.com“ diese unzulängliche Konfiguration bemerkt und den Host dazu missbraucht, Tausende von Spamnachrichten an Adventure Works zu senden. Das Skript „INTERNET01_spam_msg.vbs“ sendet nur eine einzige Spamnachricht, aber Sie können das Skript bearbeiten und den max_loop-Wert ändern, damit mehr Spamnachrichten generiert werden.
Um einen Spamangriff zu simulieren, wurden dem gefährdeten Host 1.000 Nachrichten zur Weiterleitung an den Edge-Transport-Server gesendet. Da der SMTP-Dienst die Anzahl der Nachrichten pro ausgehender Verbindung auf 20 beschränkt, dauerte es einige Zeit, genügend Spamnachrichten zu übertragen, bis der Protokollanalyse-Agent auf dem Edge-Transport-Server in Aktion trat.
Der Protokollanalyse-Agent unterstützt den Verbindungsfilter-Agent, indem er basierend auf der SMTP-Protokollanalyse und auf IP-Zuverlässigkeitsupdates von Microsoft Update automatisch IP-Sperrlisteneinträge führt. In diesem Fall wurden die Spam-E-Mails von der SMTP-Protokollanalyse erfasst. Der Protokollanalyse-Agent verfolgt die SCL-Bewertung jeder Nachricht, um einen durchschnittlichen SCL-Wert zu errechnen, der dazu verwendet wird, eine Absenderzuverlässigkeitssstufe (Sender Reputation Level, SRL) zu bestimmen. Als während des simulierten Spamangriffs immer mehr illegitime Nachrichten eintrafen, erhöhte sich die SRL-Bewertung des Internethosts, bis sie schließlich die SRL-Sperrschwelle überschritt. Dies hatte zur Folge, dass der Host 24 Stunden lang in die IP-Sperrliste aufgenommen wurde. Von diesem Host wird also keine einzige Spamnachricht mehr angenommen. Dies erfolgte vollkommen automatisch. Es war kein Administratoreingriff erforderlich.
Abbildung 5 zeigt den resultierenden IP-Sperrlisteneintrag und die entsprechenden Änderungen in der Nachrichtenverarbeitung. Vor dem Blockieren des Hosts hat der Edge-Transport-Server jede Spamnachricht während des OnEndOfData-Ereignisses zurückgewiesen, weil basierend auf dem SCL-Grenzwert der Inhaltsfilter-Agent bei jeder Nachricht in Aktion getreten ist (zu Referenzzwecken siehe Abbildung 4). Die Nachricht wurde, wenn auch erfolglos, übertragen. Nach der Blockierung des Hosts wurde die Verbindung während des OnMailCommand-Ereignisses durch den Verbindungsfilter-Agent zurückgewiesen. Es werden keine Nachrichten mehr übertragen. Wenn Spammer bereits vor dem Übertragen von Nachrichten getrennt werden, führt dies zu Einsparungen bei der Netzwerkbandbreite und den Verarbeitungsressourcen.
Abbildung 5 Stoppen eines angreifenden Internethosts
Abbildung 5 Stoppen eines angreifenden Internethosts

Weitere Tests
Natürlich gibt es noch andere Agentfeatures und Szenarios, die getestet werden können. Sie können beispielsweise die Absenderfilterung testen, indem Sie als „Blocked.User@Contoso.com“ oder „Blocked.User@Fabrikam.com“ Nachrichten senden, oder Sie können die Empfängerfilterung testen, indem Sie Nachrichten an „Blocked.User@adventure-works.com“ senden. Sie können auch Telnet verwenden, um Verzeichnisdiebstahl-Angriffe (Directory Harvest Attack, DHA) mit verschiedenen Teergrubenintervallen zu simulieren. In der IT-Konfiguration von Microsoft wird auf dem mit dem Internet verbundenen Empfangsconnector für SMTP 5yz-Anworten ein Standardintervall von fünf Sekunden verwendet, was für die IT-Konfiguration von Microsoft genügt, um DHA-Angriffe für Spammer undurchführbar zu machen. Sie können jedoch mithilfe des Set-ReceiveConnector-Cmdlets andere Werte verwenden, was durch das Skript „EDGE01_tarpitting.ps1“ erläutert wird.
Wenn Sie noch weiter in die Materie eindringen möchten, sehen Sie sich die Snapshotdateien an, die die Pipelineablaufverfolgung für die Nachrichten von „Contoso.User@Contoso.com“ erstellt. Untersuchen Sie die Antivirusstempel „X-MS-Exchange-Organization-AVStamp-Mailbox: MSFTFF;1;0;0 0 0“, die Forefront Security verwendet, um gescannte Nachrichten zu markieren. Wenn Forefront Security auf dem Hub-Transport-Server diesen Stempel mit neueren Versionsinformationen vorfindet, muss die betreffende Nachricht kein zweites Mal gescannt werden. Wenn Sie versuchen, Forefront Security zu täuschen, indem Sie in die Testnachrichten gefälschte Antivirusstempel einfügen, tritt die Headerfirewall in Aktion und entfernt diese Stempel unmittelbar nach dem OnDataCommand-Ereignis, also lange, bevor das OnSubmittedMessage-Ereignis ausgelöst wird, das den FSE-Routing-Agent aufruft.
Beim Betrachten der Nachrichtenheader in den Snapshotdateien kommen Sie vielleicht auf die Idee, einen SPF-Testdatensatz für Contoso.com zu erstellen, der eine falsche IP-Adresse als legitimen Absender identifiziert. Eine Möglichkeit hierfür besteht darin, die Datei „INTERNET01_wrong_SPF_record.bat“ auf dem Internethost auszuführen. Danach sollten Sie eine Testnachricht als „Contoso.User@Contoso.com“ senden und sich den „X-MS-Exchange-Organization-SenderIdResult“- und „Received-SPF“-Header ansehen:
X-MS-Exchange-Organization-SenderIdResult: SoftFail
Received-SPF: SoftFail (EDGE01.extranet.adventure-works.com: domain of transitioning
Contoso.User@Contoso.com discourages use of 192.168.1.100 as permitted sender)

Zusammenfassung
Wie Sie in diesem und im vorherigen Artikel gesehen haben, sind Exchange Server 2007-Edge-Transport-Server mit einem umfassenden Satz von Transport-Agents ausgestattet, um zuverlässige, mit hoher Präzision arbeitende Antispamfunktionen einschließlich Verbindungsfilterung, Protokollanalyse und Inhaltsfilterung zu implementieren. Die Transportarchitektur ist erweiterbar und unterstützt die Implementierung weiterer Agents, um zusätzliche Funktionalität zu erhalten. Der FSE-Routing-Agent ist ein gutes Beispiel für einen zusätzlichen Agent, der Forefront Security für Exchange Server in die Transportarchitektur integriert.
In Kombination mit zusätzlichen Features wie Verbindungsteergruben, Headerfirewalls, TLS und Authentifizierung stellen Edge-Transport-Server die erforderlichen Mittel bereit, um eine sehr hohe Stufe an Messagingschutz auf mehreren Ebenen und ohne einzelne Fehlerquellen zu erreichen. Durch den Einsatz von Edge-Transport-Servern und Forefront Security in einem Umkreisnetzwerk, das streng von der internen Exchange Server-Organisation getrennt ist, können Sie die Flut illegitimer und schädlicher Inhalte von Ihrer Messagingumgebung fernhalten und zugleich Ihren Benutzern legitime Nachrichten mit einer sehr niedrigen Rate falscher Positivdiagnosen zustellen.

Kay Unkroth ist Unternehmer und bereits seit mehr als 15 Jahren als Supporttechniker, Systementwickler, Berater, Schulungsleiter und Autor für Microsoft-Servertechnologien tätig. Außerdem ist er Gründungsmitglied und Vorsitzender der Biblioso Corporation. Dieses Unternehmen spezialisiert sich auf verwaltete Dokumentations- und Lokalisierungsdienste.


 Netzwerk: Konfigurieren von VPN-Remotezugriff mit ISA&#160;Server&#160;2006
Netzwerk Alan Maddison

Konfigurieren von VPN-Remotezugriff mit ISA Server 2006
Kurz zusammengefasst:
  • VPN-Protokolle
  • Konfigurieren einer Standort-zu-Standort-VPN-Verbindung
  • Konfigurieren einer RAS-VPN-Verbindung
  • Neue Features in ISA Server 2006

Virtuelle private Netzwerke (VPNs) bieten ein hohes Maß an Anpassungsfähigkeit und Skalierbarkeit sowie Kontrolle über die Netzwerkkonnektivität. VPNs sorgen für erhöhte Sicherheit und führen oft zu bedeutenden Kosteneinsparungen
im Vergleich zu traditionellen dedizierten Punkt-zu-Punkt-Verbindungen. Außerdem sind VPNs flexibel.
Es gibt viele Arten von VPNs. Einige VPNs werden genutzt, um Benutzer mobiler Geräte mit dem Unternehmensnetzwerk zu verbinden, andere wiederum verbinden zwei geografisch getrennte Netzwerke miteinander. Die in diesen verschiedenen VPNs verwendeten Protokolle und die bereitgestellten Features weisen erhebliche Unterschiede auf. Einige stellen Sicherheitsfunktionen wie Authentifizierung und Verschlüsselung bereit, andere hingegen verfügen möglicherweise über keine integrierten Sicherheitsfeatures. Bei einigen gestalten sich Einrichtung und Wartung offensichtlich wesentlich einfacher als bei anderen.
In diesem Artikel wird erläutert, wie Sie mithilfe von Internet Security and Acceleration (ISA) Server 2006 ein VPN implementieren. Insbesondere wird beleuchtet, wie mithilfe der VPN-Funktionalität von ISA zwei häufig anzutreffende Szenarios behandelt werden können: das Bereitstellen von RAS-VPN-Verbindungen für Benutzer und das Bereitstellen von Standort-zu-Standort-VPN-Verbindungen. Beide Implementierungen verfügen über Sicherheitsfeatures, die den Datenschutz gewährleisten und für den Schutz interner Netzwerkressourcen sorgen.
Im ersten Szenario – eine RAS-VPN-Verbindung – initiiert ein Remoteclient eine VPN-Verbindung über das Internet zu ISA Server. Anschließend verbindet ISA Server den Remoteclient mit dem internen Netzwerk, sodass der Benutzer nahtlos auf interne Netzwerkressourcen, einschließlich Daten und Anwendungen, zugreifen kann. Das zweite Szenario, eine Standort-zu-Standort-VPN-Verbindung, ist etwas komplexer, da in diesem Fall ein Router, möglicherweise ISA selbst, verwendet wird. Diese Art von Verbindung bietet die Möglichkeit, Niederlassungen und Außenstellen an verschiedenen Standorten nahtlos untereinander und mit einer Zentralniederlassung zu verbinden.
Durch die Implementierung eines VPN mithilfe von ISA Server 2006 ergeben sich mehrere zusätzliche Vorteile. Einer der bedeutendsten Vorteile ergibt sich aus dem integrierten Aufbau von ISA Server. Dadurch können die VPN-Funktionen und die Funktionen der Firewall Hand in Hand arbeiten. Zusätzlich verfügt ISA Server über ein VPN-Quarantänefeature, das mithilfe der Quarantänesteuerung für Netzwerkzugriff von Windows Server® 2003 einen über Remotezugriff verbundenen Computer solange unter Quarantäne stellt, bis die Konfiguration des Computers von einem serverseitigen Skript überprüft wurde. Dadurch wird eine weitere Schutzschicht aufgebaut, da beispielsweise der Status der Antivirusdefinitionen und lokale Richtlinien der Firewall auf dem Remotecomputer überprüft werden, bevor dem Remotecomputer der Zugriff auf die Ressourcen des internen Netzwerks ermöglicht wird.
Aus Administratorsicht ergeben sich die wesentlichen Vorteile von ISA Server als VPN-Lösung aus einer Zentralisierung der Richtlinienverwaltung, der Überwachung, der Protokolle und der Berichterstellung. Diese Funktionen können sich bei Ihren täglichen Aufgaben als Administrator als unschätzbar erweisen. Insbesondere die Echtzeitüberwachung und das Filtern von Protokollen vermitteln wichtige Erkenntnisse zum Netzwerkverkehr und den Verbindungen, die über ISA Server abgewickelt werden.

VPN-Protokolle
Die wichtigsten in einer ISA VPN-Verbindung genutzten Tunnelingprotokolle stellen die erste Verteidigungslinie zum Absichern von Verbindungen dar. ISA Server unterstützt drei Protokolle – Layer-2-Tunnelingprotokoll (L2TP) über IPsec, Point-to-Point-Tunnelingprotokoll (PPTP) und IPsec-Tunnelmodus. Das an letzter Stelle genannte Protokoll wird nur für Standort-zu-Standort Verbindungen unterstützt. Es wird hauptsächlich für die Interoperabilität mit Routern und anderen Betriebssystemen genutzt, von denen L2TP und PPTP nicht unterstützt werden.
L2TP wird mit IPSec gekoppelt, da L2TP nicht über eigene Mechanismen für den Datenschutz verfügt. Im Zusammenspiel mit IPSec, das über stabile Mechanismen für Authentifizierung und Verschlüsselung verfügt, stellt diese Kombination eine hervorragende Lösung dar. PPTP verwendet für die Authentifizierung entweder das Microsoft® Challenge Handshake Authentication Protocol (MS CHAP) Version 2 oder das Extensible Authentication Protocol-Transport Layer Security (EAP-TLS) und für die Verschlüsselung Microsoft Point-to-Point-Encryption (MPPE).
Ob sich eine Organisation für L2TP über IPSec oder für PPTP entscheiden sollte, ist meist von den besonderen Umständen in der Organisation abhängig. Mit L2TP über IPSec können Sie komplexere und ausgeklügelte Verschlüsselungsmechanismen verwenden, und L2TP über IPSec unterstützt mehr Typen von Netzwerken (einschließlich IP, X.25, Frame Relay und ATM). PPTP hingegen kann einfacher implementiert werden und stellt normalerweise geringere Anforderungen. Wenn keine Einschränkungen für die Organisation zu beachten sind, gilt allerdings ein Implementieren von L2TP über IPSec als die bessere Lösung.

Standort-zu-Standort-VPN-Verbindung
Die in ISA Server 2006 implementierten Weiterentwicklungen vereinfachen das Einrichten einer Standort-zu-Standort-VPN-Verbindung erheblich. In früheren Versionen musste dazu eine Vielzahl an Arbeitsschritten durchgeführt werden. Als Beispiel für diesen Artikel wird eine Verbindung mittels L2TP über IPsec zwischen einem Standort einer Außenstelle und einer Zentralniederlassung erläutert, wobei an beiden Standorten ISA Server genutzt wird. Bei dieser Vorgehensweise muss ISA Server zunächst in der Zentralniederlassung konfiguriert werden. Anschließend wird ISA Server in der Außenstelle konfiguriert.
Im ersten Schritt werden die auf beiden ISA Servern erforderlichen lokalen Benutzerkonten konfiguriert. Diese Benutzeridentität stellt den Sicherheitskontext bereit, in dem die Verbindung zu ISA Server am Standort der Außenstelle bzw. zu ISA Server in der Zentralniederlassung aufgebaut wird. Der Name dieses Kontos sollte an den Namen der VPN-Verbindung angelehnt sein, die Sie innerhalb der ISA-Verwaltungskonsole einrichten. Eine geeignete Benennung wäre z. B., auf ISA Server in der Zentralniederlassung (über den die Verbindung zum Remotestandort hergestellt wird) den Benutzernamen „VPN Außenstelle“ und auf ISA Server in der Außenstelle den Namen „VPN Zentrale“ einzurichten. Nach dem Erstellen dieser Konten müssen Sie auf die Kontoeigenschaften zugreifen, die Registerkarte „Dial In“ (Einwählen) öffnen und sicherstellen, dass die Option „Zugriff zulassen“ aktiviert ist.
Nach Erstellen des lokalen Benutzerkontos besteht der nächste Schritt im Bereitstellen des Public Key-Infrastruktur-Zertifikats (PKI-Zertifikat). Dieses Zertifikat wird für die Authentifizierung zwischen den beiden Standorten verwendet. Sie können sich für die Verwendung eines voreingestellten Schlüssels entscheiden. Die Verwendung eines Zertifikats ist jedoch immer vorzuziehen. Die einfachste Möglichkeit zum Installieren eines Zertifikats für eine VPN-Verbindung besteht darin, direkt eine Verbindung zur Zertifizierungsstelle Ihres Unternehmens aufzubauen und über die Website des Zertifizierungsservers ein Zertifikat anzufordern. Dazu müssen Sie jedoch möglicherweise eine Zugriffsregel erstellen, um ISA Server den Aufbau einer Verbindung zum Zertifikatserver über HTTP zu ermöglichen.
Wenn Sie mit früheren Versionen von ISA Server vertraut sind, werden Sie feststellen, dass die in Abbildung 1 dargestellte Benutzeroberfläche von ISA Server 2006 wesentlich intuitiver gestaltet wurde. Wenn Sie im linken Fensterbereich „VPN“ auswählen, werden in den Fensterbereichen in der Mitte und rechts kontextbezogene Konfigurations- und Taskoptionen angezeigt.
Abbildung 1 ISA  Server 2006 verfügt über eine intuitivere Oberfläche
Abbildung 1 ISA Server 2006 verfügt über eine intuitivere Oberfläche
Starten Sie den Assistenten zum Erstellen eines Standort-zu-Standort-VPNs. Klicken Sie dazu im rechten Fensterbereich auf den Task „VPN-Standort-zu-Standort-Verbindung erstellen“. Beim Start fragt der Assistent nach einem Namen für das Standort-zu-Standort-Netzwerk. Dieser Name sollte an den Namen des bereits erstellten Benutzerkontos angelehnt sein. Geben Sie den Namen ein, und klicken Sie auf die Schaltfläche „Weiter“. Im nächsten Bildschirm (siehe Abbildung 2) wählen Sie das zu verwendende VPN-Protokoll aus. In diesem Beispiel wurde „L2TP über IPSec“ ausgewählt. Klicken Sie auf „Weiter“. Der Assistent gibt die nützliche Warnmeldung aus, dass ein zum Netzwerknamen passendes Benutzerkonto verfügbar sein muss. Da dies der Fall ist, können Sie einfach auf „OK“ klicken, um zum nächsten Bildschirm zu gelangen.
Abbildung 2 Auswählen des zu verwendenden VPN-Protokolls
Abbildung 2 Auswählen des zu verwendenden VPN-Protokolls
Jetzt müssen Sie einen IP-Adresspool erstellen. Hier haben Sie zwei Möglichkeiten: Sie können entweder einen statischen Adresspool in ISA Server erstellen, oder Sie können die Adresszuweisung dem DHCP-Server überlassen. Da beide Methoden gleichwertig sind, sollten Sie Ihre Entscheidung an den in Ihrem Unternehmen üblichen Verfahren bezüglich dieser Option orientieren. Im nun angezeigten Bildschirm werden Sie zur Eingabe des Namens des Remoteservers aufgefordert. Geben Sie den vollqualifizierten Domänennamen (FQDN) des Remoteservers und anschließend die Benutzeranmeldeinformationen für die Verbindung ein. Beachten Sie, dass hier die Informationen zum Benutzerkonto eingegeben werden müssen, das Sie im ISA Server der Außenstelle eingerichtet haben. Im Beispiel wäre dies das Benutzerkonto „VPN Zentrale“, wie in Abbildung 3 dargestellt.
Abbildung 3 Eingeben des FQDN des Remoteservers
Abbildung 3 Eingeben des FQDN des Remoteservers
Im nächsten Bildschirm wählen Sie die Authentifizierungsmethode für ausgehende Verbindungen aus. (Wie bereits weiter oben erwähnt, sollte vorzugsweise ein Zertifikat verwendet werden.) Geben Sie anschließend den IP-Adressbereich ein, der im internen Netzwerk des Remotestandorts verwendet wird.
Wenn Sie ISA Server 2006 Enterprise Edition verwenden, ermöglicht Ihnen der Assistent anschließend das Konfigurieren der für den Netzwerklastenausgleich dedizierten IP-Adressen des Remotestandorts. Wenn Sie ISA Server 2006 Standard Edition verwenden, übergehen Sie den Schritt für den Lastenausgleich und fahren direkt mit dem nächsten Bildschirm fort (siehe Abbildung 4). In diesem Schritt erstellen Sie die Netzwerkregel für das Weiterleiten des Datenverkehrs vom Remotestandort zum lokalen Netzwerk.
Abbildung 4 Erstellen der Netzwerkregel für das Weiterleiten des Datenverkehrs
Abbildung 4 Erstellen der Netzwerkregel für das Weiterleiten des Datenverkehrs
Im nächsten Schritt dieses Vorgangs erstellen Sie eine Zugriffsregel. Beim Konfigurieren der Zugriffsregel stehen Ihnen drei Optionen für das Zulassen der zu verwendenden Protokolle zur Verfügung. Sie können allen ausgehenden Datenverkehr, allen ausgehenden Datenverkehr mit Ausnahme bestimmter Protokolle oder nur bestimmte Protokolle zulassen. In den meisten Situationen werden Sie allen ausgehenden Datenverkehr zulassen.
Nun ist es beinahe geschafft. An dieser Stelle zeigt der Assistent eine Zusammenfassung der von Ihnen eingegebenen Konfigurationsangaben an. Wenn Sie jetzt auf die Schaltfläche „Fertig stellen“ klicken, wird die Standort-zu-Standort-VPN-Verbindung eingerichtet. In einem Dialogfeld wird angezeigt, dass eine Systemrichtlinienregel für das Herunterladen einer Zertifikatsperrliste (Certificate Revocation List, CRL) genehmigt werden muss. Klicken Sie auf „Ja“, um diese Regel zu genehmigen. Der Assistent zeigt Ihnen anschließend Informationen zu weiteren Konfigurationsschritten an, die möglicherweise noch ausgeführt werden müssen. Nach der Konfiguration von ISA Server am zentralen Standort müssen Sie alle Schritte nochmals ausführen, um den Remotestandort zu konfigurieren. Wenn beide Standorte konfiguriert sind, können die Benutzer an den beiden Standorten über das VPN miteinander kommunizieren.

RAS-VPN-Verbindung
Eine RAS-VPN-Verbindung für den Clientzugriff kann wesentlich einfacher konfiguriert werden (siehe Abbildung 5). Zuerst wählen Sie im linken Fensterbereich der Administratorkonsole von ISA Server die Option „VPN“ aus. Anschließend wählen Sie im linken Fensterbereich den Task „VPN-Clientzugriff aktivieren“ aus. Es wird eine Warnmeldung angezeigt, dass dadurch möglicherweise der Routing- und RAS-Dienst neu gestartet werden muss. (Da dies zu Verbindungsproblemen führen kann, ist es vorzuziehen, diese Änderung innerhalb eines geplanten Wartungsfensters zu implementieren.) Klicken Sie zum Fortfahren auf „OK“. ISA Server aktiviert eine Systemrichtlinie, die dem Datenverkehr von VPN-Clients den Zugriff auf ISA Server ermöglicht. Sie können diese Regel anzeigen. Wählen Sie dazu in der Administratorkonsole von ISA Server die Option „Firewallrichtlinie“ und anschließend den Task „Systemrichtlinienregeln anzeigen“ aus.
Abbildung 5 Konfigurieren einer RAS-VPN-Verbindung
Abbildung 5 Konfigurieren einer RAS-VPN-Verbindung
Außerdem wird eine Standardnetzwerkregel aktiviert, die ein Routing zwischen dem internen Netzwerk und den beiden VPN-Netzwerken (VPN-Clients und Quarantäne-VPN-Clients) ermöglicht. Diese Netzwerkregel kann angezeigt und bearbeitet werden. Wählen Sie dazu im linken Fensterbereich die Option „Netzwerke“ aus, und öffnen Sie anschließend im mittleren Fensterbereich die Registerkarte „Netzwerkregeln“.
Jetzt muss noch der VPN-Clientzugriff konfiguriert werden. Es sind drei weitere Parameter zu konfigurieren: die Windows-Sicherheitsgruppen, denen der Zugriff gewährt wird, die Protokolle, die von den Clients genutzt werden dürfen, und die Benutzerzuordnung. Das Dialogfeld zum Konfigurieren dieser Parameter ist in Abbildung 6 dargestellt.
Abbildung 6 Konfigurieren des VPN-Clientzugriffs
Abbildung 6 Konfigurieren des VPN-Clientzugriffs
Auf der Registerkarte „Gruppen“ wählen Sie einfach nur die Windows-Gruppen aus, denen der Remotezugriff über VPN ermöglicht werden soll. Aus Sicht des Administrators ist es meiner Meinung nach von Vorteil, wenn Sie eine einzige Gruppe erstellen, die diese Berechtigung erhält. Auf diese Weise vereinfacht sich die Verwaltung des Remotezugriffs erheblich.
Auf der Registerkarte „Protokolle“ erkennen Sie, dass standardmäßig nur „PPTP“ aktiviert ist. Sie sollten unbedingt „L2TP über IPSec“ aktivieren, wenn dies in Ihrer Umgebung möglich ist.
Mithilfe der Benutzerzuordnung können Sie Windows-Konten Benutzerkonten aus Namespaces, z. B. Remote Authentication Dial-in User Service (RADIUS), zuordnen. Dadurch wird sichergestellt, dass die Zugriffsrichtlinien korrekt angewendet werden. Wenn diese Optionen konfiguriert sind und ISA Server die Änderungen übernommen hat, ist der Konfigurationsvorgang abgeschlossen. Die Clients sollten jetzt in der Lage sein, über eine VPN-Verbindung nahtlos auf die Daten und Anwendungen im internen Netzwerk zuzugreifen.

Verbesserungen an ISA Server 2006
Mit ISA Server 2006 wird eine Reihe von Neuerungen eingeführt, die im Vergleich zu früheren Versionen eine Leistungssteigerung bieten. Diese Features – HTTP-Komprimierung, Unterstützung für Background Intelligent Transfer Service (BITs) und Quality of Service (QoS) – stellen verschiedene Verfahren zum Optimieren der Netzwerkauslastung zur Verfügung. Selbstverständlich sollten trotzdem auch weiterhin die bekannten Verfahren zur Bandbreitenoptimierung eingesetzt werden. Diese Verfahren, einschließlich Zwischenspeichern, sind integraler Bestandteil von ISA Server.
HTTP-Komprimierung wird nun schon seit einiger Zeit in verschiedenen Microsoft-Produkten unterstützt – in Internet Explorer® seit Version 4 und in Windows Server seit Windows® 2000. Dies ist jedoch die erste Version von ISA Server, in der HTTP-Komprimierung sowie die Industriestandards GZIP- und Deflate-Algorithmus unterstützt werden.
Was bedeutet dies? Durch die Unterstützung von HTTP-Komprimierung kann ein Webbrowser nach HTTP 1.1-Spezifikation von jeder beliebigen Website komprimierte Inhalte anfordern. Beachten Sie jedoch, dass lediglich die Antworten komprimiert werden, nicht jedoch die vom Client ausgehenden ursprünglichen Verbindungen.
HTTP-Komprimierung ist eine globale HTTP-Richtlinieneinstellung, die, im Gegensatz zur Zuweisung einer konkreten Netzwerkregel, für den gesamten HTTP-Datenverkehr über ISA Server gilt. Sie haben jedoch die Wahl, die HTTP-Komprimierung auf Listenerbasis zu implementieren. Dies erfolgt mithilfe des Weblistener-Assistenten.
Die HTTP-Komprimierung ist standardmäßig aktiviert. Sie finden diese Option im linken Fensterbereich unter „Allgemein“. Wie in Abbildung 7 zu erkennen ist, müssen Sie jedoch die Netzwerkelemente konfigurieren, für die Komprimierung verwendet werden soll. Um das Beispiel für Standort-zu-Standort-VPN fortzuführen, müssen Sie nun die Registerkarte „Komprimierte Daten zurückgeben“ öffnen und das zuvor erstellte VPN-Netzwerkelement des Standorts hinzufügen. An dieser Stelle haben Sie außerdem die Möglichkeit zu konfigurieren, welche Inhaltstypen komprimiert werden sollen. ISA Server 2006 enthält bereits eine Liste von Standardinhaltstypen, Sie können jedoch im Aufgabenbereich „Firewallrichtlinie“ auf der Registerkarte „Toolbox“ eigene Inhaltstypen hinzufügen. Beachten Sie, dass die Einstellungen auf der Registerkarte „Komprimierte Daten zurückgeben“ lediglich bewirken, dass ISA Server die Daten vor der Rückgabe an den Client komprimiert. Mithilfe der Registerkarte „Komprimierte Daten anfordern“ stellen Sie ein, dass ISA Server die Komprimierung der Daten durch einen Webserver vor ihrer Übermittlung an ISA Server veranlasst.
Abbildung 7 Konfigurieren der HTTP-Komprimierung
Abbildung 7 Konfigurieren der HTTP-Komprimierung
Beim „Background Intelligent Transfer System“ (BITS) handelt es sich um einen asynchronen Dateiübertragungsdienst für den Datenverkehr über HTTP und HTTPS. Windows Server 2003 unterstützt BITS Version 1.5. Dieser Dienst unterstützt Downloads und Uploads. Für Uploads wird jedoch zusätzlich Internet Information Services (IIS) Version 5.0 oder höher benötigt. Als intelligenter Dateiübertragungsdienst verfügt BITS über die Fähigkeit zur Überprüfung des Netzwerkverkehrs und verwendet dadurch nur den ungenutzten Anteil der Netzwerkbandbreite. Außerdem erfolgt die Dateiübertragung dynamisch, und BITS reagiert auf plötzlich auftretende Spitzenbelastungen im Datenverkehr durch Senken der durch BITS verursachten Netzwerkbelastung. Der Vorteil von BITS besteht darin, dass die Auslastung des Netzwerks nicht durch Downloads oder Uploads großer Dateien negativ beeinträchtigt wird. Aus Sicht eines Administrators bedeutet dies, dass weit weniger Beschwerdeanrufe aufgrund schlechter Netzwerkleistung eingehen. Gute Nachrichten!
BITS verfügt noch über andere Vorteile, die zu erhöhter Benutzerfreundlichkeit und höherer Netzwerkleistung beitragen. So erfolgt beispielsweise die Dateiübertragung mittels BITS binär. Daher kann BITS abgebrochene Dateiübertragungen, z. B. aufgrund eines Netzwerkausfalls, an derselben Stelle fortsetzen (ohne ganz von vorn beginnen zu müssen). Dazu verfügt ISA Server 2006 über eine integrierte Unterstützung für ein Microsoft Update-Zwischenspeicherfeature, durch die mithilfe des BITS-Zwischenspeichers das Ausführen von Updates optimiert wird.
Das DiffServ-Protokoll (Differentiated Services) ermöglicht das Festlegen von Paketprioritäten (oder QoS) für den Datenverkehr über HTTP und HTTPS. Abhängig von Ihrer ISA Server-Konfiguration erhalten bestimmte Datenpakete also eine höhere Priorität. Dies ist in Netzwerken mit begrenzter Bandbreite aufgrund umfangreichen Datenverkehrs oder niedriger Netzwerkverbindungsgeschwindigkeit sehr von Vorteil. Gemäß der Internet Engineering Task Force (IETF) ist DiffServ eine auf Klassen basierende Verwaltungsmethode für Datenverkehr. Folglich kann DiffServ zwischen verschiedenen Arten an Datenverkehr unterscheiden und den Datenverkehr entsprechend verwalten. Dadurch wird sichergestellt, dass der Datenverkehr mit höherer Priorität bevorzugt abgewickelt wird.
Um dieses Feature bereitzustellen, arbeitet ISA Server mit Routern zusammen, die QoS unterstützen. Wenn die Pakete mit gleicher Priorität weitergeleitet werden sollen, muss unbedingt sichergestellt werden, dass die DiffServ-Bits von ISA Server den Prioritäten der Router entsprechen.
Diese in ISA Server implementierte Art der Festlegung von Paketprioritäten ist eine globale HTTP-Richtlinieneinstellung, die für den gesamten HTTP-Verkehr gilt, der mittels eines DiffServ-Webfilters über ISA Server 2006 abgewickelt wird. Demnach unterstützt ISA Server DiffServ für andere Protokolle nicht, und es kann vorkommen, dass in Nicht-HTTP-Datenverkehr vorhandene DiffServ-Bits verloren gehen.
Wie in Abbildung 8 dargestellt, wird DiffServ als Webfilter implementiert. Der Zugriff auf DiffServ erfolgt durch Auswahl von „Add-Ins“ im linken Fensterbereich. Die Standardeinstellungen und die Prioritätsreihenfolge des DiffServ-Filters dürfen auf keinen Fall geändert werden, da ISA Server die Größe der Anforderung/Antwort zum Zeitpunkt der Verarbeitung prüfen muss.
Abbildung 8 Anzeigen des DiffServ-Webfilters
Abbildung 8 Anzeigen des DiffServ-Webfilters
Bei genauerer Betrachtung von Abbildung 8 werden Sie feststellen, dass der DiffServ-Filter standardmäßig nicht aktiviert ist. Um den Filter zu aktivieren, aktivieren Sie einfach im Aufgabenbereich die Option „Enable Selected Filters“ (Ausgewählte Filter aktivieren), und konfigurieren Sie anschließend den Filter. Da das Festlegen von Paketprioritäten durch DiffServ in ISA Server entweder anhand bestimmter URLs oder bestimmter Domänen erfolgt, müssen diese Informationen den DiffServ-Einstellungen hinzugefügt werden. Dazu klicken Sie im linken Fensterbereich der Verwaltungskonsole auf „Allgemein“ und wählen anschließend unter „Globale HTTP-Richtlinieneinstellungen“ die Option „Diffserv-Einstellungen angeben“ aus. Beim Festlegen dieser Einstellungen müssen Sie die Prioritäten festlegen und die URLs und Domänen angeben, für die diese Prioritäten gelten sollen. ISA Server 2006 verfügt über leistungsfähige neue Funktionen zum Einrichten eines Remotezugriffs für VPN-Clients oder zum Erstellen von Standort-zu-Standort-VPNs. Für VPN-Lösungen sollte ISA Server 2006 bei Ihnen an erster Stelle stehen.

Alan Maddison ist Senior Consultant in der Microsoft Technology Practice der MTI Technology Corporation. Im Mittelpunkt seiner Tätigkeit stehen Active Directory, Exchange Server und Virtualisierung.


 SQL Server: Optimieren der SQL&#160;Server-Abfrageleistung
SQL Server Maciej Pilecki

Optimieren der SQL Server-Abfrageleistung
Kurz zusammengefasst:
  • Analysieren von Ausführungsplänen
  • Optimieren von Abfragen
  • Ermitteln optimierungsbedürftiger Abfragen

Beim Optimieren eines Datenbankservers müssen Sie die Leistung einzelner Abfragen verbessern. Dies ist ebenso wichtig wie die Optimierung anderer Aspekte Ihrer Serverinstallation, die einen Einfluss auf die Leistung haben, wie z. B. Hardware- und Softwarekonfiguration – oder vielleicht sogar noch wichtiger.
Selbst wenn Ihr Datenbankserver die leistungsfähigste Hardware nutzt, die verfügbar ist, kann er bereits durch wenige problematische Abfragen negativ beeinflusst werden. Schon eine schlechte Abfrage kann gravierende Leistungsprobleme auf Seiten der Datenbank nach sich ziehen.
Umgekehrt lässt sich die Gesamtleistung einer Datenbank stark verbessern, indem einige besonders aufwendige oder besonders oft ausgeführte Abfragen optimiert werden. In diesem Artikel werde ich einige Verfahren vorstellen, mit denen Sie die aufwendigsten Abfragen bzw. diejenigen mit der schlechtesten Leistung auf Ihrem Server ermitteln und optimieren können.

Analysieren von Ausführungsplänen
Wenn eine einzelne Abfrage optimiert werden soll, betrachtet man normalerweise zuerst ihren Ausführungsplan. Der Ausführungsplan beschreibt die Abfolge von physischen und logischen Vorgängen, die SQL ServerTM durchführt, um die Abfrage auszuführen und das gewünschte Resultset zu erstellen. Der Ausführungsplan wird von einer bestimmten Komponente des Datenbankmoduls, dem so genannten Abfrageoptimierer, während der Optimierungsphase der Abfrageverarbeitung erstellt. Dabei werden viele verschiedene Faktoren berücksichtigt, wie z. B. die in der Abfrage verwendeten Suchprädikate, die betroffenen Tabellen und ihre Verknüpfungsbedingungen, die Liste der zurückgegebenen Spalten und das Vorhandensein sinnvoller Indexe, die als effiziente Datenzugriffspfade dienen können.
Bei komplexen Abfragen kann die Zahl der möglichen Permutationen riesig sein, deshalb evaluiert der Abfrageoptimierer nicht alle Möglichkeiten, sondern versucht stattdessen einen Plan zu finden, der für eine gegebene Abfrage „gut genug“ ist. Denn nicht immer lässt sich ein perfekter Plan finden, und selbst wenn es möglich wäre, könnten die Kosten für die Bewertung aller Möglichkeiten zum Ermitteln dieses perfekten Plans leicht so hoch sein, dass sie den Wert aller Leistungsgewinne zunichte machen. Aus Sicht des DBAs ist es wichtig, den Prozess und seine Beschränkungen zu verstehen.
Es gibt eine Reihe von Möglichkeiten, einen Ausführungsplan für eine Abfrage erhalten:
  • Management Studio bietet dazu die Funktionen „Display Actual Execution Plan“ (Tatsächlichen Ausführungsplan anzeigen) und „Display Estimated Execution Plan“ (Geschätzten Ausführungsplan anzeigen), mit denen der Plan grafisch dargestellt wird. Diese Features bieten die beste Lösung für eine direkte Untersuchung und sind bei weitem der am häufigsten gebrauchte Ansatz zum Anzeigen und Analysieren von Ausführungsplänen. (In diesem Artikel werde ich zum Illustrieren meiner Beispiele auf diese Weise erstellte grafische Pläne verwenden.)
  • Verschiedene SET-Optionen, wie z. B. SHOWPLAN_XML und SHOWPLAN_ALL, geben den Ausführungsplan entweder als XML-Dokument zurück, das den Plan mit einem speziellen Schema beschreibt, oder als Rowset mit Textbeschreibung zu den einzelnen Vorgängen im Ausführungsplan.
  • SQL Server Profiler-Ereignisklassen, wie z. B. „Showplan XML“, ermöglichen die Erfassung von Ausführungsplänen von Anweisungen, die während eines Ablaufverfolgung gesammelt wurden.
Auch wenn die XML-Darstellung des Ausführungsplans vielleicht für einen Menschen nicht die am leichtesten lesbare Form ist, ermöglicht diese Variante doch das Schreiben von Prozeduren und Dienstprogrammen, mit denen Ausführungspläne analysiert und nach Anzeichen für Leistungsprobleme und suboptimale Pläne durchsucht werden können. Eine XML-basierte Darstellung kann auch in einer Datei mit der Erweiterung „.sqlplan“ gespeichert und dann in Management Studio geöffnet werden, um eine grafische Darstellung zu erzeugen. Diese Dateien können auch zur späteren Analyse gespeichert werden und machen damit die Notwendigkeit einer erneuten Erstellung des Ausführungsplans bei jeder Analyse überflüssig. Dies ist besonders nützlich, wenn Sie Ihre Pläne vergleichen wollen, um Veränderungen im Laufe der Zeit zu beobachten.

Geschätzte Ausführungskosten
Zunächst müssen Sie bei Ausführungsplänen verstehen, wie sie erzeugt werden. SQL Server verwendet einen kostenbasierten Abfrageoptimierer, der versucht, den Ausführungsplan mit den niedrigsten geschätzten Kosten zu erzeugen. Die Schätzung basiert auf der Datenverteilungsstatistik, die für den Optimierer verfügbar ist, wenn die an der Abfrage beteiligten Tabellen ausgewertet werden. Wenn diese Statistiken fehlen oder veraltet sind, fehlen dem Abfrageoptimierer wichtige Informationen für die Abfrageoptimierung, und die Schätzungen werden wahrscheinlich ungenau sein. Dann kann es passieren, dass der Optimierer einen nicht optimalen Plan wählt, weil die Ausführungskosten der verschiedenen Pläne über- oder unterschätzt wurden.
Über die geschätzten Ausführungskosten gibt es einige falsche Annahmen. Insbesondere wird oft angenommen, dass die geschätzten Ausführungskosten ein guter Indikator dafür sind, wie lange die Ausführung einer Abfrage dauern wird, und dass sich anhand dieser Schätzung gute von schlechten Plänen unterscheiden lassen. Das ist jedoch nicht der Fall. Erstens ist nicht ausreichend dokumentiert, in welchen Einheiten die geschätzten Kosten ausgedrückt werden und ob sie in direkter Beziehung zur Ausführungszeit stehen. Zweitens geht es hier um eine Schätzung, die natürlich auch falsch sein kann. Daher können Pläne mit höheren geschätzten Kosten in punkto CPU, E/A und Ausführungszeit unter Umständen viel effizienter sein, trotz des höheren Schätzwerts. Dies kommt häufig bei Abfragen vor, die Tabellenvariable beinhalten. Da für Tabellenvariable keine Statistiken verfügbar sind, nimmt der Abfrageoptimierer für jede Tabellenvariable an, dass sie nur eine Zeile enthält, selbst wenn sie wesentlich umfangreicher ist. Der Abfrageoptimierer wählt den Plan also anhand einer ungenauen Schätzung aus. Deshalb sollten Sie sich beim Vergleichen der Ausführungspläne Ihrer Abfragen nicht allein auf die geschätzten Abfragekosten verlassen. Berücksichtigen Sie stattdessen die Ausgabe der Optionen STATISTICS I/O und STATISTICS TIME in der Analyse, um die tatsächlichen Ausführungskosten in punkto E/A und CPU-Zeit zu erkennen.
An dieser Stelle ist auch ein besonderer Typ von Ausführungsplan zu erwähnen, der parallele Plan. Wenn Sie Ihre Abfrage auf einem Server mit mehreren CPUs ausführen und die Abfrage für eine Parallelausführung geeignet ist, kann ein paralleler Plan ausgewählt werden. (Gewöhnlich zieht der Abfrageoptimierer einen parallelen Plan nur für eine Abfrage in Betracht, deren Kosten einen bestimmten konfigurierbaren Schwellenwert überschreiten.) Aufgrund des Aufwands für die Verwaltung mehrerer paralleler Ausführungsthreads (also die Verteilung der Arbeit auf mehrere Threads, die Synchronisierung und die Zusammenstellung der Ergebnisse) ist die Ausführung paralleler Pläne kostenintensiver, was sich auch in ihren geschätzten Kosten zeigt. Warum werden sie also gegenüber billigeren, nicht parallelen Plänen bevorzugt? Weil die Rechenleistung mehrerer CPUs genutzt wird, liefern parallele Pläne tendenziell schneller Ergebnisse als Standardpläne. Je nach Szenario und in Abhängigkeit von Variablen wie verfügbaren Ressourcen und Last durch andere, gleichzeitige Abfragen kann dies in einem Setup wünschenswert sein. Wenn das der Fall ist, sollten Sie steuern, welche Ihrer Abfragen parallele Pläne erstellen können und wie viele CPUs jede Abfrage nutzen kann. Dazu legen Sie auf Serverebene den maximalen Grad an Parallelität fest. Anschließend können Sie diese Option auf Ebene einzelner Abfragen bei Bedarf mit „OPTION (MAXDOP n)“ überschreiben.

Analysieren von Ausführungsplänen
Betrachten wir nun eine einfache Abfrage, ihren Ausführungsplan und einige Möglichkeiten zum Verbessern der Leistung. Angenommen, ich führe diese Abfrage mit Management Studio aus und habe die Option „Tatsächlichen Ausführungsplan einschließen“ in der „Adventure Works“-Beispieldatenbank in SQL Server 2005 aktiviert:
SELECT c.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
JOIN Sales.Customer c ON oh.CustomerID=c.CustomerID
GROUP BY c.CustomerID
Als Ergebnis wird der in Abbildung 1 dargestellte Ausführungsplan angezeigt. Diese einfache Abfrage berechnet den Gesamtbetrag der Bestellungen, die von allen Kunden des fiktiven Unternehmens „Adventure Works“ aufgegeben wurden. Wenn Sie nun den Ausführungsplan betrachten, können Sie sehen, wie das Datenbankmodul die Abfrage verarbeitet und das Ergebnis erzeugt. Grafische Ausführungspläne werden von oben nach unten und von rechts nach links gelesen. Jedes Symbol steht für einen durchgeführten logischen oder physischen Vorgang, und die Pfeile zeigen den Datenfluss zwischen den Vorgängen. Die Dicke der Pfeile steht für die Anzahl an Zeilen, die von den Vorgängen übergeben werden: Je dicker der Pfeil, desto mehr Zeilen sind beteiligt. Wenn Sie den Mauszeiger auf eines der Operatorsymbole setzen, werden in einem gelben QuickInfo (wie in Abbildung 2) Details zum jeweiligen Vorgang angezeigt.
Abbildung 1 Beispielausführungsplan
Abbildung 1 Beispielausführungsplan
Abbildung 2 Details zu einem Vorgang
Abbildung 2 Details zu einem Vorgang
Wenn Sie die einzelnen Operatoren betrachten, können Sie die Reihenfolge der ausgeführten Schritte analysieren:
  1. Das Datenbankmodul führt auf der Tabelle „Sales.Customer“ einen „Clustered Index Scan“-Vorgang durch, bei dem ein gruppierter Index durchsucht wird, und gibt für alle Zeilen in dieser Tabelle die Spalte „CustomerID“ zurück.
  2. Anschließend wird ein „Index Scan“-Vorgang durchgeführt, bei dem einer der nicht gruppierten Indexe in der Tabelle „Sales.SalesOrderHeader“ durchsucht wird. Dabei handelt es sich um einen Index auf der Spalte „CustomerID“, der aber implizit auch die Spalte „SalesOrderID“ umfasst (den Gruppierungsschlüssel der Tabelle). Im Anschluss an die Suche werden die Werte aus beiden Spalten zurückgegeben.
  3. Die Ausgabe beider Suchen wird mit dem physischen Operator „Merge Join“ auf der Spalte „CustomerID“ verknüpft. (Dies ist eine von drei möglichen physischen Varianten zum Durchführen einer logischen „Join“-Operation. Sie ist schnell, erfordert aber, dass beide Eingaben nach einer verknüpften Spalte sortiert sind. In diesem Fall haben beide Suchvorgänge die Zeilen bereits nach „CustomerID“ sortiert zurückgegeben, sodass ein zusätzlicher Sortiervorgang nicht erforderlich ist.)
  4. Anschließend durchsucht das Datenbankmodul den gruppierten Index auf der Tabelle „Sales.SalesOrderDetail“ und ruft die Werte von vier Spalten („SalesOrderID“, „OrderQty“, „UnitPrice“ und „UnitPriceDiscount“) aus allen Zeilen in dieser Tabelle ab. (Geschätzt wurde eine Rückgabe von 123.317 Zeilen, und diese Anzahl entspricht der tatsächlichen Rückgabe, wie Sie Abbildung 2 entnehmen können. Die Schätzung war also sehr präzise.)
  5. Zeilen, die beim Durchsuchen des gruppierten Indexes erstellt wurden, werden an den ersten „Compute Scalar“-Operator übergeben, damit der Wert der berechneten Spalte „LineTotal“ für jede Zeile berechnet werden kann, basierend auf den in der Formel verwendeten Spalten „OrderQty“, „UnitPrice“ und „UnitPriceDiscount“.
  6. Der zweite „Compute Scalar“-Operator wendet die Funktion „ISNULL“ auf das Ergebnis der vorherigen Berechnung an, wie durch die Formel der berechneten Spalte angegeben. Dies schließt die Berechnung der Spalte „LineTotal“ ab und gibt sie, zusammen mit der Spalte „SalesOrderID“, an den nächsten Operator zurück.
  7. Die Ausgabe des „Merge Join“-Operators in Schritt 3 wird mithilfe des physischen Operators „Hash Match“ mit der Ausgabe des „Compute Scalar“-Operators aus Schritt 6 verknüpft.
  8. Dann wird ein weiterer „Hash Match“-Operators angewendet, um die von „Merge Join“ zurückgegebenen Zeilen nach dem Wert der Spalte „CustomerID“ und dem berechneten SUM-Aggregat der Spalte „LineTotal“ zu gruppieren.
  9. Der letzte Knoten, SELECT, ist kein physischer oder logischer Operator, sondern ein Platzhalter, der für die Gesamtergebnisse und -kosten der Abfrage steht.
Auf meinem Laptop hat dieser Ausführungsplan geschätzte Kosten von 3.31365 (wie in Abbildung 3 gezeigt). Wenn bei der Ausführung „STATISTICS I/O“ auf ON gesetzt ist, meldet die Abfrage die Durchführung von insgesamt 1.388 logischen Lesevorgängen in den drei beteiligten Tabellen. Die unter den Operatoren angezeigten Prozentwerte geben die Kosten des jeweiligen Operators im Verhältnis zu den geschätzten Gesamtkosten des ganzen Ausführungsplans an. In Abbildung 1 sehen Sie, dass der Großteil der Gesamtkosten des Ausführungsplans durch folgende drei Operatoren entsteht: den Operator „Clustered Index Scan“ auf der Tabelle „Sales.SalesOrderDetail“ und die zwei „Hash Match“-Operatoren. Bevor ich jedoch mit ihrer Optimierung beginne, möchte ich noch auf eine sehr einfache Änderung meiner Abfrage hinweisen, durch die ich zwei der Operatoren ganz beseitigen kann.
Abbildung 3 Geschätzte Gesamtausführungskosten der Abfrage
Abbildung 3 Geschätzte Gesamtausführungskosten der Abfrage
Da ich von der Tabelle „Sales.Customer“ nur die Spalte „CustomerID“ zurückgebe und diese Spalte auch als Fremdschlüssel in der Tabelle „Sales.SalesOrderHeader“ enthalten ist, kann ich die Tabelle „Customer“ aus der Abfrage ganz entfernen, ohne die logische Bedeutung oder das Ergebnis dieser Abfrage zu verändern. Dazu verwende ich folgenden Code:
SELECT oh.CustomerID, SUM(LineTotal)
FROM Sales.SalesOrderDetail od JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Das Ergebnis ist ein anderer Ausführungsplan, der in Abbildung 4 dargestellt ist.
Abbildung 4 Ausführungsplan nach Entfernen der Tabelle „Customer“ aus der Abfrage
Abbildung 4 Ausführungsplan nach Entfernen der Tabelle „Customer“ aus der Abfrage
Zwei Vorgänge wurden dabei völlig beseitigt: der „Clustered Index Scan“-Vorgang auf der Tabelle „Customer“ und der „Merge Join“-Vorgang auf den Tabellen „Customer“ und „SalesOrderHeader“. Zusätzlich wurde auch der „Hash Match“-Vorgang durch einen viel effizienteren „Merge Join“-Vorgang ersetzt. Um jedoch den „Merge Join“-Operator auf die Tabellen „SalesOrderHeader“ und „SalesOrderDetail“ anwenden zu können, müssen die Zeilen beider Tabellen nach der Verknüpfungsspalte „SalesOrderID“ sortiert zurückgegeben werden. Dazu verwendet der Abfrageoptimierer einen „Clustered Index Scan“ auf der Tabelle „SalesOrderHeader“ anstelle des einfachen „Index Scan“-Vorgangs, der in Sachen E/A billiger gewesen wäre. Dies ist ein gutes Beispiel dafür, wie der Abfrageoptimierer in der Praxis funktioniert. Da die Kosteneinsparungen durch die Änderung der physischen Verknüpfung größer waren als die zusätzlichen E/A-Kosten durch den „Clustered Index Scan“-Vorgang, hat der Abfrageoptimierer die resultierende Kombination von Operatoren gewählt, da hier die geschätzte Gesamtsumme der Ausführungskosten am geringsten war. Auf meinem Laptop ist die Anzahl logischer Lesevorgänge zwar gestiegen (auf 1.941), die benötigte CPU-Zeit war jedoch kürzer, und die geschätzten Ausführungskosten dieser Abfrage waren um etwa 13 % geringer (2.89548).
Angenommen, ich möchte die Leistung dieser Abfrage weiter verbessern. Ich betrachte den „Clustered Index Scan“-Vorgang auf der Tabelle „SalesOrderHeader“, der nun der teuerste Operator in diesem Ausführungsplan ist. Da ich für die Abfrage nur zwei Spalten dieser Tabelle benötige, kann ich einen nicht gruppierten Index erstellen, der nur diese zwei Spalten enthält. So kann ich das Durchsuchen der ganzen Tabelle durch das Durchsuchen des viel kleineren, nicht gruppierten Indexes ersetzen. Die Indexdefinition könnte etwa so aussehen:
CREATE INDEX IDX_OrderDetail_OrderID_TotalLine
ON Sales.SalesOrderDetail (SalesOrderID) INCLUDE (LineTotal)
Beachten Sie, dass der erstellte Index eine berechnete Spalte umfasst. Dies ist je nach Definition der berechneten Spalte nicht immer möglich.
Nach Erstellen dieses Indexes und Ausführen der gleichen Abfrage erhalte ich den neuen Ausführungsplan wie in Abbildung 5 gezeigt.
Abbildung 5 Optimierter Ausführungsplan
Abbildung 5 Optimierter Ausführungsplan
Das Durchsuchen des gruppierten Indexes auf der Tabelle „SalesOrderDetail“ wurde durch das Durchsuchen eines nicht gruppierten Indexes mit bedeutend geringeren E/A-Kosten ersetzt. Außerdem habe ich einen der „Compute Scalar“-Operatoren eliminiert, da mein Index einen bereits berechneten Wert für die Spalte „LineTotal“ enthält. Die geschätzten Kosten für den Ausführungsplan betragen jetzt 2.28112, und die Abfrage führt bei der Ausführung 1.125 logische Lesevorgänge durch.

Der abdeckende Index
Übung: Kundenauftragsabfrage
Aufgabe: Hier eine Übung zum Abfragen der Kundenaufträge. Versuchen Sie, die Indexdefinition zu erstellen. Welche Spalten muss sie enthalten, um als abdeckender Index für diese Abfrage verwendet werden zu können? Kann sich die Reihenfolge der Spalten in der Indexdefinition auf die Leistung auswirken?
Lösung: Ihre Aufgabe war es, den bestmöglichen abdeckenden Index auf der Tabelle „Sales.SalesOrderHeader“ für die Beispielabfrage aus diesem Artikel zu erstellen. Dazu müssen Sie zunächst feststellen, dass diese Abfrage nur zwei Spalten der Tabelle verwendet: „CustomerID“ und „SalesOrderID“. Wenn Sie meinen Artikel sorgfältig gelesen haben, werden Sie bemerkt haben, dass im Fall der Tabelle „SalesOrderHeader“ bereits ein Index existiert, der diese Abfrage abdeckt, nämlich der Index auf der Spalte „CustomerID“. Er enthält bereits implizit die Spalte „SalesOrderID“, die als Gruppierungsschlüssel der Tabelle dient.
Ich habe ja auch erklärt, warum der Abfrageoptimierer diesen Index nicht verwendet. Natürlich könnten Sie den Abfrageoptimierer zwingen, diesen Index zu verwenden. Aber diese Lösung wäre weniger effizient als der bereits bestehende Plan, bei dem ein „Clustered Index Scan“-Vorgang und „Merge Join“-Operatoren zum Einsatz kommen. Sie würden den Abfrageoptimierer zwingen, zwischen dem Durchführen eines zusätzlichen Sortiervorgangs (um „Merge Join“ verwenden zu können) und dem Rückgriff auf einen weniger effizienten „Hash Join“-Operator zu wählen. In beiden Fallen sind die geschätzten Ausführungskosten höher als bei dem vorhandenen Plan (die Variante mit dem „Sort“-Vorgang wäre besonders ungünstig). Deshalb wird der Abfrageoptimierer sie nur verwenden, wenn er dazu gezwungen wird. Daher würde in diesem Fall nur ein nicht gruppierter Index auf „SalesOrderID“, „CustomerID“ eine bessere Leistung ermöglichen als der „Clustered Index Scan“-Vorgang. Wichtig ist jedoch, dass die Spalten in genau dieser Reihenfolge stehen müssen:
CREATE INDEX IDX_OrderHeader_SalesOrderID_CustomerID
ON Sales.SalesOrderHeader (SalesOrderID, CustomerID)
Wenn Sie diesen Index erstellen, enthält der Ausführungsplan anstelle des „Clustered Index Scan“-Operators den „Index Scan“-Operator. Das ist ein bedeutender Unterschied. In diesem Fall ist der nicht gruppierte Index mit nur zwei Spalten wesentlich kleiner als die ganze Tabelle in Form eines gruppierten Indexes. Deshalb werden zum Lesen der notwendigen Daten weniger E/A-Operationen benötigt.
Dieses Beispiel zeigt auch, wie die Reihenfolge der Spalten im Index erhebliche Auswirkungen auf dessen Nutzen für den Abfrageoptimierer haben kann. Behalten Sie dies bei der Erstellung mehrspaltiger Indexe immer im Blick.

Der auf der Tabelle „SalesOrderDetail“ erstellte Index ist ein Beispiel für einen so genannten abdeckenden Index. Dabei handelt es sich um einen nicht gruppierten Index, der alle zum Durchführen der Abfrage benötigten Spalten enthält und ein Durchsuchen der ganzen Tabelle mit den Operatoren „Table Scan“ oder „Clustered Index Scan“ überflüssig macht. Der Index ist im Prinzip eine kleinere Kopie der Tabelle, die eine Teilmenge der Spalten in der Tabelle enthält. Nur die zum Durchführen der Abfragen benötigten Spalten sind im Index enthalten. Er enthält also nur das, was zum „Abdecken“ der Abfrage benötigt wird.
Das Erstellen abdeckender Indexe für die am häufigsten ausgeführten Abfragen ist eine der einfachsten und gebräuchlichsten Methoden zum Optimieren von Abfragen. Dies funktioniert besonders gut, wenn die Tabelle viele Spalten enthält, von denen jedoch nur wenige häufig in Abfragen verwendet werden. Durch das Erstellen eines oder mehrerer abdeckender Indexe können Sie die Leistung der betreffenden Abfragen deutlich verbessern, da auf eine wesentlich kleinere Datenmenge zugegriffen wird und weniger E/A-Operationen benötigt werden. Die Wartung zusätzlicher Indexe verursacht jedoch bei Datenänderungsvorgängen (INSERT, UPDATE und DELETE) versteckte Kosten. In Abhängigkeit von Ihrer Umgebung und dem Verhältnis zwischen SELECT-Abfragen und Datenänderungen sollten Sie daher genau abwägen, ob die Leistungsverbesserungen bei Abfragen diese zusätzlichen Kosten für die Indexwartung rechtfertigen.
Doch keine Angst vor der Erstellung mehrspaltiger Indexe anstelle von einspaltigen Indexen. Häufig sind sie viel nützlicher als einspaltige Indexe, und es ist viel wahrscheinlicher, dass der Abfrageoptimierer sie verwenden kann, um die Abfrage abzudecken. Die meisten abdeckenden Indexe sind mehrspaltige Indexe.
Bei meiner Beispielabfrage gibt es jedoch noch weitere Verbesserungsmöglichkeiten. Beispielsweise ließe sie sich weiter optimieren, indem für die Tabelle „SalesOrderHeader“ ein abdeckender Index erstellt wird. Dadurch kann anstelle des „Clustered Index Scan“-Vorgangs ein einfacher „Index Scan“-Vorgang auf einem nicht gruppierten Index durchgeführt werden. Das ist eine gute Übung für Sie. Versuchen Sie, die Indexdefinition zu erstellen. Welche Spalten muss sie enthalten, um als abdeckender Index für diese Abfrage verwendet werden zu können? Kann sich die Reihenfolge der Spalten in der Indexdefinition auf die Leistung auswirken? Die Lösung finden Sie in der Randleiste "Übung: Kundenauftragsabfrage".

Indizierte Sichten
Wenn die Leistung meiner Beispielabfrage sehr wichtig ist, kann ich noch einen Schritt weiter gehen und eine indizierte Sicht erstellen, in der die Ergebnisse der Abfrage physisch gespeichert werden. Für indizierte Sichten gelten bestimmte Voraussetzungen und Einschränkungen, aber wenn die Verwendung möglich ist, sind damit erhebliche Leistungssteigerungen machbar. Bedenken Sie, dass mit indizierten Sichten höhere Wartungskosten als bei Standardindexen verbunden sind. Daher sollten Sie diese mit Bedacht einsetzen. In diesem Fall sieht die Indexdefinition wie folgt aus:
CREATE VIEW vTotalCustomerOrders
WITH SCHEMABINDING
AS
SELECT oh.CustomerID, SUM(LineTotal) AS OrdersTotalAmt, COUNT_BIG(*) AS TotalOrderLines
FROM Sales.SalesOrderDetail od
JOIN Sales.SalesOrderHeader oh
ON od.SalesOrderID=oh.SalesOrderID
GROUP BY oh.CustomerID
Beachten Sie die Option „WITH SCHEMABINDING“, die eine Voraussetzung für die Erstellung eines Indexes auf einer solchen Sicht ist, und die Funktion „COUNT_BIG(*)“, die notwendig ist, wenn die Indexdefinition eine Aggregatfunktion (in diesem Fall „SUM“) enthält. Nachdem ich die Sicht erstellt habe, kann ich einen Index dafür erstellen:
CREATE UNIQUE CLUSTERED INDEX CIX_vTotalCustomerOrders_CustomerID
ON vTotalCustomerOrders(CustomerID)
Wenn ich diesen Index erstelle, wird das Ergebnis der Abfrage in der Definition der Sicht „materialisiert“ und physisch auf dem Datenträger im Index gespeichert. Beachten Sie, dass durch alle Datenänderungsvorgänge auf den Basistabellen automatisch die Werte in der Sicht gemäß dieser Definition aktualisiert werden.
Was passiert, wenn ich die Abfrage wiederhole, hängt davon ab, welche Edition von SQL Server ich verwende. Bei den Enterprise- und Developer-Editionen wird der Abfrageoptimierer automatisch diese Abfrage mit der Definition der indizierten Sicht abgleichen und die indizierte Sicht verwenden, statt die betreffenden Basistabellen abzufragen. Abbildung 6 zeigt den in diesem Fall erstellten Ausführungsplan Er besteht aus nur einem Vorgang, nämlich einem „Clustered Index Scan“-Vorgang des Indexes, den ich für die Sicht erstellt habe. Die geschätzten Ausführungskosten betragen nur 0.09023, und es finden nur 92 logische Lesevorgänge statt.
Abbildung 6 Ausführungsplan bei Verwendung einer indizierten Sicht
Abbildung 6 Ausführungsplan bei Verwendung einer indizierten Sicht
Sie können diese indizierte Sicht auch mit anderen Versionen von SQL Server erstellen und verwenden. Um jedoch dieselbe Wirkung zu erzielen, müssen Sie die Abfrage so ändern, dass mit NOEXPAND direkt auf die Sicht verwiesen wird:
SELECT CustomerID, OrdersTotalAmt
FROM vTotalCustomerOrders WITH (NOEXPAND)
Wie Sie sehen sind indizierte Sichten, richtig eingesetzt, ein sehr leistungsfähiges Feature. Sie sind besonders zum Optimieren von Abfragen geeignet, in denen Aggregationen über große Mengen von Daten erfolgen. Bei Verwendung mit der Enterprise Edition können viele Abfragen davon profitieren, ohne dass Änderungen am Code erforderlich sind.

Ermitteln optimierungsbedürftiger Abfragen
Wie stelle ich fest, bei welchen Abfragen sich eine Optimierung lohnt? Zunächst suche ich nach Abfragen, die häufig ausgeführt werden. Bei ihnen mögen zwar die Kosten für eine einzige Ausführung nicht sehr groß sein, aber die aggregierten Kosten für alle Ausführungen können wesentlich größer sein als bei einer großen, selten ausgeführten Abfrage. Das soll keinesfalls heißen, dass sich eine Optimierung großer Abfragen nicht lohnen kann. Aber ich bin der Ansicht, dass man sich zuerst auf die am häufigsten ausgeführten Abfragen konzentrieren sollte. Wie also lassen sich diese ermitteln?
Leider ist die zuverlässigste Methode etwas kompliziert und erfordert die Durchführung einer Ablaufverfolgung für alle auf dem Server ausgeführten Abfragen und das anschließende Gruppieren der Abfragen anhand ihrer Signaturen. (Dabei werden im Abfragetext die eigentlichen Parameterwerte durch Platzhalter ersetzt, damit der gleiche Abfragetyp auch dann ermittelt werden kann, wenn die Ausführung mit anderen Parameterwerten erfolgt.) Dieser Vorgang ist kompliziert, da es schwierig ist, Abfragesignaturen zu erzeugen. Itzik Ben-Gan beschreibt in seinem Buch „Inside Microsoft SQL Server 2005: T-SQL Querying“ eine Lösung mit benutzerdefinierten CLR-Funktionen und regulären Ausdrücken.
Es gibt jedoch eine wesentlich einfachere, wenn auch nicht ganz so zuverlässige Methode. Dabei nutzen Sie die Statistiken, die im Ausführungsplancache für alle Abfragen gespeichert werden, und fragen diese mittels dynamischer Verwaltungsansichten ab. Abbildung 7 enthält eine Beispielabfrage, die sowohl den Text als auch den Ausführungsplan der 20 Abfragen in Ihrem Cache mit der höchsten Gesamtzahl von logischen Lesevorgängen zeigt. Diese Abfrage ist sehr praktisch zum schnellen Ermitteln der Abfragen, die die meisten logischen Lesevorgänge erzeugen, doch ihre Möglichkeiten sind begrenzt. Das liegt daran, dass sie nur die Abfragen anzeigt, deren Pläne zur Zeit der Abfrage bereits zwischengespeichert sind. Was nicht zwischengespeichert ist, kann auf diese Weise auch nicht erfasst werden.
Figure 7 Ermitteln der 20 aufwendigsten Abfragen in Bezug auf Lese-E/A (Close Figure 7)
SELECT TOP 20 SUBSTRING(qt.text, (qs.statement_start_offset/2)+1,
        ((CASE qs.statement_end_offset
          WHEN -1 THEN DATALENGTH(qt.text)
         ELSE qs.statement_end_offset
         END - qs.statement_start_offset)/2)+1),
qs.execution_count,
qs.total_logical_reads, qs.last_logical_reads,
qs.min_logical_reads, qs.max_logical_reads,
qs.total_elapsed_time, qs.last_elapsed_time,
qs.min_elapsed_time, qs.max_elapsed_time,
qs.last_execution_time,
qp.query_plan
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) qt
CROSS APPLY sys.dm_exec_query_plan(qs.plan_handle) qp
WHERE qt.encrypted=0
ORDER BY qs.total_logical_reads DESC
Sobald Sie die Abfragen mit den schlechten Leistungswerten ermittelt haben, betrachten Sie deren Abfragepläne und versuchen, die Leistung mithilfe der in diesem Artikel beschriebenen Indizierungsverfahren zu verbessern. Wenn es Ihnen gelingt, war die aufgewendete Zeit gut investiert.
Viel Spaß beim Optimieren!

Maciej Pilecki ist Associate Mentor bei Solid Quality Mentors, einer weltweit tätigen Organisation, die auf Schulung, Mentoring und Beratung spezialisiert ist. Er ist Microsoft Certified Trainer (MCT) und SQL Server-MVP (Most Valuable Professional) und bietet häufig Kurse an und hält oft Vorträge auf Konferenzen zu unterschiedlichen Aspekten von SQL Server und der Anwendungsentwicklung.


 Mitteilung der Redaktion: Mehr Leistung f&#252;r Sie
Mitteilung der Redaktion
Mehr Leistung für Sie

In der Ausgabe des letzten Monats wurde erstmals das Thema „Grüne EDV“ angesprochen, was hoffentlich zu einem andauernden Dialog führen wird. Es stimmt – dieses Thema ist immer noch nicht klar definiert. (Was bedeutet grün? Wenn mein Auto mit 10 Litern Benzin 120 statt 100 Kilometer weit kommt, ist das dann als grün zu bezeichnen? Nicht, dass ich ein Auto hätte. Ich lebe in New York, und hier geht man zu Fuß.)
Offenbar versucht jedes Unternehmen, das etwas auf sich hält, seine Produkte oder Dienste mit einem grünen Stempel zu versehen. Dies hat jedoch einen guten Grund, und daher erschien dieses Thema letzten Monat auf unserem Titelblatt – das Potenzial ist enorm.
Wir wissen alle, dass es dabei nicht nur um Umweltschutz, sondern auch das Generieren von Umsatz geht. Tatsache ist, dass Umweltfreundlichkeit ein Verkaufsargument geworden ist, das zu echten Ergebnissen führt. ("It's the economy, stupid!") Wenn ein Autohersteller mehr Autos verkaufen kann, weil sie effizienter sind – gut. Letztendlich haben wir hoffentlich eine gesunde Wirtschaft, die auf einer gesunden und nachhaltigen Umwelt basiert.
Wie wirkt sich das auf die IT-Branche aus? Dr. Jonathan Koomey, Wissenschaftler am Lawrence Berkeley National Laboratory und Professor an der Universität Stanford, hat kürzlich eine Studie veröffentlicht, die den gesamten Energieverbrauch von Servern in den USA und weltweit schätzte. 2005 waren Datenzentren (Server zusammen mit ihrer unterstützenden Infrastruktur wie beispielsweise Kühlsysteme) verantwortlich für 1,2 Prozent des gesamten Energieverbrauchs in den USA. Dies entspricht der Gesamtleistung von fünf 1000-Megawatt-Kraftwerken, wobei Kosten von 2,7 Milliarden $ anfallen. Weltweit steigen diese Kosten auf 7,2 Milliarden $ (was der Gesamtleistung von 14 1000-MW-Kraftwerken entspricht). Das ist enorm viel Geld (und Energie), die eingespart werden kann, und ein großer Teil dieser Arbeit kann im Datenzentrum beginnen.
Wie planen Sie Datenzentrumskapazität? Wie kann Kapazität so angepasst werden, dass sie die Nachfrage erfüllt, ohne jederzeit zu 100 Prozent verfügbar sein zu müssen? (Tipp: Virtualisierung.) Wir überwachen Server in Bezug auf Netzwerkkonnektivität, Speicherauslastung und so weiter, aber wer achtet auf den Energieverbrauch? Verbrauchen ältere Server deutlich mehr Energie als neue Computer? Sind diese erhöhten Kosten höher als die Kosten eines Ersatzcomputers?
In den nächsten Monaten wird einer unserer Fachleute, Dave Ohara (Autor des Artikels des letzten Monats, der jetzt online unter technetmagazine.com verfügbar ist), Ihnen zeigen, was wir hier bei Microsoft mit der Konstruktion unserer eigenen grünen Datenzentren in Quincy (Washington) und San Antonio (Texas) tun und wie einige dieser Fragen beantwortet werden. Wir möchten auch von Ihnen hören, wie Sie diese Probleme handhaben (oder weshalb Sie sich möglicherweise dagegen entscheiden). Senden Sie Ihre E-Mails an tnmag@microsoft.com, oder besuchen Sie unseren Blog unter blogs.technet.com/tnmag. – Joshua Hoffman

Unser Dank gilt folgenden technischen Experten von Microsoft: Tim Carroll, Omesh Desai, Steve Jenness, Sam Kroonenburg, Mutlu Kurtoglu, KC Lemson, Tim Mintner, Jim Truher, Buck Woody und Sudarshan Yadav.


 Toolbox: Neue Produkte f&#252;r IT-Experten
Toolbox
Neue Produkte für IT-Experten
Greg Steen

Videobildschirmaufzeichnung
My Screen Recorder Pro
deskshare.com/msrpro.aspx
Kommt es vor, dass Sie für ein in 20 Minuten beginnendes Meeting noch eine Präsentation der neuen Systemkonfiguration erstellen sollen? Müssen Sie Tag für Tag mit immer neuen Benutzern dasselbe Lernprogramm für eine Anwendung durchgehen? Wenn Ihnen das bekannt vorkommt, hier ein Tipp: My Screen Recorder Pro von DeskShare.
Mit dieser Anwendung können Sie, wie der Name schon verrät, die Aktivitäten auf Ihrem Desktop als Video aufzeichnen. Dies ist ideal, um in letzter Minute eine Präsentation zu erstellen oder ein wiederverwendbares Lernprogramm für Ihre Kunden aufzuzeichnen. My Screen Recorder Pro bietet zudem die Möglichkeit zur Audioaufzeichnung, sodass Sie das Video auch gleich mit den entsprechenden Erläuterungen versehen können. (Tipp: Stellen Sie vor der Aufnahme ein Skript oder eine Gliederung zusammen.)
Das Erstellen eines neuen Videos ist ganz einfach. Legen Sie zunächst den Bereich fest, der aufgezeichnet werden soll: der gesamte Desktop, ein anpassbarer Teil des Desktops, ein fester Teil des Desktops oder ein bestimmtes Anwendungsfenster. Klicken Sie dann auf die Schaltfläche „Record“ (Aufzeichnen).
Die Anwendung ermöglicht die Aufzeichnung als AVI, Windows Media® Video (WMV) oder Flash, sodass Sie Ihr Video leicht weitergeben und sogar in Webseiten einbetten und öffentlich als Streamingdatei anbieten können. Außerdem können Sie auch eine ausführbare Datei erstellen, sodass das Video auf den meisten Windows®-PCs ganz einfach lokal wiedergegeben werden kann. Das Video wird dabei in die ausführbare Datei eingebettet, was die Weitergabe erleichtert und die Wiedergabe für den Endbenutzer äußerst intuitiv macht.
Wenn das Lernprogramm oder die Präsentation mehrere Teile umfassen soll, können Sie diese auch getrennt aufzeichnen und dann zu einem Video zusammenstellen. Weiterhin können Sie das Video bearbeiten und beispielsweise die Aufnahme teilen oder ganz nach Belieben schneiden.
Für die meisten Anwendungen dürfte die Standardkonfiguration völlig ausreichen, bei Bedarf lassen sich aber Framerate, Audioqualität und Komprimierungseinstellungen speziell für Ihre Umgebung anpassen. So können auch eventuelle Größen- oder Bandbreiteneinschränkungen berücksichtigt werden. Auch ein einfacher Zeitraffermodus steht zur Verfügung, sodass langwierige Teile der Aufzeichnung (z. B. eine langsame Fortschrittsanzeige) komprimiert werden können. Ein weiteres nettes Feature ist die Möglichkeit, den Mauscursor für die Aufzeichnung zu ändern und mit Effekten zu versehen, um die Aufmerksamkeit des Zuschauers auf bestimmte Aktionen zu lenken. Zum Beispiel können Sie den Mauszeiger vergrößern oder einen Mausklick durch Ringe um den Zeiger verdeutlichen. Außerdem können Aufzeichnungen zum Archivieren mit einem Titel und einem Zeitstempel versehen werden.
Den ganz Raffinierten, Paranoiden oder Übervorsichtigen ermöglicht My Screen Recorder Pro auch zeitgeplante Aufzeichnungen. Außerdem kann das Programm über die Befehlszeile ausgeführt werden, sodass Sie diskret alle Aktivitäten auf einer Arbeitsstation überwachen können. Schließlich verfügt die Anwendung auch über integrierte Features zum Veröffentlichen der erstellten Videos auf einer FTP-Website. In Kombination mit dem Zeitplaner kann diese Funktion gut für Überwachungszwecke genutzt werden.

Preis: 99 $ (direkt) für eine Einzellizenz.
Präsentationserstellung durch Aufzeichnen der Desktopaktivitäten
Präsentationserstellung durch Aufzeichnen der Desktopaktivitäten

Datenträgerdefragmentierung
PerfectDisk 8
raxco.com/products/PerfectDisk2k
Die Festplattendefragmentierung ist für jedes Windows-System wichtig. Möglicherweise installieren und entfernen Sie ständig neue Anwendungen, Features und Softwareupdates. Für die Datenträgerdefragmentierung gibt es eine ganze Reihe von Dienstprogrammen, und erst letzten Monat wurde eines in dieser Rubrik vorgestellt. Die Defragmentierung ist jedoch wichtig, und PerfectDisk 8 von Raxco Software ist auf jeden Fall eine interessante Option. Zwar beinhalten alle Windows-Versionen bereits ein Defragmentierungstool, aber manchmal ist ein Dienstprogramm erforderlich, mit dem sich die Defragmentierung präziser steuern lässt. Wenn es Ihnen so geht, sollten Sie sich PerfectDisk einmal näher ansehen.
Wie man es wohl bei jedem Windows-Defragmentierungstool erwarten würde, lassen sich mit PerfectDisk 8 FAT16-, FAT32- und NTFS-Laufwerke defragmentieren. Zusätzlich ist es aber auch für RAID-Laufwerke geeignet. PerfectDisk 8 ist als Desktop- und Serverversion erhältlich und für Windows Vista® zertifiziert. Andere Windows-Versionen werden unterstützt, darunter Windows Server® 2003 und Windows 2000. Sogar für Exchange ist eine Version erhältlich.
Der Hersteller wirbt vor allem mit seiner SMARTPlacement-Technologie, bei der die Dateistruktur auf dem Datenträger für schnellere Zugriffsgeschwindigkeiten optimiert werden soll. Auf Windows XP-Systemen übernimmt die SMARTPlacement-Technologie beispielsweise die Verwaltung der Start- und layout.ini-Dateien und ordnet sie so, dass die Suchzeiten beim Systemstart reduziert werden. Neben der Defragmentierung eines ganzen Laufwerks lassen sich auch einzelne Dateien defragmentieren, sinnvoll beispielsweise nach dem Herunterladen einer großen ISO-Datei.
Um selbst die Systemdateien zu erreichen, die normalerweise bei laufendem Betriebssystem nicht bearbeitet werden können, bietet die Anwendung einen Offlinemodus, der beim nächsten Systemstart ausgeführt werden kann. Soweit möglich, kann die Anwendung auch versuchen den Datenträger für die Defragmentierung zu deaktivieren. Ein weiteres bemerkenswertes Feature von PerfectDisk ist die Bildschirmschoner-Defragmentierung, mit der die Defragmentierung automatisch gestartet wird, sobald sich der Bildschirmschoner einschaltet.
Mit der Befehlszeilenversion von PerfectDisk können Sie die Defragmentierung ganz einfach mit Ihrem bevorzugten Taskplaner planen und für die Remoteausführung einen beliebigen Systemverwaltungsagent auf dem System verwenden. Für größere Bereitstellungen sollten Sie auch das kostenlose PerfectDisk Command Center herunterladen, mit dem Sie die Anwendung von einem Remotestandort aus auf allen Arbeitsstationen im gesamten Unternehmen bereitstellen, aktualisieren, planen und konfigurieren können.

Preis: PerfectDisk 8 Professional (für den Desktop) ist ab 39,99 $ für eine Einzellizenz erhältlich. PerfectDisk 8 Server ist ab 239,99 $ für eine Einzellizenz erhältlich.
PerfectDisk bietet eine Vielzahl von Konfigurationsoptionen
PerfectDisk bietet eine Vielzahl von Konfigurationsoptionen

Buchbesprechung
Network Warrior
oreilly.com
Wenn Sie in Ihrem Unternehmen Cisco-Produkte einsetzen, dürfte das Buch Network Warrior von Gary Donahue (O'Reilly, 2007) für Sie sicher interessant sein. Dieses Buch bietet eine wertvolle Informationsquelle für eine breite Zielgruppe und ist für Netzwerk-Neulinge ebenso interessant wie für Fortgeschrittene mit CCNA-Zertifizierung und erfahrene Systemadministratoren, die ihre Netzwerkkenntnisse ein wenig auffrischen wollen.
Besonders ansprechend ist es, dass in dieser Veröffentlichung dem Netzwerkexperten anhand praktischer Anwendungen für Netzwerktechnologien schnelle Hilfe bei vielen alltäglichen Aufgaben geboten wird. Das Buch beginnt mit den Grundlagen und definiert zunächst genau, aus welchen Elementen ein Netzwerk aufgebaut ist. Weiter geht es mit einem Überblick über Hubs, Switches, VLANs, Trunking und VTP (VLAN Trunking Protocol), das Erstellen umfassender Strukturen mit STP (Spanning Tree Protocol) und die EtherChannel-Technologie von Cisco Systems.
Immer wieder finden sich in Network Warrior grundlegende Beispiele für das Internetwork Operating System (IOS) von Cisco und CatOS-CLI-Befehle (Command Line Interface, Befehlszeilenschnittstelle), zusammen mit Erläuterungen der Methoden und Technologien. Das Buch gewährt einen nützlichen Kurzeinblick hinter die Kulissen der aktuellen Methoden und eröffnet einmal etwas andere Perspektiven (z. B. warum es zusätzlich zu IOS immer noch CatOS gibt).
Weiterhin ist eine Besprechung von Routern und Routing im Allgemeinen mit Informationen zu den Grundlagen des Routings, von Metriken bis hin zu den administrativen Distanzen der verschiedenen Routingprotokolle enthalten. Sie finden dort auch Übersichten der Protokolle, z. B. OSPF (Open Shortest Path First), BGP (Border Gateway Protocol) und RIP (Routing Information Protocol).
Im Abschnitt über das Cisco-Protokoll HSRP (Hot Standby Router Protocol) befasst sich der Autor eingehend mit dem Thema Verfügbarkeit und erläutert einige grundlegende Konfigurationen zum Schutz einer Netzwerkinfrastruktur vor Ausfallzeiten. Es folgt eine Vorstellung der Features und Funktionen einiger Multilayerswitches von Cisco, darunter der Cisco 6500 und der Catalyst 3750, sowie eine Besprechung der grundlegenden Konfigurationen.
Auch die Informationen zum Thema Telekommunikation sind äußerst nützlich. Erklärt werden einige der wichtigsten Fachbegriffe, sodass Sie dem nächsten Besuch von Telekommunikationstechnikern nicht mehr ganz so hilflos gegenüber stehen. CSU/DSU (Channel Service Unit/Data Service Unit), die Konfiguration von DS3-Verbindungen und Frame Relays mit mehreren Knoten werden soweit erläutert, dass Sie sich auf dieser Grundlage auch mit Telekommunikationsexperten unterhalten können.
Das Buch enthält außerdem ein Kapitel mit nützlichen Ausführungen zum Thema Sicherheit und Firewalls, in dem Sie mehr über Konzeption und Konfiguration von Zugriffssteuerungslisten (Access Control Lists, ACLs) erfahren und in dem auch Authentifizierung, DMZs und bestimmte Konfigurationsoptionen für PIX-Firewalls behandelt werden. Lesenswert ist auch der kurze Abschnitt zur Firewall-Theorie, in dem die üblichen Netzwerkmantras (wie „Alles verweigern und nur das unbedingt Nötige zulassen“ oder „Sicherheit ist der Mittelweg zwischen Bequemlichkeit und Paranoia“) noch einmal betont werden.
Das letzte Kapitel von Network Warrior bietet einen Einblick in das Thema Netzwerkdesign, befasst sich mit den Grundlagen verschiedener Netzwerkinfrastrukturkonzepte, z. B. einer dreistufigen E-Commerce-Konfiguration und einem Collapsed-Core-Netzwerk ohne Verteilungsschicht, und unterstreicht dabei die Bedeutung von Dokumentations- und Benennungskonventionen.

Preis: 44,99 $ Listenpreis.

Dateisperrenverwaltung
WhoLockMe
dr-hoiby.com/WhoLockMe
Wie schön wäre es, wenn jede Anwendung Dateien richtig schließen würde. Doch leider sieht die Realität häufig anders aus. Freigabeverletzungen können wirklich störend sein, und herauszufinden, welcher Prozess den Zugriff auf eine Datei verhindert, kann sogar lästig werden. Ich weiß nicht, wie es Ihnen geht, aber ich hasse es, eine Anwendung nach der anderen schließen zu müssen, bis eine Datei wieder freigegeben wird. Glücklicherweise gibt es eine einfache kostenlose Erweiterung für Windows Explorer, die hier Abhilfe schafft: WhoLockMe.
Mit dieser für Windows NT®, Windows 2000, Windows Server 2003 und Windows XP verfügbaren Anwendung können Sie ermitteln, welcher Prozess gerade den Zugriff auf eine Datei verhindert. Dies alles erfolgt lediglich mit einem Rechtsklick und durch Auswahl eines Befehls im Kontextmenü von Windows Explorer.
WhoLockMe zeigt den Namen des Prozesses an, der eine Datei sperrt, die Prozess-ID (Process Identifier, PID), den Pfad zur geöffneten Datei, Domäne und Benutzer des Ausführungskontexts des betreffenden Prozesses sowie den vollständigen Pfad zur entsprechenden Anwendung. Wenn Sie mutig genug sind, können Sie den Prozess sogar direkt von der Benutzeroberfläche beenden.
Leider wurde WhoLockMe schon seit einiger Zeit nicht mehr aktualisiert und ist nicht für Windows Vista geeignet. Trotzdem: Wenn Sie mit einer älteren Windows-Version arbeiten, können Sie mit diesem Tool schnell und effizient herausfinden, wer oder was den Zugriff auf eine Datei verhindert, die verschoben, gelöscht oder bearbeitet werden soll.

Preis: Kostenlos

DNS-Tools
DNSStuff.com
www.dnsstuff.com
Wenn Sie mit Anwendungen oder Netzwerken mit Internetverbindung zu tun haben, nutzen Sie für Verwaltung und reibungslosen Betrieb sicher DNS und teilen auf diese Weise Außenstehenden mit, wo sich Anwendungen befinden. Ein Toolset, auf das ich mich beim Thema DNS gerne verlasse, stammt von DNSstuff.com. Diese Sammlung webbasierter Tools ist eine große Hilfe beim Beheben von Problemen und Überprüfen von Infrastrukturkonfigurationen.
Auf dieser Website finden Sie Tools für Domänen-, IP-, Hostname-, E-Mail-, Website- und allgemeine Netzwerkprobleme. Über 45 verschiedene Abfragetools sind vom Überprüfen der Mailserverkonfiguration bis hin zum Testen der Geschwindigkeit des DNS-Hosts nützliche Helfer. Wahrscheinlich stehen innerhalb Ihrer Infrastruktur die Funktionen der meisten dieser Tools bereits zur Verfügung, aber externe Tests können manchmal den entscheidenden Hinweis zum Beheben eines Fehlers geben. Außerdem müssen Sie keine Bekannten außerhalb Ihrer Firma mehr bitten, ein DNS-Reverse-Lookup für Sie durchzuführen.
Eines der leistungsfähigsten und umfassendsten Tools auf dieser Website ist DNSreport. Geben Sie einfach den Domänennamen ein, klicken Sie auf die Schaltfläche, und schon erhalten Sie umfassende Informationen zu Ihrem Setup. Der Status jedes Testzeilenelements wird in Form einer Farbcodierung angezeigt, sodass Sie die Testergebnisse auf der Suche nach eventuellen Problemen schnell überfliegen können. Überprüft werden die übergeordneten Zonen der Domäne, und es werden Details wie Namenservereinträge (Name Server, NS) angezeigt, und ob die IP-Adresse sowie der Hostname gesendet werden. Auch mögliche Sicherheitslücken werden überprüft, beispielsweise dass die DNS-Server nicht offen sind, dass alle identische NS-Einträge aufweisen und dass bei Nicht-NS-Anforderungen keine NS-Einträge verborgen gesendet werden.
Sie erhalten dazu Einblick in die Verfügbarkeit Ihres Setups, da DNSreport beim Überprüfen einzelner Fehlerquellen auch testet, ob mehrere Namenserver oder öffentliche IP-Bindungen vorhanden sind oder Namenserver fehlen. Zusätzlich überprüft DNSreport die Autoritätsursprungsdetails (Start of Authority, SOA), gibt die SOA-Seriennummer sowie die Werte für Aktualisierung, Ablauf, Wiederholung und Mindestgültigkeitsdauer (Time-to-Live, TTL) zurück und testet MNAME- und RNAME-Einträge.
Bei der Überprüfung der MX-Einträge werden Reverse-DNS-Einträge validiert und sichergestellt, dass keine Einträge doppelt vorhanden sind und dass die Einträge gültige Hostnamen aufweisen. Weiterhin versucht das Tool, eine Verbindung zu Ihrem Mailserver herzustellen und beispielsweise zu überprüfen, ob der Hostname Ihres Mailservers in der Anfangsmeldung enthalten ist, ob abuse@yourdomain-Nachrichten (wie in verschiedenen RFCs definiert) akzeptiert werden und ob der SMTP-Server derzeit als offenes Relay konfiguriert (und damit geradezu ein Magnet für Spammer) ist. Schließlich gibt DNSreport Ihren www-A-Eintrag zurück, überprüft, dass alle IPs öffentlich sind, und bestimmt, ob Ihre CNAME-Konfiguration einen zusätzlichen DNS-Lookup auslöst.
Wenn Ihnen DNSreport nicht genügt, können Sie mit den Suchtools auf dieser Site auch überprüfen, ob ein Mailserver in einer Liste bekannter Spamdatenbanken enthalten ist, oder den Abuse-Kontakt einer Domäne ermitteln. Sie können IP-Whois-Suchen durchführen, Routen und Pingsignale verfolgen und allgemeine DNS-Lookups sowie zwischengespeicherte DNS-Lookups für wichtige ISPs durchführen. Sogar NETGEO-IP-Lookups, die Überprüfung von MAC-Adressen und Sicherungen von Zonendateien sind bei Abonnement möglich. Dies ist alles in allem ein äußerst praktisches Toolset.

Preis: 3 $ pro Monat für eine Einzelmitgliedschaft (voller Zugriff und unbegrenzte Lookups).
DNSstuff.com bietet eine Vielzahl praktischer Überwachungstools
DNSstuff.com bietet eine Vielzahl praktischer Überwachungstools

Greg Steen ist Technologieexperte und Enthusiast. Er ist immer auf der Suche nach neuen Tools, um IT-Experten die Betriebs-, Qualitätssicherungs- und Entwicklungsprozesse zu erleichtern.


 Exchange Fragen &amp; Antworten: Sichere E-Mail-Protokolle, r&#228;tselhaftes Spam und mehr
Exchange Fragen & Antworten
Sichere E-Mail-Protokolle, rätselhaftes Spam und mehr
Nino Bilic and Scott Landry
Dieser Artikel basiert auf einer Vorabversion von Windows Server 2008. Die in diesem Artikel enthaltenen Informationen können jederzeit geändert werden.

F: Ich möchte sicheres SMTP verwenden. Wie erreiche ich, dass Exchange Server SMTP auf Port 465 abhört?
A: Leider ist dies nicht möglich. Sie können zwar erreichen, dass ein virtueller SMTP-Server oder ein Empfangsconnector auf Port 465 abhört, doch damit erzielen Sie kein sicheres SMTP (SMTPS).
Warum? Dafür muss etwas weiter ausgeholt werden. Es gibt zwei Arten von SSL: explizit und implizit. Am Anfang handelte es sich bei SSL in den meisten Fällen um den impliziten Typ, das heißt, dass für SSL ein dedizierter Port verwendet wurde. Zum Beispiel befindet sich HTTP standardmäßig auf Port 80, doch HTTPS (HTTP mit SSL) befindet sich auf Port 443. Vor mehreren Jahren hat sich die Internetcommunity dafür ausgesprochen, dass für SSL kein dedizierter Port erforderlich sein soll. So entstand der explizite SSL-Typ.
Netscape hatte bereits 465 als SMTPS-Port gewählt, doch Exchange Server enthielt keine SSL-Funktionalität in SMTP. Das Exchange-Team sah jedoch die Vorteile des expliziten SSL (dass es sowohl von Clients als auch von Servern genutzt werden kann) und entschied sich, das explizite SSL für SMTP zu unterstützen.
Im Fall des SMTP verwendet das explizite SSL den STARTTLS ESMTP-Befehl, um zu signalisieren, dass der vorhandene Socket gerade gesichert wird. Die Mehrzahl der anderen Hersteller von SMTP-Servern und -Clients haben den STARTTLS-Befehl ebenfalls implementiert, sodass kein Grund bestand, Port 465 zu unterstützen, der ja keinen offiziellen Internetstandard darstellte.
Bislang wird das implizite SSL für SMTP von keiner Exchange Server-Version unterstützt. Dem Exchange-Empfangsconnector oder dem virtuellen SMTP-Server die Anweisung zu geben, auf Port 465 abzuhören, ändert nichts an dieser Tatsache. Deshalb müssen Sie einen Client verwenden, der STARTTLS auf Port 25 unterstützt. Wenn Sie Port 25 nicht verwenden können, ist die nächste logische Auswahl 587 – der Standardport für Client-SMTP-Übermittlungen. Es gibt nicht viele moderne Clients, die STARTTLS auf 25 nicht unterstützen. Also gab es keinen Bedarf, die Unterstützung für implizites SSL hinzuzufügen.
Nebenbei bemerkt haben die Exchange POP3- und IMAP4-Protokolle immer implizites SSL unterstützt. Doch in Exchange Server 2007 ist jetzt auch für diese beiden Protokolle zusätzliche Unterstützung für explizites SSL enthalten. Da viele Clients diesen neueren Standard noch nicht unterstützen, wird implizites SSL soweit absehbar weiterhin verfügbar sein.

F: Ich habe eine große Anzahl von E-Mails, die sich in der Warteschlange für eine Reihe von Domänen befinden. Doch keine dieser E-Mails stammt von meinen Benutzern. Was geschieht hier, und wie verhindere ich es?
A: Das ist ein allgemeines Problem. Alle, die über einen Server auf dem Internet verfügen, können mit diesem Problem konfrontiert werden. Grundsätzlich gibt es zwei mögliche Ursachen. Die erste ist, dass Sie Relay (siehe support.microsoft.com/kb/304897) ermöglicht haben. Das ist eher nicht anzunehmen. (Offene Relays sind seit Exchange Server 2000 standardmäßig deaktiviert.) Es ist also wahrscheinlicher, dass es sich hier um NDR-Spam (Unzustellbarkeitsbericht, non-delivery report) handelt. Beim Senden von Junk-E-Mails senden Spammer oftmals an nicht vorhandene Adressen in Ihrer Domäne. Ihr Server versucht, dem Spammer mitzuteilen, dass die Benutzer nicht existieren, doch natürlich hat der Spammer die Absenderadresse manipuliert. Es kann sein, dass der Spammer eine ungültige Adresse verwendet (in diesem Fall wird der NDR eine Zeit lang blockiert, bis die Zeit abgelaufen ist) oder dass er versucht, Ihren Server dazu zu bringen, in seinem Namen Spam an eine andere Domäne zu senden, und zwar als Anlage des Unzustellbarkeitsberichts, den Ihr Server generiert hat.
Sie könnten NDRs deaktivieren, doch wenn ein legitimer Benutzer sich bei einer Adresse versehentlich vertippt, wird Ihr Server keine Benachrichtigung senden, dass die E-Mail nicht empfangen wurde, und wichtige Nachrichten könnten so verloren gehen. Hier ist eine bessere Lösung.
Stellen Sie als Erstes sicher, dass Relay nicht möglich ist. (Soll hier einfach noch einmal erwähnt werden.) Aktivieren Sie als Nächstes eine Art von Antispamfilterung, zum Beispiel den intelligenten Nachrichtenfilter (intelligent message filter, IMF) oder den Exchange Server 2007-Inhaltsfilter sowie einige Echtzeit-Sperrlisten (Realtime Block Lists, RBLs). Dies kann in der Edge-Transport-Funktion oder der Hub-Transport-Funktion erfolgen, sollte jedoch beim allerersten Hop geschehen, da es sich bei 90 Prozent aller E-Mails in der Regel um Spam handelt und es nicht wünschenswert ist, die Server damit zu belasten.
Aktivieren Sie schließlich die Empfängerfilterung für den ersten Exchange Server, der die E-Mails in Ihrer Umgebung annimmt. Dies ermöglicht Ihrem Server, eine Nachricht abzulehnen, bevor sie in Ihr Netzwerk gelangt. Bei Tippfehlern in legitimen Adressen wird nach wie vor ein NDR gesendet, doch dieser Unzustellbarkeitsbericht wird vom Server des Absenders generiert.

F: Ich habe einen Server unter Exchange Server 2000 ausführen lassen und einen unter Exchange Server 2003, und beide sendeten erfolgreich E-Mails an das Internet. Dann habe ich Exchange Server 2007 installiert, und jetzt können die Postfächer auf beiden Servern keine E-Mails mehr senden.
A: Wenn Sie früher nur einen Exchange Server hatten, sind Sie möglicherweise nicht ausreichend mit dem Konzept der Connectors vertraut. Exchange-Connectors sind logische Routerkonfigurationsobjekte, die Exchange mitteilen, wo die E-Mail hingeleitet werden soll. Wenn Sie Exchange Server 2007 in einer bestehenden Organisation einführen, um E-Mails weiterzuleiten, müssen Sie unbedingt über Routinggruppenconnectors und einen SMTP-Connector verfügen.
Sie werden zwei Routinggruppenconnectors benötigen: einen von der Exchange Server 2007-Routinggruppe zum Exchange Server 2003-Routinggruppe sowie umgekehrt. Sie können dies als Teil des Installationsvorgangs festlegen, aber wenn Sie dies versäumt haben oder sich nicht sicher sind, können Sie es anhand der Exchange-Verwaltungsshell überprüfen und dort das Problem korrigieren. Andernfalls werden Sie zwischen Ihren Servern keine E-Mails senden können. Die Nachrichten landen dann in unzugänglichen Zielwarteschlangen.
Um Internet-E-Mails weiterzuleiten, benötigen Sie nur einen einzigen SMTP-Connector, der in Exchange Server 2007 auch als Sendeconnector bekannt ist. Es sollte einer in Exchange Server 2000 und einer in Exchange Server 2003 vorhanden sein, doch möglicherweise sind Sie ohne einen ausgekommen. Der Adressraum sollte für alle Domänen „SMTP:*“ sein. Sie können festlegen, ob ein Smarthost oder DNS für das Zustellen von E-Mails verwendet werden soll. Sie wählen aus, ob ausgehende Internet-E-Mails vom Exchange Server 2007-Server oder vom älteren Server behandelt werden sollen, oder Sie können für beide Routinggruppen einen erstellen, wenn Sie möchten, dass jeder Server seine eigenen E-Mails behandelt. Sie können außerdem einen davon als Teil des Edgesync-Prozesses erstellen, wenn Sie eine Edge-Transport-Serverfunktion installiert haben.
Wenn Sie zuvor einen Smarthost auf den virtuellen SMTP-Server gestellt haben, ist jetzt eine guter Zeitpunkt, um ihn zu entfernen. Er sollte sich nur auf dem SMTP-Connector und in keinem Fall auf dem virtuellen Server befinden, da dadurch der Routinggruppenconnector unterbrochen wird.
Sie sollten außerdem daran denken, dass eingehende E-Mails von Ihrem MX-Datensatz oder dem IP gesteuert werden, an den bzw. das die Firewall weiterleitet. Was Exchange angeht, gibt es nicht viel zu konfigurieren, doch dieses Dokument dürfte Ihnen helfen, falls Sie immer noch Schwierigkeiten haben: msexchangeteam.com/archive/2006/11/17/431555.aspx.

F: Warum erhalte ich mehrere Journalberichte für dieselbe Nachricht in Exchange Server 2007?
A: Der Journal-Agent des Exchange Server 2007-Transports erfasst die Nachrichten nach ihrer Einstufung. Das Kategorisierungsmodul hat viele Gründe, warum es eine Nachricht teilt (d. h. den Nachrichtentext kopiert und die jeweiligen Umschlagsempfänger auf die jeweiligen Kopien setzt). Hier ist ein Beispiel: Da die Journalfunktion jetzt die Fähigkeit hat, Ihnen mitzuteilen, welche Mitgliedschaft eine Verteilergruppe zur Absendezeit der Nachricht hatte, könnten Sie zum Beispiel für eine verschachtelte Verteilergruppe mehrere Berichte abrufen.
Diese zusätzliche Funktion in der Berichterstattung bedeutet, dass Sie mehrere Kopien derselben Nachricht, jeweils mit einem speziellen Bericht, erhalten können. Es gibt keine Möglichkeit, um mit Sicherheit zu wissen, ob alle Berichte für eine Nachricht angekommen sind, doch wenn Sie archivieren, werden Sie sicher gemeinsam mit dem Hersteller des Archivs sicherstellen wollen, dass die Änderungen berücksichtigt werden.

F: Was ist mit dem Feature in Exchange Server 2007 zum Weiterleiten nicht aufgelöster Nachrichten an den Host geschehen? What do I do now?
A: Dieses Feature gibt es nicht mehr.
Genau genommen hat es in Situationen mit mehr als einem Exchange Server nie so richtig gut funktioniert. Exchange hat allerdings dasselbe bereits auf eine andere, viel leistungsfähigere Weise erreicht. Sie haben vor allem die Möglichkeit, einzelne SMTP-Domänen mit anderen Systemen gemeinsam zu verwenden. Deshalb wurde das Feature für das Weiterleiten nicht aufgelöster Nachrichten aufgegeben, und das Konzept der freigegebenen Domäne wurde fortgesetzt und vereinfacht. Gehen Sie in Exchange Server 2007 zu „Organisation“ | „Hub-Transport“ | „Akzeptierte Domänen“, und ändern Sie den Domänentyp von „Autorisierend“ in „Internes Relay“. Für manche Umgebungen ist es nicht ganz so einfach wie hier geschildert, und es wird daran gearbeitet, die jeweiligen Abschnitte der Dokumentation zu aktualisieren. Doch in der Zwischenzeit dürfte dies eine Hilfe sein.

F: Ich versuche, meine Stammdomäne für die Exchange Server 2007-Installation vorzubereiten. Auf dem Server, von dem aus ich versuche, das Exchange Server 2007-Setup auszuführen, ist Exchange Server 2003 ESM (Exchange-System-Manager) installiert, und die Installation schlägt fehl. Wo liegt hier das Problem?
A: Kurz gesagt wird das Ausführen des Exchange Server 2007-Setup auf einem Computer, auf dem Exchange Server 2000- oder 2003-Komponenten installiert sind, nicht unterstützt. Da Exchange Server 2003 ESM installiert ist, wird dies vom Exchange Server 2007-Setup erkannt, sodass die Überprüfung der Setupvoraussetzungen mit der Fehlermeldung endet, dass eine frühere Version von Exchange Server bereits auf diesem Computer installiert ist. Führen Sie das Exchange Server 2007-Setup von einem anderen Computer aus, oder entfernen Sie die frühere Version von Exchange Server.
Am einfachsten umgehen Sie dieses Problem wahrscheinlich, indem Sie das Exchange Server 2007-Setup einfach von einem anderen Server in der Stammdomäne aus ausführen und Ihre Domäne auf diese Weise vorbereiten. Wenn das nicht durchführbar ist, muss die Exchange Server 2003-Komponente deinstalliert werden, bevor Sie das Exchange Server 2007-Setup fortsetzen können.
Denken Sie daran, dass Sie die 32-Bit-Version von Exchange Server 2007 verwenden können, um die Domäne vorzubereiten. Es kann also in der Regel jeder 32-Bit-Server in der Stammdomäne verwendet werden. Weitere Informationen zu diesem Thema erhalten Sie unter „technet.microsoft.com/library/bb232170.aspx“.
Das heißt übrigens, dass Sie Exchange Server 2003 ESM und die Exchange Server 2007-Exchange-Verwaltungskonsole nicht auf dem gleichen Computer installieren können, da das gleichzeitig Vorhandensein der Exchange Server 2003- und der Exchange Server 2007-Verwaltungstools auf dem gleichen Computer nicht unterstützt wird. Exchange Server 2007 blockiert das Setup, wenn Sie versuchen, es auf einem Computer zu installieren, auf dem eine Exchange Server 2000- oder Exchange Server 2003-Komponente installiert ist.
Abschließend soll darauf hingewiesen werden, dass Sie nicht versuchen sollten, zuerst die Exchange Server 2007-Verwaltungstools zu installieren und dann mit der Installation der Exchange Server 2003-Tools auf dem gleichen Computer fortzufahren. Mit diesem Ansatz erhalten Sie eine Konfiguration, die nicht getestet wurde und die beim Verwalten Ihrer Server zu unerwarteten Ergebnissen führen kann. Wenn Sie beide Serverversionen von einem einzigen Computer verwalten müssen, könnten Sie Remotedesktop verwenden, um eine Verbindung zu einer Version herzustellen, oder Sie könnten einen virtuellen Computer verwenden, um eine andere Version der Verwaltungstools in einer isolierten Umgebung zu hosten.

F: Wann wird es endlich möglich sein, die Exchange Server 2007-Verwaltungstools auf einer Windows Vista®-Arbeitsstation auszuführen?
A: Die offizielle Unterstützung für die Exchange Server 2007-Verwaltungstools unter Windows Vista wird mit der Veröffentlichung von Exchange Server 2007 SP1 eingeführt. Sobald Exchange Server 2007 SP1 veröffentlicht ist, wird ein Paket mit den Exchange Server 2007 SP1-Verwaltungstools zum Herunterladen verfügbar sein.

F: Was ist mit Exchange Server 2003 ESM unter Windows Vista oder Windows Server 2008? Werde ich es auch ausführen können?
A: Nein, das wird leider nicht möglich sein. Die Verwaltungstools für alle Versionen von Exchange Server vor Exchange Server 2007 SP1 wird weder unter Windows Vista noch unter Windows Server 2008 unterstützt. Das heißt, dass auch nach der Veröffentlichung von Windows Server 2008 das Installieren von Exchange Server 2003 ESM unter Windows Server 2008 nicht unterstützt wird. Die Verwaltung von Exchange Server 2003-Servern muss entweder von Windows Server 2003- oder Windows XP-Arbeitsstationen durchgeführt werden. Alternativ dazu können Sie die Remotedesktopverbindung von einem beliebigen Betriebssystem aus verwenden.

F: In meiner Domäne führe ich mehrere Exchange Server 2003-Server aus. Werde ich meine Domänencontroller auf Windows Server 2008-Domänencontroller aktualisieren können?
A: Ja, das Ausführen von Exchange Server 2003 SP2 in der Domäne, in der die Windows Server 2008-Domänencontroller installiert sind, wird unterstützt. Beachten Sie, dass Exchange Server die Windows Server 2008-Read-Only-Domänencontroller (read-only domain controllers, RODC) oder die globalen Read-Only-Katalogserver (read-only global catalog servers, ROGC) nicht verwenden kann. Die manuelle Festlegung (Hartcodierung) von Exchange Server für die Verwendung des Windows Server 2008-RODC/ROGC kann zu unerwartetem Verhalten führen.

Nino Bilic ist Supportability Program Manager für Exchange und verbringt seine Freizeit damit, sich in die Feinheiten der Server-zu-Server-Kommunikation zu vertiefen, indem er vor der Nachtruhe noch eine Flut von Netmon-Ablaufverfolgungen liest.
Scott Landryist Support Escalation Engineer für Exchange Server und nimmt, wohin er auch geht, sein Handtuch, ein Exemplar des Handbuchs und sein bewährtes Windows Mobile-Telefon mit.


 Schwerpunkt Dienstprogramme: SMS-Cmdlets f&#252;r Windows PowerShell
Schwerpunkt Dienstprogramme
SMS-Cmdlets für Windows PowerShell
Braun Don
Laden Sie den Code für diesen Artikel herunter: Utility2007_11.exe (1211KB)

Früher gab es keine Möglichkeit, Microsoft System Management (SMS) Server 2003-Clients über die Befehlszeile zu verwalten. Glücklicherweise findet sich unter den vielen großartigen Technologien, mit deren Hilfe Administratoren jetzt Komplexität, Änderungen und Konfiguration verwalten können, Windows PowerShell. Damit lässt sich das Problem lösen.
Um die Vorteile von Windows PowerShell nutzen zu können, habe ich ein kleines „Dienstprogramm“ geschrieben: SMS2003PowerShellSnapinSample (zu finden im Codedownload zu diesem Artikel, der online unter technetmagazine.com/code07.aspx verfügbar ist). Das Dienstprogramm ist im Wesentlichen eine Sammlung von sechs Cmdlets, zusammengefasst in einem einzigen Windows PowerShellTM-Snap-In. Mithilfe dieser Cmdlets können Sie die lokale Richtlinie des SMS-Clients über Windows PowerShell für den lokalen Computer oder Gruppen von Remotecomputern konfigurieren.
Je intensiver ich mich mit der lokalen Richtlinie des SMS-Clients beschäftigte, desto sinnvoller erschien mir dies. Als Nebenprodukt dieser Arbeit konnte ich mir außerdem weitere Kenntnisse über die Funktionsweise von SMS aneignen. Es wurde deutlich, dass der SMS-Client durch umsichtige Anwendung der lokalen Richtlinie des SMS-Clients auf völlig neue Weise gesteuert werden kann: Computer, die an denselben Standort berichten, müssen nicht alle identisch konfiguriert werden. So entstanden zahlreiche Ideen: von der Konfiguration bestimmter Computer auf solche Weise, dass keine Berechtigung zur Remoteüberwachung des Computers erforderlich ist, über die Änderung der Häufigkeit, mit der der Client prüft, ob eine neue Richtlinie vorliegt, bis hin zur Deaktivierung bestimmter Komponenten zu verschiedenen Tageszeiten. Bei Verwendung der lokalen Richtlinie des SMS-Clients sind die Möglichkeiten nahezu unbegrenzt. Im Folgenden wird dies näher betrachtet.

Lokale Richtlinie des erweiterten SMS-Clients
Programmierressourcen
  • Einführung in Windows PowerShell Ein guter Einstieg für alle, die noch nicht mit Windows PowerShell gearbeitet haben
  • Anpassen von SMS mithilfe lokaler Richtlinien – TechNet-Forum MOF-basierte Anwendung der lokalen Richtlinie des erweiterten SMS-Clients
  • Erstellen eines ersten Cmdlets
  • So erstellen Sie ein Windows PowerShell-Snap-In
  • Netzwerkzugriffsschutz (Network Access Protection, NAP) für Windows Server 2008
  • Programmiererhandbuch für Windows PowerShell Für alle, die zusätzliche Informationen zum Schreiben von Cmdlets, Snap-Ins, Hosts und weitere Programmierhilfen für Windows PowerShell benötigen
  • Schrittweise Anleitungen zu Windows Server 2008 Beta 3

Alle funktionalen erweiterten Clients von SMS 2003 verfügen über eine Konfigurationsrichtlinie. Im Wesentlichen ist dies eine Liste der Einstellungen, die den verschiedenen Komponenten zugrunde liegen. Alle Einstellungen für den Client, die Bestandserfassung und die Softwareverteilung (um nur einige zu nennen) sind in diesen Konfigurationsrichtlinien enthalten. Die Richtlinien selbst werden auf dem Standortserver erstellt und über den SMS-Verwaltungspunkt an den erweiterten Client weitergegeben.
Der eigentliche Text einer SMS-Richtlinie ähnelt einer MOF-Datei (Managed Object Format) insofern, als er einen Satz Instanzen enthält, die in die Namespaces unter \\.\root\CCM WMI (Windows® Management Instrumentation, Windows-Verwaltungsinstrumentation) auf dem erweiterten Client kompiliert werden. Die verschiedenen anderen Agents lesen diese Einstellungen, die sich im Namespace \\.\root\ccm\policy\machine\requestedconfig befinden. Beim Anwenden der lokalen Richtlinie über MOF können Sie jedoch nur eine MOF-Datei auf einem einzigen Computer kompilieren. Außerdem ist eine lokale Ausführung erforderlich (bzw. Sie müssen direkt am Computer angemeldet sein). Da WMI jedoch verteilt ist, kann sowohl lokal als auch von einem Remotestandort darauf zugegriffen werden, woraus sich für SMS-Administratoren eine größere Vielfalt an Optionen ergibt. Mit WMI können Sie also auf einem Remotecomputer ebenso leicht eine Verbindung herstellen wie auf dem lokalen Computer, die entsprechenden Administratorrechte vorausgesetzt.
Die SMS-Clientrichtlinie besteht aus Konfigurationseinstellungen für die verschiedenen Clientkomponenten, kann jedoch auch Anweisungen zum Ausführen von Softwarepaketinhalten umfassen. Wie bei der Active Directory®-Gruppenrichtlinie kann eine Richtlinie eines erweiterten SMS 2003-Clients, die von einem SMS-Verwaltungspunkt abgerufen wurde, von der lokalen Richtlinie des SMS-Clients außer Kraft gesetzt werden. Sie können zwar nicht alle Teile einer Richtlinie, jedoch einige wirklich interessante Eigenschaften außer Kraft setzen. Damit erhalten SMS-Administratoren ein größeres Maß an Kontrolle über die Konfiguration und den Betrieb des SMS-Clients, da am SMS-Standort Abweichungen von der Standardkonfiguration angewendet werden können.
Ein Beispiel: In einer sicheren und konsolidierten Umgebung werden sowohl Server als auch Arbeitsstationen von SMS-Administratoren als Clients eines einzigen primären SMS-Standorts verwaltet. In dieser imaginären Umgebung könnte von einer Sicherheitsrichtlinie vorgeschrieben werden, dass ein Benutzer um Erlaubnis gefragt werden muss, bevor ein Helpdesktechniker die Remotesteuerung seines Computers übernehmen kann. Dies stellt offensichtlich ein Problem dar, wenn die Helpdesktechniker mithilfe der Remotesteuerung auf die Server zugreifen möchten: Normalerweise sind auf den Servern keine Benutzer angemeldet, daher gibt es niemanden, der die Genehmigung zur Remotesteuerung gewähren könnte. Durch umsichtige Anwendung der lokalen Richtlinie kann die Forderung nach einer Benutzererlaubnis auf bestimmten Clients jedoch außer Kraft gesetzt werden. Wahrscheinlich sind Dutzende weiterer Situationen vorstellbar, in denen die lokale SMS-Richtlinie bei der Gewährung einer Ausnahme für die Konfiguration eines bestimmten SMS-Client-Agents von Nutzen sein kann.

Einblick in Windows PowerShell-Snap-Ins
Wenn Sie sich mit den Grundlagen von Windows PowerShell vertraut gemacht haben, können Sie den Beispielquellcode in diesem Artikel erweitern, um die Möglichkeiten des Arbeitens mit der lokalen Richtlinie des SMS-Clients über die Befehlszeile auszubauen. Bestimmte Attribute sollten auf eine Klasse angewendet werden, bevor diese für Windows PowerShell verfügbar gemacht wird. Sie müssen den Zweck des Cmdlets bestimmen und entscheiden, welche Aktion ausgeführt werden soll. Dies wird als Verb-Nomen-Paarung bezeichnet. Einige der häufigen Verben in Windows PowerShell sind Add, Get und Set. Der Nomenanteil beschreibt das Objekt, für das die Aktion durchgeführt werden soll. Cmdlets verfügen in der Regel über Parameter, die in einer Cmdlet-Klasse als öffentliche Eigenschaften verschiedener Typen deklariert sind. Schließlich soll die ProcessRecord-Funktion erwähnt werden – hier wird ein Großteil der Arbeit ausgeführt. Die in Abbildung 1 gezeigte generische Vorlage können Sie zum Erstellen eigener Cmdlets verwenden.
Figure 1 Cmdlet-Vorlage (Close Figure 1)
[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true,
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}
Wenn Sie das Snap-In kompiliert haben, registrieren Sie es in Windows PowerShell, indem Sie eine Klasse in Ihr Projekt aufnehmen, für die das RunInstaller-Attribut festgelegt und einige spezifische Eigenschaften definiert wurden. Einzelheiten finden Sie im Quellcode zu diesem Artikel. Zur Registrierung des Snap-Ins benötigen Sie das Tool „InstallUtil.exe“, das Bestandteil von Microsoft® .NET Framework ist. Abbildung 2 zeigt die Syntax, die zur Registrierung des Snap-Ins verwendet wird. Beachten Sie, dass dieser Vorgang in Windows Vista® eine Erhöhung der Berechtigungen erfordert. Daher müssen Sie Windows PowerShell mit der Option zum Öffnen als Administrator öffnen oder die Skripterhöhungs-PowerToys für Windows Vista verwenden (die Sie unter technetmagazine.com/issues/2007/06/UtilitySpotlight herunterladen können).
Figure 2 Installieren des Snap-Ins aus Windows PowerShell (Close Figure 2)
PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42
Copyright (C) Microsoft Corporation. All rights reserved.
Running a transacted installation.
...
The transacted install has completed.
Die nächste Aufgabe besteht darin herauszufinden, ob das Snap-In von Windows PowerShell anerkannt wird. Wenn Sie das Get-PSsnapin-Cmdlet mit dem Registered-Parameter verwenden, fasst Windows PowerShell die derzeit geladenen Snap-Ins zusammen und gibt eine Liste der registrierten Snap-Ins aus, die hinzugefügt werden sollen. Ihr Snap-In sollte in dieser Liste aufgeführt sein:
PS> Get-PSsnapin -registered
Jetzt können Sie der Shell das Windows PowerShell-Snap-In mithilfe des Add-PSsnapin-Cmdlets hinzufügen:
PS> add-pssnapin SMS2003PowerShellSnapinSample
Nach erfolgreich abgeschlossenem Vorgang müssten Sie die Cmdlets in Ihrem Windows PowerShell-Snap-In ausführen können.
Um alle Cmdlets zu sehen, die von einem Windows PowerShell-Snap-In verfügbar gemacht werden, geben Sie einfach das entsprechende Snap-In mit dem Get-Command-Cmdlet an, wobei Sie den Namen des Snap-Ins als Wert für den PSsnapin-Parameter übergeben. Das Beispiel-Snap-In in diesem Artikel zeigt sechs Cmdlets an, einschließlich der Cmdlet-Vorlage „Verb-Noun“ (siehe Abbildung 3).
Abbildung 3 Anzeigen der Cmdlets in einem Snap-In
Abbildung 3 Anzeigen der Cmdlets in einem Snap-In
Im Beispielquellcode wurden lediglich für das Get-SMSServerConnection-Cmdlet Hilfeanmerkungen geschrieben, um zu veranschaulichen, wie es erstellt wird. Wenn Sie die Hilfe erweitern möchten, finden Sie in der XML-Datei ein Beispiel, das Sie als Modell verwenden können. Abbildung 4 zeigt die Hilfeausgabe.
Figure 4 Beispielausgabe für „Get-Help“ (Close Figure 4)
PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS
Sie wissen nun, wie das Windows PowerShell-Snap-In installiert wird, wie Sie herausfinden, welche Befehle im Snap-In vorhanden sind, und wie Sie Hilfe zu einem typischen Cmdlet erhalten können. Als Nächstes sollen die Cmdlets verwendet werden. Um eine Liste aller Sammlungen auf einem primären SMS-Standortserver anzuzeigen, können Sie den folgenden Befehl verwenden:
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name
Beachten Sie die Pipeline. Dies ist eine für die Funktionsweise von Windows PowerShell zentrale Komponente und ein äußerst leistungsfähiges Tool. Es wäre möglich, in Windows PowerShell fast alle Aufgaben in einer Zeile zu erledigen. Das Get-SMSServerConnection-Cmdlet stellt eine Verbindung mit dem SMS-Server her. Da das Get-Collections-Cmdlet über einen einzigen Eingabeparameter des Typs verfügt, der vom Get-SMSServerConnection-Cmdlet zurückgegeben wird, können Sie einfach die Ausgabe des Get-SMSServerConnection-Cmdlets an das Get-Collections-Cmdlet übergeben. So funktioniert die Pipeline. Dies ist ein gutes Beispiel dafür, wie komplexe Objekte von einem Cmdlet an ein anderes übergeben werden. Außerdem können Objekte in Variablen gespeichert werden. Wenn Sie dies in einem Windows PowerShell-Skript ausführen, sieht es in etwa so aus:
$SMS = Get-SMSServerConnection
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS
Die Ausgabe lässt sich u. U. ohne entsprechende Formatierung schlecht lesen, da „Get-Collections“ ein Objekt vom Typ „SMSCollections“ zurückgibt (im Grunde ein Objektarray vom Typ „SMSCollection“). Kurz gesagt, die Anzeige sieht nicht besonders schön aus, bis Sie entweder Sammlungen herausfiltern, an denen Sie nicht interessiert sind, oder die Anzeige in einer Tabelle unter Berücksichtigung nur der gewünschten Eigenschaften formatieren. Hierzu übergeben Sie die Ausgabe des Get-Collections-Cmdlets über die Pipeline an das Format-Table-Cmdlet, das nur die von Ihnen angegebenen Eigenschaften anzeigen kann. Beispielsweise können Sie | Format-Table Name, Members anfügen.
Es gibt jedoch eine bessere Möglichkeit, alle Elemente einer bestimmten Sammlung anzuzeigen. In diesem Beispiel ist dies „Get-CollectionMembers“. Dieses Cmdlet gibt ein Array von Zeichenfolgen zurück, die den Namen jedes einzelnen Elements der Sammlung repräsentieren. Wie Sie sicher bereits vermuten, ist dies ein hervorragender Kandidat für die Weitergabe über die Pipeline an das nächste Cmdlet.
Bis zu diesem Punkt war nicht von einer lokalen Richtlinie des erweiterten SMS-Clients die Rede, lediglich von Verbindungen zum primären SMS-Standortserver und Aufzählungen von Sammlungen und Sammlungselementen. Dieses Windows PowerShell-Beispiel-Snap-In umfasst noch zwei weitere Cmdlets namens „Enable-SoftwareDistribution“ und „Disable-SoftwareDistribution“. An diesem Punkt kommt die lokale Richtlinie des SMS-Clients ins Spiel. Durch diese letzten beiden Cmdlets wird die lokale Richtlinie des SMS-Clients für die Komponente des Softwareverteilungs-Client-Agents auf dem erweiterten SMS-Client verändert. Wie Sie möglicherweise aus dem Verbteil des Cmdlets bereits geschlossen haben, platziert „Disable“ eine Außerkraftsetzung der lokalen Richtlinie des Clients, die angibt, dass auch der Softwareverteilungs-Client-Agent deaktiviert werden soll. Auf die gleiche Weise entfernt das Verb „Enable“ alle Außerkraftsetzungen der lokalen Richtlinie des Clients und versetzt den Softwareverteilungs-Client-Agent wieder in den normalen Zustand zurück, der von der vom SMS-Verwaltungspunkt übergebenen SMS-Richtlinie definiert wird. Abbildung 5 zeigt ein Beispiel dafür, wie ein Windows PowerShell-Einzeiler aussehen könnte, der eine Außerkraftsetzung der lokalen Richtlinie des SMS-Clients für den Softwareverteilungs-Client-Agent festlegt, der dadurch für alle Mitglieder der benutzerdefinierten Sammlung von Windows Server 2003-Systemen deaktiviert wird. Der Einzeiler zum Entfernen aller Außerkraftsetzungen der lokalen Richtlinie des SMS-Clients für den Softwareverteilungs-Client-Agent in derselben Sammlung wird ebenfalls aufgeführt. Die Disable-SoftwareDistribution- und Enable-SoftwareDistribution-Cmdlets können auch allein verwendet werden, wenn Sie die lokale Richtlinie des SMS-Clients nur auf wenigen Computern ändern möchten.
Figure 5 Zusammenstellen der Cmdlets – Beispiele (Close Figure 5)
PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

Nächste Schritte
Der Beispielquellcode für diesen Artikel bietet Ihnen einen guten Ausgangspunkt für die Anwendung von Außerkraftsetzungen der lokalen Richtlinie des SMS-Clients auf Gruppen von Computern. Im Beispiel werden lediglich der SMS-Softwareverteilungs-Client-Agent und die Enabled-Eigenschaft erwähnt. Die anderen Client-Agents verfügen über zahlreiche weitere Eigenschaften, auf die Sie in der gleichen Weise Außerkraftsetzungen anwenden können. Nachdem Sie sich nun diesen allgemeinen Ausgangspunkt erarbeitet haben, besteht der nächste logische Schritt darin, weitere Komponenten der lokalen Richtlinie des SMS-Clients zu untersuchen. Überlegen Sie, welche Gruppen verwalteter Systeme gute Kandidaten für Außerkraftsetzungen der lokalen Richtlinie des SMS-Clients sein könnten, und welche Außerkraftsetzungen der lokalen Richtlinie sinnvoll wären. Ein letzter Hinweis: Sie sollten stets wissen, worauf Sie sich einlassen: Führen Sie immer gründliche Tests in einer Testumgebung durch.

Braun Don ist als Senior Premier Field Engineer bei Microsoft beschäftigt und arbeitet seit vielen Jahren mit SMS (bzw. SCCM). Sie erreichen ihn unter: donbrown@microsoft.com.


 The Cable Guy: Drahtloses einmaliges Anmelden
The Cable Guy
Drahtloses einmaliges Anmelden
Joseph Davies

Drahtlose Verbindungen, die bereits eingerichtet sind und sich dann mit einem privaten Netzwerk authentifizieren müssen, können eine zusätzliche Herausforderung für Benutzer und Administratoren darstellen. Ein Windows-basierter drahtloser Client, der Mitglied einer Active Directory-Domäne ist, muss eine IEEE 802.1X-basierte Authentifizierung durchführen, um eine geschützte
drahtlose Verbindung und eine Domänenanmeldung zu erreichen. Da die Authentifizierung entweder Benutzer- oder Computeranmeldeinformationen umfassen kann und da Domänenanmeldungen von der Netzwerkkonnektivität abhängig sind, kommt es zu Problemen beim Konfigurieren der Reihenfolge, in der die Authentifizierungen durchgeführt werden, sowie bei der Angabe der zu verwendenden Anmeldeinformationen. All dies kann sich auf Domänenanmeldungen auswirken und dazu führen, dass ein Benutzer mehrmals zur Eingabe der Anmeldeinformationen aufgefordert wird.
Erfreulicherweise können Sie mit drahtlosem SSO in Windows Vista® festlegen, dass die IEEE 802.1X-Authentifizierung für WPA2-Enterprise (Wi-Fi Protected Access 2), WPA-Enterprise und die 802.1X-Authentifizierung mit WEP (Wireless Equivalency Privacy) vor dem Benutzeranmeldevorgang erfolgen. Dadurch können Sie Domänenanmeldeprobleme in bestimmten Konfigurationen lösen. Drahtloses einmaliges Anmelden integriert außerdem nahtlos die Drahtlosauthentifizierung in die Windows®-Anmeldung, was zu einer insgesamt besseren Benutzerfreundlichkeit führt. Aus diesen Gründen werden im Artikel für diesen Monat die Features des drahtlosen SSO behandelt, sowie die Fragen, wie es konfiguriert wird und wie es beim Benutzeranmeldeprozess funktioniert.

Grundlagen des einmaligen Anmeldens
Ein drahtloser Windows-Client kann die Authentifizierung mit dem Drahtlosnetzwerk durchführen, indem er nur Computer- oder Benutzeranmeldeinformationen oder eine Kombination von beiden verwendet. Wenn nur Computeranmeldeinformationen verwendet werden, führt Windows vor der Anzeige des Windows-Anmeldebildschirms eine 802.1X-Authentifizierung durch. Dies gibt dem Drahtlosclientcomputer einen frühen Zugriff auf Netzwerkressourcen wie die Active Directory®-Domänencontroller.
Wenn nur Benutzeranmeldeinformationen verwendet werden, führt Windows ohne SSO die 802.1X-Authentifizierung durch, nachdem der Benutzeranmeldeprozess abgeschlossen ist. In Abbildung 1 wird die Start- und die Anmeldeabfolge für dieses Szenario dargestellt.
Abbildung 1 Abfolge, wenn nur Benutzeranmeldeinformationen für die Drahtlosauthentifizierung verwendet werden
Abbildung 1 Abfolge, wenn nur Benutzeranmeldeinformationen für die Drahtlosauthentifizierung verwendet werden
Das Verwenden der Benutzeranmeldeinformationen für die Drahtlosauthentifizierung hat zur Folge, dass Benutzer keine anfängliche Domänenanmeldung vornehmen können, weil keine lokal zwischengespeicherten Anmeldeinformationen für ihre Benutzerkonten vorhanden sind und weil keine Konnektivität zum Domänencontroller besteht, um die neuen Anmeldeinformationen zu authentifizieren. Außerdem schlagen einige Domänenanmeldevorgänge fehl, weil gerade keine Konnektivität zu den Domänencontrollern der Active Directory Domäne besteht. Anmeldeskripts sowie Aktualisierungen der Gruppenrichtlinie und der Benutzerprofile schlagen fehl, was zu Windows-Ereignisprotokollfehlern führt.
Beim Verwenden einer Kombination von Benutzer- und Computeranmeldeinformationen führt Windows eine 802.1X-Authentifizierung mit Computeranmeldeinformationen vor der Anzeige des Windows-Anmeldebildschirms durch. Nachdem sich der Benutzer angemeldet hat, führt Windows eine weitere 802.1X-Authentifizierung mit Benutzeranmeldeinformationen durch. Einige Netzwerkinfrastrukturen verwenden jeweils unterschiedliche virtuelle LANs (VLANs) für Computer, die sich mit Computeranmeldeinformationen authentifiziert haben, und für Computer, die Benutzeranmeldeinformationen verwendet haben. Falls die Authentifizierung zum Drahtlosnetzwerk mithilfe der Benutzeranmeldeinformationen und des Schalters zum benutzerauthentifizierten VLAN nach dem Benutzeranmeldeprozess stattfindet, erhält der drahtlose Windows-Client während des Benutzeranmeldeprozesses keinen Zugriff auf die Netzwerkressourcen auf dem benutzerauthentifizierten VLAN, wie zum Beispiel die Active Directory-Domänencontroller. Auch dies führt zum Fehlschlagen von Domänenanmeldevorgängen.
Ein anderes Problem tritt auf, wenn die Drahtlosauthentifizierung mit Benutzeranmeldeinformationen einen anderen Satz von Sicherheitsanmeldeinformationen verwendet als Benutzeranmeldeinformationen. Für solche Konfigurationen fordert Windows bei Beginn der Drahtlosauthentifizierung zusätzliche Benutzeranmeldeinformationen an, was verwirrend sein kann.
Das Feature des einmaligen Anmeldens in Windows Vista wurde entwickelt, um die Probleme der Domänenanmeldungen zu behandeln, computer- und benutzerauthentifizierte VLANs zu trennen und die Benutzer zu verschiedenen Zeiten zu verschiedenen Anmeldeinformationen aufzufordern. Mit SSO können Netzwerkadministratoren festlegen, dass die Drahtlosauthentifizierung mit Benutzeranmeldeinformationen vor dem Benutzeranmeldeprozess stattfindet. Wenn sich die für die Benutzeranmeldung und die Drahtlosauthentifizierung erforderlichen Benutzeranmeldeinformationen unterscheiden, werden alle erforderlichen Anmeldeinformationen angefordert und im Windows-Anmeldebildschirm erfasst.
Mit einmaligem Anmelden kann ein drahtloser Windows Vista-Client konfiguriert werden, um eine Drahtlosnetzwerkauthentifizierung mit Benutzeranmeldeinformationen vor dem Benutzeranmeldeprozess durchzuführen. In Abbildung 2 wird der neue Start- und die Anmeldeabfolge angezeigt.
Abbildung 2 Abfolge, wenn die Drahtlosnetzwerkauthentifizierung mit Benutzeranmeldeinformationen vor der Benutzeranmeldung stattfindet
Abbildung 2 Abfolge, wenn die Drahtlosnetzwerkauthentifizierung mit Benutzeranmeldeinformationen vor der Benutzeranmeldung stattfindet
Dies ermöglicht Konfigurationen, bei denen nur Benutzeranmeldeinformationen oder eine Kombination von Benutzer- und Computeranmeldeinformationen mit separaten VLANs ohne Funktionalitätsverlust verwendet wird. Weil der drahtlose Client über eine Netzwerkkonnektivität oder eine Konnektivität zum benutzerauthentifizierten VLAN verfügt, bevor der Benutzeranmeldeprozess beginnt, können Domänenanmeldevorgänge erfolgreich durchgeführt werden. Siehe zum Beispiel „Anschließen eines drahtlosen Windows Vista-Clients an eine Domäne“ unter microsoft.com/technet/network/wifi/vista_bootstrap_wireless.mspx.
Auf Grundlage der Konfiguration des Drahtlosprofils konsolidiert einmaliges Anmelden die Eingabefelder für die Benutzeranmeldeinformationen für die Drahtlosauthentifizierung und fügt sie dem Windows-Anmeldebildschirm hinzu. Deshalb werden alle Benutzeranmeldeinformationen für die Benutzeranmeldung und die Drahtlosauthentifizierung mithilfe der Benutzeranmeldeinformationen vom Benutzer gleichzeitig bereitstellt.
EAP-Methoden (Extensible Authentication-Protokoll), die für die neue EAPHost-Architektur in Windows Vista erstellt werden, können die EAP-Pre-Logon Authentication Provider (PLAP)-Unterstützungs-API verwenden, um die für die Authentifizierung auf dem Windows-Anmeldebildschirm erforderlichen Eingabefelder zu einzuschließen. Weitere Informationen finden Sie unter „SSO und PLAP“ unter msdn2.microsoft.com/bb530584.
Denken Sie als Beispiel für eine SSO-Sitzung an einen drahtlosen Windows Vista-Client, der so konfiguriert ist, dass er die Authentifizierung nur mit Benutzeranmeldeinformationen sowie Benutzernamen und Kennwort sowohl für die Domänenanmeldung als auch für die 802.1X-Authentifizierung durchführt. Wenn der Benutzer im anfänglichen Windows Vista-Bildschirm die Tastenkombination STRG+ALT+ENTF drückt, bestimmt SSO, dass die 802.1X-Authentifizierung vor der Benutzeranmeldung stattfinden muss. Wenn der Benutzer seinen Benutzernamen und sein Kennwort eingibt, führt SSO zuerst eine benutzerbasierte Drahtlosnetzwerkauthentifizierung durch und zeigt eine Nachricht an, die angibt, dass es eine Verbindung zum Drahtlosnetzwerk anhand seines Namens herstellt. Nach der Drahtlosauthentifizierung führt Windows Vista die Benutzeranmeldung durch und zeigt den Desktop des Benutzers an.

Konfigurieren des einmaligen Anmeldens
Vorgänge im Hintergrund
Zum besseren Verständnis des Drahtlosauthentifizierungsprozesses wird im Folgenden etwas ausführlicher behandelt, was beim aktiven Anmeldeversuch des Benutzers geschieht. Wenn ein Benutzer die Tastenkombination STRG+ALT+ENTF für die Benutzeranmeldung auf einem drahtlosen Windows Vista ausführenden Client drückt, werden die folgenden Schritte ausgeführt:
  1. Die drahtlose automatische Konfiguration legt das zu verwendende Drahtlosnetzwerkprofil fest. Wenn der drahtlose Client die Authentifizierung mit Computeranmeldeinformationen bereits erfolgreich durchgeführt hat, wird das gerade verbundene Drahtlosnetzwerkprofil verwendet. Wenn das festgelegte Drahtlosprofil so konfiguriert wird, dass es die Authentifizierung nur mit Computeranmeldeinformationen durchführt, ist keine zusätzliche Drahtlosauthentifizierung mit Benutzeranmeldeinformationen notwendig. Bei den Schritten 2 bis 6 wird angenommen, dass das ausgewählte Drahtlosprofil für die Authentifizierung mit Benutzeranmeldeinformationen und für einmaliges Anmelden konfiguriert ist und dass die Einstellung „Unmittelbar vor der Benutzeranmeldung ausführen“ ausgewählt ist.
  2. Der Benutzer gibt (falls nötig) seine Anmeldeinformationen für die Benutzeranmeldung und die Drahtlosauthentifizierung ein und initiiert die Benutzeranmeldung.
  3. Windows benachrichtigt den Benutzer, dass es versucht, eine Verbindung zum Namen des Drahtlosnetzwerks herzustellen.
  4. Windows versucht, eine Drahtlosnetzwerkauthentifizierung mit den Benutzeranmeldeinformationen durchzuführen. Wenn die Einstellung „Anzeige zusätzlicher Dialoge während der Einzelanmeldung zulassen“ aktiviert ist und der EAP-Typ für den Benutzer zusätzliche Dialogfelder anzeigen muss, zeigt Windows die Dialogfelder an. Wenn die Drahtlosauthentifizierung innerhalb der maximalen Verzögerung für die Konnektivität (in Sekunden) nicht erfolgreich stattfindet, wird die Drahtlosauthentifizierung abgebrochen. Wenn die Einstellung „Netzwerk verwendet ein anderes VLAN zur Authentifizierung mit Computer- und Benutzeranmeldeinformationen“ verwendet wird, führt Windows eine DHCP-Erneuerung der IP-Adressenkonfiguration des Drahtlosnetzwerks durch, wenn die Drahtlosauthentifizierung erfolgreich ist.
  5. Windows führt den Benutzeranmeldeprozess durch.
  6. Windows zeigt den Desktop an.
Wenn die Einstellung „Unmittelbar nach der Benutzeranmeldung ausführen“ ausgewählt wurde, führt Windows die Schritte in der folgenden Reihenfolge durch: 1, 2, 5, 3, 4, 6.

Zum Aktivieren und Konfigurieren des SSO können Sie die Gruppenrichtlinienerweiterung für Drahtlosnetzwerk-Richtlinien (IEEE 802.11) verwenden und die erweiterten Sicherheitseinstellungen für ein Drahtlosprofil einer Windows Vista-Richtlinie konfigurieren. Weitere Informationen finden Sie im Artikel „Einstellungen der Drahtlosnetzwerk-Gruppenrichtlinie für Windows Vista“ unter technetmagazine.com/issues/2007/04/CableGuy.
Wählen Sie im Dialogfeld „Erweiterte Sicherheitseinstellungen“ die Option „Einmaliges Anmelden für dieses Netzwerk aktivieren“, und konfigurieren Sie die SSO-Optionen nach Bedarf. In Abbildung 3 sehen Sie ein Beispiel für einmaliges Anmelden, das mit den Standardeinstellungen aktiviert wird.
Abbildung 3 Standardeinstellungen für einmaliges Anmelden
Abbildung 3 Standardeinstellungen für einmaliges Anmelden
Es gibt SSO-Einstellungen zur Durchführung der 802.1X-Drahtlosauthentifizierung unmittelbar vor oder nach dem Benutzeranmeldeprozess sowie zur Angabe des Zeitintervalls, innerhalb dessen die 802.1X-Authentifizierung abgeschlossen sein muss, bevor der Benutzeranmeldeprozesses beginnt. Sie können außerdem angeben, ob die Dialogfelder über die Konsolidierung der Eingabefelder im Windows-Anmeldebildschirm hinaus angezeigt werden sollen. Wenn zum Beispiel ein EAP-Typ erfordert, dass ein Benutzer das Zertifikat, das vom RADIUS-Server (Remote Authentication Dial-in User Service) während der Authentifizierung gesendet wird, bestätigt, kann der EAP-Typ das Dialogfeld anzeigen.
Sie können außerdem angeben, dass der drahtlose Client eine Erneuerung des Dynamic Host Configuration-Protokolls (DHCP) der TCP/IP-Konfiguration des Drahtlosadapters nach Durchführen der benutzerbasierten Authentifizierung initiieren soll. Wählen Sie diese Option aus, falls separate VLANs für computer- und benutzerbasierte authentifizierte drahtlose Clients vorhanden sind und diese VLANs sich von IPv4- oder IPv6-Subnetzen unterscheiden.
Nachdem Sie das Drahtlosprofil erstellt haben, das die SSO-Einstellungen innerhalb der Richtlinie enthält, können Sie drahtlose Windows Vista-Clients außerdem durch Exportieren des Profils als XML-Datei und durch anschließendes Importieren des XML-Profils in drahtlose Windows Vista-Clients konfigurieren.
Erstellen Sie zum Erstellen eines SSO-XML-Drahtlosprofils ein Drahtlosprofil mit den entsprechenden SSO-Einstellungen. Klicken Sie auf der Registerkarte „Allgemein“ der Windows Vista-Drahtlosrichtlinie auf das Drahtlosprofil mit den SSO-Einstellungen, und klicken Sie anschließend auf „Exportieren“. Geben Sie bei Aufforderung den Profil-XML-Dateinamen und seinen Speicherort an.
Importieren Sie zum Verwenden des SSO-XML-Profils für die Konfiguration eines anderen Windows Vista-Drahtlosclients das XML-Profil mit dem Befehl:
netsh wlan add profile filename=
    "[FileName].xml"
Um zu bestimmen, ob bei einem Drahtlosprofil einmaliges Anmelden aktiviert ist, verwenden Sie den Befehl:
netsh wlan show profile=[ProfileName]
Die SSO-Einstellungen sind im Abschnitt „Sicherheitseinstellungen“ der Befehlsanzeige „netsh wlan show profile“ und im Text der Ereignisse der drahtlosen Verbindung im Windows-Ereignisprotokoll aufgelistet. Sie können außerdem das Ereignisanzeige-Snap-In verwenden, um die Ereignisse im Verzeichnis „Microsoft\Windows\WLAN-AutoConfig“ der Anwendungs- und Dienstprotokolle mit der Quelle „WLAN-AutoConfig“ und den Ereignis-IDs 13001, 13002, 13003 und 13004 anzuzeigen.
Weitere Informationen erhalten Sie auf der Drahtlosnetzwerk-Webseite unter microsoft.com/wifi. Weitere Informationen zum SSO-Prozess finden Sie in der Randleiste „Vorgänge im Hintergrund“.

Joseph Daviesist technischer Redakteur bei Microsoft und lehrt und schreibt seit 1992 über Windows-Netzwerkthemen. Er hat fünf Bücher für Microsoft Press verfasst und ist der Autor der monatlich im TechNet-Magazin erscheinenden Rubrik „The Cable Guy“.


 Forschungsberichte: Verwenden von High Performance Computing im Kampf gegen HIV
Forschungsberichte
Verwenden von High Performance Computing im Kampf gegen HIV
Kristin Firth und Mia Matusow

Wenn Sie an medizinische Forschung denken, stellen Sie sich dann Männer und Frauen in weißen Laborkitteln vor, die mit Reagenzgläsern und Mikroskopen arbeiten? Vielleicht ein Team von Chemikern an einer Universität oder in einem pharmazeutischem Unternehmen? Dies sind übliche und sicher auch realistische Vorstellungen von medizinischer Forschung, aber sie stellen nur
einen Aspekt dieses Bereichs dar. In Wirklichkeit geschieht einiges an medizinischer Forschung an ganz anderen Schauplätzen.
Es überrascht Sie vielleicht, dass Microsoft Research bei der Entwicklung eines Impfstoffs gegen das HIV-Virus eine wichtige Rolle spielt. Mehr noch: Microsoft tut dies ohne einen einzigen Bunsenbrenner. Der äußere Rahmen sieht aus wie jeder andere Büroraum, ausgestattet mit normalen Schreibtischen und vielen PCs.
Aber welche Rolle spielt dann Microsoft in dieser ganzen Forschung? Die Leute in den weißen Laborkitteln, die Wissenschaftler an verschiedenen Universitäten und Forschungszentren, zu denen Massachusetts General Hospital in Boston, die Universität von Britisch-Kolumbien, die Universität von Washington, das Fred Hutchinson Krebsforschungszentrum und die Murdoch University in Australien gehören, sammeln in ihren Projekten erhebliche Datenmengen. Die eScience-Gruppe von Microsoft Research besteht aus etwa einem halben Dutzend Mitarbeitern und ist größtenteils in Redmond, Washington, angesiedelt (ein Mitarbeiter befindet sich in Neu-Mexiko). Die Gruppe ist den Wissenschaftlern beim Verarbeiten und Analysieren der riesigen Datenmengen behilflich. Microsoft Research wurde erstmals im Jahr 2003 in das Projekt eingebunden, und heute arbeitet die eScience-Gruppe mit Wissenschaftlern an verschiedenen Projekten zur Lösung gesellschaftsrelevanter Probleme zusammen. Das Team arbeitet eng mit externen Wissenschaftlern an der Erstellung benutzerdefinierter Lösungen für Projekte zusammen, bei denen Zahlen und Ergebnisse analysiert werden müssen.
Bei einem Projekt mit besonders hoher Priorität hilft Microsoft bei der Analyse von Daten im Zusammenhang mit HIV-Mutationsmustern. David Heckerman, MD, PhD und leitender Forscher bei Microsoft, erklärt, dass das HIV-Virus schnell mutiert, wenn es vom Immunsystem der infizierten Person angegriffen wird. „Wir arbeiten an einer Studie, mit der festgestellt werden soll, wie HIV in Reaktion auf das Immunsystem der Wirtsperson mutiert. Hierfür suchen wir Korrelationen zwischen dem Typ des Immunsystems eines Individuums und den HIV-Eiweißsequenzen, die es infizieren.“
Wissenschaftler entnehmen Proben von HIV-infizierten Personen, um den Typ ihres Immunsystems und die HIV-Sequenzen zu bestimmen. An dieser Stelle kommt die Zahlenanalyse ins Spiel: Die Studie sucht nach Korrelationen zwischen 3.000 HIV-Aminosäuren und Hunderten von Immunsystemtypen, bei vielen Hunderten von Individuen. „Wir haben statistische Tests erstellt, die zuverlässige Korrelationen mit einer geringeren Anzahl fälschlich positiver und negativer Ergebnisse zur Verfügung stellen“, sagt Carl Kadie, PhD, leitender Entwicklungsingenieur für Forschungssoftware bei Microsoft. „Aber diese Tests verlangen sehr viel Rechenleistung, und je mehr Testpersonen wir einbeziehen, desto besser. Es sollen möglichst Millionen Simulationen ausgeführt werden, um so äußerst zuverlässige Korrelationen zu erhalten.“

Einsatz von HPC im Kampf gegen HIV
Noch vor wenigen Jahren waren viele Forschungsprojekte aufgrund einer begrenzten Datenverarbeitungskapazität eingeschränkt. Mit nur einem halben Dutzend Computer verfügten die an diesem Projekt beteiligten Microsoft-Forscher nicht über genug Verarbeitungsleistung, um die Analyse in einem angemessenen Zeitraum durchzuführen. Die Prüfung jeder Position auf dem Genom des Impfstoffs und der verschiedenen Immunsystemtypen hätte für 200 Personen ein ganzes Jahr Arbeit bedeutet. Selbst wenn für diese Analyse 20 Computer zur Verfügung ständen, gäbe es nach wie vor das grundlegende Problem, dass die Tests manuell auf 20 getrennten Computern ausgeführt werden müssten, die dann 20 einzelne Ergebnissätze liefern, und dass ein weiteres Programm (sowie mehr Zeit) für eine Tabellarisierung der verschiedenen Ergebnissätze erforderlich wäre. Die Verwaltung all dieser Aufgaben, das Erfassen partieller Ausgaben und alle anderen damit verbundenen Einzelaufgaben hätten zu viel Zeit erfordert. Daher wendeten sich die Forscher an die HPC-Gruppe (High Performance Computing) bei Microsoft.
Im Jahr 2006 implementierten die Forscher Windows® Compute Cluster Server 2003. Diese HPC-Lösung eröffnete eine einfache Möglichkeit, die Leistung vieler Computer zu vereinen, die gemeinsam arbeiten. Windows Compute Cluster Server macht es im Wesentlichen möglich, die Arbeit über parallel ausgeführte Serverknoten zu verteilen. Die Aufgaben Datenverteilung auf die Knoten, Datenverwaltung sowie Zusammenführung der Ergebnisse sind vollständig automatisiert. Die Lösung umfasst Setupverfahren, eine Sammlung von Verwaltungstools sowie einen integrierten Auftragsplaner.
Schließlich waren mit dieser Lösung die größten technischen Hindernisse überwunden: die Rechenleistung war nicht mehr begrenzt, und der Prozess der Arbeitsverteilung und Datenverwaltung war vollständig automatisiert.

Das Setup
Für Microsoft Research war der Rechenclusteransatz genau richtig. Windows Compute Cluster Server 2003 ist hervorragend für Projekte mit Anwendungen geeignet, die immer wieder den gleichen Vorgang wiederholen, zum Beispiel, wenn Problemlösung und Analyse durch paralleles Ausführen von Aufgaben beschleunigt werden können. Diese Lösung sollte jedoch nicht leichtfertig gewählt werden, da HPC kostenintensiv sein kann, insbesondere in den Bereichen Energieversorgung und Kühlung. HPC beansprucht mehrere Server, deren CPU oft wochenlang zu 100 Prozent ausgelastet ist.
Als Nächstes ist die Größe des Clusters zu bestimmen, den sich die Organisation leisten kann, sowie der Speicherort. Wenn bereits eine Windows-basierte Umgebung mit Active Directory® vorhanden ist, steht Administratoren die erforderliche Infrastruktur zur Verfügung, um einen Cluster zu installieren, bereitzustellen und zu unterstützen. In Umgebungen, in denen Active Directory noch nicht verwendet wird, sind einige zusätzliche Konfigurationsschritte erforderlich.
Sie müssen weiterhin entscheiden, auf welche Weise Knoten innerhalb des Rechenclusters bereitgestellt werden sollen, d. h. Sie müssen wählen, ob Sie die zu Windows Compute Cluster Server 2003 gehörenden Tools oder Ihre eigenen internen Bereitstellungsverfahren verwenden wollen. Windows Compute Cluster Server 2003 selbst muss zusammen mit den Softwareanwendungen bereitgestellt werden, die Sie auf dem Cluster ausführen wollen. Dazu muss der Benutzerzugriff auf den Cluster eingerichtet werden, sodass Benutzer eine Verbindung zum Cluster herstellen und Aufträge senden können, was über die zugehörige grafische Benutzeroberfläche oder über Befehlszeilenschnittstellen möglich ist.
Windows Compute Cluster Server 2003 ist ein 64-Bit-Betriebssystem. (Die typische Architektur einer Windows Compute Cluster Server 2003-Umgebung ist in Abbildung 1 dargestellt.) Zum Zeitpunkt, an dem dieser Artikel verfasst wurde (Juni 2007), führte Microsoft Research eine Reihe verschiedener Anwendungen auf einem aus 25 IBM eServer 326-Servern erstellten Cluster aus. Jeder dieser Server weist zwei AMD Opteron-Prozessoren mit 2,6 GHz auf.
Abbildung 1 Leistung mit Windows Compute Cluster Server 2003 nutzen
Abbildung 1 Leistung mit Windows Compute Cluster Server 2003 nutzen
Nach der Bereitstellung von Windows Compute Cluster Server aktualisierte die Gruppe die zur Darstellung genetischer Korrelation verwendete Anwendung, sodass sie sich im Cluster ausführen ließ. Die Bereitstellung von Anwendungen für Rechencluster kann unterschiedlich komplex sein. Die Anwendungen selbst haben Einfluss darauf, wie viel Programmieraufwand erforderlich ist.
Zunächst verwendete die Gruppe die in Windows Compute Cluster Server integrierten Tools, um schnell eine generische Benutzeroberfläche einzurichten. Das war allerdings nur eine kurzfristige Lösung, und die Gruppe erstellte schon bald ihre eigene benutzerdefinierte Webanwendung, die größere Flexibilität bietet und die Option unterstützt, Wissenschaftlern außerhalb von Microsoft einige der Clusterknoten verfügbar zu machen. Microsoft ist nämlich Teil des Open Grid Forum, und manche der Microsoft Research-Cluster werden Benutzern an anderen Universitäten rund um die Welt zur Verfügung gestellt, sodass Forscher zusammenarbeiten und sich die Arbeit teilen können.
Zusätzlich zu grafischen Benutzeroberflächen unterstützt Windows Compute Cluster Server auch Befehlszeileneingaben und ermöglicht Benutzern somit die Skripterstellung. Weiterhin werden funktionsstarke APIs bereitgestellt, mit denen sich Programme schreiben lassen, die direkt mit dem Windows Compute Cluster-Auftragsplaner interagieren, ein Verfahren, für dessen Verwendung sich Microsoft Research entschied.

Erzielen von Ergebnissen
Dank dem Einsatz von High Performance Computing macht die eScience-Gruppe von Microsoft Research enorme Fortschritte im Wettrennen um die Entwicklung eines HIV-Impfstoffs. „Mit High Performance Computing verkürzen wir die Zeit bis zum Erzielen von Ergebnissen,“ so Heckerman. „Mehrere der externen Gruppen, mit denen wir zusammenarbeiten, verwenden jetzt unsere statistischen Verfahren und geben ihre Ergebnisse frei. Infolgedessen kommen Wissenschaftler bereits mit neuen Hypothesen auf uns zu, damit wir sie testen. Früher hätte jeder Schritt des Prozesses bis hin zum Ergebnis ein Jahr in Anspruch genommen. Jetzt dauert dies gerade einen einzigen Tag.“
Vor der Zeit von Windows Compute Cluster Server wären die von Microsoft Research verwendeten Methoden wegen der für die Analyse erforderlichen Zeit nicht sinnvoll gewesen. „Mit Windows Compute Cluster Server“, merkt Kadie an, „können wir 50 Aufträge mit jeweils 200.000 Arbeitsschritten in derselben Zeit ausführen, die früher ein Auftrag in Anspruch genommen hätte.“
Da die eScience-Gruppe jetzt riesige Datenverarbeitungsfunktionen an der Hand hat, können Tests in vielen Durchläufen mit simulierten Daten durchgeführt werden. Die Testläufe mit simulierten Daten sind entscheidend für die Feststellung, welche Ergebnisse bei wirklichen Daten interessant sind. Je mehr Simulationen durchgeführt werden, desto zuverlässiger sind die Ergebnisse.

Gelernte Lektionen
Microsoft Research hat offensichtlich von der Verwendung von Windows Compute Cluster Server profitiert, aber dies beruht auf Gegenseitigkeit. Entwickler in der HPC-Gruppe arbeiten gerade an einer zweiten Version von Windows Compute Cluster Server und gewinnen durch die Rückmeldungen aus der eScience-Gruppe immer neue Einsichten.
Vor allem hat die HPC-Gruppe durch Überwachung und Analyse des Verhaltens des Microsoft Research-Clusters viel über Ressourcenzuweisung erfahren, sodass bestimmt werden kann, wie sich die Ressourcen des Clusters auf mehrere Benutzer bestmöglich aufteilen lassen. Bei diesem Projekt zum Beispiel erstellt ein Benutzer in der Regel jeweils einen Auftrag mit durchschnittlich 50 Aufgaben. Der Benutzer sendet den Auftrag, und die Windows Compute Cluster-Auftragsverwaltung teilt genug Ressourcen zu, um alle 50 Aufgaben zu verwalten. Für das Bearbeiten der Aufgaben werden sofort alle verfügbaren Knoten im Cluster beansprucht. Dieses Szenario wäre in einer Einzelbenutzerumgebung unproblematisch, wird aber bei mehreren Benutzern zum Problem, wenn der Fortschritt von Projekten parallel verlaufen soll.
Wenn derzeit 10 der 50 Aufgaben des Auftrags abgeschlossen sind, werden nicht gleich 10 Server wieder freigegeben. Die Auftragsverwaltung wartet, bis alle 50 Aufgaben desselben Auftrags erledigt sind, bevor die Server für einen anderen Auftrag wieder freigegeben werden. HPC-Entwickler arbeiten jetzt an einer Möglichkeit, Ressourcen beim Abschluss jeder einzelnen Aufgabe und nicht erst beim Abschluss des Gesamtauftrags neu zuzuteilen.
Microsoft Research holte für die Lösung bestimmter Probleme Rat von der HPC-Gruppe ein, und zwar im Zusammenhang mit der Verwendungsweise von Windows Compute Cluster Server. Insbesondere sollte die Sicherheit so eingerichtet werden, dass Benutzeranmeldeinformationen automatisch vom Web-Front-End zum Rechencluster übertragen werden. Die Lösung bestand in der Verwendung von Microsoft® .NET Framework und der Erweiterung der ASP.NET-Formularauthentifizierung, damit die Webanwendung den Clusterknoten jedes Mal die vollständigen Benutzeranmeldeinformationen bereitstellen kann, wenn ein Benutzer einen Auftrag sendet.
Jetzt können sich die Mitglieder des eScience-Team bei Microsoft Research und ihre Kollegen rund um die Welt auf die wirklich wichtigen Aufgaben konzentrieren und die Datenverarbeitung und -verwaltung den Computern überlassen. „Dadurch können wir als Team schneller vorankommen,“ kommentiert Heckerman. „Wir erweitern die Grenzen dessen, was über HIV bekannt ist, und machen gute Fortschritte im Kampf gegen diese Krankheit.“

Kristin Firth und Mia Matusowsind Inhaberinnen von Blue Line Writing & Editing und haben das vergangene Jahrzehnt damit verbracht, strategische Inhalte für Unternehmensorganisationen im öffentlichen und privaten Sektor in drei Kontinenten zu erstellen.


 Windows PowerShell: Schreiben regul&#228;rer Ausdr&#252;cke
Windows PowerShell
Schreiben regulärer Ausdrücke
Don Jones

192.168.4.5. \\Server57\Share. johnd@contoso.com. Ohne Zweifel erkennen Sie, dass diese drei Elemente eine IP-Adresse, einen UNC-Pfad (Universal Naming Convention) und eine E-Mail-Adresse repräsentieren. Ihr Gehirn erkennt die entsprechenden Formate. Vier Gruppen von Ziffern, umgekehrte Schrägstriche, das Symbol @ und weitere Hinweise deuten darauf hin, für welche Datentypen diese Zeichenfolgen
stehen. Ohne großes Nachdenken ist Ihnen schnell klar, dass 192.168 für sich genommen keine gültige IP-Adresse darstellt, dass 7\\Server2\\Share kein gültiger UNC-Pfad ist und joe@contoso keine gültige E-Mail-Adresse repräsentiert.
Computer müssen leider ein bisschen härter arbeiten, um komplizierte Formate wie diese zu „verstehen“. An diesem Punkt kommen reguläre Ausdrücke ins Spiel. Ein regulärer Ausdruck ist eine in einer besonderen Sprache für reguläre Ausdrücke geschriebene Zeichenfolge, die einem Computer dabei hilft, Zeichenfolgen eines bestimmten Formats zu identifizieren, z. B. eine IP-Adresse, einen UNC-Pfad oder eine E-Mail-Adresse. Ein gut geschriebener regulärer Ausdruck ermöglicht es einem Windows PowerShellTM-Skript, Daten als gültig zu akzeptieren, oder Daten, die dem von Ihnen angegebenen Format nicht entsprechen, als ungültig zurückzuweisen.

Herstellen einer einfachen Übereinstimmung
Der Operator „–match“ der Windows PowerShell vergleicht eine Zeichenfolge mit einem regulären Ausdruck, auch regex genannt, und gibt dann „True“ oder „False“ zurück. Welcher Wert zurückgegeben wird, hängt davon ab, ob die Zeichenfolge dem regex entspricht. Ein sehr einfacher regex muss nicht einmal eine besondere Syntax enthalten, Literalzeichen sind ausreichend. Beispiel:
"Microsoft" –match "soft"
"Software" –match "soft"
"Computers" –match "soft"
Bei der Ausführung in Windows PowerShell geben die ersten beiden Ausdrücke „True“ zurück, während der dritte „False“ zurückgibt. In jedem folgt auf eine Zeichenfolge der Operator „–match“, dem wiederum ein regex folgt. Standardmäßig bewegt sich ein regex über einer Zeichenfolge, um eine Entsprechung zu finden. Die Zeichen „soft“ sind sowohl in Software als auch Microsoft enthalten, jedoch an verschiedenen Positionen. Bei einem regex wird standardmäßig die Groß-/Kleinschreibung nicht beachtet: „soft“ wird trotz des S in Großschreibung in „Software“ gefunden.
Falls erforderlich kann ein anderer Operator, nämlich „–cmatch“, für einen regex-Vergleich unter Beachtung der Groß-/Kleinschreibung herangezogen werden:
"Software" –cmatch "soft"
Dieser Ausdruck gibt „False“ zurück, da die Zeichenfolge „soft“ in einem Vergleich unter Beachtung der Groß-/Kleinschreibung nicht mit „Software“ übereinstimmt. Außerdem ist der Operator „–imatch“ verfügbar, mit dem die Beachtung der Groß-/Kleinschreibung explizit ausgeschlossen werden kann, obgleich dies dem Standardverhalten von „–match“ entspricht.

Platzhalter und Repeater
Ein regex kann einige Platzhalterzeichen enthalten. Ein Punkt entspricht beispielsweise einer Instanz eines beliebigen Zeichens. Ein Fragezeichen entspricht null oder einer Instanz eines beliebigen Zeichens. Hier einige Beispiele zur Illustration:
"Don" –match "D.n" (True)
"Dn" –match "D.n" (False)
"Don" –match "D?n" (True)
"Dn" –match "D?n" (True)
Im ersten Ausdruck steht der Punkt für genau ein Zeichen, deshalb wird „True“ zurückgegeben. Im zweiten Ausdruck findet der Punkt das eine Zeichen, das enthalten sein muss, nicht, also wird „False“ zurückgegeben. Das Fragezeichen, wie im dritten und vierten Ausdruck gezeigt, kann einem einzigen unbekannten Zeichen oder gar keinem Zeichen entsprechen. Im vierten Beispiel schließlich wird „True“ zurückgegeben, weil sowohl „D“ als auch „n“ ohne ein Zeichen dazwischen gefunden werden. Folglich kann das Fragezeichen als Zeichen betrachtet werden, das für ein optionales Zeichen steht. Die Rückgabe ist also nach wie vor „True“, selbst wenn an dieser Position kein Zeichen vorhanden ist.
Ein regex erkennt außerdem die Symbole * und + als Repeater. Diese müssen auf ein oder mehrere Zeichen folgen. Das Symbol * entspricht null oder mehr der angegebenen Zeichen, während das Symbol + einem oder mehreren der angegebenen Zeichen entspricht. Hier einige Beispiele:
"DoDon" –match "Do*n" (True)
"Dn" -match "Do*n" (True)
"DoDon" -match "Do+n" (True)
"Dn" -match "Do+n" (False)
Beachten Sie, dass sowohl * und + nicht nur dem „o“, sondern auch „Do“ entsprechen. Repeater sind nämlich so konstruiert, dass sie nicht nur einem Zeichen, sondern einer Reihe von Zeichen entsprechen.
Was geschieht nun, wenn der Punkt oder die Symbole *, ? oder + sich selbst entsprechen müssen? Sie stellen Ihnen einfach einen umgekehrten Schrägstrich voran. Der umgekehrte Schrägstrich ist das regex-Escapezeichen:
"D.n" -match "D\.n" (True)
Beachten Sie, dass sich dieses Zeichen vom Windows PowerShell-Escapezeichen (dem umgekehrten Apostroph) unterscheidet, jedoch dem Industriestandard für die regex-Syntax folgt.

Zeichenklassen
Eine Zeichenklasse ist eine umfassendere Form des Platzhalters, die für eine ganze Gruppe von Zeichen steht. Windows PowerShell ist in der Lage, relativ viele Zeichenklassen zu erkennen. Beispiel:
  • \w entspricht einem beliebigen Wortzeichen, das heißt Buchstaben und Zahlen.
  • \s entspricht einer beliebigen Leerstelle, z. B. Tabstopps, Leerzeichen usw.
  • \d entspricht einer beliebigen Ziffer.
Darüber hinaus gibt es negative Zeichenklassen: \W steht für ein beliebiges Nichtwortzeichen, \S für Nichtleerstellenzeichen und \D für alle Zeichen, die keine Ziffern sind. Diesen Klassen kann das Symbol * oder + folgen, zum Zeichen dafür, dass mehrere Übereinstimmungen akzeptabel sind. Hier einige Beispiele:
"Shell" -match "\w" (True)
"Shell" -match "\w*" (True)
Cmdlet des Monats
Das Write-Debug-Cmdlet eignet sich sehr gut für das Schreiben von Objekten (z. B. Textzeichenfolgen) in die Debug-Pipeline. Der Versuch, dieses Cmdlet in der Shell einzusetzen, kann allerdings ein wenig enttäuschend ausfallen, da der Eindruck entsteht, dass das Cmdlet nichts bewirkt.
Das liegt daran, dass die Debug-Pipeline standardmäßig deaktiviert ist: Für die $DebugPreference-Variable wurde „SilentlyContinue“ festgelegt. Wenn Sie den Wert in „Continue“ ändern, wird alles, was Sie mit dem Cmdlet „Write-Debug“ senden, auf der Konsole in Gelb angezeigt. Damit bietet sich eine perfekte Möglichkeit, Ihren Skripts Ablaufverfolgungscode hinzuzufügen, mit dem Sie die Ausführung eines komplexen Skripts verfolgen können. Die gelbe Farbe erleichtert es, zwischen der Verfolgung und der normalen Ausgabe des Skripts zu unterscheiden, und Sie können die Debugnachrichten jederzeit deaktivieren, ohne alle Write-Debug-Anweisungen entfernen zu müssen. Legen Sie einfach für die $DebugPreference-Variable wieder „SilentlyContinue“ fest. Der Debugtext wird dann unterdrückt.

Obwohl beide Ausdrücke „True“ zurückgeben, werden völlig verschiedene Entsprechungen gefunden. Glücklicherweise gibt es eine Möglichkeit zu überprüfen, wie der Operator „–match“ genau arbeitet: Bei jeder Übereinstimmung wird eine besondere Variable namens „$matches“ mit den Ergebnissen der Übereinstimmung aufgefüllt (also mit den Zeichen in der Zeichenfolge, die der Operator im Vergleich mit dem regex gefunden hat). Die $matches-Variable behält ihre Ergebnisse bei, bis eine weitere positive Übereinstimmung mithilfe des Operators „–match“ gefunden wurde. Abbildung 1 zeigt den Unterschied zwischen den beiden Ausdrücken, die soeben vorgestellt wurden. Wie Sie sehen können, entsprach \w dem „S“ in „Shell“, während das sich wiederholende \w* dem gesamten Wort entsprach.
Abbildung 1 Die Macht eines *
Abbildung 1 Die Macht eines *

Zeichengruppen, Zeichenbereiche und Größen
Ein regex kann auch Zeichengruppen oder Zeichenbereiche enthalten, die in eckige Klammern eingeschlossen sind. So bedeutet beispielsweise [aeiou], dass jedes der eingeschlossenen Zeichen – a, e, i, o oder u – als Übereinstimmung akzeptiert wird. [a-zA-Z] gibt an, dass jeder Buchstabe im Bereich von A bis Z akzeptiert wird (wenn Sie den Operator „–match“ verwenden, bei dem Groß-/Kleinschreibung keine Rolle spielt, wäre jedoch a-z oder A-Z ausreichend). Hier ist ein Beispiel:
"Jeff" -match "J[aeiou]ff" (True)
"Jeeeeeeeeeeff" -match "J[aeiou]ff" (False)
Mithilfe geschweifter Klammern können Sie auch ein Minimum und ein Maximum für die Anzahl der Zeichen angeben. {3} gibt an, dass genau drei der angegebenen Zeichen erforderlich sind, {3,} bedeutet, dass die Zahl der Zeichen mindestens drei betragen muss, und {3,4} gibt an, dass mindestens drei, jedoch höchstens vier Zeichen erwünscht sind. Dies ist eine ideale Möglichkeit zum Erstellen eines regex für IP-Adressen:
"192.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Für diesen regex sind vier Zifferngruppen mit jeweils einer bis drei Ziffern erforderlich, die alle durch einen Literalpunkt voneinander getrennt sind. Sehen Sie sich dieses Beispiel an:
"300.168.15.20" -match "\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}" (True)
Dies veranschaulicht die Einschränkungen eines regex. Die Formatierung dieser Zeichenfolge sieht zwar wie eine IP-Adresse aus, ist jedoch offensichtlich keine gültige IP-Adresse. Ein regex kann nicht feststellen, ob Daten tatsächlich gültig sind, sondern lediglich, ob die Daten das richtige Aussehen haben.

Schränken Sie die Bewegung ein
Die Problembehandlung bei einem regex kann schwierig sein. Es folgt ein regex zur Prüfung auf einen UNC-Pfad im Format \\Server2\Share:
"\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Der regex selbst ist in diesem Fall schwer zu lesen, da jeder literale umgekehrte Schrägstrich, der überprüft werden soll, mit einem zweiten umgekehrten Schrägstrich als Escapezeichen versehen werden muss. Dies scheint zwar gut zu funktionieren, der Schein trügt jedoch:
"57\\Server2\Share" -match "\\\\\w+\\\w+" (True)
Dieses zweite Beispiel stellt eindeutig keinen gültigen UNC-Pfad dar, wurde jedoch vom regex als gültig anerkannt. Warum? Wie bereits erwähnt, ist ein regex standardmäßig nicht verankert. Dieser regex sucht lediglich nach zwei umgekehrten Schrägstrichen, einem oder mehreren Buchstaben und einer oder mehreren Zahlen, einem weiteren umgekehrten Schrägstrich und weiteren Buchstaben und Zahlen. Dieses Muster ist in der Zeichenfolge vorhanden, jedoch zusammen mit den zusätzlichen Ziffern am Beginn, die dafür sorgen, dass der UNC-Pfad ungültig ist. Der Trick besteht darin, den regex anzuweisen, am Anfang der Zeichenfolge nach Übereinstimmungen zu suchen, ohne sich zu bewegen. Dies kann auf folgende Weise erreicht werden:
"57\\Server2\Share" -match "^\\\\\w+\\\w+" (False)
Das Zeichen ^ zeigt an, dass die Zeichenfolge an dieser Position beginnt. Mit dieser Ergänzung wird der UNC-Pfad als ungültig erkannt, da der regex erfordert, dass die ersten beiden Zeichen umgekehrte Schrägstriche sind – dies ist nicht der Fall.
In ähnlicher Weise kann das Symbol $ dazu verwendet werden, das Ende einer Zeichenfolge anzuzeigen. Im Falle eines UNC-Pfads wäre dies nicht besonders nützlich, da ein UNC-Pfad weitere Pfadsegmente enthalten kann (z. B. \\Server2\Share\Folder\File). Es sind jedoch viele Fälle vorstellbar, in denen es von Vorteil wäre, das Ende einer Zeichenfolge anzugeben.

Hilfe zu regulären Ausdrücken
In Windows PowerShell bietet das Hilfethema „about_regular_expressions“ Unterstützung bei der grundlegenden Syntax für die regex-Sprache. In Onlineressourcen finden Sie jedoch noch weitere Informationen. Eine sehr zu empfehlende Website, www.RegExLib.com, bietet beispielsweise eine kostenlose Bibliothek regulärer Ausdrücke, die für verschiedene Zwecke geschrieben und von der Allgemeinheit zur Verfügung gestellt wurden. Sie können nach Schlüsselwörtern wie „e-mail“ oder „UNC“ suchen, um schnell einen regex zu finden, der Ihren Anforderungen genügt oder zumindest einen guten Ausgangspunkt bietet. Wenn es Ihnen gelingt, einen guten regex zu erstellen, können Sie diesen in der Bibliothek verfügbar machen, damit auch andere ihn verwenden können.
Ebenfalls zu empfehlen ist RegexBuddy (www.RegexBuddy.com). Dies ist ein preiswertes Tool, das einen grafischen regex-Editor bereitstellt. RegexBuddy vereinfacht das Zusammenstellen eines komplexen regex. Außerdem erleichtert dieses Tool das Testen eines regex, um sicherzustellen, dass gültige Zeichenfolgen ordnungsgemäß akzeptiert und ungültige zurückgewiesen werden. Etliche andere Softwareentwickler haben kostenlose bzw. kommerziell vertriebene regex-Editoren und Tester sowie Sharewareprodukte herausgebracht, die für Benutzer sicher nützlich sind.

Verwendung regulärer Ausdrücke
Sie mögen sich fragen, in welcher konkreten Situation Sie einen regex verwenden können. Angenommen Sie lesen die Informationen einer CSV-Datei und verwenden diese Informationen zum Erstellen neuer Benutzer in Active Directory®. Wenn die CSV-Datei von einer anderen Person generiert wird, möchten Sie sicher überprüfen, ob die Daten das richtige Aussehen haben. Ein regex eignet sich hervorragend für diese Aufgabe. Ein einfacher regex wie \w+ kann bestätigen, dass die Vor- und Nachnamen keine Sonderzeichen oder Symbole enthalten. Mit einem etwas komplexeren regex lässt sich bestätigen, dass die E-Mail-Adressen Ihrem Unternehmensstandard entsprechen. Sie könnten folgendes Beispiel verwenden:
"^[a-z]+\.[a-z]+@contoso.com$"
Dieser regex erfordert eine E-Mail-Adresse im Format don.jones@contoso.com, wobei der Vor- und der Nachname nur Buchstaben enthalten dürfen und durch einen Punkt voneinander getrennt sein müssen. Für E-Mail-Adressen einen regex zu schreiben, ist übrigens eine schwierige Aufgabe. Wenn Sie den Bereich auf einen bestimmten Unternehmensstandard einengen, erleichtern Sie sich die Aufgabe.
Denken Sie daran, die Verankerungen am Beginn und Ende zu verwenden (^ und $), die sicherstellen, dass auf contoso.com nichts folgt und nichts den Zeichen vorausgeht, aus denen der Vorname des Benutzers besteht.
Die Verwendung dieses regex in Windows PowerShell ist eine relativ leichte Aufgabe. Angenommen die Variable „$email“ enthält die E-Mail-Adresse, die Sie aus der CSV-Datei lesen. Dann können Sie deren Gültigkeit mit einer Funktion ähnlich der folgenden überprüfen:
$regex = "^[a-z]+\.[a-z]+@contoso.com$"
If ($email –notmatch $regex) {
  Write-Error "Invalid e-mail address $email"
}
In diesem Beispiel haben Sie außerdem einen neuen Operator kennengelernt. „-notmatch“ gibt „True“ zurück, wenn die Zeichenfolge dem angegebenen regex nicht entspricht. (Für Vergleiche, in denen die Groß-/Kleinschreibung beachtet werden soll, gibt es den Operator „–cnotmatch“.)
Über reguläre Ausdrücke gäbe es noch viel zu sagen, das an dieser Stelle nicht behandelt werden kann: zusätzliche Zeichenklassen, komplexere Operationen und weitere Operatoren. Außerdem gibt es den Objekttyp [regex], der von Windows PowerShell unterstützt wird. Dieser kurze Überblick über die regex-Syntax sollte jedoch als Einstieg genügen. Wenn Sie Hilfe bei einem ganz besonders kniffligen regex benötigen, stehe ich Ihnen unter www.ScriptingAnswers.com jederzeit zur Verfügung.

Don Jones schreibt redaktionelle Beiträge für das TechNet Magazin und ist Mitautor von Windows PowerShell: TFM (SAPIEN Press). Er hält Schulungen zu Windows PowerShell ab (www.ScriptingTraining.com). Sie erreichen ihn über die Website ScriptingAnswers.com.


 Hey, Scripting Guy!: Desktopverwaltung aus dem Jenseits
Hey, Scripting Guy!
Desktopverwaltung aus dem Jenseits
Die Scripting Guys von Microsoft
Laden Sie den Code für diesen Artikel herunter: HeyScriptingGuy2007_11.exe (151KB)

Angesichts der überwältigenden Nachfrage haben wir uns für diesen Monat etwas Anderes überlegt: Statt gleich mit der Skriptprogrammierung für die Systemadministration anzufangen, werden wir mit einer Gespenstergeschichte beginnen!
Hinweis: Wenn wir, prinzipiell betrachtet, diesen Monat wirklich auf eine kleine Änderung aus wären, würden wir damit anfangen, zur Abwechslung einmal tatsächlich die Skriptprogrammierung für die Systemadministration zu behandeln. Spielen Sie einfach mit. Danke!
Vor vielen Jahren ist die Ur-Ur-Urgroßmutter eines der Scripting Guys gestorben. Kurz nachdem die Großmutter in ihrem einfachen Holzsarg zur letzten Ruhe gebettet wurde, stellten sich beim Großvater schreckliche Albträume ein, in denen seine geliebte Ehefrau verzweifelt versuchte, sich aus dem Grab befreien. Nach wiederkehrenden Angstträumen und nach wiederholten dringenden Bitten konnte der Großvater schließlich die lokalen Zuständigen davon überzeugen, ihren Körper auszugraben. Als der Sarg geöffnet wurde, sah jeder entsetzt, dass die Nägel der Großmutter völlig verbogen und die Innenseiten des Sargs mit Kratzern überdeckt waren!
Diese Geschichte ist wahrscheinlich nicht ganz wahrheitsgetreu. Je länger wir darüber nachdenken, umso mehr sehen wir ein, dass sie keinen Fünkchen Wahrheit enthält. Trotzdem lässt sich aus dieser Geschichte eine wichtige Lehre ziehen. Wir haben zwar keine Ahnung, was das sein könnte, aber sie ist irgendwo hier begraben.
Halt, jetzt erinnern wir uns wieder! Särge wurden ursprünglich entworfen, um Verstorbene vor den Naturelementen zu schützen und um zu verhindern, dass der Körper verwest. Leider hatten Särge auch eine unbeabsichtigte Folge: Sie ließen theoretisch zu, dass eine Person lebendig begraben werden konnte und nicht mehr aus dem Grab herauskam. Wie die Geschichte der Ur-Ur-Urgroßmutter eines der Scripting Guys verdeutlicht, können sogar die besten Pläne katastrophal enden – und damit, dass Personen lebendig begraben werden! (Cue the ominous music one more time.)
Hinweis: Es sei denn, Sie entscheiden sich für das optimierte Sargmodell, das von Franz Vester in den 1860er Jahren erfunden wurde. Dieser Sarg enthielt einen Strick, der mit einer Klingel über der Erde verbunden war. Im Fall einer voreiligen Beerdigung konnte der oder die „Verstorbene“ einfach klingeln und um Hilfe rufen. Der verbesserte Sarg enthielt zudem eine Faltleiter, auch wenn uns nicht ganz klar ist, wie sie einem helfen soll, sich aus einem Sarg zu befreien, der fast zwei Meter tief in der Erde begraben ist. Wenn jemand auf dem Dach einer Garage begraben wird, sicher, dann wäre eine Faltleiter wohl nützlich. Otherwise ....
Dasselbe (nämlich dass die besten Pläne katastrophal enden) gilt auch in gewisser Weise für Internetfirewalls. (Well, sort of.) Firewalls wurden ursprünglich entworfen, um die Bösewichte nicht hereinzulassen: Sie blockieren eingehenden Netzwerkverkehr. Das hilft, um die Hacker und Angreifer von Ihren Computern fern zu halten. Das ist zwar großartig, kann jedoch – wie beim Risiko mit dem Lebendigbegrabenwerden – auch eine unbeabsichtigte Folge haben: Firewalls können auch den Guten den Zugang versperren. Dies ist besonders bei der Windows®-Verwaltungsinstrumentation (Windows® Management Instrumentation, WMI) der Fall, die sich auf DCOM verlässt, um administrative Aufgaben auf Remotecomputern durchzuführen. Firewalls neigen dazu, jeglichen eingehenden DCOM-Datenverkehr zu blockieren, was die programmgesteuerte Verwaltung von Computern über das Internet sehr erschwert (wenn nicht gar völlig unmöglich macht). Genau genommen ist dies ohne die Öffnung zusätzlicher Ports auf der Firewall und der damit einhergehenden Anfälligkeit gegen Hacker völlig unmöglich. Es sei denn natürlich, Sie entscheiden sich für WinRM: Windows Remote Management.

Was ist die Windows Remote Management?
Laut dem WinRM SDK (msdn2.microsoft.com/aa384426) ist Windows Remote Management „die Microsoft-Implementierung von WS-Management Protocol, dem SOAP-basierten, firewallfreundlichen Standardprotokoll, das die Zusammenarbeit von Hardware und Betriebssystemen verschiedener Hersteller ermöglicht“. Beeindruckend, nicht wahr? Die Einzelheiten des WS-Management Protocol werden im Artikel für diesen Monat nicht behandelt. Deshalb empfehlen wir, diese im WinRM SDK nachzulesen. Vorläufig ist es wichtig festzuhalten, dass WinRM unter Windows Server® 2003 R2, Windows Vista® und Windows Server 2008 verfügbar ist und Ihnen das Verwalten von Computern über das Internet ermöglicht. WinRM erzielt dies mithilfe von Port 80, einem Standardinternetdienstport, den die meisten Firewalls geöffnet lassen. (Der von WinRM und der Standardtransportmethode, HTTP, verwendete Port kann jedoch nach Bedarf geändert werden.)
Im vorliegenden Artikel wird des Weiteren nicht besprochen, wie WinRM installiert und konfiguriert wird. Zu diesem Thema sind bereits zahlreiche Informationen verfügbar (msdn2.microsoft.com/aa384372). Ein Punkt soll hier jedoch hervorgehoben werden: Wenn Sie mithilfe von WinRM Informationen von einem Remotecomputer abrufen möchten (was natürlich der Hauptgrund für die Verwendung von WinRM ist), dann müssen Sie sowohl auf Ihrem lokalen Computer als auch auf dem Remotecomputer WinRM ausführen.
Was bedeutet das? Es bedeutet Folgendes: Falls Sie Ihre Clientcomputer nicht auf Windows Vista oder Ihre Server nicht auf Windows Server 2003 R2 oder Windows Server 2008 aktualisiert haben, werden Sie zumindest vorläufig nicht viel Nutzen aus WinRM ziehen können. Das kann sich aber morgen schon ändern. (Falls Ihre Firewall es ermöglicht, können Sie zur Verwaltung von Remotecomputern natürlich immer WMI und DCOM verwenden.)

Zurückgeben aller Eigenschaften und Instanzen einer Klasse
Doch wer achtet schon auf Vorsichtsmaßnahmen und Haftungsausschlüsse? Im Folgenden soll statt dieses unverständlichen Kauderwelschs untersucht werden, ob ein Skript erstellt werden kann, das sich WinRM zunutze macht. Zufällig lag uns ein einfaches kleines Skript vor, das mithilfe des HTTP-Protokolls und des Ports 80 eine Verbindung zu einem Computer namens „atl-fs-01.fabrikam.com“ herstellt und dann die Informationen über die auf diesem Computer installierten Dienste zurückgibt. Das Skript ist in Abbildung 1 dargestellt.
Figure 1 Silverlight-Projektkomponenten (Close Figure 1)

Datei | Beschreibung
CreateSilverlight.js | Ein JScript-Skript (in der ersten Version unterstützt Silverlight nur JScript-Skripting), mit dem die ursprünglichen Silverlight-Starteinstellungen einschließlich der zum Konfigurieren der Benutzeroberfläche und von Grafikobjekten verwendeten XAML-Datei angegeben werden.
SampleProject.js | Eine leere Datei, in die JScript-Funktionen eingefügt werden können.
Silverlight.js | Diese Datei dient zum Initialisieren des Silverlight-Steuerelements.
SampleProject.html | Hier geht es richtig los. SampleProject.html ist einfach eine HTML-Datei, die Code zum Einlesen der drei .js-Dateien umfasst. Sie enthält darüber hinaus Code zum Instanziieren des Silverlight-Steuerelements.
SampleProject.xaml | Wozu dient diese Datei? Um das herauszufinden, müssen Sie zum Haupttext dieses Artikels zurückkehren.
Figure 1 Auflisten von Diensten auf einem Remotecomputer (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service"

Set objResponse = objSession.Enumerate(strResource)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Wie Sie sehen können, wird zuerst der DNS-Name des Computers (atl-fs-01.fabrikam.com) einer Variablen namens „strComputer“ zugewiesen. Alternativ dazu könnte die Verbindung mit der IP-Adresse des Computers (oder sogar seiner IPv6-Adresse) hergestellt werden. Beispiel:
strComputer = "192.168.1.1"
Nachdem strComputer ein Wert zugewiesen wurde, wird eine Instanz des WSMan.Automation-Objekts erstellt. Anschließend wird die CreateSession-Methode aufgerufen, um eine Verbindung zum Remotecomputer herzustellen, in diesem Fall mit dem HTTP (wie bereits angekündigt):
Set objSession = objWRM.CreateSession _
    ("http://" & strComputer)
Wie schon angemerkt, wollen wir Informationen über die Dienste zurückgeben, die auf dem Remotecomputer installiert sind. Außerdem und zumindest für dieses erste Beispiel möchten wir Informationen über alle Eigenschaften aller Dienste erhalten. Was bedeutet das alles? Es bedeutet, dass wir eine URI-Ressource angeben müssen, die uns an die Win32_Service-Klasse auf dem Remotecomputer bindet:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2" & _
  "/Win32_Service"
Zugegebenermaßen ist dies nicht der ansehnlichste URI. (Wo wir schon bei diesem Thema sind: Wir können uns nicht erinnern, jemals einen ansehnlichen URI gesehen zu haben.) Erfreulicherweise handelt es sich beim Großteil des URIs um Textbausteine. Aufmerksamkeit erfordert nur der WMI-Pfad am Ende:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service
Das sollte ziemlich einfach sein. Was ist, wenn Sie eine Verbindung zur Klasse „root/cimv2/Win32_Process“ herstellen möchten? Dann muss nur der URI-Pfad entsprechend geändert werden:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Process
Sie sind an der Klasse „root/default/SystemRestore“ interessiert? Auch hier gilt: Ändern Sie einfach nur die URI-Klasse, und denken Sie daran, den Standardnamespace (statt des cimv2-Namespace) anzugeben:
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/default/SystemRestore
Und so weiter ... Es ist zwar schade, dass der Teil „http://schemas.microsoft.com/wbem/wsman/1/wmi“ des URI ebenfalls enthalten sein muss, aber ...
Jetzt können einige Daten abgerufen werden. Dazu wird einfach die Enumerate-Methode aufgerufen, wobei die Variable „strResource“ als einziger Methodenparameter übergeben wird:
Set objResponse = _
  objSession.Enumerate(strResource)
Wird diese Codezeile tatsächlich „objResponse“ mit Informationen über die Dienste, die auf dem Computer „atl-fs-01“ installiert werden, auffüllen? Gewiss. Im Unterschied zu WMI-Standardskripts wird jedoch keine Reihe von Objekten, jedes mit seinen eigenen Eigenschaften und Eigenschaftsmethoden, zurückgegeben. Stattdessen wird ein großes, althergebrachtes XML-Blob zurückgegeben, das ungefähr so aussieht wie in Abbildung 2.
Figure 2 Hübsche Farben (Close Figure 2)
<Canvas
 xmlns="http://schemas.microsoft.com/client/2007"
 xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
 Width="800"
 Height="300">

 <Canvas.Background>
 <LinearGradientBrush>
 <GradientStop Color="Blue" Offset="0.0" />
 <GradientStop Color="Black" Offset="1.0" />
 </LinearGradientBrush>
 </Canvas.Background>

</Canvas>
Figure 2 Großes, althergebrachtes XML-Blob (Close Figure 2)
<p:Win32_Service xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:p="
http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/Win32_Service" xmlns:ci
m="http://schemas.dmtf.org/wbem/wscim/1/common" xsi:type="p:Win32_Service_Type"
xml:lang="en-US"><p:AcceptPause>false</p:AcceptPause><p:AcceptStop>false</p:Acce
ptStop><p:Caption>Windows Media Center Service Launcher</p:Caption><p:CheckPoint
>0</p:CheckPoint><p:CreationClassName>Win32_Service</p:CreationClassName><p:Desc
ription>Starts Windows Media Center Scheduler and Windows Media Center Receiver
services at startup if TV is enabled within Windows Media Center.</p:Description
><p:DesktopInteract>false</p:DesktopInteract><p:DisplayName>Windows Media Center
Wenn Sie ein XML-Genie sind, ist das kein große Sache. Jeder, der mit XML vertraut ist, sollte diese Informationen analysieren und ohne große Schwierigkeiten ausgeben können (auch wenn sich diese Informationen laut dem WinRM SDK nicht in einem „von Menschen lesbaren Format“ befinden). Aber was ist, wenn Sie kein XML-Genie sind? Im diesem Fall haben Sie zwei Möglichkeiten. Erstens können Sie bis zum nächsten Monat warten, wo wir ein paar Tricks für die Arbeit mit dem XML von WinRM vorstellen. Zweitens können Sie so vorgehen wie wir in unserem Beispielskript: Setzen Sie „XSL transform“ ein, das zusammen mit WinRM installiert wird.

Was ist das?
Ein „XSL transform“ ist nichts anderes als eine Vorlage, die beschreibt, wie eine XML-Datei angezeigt werden soll. Eine vollständige und sogar eine oberflächliche Erörterung von XSL-Dateien geht über den Rahmen dessen hinaus, was wir im Artikel für diesen Monat anbieten können. Deshalb werden wir nicht versuchen, die Funktionsweise von WsmTxt.xsl (der Name des integrierten „transform“) zu erklären. Stattdessen zeigen wir einfach, wie Sie „transform“ in Ihrem Skript verwenden.
Wenn Sie die Enumerate-Methode aufrufen, sendet WinRM XML-Daten zurück. Am leichtesten lässt sich mit diesen Daten arbeiten, indem eine Do Until-Schleife eingerichtet wird, die so lange fortgesetzt wird, bis Sie das Ende des Datenstroms erreichen. Das ist, was wir hier machen:
Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop
Wie Sie sehen können, rufen wir innerhalb unserer Schleife eine Unterroutine namens „DisplayOutput“ auf. Wenn wir diese Unterroutine aufrufen, übergeben wir den Wert der ReadItem-Methode des Datenstroms als Unterroutinenparameter. (Wie diese ganze Vorgehensweise impliziert, wird der XML-Datenstrom in separaten Stücken statt eines großen Datenpakets zurückgeschickt. Unser Skript wiederum liest die XML-Daten immer nur Stück für Stück bzw. Element für Element.)
Mittlerweile sieht die DisplayOutput-Unterroutine folgendermaßen aus:
Sub DisplayOutput(strWinRMXml)
  Set xmlFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  Set xslFile = _
    CreateObject("MSXml2.DOMDocument.3.0")
  xmlFile.LoadXml(strWinRMXml)
  xslFile.Load("WsmTxt.xsl")
  Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Kurz gesagt, werden als Erstes zwei Instanzen des MSXml2.DOMDocument.3.0-Objekts erstellt. Der XML-Datenstrom (strWinRMXML) wird in ein Objekt geladen. Dann wird die XSL-Datei (WsmTxt.xsl) in ein anderes Objekt geladen. An diesem Punkt wird die TransformNode-Methode aufgerufen, um die Informationen in der XSL-Datei zu verwenden, um die vom XML-Datenstrom erfassten Daten zu formatieren und anzuzeigen.
Stimmt, das ist etwas verwirrend. Zumindest ist die Ausgabe, wenn auch nicht perfekt, so doch ein bisschen leichter zu lesen (siehe Abbildung 3).
Figure 3 Text malen (Close Figure 3)
<TextBlock
 Name="Test"
 FontSize="40"
 FontFamily="Georgia"
 FontWeight="Bold"
 Canvas.Top="20"
 Canvas.Left="20"
 Text="The TechNet Script Center">

 <TextBlock.Foreground>
 <SolidColorBrush Name="test_brush" Color="red"/>
 </TextBlock.Foreground>

</TextBlock>
Figure 3 Eine ordentlichere Version des XML (Close Figure 3)
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
    Description = This service is responsible for loading and unloading user profiles. If this service is stopped or disabled, users will no longer be able to successfully logon or logoff, applications may have problems getting to users' data, and components registered to receive profile event notifications will not receive them.
Wie schon erwähnt, ist dies zwar gut, doch es ist nicht unbedingt hervorragend. Ein Grund mehr, den Artikel des nächsten Monats zu lesen, wo wir Ihnen ein paar Möglichkeiten zeigen werden, die XML-Ausgabe selbst zu bearbeiten.

Zurückgeben ausgewählter Instanzen und Eigenschaften einer Klasse
Natürlich ist das alles wunderbar, bis auf eine Ausnahme: Es repräsentiert möglicherweise nicht vollständig die Art und Weise, wie Sie in der Regel arbeiten. Mitunter wird es vorkommen, dass Sie alle Eigenschaften aller Instanzen einer Klasse zurückgeben möchten. Doch es wird auch Zeiten geben (und vielleicht gar nicht so selten), in denen Sie nur ausgewählte Eigenschaften oder Instanzen einer Klasse zurückgeben möchten. Sie möchten zum Beispiel nur Informationen über Dienste zurückgeben, die gerade ausgeführt werden – etwas, was Sie in einem regelmäßigen WMI-Skript mithilfe eines Codes wie dem folgenden durchführen:
Set colItems = objWMIService.ExecQuery _
  ("Select * From Win32_Service " & _
   "Where State = 'Running'")
That's nice. Doch wie ändern Sie die Ressourcenzeichenfolge, um sie entsprechend anzupassen?
Um ganz ehrlich zu sein, werden Sie Ihre Ressourcenzeichenfolge nicht so ändern, dass sie ein Äquivalent zur ExecQuery-Anweisung darstellt. Sie müssen die Ressourcenzeichenfolge mit Sicherheit ändern, doch Sie müssen andere Dinge ebenfalls ändern.
Betrachten Sie dazu die Abbildung 4. Es ist ein WinRM-Skript, das Informationen über die Dienste zurückgibt, die auf einem Computer ausgeführt werden (im Gegensatz Diensten, die auf dem Computer installiert sind).
Figure 4 TextBlock-Tricks (Close Figure 4)
<TextBlock.Triggers>
 <EventTrigger RoutedEvent=
     "TextBlock.Loaded">
 <BeginStoryboard>
 <Storyboard>
 <DoubleAnimation
 Storyboard.TargetName="Test"
 Storyboard.TargetProperty="Opacity"
 From="0.0" To="1.0"
 Duration="0:0:5" />
 </Storyboard>
 </BeginStoryboard>
 </EventTrigger>
</TextBlock.Triggers>
Figure 4 Suchen ausgeführter Dienste (Close Figure 4)
strComputer = "atl-fs-01.fabrikam.com"

Set objWRM = CreateObject("WSMan.Automation")
Set objSession = objWRM.CreateSession("http://" & strComputer)

strResource = "http://schemas.microsoft.com/wbem/wsman/1/wmi/root/cimv2/*"
strFilter = "Select * From Win32_Service Where State = 'Running'"
strDialect = "http://schemas.microsoft.com/wbem/wsman/1/WQL"

Set objResponse = objSession.Enumerate(strResource, strFilter, strDialect)

Do Until objResponse.AtEndOfStream
    DisplayOutput(objResponse.ReadItem)
Loop

Sub DisplayOutput(strWinRMXml)
    Set xmlFile = CreateObject("MSXml2.DOMDocument.3.0")
    Set xslFile = CreateObject("MSXml2.DOMDocument.3.0")
    xmlFile.LoadXml(strWinRMXml)
    xslFile.Load("WsmTxt.xsl")
    Wscript.Echo xmlFile.TransformNode(xslFile)
End Sub
Auf den ersten Blick mag alles mit dem ersten WinRM-Skript, das oben angeführt wurde, fast identisch erscheinen, doch es gibt einige sehr wichtige Unterschiede. Betrachten Sie zum einen den der Ressourcenzeichenfolge zugewiesenen Wert:
strResource = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/wmi/root/cimv2/*"
Beachten Sie, dass beim Erstellen einer gefilterten Abfrage der eigentliche Name der zu verwendenden Klasse (Win32_Service) nicht angegeben wird. Stattdessen wird einfach eine Verbindung zum Namespace (root/cimv2), in dem sich diese Klasse befindet, hergestellt. Vergessen Sie dabei das Sternchen (*) am Ende nicht. Wenn Sie es nicht verwenden, gibt Ihnen das Skript die Meldung „... the class name must be '*' (star)“ zurück. Das heißt, dass Sie den Klassennamen als „*“ angeben müssen.
Außerdem müssen ein Filter und ein Dialekt definieren werden:
strFilter = _
  "Select * From Win32_Service " & _
  "Where State = 'Running'"
strDialect = _
  "http://schemas.microsoft.com" & _
  "/wbem/wsman/1/WQL"
Der Filter dürfte kein Problem darstellen. Dort wird die WQL-Abfrage gestellt (Windows Management Instrumentation Query Language, WMI-Abfragesprache): "Select * From Win32_Service Where State = 'Running'". Der Dialekt ist die Abfragesprache, die beim Erstellen des Filters verwendet wird. Im Augenblick ist nur eine Abfragesprache zulässig: WQL. Dennoch muss der Dialekt angegeben werden, sonst schlägt das Skript fehl und gibt an, dass der Filterdialekt nicht unterstützt ist.
Hinweis: Interessanterweise legt die Fehlermeldung nahe, den Dialekt zu entfernen, wenn Sie die Enumerate-Methode aufrufen. Das ist eine Empfehlung, der Sie nicht folgen sollten. Bei einer gefilterten Abfrage muss der Dialekt unbedingt angegeben werden, und zwar als WQL. Period.
Die einzige andere Änderung, die vorgenommen werden muss, fällt beim Aufrufen der Enumerate-Methode an. An diesem Punkt müssen die Variablen übergeben werden, die den Filter (strFilter) und den Dialekt (strDialect) darstellen, sowie die Variable, die die Ressource (strResource) darstellt:
Set objResponse = _
  objSession.Enumerate _
  (strResource, strFilter, strDialect)
Probieren Sie es aus.
Können denn nur ausgewählte Eigenschaften einer Klasse zurückgegeben werden? Angenommen, Sie möchten nur Name und DisplayName für alle Dienste zurückgeben, die auf einem Computer ausgeführt werden. Was dann?
In solch einem Fall können Sie versuchen, das XML zu manipulieren, sodass nur Name und DisplayName angezeigt werden. Das ist möglich, aber auch etwas knifflig. Eine leichtere Möglichkeit wäre, beim Zuweisen des Filters nur diese Eigenschaften anzugeben:
strFilter = _
  "Select Name, DisplayName " & _
  "From Win32_Service " & _
  "Where State = 'Running'"
Dann werden nur Name und DisplayName der jeweiligen Dienste angegeben, etwa so:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Zugegeben, die Formatierung ist etwas seltsam. (Was soll der ganze XmlFragment-Kram?) Ein weiterer Grund, nächsten Monat hier wieder vorbeizuschauen.

Geduld
Mit etwas Glück müsste dies jetzt für die ersten Schritte in der wilden und wunderbaren WinRM-Welt ausreichen. Selbstverständlich können wir keinen Artikel zu WinRM abschließen, ohne die früher so genannten Leichenhäuser zu erwähnen, die einst weit verbreitet waren in Deutschland. In Städten mit Leichenhäusern wurden die Leichen nicht sofort begraben. Stattdessen wurden sie in warmen Zimmern aufbewahrt und mit einer Reihe von Stricken und Drähten an ihren Fingern und Zehen versehen. Dahinter stand natürlich der Gedanke, dass die geringste Bewegung einen Alarm auslösen und Hilfe herbeirufen würde, da damals die Furcht, lebendig begraben zu werden, ziemlich weit verbreitet war. Die Körper blieben so lange in diesen provisorischen Leichenhallen, bis kein Zweifel mehr daran bestand, dass es für diese Menschen tatsächlich keine Hoffnung mehr gab.
Das hört sich ganz so wie im Scripting Guys-Team an. In jenen Leichenhäusern ist gewiss niemand jemals wieder zum Leben erwacht – die dem Scripting Guys-Team zugeteilten Menschen hingegen ...

Der Scripting Perplexer von Dr. Scripto
Im Juni 2007 haben die Scripting Guys die Tech•Ed-Konferenz in Orlando, Florida, besucht. Einfach nur an der Konferenz teilzunehmen, reichte uns nicht, also beschlossen wir, etwas Spaß zu haben. Nicht nur das, wir dachten uns, dass alle anderen auch etwas Spaß vertragen könnten. Also haben wir uns das Fun Book von Dr. Scripto einfallen lassen, ein Heft voller Rätsel zur Skripterstellung und mit diversen anderen Informationen. Wir taten uns mit dem TechNet Magazin zusammen – das heißt, wir überredeten sie, uns eine winzige Ecke ihres Stands in der Ausstellungshalle zu überlassen – und verteilten die Spaßbücher an alle, die vorbeiliefen.
Wie sich herausstellte, kam unser Fun Book gut an. Die Leute vom TechNet Magazin, nett und opportunistisch wie sie sind, sahen, wie sie sich erneut den Erfolg der Scripting Guys zunutze machen konnten (die Scripting Guys können anscheinend nie von ihrem eigenen Erfolg profitieren), und baten uns, einige Rätsel für sie zu entwerfen. Als Jean Ross, eine der Scripting Guys, sich für einen kleinen Moment abwendete, sagte Scripting Guy Greg Stemp: „Klar, machen wir!“ Hier ist das Ergebnis: Der Scripting Perplexer von Dr. Scripto. Viel Spaß.

Drop-In Scripting
In diesem Rätsel ergeben alle Buchstaben im oberen Teil bei ihrer Entwirrung ein Skript (in VBScript). Keine Sorge, Sie müssen nicht alles entschlüsseln, sondern immer nur eine Spalte. Die Buchstaben in jeder Spalte des oberen Abschnitts füllen die Leerstellen in der gleichen Spalte des unteren Abschnitts. Hier ist ein Beispiel:
In Spalte 1 befinden sich die Buchstaben S, C und T. Diese drei Buchstaben gehören in einer unbekannten Reihenfolge in die Zeile darunter. Wenn aber alle Buchstaben in der richtigen Reihenfolge eingetragen werden, ergibt die untere Zeile, von links nach rechts, etwas Logisches. Hier ist die Lösung:
Die Buchstaben S, C und T in Spalte 1 werden darunter in der Reihenfolge T, S und C eintragen. Sie sind also jeweils die ersten Buchstaben der Wörter in „The Script Center“. Das eigentliche Rätsel ist etwas schwieriger, weil es länger ist und weil das Endergebnis ein vollständiges Skript darstellt.
Tipp: Das endgültige Skript beginnt mit einem vollen Pfad zu einer Datei, wird dann geparst und zeigt nur den Dateinamen an.
Viel Glück!

Der Scripting Perplexer von Dr. Scripto
Antwort: Drop-In Scripting, November 2007
In diesem Rätsel müssen Sie die Buchstaben innerhalb einer Spalte in die richtigen Felder darunter eintragen, damit die unteren Zeilen ein Skript ergeben. Hier ist das eigenständige Skript:
name = "C:\Scripts\Test.txt"
arr = Split(name, "\")
index = Ubound(arr)
Wscript.Echo "Filename: " _
& arr(index)
So sieht es im Rätsel aus:

Die Scripting Guys von Microsoft arbeiten für Microsoft (oder sind zumindest dort angestellt). Wenn sie nicht gerade ihrem Hobby, dem Baseball (oder verschiedenen anderen Aktivitäten) nachgehen, betreiben sie das TechNet-Skriptcenter. Besuchen Sie es unter www.scriptingguys.com.


 Sicherheit auf dem Pr&#252;fstand: Sicherer Zugriff an jedem Ort
Sicherheit auf dem Prüfstand
Sicherer Zugriff an jedem Ort
John Morello

Der Technologietrend in Richtung „verbundenes und mobiles Personal“ ist heute nicht mehr zu übersehen. In vielen Organisationen agieren immer mehr Mitarbeiter und Mitarbeiterinnen von weit entfernten Büros aus, betreiben Telearbeit oder sind häufig unterwegs, um Kunden zu besuchen. Durch einen problemlosen und vom Aufenthaltsort unabhängigen Zugriff auf Anwendungen und Daten kann die Produktivität deutlich
gesteigert werden. Bis vor kurzem war das Einrichten eines sicheren Remotezugriffs jedoch meist durch das Installieren von Clientsoftware, das Eingeben obskurer Befehle und lange Verbindungszeiten gekennzeichnet.
In den vergangenen Jahren konnte eine Reihe von Ansätzen beobachtet werden, mit denen der Remotezugriff zu einer einfachen und umgänglichen Technologie weiterentwickelt werden sollte. So gibt z. B. Outlook® Web Access (OWA) dem Benutzer ein einfaches, browserbasiertes Mittel für den Zugriff auf E-Mails, Kalender und Kontakte an die Hand, und dies ohne die Komplexität eines voll ausgebauten virtuellen privaten Netzwerks (VPN) mit Layer 3. Technologien wie OWA sind ein wichtiger Bestandteil einer Lösung für „Zugriff überall“, die meisten Organisationen verfügen jedoch über eine Vielzahl wichtiger Anwendungen bei denen dieses integrierte Browserverhalten nicht möglich ist. In diesen Fällen stellen beispielsweise Terminaldienstlösungen effektive Methoden dar, mit denen den Benutzern der Zugriff auf ihre Anwendungen von jedem beliebigen Ort aus ermöglicht wird.
In Windows Server® 2008 hat Microsoft den Umfang der bereits mitgelieferten Features der Terminaldienste wesentlich erweitert. Terminaldienste verfügt nun über ein übergangsloses Fenster, ein Veröffentlichungsfeature „RemoteApp“ auf Anwendungsbasis, einen universellen Druckertreiber in Easy Print und ein browserbasiertes Portal mit dem Namen „TS-Webzugriff“. Zusätzlich – und besonders wichtig für den Zugriff überall – verfügt Windows Server 2008 auch über die Komponente „TS-Gateway“. Diese Komponente beinhaltet die SSL-Kapselung für das Remotedesktopprotokoll (Remote Desktop Protocol, RDP) und ermöglicht dadurch das einfache und sichere Durchlaufen von Firewalls und NAT-Geräten (Network Address Translation, Netzwerkadressübersetzung). TS-Gateway lässt sich außerdem in eine andere neue Technologie in Windows Server 2008, den Netzwerkzugriffsschutz (Network Access Protection, NAP) integrieren. Durch diese Kombination ist eine Überprüfung des Endpunktclientzustands möglich. Eine Kombination all dieser Komponenten ermöglicht Organisationen das Erstellen von Lösungen, mit denen Benutzer auf einfache Weise und sicher von jedem beliebigen Aufenthaltsort aus auf ihre Anwendungen und Daten zugreifen können.
In dieser Rubrik werden schwerpunktmäßig die Aspekte des Entwurfs von Netzwerken und Sicherheitsmechanismen bei Lösungen für den ortsunabhängigen Zugriff erörtert, weniger die Details zur Verwaltung von Terminaldienstkomponenten. Die Methoden zum Erstellen einer solchen Lösung werden auf Basis der in Windows Server 2008 enthaltenen Technologien aufgezeigt.

Wo liegt bei virtuellen privaten Netzwerken mit Layer 3 das Problem?
Beim Einsatz neuer Technologien sind besonders die Vorteile gegenüber derzeitigen Ansätzen von Bedeutung. Erst dadurch kann der Nutzen des neuen Modells beurteilt werden. Bei klassischen VPN mit Layer 3 müssen typischerweise zwei wesentliche Probleme angesprochen werden: Sicherheit und Benutzerfreundlichkeit.
Es mag nicht einleuchtend erscheinen, gerade die Sicherheit als ein Problem vieler moderner VPNs mit Layer 3 anzuführen. Geht es bei einem VPN nicht genau darum, einen sicheren Tunnel durch das Internet bereitzustellen? Um dies zu verstehen, sollte im Einzelnen bedacht werden, was normalerweise als Bedrohung für VPN angesehen wird. Es soll nicht heißen, dass die über diese VPNs übertragenen Daten abgefangen oder manipuliert werden können, denn die Verschlüsselung der Datenströme ist in den meisten VPNs mit Layer 3 hervorragend. Stellen Sie sich stattdessen vor, welche Bedrohung Remotecomputer mit Vollzugriff auf alle Ports und alle Protokolle des Netzwerks Ihrer Organisation darstellen. Das Problem sind nicht die von den Layer 3-VPNs verschlüsselten und übertragenen Datenströme. Stattdessen stellen eher die Remoteclients, die durch diese Tunnel eine Verbindung herstellen, ein hohes Risiko für Ihr internes Netzwerk dar. Erinnern Sie sich noch daran, dass die meisten der von Malware wie Slammer oder Blaster betroffenen Organisationen nicht über Computer im internen Netzwerk oder durch Hacker, die die Firewall überwinden konnten, infiziert wurden? Die Infektion kam stattdessen über Remotemitarbeiter, die von ihren infizierten Computern aus über VPN eine Verbindung zum internen Netzwerk herstellten. Wenn diese VPNs vollständig geroutete, auf Layer 3 basierende Verbindungen herstellen, erhält der Remotecomputer oftmals den gleichen Zugriff (sowohl zum Guten als auch zum Schlechten) auf interne Ressourcen wie ein Computer, der im Datencenter steht.
Zusätzlich ist der Betrieb von Layer 3-VPNs oftmals teuer, da Software auf Computern installiert und konfiguriert werden muss, die sich nicht im Verantwortungsbereich der IT-Gruppe der Organisation befinden. So erfordert beispielsweise das Installieren eines VPN-Clients auf dem privaten Heimcomputer eines Benutzers das Erstellen von speziell zugeschnittenen Installationspaketen und ausführlichen Installationsanleitungen für den Benutzer und möglicherweise die Behebung von Konflikten mit Anwendungen auf dem Computer des Benutzers. Außerdem können beträchtliche Verwaltungskosten entstehen, wenn neue Versionen des Clients bereitgestellt werden müssen oder wenn sich Konfigurationsdaten ändern (z. B. beim Hinzufügen eines neuen VPN-Endpunkts). Für den Benutzer erfolgt die Arbeit über dieses VPN oftmals nicht intuitiv. Da das VPN ausschließlich eine Layer 3-Verbindung bietet, ist es nicht einfach, die benötigten Geschäftsanwendungen und -daten für den Benutzer leicht zugänglich und sichtbar zu machen.

Lösen der Probleme mithilfe von Terminaldiensten
Terminaldienste und andere so genannte VPN-Technologien mit Layer 7 oder VPN-Technologien auf Anwendungsebene lösen diese beiden Probleme, da mit diesen Technologien wesentlich genauer kontrolliert werden kann, auf welche Ressourcen und Protokolle die Benutzer zugreifen können. Außerdem gestaltet sich der Umgang der Endbenutzer mit ihren Computern durch diese Technologien wesentlich einfacher und intuitiver als je zuvor.
Aus der Perspektive der Sicherheit besteht der wichtigste Unterschied zwischen einem Layer 3-VPN und einem VPN mit Terminaldiensten und TS-Gateway darin, dass die Verbindung zum internen Netzwerk nicht über eine komplett offene Pipeline erfolgt. Eine Lösung mit Layer 3 erstellt nämlich auf dem lokalen Computer eine virtuelle Schnittstelle mit vollständigem Routing in das interne Netzwerk, eine Lösung mit TS-Gateway hingegen ermöglicht ausschließlich RDP-Paketen den Zugriff auf das interne Netzwerk. Folglich ist die Gesamtangriffsfläche um ein Vielfaches kleiner, und im Rahmen des RDP können wesentlich genauere Steuerelemente zum Einsatz kommen. Ein Beispiel: obwohl das RDP das Umleiten von Laufwerken zulässt, können Organisationen das NAP in ihre TS-Gateways integrieren und dadurch diese Funktion sperren, wenn der Remotecomputer nicht beweisen kann, dass seine Antivirussoftware auf dem aktuellen Stand ist.
Für Endbenutzer besteht der offensichtlichste Unterschied zwischen einem Layer 3-VPN und einer auf Terminaldiensten aufbauenden Lösung in einem wesentlich einfacheren Setup (oftmals ist überhaupt kein Setup erforderlich) und in einem bedeutend einfacheren und intuitiveren Zugriff auf Anwendungen und Daten. Da der Client für die Remotedesktopverbindung integraler Bestandteil von Windows ist (und durch übliche Wartungstechnologien wie Windows® Update auf dem aktuellen Stand gehalten wird), muss normalerweise keine Clientsoftware installiert werden. Durch geschickte Nutzung von TS-Webzugriff können Benutzer über eine einzige URL auf all ihre Anwendungen und Daten zugreifen. Durch einfaches Klicken auf die gewünschte Anwendung startet TS-Gateway das sichere Tunneln der Verbindung über das Internet, und die Anwendung wird problemlos auf dem Desktop des Benutzers bereitgestellt. Anders ausgedrückt gleichen Erscheinungsbild und Verhalten einer lokal installierten Anwendung, einschließlich der Möglichkeiten zum Kopieren und Einfügen und zum Minimieren in die Taskleiste. Durch Anwendungen und Daten, die über einen auf Terminalserver basierenden Ansatz für den Remotezugriff einfacher auffindbar sind und ohne Zeitverzögerung zur Verfügung stehen, wird die Benutzerzufriedenheit erheblich erhöht. Außerdem sinken die Supportkosten.

Mögliche Netzwerkarchitekturen
Es gibt zwei grundlegende Ansätze für den Netzwerkentwurf zur Bereitstellung eines TS-Gatewayservers über das Internet. Bei einer Lösung wird TS-Gateway in das Umkreisnetzwerk zwischen zwei Layer 3/4-Firewalls gepackt. Bei der anderen Lösung verbleibt TS-Gateway im internen Netzwerk, und im Umkreisnetzwerk wird eine Firewall auf Anwendungsebene (z. B. Microsoft® ISA Server, Microsoft Intelligent Application Gateway oder eine der zahlreichen Drittanbieterlösungen) eingerichtet, die eingehende HTTPS-Frames überprüft. Die Pakete werden erst nach Analyse dieser eingehenden Sitzungen an den internen TS-Gatewayserver weitergeleitet.
Wenn eine Organisation ausschließlich über Layer 3/4-Firewalls mit einfacher statusbehafteter Paketprüfung verfügt, kann das TS-Gatewaygerät direkt in das Umkreisnetzwerk platziert werden, wie in Abbildung 1 dargestellt. Bei diesem Entwurf beschränkt die mit dem Internet verbundene Firewall die Konnektivität zum TS-Gateway und sorgt dafür, dass aus dem Internet ausschließlich HTTPS-Datenverkehr zum TS-Gateway gelangt. Die Firewall überprüft diesen Datenverkehr jedoch nicht auf Anwendungsebene. Sie leitet den Datenverkehr einfach zum TS-Gateway weiter. Der TS-Gatewayserver extrahiert anschließend die RDP-Frames aus den HTTPS-Paketen und leitet sie an den entsprechenden Back-End-Server weiter. Diese Back-End-Server werden in den meisten Fällen durch eine zweite Firewall vom Umkreisnetzwerk getrennt. Diese zweite Firewall ist so konfiguriert, dass RDP-Frames vom TS-Gateway an die entsprechenden internen Server weitergeleitet werden.
Abbildung 1 Bei einer Layer-3/4-Firewall wird TS-Gateway im Umkreisnetzwerk platziert.
Abbildung 1 Bei einer Layer-3/4-Firewall wird TS-Gateway im Umkreisnetzwerk platziert.
Dieses Szenario wird zwar vollständig unterstützt und kann für viele Organisationen von Nutzen sein, weist jedoch zwei bedeutende Nachteile auf: Erstens: Da TS-Gateway direkt aus dem Internet Datenverkehr empfängt, ist das Risiko eines externen Angriffs relativ hoch. Ein Angreifer könnte versuchen, das Gateway über die SSL-Sitzung zu attackieren, und da die Front-End-Firewall lediglich die Header und nicht die eigentlichen Daten überprüft, könnten diese Sitzungen das Gateway erreichen. Das heißt aber nicht, dass TS-Gateway eine Schwachstelle ist. TS-Gateway wurde den gleichen strengen Regeln für Sicherheitsentwurf und -tests unterworfen wie das gesamte Produkt Windows Server 2008. In diesem Szenario ist TS-Gateway jedoch einem höheren Risiko ausgesetzt, da es mit ungefiltertem Datenverkehr direkt aus dem Internet zu tun hat. Der zweite bedeutende Nachteil besteht im höheren Umfang des Datenverkehrs, der zwischen dem Gateway und der Back-End-Firewall zugelassen werden muss. Um Benutzer authentifizieren zu können, muss TS-Gateway mit Active Directory® kommunizieren. Damit diese Kommunikation möglich ist, muss die Back-End-Firewall für eine viel breitere Palette an Ports und Protokollen Ausnahmen genehmigen, als lediglich HTTPS zuzulassen. Diese breitere Palette an Kommunikationsmöglichkeiten stellt bei diesem Entwurf ebenfalls ein relativ hohes Risiko dar.
Ein besserer Ansatz für den Zugang eines TS-Gateways zum Internet besteht darin, eingehende HTTPS-Sitzungen von einer Firewall auf Anwendungsebene (Layer 7) überprüfen zu lassen, bevor diese Sitzungen das Gateway erreichen (siehe Abbildung 2). Bei diesem Entwurf können immer noch traditionelle Layer 3/4-Firewalls vorhanden sein und ein Umkreisnetzwerk bilden. Anstelle von TS-Gateway wird jedoch die Layer 7-Firewall im Umkreisnetzwerk platziert. Wenn Datenverkehr die äußere Firewall erreicht, filtert diese Firewall alles außer HTTPS-Frames aus und leitet diese Frames anschließend an die Layer 7-Firewall weiter. Die Layer 7-Firewall beendet die SSL-Sitzung, überprüft den unverschlüsselten Inhalt des Datenstroms, blockiert Datenverkehr mit schädlichen Inhalten und sendet anschließend die RDP-Frames durch die Back-End-Firewall und weiter zum TS-Gateway. Beachten Sie, dass die Layer 7-Firewall die Frames vor dem Senden zum TS-Gateway auf Wunsch auch wieder verschlüsseln könnte. Dieser Ansatz ist für ein privates Netzwerk einer Organisation möglicherweise zu aufwändig, kann aber für gehostete Datencenter oder bei gemeinsam genutzten Netzwerken sehr zweckmäßig sein.
Abbildung 2 Verwenden einer Firewall auf Anwendungsebene mit einem TS-Gatewaygerät
Abbildung 2 Verwenden einer Firewall auf Anwendungsebene mit einem TS-Gatewaygerät
Durch diesen Entwurf werden beide Nachteile der zuerst vorgestellten Lösung eliminiert. Da der TS-Gatewayserver ausschließlich Datenverkehr erhält, der bereits von der Layer 7-Firewall überprüft wurde, verringert sich das Risiko, dass Angriffe aus dem Internet durchkommen. Die Layer 7-Firewall müsste diese Angriffe filtern und nur sauberen, überprüften Datenverkehr zum Gateway zurücksenden.
Der zweite wesentliche Vorteil dieser Lösung besteht in der Position des Gateways bezüglich des internen Netzwerks. Da der aus dem Internet eingehende Datenverkehr von der Layer 7-Firewall überprüft wird, bevor er das Gateway erreicht, kann das Gateway im internen Netzwerk verbleiben und bei Authentifizierungen direkt auf Domänencontroller und bei Benutzersitzungen direkt auf RDP-Hosts zugreifen. Ferner können wesentlich restriktivere Richtlinien für die Back-End-Firewall eingerichtet werden. Es ist nicht erforderlich, sowohl RDP-Datenverkehr als auch Datenverkehr für die Verzeichnisauthentifizierung zuzulassen. Das Zulassen von RDP-Sitzungen von der Layer 7-Firewall zum TS-Gateway genügt vollauf. Das Verwenden einer Layer 7-Firewall als Front-End der TS-Gatewaybereitstellung stellt eine Lösung mit höherer Sicherheit bereit. Diese Lösung ist einfacher zu verwalten, und ein Umgestalten des bereits vorhandenen Umkreisnetzwerks ist nicht erforderlich.

Integration von NAP
Ressourcen zu Terminaldiensten
  • Terminaldienste in Windows Server 2008
  • Windows Server 2008-Terminaldienste TechNet-Forum
  • Terminaldienste-Teamblog
  • Microsoft Intelligent Application Gateway 2007
  • Network Access Protection (NAP) für Windows Server 2008
  • Network Access Protection (NAP)-Teamblog
  • Schrittweise Anleitungen zu Windows Server 2008 Beta 3

Das Schlüsselelement einer Lösung für den ortsunabhängigen Zugriff ist unumstritten ein ausgewogener Entwurf des Umkreisnetzwerks. Von gleicher Wichtigkeit sind jedoch Konformität und Sicherheit der Geräte an den Endpunkten. Da RDP ein reichhaltiges Protokoll ist, das viele Arten von Geräteumleitungen zulässt, z. B. RDP-Sitzungen und Drucker, ist es außerordentlich wichtig, dass die Clients, die eine Verbindung zu Ihrer Lösung herstellen, die Sicherheitsrichtlinien Ihrer Organisation einhalten. Auch mit einer sicheren, auf bewährten Methoden basierenden Netzwerktopologie wie bei den oben diskutierten Lösungen, kann es einem Endbenutzer, der beispielsweise eine Verbindung zu einem Terminalserver von einem unsicheren Computer aus herstellt, letztendlich trotzdem noch passieren, dass vertrauliche Daten verloren gehen oder dass schädliche Dateien auf den Terminalserver gelangen. Obwohl das Ausmaß der Konnektivität und damit das Schadenspotenzial bedeutend geringer sind als bei einer Verbindung über ein Layer 3-VPN, ist es trotzdem wichtig, das Risiko von Datenverlusten möglichst gering zu halten und für eine Einhaltung der IT-Richtlinien zu sorgen.
Netzwerkzugriffschutz (Network Access Protection, NAP) ist eine neue Technologie in Windows Server 2008, mit der Sie nicht nur kontrollieren können, wer eine Verbindung zu Ihrem Netzwerk herstellen kann, sondern auch von welchen Systemen ein Verbindungsaufbau ermöglicht werden soll. So können Sie z. B. mithilfe von NAP sicherstellen, dass nur Computer mit aktivierter Firewall und aktueller Antivirussoftware eine Verbindung zum Netzwerk herstellen können. NAP ist eine erweiterbare Lösung, die nicht nur das interne Netzwerk der Organisation, sondern auch Remotebenutzer einschließt, unabhängig davon, ob die Verbindung über ein Layer 3-VPN oder über TS-Gateway hergestellt wird. Durch Integration von NAP in Ihren TS-Gatewayentwurf können Sie dafür sorgen, dass nur die Systeme, die Ihre Sicherheitsrichtlinien einhalten, eine Verbindung zu Ihrem Netzwerk herstellen können. Weitere Informationen über NAP finden Sie unter der Rubrik „Sicherheit auf dem Prüfstand“ in der Ausgabe des TechNet Magazins vom Mai 2007, die online unter technetmagazine.com/issues/2007/05/SecurityWatch verfügbar ist.
Die Integration von NAP in eine TS-Gateway-Bereitstellung ist ein einfacher Prozess, beim dem ein einziger zusätzlicher Dienst in den Entwurf einbezogen wird. Bei diesem Dienst handelt es sich um den Netzwerkrichtlinienserver (Network Policy Server, NPS), der entweder auf dem TS-Gatewayserver selbst oder auf einer separaten Betriebssysteminstanz installiert werden kann. Anschließend werden mithilfe der TS-Gateway-MMC Verbindungsautorisierungsrichtlinien (Connection Authorization Policies, CAP) erstellt, in denen festgelegt wird, welche RDP-Funktionen bei einem bestimmten Zustand des Computers zulässig sind. Der TS-Gatewayserver wird so konfiguriert, dass der NPS bei jedem Verbindungsversuch überprüft und das SoH (Statement of Health) für diese Verbindung an den NPS übermittelt wird. Der Netzwerkrichtlinienserver vergleicht anschließend das SoH mit seinen Richtlinien und teilt TS-Gateway mit, ob die Verbindung beim gegebenen Zustand des Clients zugelassen werden kann oder nicht.
Ein solcher Vorgang ist in Abbildung 3 dargestellt: Ein nicht richtlinienkonformes System ist nicht für die Verwendung von Windows Update konfiguriert. In den Sicherheitsrichtlinien der Organisation ist jedoch vorgeschrieben, dass „Automatische Updates“ aktiviert ist. Wenn ein Benutzer versucht, mit diesem Computer eine Verbindung zum TS-Gateway herzustellen, erzeugt und sendet der Computer ein SoH. Dieses SoH lautet in etwa: „Meine Firewall ist aktiv, und meine Antivirussoftware ist auf dem aktuellen Stand, automatische Updates sind jedoch deaktiviert“. TS-Gateway leitet dieses SoH einfach an den NPS weiter (TS-Gateway kann das SoH nicht selbst decodieren), und der NPS vergleicht dieses SoH mit den vom Administrator definierten Richtlinien. Da automatische Updates deaktiviert wurden, bestimmt der NPS, dass die Verbindung der „nicht richtlinienkonformen“ Richtline entspricht und teilt TS-Gateway mit, dass die Verbindung nicht zugelassen werden soll. TS-Gateway trennt daraufhin die Verbindung und teilt dem Benutzer mit, dass der Computer die Sicherheitsrichtlinien der Organisation nicht erfüllt. Der Benutzer kann nun die erforderlichen Korrekturen vornehmen (in diesem Fall müssten einfach „Automatische Updates“ aktiviert werden) und erneut versuchen, die Verbindung herzustellen. Dadurch wird ein neues SoH erzeugt, der NPS erkennt den ordnungsgemäßen Zustand, und TS-Gateway lässt die Verbindung zu.
Abbildung 3 Nur richtlinienkonforme Systeme können eine Verbindung herstellen
Abbildung 3 Nur richtlinienkonforme Systeme können eine Verbindung herstellen

Schlussbemerkung
Windows Server 2008 verfügt über alle wichtigen Bausteine einer Lösung für einen sicheren ortsunabhängigen Zugriff. TS-Gateway stellt eine sichere Methode zum Tunneln von Remotedesktopsitzungen über das Internet zur Verfügung und bietet Organisationen eine breite Palette an Möglichkeiten für die Integration von TS-Gateway in bereits vorhandene Netzwerke. Es besteht die Möglichkeit, TS-Gateway direkt in das Umkreisnetzwerk oder hinter eine Layer 7-Firewall wie ISA Server oder Intelligent Application Gateway zu platzieren. Mit einer Kombination aus NAP und TS-Gateway kann eine Überprüfung des Zustands der Geräte an den Endpunkten integriert werden. Durch Überprüfung der Geräte an den Endpunkten können Organisationen nicht nur sicherstellen, dass der Verbindungsaufbau durch einen zulässigen Benutzer erfolgt, sondern auch, dass deren Computer den IT-Sicherheitsrichtlinien entsprechen. Eine Kombination dieser Technologien stellt Organisationen Funktionen für den Remotezugriff zur Verfügung, die sicherer und effizienter zu betreiben sind und verbesserte Benutzerfreundlichkeit bieten. Weitere Informationen finden Sie auf den in der Randleiste „Ressourcen zu Terminaldiensten“ aufgeführten Websites.

John Morello ist seit 2000 für Microsoft tätig. Als leitender Berater hat er Sicherheitslösungen für Fortune 100-Unternehmen sowie für US-amerikanische Kunden aus dem zivilen Bereich und dem Verteidigungswesen entworfen. Derzeit arbeitet er als leitender Programmmanager in der Windows Server Group an Technologien für ortsunabhängigen Zugriff. Sie können den Blog seines Teams unter blogs.technet.com/WinCAT lesen.


 Die Desktopdateien: Die Wahrheit &#252;ber Defragmentierung
Die Desktopdateien
Die Wahrheit über Defragmentierung
Wes Miller

Die Datenträgerfragmentierung gibt es, seit es Festplatten gibt. Wenn Sie wirklich Grund zur Sorge um Ihre Systeme haben, sollten Sie sie regelmäßig defragmentieren. Dies erinnert Sie wahrscheinlich an die alljährliche Unterhaltung mit Ihrem Zahnarzt – wenn es um die Anwendung von Zahnseide geht. Defragmentierung ist genauso wichtig.
Wenn Ihr Computer nicht in einer Ecke steht und immer ausgeschaltet ist, wird er immer mehr fragmentiert. Wie dies vor sich geht, wird gleich erläutert, doch zuerst soll Stück Defragmentierungsgeschichte erwähnt werden.

Defragmentierung und Windows NT
Windows NT® enthielt kein integriertes Dienstprogramm zur Defragmentierung, und zu jener Zeit wurde allgemein angenommen, dass es auch nicht nötig ist. Immerhin stand bei der Erstellung von NTFS der Optimierungsgedanke im Mittelpunkt, und seine Fragmentierung stellte kein so großes Problem dar wie ein vergleichbarer FAT-Datenträger. Doch mit der Zeit kann sogar die NTFS-Leistung unter einer nicht optimalen Dateiverteilung leiden. Dadurch entstand ein blühender Markt für die Defragmentierungstools von Drittanbietern. Eines der beliebtesten Produkte unter IT-Experten war Diskeeper von Executive Software (heute Diskeeper Corporation). Als Windows 2000 die Defragmentierungsfunktionalität integrierte, erwarb Microsoft von Executive Software eine Lizenz für die Technologie. Die Windows® 2000-Defragmentierungsfunktionalität war in einem eigenen Microsoft® Management Console (MMC)-Snap-In (dfrg.msc) verfügbar, das durch Klicken auf einen Datenträger oder durch manuelles Ausführen von „defrag.exe“ über die Befehlszeile aufgerufen werden konnte. Obwohl keine Zeitplanung und nur eine eingeschränkte Befehlszeile verfügbar waren, erstellten viele IT-Experten weiterhin funktionale Skripts, um die Defragmentierung mithilfe dieser integrierten Version zu automatisieren. Defrag.exe in Windows XP und Windows Server® 2003 hatte sich im Vergleich zur früheren Version verbessert, bot jedoch nur eine begrenzte Automatisierung, denn es erforderte nach wie vor eine Skripterstellung.
Eine Anzahl von Anbietern, einschließlich Winternals Software (mein ehemaliger Arbeitgeber), hat Software für die Defragmentierung von Speicherplatz in Unternehmen hergestellt. Die meisten dieser Produkte funktionieren auf die gleiche Weise mit einer zentralisierten Konsole, einer Art Agent, der sich auf Clientsystemen befindet (manchmal fortlaufend, manchmal nur bei Bedarf), und einer Struktur, anhand derer bestimmt werden kann, wann und wie eine Defragmentierungsaufgabe ausgeführt wird.
Windows Vista® setzt im Großen und Ganzen den Trend der Einzelsystemdefragmentierung fort. Dabei wird das Defragmentierungsprogramm optimiert, und es werden Optionen wie das Defragmentieren kleiner Dateifragmente (64 MB oder kleiner) integriert. Dadurch wird die Defragmentierung beschleunigt, doch viele größere Dateifragmente werden auf dem Dateiträger belassen. Das Defragmentierungsmodul an sich ist in Windows Vista und Windows Server 2008 leistungsfähiger als in früheren Versionen von Windows. Es wird zudem automatisch ausgeführt und erfordert keine manuelle Zeitplanung. In einem großen Unternehmen oder wenn Sie Ihre Systeme in einer Weise optimieren möchten, die von den Standardoptionen des Defragmentierungsprogramms nicht abgedeckt wird, kann es sein, dass Sie eine Lizenz für Drittanbietersoftware erwerben müssen. Wie in früheren Versionen treten bei der Defragmentierung eines Datenträgers möglicherweise Schwierigkeiten auf, wenn die NTFS-Komprimierung aktiviert ist und viel verwendet wird. Ein Drittanbietertool könnte bei solch einem Szenario ebenfalls nützlich sein.

Weshalb findet die Fragmentierung statt?
Fragmentierung findet statt, weil sich die Dateien mit der Zeit ändern. Im Idealfall ändern sich Windows-Dateien nicht. Zumindest ändern sie sich nicht so oft, im Grunde eigentlich nur durch Installationen von Service Packs und Softwareupdates. Sonst bleiben die Systemdateien relativ unverändert. Nach dem Durchführen einer größeren Aktualisierung wie etwa der Installation eines Service Packs, findet die Fragmentierung automatisch statt, da die aktualisierten Dateien normalerweise nicht an ihrem Datenträgerspeicherort überschrieben werden können (und zur Aktualisierung eventuell einen Neustart erfordern), was zu weiterer Fragmentierung führt.
Benutzerdateien und -daten (und die Windows-Registrierung) hingegen unterliegen ständigen Änderungen. Das Lesen, Schreiben, Bearbeiten, Kopieren und Löschen von Dateien führt zu umfangreicher Fragmentierung, vor allem bei zunehmender Auslastung der Laufwerkkapazität.
Um sich ein Bild davon zu machen, stellen Sie sich einen perfekt geordneten Datenträger vor, auf dem die Dateien den Platz lückenlos auffüllen. Angenommen, Sie öffnen und bearbeiten eine Datei und versuchen anschließend, die Datei zu speichern. Wenn die Dateigröße zugenommen hat, muss sie von Windows entweder in ihrer Gesamtheit an einem anderen Ort auf dem Datenträger gespeichert werden (angenommen nach der Datei N), oder die aktuellsten Daten müssen nach der Datei N gespeichert werden. Das bedeutet, dass Datei 2 jetzt fragmentiert ist. Wenn Sie jetzt Datei 1 bearbeiten, liegen zwei fragmentierte Dateien vor. Wenn Sie dies eine Zeit lang fortsetzen, erhalten Sie am Ende ein stark fragmentiertes System, in dem das Laufwerk an mehreren Orten suchen muss, um auf eine einzelne Datei zuzugreifen. Bei großen Datenbankdateien, umfangreichen Festplattendateien für virtuelle Computertechnologien und zahlreichen, auf einem durchschnittlichen Datenträger gespeicherten Video- und Audiodateien tritt oft Fragmentierung auf. Selbstverständlich ist dies aufgrund der zunehmenden Größe moderner Festplatten kein großes Problem, doch die Fragmentierung ist damit nicht beseitigt. Die Reaktionsfähigkeit älterer Laptops mit kleineren Festplatten nimmt immer mehr ab, sie starten langsamer und benötigen mehr Zeit, um Dateien zu öffnen und zu speichern.
Das Hauptproblem ist nicht unbedingt, wie fragmentiert das System ist, sondern wie fragmentiert die einzelnen Dateien sind. Schon von Anfang an, als die ersten Datenträger-Defragmentierungsprogramme mit mehrfarbigen Grafiken eingeführt wurden, sahen sich die Benutzer die Grafiken an und dachten sich: „Ich will einen durchgehenden Balken“. Doch im Grunde ist das überhaupt nicht wünschenswert. Einige Produkte versuchen, ihren Datenträgern den Anschein zu geben, dass es sich um zwei Blöcke handelt: einen farbigen (Dateidaten) und einen in der Regel weißen (freier Speicherplatz). Leider ist dies eines der schlimmsten Dinge, die Sie einem Datenträger antun können, wenn Sie die Absicht haben, die Frequenz und die Kosten der Defragmentierung zu reduzieren. Wenn Sie alle Dateidaten intensiv komprimieren und an den Anfang des Datenträgers stellen sowie den Großteil des freien Speicherplatzes bei zusätzlichen Dateibearbeitungen entfernen, müssen alle zusätzlichen Dateibearbeitungen an das Ende der Dateidaten gestellt werden. Diese Vorgehensweise führt im Grunde zur Fragmentierung, die mit der nächsten Dateibearbeitung einsetzt. Statt zwei Blöcke mit sauber geordneten Dateidaten zu haben, führt eine gute Defragmentierung zu einem Speicherabbild, das nicht unbedingt perfekt ist. In Abbildung 1 ist beispielsweise mein Testsystem vor der Defragmentierung dargestellt. Betrachten Sie als Nächstes Abbildung 2, in der das gleiche System nach dem Abschluss der Windows-Defragmentierung zu sehen ist.
Abbildung 1 Mein Laufwerk vor dem Defragmentieren
Abbildung 1 Mein Laufwerk vor dem Defragmentieren
Abbildung 2 Mein Laufwerk nach dem Defragmentieren
Abbildung 2 Mein Laufwerk nach dem Defragmentieren
Beachten Sie, dass bei Windows nicht die Fragmentierung der Dateien auf dem gesamten Datenträger, sondern die Fragmentierung der einzelnen Dateien im Mittelpunkt steht (in Abbildung 3 wird der Abschnitt des Defragmentierungsberichts für „Am stärksten fragmentierte Dateien“ vor der Defragmentierung angezeigt).
Abbildung 3 Defragmentierungsbericht
Abbildung 3 Defragmentierungsbericht
Demzufolge wird Windows auch nach der Defragmentierung keinen vollständig komprimierten Satz von Dateidaten am Anfang des Datenträgers anzeigen. Beachten Sie auch den großen Abschnitt grüner Daten in den beiden Abbildungen 1 und 2. Das ist die Windows-Auslagerungsdatei, die weiter unten behandelt wird. Wenn Sie auf Ihrem Windows-System den Ruhezustand aktiviert haben, wird dies ebenso in einer Defragmentierung angezeigt.

Regelmäßige Defragmentierung ist unerlässlich
Wie beim Beispiel mit der Zahnseide: Denken Sie daran, dass das Wichtigste das regelmäßige Defragmentieren ist. Es ist sogar noch wichtiger, auf Systemen mit hoher Nutzungsrate wie Servern oft zu defragmentieren. Denn wenn Sie damit warten, dauert der Prozess möglicherweise zu lange, sodass Ihr Server nicht verfügbar oder nicht reaktionsfähig ist (weil die Defragmentierung relativ viel Zeit in Anspruch nehmen kann und bestimmte Phasen der Defragmentierung zudem CPU-intensiv sein können).
Sogar die besten Onlinedefragmentierungsprogramme können nicht alles defragmentieren. Diese können zum Beispiel geöffnete oder gesperrte Dateien (wie zum Beispiel die Auslagerungsdatei oder die Registrierungsdateien) nicht immer defragmentieren und müssen die Ruhezustandsdatei umgehen, falls sie vorhanden ist (sie ist so groß wie der auf Ihrem System verwendete Arbeitsspeicher). Weitere Informationen zum Optimieren gesperrter Dateien finden Sie folgenden Abschnitt über Defragmentierungstricks.
Es ist wichtig, die falschen Vorstellungen und die Fakten im Zusammenhang mit Defragmentierung zu verstehen. In Abbildung 4 und Abbildung 5 werden einige allgemeine Themen aufgelistet, die in Diskussionsrunden zur Defragmentierung vorgebracht werden, sowie die Wahrscheinlichkeit, dass diese Probleme tatsächlich auftreten.
Figure 5 Falsche Vorstellungen über das Defragmentieren (Close Figure 5)

Falsche Vorstellung | Wahrscheinlichkeit
Systeme stürzen ab. | Unwahrscheinlich – Abstürze werden in der Regel durch Treiber- oder Hardwareprobleme verursacht (Speicherbeschädigung bzw. Neustarts oder Datenträgerfehler aufgrund von Temperaturproblemen).
Anwendungen stürzen ab. | Unwahrscheinlich – Wie auch bei einem Gesamtsystem dürfte eine ordnungsgemäß entworfene Anwendung nicht aufgrund von Fragmentierung abstürzen. Solange bei der Ursachenermittlung nicht das Gegenteil festgestellt wird, sollten Sie nicht annehmen, dass dies von der Fragmentierung verursacht wird.
Die Registrierung wird beschädigt. | Unwahrscheinlich (siehe oben) – Fragmentierung verursacht keine Registrierungsbeschädigung.
Das Ergebnis einer Defragmentierung sollte ein durchgehender Balken in einer visuellen Darstellung des Datenträgers sein. | Unwahrscheinlich – Drängen Sie im Allgemeinen nicht alle Dateien auf dem System zusammen, es sei denn, Sie haben die Absicht, ein Abbild des Systems mit einem sektorbasierten Abbilderstellungstool zu erstellen, das freien Speicherplatz nicht ausschließt bzw. die Partitionen nicht verkleinert oder teilt. Sie müssen die Dateien an den Anfang des Datenträgers stellen. Ansonsten führt intensive Dateikonsolidierung nur zu weiterer Fragmentierung.
Figure 4 Häufige Bedenken beim Defragmentieren (Close Figure 4)

Bedenken | Wahrscheinlichkeit
Die Systemleistung wird leiden. | Hoch – Hängt insbesondere von der Systemverwendung ab.
Das Wiederherstellen versehentlich gelöschter Dateien könnte schwierig oder unmöglich werden. | Hoch – Die meisten Tools zur Dateiwiederherstellung hängen von der heuristischen Methode (zur Bestimmung des Datentyps) und der Dateiclusternähe ab. Verstreute Dateien führen zu einem komplexeren oder unmöglichen Wiederherstellungsvorgang.
Es wird teuer, das System zu defragmentieren. | Mittel – Es gibt einen direkten Zusammenhang zwischen dem Nutzungsgrad des Systems und dem Ausmaß, wie sehr sich die Dateien auf dem System mit der Zeit ändern. Wenn die Benutzer zum Beispiel Dateien sehr intensiv bearbeiten, aber nur auf Serverfreigaben speichern, wird sich die Leistung mit der Zeit nicht stark verringern.
Der Datenträger wird beschädigt. | Gering – Eher unwahrscheinlich. Auch hier gilt: Je mehr ein System in Anspruch genommen wird (eingeschaltet mit ständig aktiven Datenträgern, auf denen Dateien bearbeitet, geändert oder gelöscht werden), umso wahrscheinlicher ist eine Beschädigung. Doch angesichts der heutigen Hardware ist es unwahrscheinlich, dass dies einfach aufgrund der Dateibearbeitung auftritt.

Defragmentierung als Teil Ihrer Infrastruktur
Sie sollten ernsthaft erwägen, ein Defragmentierungsprogramm regelmäßig auf allen Ihren Systemen auszuführen. Sie können das in Windows integrierte Defragmentierungsprogramm verwenden oder das Angebot von Drittanbietern wahrnehmen. Letzten Endes hängt es davon ab, wie viel Aufwand Sie betreiben möchten. In Windows XP und höheren Versionen können Sie „defrag.exe“ als geplanten Task hinzufügen. Im Knowledge Base-Artikel unter support.microsoft.com/kb/555098 erfahren Sie mehr dazu. Beachten Sie, dass die Laptopdefragmentierung einige spezielle Überlegungen erfordert. Das System eines Benutzers soll defragmentiert werden, wenn es (im Idealfall über einen Netzanschluss) eingeschaltet ist, doch CPU- oder Datenträgerzyklen sind unerwünscht, wenn ein Benutzer mobiler Geräte gerade arbeitet. Wenn jedoch ein Benutzer mobiler Geräte momentan nicht auf seinem System arbeitet, ist die Netzverbindung aller Wahrscheinlichkeit nach leider unterbrochen, und das System befindet sich entweder im Standby- oder im Ruhezustand (was aus der Sicht der Energieverwaltung und der geplanten Tasks ausgeschaltet ist). Bei Winternals (wie wahrscheinlich überall) wurde viel Zeit darauf verwendet, ein ideales Szenario für Benutzer mobiler Geräte zu entwerfen. Wenn Sie Windows Vista verwenden, eine Lösung mit einem integrierten Defragmentierungsprogramm und geplanten Tasks, die eine viel bessere Leistung bietet als frühere Versionen, ist dies möglicherweise schon ausreichend. Andernfalls ist eventuell eine Drittanbieterlösung für mobile Systeme notwendig. Einige davon starten einen Defragmentierungstask und teilen Ihnen mit, dass und wann er ausgeführt wurde (und wie oft) und wie lange die Ausführung gedauert hat.
Zusätzlich zu mobilen Szenarios empfiehlt es sich, an die Fragmentierung über das Dateisystem hinaus zu denken. Im Allgemeinen stellt dies bei Desktops oder mobilen Systemen nicht notwendig, doch Server, Microsoft Exchange, SQL ServerTM oder andere Datenspeicher erfordern unter Umständen ihr eigenes Defragmentierungsprogramm. In solchen Fällen müssen Sie entscheiden, ob dies vor oder nach dem Durchführen einer Dateisystemdefragmentierung erfolgen soll.
Wenn Sie das Defragmentierungsprogramm eines Drittanbieters verwenden, werden Sie sicherstellen wollen, dass es die Windows-Defragmentierungs-API verwendet. Seit Windows NT 4.0 hat Windows seine eigene Defragmentierungs-API zur Verhinderung eines unerwarteten Datenverlusts. Wenn Sie zum Beispiel gerade eine Datei verschieben und Ihr System die Energieversorgung verliert, ist eine unvollständige Fragmentverschiebung, die zum Datenverlust und gar einem nicht mehr startfähigen System führen könnte, alles andere als willkommen.
Abschließend sei angemerkt: Wenn Sie eine virtuelle Computertechnologie verwenden, empfiehlt sich außerdem die Überlegung, wie Sie die Defragmentierung Ihrer virtuellen Datenträger verwalten. Die Wahrscheinlichkeit der Fragmentierung ist ebenso hoch wie bei physischen Datenträgern. In vielerlei Hinsicht dürfte die Fragmentierung hier aufgrund von Größeneinschränkungen noch stärker ausgeprägt sein. Hinzu kommt, dass Sie, wenn Ihre Virtualisierungslösung die Verkleinerung von Datenträgern und Partitionen ermöglicht, u. U. als Erstes defragmentieren müssen, um Speicherplatz freizumachen (oder zumindest die Dauer des Verkleinerungsvorgangs zu verkürzen).

Zusätzliche Tools
Jetzt sind Sie bestimmt davon überzeugt, dass die Defragmentierung eine wichtige und wertvolle Funktion ist. Selbst wenn Sie kein Drittanbietertool für die Defragmentierung selbst verwenden, empfiehlt sich ein von Mark Russinovich entwickeltes Tool namens „PageDefrag“, das Sie auf der Microsoft Sysinternals-Toolwebsite (siehe microsoft.com/technet/sysinternals/FileAndDisk/PageDefrag.mspx) herunterladen können. Wie weiter oben bereits erwähnt, kann die Windows-Auslagerungsdatei nicht defragmentiert werden, während Windows online ist. Das Gleiche gilt eigentlich auch für die Windows-Registrierungsdateien und die Ereignisprotokolle. PageDefrag ermöglicht mithilfe eines kleinen Treibers die Defragmentierung dieser gesperrten Dateien, bevor Windows den Startvorgang abgeschlossen und diese Dateien gesperrt hat. Führen Sie einfach PageDefrag aus, und stellen Sie es so ein, dass es entweder beim nächsten Neustart oder bei jedem Neustart ausgeführt wird. Wenn das System neu startet (an dem Punkt im Startvorgang, an dem Sie schon einmal eine Datenträgerüberprüfung bemerkt haben), werden die in der Liste angegebenen Dateien defragmentiert (siehe Abbildung 6).
Abbildung 6 In PageDefrag zu defragmentierende Dateien
Abbildung 6 In PageDefrag zu defragmentierende Dateien
Nachdem PageDefrag abgeschlossen ist, beendet das System den Vorgang normalerweise durch einen Neustart. Weitere Informationen zu PageDefrag erhalten Sie in der Septemberausgabe von „Schwerpunkt Dienstprogramme“ von Lance Whitney (siehe technetmagazine.com/issues/2007/09/UtilitySpotlight). Beachten Sie, dass PageDefrag nur unter Windows NT 4.0, Windows 2000, Windows XP und Windows Server 2003 unterstützt wird, nicht jedoch unter Windows Vista.
Zusätzlich zu PageDefrag gibt es ein anderes Tool namens „Contig“, das Sysinternals zur Verfügung stellt und mit dem Sie eine bestimmte Datei manuell defragmentieren können (siehe microsoft.com/technet/sysinternals/FileAndDisk/Contig.mspx). Dies kann nützlich sein, wenn eine bestimmte Datei über einen gewöhnlichen Defragmentierungstask nicht defragmentiert werden konnte oder wenn sie seitdem fragmentiert wurde (nicht jedoch der restliche Datenträger).
Contig kann zudem ein ganzes Verzeichnis oder Unterverzeichnisse mithilfe von Platzhaltern defragmentieren. Im Folgenden werden alle Dateien im Windows-Verzeichnis unabhängig von ihrem Speicherort defragmentiert.
Contig –s c:\Windows\*.*
Durch Anwenden des Schalters „–v“ wird der Vorgang zu einem ausführlichen Vorgang, und „–q“ bewirkt, dass der Vorgang automatisch ausgeführt wird.

Wes Miller ist Entwicklungsmanager bei Pluck (www.pluck.com) in Austin, Texas. Davor arbeitete er bei Winternals Software in Austin und bei Microsoft als Programmmanager und Produktmanager für Windows. Sie können Wes Miller unter technet@getwired.com erreichen.


 Berichte aus der Praxis: Der Verhaltenskabeljau
Berichte aus der Praxis
Der Verhaltenskabeljau
Betsy Aoki

Manchmal brauchen Sie möglicherweise keinen größeren Server oder besser geschulte Benutzer, die Sie nicht anpiepsen, wenn Sie gerade dabei sind, mit der Arbeit Schluss zu machen, um das Wochenende zu genießen. Manchmal ist nicht die Verwaltung von Code das Problem – vielleicht brauchen Sie einfach nur einen riesigen Fisch.
Vor etwa einem Jahr arbeitete ich für die Live QnA-Website (qna.live.com) an Berichten über Missbrauch. Wir hielten die Schaltflächen zum Löschen in ständiger Bereitschaft und überwachten die Website in Bezug auf schwachsinnige Angriffe und schlechtes Verhalten. Uns standen interne Tools zur Verfügung. Wir hatten externe Richtlinien. Wir boten ein paar echten Spinnern die Stirn, die versuchten, unsere Fragen mit üblem Inhalt zu sabotieren.
Dabei verausgabte ich mich völlig. Schließlich war es meine Aufgabe, mich um den Zustand der Websitecommunity zu kümmern. Ich war diejenige, die am Verhaltenskodex mitarbeitete, der für die Website maßgeblich war. Ich war die Torwächterin, und alle sollten sich einfach nur BENEHMEN.
Nur, dass sie es nicht taten. Die Leute sind nun mal so – fähig zu den größten Niederträchtigkeiten und der allergrößten Frömmigkeit. Ich wollte mich eigentlich nicht damit befassen, ob jemand einen anderen Benutzer ein Arschgesicht nannte oder nicht.
An einem Samstag saß ich in meiner Küche und dachte über den Verhaltenskodex nach, den ich verteidigte. Während ich so mit einem Kugelschreiber herumkritzelte, kam mir eine Erleuchtung. Was wäre, wenn es keinen Verhaltenskodex („code of conduct“), sondern einen Verhaltenskabeljau („cod of conduct“) gäbe? Und wenn es ihn gäbe, wie würde dieser Kabeljau dann aussehen und sich verhalten? Ich bin in Neuengland aufgewachsen, wo wir Kabeljau gegessen haben. Weißen, schuppigen, langweiligen Kabeljau. Ich wollte in der Lage sein, meine QnA-Mitglieder mit dem Ton eines Kabeljaus zu schelten oder ihnen zu schmeicheln. Nicht nur mit der Vorschlaghammermethode der „Löschen“-Schaltfläche, die ich in letzter Zeit viel zu häufig verwendete, sondern mit bissigem Witz, der den Betreffenden zum Lachen bringen würde, während er gelobte, sich zukünftig zu benehmen. Damit war Norbert, der Verhaltenskabeljau, geboren. Ich überlegte, ob ich ihn mit einer Pfeife ausstatten sollte, dachte mir aber, dass die Fliege ausreichte.
Der Verhaltenskabeljau
Ich lud meine Fischzeichnung in eine neue LiveID hoch, gab ihr einen QnA-Benutzernamen, und Norbert, der Verhaltenskabeljau, war startbereit. Es war jedoch nicht immer ich, die hinter ihm stand. Manchmal übernahm ein anderes Teammitglied die Kabeljaurolle und schimpfte mit den Übeltätern. Wer ist der Verhaltenskabeljau? Siehe go.microsoft.com/fwlink/?LinkId=99044. Verletzt der Verhaltenskabeljau die Gefühle anderer? Siehe go.microsoft.com/fwlink/?LinkId=99045.
Die QnA-Communitymitglieder akzeptierten ihn wie selbstverständlich. Sie neckten ihn, riefen ihn herbei, waren sauer auf ihn. Er erzog die Neulinge, schimpfte mit denen, die unser Meinung nach eines Besseren belehrt werden konnten, und stellte eine fröhliche Betrachtungsweise der Regeln zur Verfügung, die über das Lesen einer auf Fakten beschränkte, im juristischen Jargon geschriebenen Webseite hinausging.
Regeln (egal, ob es sich um Unternehmensrichtlinien, das Stammesgesetz oder die Hackordnung auf dem Spielplatz handelt) hängen alle vom guten Willen derjenigen ab, die die Auswirkungen ihrer Durchsetzung spüren. Als IT-Mitarbeiter oder Entwickler einer Communitywebsite können Sie Tools erstellen, die bei der Durchsetzung der Regeln helfen, aber bisweilen ist das beste Tool für diese Aufgabe etwas, das aus Ihrem Innern kommt oder auf die Menschlichkeit aller Stammesmitglieder zurückzuführen ist. Anstelle reiner Technik kann ein wenig Social Engineering wirksamer sein. In diesem Fall unter Mitwirkung eines Fischs.

Betsy Aoki ist Community Program Manager für Microsoft im Xbox-Team. Ihre leichten Neurosen finden starken Ausdruck in ihren E-Mails, Blogbeiträgen und hoffentlich im XNA Framework.


 Windows Confidential: Das Dateisystemparadox
Windows Confidential
Das Dateisystemparadox
Raymond Chen

Wenn Sie sich Ihre Festplatte ansehen, werden Sie wahrscheinlich bemerken, dass sich eine stattliche Anzahl von Betriebssystemdateien im Stammverzeichnis des Startlaufwerks befindet. Wenn Sie sich die Dateien näher ansehen, dürfte Ihnen eine Gemeinsamkeit auffallen: boot.ini, ntldr und ntdetect.com sind kritische Startdateien, und hiberfil.sys ist die Ruhezustanddatei. Dies sind alles Dateien, die an den entscheidenden ersten Phasen beteiligt sind, in denen das Betriebssystem gestartet oder, im Fall von hiberfil. sys, der Ruhezustand beendet wird. Diese Dateien müssen sich im Stammverzeichnis des Startlaufwerks befinden. Weshalb können sie nicht an einen anderen Ort verschoben werden?
Mein Kollege Adrian Oney hat dies folgendermaßen erklärt: Um die Startdateien vom Datenträger zu lesen, wird der Dateisystemtreiber benötigt. Dieser befindet sich jedoch auf dem Datenträger, den Sie nicht lesen können, bis Sie den Dateisystemtreiber geladen haben. Eine paradoxe Situation!
Der Teufelskreis wird dadurch unterbrochen, dass ein Miniaturdateisystemtreiber in die kritischen Startdateien integriert wird. Dieser Miniaturtreiber weiß gerade genug, um die Dateien im Stammverzeichnis zu finden und sie in den Speicher zu laden. Diese Dateien wiederum können das Betriebssystem starten. An diesem Punkt kann der tatsächliche Dateisystemtreiber übernehmen und die Dateien an Orten wie Unterverzeichnissen suchen.
Der Ruhezustand folgt einem ähnlichen Muster. Der Ruhezustand eines Betriebssystems bedeutet, dass der gesamte Inhalt des Speichers in die Ruhezustanddatei geleert wird. Das Wiederherstellen aus dem Ruhezustand führt dazu, dass diese Datei wieder in den Speicher befördert wird, als ob nichts geschehen sei. Wiederum ein paradoxes Problem: Um die Ruhezustanddatei zu laden, benötigen Sie den Dateisystemtreiber, doch der Dateisystemtreiber befindet sich in der Ruhezustanddatei. Wenn Sie die Ruhezustanddatei im Stammverzeichnis des Startlaufwerks belassen, kann stattdessen der Miniaturdateisystemtreiber verwendet werden.
Diejenigen, die frühere Versionen von MS-DOS® verwendet haben, sind sich dieser Einschränkung für den Speicherort der Betriebssystemstartdateien sehr bewusst. Der alte SYS-Befehl hat eine langweilige alte Diskette in eine magische Startdiskette verwandelt. Wenn er jedoch auf einer Diskette ausgeführt wurde, die bereits Daten enthielt, hat die Konvertierung mit großer Wahrscheinlichkeit versagt, weil bei den frühen MS-DOS-Versionen die Startdateien bestimmte Orte auf der Diskette besetzen mussten, damit sie vom Bootsektor gefunden werden konnten. In späteren Versionen von MS-DOS wurden diese Anforderungen durch Verbesserungen am Startladeprogramm gelockert, doch auch bei der verbesserten Version müssen sich die Systemdateien nach wie vor im Stammverzeichnis befinden.
Eine Kundenfrage lautete: „Kann ich die Ruhezustanddatei in ein Unterverzeichnis verschieben?“ Warum ist es eigentlich so wichtig, wo sich die Datei befindet? Die ACLs auf der Datei wären die gleichen, unabhängig davon, wo sie sich befindet. Doch diese Leute wollten sie auf einem Laufwerk speichern, das sich vom Startlaufwerk unterscheidet, und erhielten die Antwort, dass dies nicht möglich sei. Der Grund für diese Einschränkung war ihnen nicht verständlich, also versuchten sie es mit einer List: „Gut, wenn ich sie zumindest in ein Unterverzeichnis verschieben kann, dann kann ich ein Verzeichnis erstellen und dort eine Verknüpfung erstellen, die auf den Ort zeigt, an dem ich die Ruhezustanddatei haben möchte.“ Woo hoo—I relocated the hibernation file!
Selbstverständlich versteht der Miniaturdateisystemtreiber Bereitstellungspunkte nicht, weil Bereitstellungspunkte eine Kommunikation mit dem Datenträgerverwaltungsdienst bedeuten. Wenn das System gerade startet, hat der Computer noch nicht einmal das Betriebssystem geladen, geschweige denn einen erweiterten Dienst, der weiß, wie die Laufwerksbuchstaben wieder ARC-Pfaden zugeordnet werden. Selbst wenn Sie diesen Dienst irgendwie zum Laufen bringen, müssen Sie immer noch die Treiber für die anderen Festplatten finden und die entsprechenden Dateisystemtreiber laden.
Es ist nur eine Frage der Zeit, bis jemand fragt, wie die Ruhezustanddatei auf eine DFS-Verknüpfung verschoben werden kann.

Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch (Addison-Wesley, 2007) mit der Geschichte von Windows und mit der Win32-Programmierung. Sein Web 2.0-Name ist Raymond oder vielleicht Chester.