 TechNet Magazine December 2007

TechNet Magazine December 2007

Kommunikation: 16 neue Features in Exchange Server 2007 Service Pack 1

Im Gegensatz zum typischen Service Pack stellt Exchange Server 2007 Service Pack 1 viel mehr als nur Hotfixes und Sicherheitsupdates bereit. Dieser Artikel gibt einen Überblick über einige der wichtigsten neuen Features und Funktionen von SP1.

Tony Smith Kommunikation: Fortlaufende Standbyreplikation in Exchange Server 2007 Service Pack 1

Eines der interessantesten Features von Service Pack 1 ist die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR). Finden Sie heraus, wie SCR Ihnen helfen kann, Ausfallzeiten zu verringern, Datenverluste einzuschränken und das Verwalten und Aufbewahren von E-Mail zu vereinfachen.

Scott Schnoll Kommunikation: Ausführen von Exchange mit Windows Server 2008

Bereiten Sie sich gerade auf die Ausführung von Exchange unter Windows Server 2008 vor? Das Microsoft Exchange-Entwicklungsteam ist seit einer Weile damit beschäftigt, und Paul Bowden teilt mit Ihnen einige Ratschläge und Erfahrungen, um Ihnen bei der Vorbereitung zu helfen.

Paul Bowden Kommunikation: Bereitstellen von Unified Messaging mit Exchange Server 2007

Die Kombination von Voicemail, Faxfunktionen und E-Mail-Messaging in einem einzigen Postfach mag als unüberwindliches Hindernis erscheinen. Es ist jedoch einfacher als Sie denken. Dies ist eine Anleitung zur Bereitstellung von Unified Messaging in Ihrem Unternehmen.

Jeff Goodwin Sicherheit: Handbuch zu den Grundlagen der Computerforensik

Lernen Sie einfache und kostengünstige Verfahren der Computerforensik kennen, die Administratoren für grundlegende Untersuchungen verwenden können.

Tom Cloward and Frank Simorjay Netzwerk: Der Microsoft Security Intelligence Report

Microsoft sammelt viele Daten zu Sicherheitsbedrohungen, denen Computerbenutzer ausgesetzt sind. Dieser Bericht bietet einen Überblick über neue Trends, die Leistung verschiedener Windows-Versionen, die weltweit am meisten betroffenen Regionen und mehr.

Tim Rains Netzwerk: Aufspüren schwer fassbarer Netzwerkprobleme

Ihr Computer kommuniziert ohne offensichtlichen Grund nicht mit anderen Computern. Diese Tipps können Ihnen helfen, das Problem schnell zu analysieren und zu reparieren.

Christopher Stoneff Mitteilung der Redaktion: Kommen wir ins Gespräch

Joshua Hoffman Briefe: Leser sagen ihre Meinung

Toolbox: Neue Produkte für IT-Experten

Greg Steen SQL – Fragen und Antworten: Speicherkonfiguration, Leistungsprofilerstellung, Einstellen des Füllfaktors und mehr

Edited by Nancy Michell Schwerpunkt Dienstprogramme: Das Microsoft Security Assessment Tool

Dieses kostenlose Dienstprogramm mit elektronischem Fragebogen kann mittelständischen Organisationen beim Identifizieren und Beheben von Netzwerksicherheitsrisiken helfen.

Lance Whitney The Cable Guy: Netzwerkrichtlinienserver

Der Netzwerkrichtlinienserver (Network Policy Server, NPS) in Windows Server 2008 ersetzt den in Windows Server 2003 verwendeten Internetauthentifizierungsdienst und führt zahlreiche Verbesserungen ein, angefangen bei der Möglichkeit, Systemintegritätsanforderungen zu erzwingen, bis hin zu verbesserter Verwaltungsfähigkeit.

Joseph Davies Windows PowerShell: Ein tieferer Einblick

Windows PowerShell stellt viele Features bereit, die oft übersehen werden. Mithilfe eines methodischen Ansatzes beim Untersuchen der Windows PowerShell-Cmdlets werden Sie einige leistungsfähige Funktionen entdecken, die Sie bisher noch nicht bemerkt haben.

Don Jones Hey, Scripting Guy!: Die Rückkehr von WinRM

War der Butler womöglich der Täter? Geschah die Tat in der Speisekammer mit dem Kerzenhalter? Keine dieser Fragen wird hier beantwortet. Nach vier langen Wochen sind die Scripting Guys nun mit Teil 2 ihrer zweiteiligen Reihe zu WinRM zurück.

The Microsoft Scripting Guys Sicherheit auf dem Prüfstand: Kennwortrichtlinien für die Windows-Domäne

Bislang ließ Windows nur eine einzige Kennwortrichtlinie pro Domäne zu. Unter Windows Server 2008 können Administratoren jedoch mehrere Kennwortrichtlinien implementieren und die jeweiligen Richtlinien an verschiedene Arten von Benutzern anpassen.

Derek Melber Die Desktopdateien: Bereitstellen von Windows in einer virtuellen Welt

Ist die Virtualisierung für Sie ein Thema? Falls nicht, sollte sich das ändern. Erfahren Sie, was Sie zur Bereitstellung virtueller Systeme wissen müssen, welche Fehler zu vermeiden sind und wie die Virtualisierung im Detail funktioniert.

Wes Miller Berichte aus der Praxis: Die fungible Zukunft

IT wird durch die Verschmelzung von Technologie und Sichtweise im Privatleben mit denen im Arbeitsleben immer stärker verkommerzialisiert und auf den Endverbraucher ausgerichtet. Diese Entwicklung wirkt sich erheblich auf das Arbeits- und das Privatleben aus.

Romi Mahajan Windows Confidential: Ein Joystick muss keine Mikrowelle sein

In diesem Artikel wird betrachtet, auf welche Weise die DirectInput-Schnittstelle für Joysticks mit Kraftrückmeldung periodische Kräfte angibt – und es wird auf einige unerwartete Ergebnisse eingegangen.

Raymond Chen


 Kommunikation: 16&#160;neue Features in Exchange Server&#160;2007 Service Pack&#160;1
Kommunikation Tony Smith

16 neue Features in Exchange Server 2007 Service Pack 1
Kurz zusammengefasst:
  • Neue Verwaltungsfeatures
  • Verbesserte Serverfunktionen
  • Verbessertes Unified Messaging

Die meisten Administratoren sind vertraut mit dem Herunterladen und Installieren von Service Packs für Server und Desktopsysteme. Diese Downloads stellen Hotfixes und Sicherheitsupdates bereit,
die Ihre Systeme auf dem neuesten Stand halten. Doch manchmal enthält ein Service Pack noch mehr. Dies ist der Fall bei der bevorstehenden Veröffentlichung von Microsoft® Exchange Server 2007 Service Pack 1, das viele interessante neue Features aufweist.
Dieser Download wird unter go.microsoft.com/fwlink/?LinkId=91472 zur Verfügung stehen und kann zur Durchführung einer vollständigen Installation von Exchange Server 2007 (mit allen SP1-Updates) und zum Aktualisieren vorhandener Installationen von Exchange Server 2007 verwendet werden. Exchange Server 2007 SP1 kann auf Windows Server® 2003 SP1, SP2 und R2 installiert werden, ist aber auch mit der zukünftigen Veröffentlichung von Windows Server 2008 kompatibel.
Service Pack 1 führt mehr neue Features und Verbesserungen ein als in dieser kurzen Übersicht behandelt werden können. Daher wurde stattdessen eine Liste mit Beschreibungen der bemerkenswertesten Änderungen zusammengestellt, die Sie zur Verbesserung Ihrer Exchange-Umgebung nutzen können. Ausführliche Informationen finden Sie im Artikel „Neuerungen in Exchange Server 2007 SP1“ unter technet.microsoft.com/bb676323.aspx.

Änderungen an der Exchange-Verwaltungskonsole
Service Pack 1 erweitert die in Abbildung 1 dargestellte Exchange-Verwaltungskonsole mit einigen praktischen neuen Features. Zunächst einmal gibt es die Toolbox, die eine Sammlung von standardmäßig mit Exchange Server 2007 installierten Tools zur Diagnose, Problembehandlung und Wiederherstellung bereitstellt und nun die Verwaltungskonsole für öffentliche Ordner, einen Detailvorlageneditor und die Routingprotokollanzeige umfasst.
Abbildung 1 Exchange-Verwaltungskonsole mit Service Pack 1
Abbildung 1 Exchange-Verwaltungskonsole mit Service Pack 1
Sie können die Exchange-Verwaltungskonsole, die Verwaltungskonsole für öffentliche Ordner, den Detailvorlageneditor und die Warteschlangenanzeige zum Exportieren von Listen aus dem Ergebnis- und Arbeitsbereich verwenden. Listen können als Text (tabulatorgetrennt), Text (kommagetrennt), Unicode-Text (tabulatorgetrennt) und Unicode-Text (kommagetrennt) exportiert werden. Der Ergebnisbereich kann jetzt nicht nur in der Exchange-Verwaltungskonsole gefiltert werden, sondern auch in der Verwaltungskonsole für öffentliche Ordner, dem Detailvorlageneditor und der Warteschlangenanzeige.
Am wichtigsten ist jedoch, dass die Exchange-Verwaltungskonsole eine Reihe neuer Verwaltungsschnittstellen umfasst (beispielsweise die bereits erwähnte Verwaltungskonsole für öffentliche Ordner). Hierauf wird noch an anderer Stelle in diesem Artikel eingegangen.

Unterstützung für IPv6
Mit der Unterstützung von Windows Server 2008 geht die Unterstützung von IPv6 (Internetprotokoll Version 6) einher. Dafür ist natürlich die Installation von Exchange Server 2007 auf Windows Server 2008 sowie die Aktivierung der IPv4- und IPv6-Protokollstacks erforderlich. Wenn Sie IPv4 vor der Installation deaktivieren, wird IPv6 nicht von Exchange unterstützt.
Sie können IP-Adressen und -Bereiche sowohl im IPv4- als auch im IPv6-Format eingeben. Alle Serverfunktionen mit Ausnahme von einer können Daten an Geräte, Server und Clients senden, die IPv6-Adressen verwenden und Daten von ihnen empfangen. Die UnifiedMessaging-Serverfunktion bildet die Ausnahme. Das liegt daran, dass aufgrund von Einschränkungen bei einigen erforderlichen Telefonie- und Sprachkomponenten IPv4 für die UnifiedMessaging-Funktion erforderlich ist.

POP3- und IMAP4-Administratoroberfläche
Die Exchange-Verwaltungskonsole umfasst eine neue Verwaltungsoberfläche zum Verwalten von POP3 und IMAP4. Hier können Sie alle POP3- und IMAP4-Einstellungen für Ihren Clientzugriffsserver einschließlich Port-, Authentifizierungs- und Verbindungseinstellungen konfigurieren. Abbildung 2 zeigt den Konfigurationsdialog für IMAP4-Eigenschaften. Dieselben Optionen sind für POP3 verfügbar.
Abbildung 2 Exchange-Verwaltungskonsole für POP3/IMAP4
Abbildung 2 Exchange-Verwaltungskonsole für POP3/IMAP4

Stabilere Postfachverwaltung
Die Features der Postfachverwaltung in der Exchange-Verwaltungskonsole unterstützen jetzt die Massenerstellung von Postfächern für vorhandene Benutzerkonten. Neue Assistenten ermöglichen es Administratoren zudem, vollständige Zugriffsrechte für ein Postfach zu gewähren oder zu entfernen und die Berechtigungen „Senden als“ für ein Postfach zu konfigurieren.

Neue Features zum Verwalten von Postfachdaten
Administratoren können jetzt .pst-Dateien zum Verwalten von Postfachdaten importieren und exportieren. Dies kann auch in der Exchange-Verwaltungsshell mithilfe der Import-Mailbox- bzw. Export-Mailbox-Cmdlets erfolgen.
Verwalten der Messagingdatensätze (Messaging Records Management, MRM) kann auf verwaltete Standardordner angewendet werden, die auf einem Exchange-Server mit Exchange-Standardclientzugriffslizenz vorhanden sind. (Beachten Sie, dass für MRM für verwaltete benutzerdefinierte Ordner nach wie vor eine Exchange Enterprise-Clientzugriffslizenz erforderlich ist.) Der neue RemoveManagedFolderAndPolicy-Parameter für das Set-Mailbox-Cmdlet entfernt MRM-Richtlinien aus einem Postfach und MRM-Eigenschaften aus verwalteten Ordnern, die als Teil der auf das Postfach angewendeten MRM-Richtlinie erstellt wurden, und konvertiert verwaltete Ordner in Standardordner.
Mithilfe neuer Systemmonitorzähler können Sie verschiedene Onlinedefragmentierungsinformationen überwachen, d. h. wann die Onlinedefragmentierung zuletzt ausgeführt wurde, wie lange dies gedauert hat und was dabei durchgeführt wurde. Diese Informationen sind für die Optimierung des Onlinedefragmentierungsintervalls praktisch.

Bestätigen von Remotezurücksetzungen
Exchange Server 2007 ermöglicht es Administratoren oder Kontobenutzern bereits, einen Remotezurücksetzungsbefehl zum Löschen aller Benutzerdaten auf einem mobilen Gerät auszugeben – ein praktisches Sicherheitsfeature, wenn ein Gerät verloren geht oder gestohlen wird. Bei Service Pack 1 wird eine Bestätigungsnachricht gesendet, wenn das Gerät die Remotezurücksetzungsanforderung bestätigt. Wenn die Anforderung (über Outlook® Web Access, OWA) vom Benutzer ausgeht, erhält dieser eine Bestätigungs-E-Mail. Wenn die Anforderung (über die Exchange-Verwaltungskonsole) vom Administrator ausgeht, erhält sowohl der Administrator als auch der Benutzer eine Bestätigungs-E-Mail.

Ein stabilerer OWA-Client
Durch viele Verbesserungen im webbasierten E-Mail-Client wird ein besseres Messaging für mobile Arbeitskräfte bereitgestellt. Mit SP1 können OWA-Benutzer sowohl persönliche Verteilerlisten als auch serverseitige Regeln erstellen und bearbeiten. Zudem können Benutzer die Features zum Löschen und Wiederherstellen gelöschter Elemente verwenden.
Die Benutzeroberfläche wurde durch Befehle zum Verschieben und Kopieren erweitert, sodass Benutzer Ordner über das mit der rechten Maustaste in der Ordnerliste verfügbare Menü verschieben und kopieren können. Einzelne Elemente in Nachrichtenordnern und öffentlichen Ordnern können ebenfalls durch Klicken mit der rechten Maustaste in der Elementliste oder Klicken auf ein Symbol in der Symbolleiste verschoben und kopiert werden.
OWA-Benutzer haben zudem vollständigen Zugriff auf öffentliche Ordner, ohne das virtuelle /public-Verzeichnis zu verwenden (außerdem ist kein Exchange 2003-Back-End-Server erforderlich, um dies zu unterstützen). Suchfunktionen für öffentliche Ordner werden in OWA ebenfalls unterstützt.
S/MIME-Funktionen ermöglichen es Benutzern jetzt, signierte und verschlüsselte E-Mail-Nachrichten zu lesen und zu verfassen (siehe Abbildung 3). Auch CNG-Unterstützung (Cryptografy API: Next Generation) und Suite-B-Kompatibilität sind vorhanden. Die OWA-Benutzeroberfläche kann zudem zur nahtlosen Integrierung benutzerdefinierter Anwendungen angepasst werden.
Abbildung 3 S/MIME-Nachrichteneinstellungen
Abbildung 3 S/MIME-Nachrichteneinstellungen

Erstellungsüberwachung in OWA Light
Outlook Web Access Light (eine weniger komplexe OWA-Version, die mit fast allen Webbrowsern funktioniert) überwacht nun die Aktivität beim Erstellen eines langen Eintrags jeglicher Art (beispielsweise einer Nachricht oder eines Kalendereintrags) durch den Benutzer, um sicherzustellen, dass die Sitzung das Zeitlimit nicht überschreitet, während der Benutzer noch Eingaben vornimmt (was zu einem Datenverlust führen würde). Außerdem werden Nachrichten automatisch im Ordner „Entwürfe“ gespeichert, wenn das Zeitlimit der Sitzung aufgrund von Inaktivität überschritten wird, während das Formular zum Erstellen der Nachricht geöffnet ist.

Verbesserte Direct Push-Leistung
Direct Push stellt eine HTTPS-Verbindung zwischen einem mobilen Gerät und dem Exchange 2007-Server her. Bei Exchange 2007 SP1 wurde die Größe der Header für die HTTPS-Anforderung und -Antwort reduziert, sodass die an ein mobiles Gerät gesendete und die von ihm empfangene Datenmenge verringert wird.

Verwaltung öffentlicher Ordner
Die neue, in Abbildung 4 dargestellte Verwaltungskonsole für öffentliche Ordner ermöglicht Administratoren das Erstellen, Konfigurieren und Verwalten öffentlicher Ordner von der Exchange-Verwaltungskonsole aus. Adresslisten, E-Mail-Adressrichtlinien, dynamische Verteilergruppen und Verteilerlisten unterstützen öffentliche Ordner. Bei der Vorschau auf eine Adressliste, eine E-Mail-Adressrichtlinie, eine dynamische Verteilergruppe und Verteilergruppenempfänger können Sie sich die E-Mail-aktivierten öffentlichen Ordner anzeigen lassen, die in den Gruppenmitgliedschaftskriterien enthalten sind.
Abbildung 4 Verwaltungskonsole für öffentliche Ordner
Abbildung 4 Verwaltungskonsole für öffentliche Ordner
Mithilfe der Verwaltungskonsole für öffentliche Ordner in Exchange 2007 SP1 können Sie Administratorrechte für öffentliche Ordner konfigurieren. Dies erfolgt mithilfe des Add-ExchangeAdministrator-Cmdlets oder des Add Exchange Administrator-Assistenten zum Hinzufügen eines Benutzers zur Administratorrolle für öffentliche Ordner oder mithilfe des Add-PublicFolderAdministratorPermission-Cmdlets zum Gewähren oder Verweigern bestimmter Rechte für öffentliche Ordner.

Verbesserte Nachrichtenverarbeitung und Routing
Hub-Transport-Server, die in der Active Directory®-Gesamtstruktur bereitgestellt werden, behandeln den gesamten E-Mail-Verkehr innerhalb der Organisation, wenden Transport- und Journalregeln an und senden Nachrichten an die Postfächer der Empfänger. An das Internet gesendete Nachrichten werden vom Hub-Transport-Server zum Edge-Transport-Server im Umkreisnetzwerk übertragen. SP1 umfasst Verbesserungen für diese Serverfunktionen.
Exchange Server 2007 umfasst ein Feature zur Systemressourcenüberwachung namens „Back Pressure“, das es Hub- und Edge-Transport-Servern ermöglicht, auf hohe Ressourcenverwendung zu reagieren. Mit SP1 wurde die Anforderung an freien Speicherplatz von 4 GB auf 500 MB beträchtlich verringert.
Die Exchange-Verwaltungskonsole in SP1 bietet mehr Transportkonfigurationseinstellungen. Zudem besteht nun die Möglichkeit, einen X.400-Adressraum als verbindliche Domäne zu konfigurieren (lange X.400-Adressen werden jetzt ebenfalls unterstützt).
Der Hub-Transport-Server unterstützt Prioritätenwarteschlangen. Das Kategorisierungsmodul berücksichtigt die Nachrichtenpriorität, die einer Nachricht von einem Outlook-Benutzer zugewiesen wird, sodass Nachrichten von hoher Wichtigkeit tatsächlich vorrangig behandelt und schneller gesendet werden als Nachrichten von niedriger Wichtigkeit.
In Exchange 2007 SP1 wird die Begrenzung eines Sendeconnectors auf einen einzelnen Active Directory-Standort durch das Hinzufügen des IsScopedConnector-Parameters in Exchange-Verwaltungsshell-Cmdlets und das Kontrollkästchen „Scoped Send Connector“ (begrenzter Sendeconnector) in der Exchange-Verwaltungskonsole vereinfacht. Wenn ein Sendeconnector begrenzt wird, berücksichtigen nur die Hub-Transport-Server, die sich am selben Active Directory-Standort wie die Quellserver des Sendeconnectors befinden, diesen Sendeconnector bei Routingentscheidungen.

Verbesserungen bei der Edge-Transport-Serversynchronisierung
In Exchange Server 2007 SP1 können Sie das Start-EdgeSynchronization-Cmdlet verwenden, um sofort mit der Synchronisierung von Daten aus dem Active Directory im Verzeichnisdienst Active Directory-Anwendungsmodus (ADAM) zu beginnen. In Exchange 2007 SP1 unterstützt dieses Cmdlet den Serverparameter, sodass das Cmdlet von einem Remotecomputer aus ausgeführt werden kann.
Das Test-EdgeSynchronization-Cmdlet, ein Diagnose-Cmdlet, das den Synchronisierungsstatus der Edge-Transport-Server meldet, wurde durch einen neuen Parametersatz erweitert, mit dem Synchronisierungsergebnisse für einzelne Benutzer überprüft werden können.

Klonen des TransportConfig-Objekts
Geklonte Konfigurationsskripts erleichtern Administratoren die Aufgabe, eine konsistente Konfiguration zu installieren, wenn mehr als ein Edge-Transport-Server in der Umgebung bereitgestellt wird. In SP1 ist das TransportConfig-Objekt, das die serverweiten Einstellungen für die Edge-Transport-Serverfunktion steuert, jetzt in den geklonten Konfigurationsinformationen enthalten. Die Einbeziehung dieses Objekts optimiert die Verfahren zur Serverbereitstellung, Sicherung und Wiederherstellung erheblich.

Verbesserungen bei Unified Messaging
Unified Messaging war ein hochinteressanter Bestandteil der ursprünglichen Exchange Server 2007-Veröffentlichung. Service Pack 1 baut auf dieser Funktionalität auf und führt viele neue Features und Verbesserungen ein. Für einige Features muss Office Communications Server 2007 in derselben Active Directory-Gesamtstruktur bereitgestellt werden, doch es gibt viele Features, für die Office Communications Server nicht erforderlich ist. An dieser Stelle können nicht alle Änderungen in Unified Messaging erläutert werden, doch es sollen zumindest die bemerkenswertesten neuen Features erwähnt werden. Wenn Sie mehr über Unified Messaging lesen wollen, finden Sie im Artikel „Bereitstellen von Unified Messaging mit Exchange Server 2007“ in dieser Ausgabe des TechNet Magazins weitere Informationen.
Zuerst einige neue Features, für die Office Communications Server 2007 erforderlich ist. Mediendatenströme zum Durchlaufen von Firewalls und für High-Fidelity-Sprachnachrichten werden nun unterstützt. Es erfolgt eine Benachrichtigung über eine Weiterleitung, wenn Sprachnachrichten hinterlassen werden und der Zielort die Anrufweiterleitung verwendet. Benutzer können ohne Eingabe einer PIN von Office Communicator 2007 aus auf Outlook Voice Access zugreifen. Bei Office Communicator 2007 werden E-Mail-Nachrichten zur Benachrichtigung bei verpassten Anrufen und Voicemailbenachrichtigungen integriert (siehe Abbildung 5). Dies ist noch längst nicht alles.
Abbildung 5 Voicemailbenachrichtigung in Office Communicator
Abbildung 5 Voicemailbenachrichtigung in Office Communicator
Eine der Verbesserungen bei Unified Messaging, für die Office Communications Server nicht erforderlich ist, besteht in der Unterstützung des Secure Realtime Transport Protocol (SRTP). Die erste Version von Exchange Server 2007 bietet zwei Sicherheitsmodi: ungesichert und gesichert. Der gesicherte Modus verschlüsselt nur den SIP-Datenverkehr (Session Initiation-Protokoll). Der RTP-Datenverkehr ist unverschlüsselt. In SP1 gibt es drei Modi: ungesichert, SIP-gesichert und gesichert. Im gesicherten SIP-Modus wird nur der SIP-Datenverkehr verschlüsselt, aber nicht der RTP-Datenverkehr. Im gesicherten Modus werden sowohl der SIP- als auch der RTP-Datenverkehr verschlüsselt. Sie können für Wählpläne, die die Exchange-Verwaltungskonsole verwenden, auch MTLS (Mutual Transport Layer Security) konfigurieren.
Weitere Änderungen umfassen den neuen Assistenten zum Aktivieren von Unified Messaging, den Sie zum Hinzufügen einer SIP- oder E.164-Adresse für einen Benutzer verwenden können, und die Konfiguration des URI-Typs für einen Wählplan, der die Exchange-Verwaltungskonsole verwendet. Außerdem wurde Dienstqualitätsunterstützung (Quality of Service, QoS) hinzugefügt, die DiffServ zum Kennzeichnen des Mediendatenverkehrs verwendet.

Bessere hohe Verfügbarkeit
Mit Service Pack 1 werden mehrere neue Features zur Verbesserung hoher Verfügbarkeit sowie Verbesserungen vorhandener Verfügbarkeitsfeatures eingeführt. Die neuen und verbesserten Features erweitern die Szenarios, in denen Sie Daten- und Dienstverfügbarkeit für Ihre Exchange 2007-Serverfunktionen erzielen können. Mithilfe der neuen Szenarios können Organisationen Hochverfügbarkeitsszenarios von Standortsicherheitsszenarios trennen und Konfigurationen bereitstellen, die auf bestimmte Anforderungen der Organisation in jedem einzelnen Bereich zugeschnitten sind.
Zunächst einmal ermöglicht zusätzliche Unterstützung für Windows Server 2008 Failovercluster für mehrere Subnetze und Unterstützung für neue Quorummodelle (Datenträger- und Dateifreigabezeuge). Außerdem gibt es sehr nützliche Verbesserungen bei der Clusterberichterstattung und den Überwachungsfunktionen einschließlich zusätzlicher Funktionalität, die für proaktive Überwachung von Umgebungen mit fortlaufender Replikation ausgelegt ist. Leistungsbezogene Verbesserungen umfassen eine Reduzierung von E/A-Vorgängen auf den Datenträgern, die passive Kopien von Speichergruppen enthalten, schnelleres Kopieren von Protokolldateien sowie schnelleres Verschieben von Postfachclusterservern zwischen Knoten.
Schließlich wurden neue Assistenten zum Verbessern der Verwaltungs- und Konfigurationsfunktionalität hinzugefügt (siehe Abbildung 6), und zum Verwalten von Postfachclusterservern wurden neue Steuerelemente für die Benutzeroberfläche hinzugefügt, so unter anderem eine neue Registerkarte für Postfachclusterserver und eine Konfigurationsseite für die fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR).
Abbildung 6 Assistent zum Verwalten von Postfachclusterservern
Abbildung 6 Assistent zum Verwalten von Postfachclusterservern

Fortlaufende Standbyreplikation
Die fortlaufende Standbyreplikation (Standby Continuous Replication, SCR) verwendet dieselbe Protokollversand- und Wiedergabetechnologie, die von der fortlaufenden lokalen Replikation (Local Continuous Replication, LCR) und CCR zum Bereitstellen zusätzlicher Bereitstellungsoptionen und -konfigurationen verwendet wird. SCR ähnelt LCR und CCR, hat jedoch eindeutige eigene Kennzeichen. Der Artikel „SCR in Exchange Server 2007“ von Scott Schnoll in dieser Ausgabe des TechNet Magazins enthält eingehendere Betrachtungen zu SCR.

Zusammenfassung
Exchange Server 2007 Service Pack 1 enthält sehr viel mehr als nur Hotfixes und Sicherheitsupdates. Es bietet viele neue Features und Verbesserungen, auf die Sie bald vertrauen werden. Dieser Artikel bietet nicht genug Platz, um alle neuen Features und Verbesserungen zu erörtern, vermittelt aber hoffentlich einen guten Überblick über die verfügbaren Funktionen. Vollständige Informationen über alle Änderungen in Service Pack 1 sowie Downloads, Webcasts und Diskussionsforen finden Sie im Exchange Server TechCenter unter technet.microsoft.com/exchange.

Tony Smith ist leitender technischer Autor für das Exchange-Benutzerschulungsteam. Er hat sich auf Unified Messaging spezialisiert. Vor der Aufnahme seiner Tätigkeit bei Microsoft war Tony als Netzwerktechniker, Microsoft-Anbieter und Microsoft-zertifizierter Trainer tätig. Zudem hat er an mehreren Projekten für Microsoft Learning einschließlich Büchern und Testumgebungshandbüchern mitgewirkt.
© 2007 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


 Kommunikation: Fortlaufende Standbyreplikation in Exchange Server&#160;2007 Service Pack&#160;1
Kommunikation Scott Schnoll

Fortlaufende Standbyreplikation in Exchange Server 2007 Service Pack 1
Kurz zusammengefasst:
  • Konfigurieren der fortlaufenden Standbyreplikation
  • Die Bedeutung von Redundanz
  • Wie SCR Ausfallzeiten verringert

Service Pack 1 stellt mehrere neue Features und Verbesserungen für Exchange 2007 bereit. Eines dieser neuen Features, SCR (Standby Continuous Replication), dient dem Zweck, Organisationen sowohl Redundanz im Datencenter als auch Standortsicherheit bereitzustellen. Wie der Name bereits erkennen lässt, wurde SCR für
Szenarios entwickelt, in denen Standbywiederherstellungsserver verwendet werden oder die Verwendung solcher Server ermöglicht wurde.
Wenn Sie mit der Produktionsfreigabeversion (Release to Manufacturing, RTM) von Exchange 2007 vertraut sind, dann wissen Sie, dass diese Version über Protokollversandfeatures ebenfalls Redundanz im Datencenter und Standortsicherheit bietet und Windows®-Failovercluster unterstützt. In der RTM-Version steht Protokollversand (offiziell als „fortlaufende Replikation“ bezeichnet) in zwei Formen zur Verfügung: als fortlaufende lokale Replikation (Local Continuous Replication, LCR, siehe Abbildung 1) und als fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR, siehe Abbildung 2).
Abbildung 1 LCR (Local Continuous Replication)
Abbildung 1 LCR (Local Continuous Replication)
Abbildung 2 Bei CCR findet der Protokollversand zu einem zweiten Server in einem Windows-Failovercluster statt
Abbildung 2 Bei CCR findet der Protokollversand zu einem zweiten Server in einem Windows-Failovercluster statt
Fortlaufende Replikation stellt Datenverfügbarkeit und Redundanz bereit, indem Administratoren ermöglicht wird, online ein Zweitexemplar jeder Postfachdatenbank zu aktivieren und zu verwalten. Diese Datenbankkopie bildet die erste Verteidigungslinie gegen Ausfall, Verlust oder Beschädigung einer Produktionsdatenbank. Statt Zeit auf die Suche eines Datensicherungsbands zur Wiederherstellung der Daten zu verschwenden, kann innerhalb weniger Minuten eine Datenbankkopie aktiviert und in eine Produktionsdatenbank verwandelt werden.
SCR erweitert die Szenarios, in denen Sie für Ihre Organisation die Verfügbarkeit von Daten und Diensten erreichen können. Die neuen Szenarios ermöglichen Ihnen, Topologien mit hoher Verfügbarkeit von Topologien mit Standortsicherheit zu trennen, und erlauben Ihnen zugleich, Konfigurationen bereitzustellen, die auf die spezifischen Anforderungen Ihrer Organisation in jedem Bereich zugeschnitten sind.
Die RTM-Version von Exchange 2007 stellt Redundanz im Datencenter und Standortsicherheit bereit, aber da LCR und CCR nur eine einzige zusätzliche Kopie jeder Datenbank bereitstellen, müssen Sie zwischen Standortsicherheit und Redundanz wählen. Bedenken Sie beispielsweise die von CCR bereitgestellten Möglichkeiten der Daten- und Dienstverfügbarkeit. In einem einzelnen Datencenter sowohl den aktiven als auch den passiven Knoten einzusetzen, liefert zwar Dienst- und Datenverfügbarkeit im Datencenter, aber keine Standortsicherheit (weil sich beide Knoten am selben physischen Standort befinden). Den aktiven Knoten in einem Datencenter und den passiven Knoten in einem zweiten Datencenter einzusetzen, bietet Ihnen zwar Standortsicherheit, aber keine Verfügbarkeit im Datencenter (weil sich der passive Knoten, der diese Features bereitstellt, in einem zweiten Datencenter befindet).
Da Sie mit SCR in Service Pack 1 zusätzliche Kopien jeder Datenbank erstellen können, schließen sich hohe Verfügbarkeit und Standortsicherheit nicht mehr gegenseitig aus. Sie können beispielsweise, wie in Abbildung 3 gezeigt, SCR mit CCR kombinieren, um Speichergruppen lokal in einem primären Datencenter zu replizieren (durch CCR, um hohe Verfügbarkeit zu erreichen) und um sie von einem Remotestandort aus in einem zweiten Datencenter oder einem Backupdatencenter zu replizieren (durch SCR, um Standortsicherheit zu erreichen). Das zweite Datencenter enthält einen Standbycluster, der in einem Standortwiederherstellungsszenario mit einem Ersatzpostfachclusterserver aktiviert und schnell bereitgestellt werden kann.
Abbildung 3 Ein Datencenter in Redmond nutzt CCR und ein Datencenter in Quincy nutzt SCR
Abbildung 3 Ein Datencenter in Redmond nutzt CCR und ein Datencenter in Quincy nutzt SCR
Abbildung 3 zeigt eine Unternehmensbereitstellung mit zwei Datencentern mit jeweils eigenem Active Directory®-Standort: Redmond und Quincy. Der Standort in Redmond befindet sich im primären Datencenter (Produktionsdatencenter) und der Standort in Quincy in einem zweiten Datencenter (Backupdatencenter). In Redmond wird CCR genutzt, um Redundanz im Datencenter zu erzielen. Zusammen mit den für Exchange 2007 benötigten Infrastrukturelementen werden auf einem Standbycluster in Quincy SCR-Ziele konfiguriert, um Standortsicherheit zu erreichen. Diese zusätzlichen Infrastrukturelemente, zu denen Clientzugriffs- und Hub-Transport-Server, Active Directory- und DNS-Server sowie Internetzugang gehören, können dedizierte oder nicht dedizierte Ressourcen sein. Dedizierte Ressourcen sind dazu bestimmt, nur die Benutzer des Datencenters zu unterstützen, in dem sie sich befinden. Nicht dedizierte Ressourcen dagegen unterstützen sowohl Benutzer im lokalen Datencenter als auch Benutzer an anderen Standorten. Sie müssen abhängig von den Gegebenheiten in Ihrer Organisation entscheiden, ob Ressourcen dediziert oder nicht dediziert sein sollen. Weitere Informationen zu dedizierten und nicht dedizierten Ressourcen finden Sie in der Hilfedatei von Exchange Server 2007 unter technet.microsoft.com/bb201662.aspx unter dem Thema „Standortsicherheitskonfigurationen“. Beachten Sie auch, dass ein neues MNS (Majority Node Set)-Quorum verwendet wird. Wie Sie in Abbildung 3 sehen können, verwendet CCR in Exchange Server 2007 statt des herkömmlichen Voterknotens das MNS-Quorum mit Dateifreigabenzeuge (File Share Witness, FSW).
In Abbildung 4 stellt eine Umgebung mit CCR und SCR, die für Stabilität eingerichtet wurde, für die Postfächer und die auf dem Server „EXCLUS1“ gehosteten Dienste mehrere Schichten von Redundanz bereit und schützt dadurch diese Postfächer vor kleinen bis großen katastrophalen Ausfällen.
Abbildung 4 Eigenständige Postfachserver, die zum gegenseitigen Replizieren von Speichergruppen SCR verwenden
Abbildung 4 Eigenständige Postfachserver, die zum gegenseitigen Replizieren von Speichergruppen SCR verwenden
Kleine und mittlere Organisationen können ebenfalls von SCR profitieren. Wie in Abbildung 4 gezeigt, kann eine Organisation beispielsweise zwei eigenständige Postfachserver („EXMBX1“ und „EXMBX2“) einsetzen und SCR dazu verwenden, einige oder alle Speichergruppen von einem Postfachserver zum nächsten zu replizieren.
In diesem Beispiel handelt es sich sowohl bei „EXMBX1“ als auch bei „EXMBX2“ um Produktionsserver mit fünf aktiven Speichergruppen. Jede Speichergruppe ist eine SCR-Quelle für ein entsprechendes SCR-Ziel auf dem anderen Server. Beim Eintreten eines Speicherausfalls oder eines anderen Ereignisses, das dazu führt, dass eine als SCR-Quelle konfigurierte aktive Speichergruppe nicht verfügbar ist, kann die SCR-Zielkopie mit wenigen administrativen Aufgaben in der Exchange-Verwaltungsshell schnell aktiviert werden. Mit Microsoft® Office Outlook® 2007 und der Datenbankportabilität sowie dem AutoErmittlungsdienst in Exchange 2007 kann bei einem Verlust einer aktiven Speichergruppe (oder mehrerer aktiver Speichergruppen) die Ausfallzeit auf wenige Minuten begrenzt werden.

SCR-Quellen und -Ziele
Genau wie LCR und CCR arbeitet auch SCR nach dem Konzept aktiver und passiver Kopien einer Speichergruppe, die im Kontext von SCR aber als SCR-Quellen bzw. SCR-Ziele bezeichnet werden. Trotzdem sind SCR-Quellen und SCR-Ziele nichts anderes als Speichergruppenkopien. (Speichergruppen für die Wiederherstellung können bei SCR nicht aktiviert werden.)
SCR verwendet als Ausgangspunkt (SCR-Quelle) eine beliebige Speichergruppe auf einem eigenständigen Postfachserver oder Postfachclusterserver in einer Einzelkopieclusterumgebung (CCR-Umgebung). Dabei ist Folgendes zu beachten: Die SCR-Quelle kann zwar ein Postfachclusterserver sein, aber SCR selbst ist keine Clusterlösung und benötigt nicht den Windows-Clusterdienst. Der Endpunkt für SCR (SCR-Ziel) kann entweder ein eigenständiger Postfachserver oder ein Knoten in einem Failovercluster sein, auf dem die Funktion „Mailbox“ installiert, aber kein Postfachclusterserver im Cluster konfiguriert wurde.

Beziehungen zwischen Quelle und Ziel
Jede SCR-Quellspeichergruppe kann eine unbegrenzte Anzahl von SCR-Zielen besitzen. Beispielsweise könnte eine Quelle ein Ziel im gleichen Datencenter und ein zweites Ziel in einem separaten Datencenter besitzen. Von Microsoft wird jedoch empfohlen, nie mehr als vier Ziele pro Quelle zu verwenden. Falls Sie beschließen, mehr als vier Ziele zu verwenden, müssen Sie abschätzen, welche Auswirkungen dies möglicherweise im Hinblick auf Speicherbedarf, CPU-Auslastung und Datenträgerressourcen des SCR-Quellservers hat, und dies bei der Planung entsprechend berücksichtigen. Jeder SCR-Zielcomputer kann mehrere Quellserver besitzen. Sowohl auf dem Quellcomputer als auch auf dem Zielcomputer muss Service Pack 1 für Exchange 2007 ausgeführt werden. Es muss ein Betriebssystem verwendet werden, das von Service Pack 1 für Exchange 2007 unterstützt wird (z. B. Windows Server® 2008 oder Windows Server 2003 SP2). SCR kann jedoch unabhängig vom verwendeten Betriebssystem nicht betriebssystemübergreifend arbeiten, sondern erfordert, dass auf der SCR-Quelle das gleiche Betriebssystem wie auf allen SCR-Zielen für diese Quelle verwendet wird. Wenn auf der SCR-Quelle beispielsweise Windows Server 2003 ausgeführt wird, muss daher auf allen SCR-Zielen für diese Quelle ebenfalls Windows Server 2003 ausgeführt werden.
SCR ist in der Standard Edition von Exchange 2007 verfügbar. Wenn als SCR-Quelle ein Postfachclusterserver in einer SCC- oder CCR-Umgebung verwendet wird, ist die Enterprise Edition von Exchange 2007 erforderlich. Jedes SCR-Ziel unterstützt bei Verwendung der Enterprise Edition maximal 50 Instanzen (50 replizierte Speichergruppen) und bei Verwendung der Standard Edition maximal 5 Instanzen.
Bei SCR-Zielen sind ebenfalls bestimmte Anforderungen zu erfüllen. Erstens müssen der Quellcomputer und der Zielcomputer in der gleichen Active Directory-Domäne sein, sie dürfen sich aber an unterschiedlichen Active Directory-Standorten befinden. Zweitens müssen die Datenbank- und Protokolldateipfade auf der Quelle und auf allen Zielen dieser Quelle bei jeder Speichergruppe, die mit SCR repliziert wird, identisch sein. Drittens können Sie, wenn ein Knoten oder ein Server als SCR-Ziel konfiguriert wird, für keine Speichergruppe auf dem SCR-Zielcomputer LCR aktivieren und dem Standbyfailovercluster keine Postfachclusterserver hinzufügen.

Vergleich von SCR mit CCR und LCR
Wie in Abbildung 5 zu sehen ist, verwendet SCR das gleiche Protokollversand- und Wiedergabeverfahren wie LCR und CCR, um neue Bereitstellungsoptionen und Konfigurationen bereitzustellen. Genau wie bei LCR und CCR dürfen SCR-fähige Speichergruppen nicht mehr als eine einzige Datenbank enthalten. Darüber hinaus kann SCR nicht für eine Öffentliche Ordner-Datenbank verwendet werden, wenn in der Exchange-Organisation mehr als eine Öffentliche Ordner-Datenbank vorhanden ist.
Abbildung 5 SCR führt einen Protokollversand zu einem anderen Server oder einem passiven Knoten in einem Failovercluster durch
Abbildung 5 SCR führt einen Protokollversand zu einem anderen Server oder einem passiven Knoten in einem Failovercluster durch
Ein wichtiger Unterschied bei SCR besteht darin, dass SCR mehrere Ziele pro Speichergruppe unterstützt, während LCR und CCR nur ein einziges Ziel (die passive Kopie) unterstützen. Ein weiterer wichtiger Unterschied liegt darin, dass es im Gegensatz zu CCR und LCR nicht möglich ist, eine Sicherungskopie einer SCR-Kopie zu erstellen. Bei der Verwendung von SCR werden die Datenbankheader für SCR-Ziele aktualisiert und die Protokolldateien abgeschnitten, wenn unterstützte Sicherungen anhand der SCR-Quellspeichergruppe durchgeführt werden (oder wenn im Fall von CCR und LCR Sicherungen anhand der aktiven oder passiven Kopie der SCR-Quellspeichergruppe durchgeführt werden).
Genau wie bei LCR und CCR erfolgt der Protokollversand bei SCR fortlaufend und nach einem Pullmodell. Sobald eine neue Protokolldatei geschlossen und ihr unter Verwendung der nächsten sequenziellen Protokolldateizahl ein Name zugewiesen wurde, überträgt der auf dem SCR-Zielcomputer ausgeführte Microsoft Exchange-Replikationsdienst die geschlossenen Transaktionsprotokolldateien mittels Pull vom SCR-Quellcomputer, überprüft sie, wertet sie aus und verschiebt sie dann in den entsprechenden Ordner für Speichergruppenprotokolldateien auf dem SCR-Zielcomputer.

Wiedergabeverzögerungszeit
Nach dem Kopieren der Protokolldateien auf den SCR-Zielcomputer erfolgt bei SCR etwas, das bei LCR und CCR nicht passiert. Statt sofort die Protokolldateien in der Kopie der Datenbank wiederzugeben, setzt SCR eine integrierte Wiedergabeverzögerung von 50 Protokolldateien und 24 Stunden durch. SCR erlaubt Ihnen dazu, außer der integrierten Verzögerung eine zusätzliche zeitliche Verzögerung festzulegen. Es kann in verschiedenen Szenarios nützlich sein, die Wiedergabeaktivität zu verzögern. Beispielsweise könnte eine Verzögerung im Fall einer logischen Beschädigung einer aktiven Datenbank die logische Beschädigung der SCR-Zieldatenbank verhindern.
Die vom Administrator gesteuerte Wiedergabeverzögerung wird mithilfe eines Parameters namens „ReplayLagTime“ eingestellt, mit dem festgelegt wird, wie lange der Exchange-Replikationsdienst warten soll, bevor Protokolldateien wiedergegeben werden, die auf den SCR-Zielcomputer kopiert wurden. Die Verzögerungszeit wird im Format Tage.Stunden:Minuten:Sekunden festgelegt, und die Standardeinstellung beträgt 24 Stunden. Die maximal zulässige Einstellung für diesen Wert beträgt sieben Tage. Die zulässige Minimaleinstellung liegt bei Null Sekunden. Die Einstellung dieses Minimalwerts hat zur Folge, dass jegliche Verzögerung der Protokollwiedergabeaktivität, die auf die Standardverzögerung von 50 Protokolldateien folgt, deaktiviert wird.
Zusätzlich zu „ReplayLagTime“ besitzt Exchange unabhängig von dem für „ReplayLagTime“ eingestellten Wert eine integrierte, hartcodierte Verzögerung von 50 Protokolldateien. Um festzulegen, wann eine Protokolldatei wiedergegeben werden soll, verwendet Exchange die jeweils größere Verzögerungszeit, die durch „ReplayLagTime“ oder die Standardeinstellung von x Protokolldateien (x=50) festgelegt wird. Dies ist eine zusätzliche Sicherheitsvorkehrung gegen die Notwendigkeit, eine Speichergruppe durch Seeding erneut einrichten zu müssen, falls bei einer SCR-Quelle, die eine fortlaufende Replikation verwendet (z. B. ein Postfachclusterserver in einer CCR-Umgebung), ein Failover eintritt und eine oder mehrere Speichergruppen mithilfe des Cmdlets „Reset-StorageGroupCopy“ online geschaltet werden müssen. (Seeding bezeichnet den Prozess, die ESE (Extensible Storage Engine)-Streaming-Backup-APIs zu verwenden, um eine Onlinekopie der SCR-Quelldatenbank auf dem SCR-Zielcomputer anzufertigen.) Durch das Verzögern der Wiedergabeaktivität auf den SCR-Zielen beim Eintreten eines verlustbehafteten Failovers einer SCR-Quelle wird die Wahrscheinlichkeit gesenkt, dass die SCR-Kopien durch Seeding neu eingerichtet werden müssen, weil die Art des Datenverlusts auf der SCR-Quelle die beiden Kopien zeitlich näher zusammenrückt.

Abschneideverzögerungszeit
In der RTM-Version von Exchange 2007 werden in einer Umgebung mit fortlaufender Replikation Regeln durchgesetzt, damit eine Protokolldatei nur dann gelöscht wird, wenn sie gesichert und in der Kopie der Datenbank wiedergegeben wurde. Bei der Verwendung von SCR wird diese Regel geändert. Die SCR, die das Konzept mehrerer Datenbankkopien einführt, erlaubt es, dass Protokolldateien auf dem SCR-Quellcomputer abgeschnitten werden, sobald sie von allen SCR-Zielcomputern geprüft wurden. Mit dem Abschneiden der Protokolldateien auf dem SCR-Quellserver wird nicht gewartet, bis alle Protokolle in allen SCR-Zielen wiedergegeben wurden, weil SCR-Zielkopien mit langen Protokollwiedergabeverzögerungszeiten konfiguriert werden können.
Sie können für das Abschneiden der Protokolldateien auch eine zusätzliche Verzögerung hinzufügen, indem Sie einen neuen Parameter namens „TruncationLagTime“ verwenden, mit dem im Format „Tage.Stunden:Minuten:Sekunden“ festgelegt wird, wie lange der Exchange-Replikationsdienst warten soll, bevor Protokolldateien, die auf den SCR-Zielcomputer kopiert und in der Kopie der Datenbank wiedergegeben wurden, abgeschnitten werden. Die Zeitspanne beginnt, sobald die Protokolldateien erfolgreich in der Kopie der Datenbank wiedergegeben wurden. Die maximal zulässige Einstellung für diesen Wert beträgt sieben Tage, und die zulässige Minimaleinstellung liegt bei Null Sekunden. Allerdings bewirkt die Einstellung von Null Sekunden, dass jegliche Verzögerung des Abschneidens der Protokolldateien deaktiviert wird.
In einer SCR-Umgebung wird alle drei Minuten ein Hintergrundthread ausgeführt, um zu ermitteln, ob Protokolldateien abgeschnitten werden müssen. Wenn die Sequenz der Protokolldateigenerierung unter dem Protokolldateikontrollpunkt für die Speichergruppe liegt und die Protokolldatei älter als die Summe der Werte von „ReplayLagTime“ und „TruncationLagTime“ ist, wird eine Protokolldatei auf dem SCR-Ziel abgeschnitten.
In einer mit SCR erweiterten LCR- oder CCR-Umgebung wird eine Protokolldatei auf dem SCR-Ziel abgeschnitten, wenn die folgenden vier Kriterien erfüllt sind: Die Protokolldatei wurde gesichert, die Sequenz der Protokolldateigenerierung liegt unter dem Protokolldateikontrollpunkt für die Speichergruppe, die passive Kopie der Speichergruppe ist in einem Zustand, der es erlaubt, die Protokolldatei abzuschneiden, und alle SCR-Ziele haben die Protokolldatei geprüft.

Aktivieren und Verwalten von SCR
SCR wird mithilfe des Cmdlets „Enable-StorageGroupCopy“ in der Exchange-Verwaltungsshell aktiviert, das in SP1 mit einigen neuen Parametern aktualisiert wurde. Wie oben beschrieben können Sie mithilfe von „ReplayLagTime“ und „TruncationLagTime“ das Verhalten von SCR-Zielen teilweise steuern. Mit einem weiteren Parameter namens „SeedingPostponed“ kann das anfängliche Seeding des SCR-Ziels übersprungen werden. Das Seeding zu verschieben, kann in verschiedenen Situationen nützlich sein. Nehmen Sie beispielsweise einmal an, die Datenbank in der Speichergruppe, die für SCR aktiviert wird, hat eine Größe von 100 GB. Sie wollen vermeiden, dass in Zeiten maximaler Produktion 100 GB an Daten im Netzwerk übertragen werden. Mithilfe des Parameters „SeedingPostponed“ können Sie SCR sofort aktivieren und zu einem späteren Zeitpunkt einen Seeding-Task ausführen. Auf Wunsch können Sie mithilfe des Cmdlets „Update-StorageGroupCopy“ ein manuelles Seeding des SCR-Ziels durchführen.
Während die oben genannten Parameter optional sind, gibt es einen Parameter von „Enable-StorageGroupCopy“, der für SCR obligatorisch ist: „StandbyMachine“. Mit diesem Parameter wird der Name des Computers angegeben, der das SCR-Ziel enthält. Der Wert dieses Parameters wird als Bestandteil des Werts für das Attribut „msExchStandbyCopyMachines“ der Speichergruppe festgelegt, die für SCR aktiviert wird. Das Attribut „msExchStandbyCopyMachines“ ist eine Unicode-Zeichenfolge mit mehreren Werten, die dem Active Directory-Schema hinzugefügt wird, wenn Exchange 2007 SP1 in die Exchange-Organisation eingeführt wird. Dies ist einer der Gründe, warum SP1 eine Schemaaktualisierung für Active Directory erforderlich macht.
Der Parameter „StandbyMachine“ ist für SCR von zentraler Bedeutung, und in SP1 wurden mehrere Cmdlets aktualisiert, damit dieser Parameter für das Aktivieren und Verwalten von SCR-Zielen verwendet wird. Die aktualisierten Cmdlets werden in Abbildung 6 beschrieben.
Figure 6 Cmdlets, die den Parameter „StandbyMachine“ verwenden (Close Figure 6)

Cmdlet | Beschreibung
Disable-StorageGroupCopy | Deaktiviert ein SCR-Ziel für eine Speichergruppe.
Get-StorageGroupCopyStatus | Ermittelt die aktuelle Integrität des SCR-Ziels.
New-StorageGroup | Erstellt eine neue SCR-fähige Speichergruppe, ohne dass SCR separat mithilfe des Cmdlets „Enable-StorageGroupCopy“ aktiviert werden muss.
Restore-StorageGroupCopy | Deaktiviert SCR und bereitet mithilfe eines „Mount-Database“-Vorgangs, der Bestandteil eines Wiederherstellungsverfahrens ist, eine SCR-Zieldatenbank auf die Bereitstellung vor.
Resume-StorageGroupCopy | Dient zur Wiederaufnahme einer fortlaufenden Replikation bei einer Speichergruppe, bei der SCR angehalten wurde.
Suspend-StorageGroupCopy | Hält bei einer Speichergruppe, die für SCR aktiviert wurde, die fortlaufende Replikationsaktivität an.
Update-StorageGroupCopy | Dient zum Einrichten (Seeding) oder erneuten Einrichten (Reseeding) einer SCR-Zielspeichergruppe.

Aktivieren von SCR-Zielen
SCR stellt eine oder mehrere aktuelle Kopien der Daten bereit, die verwendet werden können, falls die Originaldaten verloren gehen oder unbrauchbar werden sollten. Der Prozess, eine SCR-Zielkopie als neue Produktionsdatenbank bereitzustellen, wird als „Aktivierung“ bezeichnet. Die Aktivierung findet als Teil des Wiederherstellungsprozesses statt, der die Form einer Datenbankportabilität oder einer der zwei Wiederherstellungsoptionen („/m:RecoverServer“ zur Wiederherstellung eines eigenständigen Servers oder „/RecoverCMS“ zur Wiederherstellung eines Postfachclusterservers) annehmen kann.

Wie SCR verwendet werden kann
Im Folgenden wird aufgezeigt, wie ein fiktives Unternehmen SCR und Datenbankportabilität zur Wiederherstellung nach einem Ausfall einer Postfachdatenbank verwenden könnte. Sobald erkannt wird, dass die Produktionsdatenbank beschädigt ist, aktiviert der Administrator mithilfe von Datenbankportabilität die SCR-Zieldatenbank.
Die Organisation hat Exchange 2007 mit SP1 installiert und beschlossen, SCR zu nutzen, um auf einem entfernten Postfachserver eine Kopie einer Speichergruppe bereitzustellen. Sowohl der Quellpostfachserver als auch der Zielpostfachserver befinden sich am selben Active Directory-Standort und wurden dafür konfiguriert, mit Active Directory integrierte DNS-Server zu verwenden. Das Active Directory-Replikationsintervall wurde auf 15 Minuten gesetzt.

Aktivieren von SCR und Bereitstellen der Wiederherstellung
SCR wird so konfiguriert, dass Transaktionsprotokolldateien für eine einzige Speichergruppe (SG1) repliziert werden, in der eine einzige Datenbank (MBX1) enthalten ist. Die Pfade für die Speichergruppendateien und die Datenbankdatei lauten „C:\SG1“ und „C:\SG1\MBX1.EDB“. In diesem Fall ist „EXMBX1“ die SCR-Quelle und „EXMBX2“ das SCR-Ziel. Dies wurde folgendermaßen konfiguriert:
Enable-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
Nach Aktivieren von SCR wurden die Integrität und der Status von SCR für „SG1“ mit dem Cmdlet „Get-StorageGroupCopyStatus“ überprüft:
Get-StorageGroupCopyStatus EXMBX1\SG1
-StandbyMachine EXMBX2
Um beim Prozess der Aktivierung des SCR-Ziels Zeit zu sparen, wird „EXMBX2“ mit einer Speichergruppe namens „SG1PORT“ und einer Datenbank namens „MBX1PORT“ vorkonfiguriert, die bei den Datenbankportabilitätsvorgängen verwendet werden. „SG1PORT“ und „MBX1PORT“ sind von der Speichergruppe und den Datenbankdateien des SCR-Ziels getrennt. Daher werden die Pfade für „SG1PORT“ und „MBX1PORT“ mit einem temporären Pfad konfiguriert, der keinen Konflikt mit den SCR-Zielpfaden hervorruft. „SG1PORT“ und „MBX1PORT“ werden nur als Datenbankportabilitätsobjekte verwendet. Die eigentliche Speichergruppe und die Datenbankdateien für „SG1PORT“ werden nicht benötigt. Darum hebt der Administrator die Bereitstellung von „MBX1PORT“ auf und löscht alle in der Speichergruppe enthaltenen Dateien. Die Speichergruppe und die Datenbankobjekte bleiben in Active Directory, weil sie später während des Wiederherstellungsprozesses zur Datenbankportabilität verwendet werden.

Aktivierung und Wiederherstellung
Ein Anwendungsereignisprotokolleintrag zeigt an, dass die SCR-Quelldatenbank physisch beschädigt ist. Da SCR für „SG1“ aktiviert wurde, wird entschieden, für „SG1“ eine manuelle Aktivierung der SCR-Zieldatenbank durchzuführen und Datenbankportabilität zu verwenden, um Datenverfügbarkeit wiederherzustellen. Die Aktivierung der SCR-Zielkopie beginnt damit, dass mit dem folgenden Cmdlet die Bereitstellung von „MBX1“ in „SG1“ aufgehoben wird:
Dismount-Database EXMBX1\SG1\MBX1
Danach wird die SCR-Zieldatenbank auf die Bereitstellung vorbereitet, und die Postfächer, die sich ursprünglich auf „MBX1“ befanden, werden auf „MBX1PORT“ verlagert.
Der Prozess zum Deaktivieren von SCR und zum Vorbereiten der SCR-Zieldatenbank auf die Bereitstellung umfasst das Ausführen des Cmdlets „Restore-StorageGroupCopy“. Dieser Task kennzeichnet die Datenbank der Speichergruppe als bereitstellbar und erstellt einen Bericht zum Datenverlust, der durch die Bereitstellung der Datenbank an die Speichergruppe entstehen könnte. Darüber hinaus überprüft der Task, ob am Dateispeicherort der Speichergruppe der passiven Kopie alle Protokolldateien vorhanden sind, die von der aktiven Kopie der Speichergruppe generiert werden. Falls Protokolldateien fehlen, versucht der Prozess, auch diese Dateien zu kopieren. Mit dem folgenden Cmdlet wird die SCR-Zieldatenbank auf die Bereitstellung vorbereitet:
Restore-StorageGroupCopy EXMBX1\SG1
-StandbyMachine EXMBX2
In diesem Beispiel stehen die Protokolldateien aus der SCR-Quellspeichergruppe zum Kopieren zur Verfügung. Wenn diese Dateien nicht verfügbar sind (z. B. weil der SCR-Quellcomputer ausgeschaltet ist), muss der Parameter „Force“ dem Task „Restore-StorageGroupCopy“ hinzugefügt werden. Wenn dies nicht erfolgt, versucht „Restore-StorageGroupCopy“ in jedem Fall eine Verbindung zur SCR-Quelle herzustellen, um fehlende Protokolldateien zu kopieren, und wenn die SCR-Quelle nicht verfügbar ist, schlägt der Task „Restore-StorageGroupCopy“ fehl, und die Datenbank wird nicht auf die Bereitstellung vorbereitet. Durch Hinzufügen des Parameters „Force“ wird dem Task „Restore-StorageGroupCopy“ mitgeteilt, dass die Quelldateien nicht verfügbar sind. In diesem Fall wird der Verbindungsversuch unterlassen und damit fortgefahren, die SCR-Zieldatenbank auf die Bereitstellung vorzubereiten.
Sobald der Befehl „Restore-StorageGroupCopy“ abgeschlossen ist, muss der Administrator überprüfen, ob sich die Datenbank in einem fehlerfreien Shutdown-Status befindet. Wenn sich die Datenbank in einem fehlerhaften Shutdown-Status befindet (siehe technet.microsoft.com/aa996757.aspx), muss sie in einen fehlerfreien Shutdown-Status versetzt werden. Wenn das Protokolldateipräfix für die Speichergruppe (z. B. „E00“ oder „E01“) bei der SCR-Quelle (EXMBX1\SG1) und der Speichergruppe auf dem SCR-Ziel (SG1PORT), das für die Datenbankportabilität verwendet wird (EXMBX2\SG1PORT), identisch ist, ist es nicht erforderlich, „Eseutil“ im Wiederherstellungsmodus auszuführen. In diesem Fall wird die Datenbank durch den abschließenden Datenbankbereitstellungsvorgang in einen fehlerfreien Shutdown-Status versetzt, nachdem alle replizierten Protokolldateien wiedergegeben wurden. Wenn sich die Datenbank nicht in einem fehlerfreien Shutdown-Status befindet, müssen an der Datenbank Exchange Server-Datenbankdienstprogramme (Eseutil) im Wiederherstellungsmodus (Eseutil /r) ausgeführt werden.
Sobald sich die Datenbank in einem fehlerfreien Shutdown-Status befindet, können Sie zwei Befehle ausführen, die Active Directory mit neuen Speicherorten für die Speichergruppendateien und die Datenbankdatei aktualisieren. Diese Befehle ändern die Pfade für „SG1PORT“ und „MBX1“ von ihren ursprünglichen Pfaden in die Pfade für die bereitgestellte Speichergruppe und die Datenbank („SG1PORT“ und „MBX1PORT“):
Move-StorageGroupPath EXMBX2\SG1PORT
-SystemFolderPath C:\SG1 -LogFolderPath C:\SG1 –ConfigurationOnly

Move-DatabasePath EXMBX2\SG1PORT\MBX1PORT
-EdbFilePath C:\SG1\MBX1PORT.EDB
–ConfigurationOnly
Bei den oben genannten Befehlen muss der Parameter „–ConfigurationOnly“ verwendet werden, damit in Active Directory nur die Konfigurationseinstellungen für diese Objekte aktualisiert werden. Es werden keine Daten oder Dateien verschoben. Dies ist auch nicht erforderlich, denn SCR hat die Daten bereits in „C:\SG1“ auf „EXMBX2“ repliziert.
Im nächsten Schritt wird die Datenbank (MBX1PORT) dafür konfiguriert, während eines Wiederherstellungsvorgangs ihre eigene Überschreibung zuzulassen. Dies erfolgt durch Auswahl des Kontrollkästchens für die Einstellung „Diese Datenbank kann bei einer Wiederherstellung überschrieben werden“ in der Exchange-Verwaltungskonsole in den Datenbankobjekteigenschaften oder durch Verwendung des folgenden Befehls in der Exchange-Verwaltungsshell:
Set-MailboxDatabase EXMBX2\SG1PORT\MBX1PORT
-AllowFileRestore:$true
Wenn die Datenbank dafür konfiguriert wurde, ihre eigene Überschreibung zuzulassen, muss die Datenbank als Nächstes mit dem folgenden Befehl bereitgestellt werden:
Mount-Database EXMBX2\SG1PORT\MBX1PORT
Sobald die Datenbank bereitgestellt wurde, müssen die Postfächer, die sich in der SCR-Quelldatenbank (SG1\MBX1) befanden, verlagert werden, damit sie auf „MBX1PORT“ auf „EXMBX2“ verweisen. Führen Sie einfach das Cmdlet „Get-Mailbox“ aus, und leiten Sie die Ausgabe zum Cmdlet „Move-Mailbox“. Während dieses Vorgangs ist es wichtig, dass die Exchange-Systemaufsicht und die Exchange-Systempostfächer nicht in der Ausgabe des Cmdlets „Get-Mailbox“ enthalten sind, die zum Cmdlet „Move-Mailbox“ geleitet wird. Diese Postfachobjekte müssen und sollen nicht verlagert werden. Es wird der folgende Befehl ausgeführt, um alle Benutzerpostfächer zu verlagern und Systempostfächer auszuschließen:
Get-Mailbox -Database EXMBX1\SG1\MBX1 |where {$_.ObjectClass -NotMatch '(SystemAttendantMailbox|
ExOleDbSystemMailbox)'}| Move-Mailbox -ConfigurationOnly
-TargetDatabase EXMBX2\SG1PORT\MBX1PORT
Jetzt ist Clientzugriff auf „MBX1PORT“ möglich. Ob Benutzer tatsächlich auf ihre Postfächer zugreifen können, nachdem sie von „EXMBX1\SG1\MBX1“ auf „EXMBX2\SG1PORT\MBX1PORT“ verschoben wurden, hängt jedoch von der Active Directory-Replikationswartezeit ab. Das heißt, abhängig von der Anzahl der Verzeichnisserver kann es einige Zeit dauern, bis sich die Aktualisierung in der Umgebung verbreitet hat. Darüber hinaus spielen auch die Clientzugriffsmethoden eine Rolle. Wenn die Verzeichnisserver, die vom Clientzugriffsserver des Benutzers verwendet werden, mit den neuen Pfaden aktualisiert wurden, haben sowohl Messaging-Clients, auf denen Outlook 2007 ausgeführt wird, als auch Clients, auf denen Outlook nicht ausgeführt wird, Zugriff auf das Postfach des Benutzers. Bei Messaging-Clients, auf denen Outlook 2003 und ältere Versionen ausgeführt werden, muss das Desktopmessagingprofil des Benutzers mit dem neuen Servernamen aktualisiert werden.

Abschließende Schritte
Sobald Clients Zugriff auf ihre Postfächer und ihre Postfachdaten haben, muss zum Schluss durch Aktivieren von SCR Redundanz eingerichtet werden. Dies wird erreicht, indem alle übrigen Speichergruppen- und Datenbankdateien aus „EXMBX1“ entfernt werden. Nach Entfernen der Dateien können die Pfade für „EXMBX1\SG1\MBX1“ in einen temporären Speicherort verschoben, und es kann „EXMBX1“ als SCR-Ziel von „EXMBX2“ verwendet werden.

Scott Schnoll ist Technischer Chefredakteur im Exchange Server-Team von Microsoft und schreibt Inhalte für Exchange Server 2007. Vor der Aufnahme seiner Tätigkeit bei Microsoft verfasste er das Buch „Exchange Server 2003 Distilled“ (Addison-Wesley Professional, 2004) und trug als Hauptautor zu „Exchange 2000 Server: The Complete Reference“ (McGraw-Hill/OsborneMedia, 2001) bei.


 Kommunikation: Ausf&#252;hren von Exchange mit Windows Server&#160;2008
Kommunikation Paul Bowden

Ausführen von Exchange mit Windows Server 2008
Kurz zusammengefasst:
  • Einrichten von Exchange unter Windows Server 2008
  • Tipps und Tricks zur Konfiguration
  • Lernen Sie Ihre Exchange-Umgebung kennen

Im Exchange-Entwicklungsteam von Microsoft besteht meine Aufgabe darin, den Zeitplan, den Arbeitsrhythmus und die Priorität für das Team festzulegen. Bei Microsoft wird meine Rolle als Versionsmanager bezeichnet. Sie lässt sich ungefähr mit einem technischen Projektmanager in anderen Unternehmen vergleichen. Wie jeder weiß, der bereits
in dieser Position gearbeitet hat, erfordert die pünktliche Bereitstellung eines guten Produkts Wissen, Können, harte Arbeit und den Respekt des Teams. Wenn Sie mit einem so erfahrenen und talentierten Team zusammenarbeiten, erreichen Sie diese Glaubwürdigkeit nicht über Nacht, sondern müssen sie sich verdienen.
Eine Möglichkeit, sich Anerkennung zu verschaffen, besteht darin, Ihr Postfach auf einem „Dogfood“-Server auszuführen – einem Produktionsserver mit einer Vorabversion von Exchange. Dabei handelt es sich um eine fließende Umgebung, die alle zwei oder drei Wochen auf neue Exchange-Builds aktualisiert wird. Dieses Setup ermöglicht es uns, die Software in einer realen Umgebung mit echten menschlichen Interaktionen zu testen. Wir führen sogar unsere Postfächer auf den neuesten Testbuilds aus. In diesem Artikel möchte ich meine Erfahrungen dabei mit Ihnen teilen.

Vorbereitung auf „Longhorn“
Ende 2006, als wir gerade Exchange Server 2007 ausgeliefert hatten, zeichnete sich ein neues Betriebssystem am Horizont ab – Windows Server® mit dem Codenamen „Longhorn“. Als wir mit der Zusammenstellung von Plänen für das erste Service Pack für die neue Exchange-Plattform begannen, wurde offensichtlich, dass die Zeitpläne für Exchange und Windows® ähnlich waren und dass „Longhorn“ (jetzt als Windows Server 2008 bezeichnet) eine große Sache war. An diesem Punkt entschieden wir, Exchange Server 2007 SP1 sowohl für Windows Server 2003 als auch für Windows Server 2008 zu entwickeln. Die Unterstützung einer Unternehmensanwendung unter mehreren Versionen von Windows erfordert beträchtlichen Koordinations- und Planungsaufwand. So arbeitet Exchange beispielsweise eng mit IIS zusammen, und Windows Server 2008 enthält eine neue Version, IIS 7.0.
Ich habe Windows Server 2008 Ende Dezember 2006 zum ersten Mal in meiner Testumgebung installiert. Zwei Dinge sind mir von diesem Tag im Gedächtnis geblieben: Zum einen, dass die Installation sehr schnell ablief, und zum anderen, dass die Verwendung der Verwaltungstools so intuitiv verständlich war, obwohl es starke Unterschiede zu Windows Server 2003 gab.
In unseren Haupttestumgebungen lässt sich Windows Server 2008 in ca. einem Drittel der Zeit installieren, die für eine Installation von Windows Server 2003 benötigt wird. Einer der Gründe hierfür liegt darin, dass optionale Komponenten, die für die Ausführung des Betriebssystems nicht unbedingt erforderlich sind, standardmäßig nicht konfiguriert sind. Dies ist nützlich, um die Angriffsfläche des Computers zu verkleinern und die Dinge so einfach wie möglich zu halten. Niemand mag es, wenn die Dinge unnötig kompliziert werden. Der typische Nachteil einer solchen Installation bestand bisher darin, dass Sie jedes Mal den Datenträger einlegen mussten, wenn Sie zusätzliche Komponenten hinzufügen wollten. Bei Windows Server 2008 werden jedoch alle Dateien in einen SxS-Ordner („Side-by-Side“ ausgesprochen) kopiert. Sie verwenden dann das Server-Manager-Tool zum Konfigurieren der erforderlichen Komponenten, und das Betriebssystem übernimmt das Kopieren der Dateien.
An dieser Stelle sollte etwas erwähnt werden, das als „Server Core“ bezeichnet wird. Hierbei handelt es sich um einen Modus von Windows Server 2008, in dem nur der absolut erforderliche Mindestumfang an Betriebssystemkomponenten installiert wird. In diesem Modus interagieren Sie in der Regel über eine Eingabeaufforderung mit der Serverkonsole, nicht einmal Explorer wird installiert. Dieser Modus eignet sich gut für Infrastrukturserver wie Domänencontroller und DNS-Server. Sie können jedoch nicht jede Art von Anwendung in diesem Modus ausführen. Exchange zeichnet sich durch die umfangreiche Verwendung von verwaltetem Code aus, wodurch die Unterstützung von Server Core-Installationen ausgeschlossen ist.

Einrichten von Exchange
Nur allzu gern führe ich mithilfe der physischen Windows Server 2008- und Exchange Server 2007 SP1-Medien eine komplette Neuinstallation auf einem Computer ohne weitere Downloads oder Voraussetzungen durch. Die beste Methode, um eine Windows Server 2008-Installation für Exchange zu konfigurieren, besteht in der Verwendung des Tools „ServerManagerCmd“. Ich habe eine XML-Antwortdatei erstellt (in Abbildung 1 dargestellt), durch die gerade genug Betriebssystemkomponenten installiert werden, um die Installation und Ausführung von Exchange unter Windows Server 2008 zu ermöglichen. Nach der Installation des neuen Betriebssystems wird einfach der folgende Befehl ausgeführt, um das System einzurichten:
Figure 1 ServerManagerCmd-Antwortdatei für Exchange (Close Figure 1)
<!-- ServerManagerCmd Answer File compatible with Windows Server 2008        -->
<!-- Usage: ServerManagerCmd -ip Exchange.xml                                -->

<ServerManagerConfiguration
    Action="Install"
    xmlns="http://schemas.microsoft.com/sdm/Windows/ServerManager/Configuration/2007/1">

    <!-- BASE: Install PowerShell 1.0 feature -->
    <Feature Id="PowerShell"/>

    <!-- PREPARESCHEMA: Install LDIFDE and other directory tools like LDP and ADSIEdit -->
    <Feature Id="RSAT-ADDS"/>

    <!-- CAS/MBX: Install the Web Server role with additional child components -->
    <Role Id="Web-Server"/>
    <RoleService Id="Web-Metabase"/>
    <RoleService Id="Web-Lgcy-Mgmt-Console"/>
    <RoleService Id="Web-Basic-Auth"/>
    <RoleService Id="Web-Windows-Auth"/>

    <!-- CAS: Install the three authentication types for OWA, GZip compression, plus Outlook Anywhere support -->
    <RoleService Id="Web-ISAPI-Ext"/>
    <RoleService Id="Web-Digest-Auth"/>
    <RoleService Id="Web-Dyn-Compression"/>
    <Feature Id="RPC-over-HTTP-proxy"/>

    <!-- EDGE: Install Active Directory Lightweight Directory Services (previously known as ADAM) -->
    <Role Id="ADLDS"/>

    <!-- UM: Install the Windows Media Player components -->
    <Feature Id="Desktop-Experience"/>

</ServerManagerConfiguration>

ServerManagerCmd –ip Exchange.xml
Wenn dieser Vorgang abgeschlossen ist und Sie das System neu gestartet haben, verfügen Sie über alle Voraussetzungen, um Exchange-Serverfunktionen wie Mailbox, ClientAccess, Hub-Transport, Edge-Transport und UnifiedMessaging zu installieren.
Ein weiterer nützlicher Trick besteht darin, ServerManagerCmd mit dem Schalter –query zu verwenden. Dadurch wird die gesamte Liste der Serverfunktionen und Dienste aufgeführt und angezeigt, welche davon tatsächlich konfiguriert sind (in Abbildung 2 durch den grünen Text gekennzeichnet).
Abbildung 2 Auflisten von Exchange-Serverfunktionen und -Diensten
Abbildung 2 Auflisten von Exchange-Serverfunktionen und -Diensten
Aber zurück zur eigentlichen Geschichte: Wir haben die Anfangsmonate des Jahres 2007 in der Testumgebung verbracht, um herauszufinden, welche Änderungen zum Erzielen einer hervorragenden Leistung unter Windows Server 2008 erforderlich waren. Wenn ich eines gelernt habe dann das: Sie können Software in der Testumgebung installieren und so lange testen, wie Sie wollen, die wahre Qualität erweist sich jedoch erst bei realen Bereitstellungen mit echten Benutzern. Genau aus diesem Grund unterziehen wir unsere Produkte „Dogfood“-Tests, indem wir sie im echten, alltäglichen Einsatz erproben. Die Veröffentlichung von Windows Server 2008 Beta 3 im April 2007 war der Wendepunkt – es war an der Zeit, mit der Bereitstellung in der Produktionsumgebung zu beginnen.
Ich schaute einem Mitglied des Betriebsteams über die Schulter, als wir den ersten Satz von Exchange-Servern unter Windows Server 2008 bereitstellten. Das Exchange-Setup lief ohne Probleme ab, und alle Dienste wurden gestartet. Jetzt mussten wir nur noch ein Postfach verschieben und feststellen, ob dies wirklich funktionierte. Ich meldete mich freiwillig als Tester. Mein Postfach hat eine Größe von 2 GB. 26 Minuten später war es betriebsbereit, und ich konnte mit Exchange unter Windows Server 2008 E-Mails versenden. Ein Erfolg!

Gewonnene Erfahrungen
Seit dieser ersten Installation unter Windows Server 2008 haben wir an der Feinabstimmung gearbeitet, um sicherzustellen, dass alles wirklich für den großen Tag bereit ist. Im Zuge dessen mussten wir einige wichtige Bereitstellungsentscheidungen treffen.
Installation Sie können Exchange Server 2007 SP1 entweder als Upgrade für die ursprüngliche Exchange Server 2007-Installation – von mir als RTM-Version (Release to Manufacturing) von Exchange 2007 bezeichnet – verwenden oder direkt mit den Exchange Server 2007 SP1-Medien eine Installation auf einem neuen Computer durchführen. Dies ist wichtig, da Sie die RTM-Version von Exchange Server 2007 nicht auf einem Computer installieren können, auf dem Windows Server 2008 ausgeführt wird.
Upgrades Obwohl Sie das Betriebssystem direkt von Windows Server 2003 SP2 auf Windows Server 2008 aktualisieren können, müssen zunächst bestimmte Komponenten deinstalliert werden. Eine dieser Komponenten ist Windows PowerShell™. Sie bildet die Grundlage für die Exchange-Verwaltung, selbst das Exchange-Setup basiert auf Windows PowerShell. Aus diesem Grund können direkte Upgrades des Betriebssystems nicht unterstützt werden, wenn Exchange bereits installiert ist. Für viele Benutzer bedeutet dies in der Regel, dass sie Windows Server 2008 auf einem neuen Computer installieren und dann Exchange Server 2007 SP1 installieren sollten.
IPv6 Exchange wurde für die Nutzung mehrerer neuer Features von Windows Server 2008 entwickelt. So wird beispielsweise IPv6 standardmäßig installiert, und zwei Exchange-Server, die unter dem neuen Betriebssystem ausgeführt werden, verwenden automatisch IPv6, um miteinander zu kommunizieren. Die Schnittstellen der Exchange-Verwaltungskonsole akzeptieren ebenfalls IPv6-Adressbereiche. Es gibt einen Nachteil: Exchange erfordert nach wie vor, dass an jede Netzwerkschnittstelle eine IPv4-Adresse gebunden wird.
Domänencontroller ohne Schreibzugriff Eine ziemlich radikale Änderung für Active Directory®-Bereitstellungen ist das Konzept von Domänencontrollern ohne Schreibzugriff (oder globalen Katalogservern). Dadurch können Unternehmen einen Active Directory-Server bereitstellen, der eine unidirektionale Replikation empfängt und Änderungen nicht zurückreplizieren kann. Dies kann in Zweigstellen oder an Remotestandorten nützlich sein, bei denen die physische Sicherheit nicht garantiert werden kann. Unglücklicherweise kann Exchange Server 2007 SP1 keinen Domänencontroller ohne Schreibzugriff verwenden und erfordert den Zugriff auf eine normale beschreibbare Partition von Active Directory.

Ihre Exchange-Umgebung
Exchange- und Windows Server-Ressourcen
  • Windows Server 2008-TechCenter
  • Exchange Server TechCenter
  • TechNet-Evaluierungscenter
  • Windows Server 2008-Virtual Labs

Bei der Auswahl der Betriebssystemebene für die Bereitstellung haben Sie die Möglichkeit, verschiedene Konfigurationen auszuführen, wie in Abbildung 3 dargestellt.
Figure 3 Übersicht über die Exchange-Umgebung (Close Figure 3)

Exchange-Version | Serverbetriebssystem | Domänencontroller
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2008 | Windows Server 2003
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2008
Exchange Server 2007 SP1 | Windows Server 2003 SP2 | Windows Server 2003
Eine weitere Überlegung sind Bereitstellungen mit unterschiedlichen Versionen. Sie können problemlos eine Mischung aus verschiedenen Exchange- und Windows-Versionen zusammen einsetzen. Beispielsweise können Sie Exchange Server 2007 SP1 unter Windows Server 2008 für Clientzugriffsserver bereitstellen und sie auf die RTM-Version von Exchange Server 2007 auf Windows Server 2003-Postfachservern zugreifen lassen.
Bei älteren Versionen von Exchange und Windows Server 2008 Active Directory sind bestimmte Aspekte zu beachten. Wenn Sie über Exchange Server 2003 SP2 oder höher verfügen, können Sie Windows Server 2008-Domänencontroller in Ihrer Umgebung bereitstellen und verwenden. Wenn Sie jedoch immer noch Exchange 2000 einsetzen, sollten Sie mit der Bereitstellung von Windows Server 2008-Domänencontrollern am Active Directory-Standort, an dem sich diese Exchange-Server befinden, warten – oder die DSAccess-Einstellungen (Directory Service Access) hartcodieren, damit Exchange 2000 nicht versucht, die Windows Server 2008-Domänencontroller zu verwenden.

Schlussbemerkungen
Es wurde viel Arbeit investiert, damit Exchange 2007 SP1 sowohl auf der Windows Server 2003- als auch auf der Windows Server 2008-Plattform einwandfrei funktioniert. Uns liegt daran, für Exchange Flexibilität bei der Bereitstellung sowie besser durchdachte Szenarios zu bieten. Sie sind mit Sicherheit angenehm überrascht, wie leicht und schnell sich Exchange unter Windows Server 2008 bereitstellen lässt. Außerdem werden Ihnen einige ausgetüftelte interne Verbesserungen bei Leistung und Skalierbarkeit auffallen, beispielsweise die deutlich bessere Skalierbarkeit von Clientzugriffsservern für Outlook Anywhere-Clients.
Windows Server 2008 bietet die Plattform für zukünftige Innovationen im Messagingbereich. Sie werden nicht enttäuscht sein.

Paul Bowden ist leitender Programmmanager im Exchange Server-Team. Er verbringt einen Großteil seiner Freizeit damit, seine PayPal-Kontoinformationen auf Anforderung erneut zu bestätigen.


 Kommunikation: Bereitstellen von Unified Messaging mit Exchange Server&#160;2007
Kommunikation Jeff Goodwin

Bereitstellen von Unified Messaging mit Exchange Server 2007
Kurz zusammengefasst:
  • Grundlagen der Telefonie
  • Überlegungen zum Entwurf von Unified Messaging
  • Migration von Benutzern

Sie haben sich also entschieden, Exchange Server 2007 Unified Messaging in Ihrer Umgebung bereitzustellen. Sie haben eine Unified Messaging-Serverfunktion installiert, sie in Ihre vorhandene Nebenstellenanlage integriert, und jetzt verfügen Sie und 10 weitere Mitarbeiter über Voicemail, E-Mail und Faxnachrichten, die in Exchange gespeichert werden. In der Vergangenheit hätten Sie
dies wahrscheinlich bereits als große Leistung angesehen. Aber wie stellen Sie diese Features für Tausende von Abonnenten an verschiedenen Standorten ohne Unterbrechung der Geschäftstätigkeit bereit?
Dieser Artikel dient hoffentlich als nützliche Anleitung. Es soll veranschaulicht werden, wie Sie Unified Messaging in Ihrer Umgebung bereitstellen können. Außerdem werden die mit einer solchen Bereitstellung verbundenen Telefoniekonzepte klar aufgezeigt. Wenn Sie Hilfe zu Installation, Konfiguration oder Features von Exchange Server 2007 Unified Messaging benötigen, finden Sie weitere Informationen in der Randleiste „Unified Messaging-Ressourcen“ am Ende dieses Artikels. Microsoft hat außerdem verschiedene Unternehmen als Unified Messaging-Experten bestimmt, die Kunden bei der Beratung, dem Entwurf und der Bereitstellung von Exchange Server 2007 Unified Messaging helfen können. Wenn Sie Hilfe bei Installation, Konfiguration, oder Bereitstellung benötigen, setzen Sie sich mit einem dieser Experten, die ebenfalls in der Randleiste aufgeführt sind, in Verbindung.

Erste Schritte
Unified Messaging Technologien sind bei Exchange nicht neu. Zahlreiche Unternehmen bieten Unified Messaging-Produkte an, die mit Exchange kombiniert werden können. Dies ist jedoch die erste Version von Exchange, die Unified Messaging systemeigen unterstützt. Seit der Einführung haben viele Kunden Exchange Server 2007 Unified Messaging für kleine Gruppen innerhalb ihrer Organisation bereitgestellt. Aus verschiedenen Gründen wurde Unified Messaging jedoch nicht immer für alle Benutzer bereitgestellt. Ein Problem ist, dass viele Exchange-Administratoren nicht mit den Telefoniekonzepten und -technologien für die Implementierung von Unified Messaging vertraut sind, und mit dem Design und der Bereitstellung dieser Lösungen in ihren Unternehmen überfordert sind.
Wie bei jedem Bereitstellungsprojekt werden die besten Ergebnisse durch einen schrittweisen Ansatz erzielt. Die fünf Phasen Planung der Architektur, Testen der Lösung, Pilottests einer Benutzercommunity, Schulung und Migration von Benutzern zum neuen System sind Aspekte, die bei der Bereitstellung eines Unified Messaging-Projekts in Erwägung gezogen werden müssen. Es ist wichtig, dass sowohl IT als auch Telekomgruppen innerhalb Ihrer Organisation bei der Planung des Projekts einbezogen werden.
Viele Features, die Benutzer auf herkömmlichen Voicemailplattformen als selbstverständlich ansehen, müssen dupliziert werden. Wenn dies nicht möglich ist, sollte eine Alternativlösung entworfen werden, durch die Auswirkungen auf Benutzergruppen bei der Bereitstellung eines neuen Projekts minimiert werden. Dies ist ein wichtiger Bereich, bei dem Sie auf die Unterstützung des Telekomteams angewiesen sind. Andererseits muss das Telekomteam vom IT-Team lernen, wie die neue Voicemailplattform verwaltet, Probleme behandelt und die neue Plattform während der Implementierung unterstützt wird.

Grundlagen der Telefonie
Sie werden die Planung sehr viel einfacher finden, wenn Sie die grundlegende Architektur, den Anrufverkehr und die Terminologie von Unified Messaging verstehen. Abbildung 1 veranschaulicht ein Beispiel für eine Unified Messaging-Lösung, die in ein vorhandenes Unternehmenstelefoniesystem integriert ist. Im Folgenden werden die häufigsten Konzepte und Technologien betrachtet, die mit einer solchen Bereitstellung verbunden sind.
Abbildung 1 Eine PBX-zu-Unified Messaging-Lösung
Abbildung 1 Eine PBX-zu-Unified Messaging-Lösung
Eine Nebenstellenanlage (Private Branch Exchange, PBX) ist ein privates Telefonnetzwerk, das innerhalb eines Unternehmens verwendet wird. Bei einem solchen System verfügt jeder Benutzer in der Regel über ein Schreibtischtelefon, das an die Nebenstellenanlage angeschlossen ist, von dem Anrufe zu anderen internen Benutzern durch Eingabe einer Nebenstelle (normalerweise vier oder fünf Ziffern) und zu externen Telefonen getätigt werden können.
Manche Unternehmenskunden, die über viele Standorte mit Nebenstellenanlagen verfügen, lassen die Systeme über Netzwerktechnologien des jeweiligen PBX-Anbieters miteinander verbinden. Dies ermöglicht allen Benutzern auf den vernetzten Nebenstellenanlagen, sich gegenseitig durch einfache Eingabe einer Nebenstelle anzurufen.
Unified Messaging beinhaltet die Integration zweier ungleicher Systeme: Exchange Messaging und das physische Telefoniesystem. Die Kommunikation zwischen dem Unified Messaging-Server und der Telefoniearchitektur wird mithilfe des Sitzungsaktivierungsprotokolls (Session Initiation Protocol, SIP) durchgeführt. Einige PBX-Technologien können direkt mit dem Unified Messaging Server über SIP kommunizieren, andere erfordern ein SIP-Gateway. In Abbildung 1 ist die Nebenstellenanlage mit einem SIP-Gateway über eine T1-Leitung verbunden. Wenn ein Anruf zu Unified Messaging weitergeleitet wird, sendet die Nebenstellenanlage Informationen (Telefonnummer des anrufenden und des angerufenen Teilnehmers sowie eine Art Ursachencode) an das SIP-Gateway, sodass der Unified Messaging-Server den Empfänger des Anrufs ermitteln kann.
Einige Nebenstellenanlagen können miteinander über das IP-Netzwerk verbunden werden. Mit Telefonienetzwerken können Anrufe über das IP-Netzwerk zu einer zentralisierten Voicemaillösung umgeleitet werden. In Abbildung 2 ist beispielsweise zu sehen, dass Anrufe an Zürich nach London zurückgeleitet werden.
Abbildung 2 Eine kompliziertere Bereitstellung von Unified Messaging
Abbildung 2 Eine kompliziertere Bereitstellung von Unified Messaging

Anrufverkehr
Unified Messaging-Ressourcen
  • Unified Messaging-Expertenkatalog
  • Exchange Unified Messaging-TechCenter
  • Unterstützte SIP-Gateways
  • Telefonieberater
  • PBX-Konfigurationshinweise

Angenommen ein Anruf von einem externen Anrufer wird an ein Unified Messaging-Teilnehmertelefon geleitet. In diesem Fall ist der Unified Messaging-Teilnehmer nicht im Büro, und das Telefon bleibt unbeantwortet. Verfolgen Sie den Pfad der Nachricht in Abbildung 1.
Die Nebenstellenanlage sendet den Anruf an das SIP-Gateway, das den Anruf mit SIP über TCP mit dem Unified Messaging-Server aushandelt. Der Server empfängt Integrationsdaten vom SIP-Gateway, die angeben, für wen der Anruf bestimmt war. Der Unified Messaging-Server spielt daraufhin die Nachricht des Teilnehmers ab und ermöglicht dem externen Anrufer, eine Nachricht zu hinterlassen. Diese Nachricht wird daraufhin an das Exchange-Postfach des Unified Messaging-Teilnehmers gesendet.
Hierbei handelt es sich um eine extrem vereinfachte Ablaufbeschreibung des Anrufsverkehrs. Machen Sie sich bewusst, dass der Unified Messaging-Server eine aufgezeichnete Nachricht über SMTP an den Hub-Transport-Server für die Lieferung an den Postfachserver weiterleitet.
Als Unified Messaging-Teilnehmer verfügen Benutzer nun über Zugriff auf ihr Exchange-Postfach über ein Telefon (mithilfe von Outlook® Voice Access) oder einen Computer (mithilfe von Outlook 2007 oder Outlook Web Access). Teilnehmer können jedoch auch auf Nachrichten über ein Telefon mithilfe von Outlook 2007 oder Outlook Web Access mit einem Feature namens „Wiedergabe über Telefon“ zugreifen, mit dem der Teilnehmer die ausgewählte Nachricht über Unified Messaging durch Anrufen eines bestimmten Telefons statt Zugriff über den Computer abspielen kann. Wenn diese Methode verwendet wird, interagiert der Unified Messaging-Server sowohl mit dem Clientzugriffsserver als auch dem Postfachserver. Dies ist für das Verständnis wichtig, denn wenn Sie einen Unified Messaging-Server in einem entfernten Büro platzieren, das über keinen lokalen Clientzugriffsserver verfügt, muss der Unified Messaging-Server den Clientzugriffsserver über das WAN kontaktieren, wodurch die Leistung möglicherweise verlangsamt wird.

Systementwurf
Kunden implementieren in der Regel einen von zwei Exchange-Architekturentwürfen: zentralisiert oder dezentralisiert. Im Allgemeinen basiert die Unified Messaging-Architektur auf der jeweiligen Exchange-Architektur, was bedeutet, dass an jedem Ort, an dem ein Postfachserver bereitgestellt wird, ebenfalls ein Unified Messaging-Server bereitgestellt wird. Natürlich bestätigen Ausnahmen die Regel.
Beim Entwurf Ihrer Unified Messaging-Architektur sind fünf grundlegende Bereiche zu berücksichtigen.
  • Serververteilung
  • Anzahl von Unified Messaging-Servern
  • SIP-Gateway
  • Postfachspeicher
  • Unified Messaging-Standortkonfiguration
Nicht zu vergessen die Geschäftskontinuität. In der Regel kann Ihr Notfallwiederherstellungsplan für Exchange zum Bestimmen von Elementen verwendet werden, die für Unified Messaging relevant sind.
Beispielbereitstellungsszenarios können Ihnen beim Verständnis von Unified Messaging-Serverfunktionen helfen. Abbildung 2 veranschaulicht eine umfangreiche Unternehmensbereitstellung von Exchange Server 2007 mit Unified Messaging.
In diesem komplizierteren Entwurf sind die primären Datencenter Seattle und London. Unified Messaging-Server an diesen Standorten dienen den jeweiligen Benutzergruppen, da die Postfach- und Hub-Transport-Server lokal sind. Beide Standorte verfügen über IP-Nebenstellenanlagen, die eine Anrufübertragung an den lokalen Unified Messaging-Server bieten, der für die Anrufbeantwortung sorgt.
Mittelgroße Standorte liegen in New York und Glasgow. Unified Messaging-Server an diesen Standorten dienen den jeweiligen Benutzergruppen, da die Postfach- und Hub-Transport-Server lokal sind. Wie bei den primären Datencentern verfügen beide Standorte über IP-Nebenstellenanlagen, die eine Anrufübertragung an den lokalen Unified Messaging-Server bieten, der für die Anrufbeantwortung sorgt.
Kleinere Standorte verfügen nicht über lokalisierten Mailbox- oder Hub-Transport-Server, sondern bieten Unified Messaging-Funktionen von den primären Datencentern aus. Austin verfügt über eine NEC-Nebenstellenanlage, bei der die Konnektivität zu einem lokalen SIP-Gateway analog hergestellt wird. Anrufe bei lokalen Endbenutzern werden zum SIP-Gateway weitergeleitet, das mit dem Unified Messaging-Server in Seattle verhandelt, um Anrufbeantwortung für Unified Messaging bereitzustellen.
Zürich verfügt über einen Avaya Communication Manager, der über das IP-Netzwerk mit dem Avaya Communication Manager in London vernetzt ist. Anrufe bei lokalen Benutzern werden über das Avaya Communication Manager-Netzwerk weitergeleitet, das mit dem Unified Messaging-Server in London verhandelt, um Anrufbeantwortung für Unified Messaging bereitzustellen.
In diesem Beispiel verfügt der Standort Seattle über Exchange-Postfachserver und Unified Messaging-Server am selben physischen Standort. Bei einer Architektur mit einem einzigen Standort sind alle Server (Postfachserver, Unified Messaging-Server, Clientzugriffsserver usw.) und PBX-Ausrüstung am selben Standort vorhanden. Bei Unternehmen mit mehreren Standorten wird der Entwurf komplexer. Diese Komplexität mag überwältigend scheinen, durch ein gutes Verständnis einiger grundlegender Unified Messaging-Prinzipien wird sie jedoch überschaubar.
Wenn ein Postfachserver an einem Standort vorhanden ist, wird empfohlen, dort auch einen Unified Messaging-Server bereitzustellen (wie in Abbildung 2 dargestellt). Seattle, London, New York und Glasgow entsprechen alle diesem Entwurf. Weder Austin noch Zürich verfügen über einen lokalen Postfachserver, Unified Messaging-Dienste können jedoch trotzdem durch Nutzung des IP-Netzwerks für diese Standorte bereitgestellt werden. Austin verfügt über eine lokale analoge Nebenstellenanlage. In diesem Fall muss ein SIP-Gateway verwendet werden, um IP-Netzwerkkonnektivität für den Unified Messaging-Server in Seattle bereitzustellen. Zürich verfügt über eine lokale IP-Nebenstellenanlage, die über das Netzwerk mit der Londoner Nebenstellenanlage zurückverbunden wird. Anrufe bei einem Benutzer in Zürich würden das Telefonienetzwerk folglich zurück zur Londoner Nebenstellenanlage und dem Unified Messaging-Server durchlaufen.
Da Anrufe bei Teilnehmern in Zürich das Netzwerk durchlaufen und von einem zentralisierten Unified Messaging-System in London verarbeitet werden, bleiben Anrufe bei allen Teilnehmern in Zürich im Falle eines Ausfalls unbeantwortet, bis das Netzwerk repariert ist. Wenn lokale Störungen im Falle eines Netzwerkausfalls vermieden werden sollen, könnte ein Unified Messaging-Server in Zürich platziert werden. Im Falle eines Netzwerkausfalls nimmt der Unified Messaging-Server weiterhin Anrufe entgegen und leitet diese weiter, wenn das Netzwerk repariert ist.
Die Serververteilung ist wahrscheinlich der wichtigste zu berücksichtigende Faktor für den Entwurf einer für Ihre Umgebung geeigneten Architektur. Das Flussdiagramm in Abbildung 3 soll Ihnen bei der Bestimmung der ordnungsgemäßen Serververteilung helfen.
Abbildung 3 Bestimmen der Serververteilung
Abbildung 3 Bestimmen der Serververteilung

Einschätzen von Serveranforderungen
Als nächstes gilt es zu überlegen wie viele Unified Messaging-Server Sie benötigen, um Ihre Benutzercommunity zu unterstützen. Die Antwort darauf hängt von mehreren standortspezifischen Faktoren ab.
Unified Messaging-Skalierbarkeit wird dadurch bestimmt, wie viele Anrufe (angerufene Ports in der Telefonieumgebung) vom Server gleichzeitig unterstützt werden können. Für jeden Anruf beim System muss der Unified Messaging-Server Netzwerk, CPU, Speicher und Datenträgerressourcen bereitstellen. Durch Erweitern dieser Ressourcen kann ein Unified Messaging-Server mehrere gleichzeitige Anrufe unterstützen. Da solche Ressourcen aber immer begrenzt sind, kann der Unified Messaging-Server nur eine bestimmte Anzahl gleichzeitiger Anrufe verarbeiten, bevor eine Ressourcenüberlastung auftritt.
Sie können mithilfe von Erlang-Verkehrsanalyseberechnungen bestimmen, wie viele Ports für die Unterstützung der Teilnehmeranzahl erforderlich sind. Darauf soll hier jedoch nicht näher eingegangen werden. Wenn Sie eine einfachere Möglichkeit zum Bestimmen der Anzahl erforderlicher Ports suchen, fragen Sie Ihren Telefonieadministrator, wie viele Voicemailports auf dem vorhandenen Voicemailsystem verwendet werden. Basierend auf praktischen Erfahrungen sind die Portanforderungen auf einem herkömmlichen Voicemailsystem und einem Unified-Voicemailsystem sehr ähnlich.
Generell wird die Bereitstellung von höchstens 60 Ports auf einem einzelnen Server empfohlen. Dies hat nichts mit Software- oder Hardwarebeschränkungen zu tun. Die Zahl basiert vielmehr auf der Tatsache, dass ein einzelner Server mit 60 Ports ca. 5000 Benutzer unterstützen kann. Wenn bei diesem einzelnen Server ein Ausfall auftritt, ergibt sich daraus ein Einzelserverausfall auf Ihrer gesamten (sehr großen) Teilnehmerbasis.
Bei der Bereitstellung von Unified Messaging-Servern müssen Sie möglicherweise den Entwurf einer N+1- Redundanz für die Architektur in Erwägung ziehen. Abbildung 4 veranschaulicht den Entwurf eines vollständig redundanten Servers und SIP-Gateways. Wenn bei Unified Messaging-Server 1 unter Verwendung dieses Entwurfs ein Ausfall auftritt, verhandeln Anrufe von SIP-Gateway 1 automatisch Anrufe mit Unified Messaging-Server 2. Sie können die Nebenstellenanlage auch für die gleichmäßige Verteilung der Anruflast zwischen den SIP-Gateways programmieren. Der erste Anruf beim System könnte beispielsweise an das SIP-Gateway 1 geleitet werden, und der nächste Anruf beim System könnte zum SIP-Gateway 2 geleitet werden. Ein Wechsel der Anrufe zwischen den Gateways ermöglicht eine gleichmäßige Anruf- und Lastverteilung zwischen den Unified Messaging-Servern.
Abbildung 4 Verteilen von Anrufen zwischen den Servern für Redundanz
Abbildung 4 Verteilen von Anrufen zwischen den Servern für Redundanz
Es gibt derzeit zwei SIP-Gatewayanbieter, die für Exchange Server 2007 Unified Messaging-Lösungen unterstützt sind: AudioCodes und Dialogic. Wenn SIP-Gateways für Ihren Entwurf erforderlich sind, erwerben Sie unbedingt ein Gateway, das die Anzahl der für Ihren Entwurf erforderlichen Sitzungen (Ports) unterstützt. Wenn Ihr Entwurf beispielsweise 32 Ports erfordert, benötigen Sie ein Gateway, das mindestens genauso viele Sitzungen unterstützt.
Wenn Sie sich fragen, ob Ihre Nebenstellenanlage mit Unified Messaging funktioniert oder welches Gateway Sie verwenden sollen, werfen Sie einen Blick auf die Randleiste „Unified Messaging-Ressourcen“. Über die dort aufgeführten Links erhalten Sie spezifischen Anleitungen von Microsoft sowie Zugriff auf einen Katalog mit Unified Messaging-Experten, die Sie bei der Analyse der spezifischen Anforderungen Ihrer Organisation unterstützen. Aus eigener Erfahrung funktionieren die meisten Nebenstellenanlagen mit SIP-Gateways und Exchange Unified Messaging, und einige Nebenstellenanlagen können systemeigen mit dem Unified Messaging-Server mithilfe von SIP über TCP kommunizieren.
Exchange Unified Messaging unterstützt drei Audiocodecs für die Speicherung von Voicemailnachrichten: G.711 PCM Linear, GSM 06.10 und Windows Media® Audio (WMA). Jede lineare PCM WAV-Datei belegt ungefähr 16 KB pro Audiosekunde. WMA ist der Standardaudiocodec für Unified Messaging. Das Audio wird auf 1,1 Kilobit (KBit) pro Audiosekunde mit einem 7 KB-Header komprimiert. GSM 06.10 komprimiert das Audio auf 1,6 KBit pro Audiosekunde, verfügt jedoch über einen kleineren Header als WMA-Codierung.
Sowohl WMA als auch GSM 06.10-Codierungen bieten eine für Sprachnachrichten akzeptable Sprachqualität. Basierend auf praktischen Erfahrungen bei der Verwendung von WMA- oder GSM-Codecs können Sie von einer 10- bis 20-prozentigen Vergrößerung des Postfachspeichers ausgehen, je nachdem, wie stark Ihre Organisation auf Voicemail angewiesen ist.
Bei der Auswahl des zu verwendenden Audiocodecs für Ihre Umgebung berücksichtigen Sie die mobilen Geräte und sonstigen Betriebssysteme, die Ihre Endbenutzer möglicherweise verwenden. Fragen zu diesem Thema beziehen sich hauptsächlich darauf, ob Benutzer ihre Voicemail auf ihren Windows Mobile®-Geräten abhören können. Andere Betriebssysteme sind ebenso Anlass für Fragen: Vielleicht verfügen Sie über eine umfangreiche Implementierung von Linux-Computern, die möglicherweise keine WMA-Dateien wiedergeben können. Wie Ihr Szenario auch immer aussehen mag, bedenken Sie, dass solche Aspekte bei den Schulungsanforderungen für Helpdeskressourcen berücksichtigt werden müssen.

Konfiguration und Tests
Unabhängig davon, ob die Unified Messaging-Architektur zentralisiert oder verteilt ist, müssen zahlreiche Voicemailanforderungen vor der Bereitstellung von Unified Messaging in Ihrer Organisation berücksichtigt werden. Eine ausführliche Liste der vom Projektteam zu diskutierenden Themen finden Sie in der Randleiste „Unified Messaging-Prüfliste“. Die Informationen zu all diesen Themen sollten für jeden Standort erfasst werden, an dem eine Bereitstellung von Unified Messaging in Frage kommt. Bedenken Sie, dass sich sowohl das IT- als auch das Telekomteam gemeinsam durch diese Themen arbeiten müssen.
Wenn Ihr System entworfen und die Konfiguration abgeschlossen ist, sollte ein Testsystem eingerichtet werden, mit dem der Entwurf überprüft wird. Bei einem Entwurf mit mehreren Standorten sollten mindestens zwei separate Machbarkeitsstudien durchgeführt werden, und die Entwurfsfunktionen sollten auf korrekte Funktionsweise überprüft werden.
Aus Ihren Konfigurationsanforderungen sollte ein Funktionstestplan entwickelt und durchgeführt werden. Der Funktionstestplan sollte Teilnehmerzugriffsmethoden (Telefon, Outlook 2007 und Outlook Web Access), Verwaltungsmethoden sowie Hardware- und Netzwerkausfälle beinhalten.
Nachdem die Tests abgeschlossen sind und sich alle einig sind, dass Unified Messaging die Features des alten Voicemailsystems verdoppelt bzw. wenn eine alternative Lösung entworfen wurde, um alle Konfigurationen oder Features zu unterstützen, die nicht dupliziert werden können, sollte eine Pilotgruppe von Benutzern zum Testen des Systems ausgewählt werden. Durch die Pilotgruppe werden die in Ihrer Umgebung erforderlichen Schritte veranschaulicht, um Teilnehmer aus dem alten Voicemailsystem in das neue Unified Messaging-System zu übertragen. Im Allgemeinen sind die folgenden Schritte erforderlich, um einen Teilnehmer zu übertragen:
  1. Deaktivieren Sie den Teilnehmer im vorhandenen Voicemailsystem.
  2. Aktivieren Sie den Teilnehmer in Active Directory für Unified Messaging über die Exchange-Verwaltungskonsole.
  3. Ändern Sie den Übertragungspfad des Telefons zu einer Unified Messaging-Pilotnummer.
Es ist wichtig, den Teilnehmer im vorhandenen Voicemailsystem zu deaktivieren, sodass keine Nachrichten an das alte Postfach gesendet werden.
Während der Pilotphase sollten Sie alle Fragen erfassen, die Ihre Teilnehmer in Bezug auf die Systemfunktionalität haben. Eine Dokumentation dieser Informationen ermöglicht Ihnen die Lösung häufiger Probleme während der Schulungsphase.
Adäquate Schulung ist für eine erfolgreiche Übertragung zum neuen System sehr wichtig. Die Benutzer sind es gewöhnt, auf die Voicemail vom Telefon aus mit einer bestimmten Benutzerschnittstelle zuzugreifen. Bei einigen Voicemailsystemen müssen Benutzer beispielsweise auf 5 drücken, um Nachrichten abzuhören. Bei Exchange Unified Messaging müssen Benutzer auf 1 drücken bzw. „Voicemail“ sagen (oder Outlook 2007 oder Outlook Web Access für die Wiedergabe von Sprachnachrichten verwenden). Die Unified Messaging-Teilnehmerschulung sollte die Navigation in der Telefoniebenutzerschnittstelle, in Outlook Voice Access und Outlook/Outlook Web Access umfassen.
Bei Exchange 2007 Unified Messaging ist die Möglichkeit, die Befehle zu sprechen, in Outlook Voice Access integriert. Oft sind Benutzer von den neuen Funktionen des Systems so angetan, dass dies den Übergang von einer Benutzeroberfläche zur anderen erleichtert.
Exchange Unified Messaging verfügt über die Fähigkeit, eine benutzerdefinierte Text-E-Mail-Nachricht an jeden Benutzer zu senden, der aktiviert wird. Diese benutzerdefinierten Nachrichten können für die Bereitstellung hilfreicher Weblinks zu häufig gestellten Fragen (FAQs), Teilnehmerdokumentation, Helpdesktelefonnummern usw. verwendet werden. Sie können außerdem Informationen für den Zugriff auf das Voicemailsystem und das eindeutige Kennwort des Teilnehmers enthalten. Dies ist eines der leistungsfähigsten Features, das Sie beim Aktivieren der Endbenutzer einsetzen können.

Migration von Benutzern
Unified Messaging-Prüfliste
In den folgenden Abschnitten werden die grundlegenden Elemente eines Unified Messaging-Systems definiert. Außerdem werden mögliche Fragen angesprochen, die in Vorbereitung auf die Bereitstellung und Konfiguration von Exchange Server 2007 Unified Messaging beantwortet werden müssen. Verwenden Sie dies als Prüfliste für die Entwicklung eines Bereitstellungsplans.
Wählpläne Ein Unified Messaging-Wählplan entspricht einer Nebenstellenanlage und den verbundenen Nebenanschlüssen logisch. Einige Aspekte des Wählplans, die im Voraus zu berücksichtigen sind:
  • Aus wie vielen Ziffern besteht die Nummer des Nebenanschlusses?
  • Was ist die Pilotnummer des Unified Messaging-Systems?
  • Was müssen Benutzer wählen, um auf eine Amtsleitung zuzugreifen?
  • Welchen Audiocodec wollen Sie für Nachrichten verwenden?
  • Was ist die Durchwahlnummer der Telefonzentrale?
Sammelanschlüsse und Pilotnummern Ein Sammelanschluss ist ein Satz von Telefonnebenanschlüssen, die für den Empfang von Anrufen in einer bestimmten Reihenfolge konfiguriert sind. Die Pilotnummer ist die primäre Durchwahl, die für den Zugriff auf den Sammelanschluss verwendet wird. Sie benötigen die gleiche Anzahl von Sammelanschlussdurchwahlnummern für Mitglieder wie die Anzahl von Voicemailports in Ihrem Entwurf.
Postfachrichtlinien Voicemail-Postfachrichtlinien unterscheiden sich nicht sehr von Exchange-Postfachrichtlinien. Im Folgenden sind einige Richtlinien aufgeführt, die Sie möglicherweise erörtern möchten:
  • Wie viele Tage sollen Voicemails vor dem Löschen gespeichert werden?
  • Wie oft ist das Zurücksetzen von Kennwörtern für Voicemail erforderlich?
  • Was ist die Voicemail-Sicherungsrichtlinie?
  • Was ist die akzeptable Mindestlänge für Kennwörter?
  • Wie viele Anmeldeversuche können maximal durchgeführt werden, bevor das Postfach gesperrt wird?
Automatisierte Telefonzentrale Automatisierte Telefonzentralen (Automated Attendant, AA) beantworten eingehende Anrufe, die nicht für einen bestimmten Teilnehmer bestimmt sind. Sie bieten Informationen und leiten Anrufer an Standorte innerhalb der Organisation. Exchange Unified Messaging stellt DTMF und Sprachfunktionen für AA-Navigation bereit. Zu den zu berücksichtigenden Faktoren gehören:
  • Gibt es unterschiedliche AA-Eingabeaufforderungen für tagsüber, nachts, und Urlaubszeiten? (Eingabeaufforderungen müssen dokumentiert und aufgezeichnet werden.)
  • Wer kann aus dem AA-Menü angerufen werden?
  • Kann Sprachnavigation eine Funktion bei der Verwendung von AA sein?
  • Sind mehrere Sprachen für die Verwendung von AA erforderlich?
Allgemeines oder Nachtpostfach Einige Organisationen verfügen über ein allgemeines oder Nachtvoicemailfach, das Anrufern das Hinterlassen allgemeiner Nachrichten ermöglicht. Wenn Ihr Unternehmen über ein solches Postfach verfügt, muss ein Exchange-Postfach für Unified Messaging erstellt und aktiviert werden.
Nachrichtenanzeige Die Nachrichtenanzeige (Message Waiting Indication, MWI) bezieht sich auf das Licht an Ihrem Telefon, das Ihnen nicht abgerufene Sprachnachrichten in Ihrem Postfach anzeigt. Ist die Nachrichtenanzeige auf Telefon-Handsets für die Bereitstellung erforderlich?
Unterstützung für mehrere Nebenanschlüsse Zahlreiche Organisationen verfügen über Mitarbeiter mit mehreren Telefonen. Bei Aktivierung dieser Teilnehmer für Unified Messaging müssen Sie alle Durchwahlnummern zu diesem Zeitpunkt zuordnen. Stellen Sie zunächst eine Liste mit Mitarbeitern auf, die über mehrere Nebenanschlüsse verfügen.
Unterstützung für IVR Einige herkömmliche Voicemailsysteme unterstützen IVR-Anwendungen (Interactive Voice Response), die Unified Messaging nicht duplizieren kann. Bestimmen Sie, ob dem zu ersetzenden System solche Anwendungen zugeordnet sind. Diese Anwendungen können auf dem vorhandenen System bleiben oder müssen durch alternative IVR-Anwendungen ersetzt werden.
Voicemailvernetzung Die Voicemailvernetzung bietet eine Möglichkeit, eine Nachricht von einem System zu einem anderen ungleichartigen System zu senden. In einem großen Unternehmen möchte der Geschäftsführer beispielsweise eine Sprachnachricht an die gesamte Organisation senden, oder aber Sie möchten allgemeine Informationen wie eine Feuerwehrübung bekannt geben. Mit einem Voicemailnetzwerk kann der Geschäftsführer eine Sprachnachricht einmal aufzeichnen und sie an alle Mitarbeiter im Unternehmen senden, unabhängig davon, welches Voicemailsystem sie verwenden. Zurzeit kann Exchange Unified Messaging nicht mit anderen herkömmlichen Voicemailsystemen vernetzt werden.
Faxunterstützung Einige herkömmliche Voicemailplattformen unterstützen eingehende Faxnachrichten und ermöglichen Ihnen den Einsatz einer einzelnen Telefonnummer sowohl für den Sprachgebrauch als auch eingehende Faxnachrichten. Exchange Server 2007 Unified Messaging unterstützt eingehende Faxnachrichten und kann für den Ersatz dieser Funktion verwendet werden. Dies ist ein Einwegfeature. Das System unterstützt keine ausgehende Faxfunktion. Wenn dies erforderlich ist, müssen Sie ein Drittanbieterprodukt in Erwägung ziehen, das diese Funktion unterstützt.

Es gibt viele verschiedene Ansichten darüber, wie das System in die gesamte Produktion migriert wird. Die zwei primären Methoden sind eine schrittweise Migration und eine einmalige Übertragung. Unabhängig davon, für welche Variante Sie sich entscheiden, schulen Sie Ihr Helpdeskpersonal für die allgemeinen in der Pilotgruppe aufgezeichneten Fragen. Außerdem sollte das Helpdeskpersonal wissen, wie ein Benutzer aktiviert wird, wie überprüft wird, ob ein Benutzer aktiviert ist, und wie ein Kennwort geändert wird.
Die Migration von Benutzern aus dem alten Voicemailsystem zu Unified Messaging ist relativ einfach, es gilt jedoch einen wichtigen Faktor zu bedenken: Voicemailvernetzung. Genauso wie Sie mit einem E-Mail-System E-Mails an andere E-Mail-Benutzer und Systeme senden, weiterleiten und auf diese antworten können, ist dies ebenso mit einem Voicemailsystem möglich.
Sehen Sie sich folgendes Szenario an: Alice und Brian befinden sich zurzeit auf dem alten Voicemailsystem. Brian wird zu Unified Messaging migriert und möchte eine Nachricht an Alice auf dem alten Voicemailsystem senden. Da sich die zwei Benutzer auf separaten Systemen befinden, können sie nicht länger gegenseitige Voicemailnachrichten senden, beantworten oder weiterleiten. Es ist somit eine Voicemailinsel entstanden.
Mit herkömmlichen Voicemailsystemen wird dieses Problem behoben, indem eine Art Netzwerkprotokollumwandler verwendet wird, mit dem unterschiedliche Systeme vernetzt werden können. Es gibt zurzeit jedoch keinen Netzwerkprotokollumwandler, mit dem unterschiedliche Systeme mit Exchange Server 2007 Unified Messaging vernetzt werden können. Dies mag zwar für Ihre Organisation nicht wichtig sein, Sie sollten sich dieser Tatsache jedoch bewusst sein, wenn Sie Benutzer in kleinen Gruppen migrieren möchten.
Ich bevorzuge eine einmalige Übertragung aller Benutzer eines Standorts. Eine einmalige Übertragung ist ein klar getrennter Übergang von einem System zu einem anderen. Dies findet häufig an einem Wochenende statt. Die Benutzer verlassen am Freitag das Büro und finden am Montag ein neues Voicemailsystem vor. Einige Administratoren sind der Ansicht, dass eine einmalige Übertragung nur bei kleinen Unternehmen oder Remotestandorten verwendet werden sollte. Ich bin anderer Meinung. In bin an einmaligen Übertragungen mit mehr als 7000 Benutzern an einem einzigen Standort beteiligt gewesen, an dem weniger als 1 Prozent der Mitarbeiter das Helpdesk um Unterstützung bitten mussten. Wenn alle anderen Phasen des Projekts vernünftig geplant und ausgeführt wurden, dürfte die Übertragung zum gesamten Produktionssystem reibungslos laufen.
Bei der Übertragung mehrerer Standorte in die gesamte Produktion sollten Sie jedoch erwägen, kleinere Remotestandorte einen nach dem anderen zu übertragen, bevor schließlich der größte Standort übertragen wird. Ziehen Sie Lehren aus der Übertragung der kleineren Standorte, und implementieren Sie erforderliche Änderungen in den Projektplan.
Idealerweise sollte die Benutzerschulung abgeschlossen und sollten alle Benutzer vor einer Liveschaltung des Systems für Unified Messaging aktiviert sein. Im Folgenden finden Sie eine schrittweise Methode für die Vorbereitung der einmaligen Übertragung eines Voicemailsystems.
Zunächst müssen Sie überprüfen, ob das Unified Messaging-System komplett installiert, konfiguriert und getestet wurde.
Führen Sie die Schulung in kleinen Gruppen durch. Erklären Sie den Benutzern während der Schulung, dass ihr Postfach vor der Liveschaltung des Systems aktiviert wird, und dass sie dazu aufgefordert werden, sich bei ihrem Postfach anzumelden und dieses durch Ändern ihres Kennworts und Aufzeichnen ihrer Nachricht zu initialisieren. Wenn die Schulung abgeschlossen ist, aktivieren Sie diese Benutzer umgehend, sodass diese ihr Postfach vor der Übertragung initialisieren können.
Wenn die Schulung abgeschlossen ist, wählen Sie ein Wochenende, an dem Sie alle Benutzer im alten Voicemailsystem deaktivieren und ihre Telefone zu Exchange Unified Messaging weiterleiten. Am Montag Morgen ist Ihr System für alle Benutzer in Ihrer Organisation live geschaltet.

Durchführen der Übertragung
Unabhängig davon, ob Sie einen einzelnen Standort oder eine große Organisation mit mehreren Standorten unterstützen, dürften die Informationen in diesem Artikel hilfreich sein. Organisationen mit mehreren Standorten können dem Entwurf Komplexität verleihen, die grundlegenden Anforderungen sind jedoch dieselben, unabhängig davon, ob Sie über 50 oder 5000 Benutzer verfügen.
Ich kann nicht genug betonen, dass sowohl IT- als auch Telekomteams bei der Bereitstellung einer Unified Messaging-Lösung zusammenarbeiten müssen. In meiner Erfahrung gehören zu den Dingen, die ein Unified Messaging-Projekt zum Scheitern verurteilen können, Uneinigkeiten zwischen IT und Telekom und fehlende Übereinstimmung im Hinblick auf die Lösung. Die Annäherung der Technologien ist nicht besonders schwierig, es ist aber vielleicht empfehlenswert, eine Person außerhalb Ihrer Organisation zu Rate zu ziehen, die über Kenntnisse in den Bereichen IT und Telekom verfügt, um die Teams zusammenzuführen bzw. eine erfolgreiche Projektbereitstellung zu planen.

Jeff Goodwin ist Senior Technologist bei der VIA Group und spezialisiert sich auf Entwurf und Bereitstellung von Exchange und Unified Messaging. Sie können ihn unter folgender E-Mail-Adresse erreichen: jgoodwin@theviagroup.com.


 Sicherheit: Handbuch zu den Grundlagen der Computerforensik
Sicherheit Tom Cloward and Frank Simorjay

Handbuch zu den Grundlagen der Computerforensik
Kurz zusammengefasst:
  • Das Basishandbuch für Computeruntersuchungen für Windows
  • Das Starter Kit zur Malwareentfernung
  • Erstellen eines Untersuchungskits mit Windows PE
  • Sicherstellen von Informationen für die forensische Analyse

Es gibt zahllose Methoden, mit denen Angreifer einen Computer missbrauchen können, um illegale Handlungen durchzuführen. Sie dringen beispielsweise als Hacker in Systeme ein, stehlen Geschäftsgeheimnisse, schleusen neue Viren ein, entwenden mithilfe von Phishingnachrichten persönliche Informationen und so weiter. Ständig ist die Rede von neuen Sicherheitslücken
und Angriffsmethoden. Was nicht so häufig angesprochen wird, sind die vielen Möglichkeiten, wie Computer zur Untersuchung von Aktivitäten dieser Art eingesetzt werden können.
Während für einige Untersuchungen Experten mit Spezialausbildung, teure Tools und komplizierte Verfahren erforderlich sind, gibt es einfachere und kostengünstigere Methoden für grundlegende Untersuchungen und Analysen. In diesem Artikel werden Verfahren der Computerforensik behandelt, die Ihnen als Administrator zur Verfügung stehen.
Diese Erörterung stützt sich auf zwei Solution Accelerators, die Sie kostenlos herunterladen können: „Das Basishandbuch für Computeruntersuchungen für Windows“ (go.microsoft.com/fwlink/?LinkId=80344) und das Starter Kit zur Malwareentfernung (go.microsoft.com/fwlink/?LinkId=93103). Dieser Artikel zeigt auf, wie diese beiden Lösungen kombiniert werden können, um eine startfähige Windows® PE-Umgebung einzurichten, in der Sie eine effektive Untersuchung durchführen und Ihre Ergebnisse für Berichte und Analysen sicherstellen können. Beachten Sie, dass mit den hier behandelten Methoden keine Festplatten untersucht werden können, die verschlüsselt oder Teil eines RAID-Volume sind. Wenn die Festplatte beschädigt ist, müssen Sie bereits im Vorfeld zusätzliche Schritte durchführen, um den ursprünglichen Zustand der Festplatte wiederherstellen zu können.
In dieser Lösung wird zwar eine grundlegende Methode beschrieben, um auf einem Windows-Computer Beweismaterial zu sammeln, aber es handelt sich trotzdem nur um ein einfaches Ad-hoc-Verfahren. Im Handel sind mehrere ausgereiftere Lösungen erhältlich, mit denen alle hier beschriebenen Arbeiten viel effektiver durchgeführt werden können.
Bedenken Sie auch, dass das hier behandelte Verfahren weder eine garantierte normative Lösung darstellt noch von der International Society of Forensic Computer Examiners (Internationale Gesellschaft zur Computerforensikuntersuchung) zertifiziert wurde. Bevor Sie mit einer Untersuchung beginnen, sollten Sie darüber nachdenken, ob auf der Festplatte vorhandenes Beweismaterial in Zukunft eventuell in einem Gerichtsverfahren verwendet werden könnte. Falls diese Möglichkeit besteht, sollte eine zertifizierte professionelle Computeruntersuchung durchgeführt werden. Abhängig von der Art der gerichtlichen Schritte müssen Sie darüber hinaus in Erwägung ziehen, ob die Untersuchung nicht sofort den zuständigen Polizeibehörden überlassen werden sollte. Weitere Informationen zu diesem Thema finden Sie im „Basishandbuch für Computeruntersuchungen für Windows“.

Die Solution Accelerators
Im „Basishandbuch für Computeruntersuchungen für Windows“ werden Prozesse und Tools erörtert, die Sie bei einer internen Computeruntersuchung einsetzen können. In diesem Handbuch werden die vier Phasen des Computeruntersuchungsmodells skizziert: Bewerten, Beziehen, Analysieren und Berichten. Dieses nützliche Modell kann IT-Experten helfen, Untersuchungen so durchzuführen, dass wichtige Ergebnisse sichergestellt werden.
In diesem Handbuch wird auch darauf eingegangen, wann die Polizeibehörden verständigt oder gerichtliche Schritte ergriffen werden sollten. Wenn Sie vor dieser Entscheidung stehen, sollten Sie Ihre Rechtsberater hinzuziehen. Dieses Handbuch enthält Informationen zum Umgang mit Computerkriminalität, zur Kontaktaufnahme mit den zuständigen Strafverfolgungsbehörden sowie zu den Windows Sysinternals-Tools und anderen Windows-Tools, die beim Durchführen von Untersuchungen nützlich sind.
Der andere Solution Accelerator, auf den in diesem Artikel verwiesen wird, das Starter Kit zur Malwareentfernung, bietet eine Anleitung zum Erstellen und Verwenden einer Windows PE-Start-CD, um Malware von einem Computer zu entfernen. Dieses Kit enthält eine Liste von Bedrohungen und eine Reihe von Schutzmaßnahmen, mit denen die potenziellen Auswirkungen dieser Bedrohungen auf eine Organisation eingedämmt werden können. Weiterhin wird unterstrichen, wie wichtig das Entwickeln eines Vorfallreaktionsplans ist, der beim Verdacht eines Malwarebefalls befolgt werden kann. Das Starter Kit zur Malwareentfernung enthält dazu ein aus vier Phasen bestehendes Verfahren, um IT-Experten zu helfen, die Art einer vorliegenden Malware zu bestimmen, ihre Ausbreitung einzudämmen, sie wenn möglich zu entfernen, zu überprüfen, ob sie tatsächlich entfernt wurde, und mit allen weiteren erforderlichen Schritten fortzufahren.

Die Windows PE-CD-ROM
Für eine Untersuchung dieser Art müssen zwei Voraussetzungen erfüllt sein: Es muss eine Windows PE-CD-ROM und ein externes Speichergerät, beispielsweise ein USB-Flashlaufwerk, vorliegen.
Sie wissen wahrscheinlich bereits aus dem Fernsehen, dass Polizeibeamte an einem Tatort nichts verändern dürfen. Aus genau demselben Grund empfiehlt es sich, die Daten der Festplatte, die untersucht wird, sicherzustellen. Im Gegensatz zur CD-ROM des Starter Kits zur Malwareentfernung werden von der Windows PE-Start-CD, die jetzt erstellt wird, Tools nur so ausgeführt, dass an den Daten auf der Festplatte keinerlei Änderungen vorgenommen werden.
Die Windows PE-CD-ROM startet das System in einer begrenzten Windows-Umgebung. Wenn Sie diese Start-CD erstellen, können Sie Tools (z. B. Tools des Starter Kits zur Malwareentfernung) einbeziehen, die für einen bestimmten Zweck vorkonfiguriert sind. Beachten Sie, dass der Computer mindestens über 512 MB RAM verfügen muss. Dies wird von Windows PE vorausgesetzt.
Das im Starter Kit zur Malwareentfernung ausführlich beschriebene Verfahren zum Erstellen der Windows PE-CD-ROM ist recht einfach. Bevor Sie die Start-CD erstellen, müssen Sie das AIK (Automated Installation Kit) von Windows und die Sysinternals-Suite (verfügbar unter microsoft.com/technet/sysinternals/utilities/sysinternalssuite.mspx) installieren, die Sysinternals-Tools wie in Aufgabe 2 des Starter Kits zur Malwareentfernung beschrieben in der Toolliste speichern und alle sonstigen Tools und Dienstprogramme zum Erkennen von Malware installieren. Ausführliche Anweisungen zum Erstellen der CD-ROM finden Sie in den in der Dokumentation des Starter Kits zur Malwareentfernung beschriebenen Schritten.

Das externe USB-Laufwerk
Da bei diesem Vorgang das untersuchte Laufwerk nicht verändert wird, benötigen Sie auch einen USB-Stick oder eine andere externe Festplatte, damit Sie die bei der Untersuchung generierten Ausgabedateien speichern können. (Ein USB-Stick wird als externes Laufwerk empfohlen, weil USB-Geräte von Windows PE automatisch bereitgestellt werden können.) Sie sollten auch eine externe Festplatte verwenden, um ein Abbild der Originalfestplatte zu speichern. Aufgrund all dieser Anforderungen und Möglichkeiten ist es wichtig, Ihre Vorgehensweise im Voraus zu planen, um den gesamten für die Untersuchung erforderlichen Speicherplatz zu berücksichtigen.
Da Sie beim Start einer Untersuchung sicherstellen wollen, dass das Kit nicht manipuliert wurde, müssen Sie sämtliche vorherigen Daten vom externen Festplattenlaufwerk, das zum Speichern der Untersuchungsdateien verwendet wird, entfernen. Dies ist mit einem Festplattenbereinigungsdienstprogramm, das die gesamte beschreibbare Oberfläche des Laufwerks überschreibt, auf einfache Weise möglich. Danach kann die externe Festplatte formatiert und für die Verwendung bei der Untersuchung entsprechend gekennzeichnet werden. Durch diese Vorsichtsmaßnahme wird sichergestellt, dass auf dem Gerät keine Dateien enthalten sind, die das während der Untersuchung gesammelte Beweismaterial verfälschen könnten.
Sie sollten auch ein Formular für die Kette der Beweismittelverwahrung („Chain of Custody“) einbeziehen, damit offiziell dokumentiert ist, wer während der Untersuchung Zugang zum Computer hatte. Das „Basishandbuch für Computeruntersuchungen für Windows“ stellt ein Formular für die Kette der Beweismittelverwahrung zur Verfügung. Sobald Sie das Kit (mit der erforderlichen Start-CD für Windows PE, einem externen Speichergerät und einem Formular für die Kette der Beweismittelverwahrung) zusammengestellt haben, können Sie fortfahren.

Durchführen einer Untersuchung
Jetzt haben Sie alle notwendigen Vorbereitungen abgeschlossen, um eine Untersuchung durchzuführen. Starten Sie zunächst mithilfe der Windows PE-CD-ROM den verdächtigen Computer, wobei Sie sicherstellen müssen, dass in der Startreihenfolge des Computers das CD-ROM-Laufwerk als primäres Startgerät festgelegt ist. Wenn Sie dazu aufgefordert werden, drücken Sie eine beliebige Taste, um das Hochfahren von CD-ROM abzuschließen. Dadurch erhalten Sie Zugriff auf die Tools, die Sie auf der CD-ROM installiert haben.
Das Kit wird hier auf einem Beispielcomputer eingesetzt, um zu demonstrieren, wie Sie von einem „Testbox1“ genannten Computer Informationen sammeln können. Auf dem Computer „Testbox1“ ist dem CD-ROM-Laufwerk der Laufwerkbuchstabe „X:\“ zugewiesen und als Standardspeicherort für die Tools des Starter Kits zur Malwareentfernung „X:\tools“ festgelegt. Um auf die Tools im Kit zuzugreifen, geben Sie ganz einfach Folgendes ein: „cd \tools“.
Es gibt mehrere Tools, die in der Lage sind, die auf einem Computer bereitgestellten Ziellaufwerke zu identifizieren. Das im Sysinternals-Toolverzeichnis enthaltene Dienstprogramm „Bginfo.exe“ kann diese Informationen liefern und sie leicht zugänglich in einem Hintergrundfenster auf dem Desktop anzeigen. Auch der Drive Manager kann alle Laufwerke des Computers einschließlich der Zielfestplattenlaufwerke und des externen USB-Geräts identifizieren. Abbildung 1 zeigt die Datenträgerinformationen für „Testbox1“. Das Startlaufwerk ist „X:\“, das Zielfestplattenlaufwerk ist „C:\“, und das externe USB-Laufwerk ist „F:\“.
Abbildung 1 Anzeigen von Datenträgerinformationen mit dem Drive Manager
Abbildung 1 Anzeigen von Datenträgerinformationen mit dem Drive Manager

Überprüfen auf Malware
Vor einer Untersuchung sollten unbedingt Antimalwaretools ausgeführt werden, um sicherzustellen, dass die Untersuchung nicht durch einen Virus oder einen anderen schädlichen Code verfälscht wird. Der durch das Antimalwaretool generierte Bericht kann ggf. als Beweismittel verwendet werden. Einen Computer nicht auf Malware zu überprüfen, kann dagegen die Untersuchung gefährden sowie ihre Glaubwürdigkeit hinsichtlich Gründlichkeit und Genauigkeit in Frage stellen. Es wird empfohlen, die bereitgestellten Antimalwaretools im schreibgeschützten oder im Berichtsmodus auszuführen.
Im Starter Kit zur Malwareentfernung werden eine Reihe empfohlener Tools beschrieben, zum Beispiel MSRT (Malicious Software Removal Tool) und McAfee AVERT Stinger. Achten Sie beim Ausführen von MSRT (Malicious Software Removal Tool) darauf, die Befehlszeilenoption „/N“ zu verwenden, um das Tool anzuweisen, Malware lediglich zu melden, aber nicht zu versuchen, sie zu entfernen:
x:\tools\windows-KB890830-v1.29.exe /N
Als Ergebnis erhalten Sie eine Berichtdatei, die unter „%windir%\debug\mrt.log“ abgelegt wird.
Wenn Sie McAfee AVERT Stinger ausführen, stellen Sie dieses Tool wie in Abbildung 2 gezeigt ebenfalls auf den Modus „Report only“ (Nur berichten) ein, damit das Tool den Computer nur untersucht, aber keine Änderungen an der Festplatte vornimmt. Vergessen Sie nicht, nach Abschluss dieses Scans einen Bericht des Tools zu speichern.
Abbildung 2 Verwenden Sie in McAfee AVERT Stinger den Modus „Report only“ (Nur berichten)
Abbildung 2 Verwenden Sie in McAfee AVERT Stinger den Modus „Report only“ (Nur berichten)

Speichern wichtiger Dateien
Falls vor der Untersuchung keine Datensicherung der gesamten Festplatte durchgeführt wurde, sollten Sie zumindest wichtige Benutzerdateien sichern. Konfigurationsinformationen können bei Bedarf für eine zukünftige Prüfung verwendet werden. Sammeln Sie zunächst die Registrierungsdateien und -einstellungen, die alle relevanten Informationen darüber enthalten, wie der Computer verwendet wurde und welche Software auf dem System installiert ist.
Um die Registrierungsstruktur des Beispielcomputers „Testbox1“ zu speichern, wird zunächst auf dem entfernbaren Laufwerk „F:\“ ein Ordner erstellt und danach mit den folgenden Befehlen das Datum und die Uhrzeit des Untersuchungsbeginns aufgezeichnet:
f:
Mkdir f:\evidence_files
Date /t >> f:\evidence_files\Evidence_start.txt
Time /t >> f:\evidence_files\Evidence_start.txt
Jetzt wird mithilfe des xcopy-Befehls zum Kopieren des gesamten Konfigurationsverzeichnisses und seiner Inhalte die Registrierungsstruktur gespeichert. Die für Sie relevanten Registrierungsdateien befinden sich in „%windows%\system32\config“. Im Beispiel wird nun Folgendes ausgeführt:
xcopy c:\windows\system32\config\*.* f:\registrybkup /s /e /k /v
Dieser Befehl kopiert alle Konfigurationsinformationen, die im Ordner „config“ enthalten sind. Im Ordner „config“ von „Textbox1“ sind ungefähr 95 MB an Daten gespeichert.
Konzentrieren Sie sich als Nächstes auf Benutzerdaten, die sich an beliebigen Speicherorten auf der Festplatte befinden können. In diesem Beispiel werden nur Daten aus einem Verzeichnis namens „c:\HR“ kopiert. Um sicherzustellen, dass die Daten vollständig gesammelt werden, werden mit dem folgenden xcopy-Befehl alle im Verzeichnis und in seinen Unterverzeichnissen enthaltenen Daten kopiert:
Mkdir f:\evidence_files\HR_Evidence
Mkdir f:\evidence_files\documents_and_settings
Mkdir f:\evidence_files\users
xcopy c:\HR\*.* f:\evidence_files\HR_Evidence /s /e /k /v
Jetzt können Sie sich den Daten in persönlichen Ordnern zuwenden. Auch hier sollen sämtliche Daten kopiert werden, die in diesen Verzeichnissen und ihren Unterverzeichnissen enthalten sind. Dazu werden die folgenden Befehle verwendet:
Xcopy c:\documents and settings\*.* f:\evidence_files\documents_and_settings /s /e /k /v

Xcopy c:\users\*.* f:\evidence_files\users /s /e /k /v
In diesem Beispiel wurden über 500 MB an Daten gesammelt, die jetzt bei Bedarf analysiert werden können. Wie Sie sehen, ist die Menge der gesammelten Daten möglicherweise sehr hoch, vor allem dann, wenn Sie mit Audio-, Video- und Fotodateien zu tun haben. Trotzdem ist es wichtig, möglichst viele Originaldaten sicherzustellen, weil in einer Untersuchung u. U. nicht nur das gesammelte physische Beweismaterial erforderlich ist, sondern auch die Gewährleistung, dass diese Daten durch den Sammelprozess nicht verändert wurden. Im Idealfall sollten Sie für die Untersuchung ein vollständiges Abbild des Datenträgers anfertigen, aber dies kann aufgrund von Größenbeschränkungen schwierig sein. Es erübrigt sich, darauf hinzuweisen, wie wichtig eine Ermittlung des möglicherweise für die Untersuchung erforderlichen Speicherplatzes bereits im Voraus ist.

Sammeln zusätzlicher Informationen
Systemdateien können bei der Sammlung von Beweismaterial ebenfalls eine nützliche Ressource sein, aber das Sammeln dieser Daten erfordert evtl. eine genauere Untersuchung des Zielcomputers, da sich diese Dateien nicht immer am selben Ort befinden. Dennoch sind bestimmte Arten von Dateien diese Suche wert, weil sie nützliche Erkenntnisse liefern können. So sind beispielsweise in Auslagerungsdateien Informationen darüber enthalten, auf welche Dateien über den Speicher zugegriffen wurde. Darüber hinaus können Auslagerungsdateien sogar ausführliche Informationen zur Nutzung liefern. Auf ähnliche Weise liefern Webbrowserdaten und Cookies Informationen zu Verhaltensweisen und Verhaltensmustern beim Surfen im Internet.
Diese Daten können manchmal nur durch intensive Nachforschungen aufgespürt werden, vor allem dann, wenn ein Benutzer seine Konfiguration so geändert hat, dass Daten nicht an den üblichen Standardspeicherorten gespeichert werden. Es gibt mehrere Sysinternals-Tools, die Ihnen bei der Suche nach wichtigen Dateien helfen können. In Abbildung 3 sind fünf nützliche Anwendungen mit den jeweiligen Beschreibungen aufgeführt.
Figure 3 Tools zum Suchen relevanter Dateien und Daten (Close Figure 3)

Anwendung | Beschreibung
AccessChk | Zeigt den Zugriff auf Dateien, Registrierungsschlüssel und Windows-Dienste durch den von Ihnen angegebenen Benutzer oder eine angegebene Gruppe an.
AccessEnum | Zeigt an, welche Benutzer auf welche Verzeichnisse, Dateien und Registrierungsschlüssel eines Computers zugreifen dürfen. Diese Informationen können Sie nutzen, um Bereiche ausfindig zu machen, an denen Berechtigungen nicht ordnungsgemäß zugewiesen sind.
Du | Zeigt die Datenträgernutzung nach Verzeichnis an.
PsInfo | Zeigt Informationen über einen Computer an.
Strings | Sucht in Binärabbildern nach ANSI- und UNICODE-Zeichenfolgen.

Tom Cloward, CCE, CISSP, befasst sich als Programmmanager bei Microsoft mit der Bereitstellung von Solution Accelerators für IT-Experten auf den Gebieten Sicherheit und Kompatibilität. Er arbeitet seit über 15 Jahren in der Software- und IT-Branche und hat sich auf die Bereiche IT-Sicherheit, Forensik und Kompatibilität spezialisiert.
Frank Simorjay, CISSP, CET, ist technischer Programmmanager und arbeitet als Sicherheitsexperte für die Gruppe „Microsoft Solution Accelerator – Security and Compliance“. Er entwickelt Sicherheitslösungen für Kunden von Microsoft. Sein jüngstes Produkt ist das bei Microsoft TechNet erhältliche Starter Kit zur Malwareentfernung.


 Netzwerk: Der Microsoft Security Intelligence Report
Netzwerk Tim Regen

Der Microsoft Security Intelligence Report
Kurz zusammengefasst:
  • Trends bei der Veröffentlichung von Softwaresicherheitsrisiken sowie bei Exploits und Malware
  • Die Auswirkung von Bedrohungen für verschiedene Windows-Versionen
  • Die am stärksten und am wenigsten infizierten Bereiche der Welt

Daten von vielen hundert Millionen mit dem Internet verbundenen Systemen und der weltweit am stärksten ausgelasteten Onlinedienste vermitteln Microsoft ein einzigartiges Bild der Sicherheitsbedrohungen, denen sich Internetbenutzer heute gegenüber sehen.
Microsoft veröffentlicht diese Daten zweimal jährlich im Security Intelligence Report (SIR). Mitwirkende an dem Bericht sind unter anderem das Microsoft®-Malwareschutzcenter (MMPC), das Microsoft Security Response Center (MSRC), die Trustworthy Computing Group (TwC) sowie zahlreiche andere Produktgruppen. Der Bericht bietet ein detailliertes Bild neuer Trends bei der Veröffentlichung von Softwaresicherheitsrisiken, Malware und möglicherweise unerwünschter Software wie Spyware und Adware. Er umfasst weiterhin Details dazu, welche Leistung verschiedene Versionen des Windows-Betriebssystems gegenüber Bedrohungen gezeigt haben und welche Regionen der Welt am meisten mit Malware und anderer schädlicher Software infiziert sind. Die aktuelle Version des Berichts, der sich auf die im ersten Halbjahr 2007 beobachteten Trends konzentriert, umfasst einen neuen Abschnitt über Exploits in Bezug auf Sicherheitsrisiken. Wenn Sie für die Computersicherheit verantwortlich sind oder sich dafür interessieren, ist dieser Bericht sicher von großem Interesse für Sie, da er über Bedrohungen im Zusammenhang mit dem Internet informiert.
Der aktuelle SIR offenbart, dass bei der Sicherheitsforschung mehr Sicherheitsrisiken in der Software aller Anbieter festgestellt werden. Tatsächlich wurden allein im ersten Halbjahr 2007 über 3.400 neue Softwaresicherheitsrisiken offen gelegt! Doch trotz dieser bedeutenden Zahl nimmt der Gesamtprozentsatz offen gelegter Sicherheitsrisiken bei Betriebssystemen ab.
Was bedeutet dies? Eine Möglichkeit besteht darin, dass sich die Sicherheitsforschung stärker auf Anwendungen konzentriert, da sich die Sicherheit von Betriebssystemen fortwährend verbessert. Da zudem die Anzahl neuer Anwendungen die Anzahl neuer Betriebssysteme überholt, ist die Verbreitung von Anwendungen wahrscheinlich eine treibende Kraft bei diesen neuen Trends zur Veröffentlichung von Sicherheitsrisiken.
Im Jahr 2006 hatten 29,3 Prozent der bekannten Sicherheitsrisiken in Microsoft-Produkten einen öffentlich verfügbaren Exploitcode, während dies am 1. August 2007 nur bei 20,9 Prozent der bekannten Sicherheitsrisiken der Fall war. Obwohl die Anzahl der Sicherheitsrisiken zunimmt, bleibt das Verhältnis des Exploitcodes konstant und hat sogar leicht abgenommen. Bei neueren Produkten ist es schwieriger, Exploitcode zu finden. Wir haben einen Vergleich nach Produkten durchgeführt, der nahe legt, dass neuere Versionen von Produkten weniger gefährdet sind als Produktversionen, die seit längerer Zeit auf dem Markt sind. Im Durchschnitt nimmt die Ausnutzbarkeit eines Sicherheitsrisikos über den Produktlebenszyklus hinweg ab, sodass bei der Mehrzahl der Produkte spätere Versionen weniger ausnutzbare Sicherheitsrisiken aufweisen. Dies ist am offensichtlichsten bei den Windows- und Microsoft Office System-Produkten. Spätere Versionen von beiden (Windows Server® 2003, Windows Vista®, Office 2003 und das 2007 Office System) zeigen eine deutliche Abnahme bei der Anzahl der Sicherheitsrisiken während des Produktlebenszyklus.
Der SIR gewährt wertvolle Einblicke in die Trends bei Malware. Diese Trends sind Hinweise auf die derzeit für Angriffe auf Benutzer verwendeten Taktiken. Die Betrachtung von Daten aus verschiedenen wichtigen Primärquellen, darunter Microsoft Exchange Hosted Services (EHS), Windows Live® OneCare und Windows Live OneCare-Sicherheitsscanner, das Windows-Tool zum Entfernen von Malware (Malicious Software Removal Tool, MSRT) und Windows Defender bietet eine Sichtweise der Bedrohungen aus verschiedenen Blickwinkeln.
Social Engineering spielt eine zunehmend wichtige Rolle bei der Malwareverteilung. Solche Angriffe täuschen Benutzer oft, sodass diese eine Aktivität durchführen, durch die sich die Wirksamkeit der Sicherheitsmechanismen verringert. EHS-Daten deuten darauf hin, dass im ersten Halbjahr 2006 klassische E-Mail-Würmer mit 95 Prozent der in E-Mails entdeckten Malware die größte per E-Mail übertragene Bedrohung darstellten. Zu Beginn des zweiten Halbjahrs 2006 hat sich diese Zahl auf 49 Prozent verringert und ist im ersten Halbjahr 2007 konstant geblieben (siehe Abbildung 1). Phishing und E-Mails, die IFrame-Angriffe enthielten, machten 27 Prozent der E-Mail-Malwareerkennung im zweiten Halbjahr 2006 aus und stiegen im ersten Halbjahr 2007 auf 37 Prozent an. Heruntergeladene Trojaner, die in E-Mails übermittelt wurden, erreichten mit 20 Prozent im zweiten Halbjahr 2006 einen Höhepunkt und fielen im ersten Halbjahr 2007 auf 7 Prozent ab.
Abbildung 1 Die Zusammensetzung infizierter E-Mails im ersten Halbjahr 2007
Abbildung 1 Die Zusammensetzung infizierter E-Mails im ersten Halbjahr 2007
Von Windows Live OneCare und vom Windows Live OneCare-Sicherheitsscanner (safety.live.com) gesammelte Telemetriedaten zeigen, dass die Infektionsraten von Viren, Hintertüren, Kennwortdieben und Daten stehlenden Trojanern im ersten Halbjahr 2007 zugenommen haben.
Das MSRT ist auf die Identifizierung und Entfernung verbreiteter Malware auf Kundencomputern ausgelegt. Es wird hauptsächlich als kritisches Update über Windows Update (WU), Microsoft Update (MU) und automatische Updates (AU) veröffentlicht. In den letzten zwei Jahren hat das MSRT 50,3 Millionen Infektionen auf weltweit 20,5 Millionen Computern entfernt. Die Gesamtzahl von MSRT-Ausführungen beträgt bisher 7,4 Milliarden, wobei 1,9 Milliarden Ausführungen im ersten Halbjahr 2007 stattfanden.
Das MSRT ist eine hervorragende Datenquelle für Microsoft und seine Kunden. Die vom MSRT beobachteten Infektionsraten sind bei Windows Vista- und Windows XP SP2-Systemen weitaus niedriger als bei älteren Windows-Betriebssystemen, wie Abbildung 2 zeigt. Durch das MSRT wurde Malware auf 60 Prozent weniger Computern entfernt, auf denen Windows Vista ausgeführt wird, als auf Computern, auf denen Windows XP SP2 ausgeführt wird, und 91,5 Prozent weniger Malware als auf Computern, auf denen Windows XP ohne installiertes Service Pack ausgeführt wird. Interessanterweise ist die Anzahl von Desinfektionen pro Computer im Lauf der Zeit konstant geblieben und beträgt durchschnittlich 2,2 Desinfektionen pro infiziertem Computer.
Abbildung 2 Durch das MSRT im ersten Halbjahr 2007 bereinigte Betriebssystemversionen
Abbildung 2 Durch das MSRT im ersten Halbjahr 2007 bereinigte Betriebssystemversionen
Im Allgemeinen wird vom MSRT verhältnismäßig mehr Malware in Entwicklungsländern als in Industriestaaten gefunden. Die am stärksten infizierten europäischen Länder beispielsweise sind Albanien und die Türkei, während Italien und Finnland die am wenigsten infizierten sind. Im asiatisch-pazifischen Raum sind die Mongolei und Thailand die am stärksten infizierten Länder und Neuseeland und Japan die am wenigsten infizierten. Die USA sind verhältnismäßig weniger infiziert als die meisten Länder und Regionen in Nord- und Südamerika, und die Infektionsrate entspricht ungefähr der Durchschnittsrate weltweit. Im Durchschnitt hat MSRT im ersten Halbjahr 2007 jeweils einen von 216 Computern bereinigt.
Windows Defender wird auf Windows Vista, Windows XP und Windows Server 2003 ausgeführt. Insgesamt wurden im ersten Halbjahr 2007 50,7 Millionen möglicherweise unerwünschter Softwareprogramme entdeckt, wobei im Vergleich zu Computern, auf denen Windows XP SP2 ausgeführt wurde, 2,8 Mal weniger Programme auf Computern entdeckt wurden, auf denen Windows Vista ausgeführt wurde. Ebenso war die Anzahl von Erkennungen von möglicherweise unerwünschter Software bei Computern, auf denen Windows Vista ausgeführt wurde, halb so groß wie die Anzahl bei Computern, auf denen Windows Server 2003 ausgeführt wurde.
Obwohl diese Statistiken alle recht interessant sind, fragen Sie sich vielleicht jetzt, wie sie zu Ihrem Schutz und zum Schutz Ihrer Umgebung beitragen. Im aktuellen SIR wird jeder Hauptabschnitt mit einer Zusammenfassung der wesentlichen Themen des betreffenden Abschnitts und einem Satz von „Strategien, Schutzmaßnahmen und Gegenmaßnahmen“ eingeleitet. Mithilfe dieser Listen erhalten Sie schnell einen Überblick über die wichtigsten Ergebnisse in jedem Abschnitt des Berichts.
Zudem können Sie die Daten, Einblicke und Anleitungen im SIR zum Bewerten und Verbessern Ihres aktuellen Sicherheitsansatzes angesichts der sich ständig ändernden Bedrohungen verwenden. Der vollständige Bericht, der Strategien, schadensbegrenzende Maßnahmen und Gegenmaßnahmen auf Grundlage der wichtigsten Ergebnisse bietet, kann unter microsoft.com/sir heruntergeladen werden.

Tim Regen ist als Produktmanager im Microsoft-Malwareschutzcenter (Microsoft Malware Protection Center, MMPC) tätig. Er ist für die Produktion des Microsoft Security Intelligence Report (SIR) verantwortlich. Die Autoren des SIR sind Jeff Jones (Direktor, Microsoft Trustworthy Computing Group), Jeff William (Director für das MMPC), Mike Reavey (Group Manager, Microsoft Security Response Center) und Ziv Mador (leitender Programmmanager und Response Coordinator, MMPC).


 Netzwerk: Aufsp&#252;ren schwer fassbarer Netzwerkprobleme
Netzwerk Christopher Stoneff

Aufspüren schwer fassbarer Netzwerkprobleme
Kurz zusammengefasst:
  • Die üblichen Ursachen für Netzwerkprobleme
  • Über das Offensichtliche hinausblicken
  • Wenn Tools zur Problembehandlung nicht helfen
  • Warum Verbindungsbeschränkungen konfiguriert werden müssen

Es ist wahrscheinlich schon oft passiert: Ihr Computer kann nicht mit anderen Computern kommunizieren, und Sie wissen nicht, woran das liegt. Ihr Verwaltungssystem befindet sich in einem Segment eines gerouteten Netzwerks, das über einen Router wie beispielsweise Microsoft Internet
Security and Acceleration Server (ISA) oder ein anderes Hardwaregerät mit anderen Netzwerksegmenten verbunden ist. Wenn Sie versuchen, 10, 20 oder sogar 100 Systeme zu verwalten, gibt es keine Probleme. Doch wenn Sie dann 500 Systeme verwalten möchten, kann Ihr Computer im Netzwerk nur mit den Computern kommunizieren, zu denen bereits offene Verbindungen bestehen. Sie können nicht mit anderen Systemen kommunizieren, und Sie haben keinen Zugriff auf das Internet, doch kein anderer Benutzer hat mit diesem Phänomen zu kämpfen, selbst nicht in Ihrem Segment. Wo würden Sie mit der Suche beginnen?

Analysieren des Problems
In dieser Situation wird am häufigsten angenommen, dass die Verwaltungssoftware fehlerhaft ist. Viele proaktive Verwaltungstools sind mit Ihren Systemen verbunden und verwalten diese, doch bisweilen können diese Tools selbst Ursache des Problems sein, das Sie aufzuspüren versuchen. Das ist darauf zurückzuführen, dass ein proaktives Verwaltungstool im Namen einer besseren Verwaltung Tausende von Verbindungen zu Ihren Geräten erstellen kann. Windows® hält diese Verbindungen standardmäßig zwei Minuten lang offen, selbst wenn sie im Leerlauf sind, es sei denn, dass das Tool, die Anwendung oder der Dienst sie länger aktiv hält. Obwohl Ihr Verwaltungssystem also bereits zwei Minuten lang nicht mit anderen Computern kommuniziert hat, können dennoch über 1.000 Verbindungen offen sein. (Sie können sich offene Verbindungen durch Ausführen von NETSTAT in einer Eingabeaufforderung anzeigen lassen. Der NETSTAT-Befehl zeigt Ihnen alle offenen und ausstehenden Verbindungen zu und von Ihrem System an, sowie Verbindungen, die geschlossen werden. Außerdem wird der Status aller Verbindungen angezeigt. Beschreibungen der Statusmeldungen können in RFC 793 unter tools.ietf.org/html/rfc793 eingesehen werden.)
Um fehlerhafte Verwaltungssoftware auszuschließen, können Sie eine Batchdatei erstellen, die Verbindungen zu den Remotesystemen einrichtet. Wenn das gleiche Problem beim Ausführen der Batchdatei auftritt, wissen Sie, dass es nicht an der Verwaltungssoftware und ihren Threads gelegen hat. Dies ist ein Beispiel für den Inhalt der erforderlichen Batchdatei:
Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...
Wenn das fragliche Verwaltungsprogramm seinen eigenen Netzwerk- und Authentifizierungsstapel implementiert hat, könnte es der Übeltäter sein, doch bei agentlosen Lösungen, um die es sich bei den meisten dieser Verwaltungspakete handelt, verwendet das Tool die Netzwerk- und Authentifizierungsstapel des Betriebssystems zum Durchführen von Netzwerkvorgängen. Die Verwendung einer Batchdatei, die genauso viele Netzwerkverbindungen startet, ohne dass der Fehler verursacht wird, zeigt, dass das Problem nicht auf die Verwendung der Netzwerk- und Authentifizierungsstapel des Betriebssystems durch das Programm zurückzuführen ist, da die Batchdatei sie ebenfalls verwendet.

Protokolle und Fehlermeldungen, die nicht hilfreich sind
Sie dürften bemerkt haben, dass Sie beim Versagen der Verbindungen falsche Fehlerinformationen erhalten haben: Fehler 53 (der Netzwerkpfad wurde nicht gefunden), Fehler 64 (der Netzwerkname wurde gelöscht) und Fehler 1203 (kein Netzwerkanbieter hat den angegebenen Netzwerkpfad akzeptiert). Alle diese Fehler könnten normalerweise auf Probleme mit der Namensauflösung hinweisen, doch alle anderen Computer haben damit und mit der Herstellung von Verbindungen zu denselben Systemen keine Probleme. Um zu überprüfen, dass der Fehler nicht bei Ihren Maschineneinstellungen liegt, führen Sie einfach „ipconfig“ aus, um zu bestätigen, dass die Einstellungen richtig sind.
Da das Phänomen in Ihrem Verwaltungssystem angesiedelt zu sein scheint, sollten Sie sich die die Ereignisprotokolle ansehen. Eine Suche in den Anwendungsprotokollen ist ergebnislos, doch im Systemprotokoll finden Sie ein Warnereignis 4226 aus der Ereignisquelle TCP/IP, in dem es heißt, dass die maximale Anzahl von Verbindungen erreicht wurde (siehe Abbildung 1).
Abbildung 1 Die TCP-Verbindungsbeschränkung wurde erreicht
Abbildung 1 Die TCP-Verbindungsbeschränkung wurde erreicht
Eine gründliche Suche in der Microsoft® Knowledge Base nach Verbindungsbeschränkungen offenbart, dass unvollständigen Verbindungen Verbindungsbeschränkungen auferlegt werden, was jedoch nicht für abgeschlossene Verbindungen gilt. Sie haben die Möglichkeit, die folgenden Registrierungseinträge unter HKLM\System\CurrentControlSet\Services\TCPIP anzupassen, um die oben genannten Faktoren zu steuern: TcpNumConnections wird verwendet, um die maximale Anzahl von Verbindungen festzulegen, die bei TCP gleichzeitig offen sein können (der Standardwert ist 10). TCPTimedWaitDelay legt die Zeit fest, in der eine Verbindung im TIME_WAIT-Status verbleibt, wenn sie geschlossen wird. Die Standardhalbwertzeit beträgt 120 Sekunden, d. h., eine Verbindung ist praktisch 4 Minuten lang in Gebrauch. Schließlich spielt MaxFreeTcbs auch eine Rolle bei der maximalen Anzahl von Verbindungen. Wenn alle TCP-Steuerblöcke in Gebrauch sind, sollte TCP Verbindungen freigeben, die im TIME_WAIT-Status aufgeführt werden, um mehr Verbindungen zu erstellen, obwohl TCPTimedWaitDelay noch nicht abgelaufen ist. TCPTimedWaitDelay hat einen Wertbereich von 30-300 Sekunden (0x1E – 0x12C).
Abhängig von Ihrem Szenario dürften diese Registrierungsänderungen zu einer leichten Verbesserung der Gesamtleistung führen. Eine weitere Möglichkeit besteht darin, die TCPIP.sys-Datei zu patchen, um diese Beschränkungen zu entfernen, doch dies führt nur zu Verbesserungen in P2P-Anwendungen.

Netzwerkerfassungen
Nach weiteren erfolglosen Versuchen zur Lösung der Verbindungsprobleme scheint eine Netzwerkerfassung der beteiligten Computer vielversprechend. Beim Ausführen von Microsoft Netzwerkmonitor (Netmon) wurden Erfassungen erstellt, die genau dieselben Ergebnisse zeigten, die in den Verwaltungstools und Testskripts angezeigt wurden: erst funktioniert alles, dann auf einmal nicht mehr, ohne dass ein Fehler angezeigt wird.
Abbildung 2 zeigt das Ergebnis beim Ausführen von Netmon, wobei eine erfolgreiche Kommunikation zwischen den ersten n Systemen angezeigt wurde. Beachten Sie, dass Bestätigungen von RPC-Anforderungen erhalten werden. Dies ist genau das, was Sie sehen wollen – erfolgreiche bidirektionale Kommunikation.
Abbildung 2 Erfolgreiche Kommunikation in Netmon
Abbildung 2 Erfolgreiche Kommunikation in Netmon
Jetzt müssen Sie sich die Erfassungen aus dem Verwaltungssystem und den Remotecomputern ansehen, die den Fehler 53/1203 aufzuweisen scheinen. Wie erwartet, gibt es nichts zu sehen, da die Computer nicht miteinander kommunizieren. In der Netzwerkerfassung in Abbildung 3 hat das Verwaltungssystem die IP-Adresse aufgelöst und versucht, über Port 445 (dem Microsoft-SMB-Port) eine Verbindung zum System herzustellen, erhält aber nie eine Antwort.
Abbildung 3 Versuche, über Port 445 eine Verbindung zum System herzustellen, führen zu keiner Antwort
Abbildung 3 Versuche, über Port 445 eine Verbindung zum System herzustellen, führen zu keiner Antwort
Der Fehler, der gemeldet wird, wenn mehr Threads als die derzeitigen Verbindungsmöglichkeiten Ihres Computers vorhanden sind, ist nicht immer konsistent. In einigen Fällen könnte Ihnen das Quellsystem einen Fehler 53 melden, der anzeigt, dass Sie Namensauflösung erhalten haben, aber die IP-Adresse einfach nicht gefunden werden konnte. Dies ist ein Hinweis auf einen DNS, der eine Adresse bereitstellt, zu der Sie keine Verbindung herstellen können. Möglicherweise erhalten Sie einen Fehler 1203, der anzeigt, dass kein Computer auf den angeforderten Namen oder die IP-Adresse geantwortet hat. Fehler 1203 zeigt in diesem Fall an, dass der DNS für Sie nicht verfügbar ist. Sie werden feststellen, dass dies der Fall ist, wenn Sie „nslookup“ ausführen.
Zu diesem Zeitpunkt sind Sie wahrscheinlich frustriert, aber es gibt noch weitere Optionen. Die meisten Benutzer werden aufgrund der Art und Weise, wie sich dieses Problem darstellt, nicht einmal in Erwägung ziehen, sich die Verbindungsinfrastruktur anzusehen: Ihr Computer ist der einzige, der keine Verbindung zum übrigen Netzwerk herstellen kann, und die Ereignisprotokolle zeigen, dass Ihr Computer die maximale Anzahl zulässiger Verbindungen erreicht hat, sodass das Problem nicht an der Architektur liegen dürfte.
Obwohl die vielen tausend Verbindungen, die von Ihrer Verwaltungslösung erstellt werden, nicht gleichzeitig initiiert werden, bedeuten Übertragungs-Keep-Alives und Verbindungstimeouts möglicherweise, dass jeweils mehr Verbindungen offen sind als Sie vielleicht denken. Daher müssen Sie auch die Systeme untersuchen, die Ihr übriges Netzwerk verbinden.
Im Folgenden soll dies näher erläutert werden. Wie bereits erwähnt, durchläuft der Netzwerkverkehr durch Ihr Netzwerk Switches, Router und vielleicht auch Firewalls. An einem beliebigen Punkt, wobei es sich normalerweise um den Router oder die Firewall handelt, liegt u. U. ein Angriffserkennungssystem vor. Verwaltete Switches und Router können ebenfalls eine Datenverkehrfilterung verwenden. Sie oder die Person, die diese Geräte steuert, muss die Protokolle auf Fehler oder Warnungen hin überprüfen. Das Kommunikationsproblem könnte durchaus auf diese Systeme zurückzuführen sein.
Da Sie Verbindungen von einem internen System zu anderen internen Systemen herstellen, stellen Sie möglicherweise fest, dass keine Warnungen generiert werden, weil Warnungen für das Gerät nicht konfiguriert wurden oder weil es sich bei dem Problem nicht um einen Eindringversuch oder DoS-Angriff (Denial of Service) handelt. Auch hier sollten Sie mit den Protokollen beginnen. Bei ISA Server beispielsweise finden Sie diese Protokolle in der ISA Server-Verwaltungskonsole unter Arrays\<Arrayname>Monitoring (Überwachung)\Logging (Protokollierung).
Wenn Sie durch eine Richtlinie blockiert werden, können Sie (im Fall von ISA Server) nach folgenden Ergebniscodes suchen, wobei die Quell-IP-Adresse Ihr Verwaltungscomputer ist:
  • 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
  • 0xc004000d FWX_E_POLICY_RULES_DENIED
  • 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED
Wenn Sie solche Ergebnisse finden, haben Sie die Ursache Ihrer Konnektivitätsprobleme identifiziert.

Implementieren der Lösung
Jetzt, da Sie das Problem identifiziert haben, kann die Lösung einfach implementiert werden. Oft wird dies aber aufgrund von Abteilungsrichtlinien erschwert. Bevor Sie Änderungen vornehmen, stellen Sie sicher, dass Sie über die entsprechenden Berechtigungen verfügen, denn das Erstellen von Ausschlüssen bei den Sicherheitskonfigurationen Ihrer Firewalls, Router und/oder Angriffserkennungssysteme ist nicht immer zulässig.
ISA Server wird hier erneut als Beispiel herangezogen, und in den folgenden Schritten wird aufgezeigt, wie die maximale Anzahl von Verbindungen für einen bestimmten Host oder für alle Computer im Netzwerk (wie in Abbildung 4 dargestellt) erhöht werden kann. Öffnen Sie die ISA Server-Verwaltungskonsole, und navigieren Sie zu Arrays\<Arrayname>\Konfiguration\Allgemein\Flutabwehreinstellungen konfigurieren.
Abbildung 4 Erhöhen Sie die maximale Anzahl von Verbindungen für einen Host oder alle Computer, die ISA Server verwenden.
Abbildung 4 Erhöhen Sie die maximale Anzahl von Verbindungen für einen Host oder alle Computer, die ISA Server verwenden.
Bei den beiden Einstellungen, die von Interesse sind, handelt es sich um die maximale Anzahl gleichzeitiger TCP-Verbindungen pro IP-Adresse und die maximale Anzahl von TCP-Verbindungsanforderungen pro Minute pro IP-Adresse. Die maximale Anzahl gleichzeitiger TCP-Verbindungen pro IP-Adresse ist in der Regel auf einen Wert eingestellt, der ausreichen würde, wenn keine aktive Verwaltung stattfindet, das heißt, kein einzelner Computer stellt schnell aktive Verbindungen zu Tausenden von anderen Computern her. In ISA Server beträgt die standardmäßige Beschränkung für die maximale Anzahl gleichzeitiger TCP-Verbindungen 160. Die maximale Anzahl von TCP-Verbindungsanforderungen pro Minute pro IP-Adresse ist so ausgelegt, dass der Schaden und die Sichtbarkeit bei Netzwerkscans eingeschränkt werden. Die Standardbeschränkung beträgt 600 Verbindungsanforderungen pro Minute pro IP.
Wie bereits erwähnt, hält Windows eine Verbindung für eine Dauer von zwei Minuten aktiv, vorausgesetzt, nichts anderes versucht, die Verbindung aktiv zu halten, selbst wenn die Verbindung nicht in Gebrauch ist. Das heißt, dass die Verbindung aktiv bleibt, selbst wenn Sie einen Computer bereits erfolgreich verwaltet haben und nicht mehr mit ihm kommunizieren müssen. Diese offene Verbindung wird bei der Gesamtzahl der Ihnen zugeteilten Verbindungen berücksichtigt. Wenn dieser Prozess ohne Entfernen von Verbindungen mehr als 160 Mal wiederholt wird, werden Sie feststellen, dass alle Verbindungsversuche von Ihrem Router abgewiesen werden. Selbst wenn Ihr Verwaltungsprogramm aktiv eine Sitzung beendet, könnte Windows die Verbindung durchaus in einem time_wait-Status belassen und darauf warten, dass der Zielcomputer der Trennung der Sitzung zustimmt.
Beginnen Sie mit Anpassungen beim vermutlichen Übeltäter: die maximale Anzahl gleichzeitiger TCP-Verbindungen pro IP-Adresse. Diese sollte so festgelegt werden, dass Ihr Verwaltungscomputer in der Lage ist, alle erforderlichen Verbindungen zu erstellen, damit die Systeme verwaltet werden können, ohne dass der Zugriff verweigert wird. Klicken Sie auf die Schaltfläche „Bearbeiten“ neben der Einstellung, und ändern Sie die Werte.
Die nächste Eingabeaufforderung (siehe Abbildung 5) hat ein Feld für die Beschränkung, bei der es sich um die standardmäßige, für alle Clients geltende Beschränkung handelt. Die benutzerdefinierte Ausnahme gilt für alle Computer, Netzwerke und so weiter, die auf der Registerkarte „IP-Ausnahmen“ des Flutabwehrdialogs definiert sind. Wenn Sie wünschen, dass alle Computer mehr Verbindungen erstellen können, ändern Sie den Beschränkungswert. Um die Ausnahme nur für Ihren Verwaltungscomputer zu konfigurieren, passen Sie die benutzerdefinierte Ausnahme an und fügen Ihren Computer der Registerkarte „IP-Ausnahmen“ hinzu. Es ist im Allgemeinen vorzuziehen, die Ausnahme nur für den eigenen Computer zuzulassen.
Abbildung 5 Standardmäßige Verbindungsbeschränkung und benutzerdefinierte Verbindungsbeschränkung
Abbildung 5 Standardmäßige Verbindungsbeschränkung und benutzerdefinierte Verbindungsbeschränkung
Wenn Sie die benutzerdefinierte Ausnahme nur zum Ändern des Werts bei bestimmten Systemen verwenden möchten, ändern Sie den Wert im Feld zur benutzerdefinierten Ausnahme, und klicken Sie auf „OK“. Dann fügen Sie Ihren Computer auf der Registerkarte „IP-Ausnahmen“ im Flutabwehrdialog hinzu. Um nur Ihren Computer zur Ausnahmeliste hinzuzufügen, klicken Sie auf der Registerkarte „IP-Ausnahmen“ auf „Hinzufügen“, um das Dialogfeld „Computersätze“ aufzurufen. Klicken Sie auf „Neu“, um einen neuen Netzwerksatz zu erstellen, der Ihr(e) System(e) enthält, wenn ein Netzwerksatz, der diese Computer enthält, nicht bereits vorhanden ist. Wählen Sie diesen Netzwerksatz aus, und klicken Sie auf „Hinzufügen“, um den Netzwerksatz „Interne Netzwerke“ hinzuzufügen. Klicken Sie anschließend auf „Schließen“. Wählen Sie den Netzwerksatz „Interne Netzwerke“ erneut aus, und klicken Sie auf „Bearbeiten“. Hierdurch werden die Eigenschaften für „Interne Netzwerke“ geöffnet (siehe Abbildung 6). Klicken Sie in diesem Dialogfeld auf „Hinzufügen“, um ein Untermenü aufzurufen, in dem Sie einen Computer, einen Adressbereich oder ein Subnetz hinzufügen können. Wählen Sie „Computer“ aus. Geben Sie einen Namen zur Identifizierung des Eintrags, die IP-Adresse des Computers und eine Beschreibung ein, damit niemand, der diesen Eintrag später sieht, Ihr System möglicherweise entfernt (siehe Abbildung 7). Klicken Sie auf „OK“, um Ihr System hinzuzufügen, und dann erneut auf „OK“, um die Ausnahme hinzuzufügen. Nachdem diese Änderungen durchgeführt wurden, müssen Sie die Einstellungen übernehmen.
Abbildung 6 Einstellungen für Eigenschaften interner Netzwerke
Abbildung 6 Einstellungen für Eigenschaften interner Netzwerke
Abbildung 7 Geben Sie den Computernamen, die IP-Adresse und eine Beschreibung ein, um sicherzustellen, dass Ihr System nicht entfernt wird.
Abbildung 7 Geben Sie den Computernamen, die IP-Adresse und eine Beschreibung ein, um sicherzustellen, dass Ihr System nicht entfernt wird.
Führen Sie einen weiteren Versuch mit Ihrem proaktiven Verwaltungstool aus. Sie dürften feststellen, dass sich die Leistung sehr verbessert hat und die Verbindung nicht versagt, zumindest nicht aufgrund des Netzwerkverkehrs. Letzten Endes hat sich herausgestellt, dass das Problem nicht in der Anzahl von Verbindungen bestand, die von der Software initiiert wurde, sondern an einem Mangel richtiger Planung für die Verbindungen, die die Unterbrechung verursacht haben.

Gelernte Lektionen
Die größten Schwierigkeiten bereiten in der Regel wirklich schwer fassbare IT-Probleme und deren Lösung. Es sind die Probleme, die nicht vom Endbenutzer geschaffen oder vom Serverteam verursacht wurden, Probleme, die das Helpdesk nicht kennt und die Sie wahrscheinlich leider selbst lösen müssen. Es gibt eine Vielzahl von Tools, mit denen Sie Probleme beheben, isolieren und lösen können, doch manchmal reichen diese Tools nicht aus. Bisweilen liefern sie falsche Ergebnisse. In diesen Fällen müssen Sie klüger sein als die Tools.
Wenn Sie das nächste Mal zwischen einer Reihe von Computern in Ihrem Netzwerk ohne offensichtliche Erklärung keine Verbindungen herstellen können, probieren Sie die hier beschriebenen Schritte aus. Es besteht durchaus die Möglichkeit, dass Sie das Problem durch das Befolgen der Schritte, eine nähere Betrachtung Ihrer Verwaltungssoftware und das richtige Einstellen zulässiger Verbindungen am Ende lösen können.

Christopher Stoneff ist Produktmanager bei Lieberman Software (liebsoft.com), einem Softwareentwickler im Bereich Sicherheit und Systemverwaltung. Chris Stoneff verfügt über mehr technische Zertifizierungen als ein normaler Mensch eigentlich haben sollte. Sein Interesse gilt nicht nur der Frage, wie etwas auf eine bestimmte Weise funktioniert, sondern auch warum das so ist.


 Mitteilung der Redaktion: Kommen wir ins Gespr&#228;ch
Mitteilung der Redaktion
Kommen wir ins Gespräch
Joshua Hoffman

Nahezu alles Wichtige, das je geschehen ist, begann mit einem Gespräch.
„Ich glaube nicht wirklich, dass die Erde eine Scheibe ist. Wir sollten das mal überprüfen, meinen Sie nicht auch?“
„Warum schicken wir keinen Menschen zum Mond?“
„Kann ich mit Ihnen über eine Idee für diese neuen PCs sprechen?“
„Treffen wir uns auf eine Tasse Kaffee.“
(Letzteres ist eigentlich kein wichtiges Ereignis ... Ich trinke nur wirklich gerne Kaffee. Immerhin – wenn wir uns auf einen Kaffee träfen, hätten wir vielleicht eine wichtige Idee!)
Auf jeden Fall trifft der Gedanke, dass alles Wichtige in der Regel mit einem Gespräch beginnt, für mich in diesem Monat auf zwei Ebenen zu. Die erste bezieht sich auf ein tatsächliches Gespräch, das derzeit stattfindet – in Blogs, auf Fluren und sogar in dieser Ausgabe des TechNet Magazins (siehe den Artikel von Romi Mahajan in der Rubrik „Berichte aus der Praxis“). Es dreht sich um die „Verbraucherorientierung“ der Informationstechnologie. Dabei steht der Gedanke im Mittelpunkt, dass wir nicht nur IT-Experten bei der Arbeit sind. In Wirklichkeit hat das, was wir in unserem alltäglichen Leben tun (als freiwilliger Helfer Wohltätigkeitsprojekte unterstützen, Karaoke singen, Xbox spielen usw.) Auswirkungen auf unsere Arbeit und auf die Entscheidungen, die wir in unserem beruflichen Leben treffen. Dieses Gespräch werden Romi und ich, zusammen mit einigen besonderen Gästen, bei einer Podiumsdiskussion mit dem Titel „The Fungible Future“ auf der bevorstehenden Windows Connections-Konferenz in Las Vegas fortsetzen. Ich hoffe, dass Sie persönlich vorbeischauen oder die Website unter WeWantToKnow.net besuchen. Sie können sich auch in unserem Blog unter blogs.technet.com/tnmag in das Gespräch einbringen, da wir an Ihrer Meinung interessiert sind.
Der zweite Aspekt, auf den ich eingehen möchte, ist die von uns verwendete Technologie, um diese Gespräche zu ermöglichen. In dieser Ausgabe des TechNet Magazins betrachten wir wichtige Verbesserungen bei Exchange Server, die es Ihnen erleichtern, in Verbindung zu bleiben – unabhängig davon, ob Sie im Büro gegenüber oder auf der anderen Seite der Welt arbeiten. Wir zeigen Ihnen die Verbesserungen, die Exchange Server 2007 SP1 zu bieten hat, wie Sie mit der fortlaufenden Standbyreplikation Ihre Pläne zur Notfallwiederherstellung wesentlich effektiver gestalten können, wie die Exchange-Plattform durch Windows Server 2008 erweitert wird und wie Unified Messaging Ihre Gespräche noch wirkungsvoller macht. Als besonderes Schmankerl enthält die Druckausgabe des TechNet Magazins in diesem Monat das neueste Exemplar einer Reihe äußerst beliebter Poster, die von den Redakteuren Astrid und Martin McClean gestaltet wurden. Vielleicht kennen Sie ihr preisgekröntes Puzzleposter aus Active Directory-Komponenten oder die Windows Server 2008-Poster, die in der Vergangenheit im Magazin erschienen sind. In diesem Monat befassen sie sich mit Exchange. Kommen wir ins Gespräch! – Joshua Hoffman

Unser Dank gilt folgenden technischen Experten von Microsoft: Ed Banti, Anah Cameron, Chun Yong Chua, Cliff Didcock, Jeremy Kelly, Michael Murgolo, Jon Orton, Jeff Ressler, Kevin Sullivan, Jim Truher, Scot Vidican und Michael Wilson.


 Briefe: Leser sagen ihre Meinung
Briefe
Leser sagen ihre Meinung

PageDefrag-Dienstprogramm
Ich habe versucht, das in der Ausgabe vom September 2007 erörterte SysInternals PageDefrag-Dienstprogramm auszuführen. Unter Windows Vista® x64 war dies jedoch nicht möglich, und folgende Fehlermeldung wurde angezeigt: „Make sure that you are an administrator. Error loading PageDefrag driver.“ (Stellen Sie sicher, dass Sie Administratorrechte besitzen. Fehler beim Laden des PageDefrag-Treibers.)
– Alex D.

Derzeit wird das PageDefrag-Dienstprogramm in Windows Vista nicht unterstützt. Es funktioniert nur mit Windows NT® 4.0, Windows® 2000, Windows XP und Windows Server® 2003. Wir entschuldigen uns dafür, dass dies aus dem September-Artikel nicht klar hervorging.

Sicherungsplaner
Ich habe den Artikel „Windows Vista-Sicherungstechnologien“ in der Ausgabe vom September 2007 mit großem Interesse gelesen, aber ich habe ein paar Fragen.Abbildung 2 im Artikel zeigt ein Datum und die Uhrzeit für die nächste Sicherung. Wie ist dies möglich, wenn das Sicherungstool keinen eigenen Planer enthält?
Da Änderungen an Datenträgerblöcken als Grundlage zur Bestimmung dessen dienen, was gesichert werden soll, was geschieht, wenn eine Datenträgerdefragmentierung stattgefunden hat? Führt dies zu einer großen zu sichernden Datenmenge, weil die Blöcke verschoben oder geändert wurden? Wie wirkt sich eine Datenträgerdefragmentierung aus, wenn Blöcke während einer Wiederherstellung an ihrem ursprünglichen Speicherort wiederhergestellt werden?
– Bruce G.

Wir haben uns an die Autorin Christine Fok gewandt, die Folgendes dazu gesagt hat:
Abbildung 2 zeigt ein Datum und die Uhrzeit für die nächste Datei- und Ordnersicherung an, aber nur die Uhrzeit der aktuellsten Complete PC-Sicherung. Sie können eine Sicherung auf Datei-/Ordnerebene planen, aber wie Sie angemerkt haben, verfügt Complete PC-Sicherung nicht über einen eigenen Planer.
Sie haben Recht, dass beim Ausführen von „Defrag“ zwischen zwei Complete PC-Sicherungen die zweite Sicherung größer werden könnte. Ihre Anmerkung bezüglich der Wiederherstellung nach einer Defragmentierung ist ebenfalls richtig. Complete PC wird auf der Volumeebene unterhalb des Dateisystems ausgeführt. Jeder Block wird genau in den Zustand zum Zeitpunkt der Sicherung an genau denselben Speicherort auf dem Datenträger versetzt, unabhängig davon, ob „Defrag“ seit dieser Sicherung ausgeführt wurde oder nicht. Deshalb muss das Volume nach der Wiederherstellung möglicherweise erneut defragmentiert werden.

BGInfo-Tool
Mir hat die Rubrik „Schwerpunkt Dienstprogramme“ in der Ausgabe vom August 2007 sehr gut gefallen. Das BGInfo-Tool von SysInternals, das entscheidende CPU- und Netzwerkinformationen sammelt, ist hervorragend. Ich lese gerne über Leute, die neue Produkte, Dienstprogramme, Programme oder Anwendungen entwickeln. Hat Bryce Cogswell noch andere Softwareprodukte für Microsoft entwickelt?
– Daryl B.

Wir freuen uns, dass Ihnen das BGInfo-Dienstprogramm gefällt! Bryce Cogswell hat eine Reihe praktischer Dienstprogramme entwickelt, meist in Zusammenarbeit mit Mark Russinovich als Mitarbeiter von SysInternals. Zum Glück wurde SysInternals 2006 von Microsoft übernommen, und sowohl Bryce Cogswell als auch Dr. Russinovich sind jetzt hier tätig. Sie finden alle Dienstprogramme der beiden auf der SysInternals-Website unter microsoft.com/technet/sysinternals.

RPC und Firewalls
Der Artikel „Problembehandlung bei RPC-Fehlern“ in der Ausgabe vom Juli 2007 war sehr hilfreich, hat aber einen wichtigen Punkt nicht angesprochen: Die Windows-Firewall kann ebenfalls RPC-Fehler verursachen. Wenn die Windows-Firewall so konfiguriert wird, dass PING-Anforderungen möglich sind, unerwünschte eingehende Nachrichten jedoch nicht, schlagen alle Versuche zur Remoteverwaltung eines Computers fehl. Beim Ausführen von RPCPING.exe des Windows Resource Kit wird 1722 als Fehler zurückgegeben (der RPC-Server ist nicht verfügbar).
In diesem Fall tut die Firewall genau das, was sie tun soll: Sie verhindert, dass Außenstehende auf ein bestimmtes System zugreifen. Leider wird dies jedoch auch Administratoren zur Verzweiflung treiben, wenn sie versuchen, Computer in einem Unternehmensnetzwerk zu verwalten.
– Aaron M.

Danke, dass Sie auf eine weitere mögliche Quelle von RPC-Schwierigkeiten hingewiesen haben. Wir hoffen, dass die im Artikel erwähnten Tools dazu beitragen können, diese Probleme zu lösen.

Windows XP-Lizenzen
In der Rubrik „Berichte aus der Praxis“ im Oktober 2007 wurde die Möglichkeit erwähnt, Lizenzen für Windows XP für nur 5,00 $ zu erwerben. Wir sind ein gemeinnütziger Verlag, und ich würde gerne wissen, wie diese Lizenzen erworben werden können. Gibt es eine Möglichkeit, dies telefonisch oder per E-Mail zu tun? Ich habe eine E-Mail-Adresse, aber keinen Internetzugriff.
– Ernest B.

Sie können den administrativen MAR-Partner, TechSoup, unter communitymar@techsoup.org oder unter der Rufnummer 800-659-3579 x350 erreichen. Sie können auch an folgende Adresse schreiben: Community MAR Administrator, TechSoup Stock, 435 Brannan Street #100, San Francisco, CA 94107, USA.


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

Überwachen von Netzwerksystemen
ActiveXperts Network Monitor
activexperts.com
Als Systemadministrator wollen Sie wahrscheinlich wissen, ob etwas schief geht, bevor Ihre Benutzer aufgeschreckt aus ihren Arbeitsnischen auftauchen. Die Dienstüberwachung ist ein wichtiges Tool zur proaktiven Verwaltung Ihrer Infrastruktur. ActiveXperts Network Monitor ist eine stabile Lösung, die eine Reihe verschiedener Überprüfungen sowohl für LAN/WAN- als auch Windows®-, Novell- und *NIX-Server umfasst, sodass Sie Probleme erkennen, bevor Ihre Benutzer Sie auf Fehler hinweisen.
ActiveXperts Network Monitor ist eine Windows-basierte Anwendung, die auf dem von Ihnen als Überwachungsstation festgelegten Computer als Dienst ausgeführt wird. Das Basisbetriebssystem auf diesem Computer kann Windows 2000, Windows Server® 2003, Windows XP oder Windows Vista® sein. Nach der Installation richten Sie mithilfe eines Konfigurationsassistenten auf einfache Weise E-Mail-Benachrichtigungen, SMS-Benachrichtigungen sowie die Standardscanfrequenz oder Fehlerschwelle ein. Sie können auch einen Satz Beispielüberprüfungen hinzufügen, die als Beispiele in Ihrer Konfiguration verwendet werden können. Dies ist für den Einstieg äußerst nützlich, da Sie mit der grundlegenden Konfiguration der verschiedenen Anwendungsfeatures speziell für die Anforderungen in ihrer Umgebung vertraut werden.
Die Anwendung besteht aus drei verschiedenen Komponenten: Das Netzwerkmonitormodul ist der Windows-Dienst, der fortwährend Überwachungsaufgaben ausführt. Beim Netzwerkmonitormanager handelt es sich um eine Windows-Anwendung, die Ihnen die aktuelle Überwachungsaktivität und die Taskergebnisse anzeigt sowie Änderungen an der Konfiguration ermöglicht. Eine Weboberfläche bietet schreibgeschützten Zugriff auf Tasks und Taskergebnisse.
Außerdem bearbeitet das Netzwerkmonitormodul beim Ausführen von Überwachungsüberprüfungen auch Benachrichtigungen, von Ergebnissen ausgelöste Aktionen und die Protokollierung für die Anwendung. Das Überwachungsmodul ist eine Multithreadanwendung, die auf Ihre Umgebung skaliert werden kann. Der Dienst erfordert keinen Endpunktagent zum Ausführen der Überwachungsüberprüfungen, Sie müssen daher allerdings Administratoranmeldeinformationen bereitstellen, um Windows-Remoteserver oder Remotearbeitsstationen zu überwachen. Glücklicherweise können Sie mehrere Anmeldeinformationssätze festlegen, sodass für die Überwachung über verschiedene Domänen und Sicherheitskontexte hinweg kein einzelnes Konto mit allen Anmeldeinformationen zum Ausführen Ihrer Überwachungslösung erforderlich ist.
Sie arbeiten wahrscheinlich die meiste Zeit über mit dem Netzwerkmonitormanager, mit dem Sie alle Features, Konfigurationseinstellungen und Funktionen fein abgestimmt steuern können. Hier können Sie die Überwachungsaufgaben in einer Ordnerstruktur organisieren, um Elemente in großen Umgebungen schneller suchen und identifizieren zu können. Außerdem kann die aktuelle Benutzeroberflächenansicht für die schnelle Anzeige eines bestimmten Satzes von Überwachungsaufgaben gefiltert werden.
Das Hinzufügen einer neuen Überwachungsüberprüfung ist einfach. Der Netzwerkmonitor umfasst fast 40 integrierte Überprüfungen einschließlich IP- und Protokollüberprüfungen (beispielsweise ICMP, LDAP, SMTP und HTTP), Windows-Überprüfungen (z. B. CPU-, Prozess-, Speicher- und Terminalserverüberprüfungen), ODBC-Konnektivität, Oracle TnsPing, abfragebasierte OLEDB-Datenbanküberprüfungen, Novell-Mitgliedschaftsüberprüfungen und *NIX RSH-Überprüfungen. Zudem können Umgebungsdetails in Ihrem Netzwerk, z. B. Temperatur, Luftfeuchtigkeit und Feuchtigkeit, mithilfe eines SensaTronics-Umgebungsmonitors überwacht werden.
Die Anwendung unterstützt benutzerdefinierte VBScript- und Remoteshellskripts, sodass Sie die Überwachungsaufgaben auf Ihre Bedürfnisse zuschneiden können. Die Anwendung umfasst einen VBScript-Vorlagensatz zum Überwachen verschiedener Dienste wie Antivirus, Microsoft® ISA Server und XML-Abfrage, damit Sie beim Erstellen benutzerdefinierter Überwachungsaufgaben nicht von vorn beginnen müssen.
Sie können die Überprüfungsfrequenz und Fehlerschwelle für jeden Task einstellen und Überprüfungen so planen, dass sie an einem bestimmten Tag und zu einer bestimmten Zeit ausgeführt werden, wenn Sie beispielsweise die Ergebnisse eines anderen ausgeführten Prozesses (etwa eine Protokollarchivierung oder das Zurücksetzen eines IIS-Anwendungspools) überprüfen müssen. Sie können auch die Ausführung von EXE-Dateien, Skripts und Stapelverarbeitungsaufträgen festlegen, wenn eine Überprüfung fehlschlägt oder wiederhergestellt wird, und einen Neustart veranlassen bzw. einen bestimmten Dienst neu starten. Schließlich zeigt die Weboberfläche eine XSL-übersetzte Ansicht von XML-Ergebnisdaten an. Die Stylesheets lassen sich leicht auf Ihre Anforderungen zuschneiden, um eine benutzerdefinierte Ansicht Ihres Network Operations Center (NOC) oder mobilen Geräts zu erstellen. Da es sich um XML-Daten handelt, können sie leicht zur Verwendung in einer anderen Anwendung oder einem Gesamtsystem abgerufen werden.

Preis: Ab 395 $ im Direktversand für eine Mehrserverlizenz (5 Server)
ActiveXperts Network Monitor umfasst Beispielüberprüfungen für den Einstieg
ActiveXperts Network Monitor umfasst Beispielüberprüfungen für den Einstieg

Buchbesprechung
Windows Vista Ressource Kit
microsoft.com/mspress/books/9536.aspx
Da immer mehr Unternehmen Windows Vista-Clients in ihre Infrastruktur integrieren, müssen IT-Experten im Umgang mit den im neuen Betriebssystem verfügbaren Tools fit sein. Das neu veröffentlichte Buch Windows Vista Resource Kit (Microsoft Press®, 2007) deckt viele Informationen und Tools ab, die zur erfolgreichen Implementierung von Windows Vista-Clients im Unternehmen erforderlich sind, angefangen bei der automatischen Installation und Volumenaktivierung über die Desktopverwaltung und -wartung bis hin zur Verwendung von IPv6-Netzwerken und Remoteunterstützung. Neben 1.568 Buchseiten erhalten Sie auch eine Support-DVD mit über 100 Skripts zum Verwalten und Bereitstellen, einem Satz Debuggingtools, dem Solution Accelerator for Business Desktop Deployment (BDD) und anderen nützlichen Dingen.
Das Buch beginnt mit einem Überblick über die neuen Features in Windows Vista und schenkt den Sicherheitsverbesserungen wie Benutzerkontensteuerung (User Account Control, UAC), BitLocker-Laufwerkverschlüsselung und Datenausführungsverhinderung (Data Execution Prevention, DEP) besondere Aufmerksamkeit. Zudem wird das Konzept der Diensthärtung und des Kernelpatchschutzes erörtert. Anschließend geht es um die Bereitstellung von Windows, wobei die zahlreichen Tools untersucht werden, die zum Automatisieren des Prozesses zur Verfügung stehen. Das Buch befasst sich beispielsweise mit der Konfiguration einer Windows PE 2.0-Vorinstallations- und -Wiederherstellungsumgebung und mit BDD 2007, wobei Sie eine Anleitung zum Planen und Bereitstellen von Windows Vista im Unternehmen erhalten. Außerdem werden bewährte Methoden zum Erstellen und Konfigurieren von Datenträgerabbildern vorgestellt. In einer informativen Diskussion wird erläutert, wie Benutzerdaten mithilfe von Windows-Easytransfer und dem User State Migration Tool migriert werden.
Anschließend werden die Details beim Verwalten der Desktopumgebung über die Gruppenrichtlinie erörtert, wobei die neuen XML-basierten administrativen Vorlagedateien (ADMX) vorgestellt werden. Zusätzlich wird das Verwalten von Datenträgern und Dateisystemen behandelt. Auch die neuen ReadyBoost- und BitLocker-Verbesserungen in Windows Vista werden vorgestellt. Das Buch erläutert, wie frühere Versionen, Schattenkopien und Datenträgerkontingente funktionieren, und untersucht dann näher, wie Windows-Teamarbeit in Arbeitsgruppen, Domänen und drahtlosen Ad-hoc-Umgebungen bereitgestellt und verwaltet werden kann.
Der Abschnitt über die Desktopwartung befasst sich mit Aufgaben, Windows-Fehlerberichterstattung, Leistungsüberwachung und Windows Eventing. Außerdem erläutert das Buch, wie Sie Remoteunterstützung bei Ihrem Helpdesk nutzen können. Anschließend werden Softwareupdates, der intelligente Hintergrundübertragungsdienst (Background Intelligent Transfer Service, BITS) und Windows Update sowie Überwachungstools erörtert.
Der Abschnitt zum Thema Netzwerke beschreibt ausführlich, wie die Windows-Firewall funktioniert, und erläutert die neuen Verbesserungen beim Netzwerkstapel. Außerdem wird die Verwendung von Remotedesktop- und VPN-Verbindungen zum Konfigurieren von Remotebenutzern und Netzwerken untersucht.
Schließlich gibt das Buch einen guten Überblick über die Behandlung von Problemen, z. B. beim Starten und in Netzwerken sowie bei Treiberfehlern und Geräteproblemen. Gelegentlich scheint ein gewisser Marketingjargon durch, doch die meisten der über 1.500 Seiten sind keinesfalls schwammig geschrieben. Das Buch bietet eine detaillierte, umfassende Betrachtung von Windows Vista, den Tools und der Verwaltung des Betriebssystems.

Preis: 59,99 $ im Direktversand.

Analysieren des HTTP-Datenverkehrs
Charles Web Debugging Proxy
xk72.com/charles
Wenn Sie die große Menge HTTP-basierter Kommunikation zwischen Anwendungen und zwischen Ihren Arbeitsstationen, Servern und dem Internet in Betracht ziehen, ist ein guter HTTP-Verkehrsanalyzer ein wirklich nützliches Tool für Systemadministratoren. Mithilfe dieses Tools können Sie Proxyprobleme, Sicherheitsaspekte, Konnektivitätsfehler, Konfigurationsprobleme und Schwierigkeiten bei der Kommunikation zwischen Anwendungen identifizieren. Ein Tool, das mir recht gut gefällt, ist Karl von Randows Java-basierte Anwendung, der Charles Web Debugging Proxy.
Wie bei anderen Debuggingproxys handelt es sich bei der Anwendung praktisch um den Mittelsmann – sie ist zwischen Endpunktanwendungen angesiedelt und hat die Aufgabe, den Verkehr abzuhören und zu interpretieren. Dank dieser Konfiguration können Sie sich mithilfe der Anwendung auch verschlüsselten HTTPS-Datenverkehr im entschlüsselten Nur-Text-Format anzeigen lassen. Die Benutzeroberfläche vermittelt eine gut organisierte Ansicht der aufgezeichneten Sitzung mit umfassenden Informationen, die von einfachen Anforderungen nach Seiten, Abbildern, Skripts und Stylesheets bis hin zu Detailangaben wie Größe, Latenz und Zeitdauer reichen. Sie können auch sehen, welche Cookies bei den jeweiligen Anforderungen gesendet werden und eingehen und was sie enthalten, und Sie können Cookies sogar ganz blockieren.
Mit dem Charles Web Debugging Proxy können Sie Probleme bei der Anforderungszwischenspeicherung beheben, indem Sie die zuletzt geänderten Daten bei 304 nicht geänderten Antworten überprüfen bzw. die Zwischenspeicherung deaktivieren, indem Sie Header, die sich auf die Zwischenspeicherung beziehen, aus den entsprechenden Anforderungen und Antworten entfernen, während diese durch die Anwendung weitergeleitet werden. Mit den Einstellungen zum erneuten Schreiben können Sie sogar einen Satz von Regeln definieren, der eine Reihe von HTTP-Headern oder Textbereichen neu schreibt, während die Anforderungen und Antworten die Anwendung durchlaufen. Sie könnten sogar die DNS-Spoofingeinstellungen der Anwendung verwenden, um die IP-Adresse eines Hosts außer Kraft zu setzen, sodass Sie Anforderungen von Elementen, die im DNS-System möglicherweise nicht registriert sind, testen können. Dies ist beispielsweise besonders zum Testen eines neuen Webservers geeignet, um sicherzustellen, dass er vor der Aktivierung den Hostheader richtig abfragt und entsprechend antwortet.
Sie können das Tool auch zum Debuggen von AJAX-Anforderungen und -Antworten verwenden und sich die rohen XML-Daten in der Antwort anzeigen lassen. In der Benutzeroberfläche können Sie sich sogar die rohen Anforderungs- und Antwortdaten im Text anzeigen lassen und so ungewöhnliche Header entdecken.
Das Tool stellt zwei sehr schöne Datenlayouts bereit, die einen wirklich guten Einblick in die Datentransaktion gewähren: die Zusammenfassungstabelle und die Diagrammtabelle. Mithilfe der Zusammenfassungstabelle können Sie die Anforderungs-/Antwortdaten schnell scannen, wobei Headergröße, Textgröße, Antwortzeit, Antwortcode, MIME-Typ und Ressource angezeigt werden. Die Diagrammtabelle andererseits bietet eine grafische Lebenszykluszeitskala, die zeigt, wo die Anforderungs-/Antwortdaten in der Sequenz aufgetreten sind und wie lang die Transaktion gedauert hat.
Sie können die aufgezeichneten Sitzungen zur späteren Wiedergabe und Analyse speichern. Dies kann nützlich sein, um schwierige Anforderungs-/Antwortabläufe aufzuzeichnen, die sporadische Kommunikationsfehler verursachen. Anschließend können diese reproduziert werden. Es ist sogar möglich, HTTP-Ablaufverfolgungsdateien in eine neue Sitzung zu importieren und die aktuelle Sitzung in das CSV- oder HTTP- Ablaufverfolgungsformat zu exportieren.
Für Anforderungssimulationen bei geringeren Bandbreiten, um beispielsweise festzustellen, warum eine Anforderung bei einem 56K-Modemanschluss fehlschlägt, aber nicht in Ihrem Unternehmensnetzwerk, bietet die Anwendung ein Einschränkungsfeature zum Auswählen eines Satzes häufiger Voreinstellungen oder zum Definieren einer neuen Voreinstellung auf Grundlage von vier Einschränkungspunkten: Bandbreite, Auslastung in Prozent, Roundtrip-Latenz und Maximum Transmission Unit. Sie können den Debuggingproxy auch so konfigurieren, dass er als Reverseproxy oder Anschlussweiterleitung dient, wobei ein lokaler Port an einen Remoteendpunkt (und -port) gebunden wird, sodass der gesamte Verkehr an die Remoteadresse umgeleitet wird.

Preis: Ab 50 $ im Direktversand für eine Einzelbenutzerlizenz.
Charles Web Debugging Proxy analysiert den HTTP-Verkehr
Charles Web Debugging Proxy analysiert den HTTP-Verkehr

Bereinigen unnötiger Dateien
Wise Disk Cleaner 2
wisecleaner.com
Eine Festplatte ist fast so etwas wie ein Zuhause – im Lauf der Zeit sammeln sich dort Dinge an, die Sie eigentlich nicht brauchen. Hin und wieder ist es angebracht, sich etwas Zeit zum Aufräumen zu nehmen. Es gibt einige Standardmethoden zum Aufräumen einer Festplatte mit integrierten Windows-Tools, beispielsweise die Datenträgerdefragmentierung, die Datenträgerbereinigung und die Suchfunktion. Doch manchmal ist ein schnell und einfach zu verwendendes Dienstprogramm die beste Möglichkeit, besonders dann, wenn es kostenlos erhältlich ist. Ein solches Tool ist Wise Disk Cleaner 2, das Ihre Festplatten nach lästigen Dateien durchsucht, die Staub ansammeln und durchaus aus Ihrem System entfernt werden können.
Ein besonderer Vorteil dieses Tools besteht darin, dass alle gefundenen Dateien direkt auf der Benutzeroberfläche angezeigt werden, sodass potenzielle Probleme leicht entdeckt werden können. Ein weiteres gutes Feature besteht darin, dass Sie leicht zusätzliche Dateimuster hinzufügen können, die überprüft und entfernt werden sollen. Wise Disk Cleaner bereinigt auf Wunsch auch Ihre temporären Internetdateien, wobei Sie Cookies beibehalten können, damit Einstellungen für Websites, die dort gespeichert sein könnten, nicht verloren gehen. Darüber hinaus können Sie Windows Update-Deinstallationsdateien entfernen und die Windows Update-Quelle, die Liste kürzlich verwendeter Dateien sowie die Windows- und temporären Benutzerverzeichnisse bereinigen. Die Anwendung kann sogar automatisch ausgeführt werden. Datei stellen Sie ein, ob die Elemente permanent gelöscht oder nur in den Papierkorb verschoben werden sollen. Zudem protokolliert die Anwendung die Aktivitäten zur späteren Prüfung – nicht schlecht für ein kostenloses Tool.

Preis: Kostenlos.
Wise Disk Cleaner 2 sucht Dateien, die Sie problemlos löschen können
Wise Disk Cleaner 2 sucht Dateien, die Sie problemlos löschen können

Verwalten von Netzwerkgeräten
iReasoning Networks MIB Browser Personal Edition
ireasoning.com/mibbrowser.shtml
Wenn SNMP (Simple Network Management Protocol)-aktivierte Netzwerkgeräte, Anwendungen oder Systeme in Ihrer Infrastruktur vorliegen, ermöglicht iReasoning Networks MIB Browser das Laden eines Satzes von MIB-Dateien (Management Information Base) und das Durchsuchen der hierarchischen Struktur in einer Ansicht, die der in Windows Explorer ähnelt. Hier können Sie sich die Details des ausgewählten Objekts einschließlich Objektbezeichner (Object Identifier, OID), Syntax, Schreib-/Lesezugriff und Beschreibung anzeigen lassen.
Sie können leicht eine SNMP-Anforderung zum Abrufen von Daten aus einem Netzwerkgerät über die Benutzeroberfläche erstellen. Geben Sie einfach die IP-Adresse des Geräts ein, wählen Sie das MIB-Objekt aus, und klicken Sie auf „Go“. Bei Bedarf können Sie auch den Port, die SNMP-Anforderungsversion und die Lese-und Schreib-Communityzeichenfolgen festlegen. Änderungen an einem Agent können ebenfalls leicht durchgeführt werden (vorausgesetzt, Ihr Gerät lässt dies zu). Wählen Sie einfach die OID, den Datentyp und den Wert aus, und klicken Sie anschließend auf „OK“. Außerdem ist ein integriertes Dienstprogramm zum Senden und Empfangen von Trapnachrichten vorhanden, mit dem Sie Trapnachrichten erstellen und die Trapaktivität überwachen können (dabei können Filter angewendet werden, damit das fragliche Gerät leichter erkannt wird).
iReasoning Networks MIB Browser Personal Edition ist kostenlos, doch SNMPv3 wird nicht unterstützt, und es können maximal fünf MIBs gleichzeitig geladen werden. Vielleicht ist die Professional Edition interessant für Sie (269 $ pro Lizenz im Direktversand). Sie enthält zusätzliche Features und unterstützt SNMPv3, Netzwerkerkennung und Gerätevergleich.

Preis: Kostenlos.
iReasoning Networks MIB Browser
iReasoning Networks MIB Browser

Greg Steen ist Technologieexperte und Enthusiast und immer auf der Suche nach Hilfsmitteln und Methoden, um Arbeits- und Entwicklungsprozesse für IT-Experten zu erleichtern.


 SQL&#160;– Fragen und Antworten: Speicherkonfiguration, Leistungsprofilerstellung, Einstellen des F&#252;llfaktors und mehr
SQL – Fragen und Antworten
Speicherkonfiguration, Leistungsprofilerstellung, Einstellen des Füllfaktors und mehr
Herausgegeben von Nancy Michell

Konfigurieren des Speichers
Tipp: Leichtere Profilerstellung
Wussten Sie, dass Sie jetzt PerfMon mit SQL Server 2005 Profiler korrelieren können?
Vielleicht haben Sie schon einmal CPU-Auslastungsspitzen, eine übermäßige Speichernutzung oder eine allgemeine Leistungsabnahme im Systemmonitor Ihres SQL Server-Computers bemerkt und sich gewundert, wodurch diese Leistungsanomalien verursacht wurden. Vor SQL Server 2005 mussten Sie Profiler zur Ablaufverfolgung verwenden, dann die „sysprocesses“ in Enterprise Manager untersuchen und abschließend die Systemmonitor-Protokolle erfassen, was natürlich den Start von PerfMon erforderte. Nach all diesen Arbeitsvorgängen mithilfe der Tools mussten die Ereignisse zwischen den Tools trotzdem noch manuell abgestimmt werden, um herauszufinden, was die Leistungsbeeinträchtigung verursachte. Sie mussten sich also durch jedes Protokoll einzeln durchkämpfen. Dies war ziemlich mühsam, aber unumgänglich, wenn Sie den Leistungsproblemen auf den Grund gehen wollten.
Mit SQL Server 2005 müssen Sie nach wie vor eine Ablaufverfolgung durchführen und Ihre PerfMon-Protokolle untersuchen, doch mithilfe von Profiler können Sie sie jetzt anhängen. Sie können einen Bildlauf durch die T-SQL-Anweisungen durchführen, und Profiler zeigt Ihnen automatisch alle Anweisungen in einer Grafik an. Wenn Sie auf der Systemmonitor-Benutzeroberfläche in Profiler klicken, gelangen Sie zu der Anweisung, die dem jeweiligen Zeitstempel entspricht. Dies erspart Ihnen bei der Problembehandlung Ihrer SQL Server-Umgebung viel Zeit.
Im Folgenden wird untersucht, wie Sie PerfMon-Protokolle an Profiler anfügen:
  1. Starten Sie den Systemmonitor, und beginnen Sie mit dem Erfassen der Informationen vom Datenbankserver.
  2. Erstellen Sie ein neues Gegenprotokoll unter „Leistungsprotokolle und -warnungen“, und geben Sie einen Namen für Ihr neues Protokoll ein.
  3. Fügen Sie neue Zähler wie „Prozessorzeit (%)“ hinzu. Außerdem empfiehlt es sich, das Protokollieren so festzulegen, dass es entweder manuell oder anhand einer Vorgabe auf der Registerkarte „Zeitplan“ startet.
  4. Klicken Sie auf „OK“. Falls Sie die manuelle Option ausgewählt haben, stellen Sie sicher, dass Sie das Protokollieren starten.
  5. Richten Sie auf Ihrem SQL Server mithilfe von Profiler eine Ablaufverfolgung ein. Klicken Sie dazu im Menü „Datei“ auf „Neue Ablaufverfolgung“. Stellen Sie sicher, dass Sie StartTime und EndTime in die Ablaufverfolgung aufnehmen, benennen Sie die Ablaufverfolgung, und legen Sie fest, dass sie in einer Datei gespeichert wird. Abschließend müssen Sie den Server starten, damit eine Transaktionsaktivität simuliert wird, und dann das Erfassen von Daten über Systemmonitor und Profiler beenden.
  6. Wählen Sie in Profiler im Menü „Datei“ die Option „Leistungsdaten importieren“ aus. Wählen Sie als Nächstes an dem Ort, an dem Sie das PerfMon-Protokoll ausgewählt und gespeichert haben, „Datei“ | „Öffnen“ | „Ablaufverfolgung“ aus. Wählen Sie abschließend den Ort aus, an dem Sie die Profiler-Ablaufverfolgung gespeichert haben.
Danach werden Sie viel leichter herausfinden können, welche Auswirkung bestimmte SQL-Anweisungen auf die Verarbeitungszeit hatten.

F: Ich möchte herausfinden, was die beste Speicherkonfiguration für meine SQL Server™-Computer ist. Der Administrator vor mir hat „Boot.ini“ für jeden Computer mit 12 GB RAM auf einem SQL Server 2000 mit einem Cluster mit zwei Knoten folgendermaßen festgelegt: „Yes /PAE NO /3GB“ (Keine AWE-Einstellung für SQL Server). Da ein Arbeitsspeicher von 12 GB zur Verfügung steht, ist es ratsam, den /3GB-Schalter in „Boot.ini“ zu entfernen, AWE zu aktivieren und SQL Server ungefähr 10 GB von 12 GB zuzuteilen? Auf den Computern wird außer SQL Server sonst nichts ausgeführt, es sind also keine anderen Anwendungen vorhanden, die den Speicher nutzen.
A: Ja. AWE (Address Windowing Extensions) sollte aktiviert und eine RAM-Obergrenze für SQL Server vorgegeben werden. 10 GB ist ein geeigneter Wert für einen dedizierten 12 GB-SQL Server-Computer. (Beachten Sie, dass ein Vorgabewert nur für SQL Server 2000 gilt. Ab SQL Server 2005 ist die Verwendung von AWE nicht mehr statisch und kann jederzeit geändert werden.) Es gab immer schon eine große Debatte darüber, ob sowohl der /3GB- als auch der /PAE-Schalter oder ob nur der erforderliche /PAE-Schalter verwendet werden soll. Obwohl tatsächlich nur der /PAE-Schalter erforderlich ist und AWE aktiviert sein sollte, empfiehlt es sich, beide Schalter zu verwenden. Dabei müssen jedoch einige Faktoren berücksichtigt werden.
Die Verwendung des /3GB-Schalters hängt davon ab, ob er in Ihrer Situation benötigt wird. Reichen die MemToLeave-Speicherbereiche, die sich in den ersten 2 oder 3 GB des virtuellen Adressraums befinden müssen, nicht aus? Entziehen Sie bei Aktivierung des Schalters dem Betriebssystem dringend erforderlichen Speicher? (Weitere Informationen hierzu erhalten Sie unter „support.microsoft.com/kb/316739“.) Wenn Sie mit einem Cluster arbeiten, können Sie „/3GB“ auf einem Knoten einrichten, ohne ihn auf dem anderen einzurichten. Sollten dann beim Testen mit „/3GB“ Probleme auftreten, können Sie für die Instanz relativ schnell ein Failover auf den anderen Knoten erreichen. Denken Sie daran, dass bei mehr als 16 GB RAM der /3GB-Schalter nicht unterstützt wird.
Mithilfe von „/3GB“ erhöhen Sie den virtuellen Adressraum (VAS) um 50 Prozent. Das heißt, dass nicht nur der Datencache, sondern auch Anwendungen, die VAS hinsichtlich des Speichers belasten, davon profitieren. Erfreulicherweise ist dieser missverständliche Faktor bei den 64-Bit-Servern (sowohl bei IA64 als auch bei x64) beseitigt. Wenn der Computer für SQL Server dediziert ist, sind Bedenken zum Speicherentzug für das Betriebssystem unnötig. 2 GB für das Betriebssystem einzuplanen, ist ebenfalls nicht erforderlich. Wenn dieser Server für SQL Server dediziert ist und nur die standardmäßig erforderlichen Betriebssystemdienste ausgeführt werden, wird sich auf dem Server vermutlich etwa 1,3 GB freier Speicherplatz befinden. Deshalb sollten Sie ruhig das zusätzliche 1 GB für SQL Server bereitstellen. Starten Sie mit 10 GB, überwachen Sie mithilfe von PerfMon den verfügbaren Speicherplatz über einen längeren Zeitraum hinweg, um den Umfang des Leerlaufs festzustellen, und passen Sie den Wert dementsprechend an. Denken Sie daran, dass Sie einen Austausch herbeiführen, wenn Sie SQL Server 2000 zu viel Speicher zuweisen, da AWE beim Einsatz von SQL Server 2000 nicht so dynamisch ist wie bei SQL Server 2005. Die Frage, ob Sie den /3GB-Schalter verwenden sollen, lässt sich am besten anhand von Tests in Ihrer spezifischen Umgebung beantworten.

Instanznamen für Replikation
F: Kann ich jetzt die IP-Adresse meines Servers bei der Replikation von SQL Server 2005 verwenden, um anzugeben, welche Instanz repliziert werden soll? In SQL Server 2000 führt dies laut dem Artikel „So replizieren Sie zwischen Computern, die SQL Server in nicht vertrauenswürdigen Domänen oder im Internet ausführen“ (support.microsoft.com/kb/321822) zu Fehlern, doch ich weiß nicht, ob dies nach wie vor zutrifft.
A: Wenn Sie Server zur Teilnahme an einer Replikation angeben, müssen Sie den Namen der bei SQL Server registrierten Instanz bereitstellen. Sie müssen zum Beispiel den SQL Server-Instanznamen verwenden, wenn Sie die Verleger- oder Abonnentenparameter für die gespeicherten Replikationsverfahren oder für die Replikationsagent-Verbindungseinstellungen in der Befehlszeile angeben. Wenn der Netzwerkname für die SQL Server-Instanz vom registrierten Instanznamen abweicht, schlagen die Replikationsverbindungen durch Agents fehl.
Wenn sich der Netzwerkname der Instanz und der SQL Server-Instanzname unterscheiden, können Sie den SQL Server-Instanznamen als gültigen Netzwerknamen hinzufügen. Eine Möglichkeit, einen alternativen Netzwerknamen festzulegen, besteht darin, ihn der lokalen Hostdatei hinzuzufügen. Die lokale Hostdatei befindet sich standardmäßig unter WINDOWS\system32\drivers\usw. oder WINNT\system32\drivers\usw. Wenn der Computername beispielsweise „comp1“ lautet, der Computer die IP-Adresse „10.193.17.129“ hat und der Instanzname „inst1/instname“ lautet, fügen Sie der Hostdatei den folgenden Eintrag hinzu:
10.193.17.129 inst1

SQL Server Integration Services
F: Ich installiere einen Cluster (aktiv/aktiv) für SQL Server 2005 (64-bit Enterprise Edition mit zwei Servern), und mir werden insgesamt vier Instanzen von SQL Server 2005 zur Verfügung stehen. SQL Server Integration Services (SSIS) ist für alle Instanzen erforderlich. Was können Sie mir über das Clustering von SSIS und die Auswirkungen auf Wartungspläne mitteilen?
A: Sie können SSIS zwar gruppieren, dies ist jedoch nicht erforderlich, und es könnten dabei verschiedene Probleme auftreten, einschließlich einer nicht ausreichenden Unterstützung für die Delegierung (siehe msdn2.microsoft.com/aa337083) und der Tatsache, dass es sich nicht um mehrere Instanzen handelt – es kann immer nur eine Instanz auf einem Knoten ausgeführt werden.
Früher musste SSIS installiert – nicht ausgeführt, sondern nur installiert – werden, damit der Wartungsplanungs-Assistent ausgeführt werden konnte. Dies ist jedoch in SQL Server 2005 SP1 nicht mehr der Fall. Wenn SSIS nicht ausgeführt wird, können die Wartungspläne von SQL Server Agent ausgeführt werden.
Erwägen Sie statt einer Clusterbildung, SSIS weiterhin als eigenständigen Dienst auszuführen und „MsDtsSrvr.ini.xml“ so zu bearbeiten, dass auf alle ausführenden Instanzen verwiesen wird. Dadurch können Sie die Pakete von allen Knoten aus verwalten und die von den meisten Kunden geforderte hohe Verfügbarkeit bereitstellen, ohne auf die Probleme zu stoßen, die sich beim Clustering des Diensts oft ergeben.
Weitere Informationen zu Fehlern bei der Wartungsplanerstellung erhalten Sie im empfohlenen Knowledge Base-Artikel unter „support.microsoft.com/kb/909036“.

Seltsame Ausführungszeiten
F: Bei einem Auslastungstest auf meinem SQL Server 2005 SP1-Computer hat SQL Server Profiler viele negative Werte für die Ausführungszeit der gespeicherten Verfahren ermittelt, und in einigen Fällen stimmt die Ausführungszeit nicht mit dem Ergebnis überein, das ich erhalte, wenn ich die Startzeit von der Endzeit abziehe.
A: Eine Reihe von Faktoren können sich auf die Berichterstellung in Bezug auf die Ausführungszeit gespeicherter Verfahren und auf andere Leistungszeiten in SQL Server Profiler auswirken. Denken Sie daran, dass SQL Server 2005 die Ausführungszeit in Millisekunden berechnet. Wenn Sie eine Technologie verwenden, die die Maßeinheit ändert, erhalten Sie eine inkonsistente Berichterstellung und Ausführungszeiten, die keinen Sinn ergeben.
Wenn Sie zum Beispiel andere Energieschemas, CPU-Stepping oder die AMD-Technologie „Cool 'n Quiet“ verwenden, ändern Sie die CPU-Frequenzen, die dann nicht mit dem übereinstimmen, was SQL Server Profiler beim Berechnen der Ausführungszeiten erwartet.
Im Knowledge Base-Artikel unter „support.microsoft.com/kb/931279“ werden die Symptome, die vielen verschiedenen Ursachen und einige Abhilfen erläutert.
Tipp: Prüfen Sie Ihren Füllfaktor
Angenommen, Ihr Glas ist bis zum Rand mit Wasser gefüllt, und Sie versuchen, mehr Wasser in das Glas zu schütten. Was geschieht? Das Wasser läuft über.
So verhält es sich auch mit SQL Server. Wann immer einer vollen Indexseite eine neue Zeile hinzugefügt wird, verschiebt SQL Server ungefähr die Hälfte der Zeilen auf eine neue Seite, um für die neue Zeile Platz zu schaffen. Dieser Vorgang wird als Seitenteilung bezeichnet. Seitenteilungen schaffen Platz für neue Datensätze, sind allerdings zeit- und ressourcenaufwändig. Außerdem können sie zur Fragmentierung führen, die sich ungünstig auf E/A-Vorgänge auswirkt. Wie lässt sich dies vermeiden?
Um solche Situationen zu verhindern, müssen Sie den Füllfaktorwert proaktiv bestimmen. Wenn ein Index (neu) erstellt wird, bestimmt der Füllfaktorwert, wie viel Prozent des Speicherplatzes auf jeder Blattebenenseite mit Daten gefüllt wird, und behält den Rest für zukünftiges Wachstum vor. Das Konfigurieren eines Füllfaktorwerts auf 60 bedeutet zum Beispiel, dass 40 Prozent jeder Blattebenenseite leer gelassen wird, um die Indexerweiterung zu ermöglichen, die erfolgt, wenn der zugrunde liegenden Tabelle Daten hinzugefügt werden.
Der Standardfüllfaktorwert ist immer 0, was für die meisten Situationen geeignet ist. Grundsätzlich bedeutet der Füllfaktor 0, dass die Blattebene nahezu bis zur Kapazitätsgrenze gefüllt wird, jedoch etwas Speicherplatz für mindestens eine zusätzliche Indexzeile vorhanden ist. (Beachten Sie, dass die Füllfaktoren 0 und 100 ähnlich sind.)
Sie können den Füllfaktorwert für einzelne Indexe während einer CREATE INDEX- oder ALTER INDEX-Anweisung festlegen, oder Sie können diesen Wert direkt auf Serverebene konfigurieren, damit alle neu erstellten Indexe die Standardeinstellung verwenden.
Im folgenden Beispiel wird der Füllfaktorwert auf Serverebene auf 70 Prozent festgelegt. Das bedeutet, dass 30 Prozent freier Speicherplatz für zukünftige Erweiterungen zur Verfügung steht. Selbstverständlich müssen Sie diese Option vor dem Implementieren in einer Produktionsumgebung sorgfältig testen.
USE Master;
GO
SP_Configure 'show advanced options',1;
GO
SP_Configure 'Fill Factor', 70;
GO
--You must restart SQL Server Engine for changes to take effect.
Was geschieht, wenn Sie den Füllfaktor auf der einzelnen Indexebene konfigurieren wollen? Angenommen Sie erstellen die folgende Tabelle und möchten einen eindeutigen Index für die Spalte „Col_A“ mit einem Füllfaktorwert von 70 erstellen. Der Befehl sieht dann etwa so aus:
--Create an Item table
USE Item_DB;
GO
CREATE TABLE ITEM (Col_A Varchar(100),Col_b Varchar(200));
GO;

--Create a unique index on colum Col_A of Item table with a Fill Factor value of 70
CREATE UNIQUE INDEX AK_Index ON Item (Col_A)
WITH (FillFactor = 70);
GO
Wie identifizieren Sie den Füllfaktor für jeden Index? Sie können „sys.Indexes“ abfragen, um den Füllfaktorwert für alle Indexe in einer Datenbank abzurufen, etwa so:
USE Item_DB;
GO
SELECT Fill_Factor FROM Sys.Indexes WHERE Object_id=object_id('item') AND name IS NOT NULL;
GO


 Schwerpunkt Dienstprogramme: Das Microsoft Security Assessment Tool
Schwerpunkt Dienstprogramme
Das Microsoft Security Assessment Tool
Lance Whitney
Laden Sie den Code für diesen Artikel herunter: Microsoft Security Assessment Tool 3.0 (nur auf Englisch) (10547.2KB)

Das Aufspüren von Netzwerksicherheitsproblemen kann knifflig und zeitaufwändig sein. Ein Tool, das Ihnen beim Identifizieren und Beheben von Sicherheitsrisiken helfen kann, ist das Microsoft® Security Assessment Tool (MSAT), ein kostenloses Dienstprogramm mit einem elektronischen Fragebogen, in dem Sie Ihre Sicherheitsumgebung beschreiben. Das MSAT ist für mittelständische Organisationen mit 50 bis 500 Computern ausgelegt und stellt 172, in verschiedene Kategorien aufgeteilte Fragen. Anschließende werden eine Analyse Ihrer Lage und Verbesserungsempfehlungen bereitgestellt.
Das MSAT beginnt mit einer Reihe von Fragen zu Ihrem Geschäftsmodell, die zum Erstellen eines Geschäftsrisikoprofils (Business Risk Profile, BRP) verwendet werden, in dem Ihr Sicherheitsrisiko im Vergleich zu anderen Unternehmen in Ihrer Branche bewertet wird. Die Beantwortung des Fragebogens dauert in der Regel zwei Stunden. Sie können die Beantwortung der Fragen jederzeit unterbrechen und wieder aufnehmen. Dies sind die Kategorien sowie einige Beispielfragen:
Grundlegende Informationen Wie viele Clients und Server sind in Ihrer Organisation vorhanden?
Infrastruktursicherheit Arbeiten Ihre Mitarbeiter von Remotestandorten aus? Greifen externe Auftragnehmer auf Ihr Netzwerk zu?
Anwendungssicherheit Entwickelt Ihr Unternehmen Anwendungen? Werden vertrauliche Daten gespeichert, die von Ihren Anwendungen verarbeitet werden?
Betriebssicherheit Stellt Ihr Unternehmensnetzwerk eine Verbindung zu externen Netzwerken her? Erhält Ihre Organisation Datenfeeds von externen Parteien?
Mitarbeitersicherheit Lagert Ihr Unternehmen die Computerwartung aus? Dürfen Mitarbeiter vertrauliche Unternehmensdaten auf ihre Arbeitsstationen herunterladen?
Umgebung Wie viele Mitarbeiter sind in Ihrer Organisation beschäftigt? Gibt es in der IT-Abteilung eine hohe Mitarbeiterfluktuation?
Anschließend generiert das MSAT eine Bewertung, die eine als Tiefenverteidigungsindex (Defense-in-Depth Index, DiDI) bezeichnete Messung verwendet. Diese konzentriert sich auf die bereits bei Ihnen vorhandenen Sicherheitsprozesse. Es werden dieselben Kategorien verwendet, und die folgenden Beispiele sind typische Fragen: Verwendet Ihre Organisation Firewalls an allen Standorten? Verwenden Sie benutzerdefinierte Makros in Ihren Microsoft Office-Anwendungen? Haben Ihre Benutzer Administratorrechte auf ihren Arbeitsstationen? Verfügen Sie über eine Richtlinie zum Bereitstellen von Patches und Updates auf Ihren PCs?
Als Reaktion auf Ihre Antworten bietet das MSAT drei Berichte an. Der Zusammenfassungsbericht enthält ein Balkendiagramm mit den Ergebnissen. Ein hohes Ergebnis beim BRP weist auf höhere Risiken hin, während ein hohes Ergebnis beim DiDI mehr Sicherheit bedeutet. Ein niedriges BRP und ein hoher DiDI mögen zwar wünschenswert scheinen, doch im MSAT wird mehr Wert auf die Untersuchung einzelner Bereiche gelegt. Daher zeigt der vollständige Bericht für jeden einzelnen Bereich an, ob die Sicherheit bewährten Methoden entspricht, Verbesserungen erforderlich sind oder ein großer Mangel besteht (siehe Abbildung 1).
Abbildung 1 Der vollständige Bericht
Abbildung 1 Der vollständige Bericht
Schließlich werden Sie im Vergleichsbericht gebeten, die Ergebnisse anonym auf eine sichere MSAT-Website hochzuladen, auf der Sie Ihre Ergebnisse mit denen anderer Organisationen vergleichen können.
Sie können das Tool von der Microsoft Security Guidance-Website unter securityguidance.com oder von der TechNet Magazin-Website unter technetmagazine.com/code07.aspx herunterladen.

Lance Whitney ist IT-Berater, Schulungsleiter und Autor technischer Artikel. Er hat sich intensiv mit dem Optimieren von Windows-Arbeitsstationen und -Servern beschäftigt. Lance Whitney ist von Haus aus Journalist und hat vor etwa 15 Jahren den Sprung ins kalte Wasser der IT-Welt getan.


 The Cable Guy: Netzwerkrichtlinienserver
The Cable Guy
Netzwerkrichtlinienserver
Joseph Davies
Dieser Artikel basiert auf einer Vorabversion von Windows Server 2008. Die in diesem Artikel enthaltenen Informationen können jederzeit geändert werden.

Der NPS-Dienst in Windows Server 2008 ist der Nachfolger für den Internetauthentifizierungsdienst (IAS) in Windows Server 2003. NPS ermöglicht, dass ein Computer, der unter Windows Server 2008 ausgeführt wird, als ein RADIUS-Server (Remote Authentication Dial-in User Service) und Proxy fungiert. RADIUS ist ein IETF-Protokoll (Internet Engineering Task
Force), das in den RFCs 2865 und 2866 festgelegt ist und eine zentralisierte Authentifizierung, Autorisierung und Kontoführung (AAA) für Netzwerkzugriffsgeräte, beispielsweise Drahtloszugriffspunkte, bereitstellt. RADIUS-Server führen AAA für Netzwerkszugriffsgeräte durch. RADIUS-Proxys leiten RADIUS-Nachrichten zwischen RADIUS-Clients (Netzwerkzugriffsgeräten) und RADIUS-Servern weiter.
NPS umfasst viele Verbesserungen, um die Bereitstellung eines authentifizierten Netzwerkzugriffs und die Erweiterbarkeit für Komponenten von Drittanbietern zu ermöglichen sowie aktuelle Netzwerktechnologien und Plattformen zu unterstützen. Das neue NPS-Snap-In wird in Abbildung 1 dargestellt.
Abbildung 1 Neues NPS-Snap-In
Abbildung 1 Neues NPS-Snap-In

Features des Netzwerkrichtlinienservers
In diesem Artikel werden die NPS-Features untersucht, die in vorherigen Versionen von Windows® nicht enthalten waren. Am Anfang wird erläutert, wie der Netzwerkzugriffsschutz (Network Access Protection, NAP) dabei hilft, die Anforderungen an die Systemintegrität für Ihr Netzwerk durchzusetzen. Danach werden die Themen Verwaltung, Konfiguration, IPv6-Unterstützung und andere Elemente angeschnitten. Darüber hinaus werden die Features des neuen NPS-Snap-Ins beschrieben.
Netzwerkzugriffsschutz Bei NAP, eingeführt in Windows Server® 2008, handelt es sich um einen Satz neuer Technologien, der Ihnen helfen kann, die Einhaltung der Computerintegritätsanforderungen durchzusetzen, und Ihr Intranet dadurch besser zu schützen. Ihre Integritätsrichtlinien können zum Beispiel angeben, dass eine Firewall installiert und aktiviert werden muss und dass die aktuellen Betriebssystemupdates auf allen Clients installiert werden müssen, die eine Verbindung zu Ihrem Netzwerk herstellen. Mit NAP können Sie individuelle Richtlinien erstellen, um die Computerintegrität zu bescheinigen, bevor Sie einen Netzwerkzugriff oder eine Kommunikation zulassen. Sie können Computer automatisch aktualisieren, um eine fortlaufende Richtlinienkonformität zu gewährleisten, und nicht richtlinienkonforme Computer auf ein eingeschränktes Netzwerk begrenzen, bis sie richtlinienkonform sind. Weitere Informationen finden Sie unter microsoft.com/nap.
In einer NAP-Bereitstellung ist der NPS-Server ein NAP-Integritätsrichtlinienserver, der die Integrität von NAP-Clients im Hinblick auf die NAP-Erzwingungspunkte evaluiert, zum Beispiel die Health Registration Authority (HRA), 802.1X-Zugriffspunkte, VPN-Server und DHCP-Server. Der NPS-Server bestimmt außerdem, ob Clients uneingeschränkten oder eingeschränkten Zugriff auf das Intranet erhalten sollen. Netzwerkrichtlinien, Integritätsrichtlinien und NAP-Einstellungen bestimmen das Verhalten der Integritätsevaluierung für NPS.
Unterstützung von EAPHost- und EAP-Richtlinien NPS unterstützt EAPHost, die neue Architektur für die EAP-Authentifizierungsmethoden (Extensible Authentication Protocol). Diese neue Architektur ermöglicht Anbietern der EAP-Methode die einfache Entwicklung und Installation neuer EAP-Methoden für die 802.1X- oder die PPP (Point-to-Point Protocol)-basierte Authentifizierung sowohl auf Clientcomputern als auch auf NPS-Servern.
EAPHost unterstützt die Installation und die Verwendung aller EAP-Methoden, die unter der EAP-Registrierung unter www.iana.org/assignments/eap-numbers aufgelistet werden, sowie andere beliebte Authentifizierungsmethoden wie Cisco Systems Lightweight EAP (LEAP). EAPHost ermöglicht gleichzeitig mehrere Implementierungen einer EAP-Methode. So können Sie beispielsweise Protected EAP (PEAP) sowohl in der Microsoft-Version als auch in der Version von Cisco Systems installieren und auswählen.
Für Anbieter der EAP-Methode unterstützt EAPHost EAP-Methoden, die bereits für Windows XP und Windows Server 2003 entwickelt wurden. Außerdem wird eine leichtere Möglichkeit unterstützt, neue EAP-Methoden für Windows Vista® und Windows Server 2008 zu entwickeln. Nach der Installation können Sie die für ein bestimmtes Netzwerkzugriffsszenario erforderlichen EAP-Methoden in einer Netzwerkrichtlinie konfigurieren. Eine Netzwerkrichtlinie für NPS ist identisch mit einer RAS-Richtlinie für IAS.
Weitere Informationen zur EAPHost-Architektur erhalten Sie unter technetmagazine.com/issues/2007/05/CableGuy.
In XML gespeicherte Konfiguration Bei IAS wurden die Konfigurationsinformationen in einer Jet-Datenbank gespeichert. Bei NPS werden die Konfigurationsinformationen jetzt im XML-Format gespeichert. Dadurch wird es leichter, die Konfiguration eines NPS-Servers zu exportieren und sie in einen anderen Server zu importieren. Das Exportieren und Importieren von Konfigurationsdateien ist eine Möglichkeit, die Einstellungen mehrerer NPS-Server in einer fehlertoleranten Konfiguration zu synchronisieren. Sie können die NPS-Konfiguration mit dem Befehl „netsh nps export“ exportieren und sie mit dem Befehl „netsh nps import“ importieren.
Einhaltung allgemeiner Engineeringkriterien NPS wurde aktualisiert, um die Bereitstellung in Umgebungen zu unterstützen, in denen die Microsoft® Common Engineering Criteria (CEC) eingehalten werden müssen. Weitere Informationen finden Sie unter microsoft.com/windowsserversystem/cer/allcriteria.mspx.
Stabile NPS-Erweiterungs-DLLs Der NPS-Dienst kann durch Erweiterungs- und Autorisierungs-DLLs erweitert werden. Im Gegensatz zu IAS sind diese Drittanbieterkomponenten in NPS abgeschirmt, damit die für sie auftretenden Probleme keine Auswirkung auf den Betrieb des NPS-Diensts haben.
Unterstützung für IPv6 NPS unterstützt IPv6 und die Bereitstellung in systemeigenen oder getunnelten IPv6-Umgebungen. Sie können IPv6-Adressen für RADIUS-Clients oder Remote-RADIUS-Server konfigurieren, und der NPS-Dienst kann die Kontoauthentifizierung und Autorisierungsvorgänge über IPv6 für Active Directory®-Domänendienste kommunizieren.
IAS und NPS im Vergleich
Wenn Sie mit dem IAS-Snap-In für Windows Server 2003 bereits vertraut sind, werden Sie die folgenden Änderungen im NPS-Snap-In begrüßen:
  • Aus RAS-Richtlinien sind Netzwerkrichtlinien geworden, die sich jetzt unter dem Knoten „Richtlinien“ befinden.
  • Der Knoten „RADIUS-Clients“ befindet sich jetzt unter dem Knoten „RADIUS-Clients und -Server“.
  • Den Knoten „Verbindungsanforderungsverarbeitung“ gibt es nicht mehr. Der Knoten „Verbindungsanforderungsrichtlinien“ befindet sich jetzt unter dem Knoten „Richtlinien“, und der Knoten „Remote-RADIUS-Servergruppen“ befindet sich jetzt unter „RADIUS-Clients und -Server“.
  • Die Bedingungen und Profileinstellungen für den Remotezugriff auf die RAS-Richtlinie auf den Registerkarten „Übersicht“, „Bedingungen“, „Einschränkungen“ und „Einstellungen“ für die Eigenschaften einer Netzwerkrichtlinie wurden umgestaltet.
  • Die Bedingungen und Profileinstellungen für die Verbindungsanforderungsrichtlinie auf den Registerkarten „Übersicht“, „Bedingungen“ und „Einstellungen“ für die Eigenschaften einer Verbindungsanforderungsrichtlinie wurden umgestaltet.
  • Der Ordner „RAS-Protokollierung“ wurde in den Knoten „Kontoführung“ umbenannt und enthält die Knoten „Lokale Datei“ oder „SQL ServerTM“ nicht mehr.

Automatische Generierung sicherer gemeinsamer geheimer RADIUS-Schlüssel Gemeinsame geheime RADIUS-Schlüssel werden zur Überprüfung verwendet, dass RADIUS-Nachrichten von einem RADIUS-Client, -Server oder -Proxy gesendet wurden, der mit dem gleichen gemeinsamen geheimen Schlüssel konfiguriert wurde. Mit gemeinsamen geheimen Schlüsseln werden außerdem vertrauliche RADIUS-Attribute, zum Beispiel Kennwörter und Verschlüsselungsschlüssel, verschlüsselt. Bei sicheren RADIUS-Schlüsseln handelt es sich um eine lange Sequenz (mehr als 22 Zeichen) zufälliger Buchstaben, Zahlen und Satzzeichen.
Mit dem NPS-Snap-In können Sie automatisch einen sicheren gemeinsamen geheimen RADIUS-Schlüssel generieren, wenn Sie einen RADIUS-Client hinzufügen oder bearbeiten. Dieser sichere gemeinsame geheime Schlüssel kann in einen Texteditor, z. B. Editor, kopiert werden, sodass Sie das Netzwerkzugriffsgerät oder den NAP-Erzwingungspunkt mit dem gleichen sicheren gemeinsamen geheimen Schlüssel konfigurieren können.
Integration mit Server-Manager Sie können NPS über die Tools „Aufgaben der Erstkonfiguration“ und „Server-Manager“ installieren. In beiden Fällen installieren Sie NPS mit der Rolle „Netzwerkrichtlinien- und Zugriffsdienste“. Klicken Sie zu Beginn im Tool „Aufgaben der Erstkonfiguration“ unter „Server anpassen“ auf die Option „Rollen hinzufügen“. Öffnen Sie im Tool „Server-Manager“ die „Rollenübersicht“, und klicken Sie auf „Rollen hinzufügen“.
Nachdem NPS installiert ist, können Sie auf „Netzwerkrichtlinien- und Zugriffsdienste“ unter dem Knoten „Rollen“ in der Konsolenstruktur von Server-Manager klicken, um den Status des NPS-Diensts zu prüfen und die in den letzten 24 Stunden aufgetretenen Fehlerereignisse anzuzeigen. Wenn Sie den Knoten „Netzwerkrichtlinien- und Zugriffsdienste“ in der Konsole erweitern, können Sie NPS mit dem NPS-Snap-In konfigurieren.
Verbesserte Netsh-Unterstützung Windows Server 2003 hatte zur Konfiguration von IAS nur einen begrenzten Satz von Befehlen im „netsh aaaa“-Kontext. In Windows Server 2008 enthält der neue „netsh nps“-Kontext einen umfangreichen Satz von Befehlen zum Konfigurieren von NPS in der Befehlszeile oder durch ein Skript. Sie können jetzt mit „netsh nps“-Befehlen RADIUS-Clients und Remote-RADIUS-Server, Netzwerkrichtlinien und die Protokollierung konfigurieren, und für NAP können Sie Integritätsrichtlinien, Systemintegritätsprüfungen und Wartungsservergruppen konfigurieren. Skripts, die aus Befehlen im „netsh nps“-Kontext bestehen, stellen eine andere Möglichkeit für das Synchronisieren von Einstellungen mehrerer NPS-Server in einer fehlertoleranten Konfiguration bereit.
Quelltags zur Netzwerkrichtlinienisolierung Netzwerkrichtlinien können für eine bestimmte Art von Netzwerkzugriffsserver oder NAP-Erzwingungspunkt, zum Beispiel einen DHCP-Server oder eine HRA, konfiguriert werden, der zu einem Quelltag wird, das die Netzwerkrichtlinie klassifiziert. Windows Server 2008-basierte Zugriffsserver und NAP-Erzwingungspunkte umfassen dieses Quelltag in ihren RADIUS-Nachrichten. Beim Empfang einer RADIUS-Nachricht, die einen Zugriff anfordert, versucht der NPS-Dienst, eine geeignete Netzwerkrichtlinie zu finden, die das gleiche Quelltag hat wie die eingehende Nachricht. Wenn keine übereinstimmende Richtlinie vorhanden ist, versucht NPS, für die Richtlinien ohne ein Quelltag eine geeignete Netzwerkrichtlinie zu finden.
Das Verwenden des Quelltags in Netzwerkrichtlinien und eingehenden RADIUS-Nachrichten trennt die verschiedenen Arten von Netzwerkrichtlinien voneinander. Zum Beispiel werden Netzwerkrichtlinien für DHCP-Server für VPN-Verbindungen nicht verwendet.
Integration mit dem Cisco-Netzwerkzugriffssteuerelement NPS unterstützt Features, sodass eine bessere Integration in Umgebungen mit Cisco-Hardware und Netzwerkzugriffssteuerung (NAC) ermöglicht wird. Die Features umfassen den Support für das HCAP (Host Credential Authorization Protocol) und die HCAP-Bedingungen, die Bedingung für den Richtlinienablaufzeitpunkt und die Netzwerkrichtlinieneinstellung „Netzwerkzugriffsschutz“ für den erweiterten Status.
Neue Netzwerkrichtlinienbedingungen Die Netzwerkrichtlinien in NPS haben neue Bedingungen, die zur Angabe von Computergruppen, Benutzergruppen, zulässigen EAP-Typen sowie von Client- und Zugriffsserver-IPv6-Adressen dienen. Für die Unterstützung von HCAP enthält NPS neue Bedingungen für Standort- und Benutzergruppen. Für die Unterstützung von NAP enthält NPS neue Richtlinienbedingungen für Identitätstyp, Integritätsrichtlinie, NAP-fähige Computer, Betriebssystem und Richtlinienablaufzeitpunkt.
NPS-Snap-In Das neue NPS-Snap-In wurde maßgeblich verbessert, sodass Sie RADIUS-Clients und Remote-RADIUS-Server, Netzwerkrichtlinien für allgemeine Netzwerkzugriffsszenarios, Integritätsrichtlinien und NAP-Einstellungen für NAP-Szenarios sowie Protokollierungseinstellungen leichter erstellen und verwalten können.
Im Knoten „RADIUS-Clients und -Server“ können Sie RADIUS-Clients (Netzwerkzugriffsserver, NAP-Erzwingungspunkte oder andere RADIUS-Proxys, wenn NPS als RADIUS-Server fungiert) und Remote-RADIUS-Servergruppen konfigurieren (andere RADIUS-Server, wenn NPS als RADIUS-Proxy fungiert).
Im Knoten „Richtlinien“ können Sie Folgendes konfigurieren: die Verbindungsanforderungsrichtlinien (ob der NPS-Dienst als RADIUS-Server oder Proxy fungiert), Netzwerkrichtlinien (Autorisierungs- und Verbindungseinstellungen und -einschränkungen, wenn der NPS-Dienst als RADIUS-Server fungiert) und Integritätsrichtlinien (Systemintegritätskonformität für NAP-Clients). Wenn Sie im Detailbereich eine Verbindungsanforderungsrichtlinie oder eine Netzwerkrichtlinie auswählen, zeigt das NPS-Snap-In die Bedingungen und Einstellungen der Richtlinie an. In Abbildung 2 wird ein Beispiel dafür gezeigt.
Abbildung 2 Durch NPS-Snap-In verbesserte Anzeige
Abbildung 2 Durch NPS-Snap-In verbesserte Anzeige
Im Knoten „Netzwerkzugriffsschutz“ ermöglicht der Knoten „Systemintegritätsprüfungen“ die Konfiguration der NAP-Integritätsanforderungen. Mit dem Knoten „Wartungsservergruppen“ können Sie den Satz von Servern konfigurieren, auf die beschränkte NAP-Clients für die VPN- und die DHCP-NAP-Erzwingungsmethoden Zugriff haben. Schließlich können Sie im Knoten „Kontoführung“ konfigurieren, wie NPS die Informationen zur Kontoführung speichern soll.
Das NPS-Snap-In umfasst einen umfangreichen Satz von Assistenten zur Automatisierung der Erstkonfiguration von RADIUS-Clients und der für die NAP-Erzwingungsmethoden erforderlichen Richtlinien, DFÜ- oder VPN-basierte Verbindungen und 802.1X-authentifizierte Drahtlos- und Kabelverbindungen. Für die NAP-Erzwingungsmethoden konfiguriert der NAP-Assistent automatisch alle Verbindungsanforderungsrichtlinien, Netzwerkrichtlinien und Integritätsrichtlinien.
Diese neuen Assistenten sind verfügbar, wenn Sie auf den NPS-Knoten im NPS-Snap-In klicken. Zum Konfigurieren von Richtlinien und Einstellungen für die NAP-Erzwingungsmethoden wählen Sie in der Dropdownliste „Standardkonfiguration“ die Option „Netzwerkzugriffsschutz“ aus und klicken anschließend auf „NAP konfigurieren“. Zum Konfigurieren von Richtlinien und Einstellungen für den VPN- oder DFÜ-Netzwerkzugriff wählen Sie in der Dropdownliste „Standardkonfiguration“ die Option „RADIUS-Server für DFÜ- oder VPN-Verbindungen“ aus und klicken anschließend auf „VPN oder DFÜ konfigurieren“. Zum Konfigurieren von Richtlinien und Einstellungen für den 802.1X-authentifizierten verkabelten oder drahtlosen Zugriff wählen Sie in der Dropdownliste „Standardkonfiguration“ die Option „RADIUS-Server für drahtlose oder verkabelte 802.1X-Verbindungen“ aus und klicken anschließend auf „802.1X konfigurieren“.
Alle Assistenten führen Sie durch die häufigsten Konfigurationselemente für Ihr ausgewähltes Szenario. Die Assistenten für die NAP-Erzwingungsmethoden sind besonders hilfreich: Der NAP-Assistent für die VPN-Erzwingung erstellt eine Verbindungsanforderungsrichtlinie, drei Netzwerkrichtlinien (für richtlinienkonforme NAP-Clients, nicht richtlinienkonforme NAP-Clients, und nicht NAP-fähige Clients) sowie zwei Integritätsrichtlinien (für richtlinienkonforme und nicht richtlinienkonforme NAP-Clients).
Der neue NAP-Assistent und andere Assistenten zum Erstellen von RADIUS-Clients, Remote-RADIUS-Servergruppen, Verbindungsanforderungsrichtlinien und Netzwerkrichtlinien vereinfachen das Konfigurieren von NPS für viele verschiedene Netzwerkzugriffsszenarios.

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


 Windows PowerShell: Ein tieferer Einblick
Windows PowerShell
Ein tieferer Einblick
Don Jones

Windows PowerShell steckt voller Features, die von vielen Administratoren oft übersehen werden. Wenn Sie sich näher damit befassen, werden Sie auf einige erstaunliche Funktionen stoßen. Tatsächlich entdecke ich selbst oft neue Features bei einem bestimmten Cmdlet, das ich meiner Meinung nach bereits in- und auswendig kannte.
In den Windows PowerShellTM-Kursen, die ich unterrichte, empfehle ich Administratoren, einen Kalender für das Cmdlet des Tages zu erstellen, ähnlich den Kalendern mit einem Wort des Tages, die man kaufen kann. So können sie sich am Morgen eines jeden Wochentags (das Wochenende gebe ich ihnen frei) ein paar Minuten lang mit den vollständigen Funktionen eines Cmdlets vertraut machen. Windows PowerShell enthält ungefähr 130 Cmdlets, sodass Sie praktisch alle Funktion der Windows PowerShell in etwa sechs Monaten kennenlernen können, wenn Sie sich an diesen Zeitplan halten. Dann können Sie sich den ganzen Exchange Server 2007-Cmdlets zuwenden.
Im Artikel dieses Monats erhalten Sie Beispiele für eine Reihe Entdeckungen, die Sie dabei möglicherweise machen. Es wird veranschaulicht, was Sie in einigen wenigen Minuten erreichen können, wenn Sie die Funktionen verschiedener Cmdlets eingehender untersuchen.

Schönere HTML-Berichte
Ein Cmdlet, das nicht ausreichend genutzt wird, ist ConvertTo-HTML. Dieses intelligente Cmdlet kann eine Sammlung von Eingabeobjekten – Dienste, Prozesse, Objekte der Windows®-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) oder anderes – annehmen und sie in eine HTML-Tabelle verwandeln. Dann können Sie die HTML-Tabelle nach Out-File leiten, und schon verfügen Sie über eine HTML-Seite, die zum Bereitstellen auf einem Intranetwebserver geeignet ist. Sie könnten beispielsweise die Ausführung dieser einfachen Zeile jeweils am Morgen planen:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Auf diese Weise wird ein HTML-Bericht der Dienste erstellt, die automatisch gestartet werden sollen, aber nicht ausgeführt werden, wie in Abbildung 1 dargestellt.
Abbildung 1 Ein HTML-Bericht der Dienste, die nicht ausgeführt werden
Abbildung 1 Ein HTML-Bericht der Dienste, die nicht ausgeführt werden
Doch möglicherweise möchten Sie einen Bericht erstellen, der etwas attraktiver ist. Glücklicherweise erstellt das ConvertTo-HTML-Cmdlet sauberen HTML-Code, das heißt, in den erstellten HTML-Code wird keine Formatierung eingebettet. Gemäß den HTML-Regeln sollten Sie nie Formatierung in den HTML-Code stellen (oder zumindest so wenig wie möglich). Stattdessen wird die Formatierung in ein externes Cascading Style Sheet (CSS) gestellt und das CSS mit der HTML-Datei verknüpft. Diese Verknüpfung kann mit ConvertTo-HTML erstellt werden.
CSS ist mit dem <HEAD>-Abschnitt einer HTML-Datei verknüpft. Wenn Sie sich die Hilfe für ConvertTo-HTML ansehen, werden Sie feststellen, dass die Syntax einige Parameter enthält, die Sie möglicherweise übersehen haben.
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
Der –head-Parameter ermöglicht das Festlegen von zusätzlichem HTML-Code, der in den <HEAD>-Abschnitt des Skripts eingefügt werden soll. Jetzt kann der Einzeiler leicht geändert werden, sodass er mit einer vorhandenen CSS-Datei verknüpft wird, die die auf die HTML-Tabelle anzuwendende Formatierung enthält:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
Hier wurde der –head-Parameter zum Einfügen einer Verknüpfung mit einer CSS-Datei verwendet, die sich im selben Ordner wie die Ausgabe-HTML-Datei befindet. Zudem wurde der –title-Parameter zum Festlegen des Titels der Webseite verwendet. Das Ergebnis ist in Abbildung 2 dargestellt. Der Text der verwendeten Style.CSS-Datei sieht folgendermaßen aus:
Abbildung 2 Ein mit einer CSS-Datei formatierter HTML-Bericht
Abbildung 2 Ein mit einer CSS-Datei formatierter HTML-Bericht
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }

Leichteres Filtern
Cmdlet des Monats
In diesem Monat geht es um ein Cmdlet-Paar: Start-Transcript und Stop-Transcript. Beide dienen zur Steuerung von Windows PowerShell-Aufzeichnungsprotokollen, d. h. alles, was im Konsolenfenster angezeigt wird, wird in eine von Ihnen angegebene Textdatei geschrieben. Es ist ziemlich einfach. Führen Sie zunächst Start-Transcript aus, und legen Sie einen Dateinamen fest. Führen Sie anschließend Stop-Transcript aus, um die Protokollierung zu beenden, und schließen Sie die Datei. Dies ist eine hervorragende Möglichkeit, von der Ad-hoc-Shellverwendung zur formellen Skripterstellung überzugehen. Wenn erst einmal einzelne Befehlszeilen in der Shell arbeiten, können Sie diese einfach aus der von Ihnen erstellten Protokolldatei kopieren und einfügen. Selbstverständlich können Sie auch einfach das Protokoll so bearbeiten, dass nur noch das eigentliche Skript vorhanden ist. Jeffery Hicks, ein Kollege bei MVP, hat sogar ein Skript geschrieben, das Protokolle analysiert und sie in Windows PowerShell PS1-Dateien verwandelt. Dieses Skript finden Sie unter blog.sapien.com/current/2006/11/28/powershell-transcripts.html.

Im Folgenden wird das Get-WMIObject-Cmdlet nähere betrachtet. Seine Syntax, die in der integrierten Hilfe der Windows PowerShell aufgeführt wird, deutet auf ungenutzte Funktionen hin:
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Ein häufiger Fehler von neuen Windows PowerShell-Benutzern besteht darin, dass sie einen WMI-Befehl wie diesen ausgeben:
Gwmi Win32_NTLogEvent –comp Server2
Dieser Befehl ruft die Ereignisprotokolleinträge von Server2 ab, und zwar alle Ereignisprotokolleinträge. Es dauert eine Weile, bis Server2 diese Aufgabe verarbeitet und überträgt, und Windows PowerShell braucht ebenfalls einige Zeit, um mit einer so großen Sammlung etwas Nützliches anzustellen.
Ein besserer Ansatz besteht darin, dass Server2 die Ereignisse, die wirklich wichtig sind, sucht und sendet. Dies könnte durchaus mit einer Abfrage in der WMI-Abfragesprache (WMI Query Language, WQL) erfolgen. Manche empfinden diese Abfragesyntax als schwierig, doch in der Windows PowerShell können Sie mithilfe des –filter-Parameters einfach nur den Filteranteil einer WQL-Abfrage angeben.
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Auf diese Weise werden alle Ereignisse (aus beliebigen Protokollen) mit der Ereignis-ID 1024 abgerufen. Beachten Sie, dass das Filterkriterium = als Vergleichsoperator anstelle des –eq-Operators der Windows PowerShell verwendet. Der Grund besteht darin, dass der Filter einfach nur an den WMI-Dienst des Remotecomputers zur Verarbeitung übergeben wird. Daher muss das Kriterium in der WMI-Syntax und nicht in der Windows PowerShell-Syntax vorliegen.
Es gibt auch einen –filter-Parameter in anderen Cmdlets, beispielsweise Get-ChildItem, das Cmdlet hinter Aliasen wie Dir und Ls. In den meisten Fällen übergibt der –filter-Parameter Ihr Filterkriterium direkt an die zugrunde liegende Technologie. Dies führt zu etwas, das ich gerne als Quellfilterung bezeichne, und das oft viel schneller ist, als alle Objekte zu übertragen und diese durch das Where-Object-Cmdlet laufen zu lassen, um die nicht erwünschten herauszufiltern.

Übersehene Cmdlets
Der Ansatz, bei dem Sie sich mit einem Cmdlet pro Tag befassen, wird Ihnen durchaus helfen, Cmdlets besser zu verstehen, die Sie Ihrer Meinung nach bereits kannten. Doch ein weiterer guter Grund für einen Kalender mit einem Cmdlet pro Tag besteht darin, dass Sie auf diese Weise keine Cmdlets übersehen, die Sie sonst vielleicht überhaupt nicht entdecken würden. Eins meiner Lieblings-Cmdlets, das von vielen nicht verwendet wird, ist Resolve-Path. Bei einem Platzhalterpfad gibt es eine Sammlung von Datei- und Ordnernamen zurück, die dem Pfad entsprechen. Es ähnelt dem Get-ChildItem-Cmdlet (d. h. die vertrauten Dir- oder Ls-Aliase), doch statt eine ganze Datei und Ordnerobjekte zurückzugeben, gibt es einfache Zeichenfolgen zurück, die zur weiteren Filterung oder Verarbeitung an andere Cmdlets geleitet werden können. Seine Verwendung ist einfach:
Resolve-Path C:\P*
Diese einfache Zeile gibt Pfade wie C:\Programme, C:\Processes.txt und so weiter zurück. Abbildung 3 zeigt zwei Beispiele für die Verwendung dieses Cmdlets.
Abbildung 3 Verwendung des praktischen, aber oft übersehenen Resolve-Path-Cmdlets
Abbildung 3 Verwendung des praktischen, aber oft übersehenen Resolve-Path-Cmdlets

Beginnen Sie ganz am Anfang
Wenn Sie damit anfangen wollen, sich pro Tag mit einem Cmdlet zu beschäftigen, führen Sie Gcm aus, ein Alias für Get-Command. Sie erhalten eine Liste aller Cmdlets, die die Windows PowerShell kennt, einschließlich jener, die Sie über Snap-Ins wie beispielsweise die Exchange Server 2007-Verwaltungsshell, die PowerShell-Communityerweiterungen und so weiter hinzugefügt haben. Wählen Sie einfach das erste auf der Liste aus – bei mir war es Add-Content – und lesen Sie die entsprechende Hilfe:
Help Add-Content –full
Sie brauchen die vollständige Hilfe, nicht die knappere Standardhilfe, um eine vollständige Beschreibung der einzelnen Parameter zu erhalten, einige Beispiele der Verwendung des Cmdlets zu sehen und weitere ausführliche Informationen herauszufinden. Nehmen Sie sich etwas Zeit, um mit dem Cmdlet zu experimentieren. (Sie könnten einen virtuellen Computer verwenden, damit Sie nicht mit der Produktionsumgebung arbeiten müssen.) Ich empfehle, jeden Wochentag 10 Minuten darauf zu verwenden, am besten immer zur selben Tageszeit, damit es zur Gewohnheit wird. In kürzester Zeit werden Sie alle Merkmale und Funktionen von Windows PowerShell gründlich kennenlernen.

Don Jones ist der führende Experte für die Skripterstellung bei SAPIEN Technologies und Mitverfasser von Windows PowerShell: TFM (SAPIEN Press, 2007). Sie erreichen ihn unter www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Die R&#252;ckkehr von WinRM
Hey, Scripting Guy!
Die Rückkehr von WinRM
Die Scripting Guys von Microsoft

Als die Scripting Guys mit der Entwicklung einer zweiteiligen Reihe zu Windows® Remote Management (WinRM) begannen, drängte sich ein wichtiges Thema sofort in den Vordergrund: die Sicherheit. Schließlich kannten die Scripting Guys die Probleme, die bei der Veröffentlichung des letzten Teils der Harry Potter-Reihe aufgetreten waren: Vorbestellte Exemplare der Bücher wurden versehentlich zu früh versandt und vor dem offiziellen Veröffentlichungstermin des Buchs geliefert. (Hat sich dies als Problem erwiesen? Nein, natürlich nicht, der Verlag bat die Kunden einfach, das Buch erst nach dem Veröffentlichungsdatum zu lesen.)
Das ist aber noch nicht alles. Das Ende des Buchs und der Reihe wurde verraten, bevor die Bücher erhältlich waren. (Falls Sie das Buch noch nicht gelesen haben, hier der Ausgang der Geschichte: Es stellt sich heraus, dass Harry Potter eine Art Zauberer oder so was ist!) Zudem waren gescannte Kopien aller Seiten sofort im Internet verfügbar, in einigen Fällen noch bevor die Autorin J. K. Rowling diese Seiten überhaupt geschrieben hatte. Insgesamt betrachtet handelte es sich schon um ein gewisses Sicherheitsdebakel, und die Scripting Guys wollten auf keinen Fall zulassen, dass ihnen etwas Ähnliches passierte. Denn wenn die Leute schon so erpicht darauf waren, das Ende der Harry Potter-Saga zu verraten, ist gar nicht auszudenken, wie weit sie gehen würden, um das Ende der zweiteiligen Reihe der Scripting Guys zu WinRM in Erfahrung zu bringen.
Glücklicherweise konnten die Scripting Guys sicherstellen, dass ihre Geheimnisse bewahrt wurden. Zugegebenermaßen war dies hauptsächlich der Tatsache zu verdanken, dass sie den zweiten Teil der Reihe erst weit nach dem Abgabetermin für den Artikel schrieben. Nun ja, der Scripting Guy, der diesen Artikel schreibt, war den ganzen August über im Urlaub, und im Gegensatz zu einem erstaunlich hohen Prozentsatz von Microsoft-Mitarbeitern verwendet er im Urlaub keinen Computer – er schaut nicht mal einen an.
Zugegeben: Selbst wenn er nicht im Urlaub ist, wirft er selten einen Blick auf einen Computer – von dessen Verwendung ganz zu schweigen. Aber das ist eine andere Geschichte.
Jedenfalls wissen wir, dass viele von Ihnen in den letzten vier Wochen nicht schlafen konnten und sich nächtelang den Kopf darüber zerbrochen haben, wie die WinRM-Saga wohl enden wird. Nun, die gute Nachricht ist, dass diese schmerzhaft langen Wochen schlafloser Spannung vorbei sind. Hier folgt als Premiere der aufregende Abschluss der zweiteiligen Reihe der Scripting Guys zu WinRM. Also, eigentlich ist er drüben in Abbildung 1 zu sehen.
Figure 1 Die Auflösung (Close Figure 1)
strComputer = "atl-fs-01.fabrikam.com"

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

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

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

Do Until objResponse.AtEndOfStream
    strXML = objResponse.ReadItem

    Set objXMLDoc = CreateObject("Microsoft.XMLDom")
    objXMLDoc.async=False
    objXMLDoc.loadXML(strXML)

    Set objElement = objXMLDoc.documentElement
    Wscript.Echo "Name: " & objElement.ChildNodes(0).ChildNodes(0).NodeValue
    Wscript.Echo "Display Name: " &  objElement.ChildNodes(1).ChildNodes(0).NodeValue
    Wscript.Echo
Loop
Ja, wir verstehen schon: Die atemberaubende Wendung verursacht auch bei uns eine Gänsehaut. objElement.ChildNodes(0).ChildNodes(0).NodeValue! Wer hätte das geahnt? Dies liegt natürlich daran, dass aufgrund unserer strengen Sicherheitsmaßnahmen sogar die Scripting Guys selbst keine Ahnung hatten, wie die Reihe enden würde. Aber jetzt ist das Geheimnis gelüftet.
Bevor wir jedoch ins Detail gehen, sollten wir die wichtigsten Punkte der Reihe kurz wiederholen, falls es noch jemanden gibt, der Teil 1 (der unter technetmagazine.com/issues/2007/11/HeyScriptingGuy zu finden ist) aus unerfindlichen Gründen nicht gelesen hat. In Teil 1 wurde WinRM vorgestellt, eine neue Technologie von Windows Server® 2003 R2, Windows Vista® und Windows Server 2008, die die Verwaltung von Computern über das Internet und sogar über Firewalls hinweg stark vereinfacht. Zwar konnten mit der Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) schon immer Computer von einem Remotestandort aus verwaltet werden, WMI stützt sich jedoch auf DCOM (Distributed COM) als Remoteverwaltungstechnologie. Das ist soweit auch kein Problem, abgesehen davon, dass viele Firewalls DCOM-Datenverkehr standardmäßig blockieren. Sie können zwar die entsprechenden Ports öffnen und DCOM-Datenverkehr zulassen, viele Netzwerkadministratoren machen jedoch von dieser Möglichkeit nur ungern Gebrauch. Ihre Hauptsorge besteht darin, dass durch Zulassen von DCOM gleichzeitig allen möglichen böswilligen Angriffen die Tür geöffnet wird.
Daher wurde WinRM entwickelt, „die Microsoft-Implementierung von WS-Management Protocol, eines SOAP-basierten, firewallfreundlichen Standardprotokolls, das die Zusammenarbeit von Hardware und Betriebssystemen verschiedener Hersteller ermöglicht“. Damit wird eigentlich nur vornehm ausgedrückt, dass Sie jetzt die Remoteverwaltung mit Standardinternetprotokollen wie HTTP und HTTPS durchführen können.
Wie im letzten Monat angemerkt wurde, können mit WinRM mühelos Verbindungen zu Remotecomputern hergestellt und WMI-Informationen von ihnen abgerufen werden. Bedeutet dies also, dass diese Technologie absolut perfekt ist? Nun, das ist nicht ganz richtig. Es wurde bereits darauf hingewiesen: Wenn WinRM Daten an das aufrufende Skript sendet, kommen diese Daten im XML-Format zurück. Die Analyse und Verwendung von XML kann etwas schwierig sein, insbesondere für Systemadministratoren mit begrenzter Erfahrung in diesem Bereich. Aus diesem Grund umfasst WinRM eine XSL-Transformation, die die zurückgegebenen Daten in ein leichter lesbares Format konvertiert.
So weit so gut, allerdings bedeutet dies auch, dass die Ausgabe immer ungefähr so aussieht:
Win32_Service
    AcceptPause = false
    AcceptStop = true
    Caption = User Profile Service
    CheckPoint = 0
    CreationClassName = Win32_Service
Dies ist nicht unbedingt eine schlechte Sache, bedeutet jedoch auch, dass die Ausgabe immer in das Befehlsfenster geschrieben wird. Sie können standardmäßig nicht ohne Weiteres Daten in einer Textdatei speichern, diese Daten in eine Datenbank oder Microsoft® Excel®-Tabelle schreiben und nicht viel anderes mit diesen Daten anfangen als die Informationen auf dem Bildschirm anzuzeigen. Das ist nicht gut genug.
Darüber hinaus wird das Problem verstärkt, wenn Sie sich dafür entscheiden, nur eine bestimmte Anzahl von Eigenschaften für eine WMI-Klasse zurückzugeben (um beispielsweise den Netzwerkverkehr zu verringern). Bei der Arbeit mit nur einigen, nicht allen Eigenschaften einer Klasse erhalten Sie eine ähnliche Ausgabe wie die folgende:
XmlFragment
    DisplayName = Windows Event Log
    Name = EventLog

XmlFragment
    DisplayName = COM+ Event System
    Name = EventSystem
Interessant, aber nicht gerade die ästhetisch ansprechendste Darstellung von Informationen (insbesondere die Überschrift „XmlFragment“, die immer wieder im Bericht erscheint).
Was können Sie jedoch dagegen tun? Benutzerdefinierten Code zum Analysieren und Formatieren dieser XML-Daten schreiben? Das klingt nicht gerade nach einem Schritt, den ein im Bereich Systemverwaltung tätiger Skriptersteller ausführen würde. Oder doch?

Wenn Sie möchten, dass etwas ordentlich erledigt wird, nehmen Sie die Sache selbst in die Hand
Wie sich herausstellt, ist die Arbeit mit den von WinRM zurückgegebenen XML-Rohdaten bei weitem keine so schwierige Aufgabe, wie es vielleicht scheint. In diesem Monat wird eine einfache Methode zum Analysieren und Formatieren von XML-Daten aufgezeigt. Der hier verwendete Ansatz ist keineswegs die einzige Möglichkeit für die Arbeit mit XML. Das ist jedoch kein Problem, da unser Hauptziel an dieser Stelle darin besteht, aufzuzeigen, dass Sie nicht auf die XSLT-Transformation angewiesen sind. Sobald Sie den Grundgedanken verstehen, sind Ihrer Kreativität in Bezug auf die Verwendung von WinRM-Daten keine Grenzen mehr gesetzt.
Es gibt jedoch einen kleinen Haken: Damit dieser Artikel nicht die festgelegte Länge überschreitet, wird der größte Teil des Skripts, das Sie gerade in Abbildung 1 gesehen haben, übersprungen. Das sollte kein allzu großes Problem darstellen, da die ersten beiden Drittel des Skripts im letzten Monat in dieser Rubrik ausführlich beschrieben wurden. Stattdessen konzentriert sich dieser Artikel auf das letzte Drittel des Skripts – den Teil, in dem tatsächlich mit den zurückgegebenen Daten gearbeitet wird.
Wie Sie sehen, setzt dieser Teil der WinRM-Reihe an der Stelle an, an der eine Instanz des WSMan.Automation-Objekts erstellt, ein Remotecomputer abgefragt (in diesem Fall atl-fs-01.fabrikam.com) und Informationen zu allen Diensten, die auf diesem Computer ausgeführt werden, erhalten wurden. Dies führt zu der Zeile im Skript, in der eine Do Until-Schleife zum Lesen und Verarbeiten der zurückgegebenen XML-Daten eingerichtet wird. Diese Schleife wird fortgesetzt, bis keine zu lesenden und zu verarbeitenden Daten mehr vorhanden sind. (Oder um es so klingen zu lassen, als ob wir wüssten, wovon wir reden: Diese Schleife wird bis zum Zeitpunkt fortgesetzt, an dem die AtEndOfStream-Eigenschaft der XML-Datei „True“ ist.)
Dies ist die Codezeile, die hier gemeint ist, und bei der die Geschichte in diesem Monat beginnt:
Do Until objResponse.AtEndOfStream
Innerhalb der Schleife wird als Erstes die ReadItem-Methode verwendet, um den ersten Abschnitt der zurückgegebenen XML-Daten zu lesen. (Da mit WinRM gearbeitet und Dienstinformationen abgerufen werden, besteht dieser erste Abschnitt aus allen Daten, die für den ersten Dienst in der Sammlung zurückgegeben wurden.) Nach dem Speichern dieser Daten (die wiederum im XML-Format vorliegen) in einer Variablen namens „strXML“ wird eine Instanz des Microsoft.XMLDom-Objekts erstellt. Dadurch entsteht effektiv ein leeres XML-Dokument, mit dem gearbeitet werden kann:
Set objXMLDoc = _
    CreateObject("Microsoft.XMLDom")
Sobald das leere Dokument bereitsteht, wird der Wert der Async-Eigenschaft auf „False“ festgelegt und anschließend die loadXML-Methode aufgerufen.
Somit kommen wir zu – was haben Sie da gerade gesagt? Warum der Wert der Async-Eigenschaft auf „False“ festgelegt wird? Und weshalb die loadXML-Methode aufgerufen wird? Gute Fragen – die könnten glatt von uns stammen!
Zunächst einmal gibt die Async-Eigenschaft an, ob das Skript das asynchrone Herunterladen von XML-Informationen zulässt. Wenn diese Eigenschaft „True“ ist, wird das Herunterladen gestartet und die Kontrolle sofort an das Skript zurückgegeben, selbst wenn der Download noch nicht abgeschlossen ist. Das klingt zugegebenermaßen recht gut. Unglücklicherweise wird jedoch das Skript dann so fortgesetzt, als ob alle benötigten Informationen zur Verfügung stehen. Wenn allerdings nicht alle erforderlichen Informationen vorhanden sind, kommt es zu Problemen. Daher wird die Async-Eigenschaft auf „False“ festgelegt.
Hinweis: Sie könnten natürlich Code schreiben, um den Downloadstatus regelmäßig zu überwachen, und dadurch sicherstellen, dass das Skript nicht vorzeitig fortgesetzt wird. Dies funktioniert, aber eine weitaus einfachere Methode besteht darin, einfach den Wert der Async-Eigenschaft auf „False“ festzulegen. In diesem Fall wird das Skript blockiert, bis der Download abgeschlossen ist. Das heißt bei einem angefangenen Download wartet das Skript, bis dieser beendet ist, bevor weitere Schritte durchgeführt werden.
Was die loadXML-Methode angeht, so stimmt ihre Funktion weitgehend mit dem überein, worauf ihr Name bereits schließen lässt: Sie lädt ein wohlgeformtes XML-Dokument (oder Dokumentfragment) in das leere Dokument. Jetzt muss lediglich die loadXML-Methode aufgerufen werden, wobei die Variable „strXML“ als einziger Methodenparameter übergeben wird:
objXMLDoc.loadXML(strXML)
Das Ergebnis? Die WinRM-Daten wurden in ein virtuelles XML-Dokument verwandelt. Das bedeutet, dass Sie mit der Verwendung von XML-Standardmethoden beginnen können, um dieses virtuelle Dokument zu analysieren.
Zu diesem Zweck müssen Sie dann die folgende Codezeile verwenden, um einen Objektverweis auf das Stammelement in der XML-Datei zu erstellen:
Set objElement = objXMLDoc.documentElement
Jetzt wird die Sache richtig unterhaltsam. (Natürlich vorausgesetzt, dass Ihre Vorstellung von Unterhaltung in der Analyse einer XML-Datei besteht. Für die Scripting Guys ist dies definitiv der Fall.)
Wie Sie sich vielleicht erinnern, sieht die Abfrage in der WMI-Abfragesprache (WMI Query Language, WQL) – in der WinRM-Terminologie als „Filter“ bezeichnet – folgendermaßen aus:
strFilter = "Select Name, DisplayName " & _
  "From Win32_Service Where State = 'Running'"
Es wurden also zwei Eigenschaften von der Win32_Service-Klasse angefordert: „Name“ und „DisplayName“. (Dazu wurde eine Where-Klausel eingefügt, die die zurückgegebenen Daten auf Dienste beschränkt, die gerade ausgeführt werden. Darum müssen Sie sich jedoch an dieser Stelle nicht kümmern.) Ist es wichtig, dass zwei Eigenschaften angefordert wurden? Ist die Reihenfolge der Anforderung von Bedeutung? Vielleicht. Woher sollen wir das denn wissen?
Ach ja, richtig: Vielleicht sollten wir als Autoren dieses Artikels wirklich die Antworten auf diese Fragen kennen. Kein Problem: Zufällig wissen wir, dass die Antwort auf beide Fragen „Ja“ lautet. Ist es wichtig, dass in der WQL-Abfrage zwei Eigenschaften angefordert wurden? Ja, schließlich handelt es sich dabei um die einzigen Eigenschaftswerte, die zurückgegeben werden, im Gegensatz zu einer Select * From-Abfrage, bei der Werte für alle Eigenschaften einer Klasse zurückgegeben werden.
Ist dann auch die Reihenfolge dieser beiden Eigenschaften wichtig? Absolut. Die Reihenfolge, in der die Eigenschaftennamen angegeben werden, ist dieselbe Reihenfolge, in der die Eigenschaftswerte zurückgegeben werden. Dies ist wichtig, da jeder Eigenschaftswert als untergeordneter Knoten (oder Abschnitt) des Stammelements zurückgegeben wird. Welcher Eigenschaftswert wird als erster untergeordneter Knoten zurückgegeben? Diese Frage lässt sich leicht beantworten. In diesem Fall ist der erste untergeordnete Knoten die Name-Eigenschaft, da diese als erste Eigenschaft in der WQL-Abfrage aufgelistet wird. Welche Eigenschaft wird als zweiter untergeordneter Knoten zurückgegeben? Richtig, die DisplayName-Eigenschaft, weil sie das zweite Element ist, das in der Abfrage aufgelistet wird.
Moment mal! Haben Sie das selbst herausgefunden, oder hat Ihnen jemand heimlich ein Vorausexemplar dieses Artikels zur Verfügung gestellt?
Jedenfalls wird es dadurch einfach, den Wert der Name-Eigenschaft auszugeben. Sie müssen lediglich auf den „NodeValue“ des ersten Elements (Element 0) in der ersten ChildNodes-Sammlung (Element 0) verweisen, ungefähr so:
Wscript.Echo "Name: " & _
objElement.ChildNodes(0).ChildNodes(0).NodeValue
Wie wird auf den Wert der DisplayName-Eigenschaft verwiesen? In diesem Fall verweisen Sie auf den „NodeValue“ des ersten Elements in der zweiten ChildNodes-Sammlung (Element 1):
Wscript.Echo "Display Name: " & _
objElement.ChildNodes(1).ChildNodes(0).NodeValue
Wie verhält es sich, wenn eine dritte Eigenschaft (beispielsweise „Status“) in der WQL-Abfrage enthalten ist? In diesem Fall verweisen Sie einfach auf den „NodeValue“ des ersten Elements in der dritten ChildNodes-Sammlung (Element 2):
Wscript.Echo "Status: " & _
objElement.ChildNodes(2).ChildNodes(0).NodeValue
So geht es weiter bis zur letzten Eigenschaft.
Wie sieht jetzt die Skriptausgabe aus? Etwa so:
Display Name: Windows Event Log
Name: EventLog

Display Name: COM+ Event System
Name: EventSystem
Zugegebenermaßen unterscheidet sich dies scheinbar nur wenig von der WinRM-Standardausgabe (obwohl die alberne XmlFragment-Überschrift beseitigt wurde). Folgendes macht den Unterschied aus: Durch die Arbeit mit den einzelnen Eigenschaftswerten sind Sie nicht mehr auf die Standardformatierung angewiesen (beachten Sie, dass die Bezeichnung „Display Name“ anstelle von „DisplayName“ verwendet wird), und es entfällt die Beschränkung, dass Informationen nur im Befehlsfenster angezeigt werden können.
Möchten Sie stattdessen diese Daten lieber in eine Excel-Tabelle schreiben? Nichts leichter als das: Fügen Sie zunächst den folgenden Codeblock (durch den eine neue Excel-Tabelle erstellt und konfiguriert wird) unmittelbar nach der Zeile im WinRM-Skript ein, durch die die Enumerate-Methode aufgerufen wird:
Set objExcel = _
  CreateObject("Excel.Application")
objExcel.Visible = True
Set objWorkbook = objExcel.Workbooks.Add()
Set objWorksheet = objWorkbook.Worksheets(1)

i = 2
objWorksheet.Cells(1,1) = "Name"
objWorksheet.Cells(1,2) = "Display Name"
Ersetzen Sie nun die ursprüngliche Do Until-Schleife durch die in Abbildung 2. Probieren Sie es aus.
Figure 2 Neue Do Until-Schleife (Close Figure 2)
Do Until objResponse.AtEndOfStream
  strXML = objResponse.ReadItem

  Set objXMLDoc = CreateObject("Microsoft.XMLDom")
  objXMLDoc.async=False
  objXMLDoc.loadXML(strXML)

  Set objElement = objXMLDoc.documentElement
  objExcel.Cells(i, 1) = objElement.ChildNodes(0).ChildNodes(0).NodeValue
  objExcel.Cells(i, 2) = objElement.ChildNodes(1).ChildNodes(0).NodeValue
  i = i + 1
Loop

WinRM, Teil 3?
Dieser Artikel und der des vorigen Monats dürften Ihnen genügend Informationen für Ihre ersten Schritte mit WinRM bieten. Wir hoffen es jedenfalls. WinRM ist eine faszinierende neue Technologie, die eine wesentlich einfachere Remoteverwaltung Ihrer Computer (unter Aufrechterhaltung der Sicherheit) verheißt. Was natürlich direkt zu der Frage führt, die allen unter den Nägeln brennt: Bedeutet das, dass es einen dritten Teil der WinRM-Saga geben wird?
Leider können wir Ihnen das nicht verraten. Nicht aus Gründen der Sicherheit, sondern einfach, weil wir aufgrund des normalen Planungs- und Entscheidungsfindungsprozesses der Scripting Guys nicht wissen, ob ein weiterer Artikel zu WinRM geschrieben wird. Wie heißt es doch so schön: Bleiben Sie dran!
Der Scripting Perplexer von Dr. Scripto
Doktor Scripto hatte einen kleinen Unfall. Er ließ eines seiner Skripts herumliegen (statt es wie ein ordentlicher Skriptersteller fortzuräumen) und ist versehentlich darüber gestolpert, sodass die Skriptteile in alle Richtungen flogen. Er hat es geschafft, alle Variablen, Schlüsselwörter, Symbole usw. zu finden, und sie hübsch in alphabetischer Reihenfolge angeordnet, aber jetzt er muss sie wieder zusammensetzen, um sein Skript als Ganzes wiederherzustellen. Er wird eine Weile dafür brauchen, aber er geht davon aus, dass er bis zum Erscheinen des TechNet Magazins im nächsten Monat damit fertig wird. In der Zwischenzeit können Sie versuchen, diesen scheinbar willkürlichen Satz von Skriptteilen in ein vollständiges Skript zu verwandeln. Viel Glück!
Tipp: OK, hier ist eine kleine Hilfestellung. Durch das fertige Skript werden alle Dateien auf dem lokalen Computer gelöscht, die älter als ein angegebenes Datum sind.

Der Scripting Perplexer von Dr. Scripto
Antwort: Tollpatschiger Doktor Scripto, Dezember 2007
Ja, Dr. Scripto hat es geschafft, sein Skript wieder zusammenzusetzen. Hier ist das rekonstruierte, funktionierende Skript, durch das alle Dateien auf dem lokalen Computer gelöscht werden, die älter als ein angegebenes Datum sind:
strDate = "20060102000000.000000+000"

strComputer = "."
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")
Set colFiles = objWMIService.ExecQuery("Select * From CIM_DataFile Where CreationDate < '" & strDate & "'")
For Each objFile in colFiles
    Wscript.Echo objFile.Name
Next

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: Kennwortrichtlinien f&#252;r die Windows-Dom&#228;ne
Sicherheit auf dem Prüfstand
Kennwortrichtlinien für die Windows-Domäne
Derek Melber

Wenn Sie Administrator einer Windows-Domäne sind, kennen Sie sich mit den Einschränkungen in Bezug auf Kennwortrichtlinien für Domänenbenutzerkonten nur allzu gut aus. Mit der Veröffentlichung von Windows Server 2008 werden jedoch einige dieser Einschränkungen aufgehoben. Im Folgenden wird untersucht, wie das neue Betriebssystem ein bestimmtes Problem löst: die Unfähigkeit, mehrere Kennwortrichtlinien zu implementieren.
Wenn Sie heute eine Version der Windows®-Domäne ausführen (Windows NT®, Windows 2000 Active Directory® oder Windows Server® 2003 Active Directory), sind Sie auf eine einzige Kennwortrichtlinie pro Domäne beschränkt. In Wirklichkeit stellt nicht nur die Kennwortrichtlinie eine Beschränkung dar, sondern auch die weiteren Einstellungen, die unter die Kontorichtlinien fallen. In Abbildung 1 werden diese Richtlinien und Einstellungen dargestellt.
Figure 1 Kontorichtlinien (Close Figure 1)

Kennwortrichtlinien
Kennwortverlauf erzwingen
Maximales Kennwortalter
Minimales Kennwortalter
Minimale Kennwortlänge
Kennwort muss Komplexitätsvoraussetzungen entsprechen
Kennwörter mit umkehrbarer Verschlüsselung speichern
Kontosperrungsrichtlinien
Kontosperrdauer
Kontensperrungsschwelle
Zurücksetzungsdauer des Kontosperrungszählers
Kerberos-Richtlinie
Benutzeranmeldeeinschränkungen erzwingen
Max. Gültigkeitsdauer des Diensttickets
Max. Gültigkeitsdauer des Benutzertickets
Max. Zeitraum, in dem ein Benutzerticket erneuert werden kann
Max. Toleranz für die Synchronisation des Computertakts
Diese Richtlinieneinstellungen gelten standardmäßig für alle Domänen- und Benutzerkonten, die der Domäne zugeordnet sind. Das liegt an der Art und Weise, wie die Gruppenrichtlinie durch die Active Directory-Struktur hindurch erbt. Um zu verstehen, wie sich diese Richtlinien auf die Domänen- und lokalen Benutzerkonten auswirken, sollten Sie wissen, wo diese Richtlinien festgelegt werden und wie sich die Vererbung der Gruppenrichtlinie auf alle unterschiedlichen Benutzerkonten auswirkt. (Beachten Sie, dass die Kerberos-Richtlinieneinstellungen nur für Domänenbenutzerkonten gelten, da nur Domänenbenutzerkonten Kerberos zur Authentifizierung verwenden. Lokale Benutzerkonten verwenden stattdessen NTLMv2, NTLM oder LM zur Authentifizierung.)

Einstellen von Kontorichtlinien
Innerhalb von Active Directory werden die Kontorichtlinien für die gesamte Domäne von der Gruppenrichtlinie eingerichtet und kontrolliert. Dies erfolgt bei der anfänglichen Installation der Active Directory-Domäne über ein Standardgruppenrichtlinienobjekt (Group Policy Object, GPO), das mit dem Domänenknoten in Active Directory verknüpft ist. Dieses GPO, genannt Standarddomänenrichtlinie, enthält Standardkonfigurationen für alle drei Abschnitte der Kontorichtlinien. In Abbildung 2 ist eine umfassende Liste der anfänglichen Einstellungen für die Kennwortrichtlinienelemente auf einer Windows Server 2003-Domäne dargestellt.
Abbildung 2 Standardkennwortrichtlinien für die Windows Server 2003-Domäne
Abbildung 2 Standardkennwortrichtlinien für die Windows Server 2003-Domäne
Die Einstellungen in diesem GPO kontrollieren die Kontorichtlinien für alle Domänenbenutzerkonten sowie für jeden Domänencomputer. Es muss unbedingt beachtet werden, dass alle Domänencomputer (Desktops und Server) über eine lokale Sicherheitskontenverwaltung (Security Accounts Manager, SAM) verfügen. Die Sicherheitskontenverwaltung wird von den Einstellungen in diesem Standard-GPO kontrolliert. Selbstverständlich enthalten die lokalen Sicherheitskontenverwaltungen auch lokale Benutzerkonten für den jeweiligen Computer.
Die Einstellungen in der Standarddomänenrichtlinie betreffen alle Domänencomputer durch die Active Directory-Struktur hindurch über die normale Vererbung von GPOs. Da dieses GPO mit dem Domänenknoten verknüpft ist, sind alle Computerkonten in der Domäne davon betroffen.

Was Sie mit aktuellen Kennwortrichtlinien nicht vornehmen können
Eine Reihe von Missverständnissen über Kennwortsteuerelemente ergibt sich aus der aktuellen Implementierung von Active Directory (in Windows Server 2003) – trotz jahrelanger strenger Prüfung und mangels Beweisen, dass diese falschen Vorstellungen tatsächlich wahr sind. Klar ist, oder sollte es zumindest sein, dass die Funktionsweise der Richtlinie ihrem Entwurf entspricht.
Doch viele Administratoren glauben, dass es möglich ist, mehrere Kennwortrichtlinien für Benutzer in derselben Domäne einzurichten. Sie denken, dass ein GPO erstellt und mit einer Organisationseinheit verknüpft werden kann. Die Idee dabei ist, Benutzerkonten zur Organisationseinheit zu verschieben, damit sich das GPO auf die Objekte auswirkt. Innerhalb des GPOs werden die Kontorichtlinien geändert, um eine sicherere Kennwortrichtlinie zu erstellen, möglicherweise durch Festlegen der maximalen Kennwortlänge auf 14 Zeichen. Doch aus mehreren Gründen stellt diese Konfiguration in keinem Fall das gewünschte Ergebnis bereit. Erstens handelt es sich bei den Kennwortrichtlinieneinstellungen vielmehr um computerbasierte als benutzerbasierte Richtlinien. Mit dieser Einstellungsgrundlage werden sich die Einstellungen niemals auf ein Benutzerkonto auswirken. Zweitens besteht die einzige Möglichkeit, die Kontorichtlinieneinstellungen für ein Domänenbenutzerkonto zu ändern, innerhalb eines mit der Domäne verknüpften GPOs. Mit der Organisationseinheit verknüpfte GPOs, die so konfiguriert sind, dass sie die Kontorichtlinieneinstellungen verändern, verändern die lokale Sicherheitskontenverwaltung der Computer, die sich in der Organisationseinheit oder in den untergeordneten Organisationseinheiten der verknüpften Organisationseinheit befinden.
Ein zweites Missverständnis beruht darauf, dass die in der Stammdomäne (der Ausgangsdomäne der Active Directory-Gesamtstruktur) eingerichteten Kontorichtlinieneinstellungen bis zu den untergeordneten Domänen in der Gesamtstruktur vererbt werden. Auch dies ist nicht der Fall, und die Einstellungen können nicht in dieser Weise angewendet werden. GPOs, die mit der Domäne und den Organisationseinheiten innerhalb einer Domäne verknüpft sind, haben keine Auswirkung auf Objekte in einer anderen Domäne, selbst wenn die Domäne, mit der das GPO verknüpft ist, die Stammdomäne ist. Die einzige Methode, mit der GPO-Einstellungen Objekte in verschiedenen Domänen umfassen können, ist das Verknüpfen von GPOs mit Active Directory-Standorten.

Künftige Aussichten für Kennwörter
Wie oben beschrieben behandeln die aktuellen Versionen von Windows die Benutzerkontokennwörter auf einfache und direkte Weise. Dazu gehört ein Satz von Kennwortregeln für alle Domänenkonten sowie die Verwaltung der Kontorichtlinien durch ein Gruppenrichtlinienobjekt, das mit dem Domänenknoten in Active Directory verknüpft wird. Für Windows Server 2008 trifft all dies nicht mehr zu.
Bei Windows Server 2008 und der zugehörigen Active Directory-Infrastruktur kommt ein anderes Verfahren zum Einsatz. Im Gegensatz zu Kontorichtlinien in einem GPO, bei dem nur eine einzige Richtlinie für alle Domänenbenutzerkonten festgelegt werden konnte, befinden sich die Einstellungen jetzt in einem tieferen Bereich von Active Directory. Außerdem basieren die Kontorichtlinien nicht mehr auf Computerkonten. Jetzt können Sie einzelne Benutzer und Benutzergruppen festlegen, die ihre Kennworteinschränkungen selbst kontrollieren. Dies ist ein brandneues Konzept für Windows-Administratoren, da es bisher immer nur Kontorichtlinien für Computerkonten gab.

Kontorichtlinien innerhalb von Windows Server 2008
Innerhalb von Windows Server 2008 werden Kontorichtlinien nicht mit der Standarddomänenrichtlinie eingerichtet. Genau genommen werden GPOs zum Erstellen von Kontorichtlinien für Domänenbenutzerkonten überhaupt nicht verwendet. In Windows Server 2008 werden Sie zur Active Directory-Datenbank geleitet, um dort Änderungen vorzunehmen. Insbesondere steht das Tool ADSIEdit zur Verfügung, mit dem Sie das Active Directory-Objekt und seine zugeordneten Attribute ändern.
Der Grund für diese Änderung liegt darin, dass die Gruppenrichtlinie nicht für mehrere Kennwörter innerhalb derselben Domäne entworfen wurde. Die Implementierung der Fähigkeit in Windows Server 2008, mehrere Kennwörter pro Domäne zu haben, ist zwar elegant, doch lange nicht so benutzerfreundlich wie allgemein erwünscht. Mit der Zeit wird es jedoch einfacher werden, auf die Schnittstelle für das Konfigurieren der Einstellungen zuzugreifen. Vorläufig müssen Sie sich auf hartnäckige Active Directory-Datenbankarbeit gefasst machen, um die Änderungen im System vorzunehmen.
Sie müssen zum Ändern der Kontorichtlinieneinstellungen nicht ADSIEdit verwenden, wenn Sie eine andere Methode bevorzugen. Sie können jedes andere LDAP-Bearbeitungstool verwenden, das die Active Directory-Datenbank nutzen kann, oder sogar Skripterstellung. Beim Implementieren von Kennwortrichtlinien in Windows Server 2008 müssen Sie jetzt einen ganz anderen Ansatz wählen als bisher. Die neuen Funktionen bedeuten, dass Sie beachten müssen, welche Benutzer und Gruppen welche Kennworteinstellungen erhalten.
Sie müssen nicht nur die Kennwortlänge, sondern auch die zusätzlichen Einschränkungen bedenken, die mit den Kennwortrichtlinieneinstellungen einhergehen, darunter Mindest- und Höchstalter, Verlauf und so weiter. Andere Aspekte umfassen die Kontrolle der Richtlinieneinstellungen für die Benutzersperre und der Kerberos-Einstellungen. Es gibt eine 1:1-Beziehung zwischen den aktuellen Kontorichtlinieneinstellungen und den Einstellungen, die in der Active Directory-Datenbank in Windows Server 2008 konfiguriert sind. Dabei muss jedoch beachtet werden, dass die Namen der einzelnen Richtlinieneinstellungen, die jetzt Active Directory-Objekte und -Attribute sind, anders lauten.
Um die neuen Kennworteinstellungen zu implementieren, muss ein Kennworteinstellungsobjekt (Password Settings Object, PSO) namens „msDS-PasswordSettings“ unter dem Kennworteinstellungscontainer erstellt werden, der den LDAP-Pfad „cn=Password Settings,cn=System,dc=domainname,dc=com” aufweist. Beachten Sie, dass die funktionale Ebene der Domäne, in der Sie arbeiten, auf Windows Server 2008 festgelegt sein muss. Unter diesem neuen Objekt füllen Sie die Informationen für mehrere Attribute aus (siehe Abbildung 3).
Figure 3 Kennwortattribute in Active Directory (Close Figure 3)

Active Directory-Attributname | Attributbeschreibung
msDS-PasswordSettingsPrecedence | Bestimmt den Vorrang in Situationen, in denen ein Benutzer Mitglied mehrerer Gruppen mit verschiedenen Kennwortrichtlinien ist.
msDS-PasswordReversibleEncryptionEnabled | Schaltet um, falls die umkehrbare Verschlüsselung aktiviert ist.
msDS-PasswordHistoryLength | Bestimmt, wie viele Zwischenkennwörter eindeutig sein müssen, bevor eins wiederverwendet werden kann.
msDS-PasswordComplexityEnabled | Richtet die Anzahl und die Art der in einem Kennwort erforderlichen Zeichen ein.
msDS-MinimumPasswordLength | Richtet die Mindestlänge eines Kennworts ein.
msDS-MinimumPasswordAge | Bestimmt, wie lange ein Benutzer ein Kennwort beibehalten muss, bevor es geändert werden kann.
msDS-MaximumPasswordAge | Bestimmt, wie lange ein Benutzer ein Kennwort verwenden kann, bevor es geändert werden muss.
msDS-LockoutThreshold | Bestimmt, wie viele fehlgeschlagene Kennwortversuche zugelassen werden, bevor ein Benutzerkonto gesperrt wird.
msDS-LockoutObservationWindow | Bestimmt den Zeitraum, nach dem der Kontosperrungszähler zurückgesetzt wird.
msDS-LockoutDuration | Bestimmt die Kontosperrdauer nach zu vielen fehlgeschlagenen Kennwortänderungsversuchen.
Wie oben beschrieben werden alle Gruppenrichtlinieneinstellungen, die sich auf die Kontorichtlinieneinstellungen beziehen, als Attribute dupliziert. Beachten Sie, dass es auch eine Vorrangeinstellung gibt. Sie ist unerlässlich beim Implementieren mehrerer Kennwörter in derselben Domäne, da mit Sicherheit Konflikte auftreten werden und für ihre Behandlung eine Methode vorhanden sein muss.

Kontorichtlinieneinstellungen zuweisen
Sie müssen für jedes Objekt, das Sie erstellen, alle Attribute ausfüllen, um die Kontorichtlinien für alle Benutzer zu gestalten. Es gibt ein neues Attribut namens „msDS-PSOAppliesTo“, das festlegt, welche Objekte den Satz der Richtlinieneinstellungen erhalten. Dies ist das goldene Attribut, mit dem Sie bestimmte Einstellungen an bestimmte Benutzer leiten. Bei der Liste unter diesem Attribut kann es sich entweder um Benutzer oder um Gruppen handeln, doch wie bei allem, was mit dem Einrichten einer Zugriffssteuerungsliste zu tun hat, ist es am besten, Gruppen statt Benutzer zu verwenden. Gruppen sind stabiler, transparenter und in der Regel leichter zu behandeln.

Grund zur Freude
Nach jahrelangem Warten darauf, mehrere Kennwörter innerhalb derselben Active Directory-Domäne verwenden zu können, ist diese Möglichkeit jetzt endlich vorhanden. Wenn es um Kennwörter geht, gilt nicht mehr die gleiche Sicherheitsstufe für jeden Benutzer in der gesamten Domäne. Jetzt sind zum Beispiel Standardbenutzer mit einem 8-Zeichen-Kennwort und IT-Experten (die möglicherweise Administratorrechte haben) mit einem komplexeren 14-Zeichen-Kennwort möglich.
Es ist etwas gewöhnungsbedürftig, die Active Directory-Datenbank aufzurufen, um Kontorichtlinieneinstellungen einzurichten oder zu ändern. Erfreulicherweise ahmen die neuen Einstellungen jedoch das nach, womit Sie bereits vertraut sind. Machen Sie sich mit diesen neuen Einstellungen unbedingt vertraut, sobald Ihnen Windows Server 2008 vorliegt, da diese Einstellungen sicherlich zum ersten Satz an Konfigurationen gehören, die Sie vornehmen.

Derek Melber, MCSE, CISM, MVP, ist unabhängiger Berater und Trainer. Zu seinem Tätigkeitsbereich gehören Schulungen zur sowie die Verbreitung der Microsoft-Technologie, wobei er sich auf Active Directory, die Gruppenrichtlinie, Sicherheit und die Desktopverwaltung konzentriert. Derek Melber hat mehrere IT-Bücher verfasst, einschließlich „Microsoft Windows Group Policy Guide“ (Microsoft Press, 2005). Er ist unter derekm@braincore.net zu erreichen.


 Die Desktopdateien: Bereitstellen von Windows in einer virtuellen Welt
Die Desktopdateien
Bereitstellen von Windows in einer virtuellen Welt
Wes Miller

Die virtuelle Computertechnologie ist allgegenwärtig. Wenn Sie sie noch nicht nutzen, wird es jetzt Zeit. Die Virtualisierung verringert die Hardwareabhängigkeit, indem im Wesentlichen eine eigene Hardwareabstraktionsschicht erstellt wird und es Ihnen ermöglicht wird, ein oder mehrere Gastsysteme, z. B. Windows Server- oder Windows-Clientbetriebssysteme, zwischen Hostsystemen zu verschieben.
Natürlich unterscheidet sich die Virtualisierung insofern von der Emulation, als dass sie nicht den Prozessor des Gasts imitiert. Sie stellt einfach die Ressourcen des Hostsystems so dar, dass Gastsysteme auf sie zugreifen können. Daher sind Hostsysteme für Gäste generisch. Sie können im Allgemeinen einen virtuellen Gast vom System eines OEMs auf das System eines anderen OEMs verschieben, wobei die Hardware des Hosts in der Regel keine Rolle spielt. Es sind jedoch einige Punkte zu beachten. Wenn Sie beispielsweise einen Gast von Hardware mit einem Prozessor eines CPU-Herstellers wie AMD auf Hardware mit einem Prozessor eines anderen Herstellers wie Intel verschieben, könnten je nach der von Ihnen verwendeten Virtualisierungstechnologie Probleme auftreten. Dies beruht darauf, dass durch die virtuelle Computertechnologie lediglich Informationen zwischen Host und Gast übertragen werden und keine spezifische CPU für den Gast emuliert wird (wie dies beispielsweise der Fall ist, wenn Microsoft® Virtual PC auf einem PowerPC-basierten Macintosh-Legacycomputer ausgeführt wird).
Bei der Virtualisierung werden jedoch wichtige Hardwarekomponenten für den Gast emuliert. Dies beschränkt sich zumeist auf Netzwerk-, Video- (in der Regel ein stark eingeschränktes Gerät ohne hoch entwickelte emulierte GPU) und Massenspeichergeräte. Die Funktionsweise bei dieser Art von Verbund besteht darin, dass eine oder mehrere durch Software emulierte Geräte für den Gast dargestellt werden. Wenn Sie die Artikel dieser Rubrik bereits seit einer Weile lesen, werden Sie bemerkt haben, dass es sich dabei um die gleiche Liste von Geräten handelt, auf die auch Windows® PE abzielt. Bei der Virtualisierung sind dies die gleichen Arten von Geräten, die erforderlich sind, damit Windows wirklich funktioniert. Darüber hinaus müssen alle Virtualisierungstechnologien ein BIOS emulieren. Obwohl auch Extensible Firmware Interface (EFI) emuliert werden könnte, ist dies aufgrund der begrenzten Auswahl von EFI-basierten Betriebssystemen derzeit nur von eingeschränktem Nutzen. Diese Emulation ermöglicht das Starten von virtuellen Gästen. Das BIOS und jedes der Geräte emulieren ein tatsächliches Gerät in der Software und stellen dieses Gerät für Gäste dar. Dies bedeutet, dass die gleichen Treiber (nicht immer durch Windows bereitgestellt) erforderlich sind, die das tatsächliche Gerät erfordern würde. Dies ist ein wichtiges Konzept, das zu beachten ist.
Obwohl einige Virtualisierungstechnologien auch Schnittstellen zu USB- (oder USB 2.0-) Geräten ermöglichen, soll an dieser Stelle nicht auf die Einzelheiten dieser Technologien eingegangen werden. Abgesehen von den USB-Geräten, die entweder Treiber (Drucker, drahtlose USB-Netzwerkkarten usw.) oder bestimmte DirectX®-Unterstützung (bei den meisten Virtualisierungstechnologien in der Regel nicht vorhanden) erfordern, sollte kein großer Aufwand erforderlich sein, damit sie funktionieren. Beachten Sie, dass die Unterstützung für USB-Geräte oder andere nicht emulierte Geräte natürlich von der verwendeten Virtualisierungstechnologie abhängt. Sie sollten auf jeden Fall die Einschränkungen oder Nachteile des von Ihnen verwendeten Virtualisierungsprodukts kennen, bevor Sie versuchen, neue Geräte in Verbindung mit dieser Technologie zu verwenden.
Derzeit gibt es zwei Hauptanbieter von Virtualisierungstechnologie für Windows: Microsoft und VMware (vmware.com). Darüber hinaus gibt es weitere vielversprechende Anbieter wie Parallels (parallels.com).
Da Sie jetzt eine Vorstellung davon haben, worum es bei der Virtualisierung geht, wird im Rest dieses Artikels erläutert, wie sie eingerichtet wird, wie die häufigsten Fehler vermieden werden und wie Sie sie auf einer Reihe von Computern in Ihrer Umgebung bereitstellen können.

Virtuelle Bereitstellung
Die Bereitstellung virtueller Systeme muss sich nicht von der Bereitstellung physischer Systeme unterscheiden. Wie Sie jedoch sehen werden, gibt es einige gute Gründe, sie anders zu gestalten.
Unter Windows NT® mussten Sie anfangs die Bereitstellung über das Setup vornehmen. Sie konnten dafür ein Skript erstellen, mussten jedoch den gesamten Prozess durchlaufen. Nach Abschluss des Setups wurde das Kopieren dieses Abbilds auf mehrere Systeme – obwohl ein recht praktisches Konzept – einfach nicht unterstützt.
Schließlich entschied Microsoft jedoch, dass es sinnvoll war, mittels Datenträger duplizierte oder „geklonte“ Windows NT-Systeme zu unterstützen. Daher steht heute jede Methode, die bei der Bereitstellung physischer Systeme verfügbar ist, auch für die Bereitstellung virtueller Systeme zur Verfügung. Sie können folgende Methoden verwenden: Winnt32 (oder setup.exe im Fall von Windows Vista® und Windows Server® 2008), Windows PE (1.x oder 2.x, abhängig vom bereitgestellten Client, wie in früheren Artikeln erläutert), die Remoteinstallationsdienste (Remote Installation Services, RIS), die Windows-Bereitstellungsdienste (Windows Deployment Services, WDS) oder Sysprep (das mit Windows NT 4.0 eingeführte Systemvorbereitungsprogramm für die Bereitstellung) sowie Ihre bevorzugte Technologie zur Datenträgerduplizierung (beispielsweise ImageX).
Natürlich ist dies nur bei der erstmaligen Bereitstellung eines bestimmten Betriebssystems erforderlich. Danach können Sie es einfach kopieren. Mit datenträgerbasierten Duplizierungsmethoden wie den gerade genannten ist jedoch ein Problem verbunden.

Verwenden von Sysprep
Die ursprüngliche Entscheidung von Microsoft, die datenträgerbasierte Duplizierung nicht zu unterstützen, beruhte hauptsächlich auf der Windows NT-Sicherheitskennung (Security Identifier, SID). Glücklicherweise bietet Sysprep eine Lösung. Sehen Sie sich jedoch zunächst das Problem an, das durch Sysprep gelöst wird. Wie unter support.microsoft.com/kb/314828 beschrieben, besteht die SID aus einer SID-Strukturrevisionsnummer (in der Regel eine GUID (Globally Unique Identifier)), die einen einzelnen Windows-basierten Computer identifiziert. Diese ID wird dann als Stammteil des Bezeichners für alle lokalen Konten verwendet. Lokale Konten verfügen über einen eigenen eindeutigen Bezeichner, der als relative ID (Relative Identifier, RID) bezeichnet wird. Die RID besteht aus einer Konto-ID, die mit dem Ende der SID verkettet wird. Daher wird die Kombination der beiden IDs zum Bezeichner für lokale Konten.
Betrachten wir nun anhand der Administrator-SID S-1-5-21-191058668-193157475-1542849698-500, warum dies ein Problem darstellt. Hier ist S-1-5 der Deskriptor, der definiert, dass es sich hierbei um eine SID handelt (das S ist in der Textdarstellung einer SID immer vorhanden). 1 stellt die Revisionsnummer der Windows NT-SID und 5 den Autoritätsbezeichnerwert (hier Windows-Sicherheit) dar. Der Rest ist die eigentliche SID, einschließlich der Zahl 500, die diese SID als bekannte SID kennzeichnet – das Windows-Administratorkonto. Das Administratorkonto, das standardmäßig bei allen Windows-Installationen erstellt wird (und nicht gelöscht werden kann), besitzt eine SID, die mit der Zahl 500 endet. Bei lokalen Benutzerkonten, die Windows nach der Installation hinzugefügt werden, wird oberhalb von 1000 mit der Iteration begonnen.
Mit dem über Windows Sysinternals erhältlichen Tool PSGetSID (im Artikel zu den PSTools unter technetmagazine.com/issues/2007/03/DesktopFiles erwähnt) können Sie eine SID für einen bestimmten Benutzer auf einem System oder die SID des Systems abrufen. Die Ausgabe von PSGetSID für die SID des virtuellen Systems und die SID für das Benutzerkonto 1003 dieses Beispiels ist in Abbildung 1 dargestellt.
Abbildung 1 Ausgabe von PSGetSID für die SID eines virtuellen Systems und die SID des Benutzerkontos 1003
Abbildung 1 Ausgabe von PSGetSID für die SID eines virtuellen Systems und die SID des Benutzerkontos 1003
Da die RIDs lokaler Konten auf dieser SID basieren, sollte das Problem, das auftritt, wenn Sie ein System mittels Datenträgern duplizieren oder einfach das Abbild eines virtuellen Computers kopieren, relativ offensichtlich sein. Da die SID nicht geändert wird (die primäre, aber nicht die einzige Aufgabe von Sysprep), erhalten Sie eine Kopie der Schlüsselkomponente, die ein Windows-System einzigartig macht. Wenn System A und System B die gleiche Administrator-SID aufweisen, würden sich Benutzer auf jedem der Systeme legitim als derselbe Benutzer identifizieren. Dasselbe gilt für alle lokalen Konten von System B bei der Authentifizierung bei System A und umgekehrt. Noch schlimmer ist, dass diese Systeme bei der Darstellung für Active Directory® dieselbe SID aufweisen. Wenn Sie es also zulassen, dass sich System A bei einer Domänenressource authentifiziert, dies System B jedoch nicht gestatten, tritt ein Konflikt auf. Wenn Sie für B die Ablehnung festlegen, wird A ebenfalls abgelehnt.
Daher ist es äußerst wichtig, dass Sie SIDs auf Systemen mit Sysprep neu generieren – insbesondere in Szenarios mit virtuellen Systemen, da Systemabbilder allzu einfach übertragen werden können. Sie sollten kein Drittanbietertool zum Ändern von SIDs verwenden, sondern ausschließlich Sysprep. Sysprep ist ein von Microsoft für die Vorbereitung von Systemen auf die Duplizierung (sogar von virtuellen Systemen) entwickeltes, getestetes und unterstütztes Tool. In Abbildung 2 sehen Sie ein Beispiel dafür, wie Sysprep aussieht, bevor die SID auf einem System geändert wird. Stellen Sie sicher, dass das Kontrollkästchen „Don't regenerate security identifiers“ (Sicherheitskennungen nicht erneut generieren) stets deaktiviert ist, wenn Sie als nächsten Schritt das System auf die Duplizierung vorbereiten.
Abbildung 2 "Don't regenerate security identifiers (Sicherheitskennungen nicht erneut generieren)" sollte bei der Vorbereitung auf die Duplizierung deaktiviert sein
Abbildung 2 "Don't regenerate security identifiers (Sicherheitskennungen nicht erneut generieren)" sollte bei der Vorbereitung auf die Duplizierung deaktiviert sein
Neben der Aktualisierung der SID auf eine neue ID werden durch Sysprep auch alle privaten Datenspeicher geändert, die dem Tool bekannt sind, sodass sie die SID und den Computernamen widerspiegeln, oder um ihre Verschlüsselung so zu ändern, dass sie mit der neuen SID funktioniert. Einige Beispiele hierfür sind der Datenspeicher „Geplante Aufgaben“ und die zugehörigen Werte in der IIS-Metabasis (wenn IIS installiert ist).
Sysprep löscht zudem zwangsweise jede Netzwerkkarte im System und entfernt gleichzeitig die Netzwerkkonfigurationsdaten für die Netzwerkkarte. Da die Netzwerkkonfiguration von der Netzwerkkarte in der Registrierung abhängt und die Beziehung dieser Netzwerkkarte auf der Hardware-ID der Netzwerkkarte basiert (die außerhalb von Verschiebungsvorgängen zwischen virtuellen Systemen leicht zerstört werden kann), werden diese üblicherweise nicht beachteten Daten von Sysprep bereinigt.
Sysprep bereinigt zudem alle Informationen zur Active Directory-Mitgliedschaft in einem System. Daher muss das Programm im Rahmen seiner Arbeit ein System zwangsweise aus der Domäne entfernen. Dadurch wird sichergestellt, dass Systeme, die gerade neue SIDs erhalten haben, der Domäne auf sichere Weise beitreten können. Einige Dienstprogramme, die SIDs ändern, ermöglichen es Ihnen, die SID eines Computers zu ändern, ohne ihn aus der Domäne zu entfernen. Dies ist jedoch weder zuverlässig, noch sicher. Wenn Sie Sysprep unbedingt auf einem Computer ausführen müssen, der ein Domänenmitglied ist, entfernen Sie ihn vor der Ausführung von Sysprep aus der Domäne, oder führen Sie Sysprep aus, und lassen Sie das Programm diese Aufgabe durchführen.
In diesem Zusammenhang gilt auch: Wenn Sie einen Ihrer Domänencontroller (DCs) virtualisieren, müssen Sie Systeme duplizieren, bei denen es sich um rein eigenständige Server handelt, die nicht zu DCs heraufgestuft wurden und nicht mit der Domäne verbunden sind. Mit Ausnahme von Windows Server 2003 Small Business Server Edition können Sie einen DC nicht mittels Datenträgern auf sichere Weise duplizieren. Zur sicheren Erstellung neuer DCs sollten Sie ein Datenträgerabbild eines Servers erstellen, der für den Beitritt zur Domäne und die Heraufstufung zu einem DC bereit ist. Außer im sehr speziellen Fall von SBS mit einer einzelnen Gesamtstruktur/einem einzelnen Server ist Sysprep nicht bekannt, wie SIDs auf einem DC auf sichere Weise geändert werden.
Neben der Änderung der SID und dem Entfernen des Computers aus der Domäne ändert Sysprep abschließend auch den Namen des Computers.
Möglicherweise erscheint es Ihnen übertrieben, dass Sie alle vorstehenden Aufgaben beim Erstellen von Abbildern oder selbst beim einfachen Kopieren virtueller Systeme durchführen müssen. Dies ist jedoch äußerst wichtig, insbesondere wenn Sie diese Systeme in einem Netzwerk mit anderen physischen oder virtuellen Systemen, in einer Domäne oder zusammen mit einer anderen Kopie von ihnen im Netzwerk verwenden.
Wenn Sie Sysprep beim Duplizieren virtueller Systeme nicht verwenden, werden fast zwangsläufig verschiedene offensichtliche (Active Directory- oder andere Netzwerkkonflikte) und auch einige unerwartete Probleme auftreten. Ihre virtuellen Abbilder sind beispielsweise sehr anfällig für Hackerangriffe, da durch „Knacken“ eines Abbilds der Zugriff auf die anderen Abbilder möglich wird.

Treiber und Hardwareabstraktionsschichten
Es wurde bereits erwähnt, dass die in einem virtuellen Abbild enthaltenen virtuellen Geräte möglicherweise nicht über die standardmäßig mitgelieferten Treiber für Windows verfügen. Stellen Sie bei der Bereitstellung (oder bei der Bereitstellung von Datenträgerabbildern mit Sysprep) sicher, dass Sie über Treiber für Ihre Geräte verfügen, da der gefürchtete Treiberfehler „0x0000007B“ beim Verschieben eines virtuellen Abbilds von einem Speicherbustreiber zum anderen genauso leicht auftreten kann wie bei der Arbeit mit physischer Hardware. Dasselbe gilt für Netzwerkkarten. Obwohl bei den meisten Virtualisierungsprodukten versucht wurde, ein weitgehend universelles virtuelles Gerät bereitzustellen, benötigen Sie möglicherweise dennoch einen zusätzlichen Treiber dafür.
Sie dürfen auch nicht das Problem der Hardwareabstraktionsschicht (HAL) ignorieren. Im Idealfall sollten Sie Ihre virtuellen Computer so erstellen, dass sie ACPI-Multiprozessoren (Advanced Configuration and Power Interface) unterstützen (siehe intel.com/technology/iapc/acpi), sofern dies von Ihrer Virtualisierungstechnologie unterstützt wird. Die Konvertierung zwischen HALs wird im Allgemeinen nicht unterstützt (weitere Informationen finden Sie unter support.microsoft.com/kb/309283). Einige Virtualisierungstechnologien – oder, was noch wichtiger ist, viele Migrationstechnologien – verheißen, dass eine Windows-Installation, die ACPI nicht unterstützt, auf sichere Weise zu einer ACPI-Installation verschoben werden kann und umgekehrt. Dies ist nicht wahr, und die resultierende Windows-Installation wird darüber hinaus von Microsoft nicht unterstützt, wenn Probleme auftreten. Die gleichen Einschränkungen, die auf der gerade erwähnten Supportwebseite erläutert werden, gelten auch für virtualisierte Systeme. In Abbildung 3 finden Sie ein Beispiel dafür, wie die HAL im Geräte-Manager auf einem meiner virtuellen Computer angezeigt wird – in diesem Fall erfolgt die Ausführung mit der ACPI-Uniprozessor-HAL. Diese ist mit ihrem Multiprozessor-Gegenstück austauschbar und darf nicht mit einem Einzelprozessor verwechselt werden.
Abbildung 3 HAL im Geräte-Manager auf einem virtuellen Computer
Abbildung 3 HAL im Geräte-Manager auf einem virtuellen Computer

Verschiedene Änderungen
Ändern Sie, was Sie können, und übernehmen Sie alle anderen Aspekte
Wenn Sie die Migration von physischen zu virtuellen Systemen oder umgekehrt in Erwägung ziehen, müssen Sie die Aspekte berücksichtigen, die Sie ändern bzw. nicht ändern können. Die folgenden Aspekte einer Windows-Installation können geändert werden:
  • Die HAL (jedoch nur von einer Uniprozessor- in eine Multiprozessor-HAL oder umgekehrt, sofern sie auf der gleichen Energiekonfiguration basieren).
  • Massenspeichercontroller (dies ist nicht einfach, aber bei den meisten Lösungen für die Migration von physischen zu virtuellen Systemen wird bereits von selbst ein entsprechender Versuch unternommen). Beachten Sie, dass die meisten Anbieter eine IDE- und eine SCSI-Speicherlösung bereitstellen. Treffen Sie bei der Bereitstellung die richtige Wahl, da es nicht gerade einfach ist, von einer Lösung auf die andere umzustellen. In der Regel führt die Auswahl von SCSI zu einem zuverlässigeren Gerät (dies ist bei den meisten Anbieterimplementierungen der SCSI-Geräteemulation der Fall).
  • Netzwerkcontroller (obwohl dieser bei einem Szenario zur Migration von virtuellen zu virtuellen Systemen im Rahmen der Technologien eines bestimmten Anbieters im Allgemeinen gleich ist).
Die folgenden Aspekte einer Windows-Installation können nicht geändert werden:
  • Die HAL (außer im oben genannten Fall, in dem dieselbe Energiekonfiguration verwendet wird). Denken Sie nicht, dass eine Migrationslösung, bei der dies der Fall ist, zu einer stabilen oder zuverlässigen Windows-Installation führt. (Noch wichtiger ist, dass sie von Microsoft nicht unterstützt wird.)

Neben der SID und dem Computernamen müssen Sie auch bestimmte Werte ändern, die für die von Ihnen verwendete virtuelle Computertechnologie spezifisch sein können. Sie müssen insbesondere die MAC-Adresse (die eindeutige ID für Netzwerkgeräte) ändern. Darüber hinaus weisen viele virtuelle Anwendungen ebenfalls einen eigenen eindeutigen Bezeichner auf. Bei den meisten Anwendungen werden diese in Konfigurationsdateien des Computers gespeichert. Daher sollten Sie wissen, wie diese Einträge geändert werden (und ihre Gültigkeit aufrechterhalten wird). Beachten Sie, dass viele Virtualisierungsprodukte, die PXE (Pre-Boot eXecution Environment) unterstützen, die SMBIOS-UUID auf der Basis ihrer eigenen eindeutigen ID erzeugen – wodurch die Notwendigkeit deutlich wird, diese zu ändern (oder die Änderung von der Virtualisierungssoftware vornehmen zu lassen, sofern dies unterstützt wird), wenn Sie sie mit einer Domäne verbinden. Andernfalls kann es unmöglich werden, WDS- oder RIS-Clientsysteme (bei GUID-Konflikten) zu verwalten. Bei den meisten Virtualisierungslösungen, mit denen ich gearbeitet habe, können im Fall doppelter MAC-Adressen schwerwiegende Netzwerkprobleme auftreten. Wenn Sie nicht einfach einen virtuellen Computer verschieben, ist es sehr wichtig, dass die MAC-Adresse geändert wird, wenn dies nicht von der Virtualisierungssoftware übernommen wird.
Andere Komponenten, an die Sie denken müssen, wenn ein virtuelles System auf die Bereitstellung vorbereitet wird, sind verknüpfte Datenträger oder Snapshots. Abhängig von Ihrer Virtualisierungslösung können diese auch als „differenzielle Datenträger“ bezeichnet werden oder einen anderen Namen tragen. Wenn Sie jedoch Sysprep zur Vorbereitung eines Systems ausführen und über Snapshots (oder einen anderen wiederherstellbaren Zustand) verfügen, die zum virtuellen System gehören, müssen diese zerstört werden, damit das Abbild bei der Duplizierung sicher, zuverlässig und geschützt bleibt. Im Fall eines Snapshots oder eines anderen Technologieansatzes zum „Rückgängigmachen von Datenträgeränderungen“ könnte das Wiederherstellen eines Snapshots den Rückschritt zu einem Zustand bedeuten, bei dem mehrere Systeme, für die der ursprüngliche virtuelle Computer als Quelle diente, jetzt miteinander in Konflikt stehen (oder sogar mit dem ursprünglichen Quellsystem, wenn es wiederhergestellt wird). Daher sollte für alle Snapshots oder differenziellen Datenträgerbeziehungen bereits Sysprep ausgeführt worden sein.

Optimierung
Die meisten Virtualisierungstechnologien umfassen Ergänzungen oder Tools für virtuelle Computer, die dabei helfen, die Leistung und die Benutzerfreundlichkeit bei der Interaktion mit dem Gast vom Host aus zu verbessern. Hierzu gehören in der Regel Arbeiten, durch die neben anderen Leistungsverbesserungen die Maus- und Tastatureingabe optimiert wird, sowie in vielen Fällen verbessertes Kopieren und Einfügen (oder andere Interaktionen zwischen Host und Gast). Installieren Sie vor der Bereitstellung die neueste Version dieser Tools auf Ihren virtuellen Systemen.
Sie müssen zudem sicherstellen, dass der Clientarbeitsspeicher nicht nur für das Gastbetriebssystem, sondern auch im Kontext mit den Hosts, auf denen es bereitgestellt wird, optimal konfiguriert ist. Vermeiden Sie den Fehler, dass ein Windows XP-Abbild, das auf die Verwendung von 1 GB RAM festgelegt ist, auf Hostsystemen bereitgestellt wird, die gar nicht über einen so großen Arbeitsspeicher verfügen.
Berücksichtigen Sie auch die Einschränkungen, denen die meisten virtuellen Technologien derzeit noch unterliegen. Daher ist es für Ihre Benutzer wichtig, wie sie mit an das virtuelle System angeschlossenen Peripheriegeräten interagieren können, sowie welche Anwendungen unter dem Gastbetriebssystem (nicht) funktionieren (die meisten Anwendungen unterstützen beispielsweise DirectX 9 oder 10 nicht, oder sie unterstützen ältere Versionen nur in begrenztem Umfang). Die Benutzer wissen möglicherweise nicht, was dies bedeutet oder wie es erkannt wird (in einigen Anwendungen werden derartige Fehler nicht wirksam behandelt).

Hostprobleme
Im Allgemeinen müssen Sie sich nicht viele Gedanken über den Host-PC machen, auf dem die Virtualisierungstechnologie ausgeführt wird, unabhängig davon, ob ein vollständiges Betriebssystem oder ein Typ-1-Hypervisor, der direkt auf der Hardware läuft, ausgeführt wird. Die meisten Virtualisierungstechnologien sind darauf ausgelegt sicherzustellen, dass das Gastbetriebssystem keine (oder nur wenige) Informationen über den Host benötigt. Sie müssen jedoch wissen, welche Hosts verwendet werden, falls bei einem Gast, der von einem Host auf einen anderen verschoben wird, Probleme auftreten. Informieren Sie sich außerdem über die Einschränkungen des Produkts Ihres Virtualisierungsanbieters auf bestimmten Plattformen. Sie können zwar möglicherweise zwischen verschiedenen Plattformen wechseln, verlieren oder gewinnen dabei aber eventuell bestimmte Features des Typ-2-Hypervisors (der Virtualisierungsanwendung) des Hostbetriebssystems.

Andere Bereitstellungsmethoden
Verwandte Sysprep-Links
In den folgenden Dokumenten finden Sie viele hilfreiche Informationen zu Sysprep:
  • Entwerfen von Abbildinstallationen mit Sysprep
  • Verwenden von Sysprep zum Automatisieren der erfolgreichen Bereitstellung von Windows XP
  • Verwenden des Systemvorbereitungsprogramms (Sysprep.exe) zur Durchführung einer Datenträgerduplizierung
  • Verwenden des Systemvorbereitungsprogramms auf nicht identischen Computern

Die Verwendung von Sysprep oder die Datenträgerduplizierung (bzw. das einfache Ausführen von Sysprep und das Kopieren des virtuellen Computers) sind offensichtliche Optionen für die Bereitstellung virtueller Systeme, es gibt jedoch noch weitere Möglichkeiten. Tatsächlich kann unabhängig davon, ob Sie die Abbilderstellung oder das Setup verwenden, die Verwendung von Windows PE in Verbindung mit der Virtualisierung einfacher sein als mit physischen Computern, da Sie nicht mit einer physischen CD, sondern mit ISO-Dateien arbeiten. Beachten Sie, dass einige Virtualisierungstechnologien in Verbindung mit DVD-Medien nicht optimal funktionieren. Fragen Sie Ihren Virtualisierungsanbieter daher unbedingt, ob diese unterstützt werden. Sie können winnt32 oder setup.exe (im Fall von Windows Vista oder Windows Server 2008) verwenden, es gibt jedoch keine besonderen Vorteile. Wenn Sie andere Microsoft-Bereitstellungstechnologien wie beispielsweise die automatischen Bereitstellungsdienste verwenden, unterstützt Ihre Virtualisierungstechnologie PXE, sodass eine netzwerkbasierte Bereitstellung ausgelöst wird, genau als ob RIS oder WDS verwendet würde.

Migration
Vergessen Sie neben der tatsächlichen Migration eines gesamten PCs nicht das Migrationsprogramm für den Benutzerstatus (User State Migration Tool, USMT). USMT ermöglicht es Ihnen, die Einstellungen eines Benutzers von einem physischen Client problemlos auf ein neues virtuelles System zu verschieben. Wenn Ihre Benutzer also ihre alten Daten und Einstellungen zu einem neuen virtuellen Computer migrieren möchten, könnten Sie beispielsweise die Dateien und Einstellungen auf einfache Weise von Windows XP abrufen, sie in einer UNC speichern und sie dann auf einen neuen virtuellen Computer übertragen.

Wes Miller lebt in Austin, Texas. Früher 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: Die fungible Zukunft
Berichte aus der Praxis
Die fungible Zukunft
Romi Mahajan

Der Philosoph und Wirtschaftswissenschaftler Karl Marx schrieb in einer seiner Abhandlungen „alles, was fest ist, löst sich in Luft auf“ und kennzeichnete damit die sich ändernden Beziehungen zwischen den gesellschaftlichen Klassen, die durch die wachsende Industrialisierung und den Kapitalismus im Europa des 19. Jahrhunderts verursacht wurden. Diese tief greifende Einsicht, dass Trennungen und Klassen nie ganz starr sind, spiegelt sich in zahlreichen Situationen und Zusammenhängen wider, nicht zuletzt in der Welt der Technologie, einer Welt, in der die einzige Konstante in der Veränderung liegt.
In dieser sich ständig ändernden Branche gibt es kein besseres Beispiel für rapide Veränderungen (und die damit verbundenen Herausforderungen) als der Aufstieg der verbraucherorientierten Technologie. IT wurde verkommerzialisiert und verbraucherorientiert, und die stärksten Anzeichen einer Änderung liegen im Privatbereich, mit großen Auswirkungen sowohl auf das Geschäfts- als auch das Privatleben. Dieses Phänomen nimmt mehrere Gestalten an:
  1. Die Welt von Web 2.0 dreht sich um das Schreiben und Lesen im Internet. Das Veröffentlichen im Internet kennzeichnet in erster Linie die Rolle des Autors als Verbraucher.
  2. Verbraucheranwendungen und -technologien stellen Unternehmen in gutem Licht dar („Heiligenschein-Effekt“).
  3. Der Großteil des Internets wird aufgrund der Verbraucherorientierung von IT geplant und getestet.
  4. IT-Einrichtungen wie Helpdesks müssen aufgrund der sich verwischenden Grenzen zwischen der Nutzung von Technologien im Heim und im Unternehmensbereich anders planen, den Umgang damit lernen und Konsequenzen daraus ziehen.
  5. Menschen treffen Entscheidungen, und diese Menschen sind sowohl Verbraucher als auch Fachleute.
  6. Die „bevorzugte“ Technologie eines Benutzers ist fast immer ein Verbraucherprodukt, kein Unternehmensprodukt.
Die Implikationen sind tief gehend, und Kategorien sind austauschbar, wie in nur einigen wenigen Beispielen deutlich wird. Einer meiner Freunde arbeitet in einem technologieorientierten Unternehmen und erzählte mir, dass ganze 8 Prozent aller Helpdeskanrufe in seinem Unternehmen von iTunes-Aktualisierungen herrühren. Das Whitepaper von Cisco „The Exabyte Era“ beginnt mit zwei Punkten: Das Internet bricht nicht unter dem Gewicht von Streamingvideo zusammen, und YouTube ist erst der Anfang. Apple Corporation verfügte im März 2007 über fast 10 Prozent des Einzelhandelsmarktanteils für Laptops. Gemäß einem Bericht der amerikanischen Marktforschungsgruppe NDP zeigt sich hier der „Heiligenschein-Effekt“ von iPod in Aktion. Microsoft investiert stark in die Bereiche Spiele, Musik, digitale Fotografie und Videohosting. Manche Unternehmen halten heute bereits Besprechungen in Second Life ab.
Technologiemarken erhielten größere Bedeutung und wurden verallgemeinert. Somit erlangen sie einen Anflug von Dauerhaftigkeit. Benutzer „googeln“ nach Begriffen, alle sprechen von iPods, man stellt sich über „myspace“ dar und spielt „Xbox®“. Es wurde eine emotionale Verbindung zwischen Menschen und ihren Technologien geschaffen, und diese Verbindung überträgt sich vom Büro nach Hause zurück zum Büro und weiter auf das Ansehen der Unternehmen, die diese Geräte, Anwendungen, Websites und Communitys schaffen. Die von uns geschaffene Sichtweise – gut, schlecht oder neutral – gilt sowohl im Privat- als auch im Berufsleben.
Was für einen Einzelnen relevant ist, ist daher eine komplizierte Angelegenheit. Eine grundlegende Kulturverschiebung ist erforderlich, damit Unternehmen sich den Herausforderungen stellen können, ihre Werbebotschaft anzupassen, sich in den Kunden hineinzuversetzen und seinen Anforderungen nachzukommen. Früher, vor der starken Spezialisierung auf Rollen, waren generische Werbebotschaften die Grundlage des Marketings. Seit neuester Zeit wird jedoch eher auf „zielgerichtetes“ Messaging gesetzt, das eine äußerst präzise Abstimmung auf Kategorien wie Berufsbezeichnung, Zielgruppensegment, Unternehmensgröße und bestimmte Technologien ermöglicht. Was dabei jedoch verloren ging, ist die Tatsache, dass tatsächlich alles, was fest ist, sich in Luft auflöst. Das Ansprechen von Menschen in ihrem Privat- und Berufsleben ist die einzige Möglichkeit, eine Verbindung herzustellen und dem Trend voraus zu sein.
Fungibel zu sein bedeutet austauschbar zu sein und keine scharfen Grenzen zwischen Kategorien aufzuweisen. Anders gesagt können zwischen der Sichtweise von Verbraucher- und Unternehmenstechnologien nicht länger Grenzen gezogen werden. IT ist inzwischen verbraucherorientiert, und die Zukunft somit tatsächlich fungibel.

Romi Mahajan ist Marketingdirektor für das Technical Audience und Platform Marketing Team bei Microsoft. Von Romi Mahajan sind bereits in vielen Bereichen zahlreiche Veröffentlichungen erschienen, darunter Politik, Umwelt, Technologie und Soziologie.


 Windows Confidential: Ein Joystick muss keine Mikrowelle sein
Windows Confidential
Ein Joystick muss keine Mikrowelle sein
Raymond Chen

Vor kurzem las ich einen Blogbeitrag eines Kollegen von mir, dem „Audio Fool“, und er erinnerte mich an einen Fehler, der mir vor vielen Jahren unterlaufen ist und der mich noch immer beschäftigt. Als sich die DirectInput®-Schnittstelle für Joysticks mit Kraftrückmeldung (Force Feedback) noch in der Entwicklung befand, wurden Joystickhersteller in die Microsoft-Zentrale in Redmond (Washington) eingeladen, um die Details der vorgeschlagenen Schnittstelle zu diskutieren und eigenes Feedback zu geben (kein Wortspiel beabsichtigt).
Bei diesen Treffen wurden zahlreiche Probleme erörtert, besonders im Gedächtnis geblieben ist mir jedoch ein Disput darüber, ob periodische Kräfte als Periode oder als Frequenz ausgedrückt werden sollten. Einer der anwesenden Hersteller regte sich auf, weil sein Unternehmen bereits einen Treiber entwickelt hatte, der die periodischen Kräfte als Frequenz angab, und der Hersteller dies nicht ändern wollte. Wie konnte ein Hersteller angesichts der Tatsache, dass es bei diesem Treffen um die Erarbeitung der Details einer völlig neuen Schnittstelle ging, erwarten, keinerlei Änderungen an seinem Treiber vornehmen zu müssen?
Dieser Hersteller beklagte sich jedoch so lautstark, dass wir schließlich nachgaben und zustimmten, zur Angabe der Rate periodischer Kräfte die Frequenz anstelle der Periode zu verwenden. Schließlich würde es doch auf dasselbe hinauslaufen. Eine Kraft mit einer Frequenz von 10 Schwingungen pro Sekunde ist mit einer Kraft mit einer Periode von einer Zehntelsekunde identisch. Periode und Frequenz stehen im umgekehrten Verhältnis.
Nun, das stimmt nicht ganz. Die Periode wurde in Millisekunden ausgedrückt, wodurch sie einen dynamischen Bereich zwischen 1 ms und knapp 50 Tagen erhält. Eine Periode von 50 Tagen ist auf der menschlichen Zeitskala nicht wahrnehmbar, und eine Periode von 1 ms ist so schnell, dass sie nicht einmal als periodisches Phänomen registriert wird – stattdessen wird sie als Musikton wahrgenommen.
Die Frequenz wurde andererseits in Hertz ausgedrückt, wodurch sie einen dynamischen Bereich von 1 Hz bis zu 4 Milliarden Zyklen pro Sekunde erhält. Finden Sie es vielleicht komisch, mit Ihrem Joystick Musik zu spielen? Stellen Sie sich die Erzeugung von Kräften vor, die bis in den Mikrowellenfrequenzbereich reichen!
Das Problem besteht darin, dass die praktisch nutzlose Ausdrucksstärke am oberen Ende des Frequenzbereichs zu Lasten des unteren Endes ging. Wie sich herausstellt, sind Flugsimulatoren große Fans periodischer Kräfte mit vergleichsweise langen Perioden. Ich kenne die zugrunde liegende Physik nicht, aber mir wurde gesagt, dass einer der Effekte, mit dem sich Piloten befassen müssen, eine auf den Steuerknüppel einwirkende periodische Kraft im Bereich von einigen Minuten ist. Das Flugzeug hat eine natürliche Tendenz, sich in einer sehr langsamen vertikalen Sinuswelle zu bewegen, und Piloten müssen Maßnahmen ergreifen, um dieser Tendenz entgegenzuwirken und den Horizontalflug aufrechtzuerhalten. Wenn die Rate der Kraft durch ihre Periode ausgedrückt würde, könnte im Flugsimulatorprogramm eine Periode von 120.000 Millisekunden vorgesehen werden. Als Frequenz ausgedrückt sind dies jedoch 0,0083 Hertz, was weitaus langsamer als die langsamste Frequenz ist, die in der Treiberschnittstelle ausgedrückt werden kann, nämlich 1 Hz. Daher ist die langsamste Kraft, die ein Flugsimulator anfordern kann, eine Kraft, die sich jede Sekunde wiederholt, was in Bezug auf den physikalischen Effekt, den der Flugsimulator nachahmen soll, immer noch ziemlich schnell ist.
Da mich dieses Problem nach all den Jahren immer noch beschäftigt, habe ich kürzlich in der Dokumentation zur Kraftrückmeldung nachgeschlagen. Zu meiner Überraschung wird anscheinend bei der DIPERIODIC-Struktur die Periode anstelle der Frequenz verwendet, um periodische Effekte auszudrücken. (Obendrein werden Mikrosekunden verwendet, was bedeutet, dass Sie jetzt nicht nur ein Flugzeug fliegen, sondern auch Musik spielen können.) Entweder wurde der Fehler behoben, oder ich werde langsam alt, und mein Gedächtnis spielt mir einen Streich. Ich muss mir jedenfalls keine Sorgen mehr wegen dieses Fehlers machen – wenn er denn überhaupt je passiert ist.

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. Diese Farbe steht Ihnen ausgezeichnet.