 TechNet Magazine December 2006
TechNet Magazine December 2006
DECEMBER 2006
Exchange Server 2007

Sind Sie bereit für die Umstellung auf Exchange 2007? Dann sind Sie hier genau richtig. Diesen Monat zeigen wir Ihnen, wie Sie sich auf die Aktualisierung vorbereiten, wie Sie Skripts für die Verwaltung von Exchange mithilfe der Exchange-Verwaltungsshell schreiben und wie Sie die Vorteile von Unified Messaging und des Zugriffs von beliebigen Standorten nutzen können, wenn Sie Outlook Web Access und Exchange 2007 kombinieren.

Außerdem finden Sie die aktuellen Verbesserungen sowohl von Exchange Server 2007 als auch des Outlook 2007-Clients. Sie erfahren, wie Sie Spam noch wirksamer mit dem Sender ID Framework bekämpfen, und erhalten weitere Informationen zum Journaling in Exchange 2007 für bessere Kontrolle und Kompatibilität.

FUNKTIONEN
Exchange Server 2007 Aktualisieren Ihrer Infrastruktur auf Exchange 2007

Unabhängig davon, ob Ihre Organisation groß oder klein ist, erfordert ein reibungsloser Übergang zu Exchange Server 2007 etwas Vorausplanung. Mit dem richtigen Plan können Sie Dienstunterbrechungen vermeiden. Im Folgenden sind die Schritte aufgeführt, die Sie für die Durchführung einer Aktualisierung befolgen müssen.

Kate Follis Übernehmen Sie das Kommando mit der Exchange-Verwaltungsshell

Die Exchange-Verwaltungsshell bietet Administratoren eine leistungsfähige Schnittstelle zum Verwalten aller Aspekte von Exchange Server 2007. Verschaffen Sie sich einen Überblick darüber, wie Sie damit beginnen können, Skripts zu schreiben, Anwendungen zu integrieren und andere wichtige Verwaltungsaufgaben über die Befehlszeile auszuführen.

David Strome Exchange & Outlook: Gemeinsam besser

Zusammen stellen Exchange Server 2007 und Microsoft Office Outlook 2007 eine riesige Weiterentwicklung bei der Kommunikation und Zusammenarbeit dar. Überzeugen Sie sich selbst, während wir die einfachere Konfiguration, die verbesserten Suchmöglichkeiten, Unified Messaging und weitere Neuerungen unter die Lupe nehmen.

Michael Khalili Immer in Verbindung mit Exchange 2007

Kommunikation ist heute wichtiger als je zuvor. Erfahren Sie, wie Sie mit den in Exchange Server 2007 integrierten Funktionen von Unified Messaging und Outlook Web Access auf alle Ihre Nachrichten gebündelt von einem beliebigen Standort aus zugreifen können.

Joshua Trupin Leistungsstarkes Journaling in Exchange 2007

Exchange Server 2007 stellt viel flexiblere Journalfähigkeiten bereit, die es Ihnen erleichtern, bestimmte Benutzerkonten zu überwachen und Konformitätsvorschriften innerhalb eines großen Unternehmens einzuhalten.

David Strome Bekämpfen von SPAM und Phishing mit Sender ID

Die auf dem Sender ID Framework (SIDF) beruhende E-Mail-Authentifizierung stößt auf eine ständig größer werdende Akzeptanz und stellt damit einen enormen Fortschritt bei der Bekämpfung von Spam- und Phishingnachrichten dar. Tatsächlich ist bereits über ein Drittel des E-Mail-Aufkommens in der ganzen Welt authentifiziert und SIDF-kompatibel. Dieses Verfahren funktioniert folgendermaßen.

Craig Spiezle und Alexander Nikolayev
SPALTEN
Mitteilung der Redaktion

Kontakt mit unseren Lesern

Joshua Trupin Toolbox

Neue Produkte für IT-Profis

Greg Steen Windows PowerShell

Einfache Befehle. Leistungsstarke Verwaltung

Don Jones Nachbesprechung

Migration von Exchange 5.5

Whitney Roberts 		Fragen und Antworten zu SQL

Verhindern von Neustarts, Installieren mehrerer Updates und vieles mehr

Herausgegeben von Nancy Michell Hey, Scripting Guy!

Wo Sind die Becherhalter?

Die Scripting Guys von Microsoft SICHERHEIT AUF DEM PRÜFSTAND

Bereitstellen einer global vertrauenswürdigen PKI

John Morello Die Desktopdateien

Einblick in das Windows Imaging-Format

Wes Miller Windows Confidential

Warten auf RunOnce

Raymond Chen


 Exchange Server&#160;2007: Aktualisieren Ihrer Infrastruktur auf Exchange&#160;2007
Exchange Server 2007 Kate Follis

Aktualisieren Ihrer Infrastruktur auf Exchange 2007
Kurz zusammengefasst:
  • Neue Funktionen in Exchange 2007
  • Vorbereitung auf eine Aktualisierung
  • Rollenbasierte Bereitstellung
  • Nachrichtenroutingtopologie

Einer der von mir unterrichteten Kurse befasste sich mit der Migration von Exchange Server 5.5 zu Exchange 2000. Der Unterricht begann morgens um 8:30 Uhr und dauerte bis abends um 18:00 Uhr. Wenn ich den Schulungsraum abends verließ,
war ich vollkommen gerädert. Es gab extrem viel vorzubereiten, nur um die Verzeichnisressourcen zu verschieben, und außerdem viel Verwirrung um NTDSNoMatch und das wackelige Vertrauen in Windows NT® 4.0, das ein Vertrauen schier unmöglich machte. Aus Zeitgründen hatten wir kaum Gelegenheit, auf die Exchange 2000 Server-Verwaltung einzugehen, aber es gab immer ein paar wissensbegierige Kursteilnehmer, die den Schulungsraum am Freitag Abend verlassen und die Migration über das Wochenende abschließen wollten. Davon habe ich immer abgeraten und mehr Planungszeit empfohlen, aber ich bin sicher, dass sie meine Warnung einfach ignoriert haben.
Der Übergang von Exchange 2000 Server oder Exchange Server 2003 zu Exchange Server 2007 erfordert ebenso Vorsicht und Vorausplanung. Der eigentliche Übergangsprozess ist je nach Organisation und der Komplexität der aktuellen Bereitstellung unterschiedlich, der Übergangsprozess erfordert jedoch nach wie vor ein Durchlaufen mehrerer Phasen. Eine kleine Organisation kann diese Phasen möglicherweise in einem einzelnen Projekt durchlaufen, während eine große Organisation möglicherweise entscheidet, Serverrollen schrittweise einzuführen und Exchange in einem Koexistenzmodus für einen bestimmten Zeitraum zu unterstützen. Der End-to-End-Prozess ist so entworfen, dass Messagingfunktionalität und -stabilität für den gesamten Übergangszeitraum aufrechterhalten werden. In diesem Artikel werden die wichtigsten Schritte beschrieben, die für eine Beibehaltung des Nachrichtenflusses innerhalb Ihrer Organisation erforderlich sind, während Sie auf Exchange Server 2007 aktualisieren.

Besonderheiten
Die erste Anforderung, auf die geachtet werden muss, ist, dass Exchange Server 2007 auf 64-Bit-Hardware bereitgestellt werden muss und keine direkte Aktualisierung von einer früheren Version von Exchange unterstützt. Sie müssen die Swingaktualisierungsmethode verwenden, um Ihre vorhandenen Messagingdienste zu Exchange 2007 zu verschieben. Die Exchange-Organisation muss sich außerdem im einheitlichen Modus befinden, um die zusätzlichen Exchange 2007-Server zu unterstützen. Wenn Ihre Organisation derzeit Exchange 5.5 verwendet, müssen Sie eine Zwischenaktualisierung zu Exchange Server 2003 durchführen, bevor Sie mit Exchange 2007 fortfahren.
Es gibt einige wichtige Änderungen in Exchange 2007, die Sie bei der Planung Ihres Übergangs bedenken müssen. Beispielsweise führt Exchange 2007 rollenbasierte Bereitstellung ein, mit der Sie die bereitzustellenden Messagingdienste auswählen und die für diese Dienste spezifischen Serverrollen bereitstellen können. Sie können die Serverrollen einzeln auf dedizierter Hardware bereitstellen oder mehrere Rollen auf demselben physischen Server installieren, die als separate Entitäten verwaltet werden. Eine Erklärung jeder Rolle finden Sie in der Randleiste „Exchange 2007-Serverrollen“.
Exchange Server 2007-Serverrollen
Postfachserver Die Postfachserverrolle bietet einen Nachrichtenspeicher für eine Organisation. Exchange 2007 kann bis zu 50 Speicher pro Server unterstützen. Diese Speicher können als 50 einzelne Speichergruppen bereitgestellt werden, oder Sie können bis zu 50 Speicher in einer einzelnen Speichergruppe erstellen. Die Postfachserverrolle ist die einzige Rolle, die als Cluster bereitgestellt werden kann. Wenn Sie also Clustering verwenden, müssen Sie den Postfachserver auf dedizierter Hardware installieren.
Clientzugriffsserver Die Clientzugriffs-Serverrolle ersetzt die Funktionalität, die von einem Front-End-Server bereitgestellt wird. Sie bietet Postfachzugriff auf Clients, die auf Exchange mithilfe von POP3, IMAP4, Outlook® Web Access (OWA), RPC-über-HTTPS (jetzt bekannt als Outlook Anywhere) und Exchange ActiveSync® zugreifen.
Hubtransportserver Diese Rolle stellt SMTP- und MAPI-Nachrichtentransportdienste für die Exchange-Organisation zur Verfügung. Jede Nachricht, die von den Benutzern in Ihrer Organisation gesendet oder empfangen wird, wird von einem Hubtransportserver verarbeitet. Dies ist sehr nützlich, da dadurch sichergestellt wird, dass keine Nachricht die serverbasierten Regeln oder Journalrichtlinien umgehen kann, die von Agents bereitgestellt werden, die an verschiedenen Stellen in der Transportpipeline aktiv sind.
Unified Messaging-Server Diese Rolle stellt Sprachzugriff auf Ihr Postfach bereit. Sie ist in Ihr IP/VoIP-Gateway oder IP-PBX integriert, um Telefonzugriff auf Nachrichten und Kalenderelemente bereitzustellen und Ihnen die Möglichkeit zu geben, eine Antwort zu transkribieren. Diese Rolle ist neu in Exchange und kann nicht mit einer der früheren Versionen von Exchange verwendet werden.
Edgetransportserver Der Edgetransportserver wird normalerweise in Ihrem Umkreisnetzwerk bereitgestellt. Er stellt SMTP-Nachrichtentransport zwischen der Exchange-Organisation und dem Internet bereit und bietet Antispam- und Antivirusverarbeitung mithilfe von Transportagents. Sie können jetzt eine einzelne Technologie als Standard sowohl für Organisations- als auch Umkreisnetzwerkserver einrichten. Dieses nahtlose Interaktionsmodell vereinfacht die Verwaltung und ermöglicht eine einfache Integration von Umkreisservern.

Untersuchen Sie Ihre Topologie
Womit fangen Sie an? Nun, es ist schwierig, Ihr Ziel zu bestimmen, wenn Sie Ihre momentane Situation nicht genau kennen. Nehmen Sie sich Zeit, Ihre aktuelle Umgebung einzuschätzen und die Topologie zu dokumentieren – nicht nur Exchange, sondern auch die Active Directory®-Umgebung. Es wird Sie wahrscheinlich freuen zu erfahren, dass Exchange 2007 jetzt kein Verbindungsstatusrouting und keine Topologie basierend auf Routinggruppen und Connectors mehr beinhaltet. Stattdessen nutzt Exchange 2007 den Vorteil der Investition aus, die Ihre Organisation bereits in das Entwerfen der Active Directory-Topologie gesteckt hat. Daraus resultierend werden alle Exchange-Empfänger und Konfigurationsdaten in Active Directory gespeichert, die Routingtopologie wird aus der Active Directory-Standortkonfiguration abgeleitet, und alle Serverrollen verwenden Standortinformationen, um die Dienste, die auf den Serverrollen ausgeführt werden, zu erkennen.
Stellen Sie sicher, dass die aktuelle Active Directory-Standorttopologie das zugrunde liegende physische Netzwerk wirklich nutzt und dass alle Active Directory-Standorte über verknüpfte Subnetze verfügen, und dokumentieren Sie daraufhin die vorhandenen Active Directory-Standorte und IP-Standortverknüpfungen. Dokumentieren Sie außerdem, wo sich Ihre Exchange 2003-Server physisch befinden, sowie die Routinggruppe und Routinggruppenconnector-Struktur.
Dies ist der schwierigste Teil des Übergangsprozesses: das Verschieben aus einer Exchange-Routinginfrastruktur basierend auf Routinggruppen in eine Routinginfrastruktur basierend auf Active Directory-Standorten. Für eine kleine Organisation ist dies normalerweise ein einfacher Prozess. Eine große Organisation mit zahlreichen Routinggruppen muss eine Übergangsphase jedoch vorsichtig planen, wenn Exchange 2003 und Exchange 2007 koexistieren. Vermeiden Sie das Senden einer Nachricht an Ihr Exchange 2003-Postfach vom Exchange 2007-Benutzer von gegenüber, die durch eine Remoteroutinggruppe über eine Verbindung mit niedriger Bandbreite geroutet wird.
Gehen Sie von folgenden Annahmen für Ihre aktuelle Topologie aus:
  • Die Exchange 2003-Organisation wird im einheitlichen Modus ausgeführt.
  • Sie verfügen über mehr als eine Routinggruppe.
  • Sie verfügen über mehr als einen Active Directory-Standort.
Abbildung 1 zeigt eine Exchange- und Active Directory-Topologie. Denken Sie daran, je mehr Details Sie in Ihren vorläufigen Plänen berücksichtigen, desto besser wird Ihr Design.
Abbildung 1 Eine Exchange- und Active Directory-Topologie
Abbildung 1 Eine Exchange- und Active Directory-Topologie (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Eine Exchange- und Active Directory-Topologie
Abbildung 1 Eine Exchange- und Active Directory-Topologie (Klicken Sie zum Vergrößern auf das Bild)

So verwendet Exchange 2007 Active Directory
Wenn ein Exchange 2007-Server startet, wird er mit einem Standortattribut gekennzeichnet, das anderen Exchange 2007-Servern beim Finden der von diesem Server zur Verfügung gestellten Dienste hilft. Nur der Hubtransportserver kann SMTP für den Transport einer Nachricht innerhalb der Organisation verwenden. Jeder Active Directory-Standort, der einen Postfachserver enthält, muss auch einen Hubtransportserver enthalten, und wenn die Postfachbenutzer auf ihr Postfach mithilfe einer Nicht-MAPI-Methode zugreifen, muss jeder Standort außerdem einen Clientzugriffsserver enthalten. Jedes Mal, wenn eine Nachricht für die Zustellung verarbeitet werden muss, läuft sie durch einen Hubtransportserver, der eine Entscheidung trifft, wie die Nachricht geroutet werden soll. Wenn die Nachricht für einen Postfachserver bestimmt ist, der sich am selben Active Directory-Standort wie der Hubtransportserver befindet, sendet der Hubtransportserver die Nachricht an das Postfach. Wenn die Nachricht für einen Postfachserver bestimmt ist, der sich an einem anderen Standort befindet, leitet der Hubtransportserver die Nachricht direkt an einen Hubtransportserver an einem Remotestandort weiter.
Der Hubtransportserver verwendet die Kosteninformationen der Active Directory-IP-Standortverknüpfung zur Berechnung der kostengünstigsten Route zum Active Directory-Standort, an dem sich das Postfach des Empfängers befindet. Der Routenauswahlalgorithmus ist dem von Exchange 2003 sehr ähnlich, aber er basiert auf Standortverknüpfungskosten anstelle von Routinggruppenconnector-Kosten. Außerdem wird die Nachricht nicht an jedem Hubtransportserver angehalten. Sie gelangt direkt von der Quelle zum Ziel. Weshalb macht er sich also die Mühe, die kostengünstigste Route zu berechnen, wenn er sich auf das IP-Netzwerk für das Senden der Nachricht verlässt? Dafür gibt es einige Gründe. Einer ist die Verzögerung von Nachrichtengabelung. Eine Nachricht, die an mehr als einen Empfänger gesendet wird, muss möglicherweise an Postfachserver an mehr als einem Active Directory-Standort gesendet werden. Anstatt die Nachricht am ersten Hubtransportserver zu gabeln oder zu teilen, teilt Exchange 2007 die Nachricht nicht, bis sie eine Gabelung im Routingpfad erreicht. Dies hat zur Folge, dass die Nachricht direkt an einen Hubtransportserver am Active Directory-Standort weitergeleitet wird, der den Gabelungspunkt darstellt. Dieses Verhalten wird auch als verzögerter Ausgangsfächer beschrieben.
Die kostengünstigste Route wird außerdem verwendet, um zu bestimmen, wo die Nachricht in die Warteschlange gestellt werden soll, für den Fall, dass das Ziel nicht erreicht werden kann. Wenn ein Hubtransportserver am Active Directory-Zielstandort nicht erreicht werden kann, versucht der sendende Hubtransportserver daraufhin, die Sendung an einen Hubtransportserver am nächstgelegenen Active Directory-Standort gemäß dem Routingpfad zu übermitteln. Die Nachrichtenübermittlung geschieht weiterhin entlang der kostengünstigsten Route, bis sie einen Active Directory-Standort erreicht, an dem ein Hubtransportserver verfügbar ist. Wenn schließlich keine Hubtransportserver entlang der Route zum empfangenden Active Directory-Standort verfügbar sind, wird die Nachricht lokal in die Warteschlange gestellt. Mit dieser Methode wird die Nachricht so nahe wie möglich am Lieferpunkt in die Warteschlange gestellt, was die Diagnose von Netzwerkfehlern deterministischer macht. Dieses Verhalten wird „Queue-at-point-of-failure“ (Warteschlange an Fehlerpunkt) genannt.
Exchange 2003 funktioniert auf eine komplett andere Weise. Es berechnet die kostengünstigste Route von einer Routinggruppe zu einer anderen basierend auf den Kosten, die den Routinggruppenconnectors zugewiesen sind. Ein Bridgeheadserver in jeder Routinggruppe entlang des Routingpfads empfängt die Nachricht und leitet sie weiter. Wenn der nächste Connector im Pfad nicht verfügbar ist, wird ein Versuch unternommen, eine alternative Route zu berechnen. Verbindungsstatus-Aktualisierungsnachrichten werden auch über die Exchange-Organisation übermittelt, um die anderen Exchange-Server darüber zu unterrichten, dass die Verbindung unterbrochen ist. Die Bridgeheadserver versuchen, um den nicht funktionierenden Connector herum zu routen, bis eine Verbindungsstatusbenachrichtigung empfangen wurde, die angibt, dass die Verbindung wieder funktioniert.
Die Herausforderung beim Übergangsprozess in einer großen Organisation besteht darin, den E-Mail-Verkehr während des Koexistenzzeitraums zu verwalten. Um diese Kontinuität zu erreichen, wenn Exchange 2007 in die Umgebung eingeführt wird, werden alle Exchange 2007-Server zu Mitgliedern einer einzelnen Routinggruppe. Das bedeutet, dass unabhängig davon, an welchem Active Directory-Standort sich der Exchange 2007-Server befindet, Exchange 2003 ihn als zu dieser einzelnen Routinggruppe gehörig betrachtet. Dies ermöglicht Ihnen, einen Routinggruppenconnector zwischen dieser Routinggruppe und den Exchange 2003-Routinggruppen einzurichten, sodass Exchange 2003 entscheiden kann, wie Nachrichten an Exchange 2007 geroutet werden. Exchange 2007 verwendet den Routinggruppenconnector außerdem zur Bestimmung, wie Nachrichten an Exchange 2003 gesendet werden. Exchange 2007 wird es jedoch immer vorziehen, eine Nachricht über einen anderen Exchange 2007-Server zu routen, und wird nie über eine Exchange 2003-Routinggruppe zu einem anderen Exchange 2007-Server weiterleiten.

Einführung des ersten Exchange 2007-Servers
Wenn Sie den ersten Exchange 2007-Server in der Exchange 2003-Organisation installieren, müssen Sie einen Exchange 2003-Bridgeheadserver auswählen, mit dem der erste Routinggruppenconnector eingerichtet wird.
Abbildung 2 zeigt, wie die Einführung des ersten Exchange 2007-Servers sich auf die Organisationstopologie auswirkt.
Abbildung 2 Installation des ersten Exchange 2007-Servers
Abbildung 2 Installation des ersten Exchange 2007-Servers (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Installation des ersten Exchange 2007-Servers
Abbildung 2 Installation des ersten Exchange 2007-Servers (Klicken Sie zum Vergrößern auf das Bild)
So weit so gut. Beachten Sie, dass die Standardkosten des von Exchange 2007 erstellten Routinggruppenconnectors nur 1 betragen. E-Mails werden wie üblich durch die Exchange 2003-Server geleitet, und wenn eine Nachricht an einen Benutzer auf dem Exchange 2007-Server von einem beliebigen Exchange 2003-Server gesendet wird, wird sie durch die Acapulco-Routinggruppe geleitet. Als der Routinggruppenconnector erstellt wurde, wurde der von Ihnen ausgewählte Exchange 2003-Bridgeheadserver automatisch zu einem Mitglied der ExchangeLegacyInterop-Universalsicherheitsgruppe und erhielt die korrekten Berechtigungen zum Senden und Empfangen von E-Mail-Nachrichten an und von Exchange 2007. Verwenden Sie immer den New-RoutingGroupConnector in der Exchange-Verwaltungsshell zur Erstellung eines Routinggruppenconnectors, wenn ein Exchange 2007-Server als Quellen- oder Zielserver für den Connector angegeben wird. Sie können auch das Cmdlet „Set-RoutingGroupConnector“ verwenden, um die Konfiguration eines Routinggruppenconnectors zu ändern. Sie möchten z. B. Quellen- und Zielserver zum ursprünglichen Routinggruppenconnector hinzufügen, um Redundanz bereitzustellen. (Weitere Informationen finden Sie im Artikel von David Strome über die Exchange-Verwaltungsshell in dieser Ausgabe des TechNet Magazins.)

Vorbereitung zum Verschieben einiger Postfächer
Der nächste Schritt besteht im Verschieben einiger Postfächer von den Exchange 2003-Servern zu den Exchange 2007-Servern. Verwenden Sie das cmdlet „Move-Mailbox (Postfach verschieben)“, um dies durchzuführen. Bevor Sie die Exchange 2003-Server jedoch außer Betrieb nehmen können, erstellen Sie Connectors zum Senden und Empfangen auf dem Exchange 2007-Server, um alle SMTP-Connectors zu ersetzen, die auf dem Exchange 2003-Server zur Verarbeitung des Routing an externe SMTP-Adressräume definiert waren.
Im nächsten Diagramm wurden die Ressourcen der Acapulco-Routinggruppe zu Exchange 2007 verschoben. Die Acapulco-Routinggruppe kann außer Betrieb genommen werden. Dies bedeutet jedoch, dass Sie nun einen Routinggruppenconnector zu einer anderen Routinggruppe einrichten müssen. In Abbildung 3 wurde der Routinggruppenconnector für einen Bridgeheadserver in der Miami Norden-Routinggruppe konfiguriert.
Abbildung 3 Konfigurieren des Routinggruppenconnectors
Abbildung 3 Konfigurieren des Routinggruppenconnectors (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Konfigurieren des Routinggruppenconnectors
Abbildung 3 Konfigurieren des Routinggruppenconnectors (Klicken Sie zum Vergrößern auf das Bild)
Fahren Sie fort mit der Übertragung der LA Osten-Routinggruppe zu Exchange 2007. Dies ist eine Situation, in der die Verwaltung des Routing etwas komplizierter wird. In Abbildung 4 wurde Exchange 2007 am Standort Los Angeles installiert, und eine zweite Routinggruppe wurde außer Betrieb genommen. Es wurden jedoch keine zusätzlichen Routinggruppenconnectors erstellt.
Abbildung 4 Installiertes Exchange 2007 am Standort Los Angeles
Abbildung 4 Installiertes Exchange 2007 am Standort Los Angeles (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4 Installiertes Exchange 2007 am Standort Los Angeles
Abbildung 4 Installiertes Exchange 2007 am Standort Los Angeles (Klicken Sie zum Vergrößern auf das Bild)
Wenn jetzt eine Nachricht vom Exchange 2007-Server am Standort Lost Angeles an den Exchange 2003-Server in der LA Westen-Routinggruppe gesendet wird, wird sie zunächst nach Acapulco weitergeleitet, dann nach Miami Norden, Miami Süden und schließlich nach LA Westen. Wenn eine Nachricht vom Exchange 2003-Server in der LA Westen-Routinggruppe an den Exchange 2007Server am Standort Los Angeles gesendet wird, wird sie zunächst nach Miami Süden, dann nach Miami Norden, Acapulco und schließlich zurück nach Los Angeles weitergeleitet. Autsch.
Um dies zu vermeiden, müssen Sie einen zweiten Routinggruppenconnector hinzufügen. Abbildung 5 zeigt das Hinzufügen eines Routinggruppenconnectors von LA Westen zum Exchange 2007-Server am Standort Los Angeles. Hinweis: Wenn Sie eine Unmenge an Routinggruppenconnectors vermeiden möchten, stellen Sie sicher, dass Ihr erster Routinggruppenconnector in einem gut verbundenen Active Directory-Hubstandort konfiguriert ist.
Abbildung 5 Effizienteres Routing
Abbildung 5 Effizienteres Routing (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 5 Effizienteres Routing
Abbildung 5 Effizienteres Routing (Klicken Sie zum Vergrößern auf das Bild)
Dies führt zu einem Problem, das möglicherweise nicht sofort erkennbar ist. Es gibt jetzt mehr als einen Eingang und einen Ausgang für die Exchange 2007-Routinggruppe. Da die Exchange 2007-Routinggruppe keinen Verbindungsstatus verwendet, ist nun eine potenzielle Routingschleife vorhanden. Der Exchange 2003-Server kann eine alternative Route um einen nicht funktionierenden Connector herum auswählen, während Exchange 2007 immer die kostengünstigste Route auswählt. Eine Umgehung dieses Problems liegt in der Unterdrückung geringer Verbindungsstatus-Aktualisierungsnachrichten, die Verbindungsstatusnachrichten verhindern, die einen nicht funktionierenden Connectorstatus melden, verhindern jedoch nicht Verbindungsstatusnachrichten, die Konfigurationsänderungen mitteilen. Dies ist wichtig, da die Exchange 2003-Server über die neuen Routinggruppenconnectors informiert sein sollen, jedoch nicht versuchen sollen, eine alternative Route zu berechnen. Das Endergebnis ist, dass die Exchange 2003-Server das gleiche „Queue-at-point-of-failure“ wie die Exchange 2007-Server zeigen werden.
In Abbildung 6 wurden weitere Exchange 2003-Ressourcen in Exchange 2007 überführt. Verbindungsstatusaktualisierungen wurden unterdrückt, und es wurde darauf geachtet, Routinggruppenconnectors einzurichten, die einen logischen Routingpfad beibehalten.
Abbildung 6 Mehr Exchange 2003-Ressourcen wechseln zu Exchange 2007
Abbildung 6 Mehr Exchange 2003-Ressourcen wechseln zu Exchange 2007 (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 6 Mehr Exchange 2003-Ressourcen wechseln zu Exchange 2007
Abbildung 6 Mehr Exchange 2003-Ressourcen wechseln zu Exchange 2007 (Klicken Sie zum Vergrößern auf das Bild)
Es besteht allerdings ein anderes Problem. Es wurden Verbindungsstatusinseln in Redmond und Vancouver erstellt. Die E-Mail wird problemlos weitergeleitet, wenn auch über Miami. Es besteht jedoch keine Möglichkeit für Redmond und Miami, Verbindungsstatus-Konfigurationsänderungen mitzuteilen. Um eine aktuelle Routingtabelle beizubehalten, müssen Sie einen anderen Routinggruppenconnector zwischen Redmond und Vancouver konfigurieren. Sie können die Kosten dieses Routinggruppenconnectors anpassen, sodass diese hoch genug sind, um Exchange 2003 an einem Routing über diese Verbindung zu hindern, während Verbindungsstatus-Konfigurationsänderungen weiterhin gemeldet werden können.
Mit vorsichtiger Planung können Sie die Probleme umgehen, die durch die Beibehaltung zweier separater Exchange-Routingtopologien entstehen können. Die besten Ergebnisse erzielen Sie, wenn Sie den Übergang für jede Routinggruppe einzeln vornehmen und jeweils dann mit der nächsten fortfahren, bis Sie ausschließlich Exchange 2007-Server ausführen.
Bis jetzt wurde auf die Routingänderungen in Exchange 2007 eingegangen, und darauf, wie sich diese auf Ihren Übergang auswirken. Es gibt noch ein paar weitere Überlegungen zu berücksichtigen, wenn Sie einen Wechsel zu Exchange 2007 planen.
Exchange 2003-Front-End-Server können nicht auf Exchange 2007-Postfächer zugreifen. Ein Exchange 2007-Clientzugriffsserver hat jedoch kein Problem, Sie mit Ihrem Exchange 2003-Postfach zu verbinden. Wenn Sie den Exchange 2007-Clientzugriffsserver verwenden, sehen Sie die gleiche OWA-Version wie der Postfachserver, auf dem Ihr Postfach gespeichert ist. Wenn Sie Exchange 2007 auf separater Hardware bereitstellen, sollte der Clientzugriffsserver die erste Rolle sein, die Sie an einem Active Directory-Standort einführen. Alle Exchange 2003-Front-End-Server, die öffentlichen Internetzugriff auf Postfächer bereitstellen, sollten durch Exchange 2007-Clientzugriffsserver ersetzt werden, bevor Postfächer zu Exchange 2007 verschoben werden.
Es wurde zuvor erwähnt, dass jeder Standort, der die Postfachserverrolle enthält, auch die Clientzugriffs-Serverrolle (wenn Sie über Nicht-MAPI-Clients verfügen – und wer kommt heutzutage schon ohne OWA aus?) und einen Hubtransportserver benötigt. Wenn Ihre Serverrollen also Hardware gemeinsam nutzen, achten Sie darauf, den Clientzugriffsserver in die Rollenauswahl einzuschließen. Zu einer typischen Installation gehören die Hubtransport-Serverrolle, die Clientzugriffs-Serverrolle und die Postfach-Serverrolle. Dies reicht für eine vollständig funktionierende Exchange-Umgebung aus.
Eine andere Überlegung für den Übergangsprozess ist der Zeitpunkt der Aktualisierung Ihrer Clientanwendung (Outlook). Es wird Ihnen nicht möglich sein, die Vorteile aller Exchange 2007-Serverfeatures vollständig zu nutzen, bis Ihre Clients auf Outlook 2007 aktualisiert wurden. Dazu gehören verbesserte Abwesenheitsnachrichten-Einstellungen und verwaltete Postfachordner-Features.
Sie werden auch entscheiden müssen, wann die Edgetransport-Serverrolle bereitgestellt werden soll. Genau genommen können Sie Ihr aktuelles Umkreisnetzwerk-SMTP-Relay und Ihren Smarthost mit dem Edgetransportserver ersetzen, bevor oder nachdem Sie beliebige sonstige Exchange 2007-Serverrollen eingeführt haben. Wenn Sie zunächst allerdings den Edgetransportserver bereitstellen, ist die Gesamtfunktionalität eingeschränkt, da Exchange 2003 keine Möglichkeit hat, die Empfänger- und Konfigurationsdaten zu replizieren, die der Edgetransportserver von Active Directory zum Active Directory-Anwendungsmodus (ADAM) benötigt.
Nachdem Sie mindestens einen Hubtransportserver installiert haben, können Sie den Edgetransportserver im Umkreisnetzwerk bereitstellen und den Edgetransportserver daraufhin dem Active Directory-Standort zuordnen, an dem sich der Hubtransportserver befindet. Der EdgeSync-Dienst auf dem Hubtransportserver repliziert eine Teilmenge der Empfängerdaten in Active Directory zu ADAM.
Mit diesen Daten kann der Edgetransportserver eine Empfängersuche und eine Sicherheitslistenzusammenfassung durchführen, sodass Sie die Vorteile der auf dem Edgetransportserver ausgeführten Spamschutzagents vollständig nutzen können. Zusätzlich dazu erstellt EdgeSync die Sendeconnectors, die für einen End-to-End-E-Mail-Verkehr an und von der Exchange-Organisation und dem Internet benötigt werden. Dies kann den Vorgang des Ersetzens der Exchange 2003-SMTP-Connectors vereinfachen, die Routing an externe Adressräume bereitstellen.
Nehmen Sie sich deshalb etwas Zeit, Ihren Übergang zu Exchange 2007 zu planen, und der Prozess wird einfach und frei von Problemen sein.

Kate Follis ist Senior Content Publisher des Exchange 2007-Teams technischer Redakteure. Ihre Gruppe ist spezialisiert auf Edgetransport- und Hubtransport-Serverrollen. Bevor sie zu Microsoft kam, war Kate Follis mehrere Jahre lang Microsoft-zertifizierte Trainerin für Exchange und Active Directory.
© 2007 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


 Exchange Server&#160;2007: &#220;bernehmen Sie das Kommando mit der Exchange-Verwaltungsshell
Exchange Server 2007 David Strome

Übernehmen Sie das Kommando mit der Exchange-Verwaltungsshell
Kurz zusammengefasst:
  • Funktionsweise der Exchange-Verwaltungsshell
  • Verwenden von Cmdlets
  • Cmdlets und Befehle

Wenn Sie eine Exchange-Umgebung verwalten, haben Sie mittlerweile sicher erfahren, dass die kommende Anwendung Exchange Server 2007 eine neue Befehlszeilenschnittstelle beinhaltet: die Exchange-Verwaltungsshell. Die auf der Microsoft Windows PowerShell-Technologie basierende
Exchange-Verwaltungsshell ist eine leistungsfähige Verwaltungsschnittstelle, mit deren Hilfe Sie jeden Aspekt von Exchange Server 2007 über die Befehlszeile verwalten können. Von dort können Sie direkt auf die Exchange-Verwaltungsshell zugreifen, Skripts zur Automatisierung schreiben oder Ihre Anwendungen in das zugrunde liegende Modul integrieren. Abbildung 1 zeigt die Shell in Aktion.
Abbildung 1 Die Exchange-Verwaltungsshell
Abbildung 1 Die Exchange-Verwaltungsshell (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Die Exchange-Verwaltungsshell
Abbildung 1 Die Exchange-Verwaltungsshell (Klicken Sie zum Vergrößern auf das Bild)
Die Exchange-Verwaltungskonsole verwendet die Exchange-Verwaltungsshell nicht nur, um Vorgänge durchzuführen. Die Assistenten zeigen Ihnen auch, welche Befehle sie gerade durchführen. Kopieren Sie die Befehle, die diese Assistenten erstellen, und fügen Sie sie direkt in die Befehlszeile oder in ein Skript ein. Nachdem Sie die Parameter nach Wunsch geändert haben, testen Sie Ihre Skripts oder Befehle mithilfe des Parameters „WhatIf“, der Ihnen gestattet, die Ergebnisse zu begutachten, bevor Sie Änderungen an Ihrer Umgebung vornehmen.
Die Exchange-Verwaltungsshell bietet Ihnen eine stabile, flexible Skriptprogrammierungsplattform, die Sie in Ihre derzeitigen Skriptprogrammierungslösungen integrieren können, und ermöglicht Ihnen, systemintern mit Datenquellen wie COM und Windows-Verwaltungsinstrumentation (WMI) zu kommunizieren. Die auf .NET Framework beruhende Exchange-Verwaltungsshell verwendet Cmdlets – die kleinste funktionale Einheit der Exchange-Verwaltungsshell –, um statt unformatierten Texts strukturierte Daten zu akzeptieren und zurückzugeben. Wir befassen uns gleich eingehender mit diesen Cmdlets.

Das Windows PowerShell-Snap-In
Der erste Schritt zum Verständnis der Exchange-Verwaltungsshell besteht darin, ihre Beziehung zu Windows PowerShell™, einer auf .NET Framework basierenden brandneuen, leistungsfähigen und vielseitigen Befehlszeilenschnittstelle, zu untersuchen. Sie vereint die besten Features mehrerer anderer Shells und ergänzt diese durch viele neue Features. Windows PowerShell wurde zu dem Zweck entworfen, als Host für andere Anwendungen zu dienen, und ähnelt darin sehr der Microsoft Management Console (MMC), die als Host für die verschiedenen, von diversen Anwendungen bereitgestellten Snap-Ins fungiert. Die Exchange-Verwaltungsshell ist das erste Windows PowerShell-Snap-In, das bisher veröffentlicht wurde.
Snap-Ins sind Sammlungen von Cmdlets, die dazu verwendet werden, eine Anwendung oder eine Hauptkomponente zu verwalten. Sie können sie nur verwenden, wenn Sie sie vorher laden. Zum Glück ist es ganz einfach, das Exchange-Verwaltungsshell-Snap-In zu starten. Doch bevor ich darauf eingehe, sollte ich zunächst einige wichtige Begriffe erläutern, die Sie verstehen müssen, wenn Sie diesen Artikel lesen und die Exchange-Verwaltungsshell verwenden möchten.
Cmdlets: Cmdlets ähneln integrierten Befehlen in anderen Shells, wie z. B. dem Befehl „dir“, der in der Datei „cmd.exe“ enthalten ist. Genau wie diese vertrauten Befehle können Cmdlets direkt über die Befehlszeile der Exchange-Verwaltungsshell aufgerufen werden und werden nicht als separater Prozess, sondern innerhalb des Kontexts der Shell ausgeführt. Im Unterschied zu den in anderen Shells enthaltenen Befehlen besitzen Cmdlets beschreibende Namen, die aus einem Verb und einem Nomen bestehen. Das Verb beschreibt die Aktion, die das Cmdlet ausführt, und das Nomen beschreibt die Komponente oder das Feature, an der diese Aktion ausgeführt wird.
Sie müssen also nicht erraten, was ein Cmdlet bewirkt. Wenn Sie das Cmdlet „Move-Mailbox“ sehen, wissen Sie genau, wozu es dient.
Um herauszufinden, inwiefern sich Cmdlets von gewöhnlichen Befehlen unterscheiden, betrachten Sie die Randleiste „Cmdlets vs. Commands“ (Cmdlets und Befehle), die dem .NET Framework 3.0-Abschnitt des Windows®-SDK entnommen wurde und unter windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx zu finden ist.
Parameter „Identity“ und Positionsparameter: Der Parameter „Identity“ kann für die meisten Cmdlets verwendet werden, die mit Exchange in Beziehung stehen. Er ermöglicht Ihnen den Zugriff auf die eindeutigen Bezeichner für bestimmte Objekte in Exchange Server 2007, damit Sie mithilfe des für Sie sinnvollsten eindeutigen Werts Aktionen an einem bestimmten Exchange-Objekt durchführen können.
Der Parameter „Identity“ ist eine Sammlung von Werten anderer Parameter. Dabei wird garantiert, dass diese Werte innerhalb dieses Satzes von Objekten eindeutig sind. Entweder können Sie die Werte dieser anderen Parameter angeben (z. B. „Name“ und „DistinguishedName“) oder sie werden vom System generiert (z. B. eine GUID). Welche weiteren Parameter (falls überhaupt) verwendet werden und wie sie mit Werten gefüllt werden, hängt vom Objekt ab, auf das Sie sie anwenden möchten.
Der Parameter „Identity“ wird auch als Positionsparameter betrachtet, d. h. als ein Parameter, dessen Wert Sie festlegen können, ohne seinen Namen anzugeben. Ein Parameter ist ein Positionsparameter, wenn für das Attribut „Parameter Position“ eine ganze Zahl festgelegt wurde. Diese ganze Zahl gibt die Position in der Befehlszeile an, an der das Cmdlet den Wert des Parameters finden kann. Weil der Parameter „Identity“ ein Positionsparameter ist, der sich an der Position 0 (der ersten Position) befindet, wird jeder Wert, der an dieser Position ohne einen Parameternamen eingegeben wird, als Wert des Parameters „Identity“ behandelt. Dies reduziert die Anzahl der Tastenanschläge bei der Eingabe von Befehlen. Zum Beispiel führt
Get-Mailbox –Identity "Kim Akers"
die gleiche Aktion durch wie
Get-Mailbox "Kim Akers"
Pipelining: Unter Pipelining versteht man in der Exchange-Verwaltungsshell den Vorgang, bei dem ein Cmdlet bei der Durchführung eines Vorgangs die Ausgabe eines anderen Cmdlets verwendet. Pipelining wird mithilfe des Pipe-Symbols „|“ durchgeführt. Alle Verben in einem bestimmten Nomen-Cmdlet-Satz können die über eine Pipe aus einem anderen Befehl übergebenen Informationen verwenden. Bei einigen Nomen-Cmdlet-Sätzen können Sie durch Pipelining Daten auch einem anderen Nomen-Cmdlet-Satz übergeben.
Die Verwendung von Pipelining zum Verketten der Aktionen von zwei oder mehr Cmdlets ermöglicht Ihnen, kleinere Komponenten in etwas Leistungsfähigeres umzuwandeln. Sie können z. B. mit einem Cmdlet Daten sammeln, diese Daten einem zweiten Cmdlet übergeben, das aus diesen Daten eine Teilmenge herausfiltert, und danach diese Daten wiederum einem dritten Cmdlet übergeben, das dann nur diese Teilmenge verarbeitet.

Starten der Exchange-Verwaltungsshell
Die einfachste Methode, die Shell zu laden, besteht darin, nacheinander auf „Start“, „Programme“, „Microsoft Exchange Server 2007“ und „Exchange-Verwaltungsshell“ zu klicken.
Sie können das Exchange-Verwaltungsshell-Snap-In aber auch laden, indem Sie dies von einer Windows PowerShell-Sitzung aus manuell tun. Klicken Sie nacheinander auf „Start“, „Programme“ und „Windows PowerShell“. Nachdem Windows PowerShell gestartet wurde, führen Sie den folgenden Befehl aus, um die Exchange-Verwaltungsshell zu laden:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Es bestehen einige Unterschiede zwischen dem Laden des Exchange-Verwaltungsshell-Snap-Ins über den entsprechenden Eintrag im Menü „Programme“ und dem manuellen Starten dieses Snap-Ins mithilfe des Cmdlets „Add-PSSnapin“. Wenn Sie zum Laden den entsprechenden Eintrag im Menü „Programme“ verwenden, wird nicht nur das Exchange-Verwaltungsshell-Snap-In geladen, sondern zugleich ein Windows PowerShell-Skript zur Einrichtung einer individuell angepassten Exchange-Verwaltungsumgebung ausgeführt. Wenn Sie nach dem manuellen Laden des Exchange-Verwaltungsshell-Snap-Ins eine ähnliche Verwaltungsumgebung einrichten möchten, wechseln Sie in das Bin-Verzeichnis Ihrer Exchange-Installation (z. B. C:\Programme\Microsoft\Exchange Server\Bin). Führen Sie danach den folgenden Befehl aus:
.\Exchange.ps1
Sehen Sie sich das Skript „Exchange.ps1“ genauer an, um zu erfahren, wie Sie die Windows PowerShell-Umgebung an Ihre Bedürfnisse anpassen können. Wenn Sie die Exchange-Verwaltungsshell laden, werden Sie etwas Ähnliches wie in Abbildung 2 sehen.
Abbildung 2 Begrüßungsbanner der Exchange-Verwaltungsshell
Abbildung 2 Begrüßungsbanner der Exchange-Verwaltungsshell (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Begrüßungsbanner der Exchange-Verwaltungsshell
Abbildung 2 Begrüßungsbanner der Exchange-Verwaltungsshell (Klicken Sie zum Vergrößern auf das Bild)

Wo beginne ich?
Weil die Shell eine so umfangreiche Palette von Cmdlets bietet, werden sich das Cmdlet „Get-Help“ und die Hilfedatei von Exchange Server 2007 als kostbare Ressourcen erweisen. Im Abschnitt „Operations“ der Hilfedatei von Exchange Server 2007 werden Dutzende von Anleitungen zum Durchführen der meisten Verwaltungsaufgaben bereitgestellt.
Wenn Sie nur „Get-Help“ eingeben, werden allgemeine Hilfsinformationen zur Verwendung der Hilfe angezeigt. Um Hilfe zu einem bestimmten Cmdlet abzurufen, geben Sie „Get-Help“ gefolgt vom Namen des gewünschten Cmdlets ein. Mithilfe der Parameter „Detailed“, „Full“ und „Example“ können Sie bestimmen, welche Informationen ausgegeben werden. Fügen Sie diese Parameter einfach am Ende des Befehls hinzu. Wenn Sie z. B. „Get-Help Cmdlet-Name –Full“ eingeben, werden alle für das betreffende Cmdlet in der Hilfe enthaltenen Abschnitte ausgegeben.
Wenn Sie Informationen zu einem oder mehreren Parametern für ein Cmdlet abrufen möchten, können Sie „Get-Help“ mit dem Parameter „Parameters“ eingeben. Wenn Sie z. B. für das Cmdlet „Set-Mailbox“ alle Parameter und Beschreibungen anzeigen möchten, in denen das Wort „quota“ enthalten ist, geben Sie folgenden Befehl ein:
Get-Help Set-Mailbox –Parameter *quota*
Unter Umständen möchten Sie eine Liste der Cmdlets anzeigen lassen, die eine bestimmte Serverrolle oder ein bestimmtes Komponentenfeature verwalten oder mit denen Objekte über einen bestimmten Funktionalitätsbereich bearbeitet werden können. Mit dem Cmdlet „Get-Help“ können Sie dies durch drei Parameter erreichen: „Role“, „Component“ und „Functionality“. Wenn Sie das Cmdlet „Get-Help“ mit diesen Parametern verwenden, müssen Sie die Werte, die Sie mit diesen Parametern angeben, in Platzhalterzeichen ( „*“) einschließen. Das Folgende sind Beispiele dafür, wie Sie „Get-Help“ mit jedem Parameter aufrufen können:
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
Weitere Informationen finden Sie in der Hilfedatei von Exchange Server 2007 unter dem Thema „Getting Help“, unter dem alle Werte aufgeführt werden, die für „Role“, „Component“ und „Functionality“ verwendet werden können.

Formatieren der Befehlsausgabe
Wenn eine Ausgabe auf dem Bildschirm angezeigt wird, zeigt die Exchange-Verwaltungsshell standardmäßig nur eine Teilmenge der für jedes Objekt verfügbaren Eigenschaften an. Sie können jedoch leicht alle Eigenschaften abrufen, indem Sie die Ausgabe eines Befehls durch Piping an die folgenden drei Formatierungs-Cmdlets weiterleiten: „Format-List“, „Format-Table“ und „Format-Wide“. Da Sie „Format-List“ und „Format-Table“ wahrscheinlich regelmäßig verwenden werden, will ich auf diese Cmdlets speziell eingehen.
Das Cmdlet „Format-List“ nimmt die Eingabe aus der Pipeline entgegen und gibt eine senkrechte, aus Spalten aufgebaute Liste aller angegebenen Eigenschaften jedes Objekts aus. Mithilfe des Parameters „Property“ können Sie angeben, welche Eigenschaften angezeigt werden sollen. Dabei ist zu beachten, dass der Parameter „Property“ ein Positionsparameter ist, was bedeutet, dass Sie nur die Werte und nicht den Parameternamen selbst angeben müssen. Wenn das Cmdlet „Format-List“ ohne Parameter aufgerufen wird, werden alle Eigenschaften ausgegeben. Dieses Cmdlet bricht Zeilen um, statt sie abzuschneiden. Einer der besten Verwendungszwecke von „Format-List“ besteht darin, die Standardausgabe eines Cmdlets zu überschreiben, damit Sie zusätzliche oder gezieltere Informationen abrufen können. Beispiel:
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
Abbildung 3 zeigt die Ausgabe dieses Befehls.
Abbildung 3 Beispiel für die Ausgabe von „Format-List“
Abbildung 3 Beispiel für die Ausgabe von „Format-List“ (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Beispiel für die Ausgabe von „Format-List“
Abbildung 3 Beispiel für die Ausgabe von „Format-List“ (Klicken Sie zum Vergrößern auf das Bild)
Mit dem Cmdlet „Format-Table“ können Sie Elemente in einem Tabellenformat mit Bezeichnungsüberschriften und Spalten von Eigenschaftsdaten anzeigen. Standardmäßig verwenden viele Cmdlets wie z. B. „Get-Mailbox“ und „Get-JournalRule“ für ihre Ausgabe das Tabellenformat. Das Cmdlet „Format-Table“ unterstützt die Parameter „Properties“ und „GroupBy“. Diese funktionieren genau wie beim Cmdlet „Format-List“. Wenn lange Zeilen von Eigenschaftsinformationen vollständig angezeigt werden sollen, statt am Ende einer Zeile abgeschnitten zu werden, verwenden Sie den Parameter „Wrap“ wie folgt:
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
Die Ausgabe wird in Abbildung 4 gezeigt.
Abbildung 4 Beispiel für die Ausgabe von „Format-Table“
Abbildung 4 Beispiel für die Ausgabe von „Format-Table“ (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4 Beispiel für die Ausgabe von „Format-Table“
Abbildung 4 Beispiel für die Ausgabe von „Format-Table“ (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie ein Platzhalterzeichen einschließen, können Sie mehrere Eigenschaften erfassen, ohne jeden Eigenschaftsnamen einzeln angeben zu müssen. Dadurch werden z. B. alle Eigenschaften zurückgegeben, die mit „E-mail“ beginnen.
Get-Mailbox | Format-List Email*

Zeit zum Üben
Nun, da Sie einige grundlegende Befehle kennen gelernt haben, sollten Sie sich mit den folgenden Beispielen näher befassen. Diese Beispiele veranschaulichen die Leistungsfähigkeit und Vielseitigkeit der Exchange-Verwaltungsshell und geben Ihnen Gelegenheit, selbst tätig zu werden.
Mit dem Befehl, den Sie zuerst ausprobieren werden, werden 10 Benutzer namens „User1“ bis „User10“ erstellt:
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
Untersuchen wir die einzelnen Bestandteile. Mit dem Befehl „1.0“ werden die ganzen Zahlen 1 bis 10 ausgegeben und über die Pipeline dem Cmdlet „ForEach“ übergeben. Das Cmdlet „ForEach“ verarbeitet jedes eintreffende Objekt und führt dabei an jedem Objekt die in den geschweiften Klammern { } enthaltenen Befehle aus. Mit dem Befehl „Net User“ wird ein neuer Domänenbenutzer und durch das Cmdlet „Enable-Mailbox“ ein neues Postfach in der Postfachdatenbank auf dem lokalen Server erstellt. Das Semikolon trennt die beiden Befehle voneinander, damit sie in derselben Befehlszeile eingegeben werden können. Die Variable „$_“ ist eine Spezialvariable, die den Wert des Objekts enthält, das sich gerade in der Pipeline befindet. In diesem Beispiel enthält die Variable „$_“ die ganze Zahl, die sich im Moment in der Pipeline befindet.
Das nächste Beispiel ermöglicht Ihnen, die Postfächer zu sehen, die sich auf dem Server MBX befinden, und die Eigenschaft „Name“ sowie die Postfachdatenbank- und Kontingenteigenschaften jedes Postfachs abzurufen.
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Das Cmdlet „Get-Mailbox“ gibt jedes Postfach zurück, das mit dem Parameter „Server“ angegeben wird, und leitet danach die Ausgabe aus jedem Postfachobjekt über eine Pipe zum Cmdlet „Format-Table“. Standardmäßig zeigt das Cmdlet „Format-Table“ alle Eigenschaften an, die von einem Cmdlet zurückgegeben werden, es sei denn, Sie legen fest, welche Eigenschaften angezeigt werden sollen. Hier werden nur die Eigenschaften „Name“ und „Database“ sowie diejenigen Eigenschaften angefordert, in denen die Zeichenfolge „quota“ enthalten ist. Abbildung 5 zeigt, wie diese Ausgabe aussehen könnte.
Abbildung 5 Ausgabe des Befehls „Get-Mailbox“
Abbildung 5 Ausgabe des Befehls „Get-Mailbox“ (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 5 Ausgabe des Befehls „Get-Mailbox“
Abbildung 5 Ausgabe des Befehls „Get-Mailbox“ (Klicken Sie zum Vergrößern auf das Bild)
In diesem Beispiel legen Sie innerhalb der Organisation für alle E-Mail-aktivierten Benutzer, in deren Titel das Wort „Manager“ enthalten ist, die Sendekontingentgrenze auf 600 MB fest.
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
Wenn es alleine ausgeführt wird, gibt das Cmdlet „Get-User“ alle in Active Directory enthaltenen Benutzer einschließlich der Benutzer zurück, die nicht postfachaktiviert sind. Um einen Satz von Benutzerobjekten abzurufen, die vom Cmdlet „Set-Mailbox“ verwendet werden können, müssen Sie das Cmdlet „Get-User“ anweisen, nur diejenigen Active Directory-Benutzerobjekte zurückzugeben, bei denen es sich um E-Mail-aktivierte Benutzer handelt. Mithilfe des Parameters „RecipientTypeDetails“ können Sie den Active Directory-Empfängertyp (in diesem Fall „UserMailbox“) angeben. Danach müssen Sie einen Satz E-Mail-aktivierter Benutzer abrufen, die Manager sind. In diesem Beispiel wird die Eigenschaft „Title“ jedes Active Directory-Benutzerobjekts mit einem Wert gefüllt. Sie können diesen Wert verwenden, um zu ermitteln, welche Benutzer Manager sind, indem Sie mithilfe des Parameters „Filter“ den Server anweisen, nur diejenigen Active Directory-Objekte zurückzugeben, die Ihren Kriterien entsprechen. Dies wird als serverseitige Filterung bezeichnet. Sobald Sie einen Satz von Objekten erhalten haben, wird dieser Satz an das Cmdlet „Set-Mailbox“ übergeben, das anschließend für jedes Postfach die Eigenschaft „ProhibitSendQuota“ auf 600 MB festlegt.
Als Nächstes testen wir das Resultat eines Befehls zum Entfernen aller Postfächer, die einer Verteilergruppe angehören. Hier ist der Befehl dazu:
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
Das erste Cmdlet ruft die Empfängerobjekte ab, die der Verteilergruppe „Fourth Year Students“ angehören. Danach werden nur diejenigen Empfängerobjekte, die dem Empfängertyp (RecipientType) „UserMailbox“ entsprechen, an das Cmdlet „Remove-Mailbox“ weitergegeben. Statt die Postfächer zu entfernen, zeigt das Cmdlet „Remove-Mailbox“ die Aktion, die es ausgeführt hätte, und die Objekte, die das Ziel dieser Aktion gewesen wären, an. Das Cmdlet „Get-DistributionGroupMember“ ruft eine Liste aller Empfängerobjekte ab, die der Verteilergruppe „Fourth Year Students“ angehören. Es müssen jedoch alle Empfängertypen außer „UserMailbox“ herausgefiltert werden, weil das Cmdlet „Remove-Mailbox“ nur mit E-Mail-aktivierten Benutzern funktionieren kann. Im Unterschied zu einigen anderen Cmdlets besitzt das Cmdlet „Get-DistributionGroupMember“ nicht das Cmdlet „Filter“, was bedeutet, dass es keine serverseitige Filterung durchführen kann. Bei Cmdlets, die keine serverseitige Filterung durchführen können (weil kein Leistungsvorteil darin gesehen wird), können Sie das Cmdlet „Where“ verwenden, um eine clientseitige Filterung durchzuführen, bei der alle Objekte abgerufen werden und die Filterung auf dem lokalen Clientcomputer durchgeführt wird. Das Cmdlet „Where“ lässt nur Objekte durch, die den von Ihnen angegebenen Kriterien entsprechen. Die Objekte mit dem Empfängertyp (RecipientType) „UserMailbox“ werden zum Cmdlet „Remove-Mailbox“ gesendet. Dieses Cmdlet entfernt das Active Directory-Benutzerobjekt und markiert das Postfach zum Entfernen. Wenn der Parameter „WhatIf“ verwendet ist, zeigt das Cmdlet „Remove-Mailbox“ einen Text wie den folgenden an:
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
Wenn Sie damit zufrieden sind, dass der Befehl die von Ihnen gewünschten Aktionen durchführt, führen Sie den Befehl ohne „WhatIf“ erneut aus. Bei bestimmten Cmdlets wie z. B. den Cmdlets mit dem Verb „Remove“ wird die Shell automatisch eine Bestätigung verlangen, bevor Änderungen vorgenommen werden. Sie haben die Wahl, jede Änderung schrittweise abzuarbeiten, die Shell anzuweisen, keine Bestätigung mehr zu verlangen, oder die weitere Verarbeitung abzubrechen. Bei Cmdlets, die nicht automatisch eine Bestätigung implementieren, können Sie mithilfe des Parameters „Confirm“ eine Aufforderung zur Bestätigung erzwingen.

Schlussbemerkung
Nun, da Sie die Leistungsfähigkeit von Cmdlet kennen gelernt haben, können Sie durch eigene Versuche herausfinden, wie hilfreich sowohl die Exchange-Verwaltungsshell als auch Microsoft Windows PowerShell bei Ihren zukünftigen Systemverwaltungsaufgaben sein werden. Wenn Sie mehr zu beiden Themen erfahren möchten, sehen Sie sich die folgenden Ressourcen an. Informationen zur Verwaltungsshell finden Sie unter go.microsoft.com/fwlink/?LinkId=69434 in der Hilfedatei von Exchange Server 2007, im Windows Powershell-Script Center und im Exchange-Teamblog unter msexchangeteam.com.

David Strome gehört als technischer Autor seit über einem Jahr der Gruppe „Exchange User Education“ bei Microsoft an. Bevor er sich in Redmond (Washington) Microsoft anschloss, befasste sich David Strome 10 Jahre damit, in verschiedenen Unternehmen in Britisch Columbia (Kanada) Exchange Server-Installationen zu entwerfen, zu implementieren und zu verwalten. Sie können ihn unter dstrome@microsoft.com erreichen.


 Exchange Server 2007: Exchange &amp; Outlook: Gemeinsam besser
Exchange Server 2007 Michael Khalili

Exchange & Outlook: Gemeinsam besser
Kurz zusammengefasst:
  • Vereinfachtes Setup
  • Integration von Voicemail, Fax und E-Mail
  • Verwaltete Ordner für Konformität

Seit vielen Jahren bereits werden Microsoft Exchange Server und Outlook von Millionen von Menschen nicht nur für die zuverlässige Zustellung ihrer E-Mails, sondern auch zur Planung der Zusammenarbeit mit anderen Personen, zur Verwaltung von Kalendern und zum Organisieren von Kontakten verwendet. Einige werden sich fragen, was dieses Erfolgsduo als Zugabe zu bieten haben könnte. Exchange Server 2007
und Microsoft Office Outlook 2007 stehen kurz vor der Veröffentlichung. Die Kombination dieser beiden Anwendungen stellt einen Quantensprung im Bereich der Kommunikation und Zusammenarbeit dar.
Die Verbesserungen, die von Exchange Server 2007 und Office Outlook® 2007 angeboten werden, sind sofort nach dem Starten des Outlook-Clients offensichtlich. In bisherigen Versionen hat Outlook erwartet, dass Sie den Namen Ihres Exchange-Postfachservers kennen, was viele Benutzer überfordert hat. Das Ergebnis waren häufige Anrufe beim Helpdesk oder komplizierte Initialisierungsskripts, was zu erhöhten Kosten und größerer Komplexität bei der Ausführung einer effizienten Messagingumgebung führte. Mit dem neuen Exchange Autodiscover-Webdienst ist Outlook in der Lage, das Konto automatisch zu konfigurieren, wenn der Client mit der Domäne verbunden ist. Wenn der Client nicht mit der Domäne verbunden ist, braucht der Benutzer nur einen Namen, eine E-Mail-Adresse und ein Kennwort einzugeben. Outlook und Exchange übernehmen alles Weitere selbsttätig (siehe Abbildung 1).
Abbildung 1 Einrichten von Konten
Abbildung 1 Einrichten von Konten (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Einrichten von Konten
Abbildung 1 Einrichten von Konten (Klicken Sie zum Vergrößern auf das Bild)
Gleichermaßen musste Outlook früher von den Benutzern nicht nur für die erstmalige Verwendung eingerichtet, sondern auch bei jedem Wechsel zu einem anderen E-Mail-Server neu konfiguriert werden. Selbst wenn Benutzer per E-Mail über den bevorstehenden Wechsel ihres Postfach informiert wurden, wurde dies von vielbeschäftigten Mitarbeitern häufig ignoriert, bis sie eines Morgens ins Büro kamen und keinen Zugang zu Outlook mehr hatten. An dieser Stelle musste erneut der Helpdesk in Aktion treten. Der Autodiscover-Webdienst löst auch dieses Problem. Wenn ein Benutzer von einem Postfachserver an einen anderen verschoben wird, erkennt Outlook, dass die alte Konfiguration nicht mehr gültig ist, fragt den Autodiscover-Webdienst erneut ab und konfiguriert dann den Client für das neue Postfach. Das gesamte Verfahren ist für den Endbenutzer vollständig transparent.

Neuerfindung des Kalenders
In der Vergangenheit war ein Großteil der Kalenderlogik in Outlook integriert. Jede Aktualisierung einer Besprechung wurde als separate Besprechungseinladung behandelt, und dies bedeutete, dass Benachrichtigungen möglicherweise in der falschen Reihenfolge angenommen wurden. Wenn zwei Besprechungsaktualisierungen kurz hintereinander gesendet wurden und ein Empfänger die zweite Aktualisierung vor der ersten akzeptiert hatte, enthielt sein Kalender möglicherweise veraltete Informationen. Der Zugriff auf Outlook-Informationen von Smartphones oder PDAs aus konnte darüber hinaus je nach Methode, mit der die Daten von den Benutzern angezeigt wurden, zu abweichenden Informationen in Bezug auf freie oder nicht verfügbare Zeiten führen.
Dies ist nun behoben worden, indem die gesamte Kalenderlogik vom Outlook-Client auf Exchange Server 2007 übertragen wurde. Wenn der Server nun eine Besprechungsanfrage empfängt, wird die Besprechung automatisch zunächst mit dem Status „Mit Vorbehalt“ in den Kalender eingetragen, bis der Benutzer auswählt, ob er den Termin annehmen oder ablehnen möchte. Wenn eine Zeit- oder Ortsänderung für die Besprechung empfangen wird, wird die Besprechung automatisch aktualisiert und die alte Einladung als veraltet markiert, sodass Benutzer sie nicht versehentlich annehmen können. Diese Logik wird von allen Clients angewendet, d. h. von Office Outlook, Outlook Web Access, Outlook Mobile oder anderen Clients von Drittanbietern, damit nur die korrekten und aktuellsten Besprechungen im Kalender enthalten sind.
Der Kalender ist damit zuverlässig und genau, und es ist möglich, einen neuen Satz von Tools anzubieten, mit denen die Benutzer noch produktiver werden können. In der Vergangenheit war es nicht leicht, Besprechungen mit mehreren vielbeschäftigten Mitarbeitern zu planen. Benutzer mussten freie Zeiten für Besprechungen manuell finden und dabei häufig viele Tage durchblättern, bis eine passende Zeit für alle Teilnehmer gefunden werden konnte. Nun kann der Planungsassistent von Outlook 2007, der in Abbildung 2 dargestellt wird, den für jeden Teilnehmer optimalen Zeitpunkt ermitteln. Nachdem Sie die erforderlichen und optionalen Teilnehmer sowie ggf. die gewünschten Räumlichkeiten oder Ressourcen eingegeben haben, zeigt der Planungsassistent eine farblich kodierte Ansicht der besten Tage für eine Besprechung an. Nach der Auswahl eines Tages wird dasselbe Schema verwendet, um an diesem Tag die beste Uhrzeit zu finden.
Abbildung 2 Planungsassistent
Abbildung 2 Planungsassistent (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Planungsassistent
Abbildung 2 Planungsassistent (Klicken Sie zum Vergrößern auf das Bild)
Der Planungsassistent setzt Prioritäten zunächst für erforderliche Teilnehmer, dann für optionale Teilnehmer und schließlich für Räumlichkeiten und Ressourcen, um die optimale Zeit für eine Besprechung zu bestimmen. Der Planungsassistent vereinfacht auch die Berücksichtigung flexibler Arbeitszeiten und verschiedener Zeitzonen. Benutzer können ihre eigenen Arbeitszeiten festlegen, indem sie ihren täglichen Arbeitsbeginn und ihr Arbeitsende definieren. Daher können Personen, die erst um 9 oder 10 Uhr zur Arbeit kommen, den Beginn ihrer Arbeitszeit entsprechend festlegen. Wenn andere Personen eine Besprechung mit diesem Mitarbeiter planen müssen, wird kein früherer Zeitpunkt, wie z. B. 8 Uhr, vorgeschlagen. Für Besprechungen, deren Teilnehmer in verschiedenen Zeitzonen wohnen (beispielsweise in Berlin und New York), werden nur Zeiten vorgeschlagen, die sich für alle Teilnehmer innerhalb der Arbeitszeiten befinden. Für die Teilnehmer in Berlin wird die Besprechung am Nachmittag geplant, wenn für die Teilnehmer in New York der Arbeitstag erst anfängt. Es wird kein Zeitpunkt vorgeschlagen, an dem es für einen der Teilnehmer erst 2 Uhr morgens ist.

Die Nadel im Heuhaufen
Im Laufe der Jahre ist die Anzahl der E-Mail-Nachrichten, die im Posteingang des durchschnittlichen Benutzers ankommen, mit alarmierender Geschwindigkeit gestiegen. Während ein typisches Postfach am Arbeitsplatz früher nur ein paar hundert Nachrichten umfasste, erhalten einige Mitarbeiter jetzt so viele Nachrichten an einem einzigen Tag. Irgendwo in dieser Nachrichtenlawine sind die wichtigen Informationen vergraben, die für Geschäftsabläufe unverzichtbar sind. Das Auffinden der richtigen Informationen genau zum benötigten Zeitpunkt kann eine Herausforderung darstellen.
Die Suchfunktionen von Office Outlook 2007 und Exchange Server 2007 wurden gegenüber den Vorgängerversionen erheblich verbessert. Unabhängig davon, ob ein Benutzer im zwischengespeicherten Modus oder im Online-Modus arbeitet, werden die gleichen Suchalgorithmen auf die Nachricht angewendet. Im Online-Modus wird die Suchabfrage an den Exchange Server gesendet, wo die Suche ausgeführt wird. Die Exchange-Inhaltsindexerstellung, die bis zu 35-mal schneller als die Indexerstellung in Exchange Server 2003 ausgeführt wird, gewährleistet, dass Nachrichten schnell gefunden und abgerufen werden können. Im zwischengespeicherten Modus verwendet Outlook die Sofortsuche, die auf der Windows® Desktopsuche 3.0 basiert, um die Indizierungsmodule zu vereinen und die CPU-Zeit zu reduzieren. Sie können eine Textsuche im Betreff, im Nachrichtentext, in den Felder „An“ und „Von“ und sogar in Anlagen durchführen (siehe Abbildung 3).
Abbildung 3 Neue Wege bei der Suche nach wichtigen E-Mail-Nachrichten
Abbildung 3 Neue Wege bei der Suche nach wichtigen E-Mail-Nachrichten (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Neue Wege bei der Suche nach wichtigen E-Mail-Nachrichten
Abbildung 3 Neue Wege bei der Suche nach wichtigen E-Mail-Nachrichten (Klicken Sie zum Vergrößern auf das Bild)

Zugriff von überall mit Unified Messaging
Exchange Unified Messaging ist eine integrierte Komponente von Exchange Server 2007, die alle Arten von Geschäftskommunikation in einem einzelnen Posteingang vereint, einschließlich E-Mail, Voicemail und Fax. In traditionellen Systemen werden Voicemails über das Telefon, E-Mails über den Computer und Faxe über ein dediziertes Faxgerät ausgetauscht. Exchange Unified Messaging ermöglicht dem Benutzer die Auswahl des besten Clients für seine Bedürfnisse zum jeweiligen Zeitpunkt und am jeweiligen Ort. In Outlook werden Voicemail- und Faxnachrichten im Posteingang direkt neben E-Mail-Nachrichten angezeigt. Wenn die Voicemailnachricht ausgewählt wird, enthält sie einen eingebetteten Player, mit dem die Nachricht direkt im Lesebereich wiedergegeben werden kann (siehe Abbildung 4).
Abbildung 4: Wiedergabe von Voicemailnachrichten in Outlook
Abbildung 4: Wiedergabe von Voicemailnachrichten in Outlook (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4: Wiedergabe von Voicemailnachrichten in Outlook
Abbildung 4: Wiedergabe von Voicemailnachrichten in Outlook (Klicken Sie zum Vergrößern auf das Bild)
Outlook ermöglicht auch die Behandlung von Nachrichten im Kontext. Viele Personen schreiben beim Abhören von Voicemail kurze Notizen auf ein Blatt Papier. Diese Notizen sind nicht mit der Voicemailnachricht verknüpft und können verloren gehen – kein gutes Modell für eine effiziente Kommunikation. Mit Exchange Unified Messaging können Sie Notizen direkt in Outlook aufschreiben. Die Notizen bleiben der Nachricht zugeordnet und werden als suchbarer Text indiziert. Dies gewährleistet, dass die Notizen immer im Kontext der entsprechenden Voicemailnachricht angezeigt werden. Auf diese Weise können sie mit der verbesserten Suchfunktion von Exchange Server 2007 und Office Outlook 2007 rasch gefunden werden.
Outlook kann auch zahlreiche Voicemailoptionen verwalten (siehe Abbildung 5). Mit einer dieser Funktionen sind Benutzer in der Lage, die persönliche Identifikationsnummer (PIN) ihres Voicemailpostfachs direkt innerhalb des Clients zu ändern. (Bei Voicemailsystemen ist das Zurücksetzen von PINs einer der Hauptgründe für Helpdeskanrufe.) Benutzer können über ihre Optionen in Outlook eine neue PIN generieren und sich per E-Mail zuschicken lassen. Mit dieser PIN erhalten sie einmaligen Zugriff auf die Telefonschnittstelle von Exchange Unified Messaging, Outlook Voice Access, und werden dann aufgefordert, ihre PIN zu ändern.
Abbildung 5: Unified Messaging umfasst eine Funktion zum Zurücksetzen der PIN
Abbildung 5: Unified Messaging umfasst eine Funktion zum Zurücksetzen der PIN (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 5: Unified Messaging umfasst eine Funktion zum Zurücksetzen der PIN
Abbildung 5: Unified Messaging umfasst eine Funktion zum Zurücksetzen der PIN (Klicken Sie zum Vergrößern auf das Bild)

Sichern und schützen
Organisationen stehen heute vielen Bedrohungen für ihre Messagingumgebung gegenüber. Outlook und Exchange arbeiten zusammen, um gegen diese Bedrohungen vorzugehen. Spam ist nur eine dieser Bedrohungen, und Office Outlook 2007 unterstützt nun Outlook-E-Mail-Poststempel, eine neue Methode zum Bekämpfen von Spam. Outlook führt an ausgehender Post ein kleines Rechenrätsel durch und fügt die Antwort zu diesem Rätsel der Nachricht bei. Exchange überprüft dann diese Antwort. Dieses Rätsel nimmt relativ wenig CPU-Zeit in Anspruch, wenn es nur einmal pro Nachricht ausgeführt wird, wie das bei legitimer E-Mail der Fall wäre. Wenn allerdings der Computer eines Spammers dieses Rätsel für Massensendungen erstellen müsste, würde dies enorme Computerressourcen beanspruchen. Daher sind Nachrichten mit einem Outlook-E-Mail-Poststempel mit viel größerer Wahrscheinlichkeit legitim als Nachrichten ohne Poststempel, und Exchange berücksichtigt dies beim Bestimmen der Gültigkeit von E-Mail-Nachrichten.
Zusätzlich zu alten Bedrohungen wie Spam stellen neue gesetzliche Vorschriften neue Anforderungen an Nachrichtensysteme. Vorschriften wie Sarbanes-Oxley, HIPPA und Basel II enthalten strenge Regeln für die Speicherung oder Zerstörung von Datensätzen. Um diesem neuen Bedürfnis gerecht zu werden, unterstützen Exchange und Outlook nun verwaltete Ordner. Diese Ordner werden von einem Administrator für Nachrichten eines bestimmen Typs eingerichtet. In Outlook werden diese Ordner dem Endbenutzer mit einer Beschreibung der Inhalte angezeigt, die im Ordner gespeichert werden sollten (siehe Abbildung 6). Nachrichten können unter Verwendung der Exchange-Transportregeln auch automatisch in einen bestimmten Ordner gesendet werden. Nach dem Ablegen der Nachrichten in einem bestimmten verwalteten Ordner behalten die Nachrichten die Archivierungs-, Speicherungs- und Ablaufrichtlinien des entsprechenden Ordners bei und werden automatisch im Einklang mit der Richtlinie der Organisation behandelt.
Abbildung 6: Verwaltete Ordner erzwingen Konformitätsregeln für E-Mail
Abbildung 6: Verwaltete Ordner erzwingen Konformitätsregeln für E-Mail (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 6: Verwaltete Ordner erzwingen Konformitätsregeln für E-Mail
Abbildung 6: Verwaltete Ordner erzwingen Konformitätsregeln für E-Mail (Klicken Sie zum Vergrößern auf das Bild)
Trotz bester Bemühungen finden gelegentlich Konformitätsverstöße statt. In diesen Fällen ist die schnelle Identifikation und Behebung unumgänglich. Die von Exchange angebotene schnelle Suche wird zu einem zentralen Tool für Konformitätsprüfer, um Nachrichten zu finden, die Anhaltspunkte für die Identifikation von Konformitätsverstößen enthalten könnten. Die Suche kann über mehrere Postfächer hinweg durchgeführt werden, um solche Verstöße zu erkennen und zu korrigieren.

Eine leichter zu verwaltende Umgebung
Zusammen bilden Exchange Server 2007 und Office Outlook 2007 ein stark verbessertes Nachrichtensystem im Vergleich zu vorherigen Versionen. Die beiden Anwendungen vereinen die gesamte wichtige Geschäftskommunikation an einem Ort und ermöglichen eine einfache Suche und problemlose Einrichtung bei erhöhter Sicherheit und Kompatibilität ohne zusätzliche Konfiguration. Zusammen bieten sie ein höheres Level der Zusammenarbeit und Kommunikation.

Michael Khalili ist Produktmanager für Exchange Server und verantwortlich für Clientzugriff und Unified Messaging. Er ist unter anderem für die Integration von Outlook und Exchange verantwortlich.


 Exchange Server&#160;2007: Immer in Verbindung mit Exchange&#160;2007
Exchange Server 2007 Joshua Trupin

Immer in Verbindung mit Exchange 2007
Kurz zusammengefasst:
  • Verbesserungen an Outlook Web Access
  • Unified Messaging in Exchange Server 2007
  • Sicherheit mit ISA Server 2006

In der Vergangenheit war Onlinekommunikation einfach. E-Mails wurden über POP3 und SMTP gesendet. Aber Anforderungen ändern sich natürlich. Heutzutage müssen Unternehmen ihren Arbeitnehmern die
Flexibilität bieten, zu selbst gewählten Arbeitszeiten und an einem selbst gewählten Standort zu arbeiten, und dies auf sichere Weise. Microsoft® Exchange Server 2007 verfügt über mehrere integrierte Features, die diese Anforderungen erfüllen, einschließlich Microsoft Office Outlook® Web Access (OWA) und Unified Messaging. Im Folgenden werden diese beiden Schlüsselkomponenten von Exchange Server 2007 vorgestellt und ihre Vorzüge gegenüber den früheren Versionen beschrieben, dank derer eine deutlich leistungsfähigere Kommunikationsplattform für die Unternehmen von heute entstanden ist.
OWA ist Teil von Exchange seit Version 5.5. Um ehrlich zu sein, waren die ersten Versionen ein bisschen umständlich. Sie waren eine Antwort auf das Problem des Zugriffs auf ein Exchange-Postfach mit einem Webbrowser, dies jedoch mit sehr viel weniger Funktionalität, als von Outlook geboten wurde.
Mit dem verbesserten OWA, der von Exchange Server 2003 geboten wurde, begann sich das Blatt für Endbenutzer zu wenden. Die browserbasierte Erfahrung wurde sehr viel natürlicher, als ob Sie in einem Clientprogramm arbeiten würden. OWA für Exchange Server 2007 geht sogar einen Schritt weiter, mit einer vollständigen Überarbeitung früherer Versionen, die die Nutzung anderer neuer technischer Errungenschaften ermöglichen, wie RPC-über-HTTP und ASP.NET 2.0.
Bedenken Sie zum Beispiel, wie OWA sein Rendering durchführt. Frühere Versionen von OWA wurden vom Postfachserver während des Speichervorgangs gerendert. Dies stellte eine zusätzliche Belastung des Postfachservers dar und führte potenziell zu Verlangsamungen im System. Im Gegensatz dazu rendert Outlook Web Access 2007 Daten über ASP.NET auf Clientzugriffsservern (Client Access Servers, CAS). Dadurch wird die Seitenverarbeitung unabhängig vom Postfachserver durchgeführt, was zu einer Verbesserung der Leistung führt.
Die Arbeit, die auf dem Front-End durchgeführt wird, wurde ebenfalls geändert. In früheren Exchange-Versionen wurden die OWA-HTTP-Anforderungen dem entsprechenden Postfachserver übergeben. Exchange Server 2007 verringert mit OWA in Zusammenhang stehenden Datenverkehr, indem Daten direkt vom entsprechenden Postfachserver über RPC abgerufen werden. Dabei handelt es sich mehr oder weniger um den gleichen Vorgang, der Ihnen die Verwendung von Outlook auf einem Client ermöglicht, der nicht mit einem virtuellen privaten Netzwerk (VPN) in Ihrem Unternehmen verbunden ist. Die Postfachinformationen werden daraufhin von OWA gerendert. Exchange Server 2007 kann auch OWA-Anforderungen übergeben, aber statt diese direkt an Postfachserver zu senden, werden sie an andere Clientzugriffsserver weitergeleitet.
Abbildung 1 zeigt die Architektur von OWA unter Exchange Server 2007.
Abbildung 1 So greift OWA auf Exchange Server-Ressourcen zu
Abbildung 1 So greift OWA auf Exchange Server-Ressourcen zu (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 So greift OWA auf Exchange Server-Ressourcen zu
Abbildung 1 So greift OWA auf Exchange Server-Ressourcen zu (Klicken Sie zum Vergrößern auf das Bild)

Verwaltung
Die überarbeitete Architektur von Exchange Server 2007 umfasst erweiterte Optionen für die Verwaltung von OWA. Sie können die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell verwenden. Konfigurationseinstellungen werden an mehreren Orten gespeichert.
Mit der Exchange-Verwaltungskonsole können Sie auf die meisten möglichen Konfigurationseinstellungen zugreifen, wie z. B. das Aktivieren oder Deaktivieren von Features, die Segmentierung, Anlagensperre und Authentifizierung verwenden, sowie das Zugreifen auf Features wie den Kalender, die Aufgabenliste und die Rechtschreibprüfung. Alles, was in der Exchange-Verwaltungskonsole durchgeführt werden kann, kann auch mithilfe von Exchange-Verwaltungsshellaufgaben getan werden.
Zusätzlich ermöglicht die Exchange-Verwaltungsshell das Erstellen und Löschen neuer virtueller Verzeichnisse für OWA. Sie können u. a. auch eine bessere Kontrolle über Einzelbenutzer-Segmentierungseinstellungen erreichen und die Standardspracheinstellung ändern.
Die Windows-Registrierung ist der Standardspeicher für formularbasierte Authentifizierungstimeouts. (Diese Einstellungen sind nicht über die Exchange-Verwaltungskonsole oder die Exchange-Verwaltungsshell verfügbar.) Sie können über Active Directory® auf OWA-spezifische Einstellungen wie die Anlagensperre und die Segmentierung zugreifen. Die IIS-Metabasis enthält alle Einstellungen (Authentifizierung, GZIP), die das Verhalten von IIS beeinflussen. Web.config enthält ASP.NET-Einstellungen wie z. B. „maxuploadsize“, die das Hochladen von OWA-Anlagen steuert.

Authentifizierung
OWA bietet mehrere Auswahlmöglichkeiten für die Authentifizierung am Server. Nach dem Setup ist die Standardeinstellung für die Sicherheit die formularbasierte Authentifizierung. Dies kann auf verschiedene Arten je nach den Anforderungen Ihres Unternehmens gesteigert werden. IIS führt eine Authentifizierung bei Active Directory durch, um sicherzustellen, dass der betreffende Benutzer über Domänenrechte verfügt. Sie können auch Standardauthentifizierung, Digestauthentifizierung, RSA SecurID oder sogar SmartCard-Anmeldung für den Zugriff auf E-Mails verwenden.
Die höchste Sicherheit für OWA bietet die integrierte Sicherheit von Windows, die Kerberos und NTLM kombiniert. Die integrierte Sicherheit von Windows ist für Outlook Web Access 2007-Webpartzugriff sowie für CAS-Proxyvorgänge zwischen Active Directory-Standorten erforderlich. Sie bietet zudem zusätzliche Vorteile für Benutzer, die auf OWA in einem Intranet zugreifen. Es bietet einmaliges Anmelden mit Windows-Clientauthentifizierung, wodurch Sie sich nicht bei OWA anmelden müssen, wenn Sie bereits ein vertrauenswürdiger Benutzer sind.
Wenn Sie formularbasierte Authentifizierung, also die Standardeinstellung, verwenden, wird OWA nach einem bestimmten Zeitraum der Inaktivität aufgrund einer Zeitüberschreitung beendet. Je nach Wahl des Benutzers eines öffentlichen oder privaten Computers (wenn bei der Anmeldung gefragt) kann das Timeout 15 Minuten (bei öffentlichen Computern) oder 8 Stunden (bei privaten Computern) betragen. Die Wahl eines öffentlichen statt eines privaten Computers ist wichtig für Ihre Benutzer, da andere Sicherheitseinstellungen in Abhängigkeit von dieser Einstellung auch anders konfiguriert sein können. Sie können beispielsweise Anlagen auf öffentlichen Rechnern sperren oder Authentifizierungstimeouts ändern. Formularbasierte Authentifizierung ist im Grunde ein Vorgang in vier Schritten wie in Abbildung 2 gezeigt.
Abbildung 2 Authentifizierungsvorgang
  1. Clients senden eine unverschlüsselte Anforderung an den Server.
  2. Server senden ein verschlüsseltes Cookie zurück an den Client.
  3. Server fahren mit dem Verwerfen und Erstellen neuer Schlüssel fort und behalten die drei neuesten Schlüssel im Speicher.
  4. Clients, die Anforderungen mit einem veralteten Schlüssel senden, der sich noch im Speicher befindet, erhalten ein neues Cookie, das mit dem neuesten Schlüssel verschlüsselt ist.
    Oder
    – Clients, die Anforderungen mit einem veralteten Schlüssel senden, der verworfen und gelöscht wurde, müssen sich neu anmelden.

msExchQueryBaseDN ist die Methode, mit der bestimmten Benutzern lediglich die Anzeige eines Unterabschnitts des Adressbuchs in OWA ermöglicht wird. msExchQueryBaseDN ist auf Active Directory-Benutzerobjekte gestempelt und zeigt auf eine Adressliste (AL) oder eine Organisationseinheit (OU). Diese AL wird als globale Adressliste (GAL) für den Benutzer verwendet, und der Benutzer bekommt eine GAL angezeigt, die lediglich Benutzerkonten in dieser OU enthält. Sie können msExchQueryBaseDN mithilfe von LDAP festlegen.

Abwärtskompatibilität
Das Kernstück von Outlook Web Access in Exchange Server 2007 ist der CAS, und das CAS-Modell wurde erstellt, um die bestmögliche Interoperabilität mit Servern bereitzustellen, die frühere Versionen von Exchange ausführen. Um sicherzustellen, dass dies funktioniert, sollten Sie Ihre Clientzugriffsserver immer bereitstellen oder aktualisieren, bevor Sie ihre verknüpften Postfachserver aktualisieren.
Ein Exchange 2007-Server mit der CAS-Rolle kann für eine Verbindung mit Postfächern auf Exchange 2000- und Exchange 2003-Servern verwendet werden. RPC-über-HTTP und Exchange ActiveSync® funktionieren beide weiterhin mit einer teilweisen Siteaktualisierung. OWA und WebDAV funktionieren auch, wenn Sie auf sie über die virtuellen Verzeichnisse /exchange, /public oder /exchweb zugreifen. Sie können benutzerdefinierte virtuelle OWA-Verzeichnisse ebenso für diese früheren Versionen auf Exchange Server 2007 erstellen.

ISA Server 2006 ist Ihr Freund
Outlook Web Access beinhaltet erhebliche Verbesserungen an Exchange Server 2007, kann jedoch noch weiter verbessert werden durch eine Verbindung mit Internet Security and Acceleration (ISA) Server 2006.
ISA Server 2006 ist ein integriertes Edgesicherheitsgateway. Während es Ihre Site vor Gefahren aus dem Internet schützt, bietet es gleichzeitig sicheren Remotezugriff auf Anwendungen und Daten. Da dies auch das Ziel von OWA ist, ergibt die Kombination dieser beiden das beste aller Computerkonzepte: Synergie. (Weitere Informationen zu ISA Server finden Sie unter microsoft.com/isaserver/2006.)
ISA Server 2006 bietet dem gequälten Exchange-Administrator mehrere Vorteile. Zum Beispiel können Sie mit dem Feature „Web Publishing Load Balancing“ (WPLB, Webpublishing-Lastenausgleich) Lasten mithilfe von Cookies ausgleichen. Sie können eine Clientserveraffinität sicherstellen, selbst wenn sich die Client-IP ändert. ISA Server 2006 bietet außerdem GZIP-Komprimierung und -Dekomprimierung, mit der Sie Datenverkehr analysieren oder Komprimierung auf Webservern vermeiden können. Mit ISA Server 2004 mussten Sie eine Entscheidung treffen: Sie konnten entweder HTTP-Komprimierung mit OWA oder formularbasierte Authentifizierung mit ISA Server verwenden. Zum Glück unterstützt ISA Server 2006 beides gleichzeitig.
Zusätzlich können Sie OWA-Linkübersetzung über ISA Server durchführen. Wenn jemand in einer OWA-E-Mail einen Intranetlink verwendet, kann ISA Server diesen in einen richtigen Internetlink übersetzen. Dies kann recht nützlich sein, aber Sie müssen dabei sicherstellen, dass Sie die Intranetlinks in demselben ISA-Array veröffentlichen, das OWA veröffentlicht.
Am wichtigsten dabei ist vielleicht, dass ISA Server 2006 eine Vorauthentifizierung durchführt, um Ihr Netzwerk im Umkreis zu schützen. Durch die Vorauthentifizierung soll sichergestellt werden, dass kein nicht autorisierter HTTP-Datenverkehr Ihre Server erreicht. Wenn der Datenverkehr, der zu Ihrem CAS geleitet wird, tatsächlich gültig ist, wird ISA Server ihn vom Umkreis zur Domäne leiten. (Umkreisserver befinden sich außerhalb der Intranetdomäne und blockieren Datenverkehr, der dort nicht hingehört. Ihr CAS sollte in der Umkreisdomäne nicht bereitgestellt werden. Es muss sich stattdessen in der Intranetdomäne befinden, damit es auf Active Directory-Benutzerkonten zugreifen kann.)

Problembehandlung in Outlook Web Access
Outlook Web Access 2007 beinhaltet neue Tools, die die Überwachung und Problembehandlung verbessern. Eine Überwachungsaufgabe wird automatisch auf dem Clientzugriffsserver ausgeführt. Die Aufgabe testet die Konnektivität für jeden Postfachserver sowie OWA-Anmeldungen. Exchange Server 2007 bietet außerdem sehr viel detailliertere Ereignisprotokollmeldungen und Leistungsindikatoren.
Der Exchange Server Best Practices Analyzer (siehe unter microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange) ist verbessert worden, um Administratoren auf relevante Warnungen und Fehler hinzuweisen, wenn OWA nicht richtig konfiguriert ist. Sie können auch OWA-Verwendungsberichte aus IIS-Protokollen über das LogParser-Tool erstellen (siehe Oktoberausgabe 2006 unter microsoft.com/technet/technetmag/issues/2006/10/LogParser).

Unified Messaging
Während OWA die Anforderungen des mobilen Geschäfts behandelt, konsolidiert Unified Messaging verschiedene Formen der Nachrichtenverarbeitung an einem einheitlichen Ort. E-Mails befinden sich jetzt auf Exchange Server. Sprache (Anrufe, Voicemail) ist auf einem Telefonieserver verfügbar. Sie rufen Ihre E-Mails über Ihren Desktop und Voicemail über Ihr Telefon ab. Ganz zu schweigen von Faxnachrichten!
Mit dem Unified Messaging von Exchange Server 2007 kann ein Unternehmen E-Mail-, Sprach- und Faxdaten an ein einziges Postfach senden, auf das Benutzer über Outlook und OWA zugreifen können. Unified Messaging bietet noch weitere Funktionen: Benutzer können auf Voicemail, E-Mails, Kontakte und Kalender über das Telefon mittels Outlook Voice Access zugreifen.
Für die Systemadministration vereinfacht Unified Messaging die Nachrichtenverarbeitung durch Kombination Ihrer Exchange- und Telefonieinfrastrukturen, um Ihnen eine einzige Speicherlösung, ein einziges Verzeichnis und ein einziges Transportmittel zu bieten. Der Grad der Komplexität wird verringert, wenn jede Person über ein einziges Postfach verfügt.
Das Beste daran ist jedoch, dass diese Lösung mit Ihren vorhandenen Servern realisiert werden kann, und wenn Sie sich mit Exchange Server 2007 und Telefonie auskennen, ist der Lernprozess ziemlich einfach. Die Features von Unified Messaging sind in Exchange integriert – Sie verwenden also dasselbe Sicherheitsmodell und dieselben Postfächer. Sie können sogar auf Ihre Voicemail und Faxe über OWA zugreifen.
Abbildung 3 zeigt die Architektur des Unified Messaging in Exchange Server 2007 mit installiertem Unified Messaging-Server. Sehen Sie es sich gut an (möglicherweise gibt es später ein Quiz), und betrachten Sie die Unified Messaging-Architektur im Detail.
Abbildung 3 Unified Messaging bringt Sprach-, Fax- und E-Mail-Kommunikation zusammen
Abbildung 3 Unified Messaging bringt Sprach-, Fax- und E-Mail-Kommunikation zusammen (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Unified Messaging bringt Sprach-, Fax- und E-Mail-Kommunikation zusammen
Abbildung 3 Unified Messaging bringt Sprach-, Fax- und E-Mail-Kommunikation zusammen (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie Unified Messaging in einem Unternehmen einrichten, muss auf zahlreiche Aspekte geachtet werden. Exchange Server enthält Objekte, die Telefoniehardware darstellen. Für diese Objekte können daraufhin Beziehungen innerhalb der Exchange Server-Umgebung definiert werden. Zu den Systemobjekten von Unified Messaging in Exchange Server gehören der UM-Server, der UM-Wählplan, das UM-IP-Gateway und der UM-Sammelanschluss sowie die UM-Postfachrichtlinie und die automatische UM-Telefonzentrale. Werfen Sie einen Blick darauf, wie jedes dieser Objekte seine Existenz rechtfertigt.
Das UM-Serverobjekt wird in Active Directory erstellt, wo die UM-Serverrolle installiert ist. Damit kann ein Administrator das Setup und die Eigenschaften der Bereitstellung des Exchange Server 2007-Unified Messaging steuern. Der UM-Wählplan ist die grundlegende Verwaltungseinheit innerhalb von Unified Messaging und stellt dar, wie Durchwahlen intern verwendet werden. Alle Benutzer innerhalb eines Wählplans erreichen andere Personen durch einfaches Wählen ihrer Durchwahl. Wenn Sie andere Standorte bündeln, verfügt meist jeder über seinen eigenen Wählplan.
Das UM-IP-Gateway-Objekt stellt ein physisches VoIP-Gateway oder eine SIP-fähige private IP-Nebenstellenanlage (PBX) dar. Ein Unified Messaging-Server kann Anrufe von einem IP/VoIP-Gatewaygerät empfangen. Ein UM-Sammelanschluss verknüpft ein IP-Gateway mit einem UM-Wählplan. Nachdem ein Sammelanschluss an der PBX konfiguriert wurde, wird ein UM-Sammelanschluss in Active Directory erstellt, um dies darzustellen. Sie können den Sammelanschluss konfigurieren, um einen Lastenausgleich über IP-Gateways hinweg zu bieten. Diese Gateways können wiederum einen Lastenausgleich durch Verknüpfen eines einzelnen UM-Sammelanschlusses mit mehreren Gateways bieten. UM-Postfachrichtlinien sind ähnlich wie Voicemail-Dienstklassen. Sie beinhalten einen Wählplan und Eigenschaften, die Betriebsrichtlinien für Benutzer und Gruppen festlegen.
Die automatische UM-Telefonzentrale kann mit einem einzelnen UM-Wählplan verknüpft werden. Er kann für die Durchführung unterschiedlicher Aufgaben angepasst werden, wie benutzerdefinierte Eingabeaufforderungsaufzeichnung und Definition von Aufgaben für unterschiedliche Tage und Zeiten. Automatische Telefonzentralen können mithilfe von Adresslisten begrenzt werden.
Abbildung 4 zeigt, wie diese sechs Unified Messaging-Objekte zusammenarbeiten.
Abbildung 4 Interaktion von Unified Messaging-Telefonieobjekten
Abbildung 4 Interaktion von Unified Messaging-Telefonieobjekten (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4 Interaktion von Unified Messaging-Telefonieobjekten
Abbildung 4 Interaktion von Unified Messaging-Telefonieobjekten (Klicken Sie zum Vergrößern auf das Bild)

Setup
Wenn ein Benutzer über ein Exchange Server 2007-Postfach verfügt, muss der Administrator es für Unified Messaging aktivieren. Zu diesem Zweck muss der Administrator das Postfach mit einer UM-Postfachrichtlinie und einer Durchwahlnummer, beide innerhalb des Wählplans, verknüpfen. Die PBX muss auch konfiguriert werden, um den Anruf an Unified Messaging im Falle eines RNA (Rufton, keine Antwort) weiterzuleiten. Die PBX leitet den Anruf zunächst an die Durchwahl des Benutzers weiter. Wenn es daraufhin zu einem RNA kommt, wird der Anruf an das VoIP-Gateway und daraufhin an den Unified Messaging-Server weitergeleitet.
Unified Messaging ist skalierbar. Sie können so viele leitungsvermittelte PBX-Kanäle und UM-Server hinzufügen, wie Sie benötigen. Wenn Sie VoIP-Gateways verwenden, werden IP-basierte Anrufe an Exchange-Unified Messaging geleitet. Da dies eine neue Funktionalität für viele Unternehmen darstellt, sollten Sie eine vollständige Netzwerkanalyse durchführen, um sicherzustellen, dass Ihr IP-Netzwerk über die erforderliche Bandbreite verfügt, um sowohl Daten als auch Sprache zu verarbeiten.
Ein typischer Exchange Server 2007-Unified Messaging-Server kann zwischen 50 und 200 IP-Anrufen gleichzeitig verarbeiten und bis zu 200 eingehende Sprach- und Faxanrufe (diese sind standardmäßig auf 100 eingestellt). Sie können weitere Unified Messaging-Server hinzufügen, wenn Sie mehr Kapazität benötigen oder wenn Sie Ihre Fehlertoleranz erhöhen möchten.

Schlussbemerkung
Das ist also der Stand der Dinge. Exchange Server 2007 stellt zwei Features zur Verfügung, Outlook Web Access und Unified Messaging, die gemeinsam enorme Vorteile für eine Organisation bieten. Mit Outlook Web Access können Sie sicher auf E-Mails von einem beliebigen Standort aus zugreifen, und Unified Messaging ermöglicht Benutzern den Zugriff auf ihre E-Mails, Voicemail, Faxnachrichten und sonstige Postfachdaten, die in ihrem Exchange 2007-Postfach landen können.

Joshua Trupin ist Executive Editor des MSDN Magazins und des TechNet Magazins. Er hat zahlreiche Artikel für MSJ, MIND, das MSDN Magazin und das TechNet Magazin sowie ein Buch, „Hoop Stats: The Basketball Abstract“, geschrieben.


 Exchange Server 2007: Leistungsstarkes Journaling in Exchange&#160;2007
Exchange Server 2007 David Strome

Leistungsstarkes Journaling in Exchange 2007
Kurz zusammengefasst:
  • Journalregeln bei Exchange Server 2007
  • Der neue Journalassistent
  • Inhalt von Journalberichten

Mussten Sie jemals ein Journal über die von einem bestimmten Benutzer gesendeten oder empfangenen E-Mail-Nachrichten erstellen und standen am Ende mit den gesuchten Nachrichten sowie den Nachrichten der anderen 300 Postfächer des
Postfachspeichers da? Microsoft Exchange Server 2007 löst dieses Problem und gibt Ihnen die präzise Kontrolle, die Sie benötigen.
Mit Journalen auf Einzelempfängerbasis, die mit Unternehmens-Clientzugriffslizenzen (Client Access Licenses, CALs) erhältlich sind, können Sie das Ziel Ihrer Journale präzise wählen. Anhand von Journalregeln können Sie jetzt die gewünschten Empfänger und Absender, die Sie in Ihr Journal aufnehmen möchten, genau definieren. Sie können Ihren Fokus auf ein einzelnes Postfach einengen oder auf beispielsweise alle Mitarbeiter der Vertriebsabteilung ausweiten. Und die Postfächer müssen sich nicht auf dem gleichen Server, im selben Active Directory®-Standort oder in einer Exchange-Organisation befinden. Durch Active Directory-Replikation werden Ihre Änderungen automatisch auf allen Computern übernommen, die die Hubtransport-Serverrolle in Ihrer Organisation ausführen.

Funktionsweise von Journaling
In Exchange Server 2003 war die Journalingfunktion auf einzelnen Postfachspeichern auf jedem physischen Server implementiert. Wenn Sie ein Journal aller Postfächer in Ihrer Organisation erstellen wollten, mussten Sie das Journaling auf jedem Postfachspeicher konfigurieren. Und wenn Sie ein Journal der Nachrichten eines einzelnen Empfängers benötigten, mussten Sie entweder ein Journal aller Benutzer des Postfachspeichers generieren oder einen neuen Postfachspeicher speziell für diesen Benutzer erstellen.
Das Journaling in Exchange Server 2007 nutzt die neue rollenbasierte Topologie in Exchange. Wie in Abbildung 1 zu sehen ist, werden alle Nachrichten von Hubtransportservern verarbeitet, wenn sie an Postfach- und Unified Messaging-Server, andere Exchange-Systeme, Anwendungen von Drittanbietern und das Internet übertragen oder von diesen empfangen werden. Alle Hubtransportserver enthalten einen Transport-Agent, den so genannten Journaling-Agent. Dieser ist für das Anwenden von Journalregeln auf die Nachrichten verantwortlich. Da sich der Journaling-Agent auf den Hubtransportservern befindet, kann er sämtliche Nachrichten auswerten, bevor diese ihren Empfänger erreichen. Der Journaling-Agent behandelt Nachrichten nach Kategorie. Dies gewährleistet den Zugriff auf alle Empfänger- und Absenderattribute einer Nachricht und ermöglicht dem Agent zu bestimmen, ob die Nachricht direkt an den Empfänger gesendet oder über einen Verteiler verschickt wurde. Er kann auch erkennen, ob sich der Empfänger in der Zeile „An“, „Cc“ oder „Bcc“ einer Nachricht befindet, die innerhalb der Exchange Server 2007-Organisation ausgesendet wurde.
Abbildung 1 E-Mail-Verkehr auf dem Hubtransportserver
Abbildung 1 E-Mail-Verkehr auf dem Hubtransportserver (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 E-Mail-Verkehr auf dem Hubtransportserver
Abbildung 1 E-Mail-Verkehr auf dem Hubtransportserver (Klicken Sie zum Vergrößern auf das Bild)
Der Journaling-Agent wendet die vom Administrator konfigurierten Journalregeln auf Nachrichten an, während sie durch den Hubtransportserver geleitet werden. Anhand dieser Regeln wird bestimmt, ob der Agent Informationen über eine Nachricht aufzeichnet und diese Informationen zusammen mit der ursprünglichen Nachricht an ein Journalpostfach weiterleitet. Diese Daten werden in einem so genannten Journalbericht übertragen.
Bei früheren Versionen von Exchange mussten Konfigurationen auf mehrere Server angewendet werden. Wenn Sie jedoch eine Journalregel in Exchange Server 2007 erstellen, wird diese Änderung über Active Directory auf alle Hubtransportserver in Ihrer Organisation angewendet. Alle Hubtransportserver, und somit auch alle Journaling-Agents, rufen dieselbe Konfiguration von Active Directory ab. Diese breite Abdeckung gewährleistet, dass alle Journaling-Agents dieselbe Journalingkonfiguration anwenden.
Berücksichtigen Sie die Replikationszeiten von Active Directory beim Erstellen oder Ändern von Journalregeln, da Konfigurationsänderungen in Ihrer gesamten Organisation repliziert und von den Hubtransportservern gelesen werden müssen. Dies dauert unter Umständen mehrere Stunden. Um Ihnen das Identifizieren von Journalingkonfigurationsaktualisierungen zu erleichtern, protokolliert Exchange ein Ereignis im Sicherheitsereignisprotokoll auf jedem Server.
Exchange Server 2007 stellt sicher, dass Journalberichte auch dann nicht verloren gehen können, wenn ein Journalpostfach nicht verfügbar, voll, falsch konfiguriert oder offline ist. (Dies ist besonders nützlich bei der Einhaltung gesetzlicher Vorschriften und Auflagen, da der Verlust von Nachrichten als Nichteinhaltung der Vorschriften interpretiert werden kann.) Wenn ein Journalbericht nicht an ein Journalpostfach übermittelt werden kann, verbleibt der Bericht in der Warteschlange des Hubtransportservers, bis das Journalpostfach wieder verfügbar wird. Da dies zu rapide anwachsenden Warteschlangen führen kann, sollten Sie die Verfügbarkeit Ihres Journalpostfachs überwachen, um sicherzustellen, dass es korrekt funktioniert. Wenn ein Journalpostfach längere Zeit nicht verfügbar sein wird, können Sie einen alternativen Empfänger für Berichte konfigurieren, die sich in der Warteschlange befinden.

Auswahl der Inhalte für Journale
Bevor Sie mit dem Erstellen von Journalregeln beginnen, benötigen Sie eine klare Vorstellung Ihrer Ziele und der in die Journale aufzunehmenden Datentypen. Durch Angeben eines Benutzers in einer Journalregel können Sie bestimmte Benutzer für das Journaling auswählen. Diese Benutzer können beispielsweise einer bestimmten gesetzlichen Anforderung unterliegen oder in ein gesetzliches Verfahren verwickelt sein, in dessen Rahmen E-Mail-Nachrichten und andere Kommunikation als Beweise gesammelt werden müssen.
Zusätzlich zur Angabe der in das Journal aufzunehmenden Empfänger können Sie auch den Bereich der Nachrichten festlegen, wobei Sie die Optionen „Intern“, „Extern“ oder „Global“ wählen können. Mit „Intern“ werden nur Nachrichten innerhalb Ihrer Organisation berücksichtigt. Mit „Extern“ werden Nachrichten berücksichtigt, bei denen sich der Absender oder einer der Empfänger außerhalb befindet, und mit „Global“ werden sowohl interne als auch externe Nachrichten erfasst. (Beachten Sie, dass mit der Option „Global“ sämtliche Nachrichten in das Journal aufgenommen werden, die durch einen Hubtransportserver geleitet werden, d. h. auch jene, die möglicherweise bereits von Regeln mit der Option „Intern“ oder „Extern“ verarbeitet wurden.)
Exchange Server 2007 unterstützt Unified Messaging. Sie können Exchange so konfigurieren, dass sämtliche E-Mails, Voicemails und Faxe eines Benutzers im Posteingang des Benutzers abgelegt werden. Dies bedeutet auch, dass Sie alle diese Daten in das Journal aufnehmen oder bestimmte Daten ausschließen können.
Wenn Sie Exchange Server 2007 mit Standard-CALs ausführen, können Sie weiterhin Journale auf Postfachspeicherbasis verwenden. Wenn Sie jedoch die neuen Journalfunktionen auf Empfängerbasis verwenden möchten, müssen Sie auf die Unternehmens-CALs von Exchange Server 2007 aufrüsten.

Speicherort für das Journalpostfach
Nachdem Sie beschlossen haben, was Sie in Ihre Journale aufnehmen möchten, müssen Sie entscheiden, wohin die Journalberichte gesendet werden sollen. Wenn Sie über mehrere Standorte verfügen, müssen Sie bei der Wahl eines Speicherorts für Ihre Journalpostfächer die aktuelle und zukünftige Netzwerktopologie berücksichtigen. Je nach Größe Ihrer Organisation und Anzahl der Postfächer kann beim Journaling eine bedeutende Anzahl sich wiederholender Berichte generiert werden.
Sie sind jedoch bei dieser Auswahl nicht auf die Exchange-Postfächer beschränkt. Sie können Journalberichte an eine beliebige gültige SMTP-Adresse senden. Diese Adresse kann auf Exchange Hosted Services, auf die Archivierungslösung eines Drittanbieters oder eine beliebige Kombination über eine Verteilungsgruppe verweisen. Es gibt jedoch gewisse Sicherheitseinschränkungen in Bezug auf das Senden von Journalberichten.
Unabhängig vom Speicherort Ihres Journalpostfachs müssen Sie ein Empfängerobjekt für das Postfach in Active Directory erstellen. Hierbei kann es sich um ein Exchange Server 2007-Postfach, einen E-Mail-aktivierten Kontakt, der E-Mail an Exchange Hosted Services oder eine Archivierungslösung eines Drittanbieters umleitet, oder um eine Verteilerliste handeln, die sowohl Postfächer als auch Kontakte enthält.

Inhalt von Journalberichten
Wenn der Journaling-Agent einen Journalbericht über eine Nachricht erstellt, versucht er, möglichst viele Details über die ursprüngliche Nachricht aufzuzeichnen. Dieser Bericht wird dann an das Journalpostfach gesendet. Diese Informationen sind sehr wichtig beim Bestimmen der Absicht, der Empfänger und der Absender der Nachricht. Beispielsweise bietet die Art der Empfängeradressenangabe, d. h. direkte Adressierung im Feld „An“, indirekte Adressierung im Feld „Cc“ oder nur Mitglied einer Verteilerliste, Aufschluss darüber, wie der Empfänger an der Diskussion der Nachricht beteiligt ist. Die ursprüngliche Nachricht wird als Anlage beigefügt. Die Screenshots in Abbildung 2 zeigen einen Journalbericht, aus dem hervorgeht, dass eine an david@contoso.com gesendete Nachricht an christine@contoso.com weitergeleitet wurde. Aus einem weiteren Journalbericht geht hervor, dass eine an den Verteiler Sales_Group@contoso.com gesendete Nachricht erweitert wurde und lukas@contoso.com, der ein Mitglied dieser Verteilergruppe ist, die Nachricht empfangen hat. Beide Berichte enthalten die ursprüngliche Nachricht als Anlage, weisen den ursprünglichen Absender als brian@contoso.com aus und haben den Betreff „Sales forecast“.
Abbildung 2 Journalberichte mit einem weitergeleiteten Empfänger und einem Empfänger aus einer Verteilergruppe
Abbildung 2 Journalberichte mit einem weitergeleiteten Empfänger und einem Empfänger aus einer Verteilergruppe (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Journalberichte mit einem weitergeleiteten Empfänger und einem Empfänger aus einer Verteilergruppe
Abbildung 2 Journalberichte mit einem weitergeleiteten Empfänger und einem Empfänger aus einer Verteilergruppe (Klicken Sie zum Vergrößern auf das Bild)
Exchange klassifiziert nur Informationen, deren Richtigkeit gesichert ist. Informationen, die nicht automatisch bestimmt werden können, werden in die entsprechenden Felder im Journalbericht eingefügt. Abbildung 2 beschreibt die Felder, die im Text des Journalberichts enthalten sind.

Alles über Sicherheit
Standardmäßig ist die gesamte Kommunikation zwischen Computern, die Exchange Server 2007 innerhalb der gleichen Exchange-Organisation ausführen, verschlüsselt. Diese Verschlüsselung umfasst auch Journalberichte. Bei Exchange Server wurde eine Reihe von Maßnahmen ergriffen, um das Risiko von Manipulationen an den Journalberichten zu reduzieren:
  • Zwischen Hubtransportservern und Postfachservern in der Exchange 2007-Organisation werden sichere Links verwendet.
  • Journalberichte werden als „Microsoft Exchange“ im Namen des Absenders der ursprünglichen Nachricht gesendet.
  • Sitzungen zwischen dem Hubtransportserver und dem Postfachserver werden authentifiziert.
  • Nur authentifizierte Verbindungen werden angenommen, wenn Journalberichte zwischen den Hubtransportservern und den Postfachservern innerhalb einer Exchange 2007-Organisation übertragen werden.
Wenn Sie ein Journalpostfach erstellen, müssen Sie es sichern, da das Postfach Nachrichten enthält, die zu und von Empfängern in Ihrer Organisation gesendet werden. Einige Nachrichten können Teil von gesetzlichen Verfahren oder behördlichen Anforderungen unterworfen sein, und es gibt verschiedene Gesetze, nach denen Nachrichten unmanipuliert bleiben müssen, wenn sie einer Ermittlungsinstanz übergeben werden sollen. Zur Erhöhung der Journalpostfachsicherheit sollten Sie das Journalpostfach so konfigurieren, dass nur Nachrichten vom Microsoft Exchange-Absender angenommen werden, und Sie sollten zwingend festlegen, dass alle an das Journalpostfach gesendeten Nachrichten von authentifizierten Absendern gesendet werden müssen. Abbildung 3 zeigt die an einem Journalpostfach konfigurierten Nachrichtenübermittlungseinschränkungen. Diese Nachrichtenübermittlungseinschränkungen können auch mit dem folgenden Befehl der Exchange-Verwaltungsshell konfiguriert werden:
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
Abbildung 3 Nachrichtenübermittlungseinschränkungen
Abbildung 3 Nachrichtenübermittlungseinschränkungen (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Nachrichtenübermittlungseinschränkungen
Abbildung 3 Nachrichtenübermittlungseinschränkungen (Klicken Sie zum Vergrößern auf das Bild)
Wenn Sie Journalberichte an ein Journalpostfach senden, das sich außerhalb Ihrer Exchange Server 2007-Organisation befindet, müssen Sie die Verbindung zwischen Ihren Exchange Server 2007-Computern und dem empfangenden Server manuell verschlüsseln und sichern. Sie können festlegen, dass Transport Layer Security (TLS) zwischen den beiden Systemen verwendet werden muss, Sie können festlegen, dass auf dem empfangenden System eine Authentifizierung durchgeführt werden muss, Sie können auf dem empfangenden System nur Nachrichten entgegennehmen, die von der SMTP-Adresse des Microsoft Exchange-Empfängers stammen (diese SMTP-Adresse hat ein Format wie z. B. Exchange_UMUnique GUID@contoso.com), und Sie können den zum Weiterleiten von Nachrichten verwendeten Active Directory-Kontakt so konfigurieren, dass nur Nachrichten vom Microsoft Exchange-Empfänger angenommen werden.

Implementieren von Journalregeln
Doch genug der Theorie! Jetzt werden wir einige Regeln implementieren. Journalregeln im Journaling-Agent können entweder in der Exchange-Verwaltungsshell oder in der Exchange-Verwaltungskonsole konfiguriert werden. In beiden Fällen können der Empfänger, der Bereich und die Journalpostfacheinstellungen konfiguriert werden. Standardmäßig werden Journalregeln beim Erstellen aktiviert. Der Wert, den Sie für die E-Mail-Adresse für Journale angeben, muss ein vorhandenes Empfängerobjekt in der Exchange Server 2007-Organisation sein. Bei diesem Empfängerobjekt kann es sich um ein Postfach, eine Verteilergruppe, eine dynamische Verteilergruppe oder einen Kontakt handeln, der E-Mail an eine SMTP-Adresse sendet.
Wenn Sie mit der Exchange-Verwaltungskonsole arbeiten, führt Sie der Assistent zum Erstellen neuer Journalregeln durch das entsprechende Verfahren. Wählen Sie beim Konfigurieren der Organisation die Hubtransport-Serverrolle aus. Klicken Sie dann im Aktionsfenster auf die Option für eine neue Journalregel. Hier müssen Sie Werte für den Regelnamen, die E-Mail-Adresse für Journale und den Bereich eingeben. Sie brauchen keinen Wert für den Empfänger anzugeben, wenn die Journalregel Nachrichten für alle Empfänger in Ihrer Organisation in das Journal aufnehmen soll. Sie können auch auswählen, ob die Journalregel nach dem Erstellen deaktiviert werden soll. Abbildung 4 stellt eine Musterkonfiguration dar, mit der alle Nachrichten in das Journal aufgenommen werden, die an brian@contoso.com gesendet werden. Die Nachrichten werden an ein Journalpostfach namens Compliance Mailbox gesendet.
Abbildung 4: Assistent für neue Journalregeln
Abbildung 4: Assistent für neue Journalregeln (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4: Assistent für neue Journalregeln
Abbildung 4: Assistent für neue Journalregeln (Klicken Sie zum Vergrößern auf das Bild)
In der Exchange-Verwaltungsshell können Sie zur Verwaltung des Journaling-Agent die folgenden sechs Cmdlets verwenden:
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
Mit dem Cmdlet „New-JournalRule“ können Sie eine neue Journalregel erstellen. Die grundlegenden Kriterien beim Erstellen einer neuen Journalregel auf diese Weise sind dieselben wie beim Verwenden des Assistenten. Sie müssen Werte für die Parameter „Name“, „Scope“ und „JournalEmailAddress“ angeben. Auch diesmal brauchen Sie den Empfänger nicht anzugeben, wenn die Journalregel Nachrichten für alle Empfänger in Ihrer Organisation in das Journal aufnehmen soll. Und wenn Sie möchten, dass die Journalregel nach dem Erstellen deaktiviert wird, müssen Sie für den Parameter „Enabled“ den Wert „$False“ angeben. Wenn Sie eine Journalregel erstellen möchten, die die gleiche Konfiguration wie in Abbildung 4 hat, verwenden Sie den folgenden Befehl:
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
Mit dem Cmdlet „Get-JournalRule“ zeigen Sie eine Liste der von Ihnen erstellten Journalregeln an. Wenn Sie nur dieses Cmdlet ausführen, zeigt es eine zusammenfassende Liste aller Journalregeln an, die in Ihrer Organisation konfiguriert sind, samt den entsprechenden Konfigurationseinstellungen. Wenn Sie alle verfügbaren Informationen über eine Journalregel anzeigen möchten, können Sie die Ausgabe des Cmdlets „Get-JournalRule“ an das Cmdlet „Format-List“ weiterleiten. Bei der Weiterleitung wird die Ausgabe eines Cmdlets zum nächsten Cmdlet gesendet, damit das zweite Cmdlet die Ausgabe weiter verarbeiten kann. Das Cmdlet „Format-List“ zeigt beispielsweise sämtliche Ausgaben an, die es empfängt. Um alle Informationen anzuzeigen, die für die zuvor erstellte Journalregel verfügbar sind, können Sie diesen Befehl verwenden:
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
Wenn Sie eine Journalregel aktivieren oder deaktivieren möchten, verwenden Sie die Cmdlets „Enable-JournalRule“ und „Disable-JournalRule“. Beim Verwenden dieser Cmdlets müssen Sie den Namen der Journalregel im Parameter „Identity“ angeben. Wenn Sie zum Beispiel die eben erstellte Journalregel deaktivieren möchten, verwenden Sie den folgenden Befehl:
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Mit dem Cmdlet „Set-JournalRule“ können Sie eine vorhandene Journalregel ändern. Der Name der Journalregel wird mit dem Parameter „Identity“ verwendet, um dem Journaling-Agent mitzuteilen, welche Regel geändert werden soll. Anschließend geben Sie die Parameter „Recipient“, „JournalEmailAddress“, „Scope“ oder eine beliebige Kombination dieser Parameter zusammen mit dem neuen Wert an. Um beispielsweise den Wert zu ändern, der im Parameter „JournalEmailAddress“ für die erstellte Regel gespeichert wird, verwenden Sie folgenden Befehl:
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
Schließlich können Sie mit dem Cmdlet „Remove-JournalRule“ eine vorhandene Journalregel entfernen. Sie geben den Namen der Journalregel mit dem Parameter „Identity“ an. Um die Musterjournalregel zu löschen, verwenden Sie folgenden Befehl:
Remove-JournalRule "Brian Smith Journal Rule"
Nach Eingabe dieses Befehls werden Sie von der Exchange-Verwaltungsshell gefragt, ob Sie die Journalregel wirklich löschen möchten. Und noch ein letzter Tipp: Bei beinahe allen Cmdlets können Sie die Parameterbezeichnung „Identity“ weglassen und nur den Parameterwert angeben.

David Strome gehört als technischer Autor seit über einem Jahr der Gruppe „Exchange User Education“ bei Microsoft an. Bevor er sich in Redmond (Washington) Microsoft anschloss, befasste sich David Strome 10 Jahre damit, in verschiedenen Unternehmen in Britisch Columbia (Kanada) Exchange Server-Installationen zu entwerfen, zu implementieren und zu verwalten. Sie erreichen ihn unter dstrome@microsoft.com.


 Exchange Server&#160;2007: Bek&#228;mpfen von SPAM und Phishing mit Sender&#160;ID
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

Bekämpfen von SPAM und Phishing mit Sender ID
Kurz zusammengefasst:
  • Grundlagen von Sender ID
  • Konfigurieren von Sender ID in Exchange Server
  • Vorteile der Authentifizierung

Um der wachsenden Zahl von Spamnachrichten entgegenzuwirken, wurden schon viele Identifikations- und Filterverfahren entwickelt. Um effektiv zu sein, müssen bei der Anwendung dieser Verfahren bei jeder E-Mail-Nachricht bestimmte Fragen gestellt werden, beispielsweise
wer sie gesendet hat. Leider ist die fundamentale Frage, wer eine bestimmte Nachricht gesendet hat, nicht immer leicht zu beantworten. Eine E-Mail wird in der Regel über das Internet gesendet, ohne dass der Absender oder die vom Absender in Anspruch genommenen Computer authentifiziert werden. Es ist sogar recht einfach, beim Senden einer E-Mail-Nachricht vorzugeben, eine andere Person zu sein, und es gibt keine automatisierte Methode, um gefälschte Nachrichten zu erkennen.
SMTP (Simple Mail Transfer Protocol), das zum Senden und Empfangen von E-Mail-Nachrichten verwendet wird, wurde nie zu dem Zweck entwickelt, den Absender einer E-Mail-Nachricht zu identifizieren. Aufgrund dieser technologischen Sicherheitslücke kann als Absender jeder beliebige Name und jede beliebige Adresse eingefügt werden. Dies hat zur Folge, dass sich Inhaltsfilter- und Spamschutzverfahren nicht auf die Daten im E-Mail-Kopf allein verlassen können, um sicherzustellen, dass Nachrichten tatsächlich von dem Absender kommen, von dem zu kommen sie vorgeben.
Diese Sicherheitslücke versucht die E-Mail-Authentifizierung zu schließen. Bei der Authentifizierung wird sowohl vom sendenden als auch vom empfangenden E-Mail-System überprüft, ob Nachrichten tatsächlich aus den Domänen kommen, aus denen sie zu kommen behaupten. Dies macht es für Organisationen leichter, Junk-E-Mail wirkungsvoll herauszufiltern und zugleich sicherzustellen, dass legitime E-Mail-Nachrichten die gewünschten Empfänger tatsächlich erreichen.
Heute gibt es zwei lizenzgebührenfreie Verfahren zur E-Mail-Authentifizierung: Sender ID Framework (SIDF) und DomainKeys Identified Mail (DKIM). SIDF ist eine auf IP (Internet Protocol) basierende Lösung, die aus dem Zusammenschluss des Sender Policy Framework (SPF) und der Microsoft Caller ID for E-Mail geschaffen wurde. Im April des Jahres 2006 veröffentlichte die IETF (Internet Engineering Task Force) die Sender ID-Spezifikationen als RFC 4405 bis RFC 4408. Eine Koalition von Teilhabern aus Industrie und Wirtschaft einschließlich Microsoft empfiehlt die Bereitstellung von SIDF auf der Grundlage von Faktoren wie etwa geschäftlichem und technischem Wert, Stabilität, Ausgereiftheit, Einfachheit der Bereitstellung, minimale Auswirkung auf die Leistung bei der eingehenden und der ausgehenden Kommunikation sowie Interoperabilität mit dem E-Mail-Ökosystem für ISPs und Unternehmensumgebungen.
DKIM ist der Zusammenschluss der IIM-Spezifikationen (Identified Internet Mail) von Yahoo! DomainKeys und Cisco Systems Inc. Im Januar 2006 genehmigte die IETF die Einrichtung einer DKIM-Arbeitsgruppe, und die Spezifikation wird derzeit von der IETF geprüft.
Obwohl es keine perfekte Lösung zum Schutz gegen Spam gibt, stellt SIDF eine bedeutende Brancheninitiative zum Schutz gegen gefälschte Domänen dar. Aus diesem Grund ist es eine Schlüsselkomponente zur Reduzierung von Spam- und Phishingangriffen und zur Erhöhung des Vertrauens in Onlineverbindungen. Die Zahl der Organisationen, die SIDF nutzen, nimmt in der ganzen Welt rapide zu. Bis heute haben mehr als 5,5 Millionen Unternehmen und Domäneninhaber SPF-Datensätze veröffentlicht, und mehr als 600 Millionen Benutzer werden durch SIDF geschützt. Derzeit ist weltweit mehr als ein Drittel des täglichen E-Mail-Aufkommens authentifiziert und SIDF-kompatibel.
Die Entwicklung und die weltweite Akzeptanz von SIDF wäre ohne den Beitrag und die Unterstützung vieler Organisationen und Unternehmen einschließlich AOL, Authentication and Online Trust Alliance (AOTA), Bell Canada, E-Mail Senders Provider Coalition (ESPC), CipherTrust, Cisco Systems, IronPort Systems, MarkMonitor, Port25 Solutions Inc, Sendmail, Symantec, TRUSTe, VeriSign und anderen nicht möglich.

Einführung in Sender ID
Einige Branchenumfragen zeigen, dass über 95 Prozent der Phishingbetrugsdelikte von gefälschten Domänen herrühren und dabei mit gefälschten Absender-E-Mail-Adressen operiert wird. Dies ist genau der Punkt, an dem SIDF in Sachen Spamschutz einen gewaltigen Vorteil bietet. SIDF alleine wird das Problem der Spamangriffe nicht lösen, aber es trägt beträchtlich dazu bei, die Folgen von Spam- und Phishingangriffen zu minimieren. Durch SIDF wird nicht verhindert, dass Junk-E-Mail gesendet wird. Es macht es aber wesentlich leichter, Junk-E-Mail zu erkennen. Das Framework hilft E-Mail-Absendern, ihren Domänennamen, ihren guten Ruf und ihre Marken zu schützen. Es stellt eine stabile Grundlage bereit, um anhand der Zuverlässigkeit und des E-Mail-Verhaltens des Absenders Filterentscheidungen zu treffen.
Sender ID versucht zu überprüfen, ob jede E-Mail-Nachricht tatsächlich aus der Internetdomäne kommt, aus der sie vorgibt, gesendet worden zu sein. Dies wird bewerkstelligt, indem die Adresse des absendenden Servers anhand einer registrierten Liste von Servern überprüft wird, die der Besitzer der Domäne zum Senden von E-Mail autorisiert hat. Diese Überprüfung wird vom Internetdienstanbieter (ISP) oder vom E-Mail-Server des Empfängers automatisch durchgeführt, bevor die Nachricht zum Posteingang des Benutzers weitergeleitet wird.
Beachten Sie dabei, dass Sender ID oder alle sonstigen Authentifizierungsmechanismen keinen Ersatz für Inhaltsfiltersysteme sind. Weder SIDF noch DKIM überprüfen den Nachrichteninhalt selbst. Stattdessen teilt die Authentifizierung dem Eingangs-E-Mail-System mit, ob überprüft wurde, dass die Nachricht tatsächlich vom angeblichen Absender stammt. Da die meisten Spam- und Phishingversuche in Wirklichkeit nicht aus der angegebenen Domäne kommen, kann dieses Verfahren helfen, diese Nachrichten zu erkennen und sie aus dem Strom der eingehenden E-Mails herauszufiltern.
Innerhalb von SIDF stellt der SPF-Datensatz einen einfachen Textdatensatz aller Ausgangs-E-Mail-Server, die mit einer Domäne verknüpft sind, und ihrer jeweiligen IP-Adressen dar. Eine Organisation veröffentlicht den SPF-Datensatz in seiner DNS-Serverzonendatei, die dann von empfangenden E-Mail-Servern geprüft wird. Das Einrichten eines SPF-Datensatzes ist schnell, einfach und kostenlos. Der SPF-Datensatzassistent von Sender ID Framework (SIDF) stellt einen schrittweisen Prozess zum Überschauen der E-Mail-Server einer Domäne und zum Erstellen individuell angepasster, veröffentlichungsfertiger Datensätze bereit. (Details zur Veröffentlichung eines SPF-Datensatzes stehen unter microsoft.com/senderid zur Verfügung. Auf den Assistenten kann über microsoft.com/senderid/wizard direkt zugegriffen werden.)
Der empfangende SMTP-E-Mail-Server sendet eine Pinganforderung an die Zonendatei der Domäne im DNS, um zu prüfen, ob ein SPF-Datensatz vorhanden ist. Sobald der Datensatz gefunden wurde, wird die IP-Adresse des sendenden Servers anhand der aufgelisteten IP-Adressen geprüft. Wenn die IP-Adresse übereinstimmt, wird die Nachricht als authentisch gewertet. Stimmt dagegen der SPF-Datensatz in der Domäne des Absenders nicht mit der IP-Adresse überein, von der die Nachricht gesendet wurde, wird dies als negatives Ergebnis gewertet und die Nachricht möglicherweise im Ordner für Junk-E-Mail abgelegt. Abbildung 1 veranschaulicht diesen Prozess.
Abbildung 1 Überprüfen der SPF-Datensätze bei eingehenden Nachrichten
Abbildung 1 Überprüfen der SPF-Datensätze bei eingehenden Nachrichten (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Überprüfen der SPF-Datensätze bei eingehenden Nachrichten
Abbildung 1 Überprüfen der SPF-Datensätze bei eingehenden Nachrichten (Klicken Sie zum Vergrößern auf das Bild)
Nachdem die Nachricht markiert wurde, ermöglicht SIDF dem empfangenden E-Mail-Server, die Nachricht auf vergangenes Verhalten, Zuverlässigkeit des Absenders, Inhalt und andere von Ihnen nach Bedarf festgelegte Kriterien zu analysieren. Durch diese Fähigkeit werden zusätzliche Schutzvorrichtungen bereitgestellt. Spammer könnten beispielsweise im Aussehen ähnliche Domänen und SPF-Datensätze registrieren, um Benutzern und empfangenden Netzwerken vorzutäuschen, die E-Mail komme von einem legitimen Absender. Doch auch wenn die E-Mail-Nachricht die Authentifizierungsüberprüfung bestehen sollte, würde der Ruf des Absenders als Spammer genügen, die Nachricht zu blockieren, an den Papierkorb weiterzuleiten oder zu löschen.

Optionen zur Bereitstellung von Sender ID
Die Authentifizierung ausgehender E-Mails über SIDF erfordert keine Änderungen der Infrastruktur oder Softwareaktualisierungen und ist an keine spezielle Client- oder Serversoftware gebunden. Organisationen jedoch, die eine Eingangsauthentifizierung einrichten möchten, um ihr Unternehmen und ihre Arbeitnehmer zu schützen, müssen ihre Eingangssysteme und ihren MTA (Message Transfer Agent) aktualisieren und Software oder ein Gerät bereitstellen, das SIDF unterstützt. Die Mehrheit der führenden Anbieter von kommerziellen MTAs, Open Source-MTAs und Spamschutzprodukten einschließlich Microsoft® Exchange Server und Exchange Hosted Filtering bieten integrierte Lösungen an.
Microsoft hat SIDF in alle Messagingprodukte von Microsoft einschließlich Microsoft Exchange Server 2003 Service Pack 2 (SP2), Exchange Server 2007, Microsoft Exchange Hosted Filtering, Microsoft Windows Live™ Mail, MSN® Hotmail®, Outlook® und die Messaging- und Zusammenarbeitsclients von Office Outlook integriert.
Doch selbst Microsoft bleibt von Spam nicht verschont. Der täglich eingehende Datenverkehr beträgt bei Microsoft im Durchschnitt ungefähr 15 Millionen Nachrichten, und bei den in letzter Zeit erfolgten Spamangriffen sind zwei- bis viermal so viele Nachrichten eingegangen. In einer derartigen Umgebung lässt sich ein erfolgreicher Spamschutz am besten durch die rechtzeitige Implementierung der jeweils verfügbaren Technologien erzielen.
Bei Microsoft wird eine interne Exchange Server-Spamschutzlösung ausgeführt, die in Exchange Server 2003 auf dem Sender ID-Filter und in Exchange Server 2007 auf dem Sender ID-Agent beruht. In beiden Versionen von Exchange Server basiert der Sender ID-Status auf der Auswertung des Sender ID-Datensatzes, der sich auf den entsprechenden DNS-Servern befindet. Die tatsächliche Domäne wird ermittelt, indem die RFC 2822-Nachrichtenköpfe in der folgenden Reihenfolge untersucht werden:
  1. Erneut gesendet-Absender
  2. Erneut gesendet-Von
  3. Absender
  4. Von
Die Domäne des Absenders (oder die Entität, die zuletzt für das Einleiten einer Nachricht in den Messagingdatenstrom verantwortlich war, weil E-Mail-Systeme völlig legitim im Auftrag anderer E-Mail-Server E-Mail-Nachrichten weiterleiten können) wird ermittelt, indem in der festgelegten Reihenfolge nach der ersten Definition der eben erwähnten Nachrichtenköpfe gesucht wird. Wenn keiner dieser Nachrichtenköpfe gefunden wird, verwendet SIDF den SMTP RFC 2821 MAIL FROM-Wert.

Konfigurieren von Sender ID
In Exchange Server 2007 kann auf Servern, auf denen die Rolle „Edge Transport“ installiert ist, der Sender ID-Agent aktiviert werden. Wenn der Sender ID-Agent aktiviert ist, werden durch ihn Nachrichten gefiltert, die durch die Empfangsconnectors eintreffen. Dabei wird der gesamte aus externen Quellen eingehende nicht authentifizierte Datenverkehr dieser Verarbeitung durch Sender ID unterzogen. In Exchange Server 2003 ist der Sender ID-Status von Server zu Server im EXCH50-Blob festgeschrieben. In Exchange Server 2007 wurde er auch den Nachrichtenmetadaten hinzugefügt. Am endgültigen Ziel werden beide für die zukünftige clientseitige Nutzung in eine MAPI-Eigenschaft umgewandelt.
Die Konfiguration der Sender ID-Filter in Exchange Server 2003, die unter den Nachrichtenübermittlungseigenschaften zur Verfügung steht, besteht nur aus der Festlegung, wie Exchange Server auf fehlgeschlagene Prüfungen reagieren soll.
Um Sender ID in Exchange Server 2007 zu aktivieren, öffnen Sie einfach für einen Server, für den die Rolle „Edge Transport“ konfiguriert wurde, die Exchange-Verwaltungskonsole, wählen die Registerkarte „Anti-spam“ (Spamschutz), wählen „Sender ID“ aus und klicken wie in Abbildung 2 dargestellt im Fenster „Actions“ (Aktionen) auf „Enable“ (Aktivieren) oder „Disable“ (Deaktivieren), um den Sender ID-Agent ein- bzw. auszuschalten. Sie können auch wie in Abbildung 3 dargestellt die Exchange-Verwaltungsshell verwenden, um Sender ID zu aktivieren oder zu deaktivieren.
Abbildung 2 Steuerelemente der Exchange-Verwaltungskonsole für den Sender ID-Agent in Exchange Server 2007
Abbildung 2 Steuerelemente der Exchange-Verwaltungskonsole für den Sender ID-Agent in Exchange Server 2007 (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Steuerelemente der Exchange-Verwaltungskonsole für den Sender ID-Agent in Exchange Server 2007
Abbildung 2 Steuerelemente der Exchange-Verwaltungskonsole für den Sender ID-Agent in Exchange Server 2007 (Klicken Sie zum Vergrößern auf das Bild)
Abbildung 3 Aktivieren von Sender ID mithilfe der Exchange-Verwaltungsshell
Abbildung 3 Aktivieren von Sender ID mithilfe der Exchange-Verwaltungsshell (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Aktivieren von Sender ID mithilfe der Exchange-Verwaltungsshell
Abbildung 3 Aktivieren von Sender ID mithilfe der Exchange-Verwaltungsshell (Klicken Sie zum Vergrößern auf das Bild)
Im Dialogfeld „Properties“ (Eigenschaften) von Sender ID wird der Status (aktiviert bzw. deaktiviert) des Agent angezeigt. Auf der Registerkarte „Action“ (Aktion) werden Optionen bereitgestellt, die den in Exchange Server 2003 verfügbaren Optionen sehr ähnlich sind (siehe Abbildung 4).
Abbildung 4 Aktionseigenschaften des Sender ID-Agent in Exchange Server 2007
Abbildung 4 Aktionseigenschaften des Sender ID-Agent in Exchange Server 2007 (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4 Aktionseigenschaften des Sender ID-Agent in Exchange Server 2007
Abbildung 4 Aktionseigenschaften des Sender ID-Agent in Exchange Server 2007 (Klicken Sie zum Vergrößern auf das Bild)
Hinsichtlich der Implementierung und der Funktionalität von Sender ID besteht zwischen Exchange Server 2003 und Exchange Server 2007 kein großer Unterschied. Sowohl der Sender ID-Filter (in Exchange Server 2003) als auch der Sender ID-Agent (in Exchange Server 2007) verwenden zur Extrahierung und Überprüfung denselben Basisalgorithmus. Die Palette der möglichen Aktionen ist ebenfalls identisch: Nachricht löschen (stilles Löschen), Nachricht zurückweisen (500-Level-SMTP-Protokollantwort) sowie Nachricht mit Sender ID-Ergebnis bestempeln und Verarbeitung fortsetzen. Die zuletzt genannte Option ist in beiden Versionen von Exchange Server die Standardaktion.
In Exchange Server 2007 können sowohl der Statuscode „Fail“ (Durchgefallen) als auch der Statuscode „TempError“ (Temporärer Fehler) die Aktion „Nachricht zurückweisen“ auslösen. (In Exchange Server 2003 kann diese Aktion nur durch den Statuscode „Fail“ (Durchgefallen) ausgelöst werden.) Der Sender ID-Agent muss explizit konfiguriert werden, damit die Aktion „Nachricht zurückweisen“ auch bei Nachrichten mit dem Statuscode „TempError“ (Temporärer Fehler) ausgelöst wird, weil Nachrichten dieser Art standardmäßig im System akzeptiert, mit dem Sender ID-Ergebnis bestempelt und danach verarbeitet werden.
Da die dafür zuständige Konfigurationsoption nicht in der grafischen Benutzeroberfläche zur Verfügung steht, müssen Sie die Exchange-Verwaltungsshell verwenden, um Sender ID-Aktionen für den Statuscode „TempError“ (Temporärer Fehler) zu konfigurieren. Wenn Sie beispielsweise den Sender ID-Agent dafür konfigurieren möchten, Nachrichten mit dem Statuscode „TempError“ (Temporärer Fehler) zurückzuweisen, führen Sie das folgende Cmdlet des Sender ID-Agent aus:
Set-SenderIDConfig -TempErrorAction Reject
Die Palette der Sender ID-Statusergebnisse und der möglichen Aktionen in Exchange Server 2007 ähnelt der Palette des Sender ID-Filters in Exchange Server 2003 und wird in Abbildung 5 dargestellt.
Figure 5 Sender ID-Status und Sender ID-Aktionen in Exchange Server 2007 (Close Figure 5)

Sender ID-Status | Beschreibung | Aktionen
Neutral | Veröffentlichte Sender ID-Daten sind ausdrücklich nicht eindeutig | Status aufstempeln
Pass (Bestanden) | IP-Adresse befindet sich in der zulässigen Gruppe | Status aufstempeln
Fail (Durchgefallen) | IP-Adresse befindet sich in der nicht zulässigen Gruppe | Status aufstempeln, löschen oder zurückweisen
SoftFail (Leicht durchgefallen) | IP-Adresse befindet sich möglicherweise in der nicht zulässigen Gruppe | Status aufstempeln
None (Kein) | Keine veröffentlichten Daten | Status aufstempeln
TempError (Temporärer Fehler) | Vorübergehender Fehler wie z. B. ein nicht verfügbarer DNS-Server | Status aufstempeln oder zurückweisen
PermError (Permanenter Fehler) | Nicht behebbarer Fehler wie z. B. ein Fehler im Datensatzformat | Status aufstempeln
Exchange löscht (sofern es dafür konfiguriert wurde) nur Nachrichten, die bei der Sender ID-Überprüfung durchgefallen sind. Keine anderen Ergebnisse lösen das Löschen von Nachrichten aus. Eingehende Nachrichten, denen der Status „Neutral“, „None“ (Kein), „SoftFail“ (Leicht durchgefallen), „TempError“ (Temporärer Fehler) oder „PermError“ (Permanenter Fehler) zugewiesen wurde, werden entsprechend bestempelt und zur weiteren Spamschutzüberprüfung weitergeleitet. In einigen Fällen, wenn die Nachricht extrem fehlerhaft ist und die VON-Angabe der IP-Adresse des Absenders fehlt, kann der Sender ID-Status nicht auf die Nachricht gestempelt werden. In diesem Fall wird die Nachricht nicht verworfen oder zurückgewiesen. Stattdessen wird sie ohne Zuweisung eines Sender ID-Status zur weiteren Verarbeitung weitergeleitet, und es wird ein entsprechendes Ereignis ins Protokoll aufgenommen, um auf diese Nachricht aufmerksam zu machen.
In Exchange Server 2007 ist es leicht, Absenderdomänen und Exchange Server-Empfänger festzulegen, die von der Sender ID-Überprüfung ausgeschlossen werden sollen. Auch diese Konfigurationsoption ist nur über die Exchange-Verwaltungsshell verfügbar. Um beispielsweise die Domäne „contoso.com“ von der Sender ID-Filterung auszuschließen, führen Sie den folgenden Befehl aus:
Set-SenderIDConfig -BypassedSenderDomains contoso.com
Ähnlich können Sie auch Nachrichten, die an bestimmte festgelegte Exchange Server-Empfänger gesendet werden, von der Sender ID-Filterung ausschließen, indem Sie den folgenden Befehl ausführen:
Set-SenderIDConfig -BypassedRecipients user@contoso.com
In Exchange Server 2007 können Sender ID-Konfigurationswerte, die über Cmdlets von der Exchange-Verwaltungsshell eingestellt wurden, aber über die grafische Benutzeroberfläche nicht eingesehen werden können, problemlos abgerufen werden, indem wie in Abbildung 6 dargestellt in der Exchange-Verwaltungsshell der Befehl „Get-SenderIDConfig“ ausgeführt wird.
Abbildung 6 Konfigurations-Cmdlets von Sender ID
Abbildung 6 Konfigurations-Cmdlets von Sender ID (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 6 Konfigurations-Cmdlets von Sender ID
Abbildung 6 Konfigurations-Cmdlets von Sender ID (Klicken Sie zum Vergrößern auf das Bild)
Mit der Exchange-Verwaltungsshell kann eine schnelle manuelle Überprüfung der IP-Adresse und des zugehörigen Domänennamens durchgeführt werden. Um den Sender ID-Status zu prüfen, führen Sie den folgenden Befehl aus:
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
Wenn die Domäne nicht existiert, werden Sie ein Ergebnis sehen, das dem in Abbildung 7 gezeigten Ergebnis ähnelt.
Abbildung 7 Überprüfung des Sender ID-Status einer Adresse
Abbildung 7 Überprüfung des Sender ID-Status einer Adresse (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 7 Überprüfung des Sender ID-Status einer Adresse
Abbildung 7 Überprüfung des Sender ID-Status einer Adresse (Klicken Sie zum Vergrößern auf das Bild)

Vorteile von Sender ID
Neben seinen offensichtlichen Vorteilen beim Authentifizieren von E-Mail-Nachrichten und beim Reduzieren der Zahl der Spam-E-Mails, die bei den Benutzern eintreffen, bietet SIDF als Protokoll noch weitere Vorzüge. Bei seiner Entwicklung hat man sich bei Microsoft auf mehrere Schlüsselziele wie beispielsweise Leistung, Kosten, Bereitstellung und Skalierbarkeit sowie Interoperabilität konzentriert.
SIDF authentifiziert zuerst den E-Mail-Absender und zieht die Zuverlässigkeit dieses Absenders in Betracht. Dadurch lässt sich die Anzahl der Spam-E-Mails und der mit falschen Angaben eintreffenden E-Mail-Nachrichten beträchtlich verringern und die Zustellung legitimer E-Mail-Nachrichten von bekannten und vertrauenswürdigen Absendern im gleichen Maße verbessern. Weil das Erstellen eines SPF-Datensatzes kostenlos ist, kann jede Organisation, die ihr System SIDF-kompatibel machen möchte, dies problemlos tun. Organisationen, die den Wunsch haben, den Richtlinien eines neuen Standards zu entsprechen, sollten in der Lage sein, dies in die Tat umzusetzen. Mit SIDF ist das Erreichen dieser Kompatibilität nicht schwerer als das Veröffentlichen eines SPF-Datensatzes.
SIDF wurde mit dem Ziel entwickelt, innerhalb bereits vorhandener Software zu arbeiten, sofern dies möglich ist. Es kann mit einer breiten Palette von E-Mail-Architekturen sowie Client- und Serversoftware verwendet werden. Um effektiv zu arbeiten, muss jeder Authentifizierungsdienst in der Lage sein, die Anforderungen der größten ISPs genauso leicht wie die des kleinsten privaten E-Mail-Servers zu erfüllen. SIDF kann einen einzelnen E-Mail-Server oder auch tausende von E-Mail-Servern unterstützen, einschließlich derjenigen E-Mail-Server, die in andere Organisationen ausgelagert wurden.
Am 18. und 19. April 2007 werden Microsoft und ein Branchenkonsortium von über 30 Organisationen und Partnern in Boston (Massachusetts) den „Authentication & Online Identity Summit“ veranstalten. Bei dieser zweitägigen Veranstaltung werden Fallstudien erörtert und eine technische Begutachtung von Sender ID vorgestellt, in der im Einzelnen auf den Geschäftswert der E-Mail-Authentifizierung eingegangen wird. Weitere Informationen finden Sie unter aotalliance.org/summit2007. Zusätzliche Informationen sowie Tools und Ressourcen finden Sie unter microsoft.com/senderid und microsoft.com/exchange.

Craig Spiezle ist Direktor von Technology Strategy and Planning for Windows Live Safety bei Microsoft. Als Produktmanager für E-Mail-Authentifizierung war Craig eine der treibenden Kräfte, die in der Branche Sender ID eingeführt haben. Seit Craig im Jahr 1992 bei Microsoft angefangen hat, hatte er mehrere Verwaltungspositionen inne, darunter Positionen in den Bereichen internationales Marketing, Produktsupportstrategien, OEM und Entwicklung neuer Märkte.
Alexander Nikolayev ist bei Microsoft als Program Manager für serverseitige Protokolle, Transportkern und Antispamkomponenten für Exchange Server und Windows Server zuständig. Er besitzt einen MBA der Universität von Mary. Lesen Sie die Beiträge von Alexander auf dem Exchange-Teamblog unter blogs.technet.com/exchange.


 Mitteilung der Redaktion: Kontakt mit unseren Lesern
Mitteilung der Redaktion
Kontakt mit unseren Lesern

TECHNET MAGAZINE IST MEHR als nur dieses fabelhafte Blatt, das Sie heute in Ihren Händen halten. Unser Team hat unermüdlich daran gearbeitet, eine innovative neue Website zu kreieren, die unsere Inhalte mehr als einer Milliarde Menschen in aller Welt zugänglich machen wird. Ab der Novemberausgabe wird jeder Artikel in sieben Sprachen online verfügbar sein: in Englisch, Spanisch, Französisch, Deutsch, Russisch, vereinfachtem Chinesisch und brasilianischem Portugiesisch. Durch Hinzufügen von sechs zusätzlichen Sprachen (die englische Ausgabe war ja bereits online erhältlich) vermehrt sich die Anzahl der Personen, die unsere Inhalte in ihrer Muttersprache lesen können, um mehr als 1,6 Milliarden. Das ist fantastisch!
Und als ob dies nicht genug wäre, haben wir eine Menge neuer Funktionen hinzugefügt, mit denen die Site noch nützlicher wird. Mit unseren neuen, anpassbaren RSS-Feeds können Sie unsere Inhalte nach Datum, Spalte, Autor oder Thema auswählen. Sie können sogar nach Belieben mischen. Besuchen Sie technetmagazine.com/rss, und beginnen Sie noch heute, Ihre eigenen Feeds zu erstellen.
Wir führen auch neue Themenseiten ein. Wenn Sie herausfinden möchten, wie sich IT-Profis auf Windows Vista vorbereiten können, besuchen Sie einfach technetmagazine.com/vista. Wenn Sie als Postmaster arbeiten, sollten Sie sich unbedingt technetmagazine.com/exchange ansehen. Derzeit finden Sie 32 interessante Themen unter technetmagazine.com/topic, und es kommen laufend neue hinzu. (Im November gab es 43 Artikel zum Thema Sicherheit, die alle geduldig darauf warten, von Ihnen gelesen zu werden.)
Aber das ist nicht alles. Jetzt können Sie sogar weitere Einblicke in das Magazin und die Welt von IT-Profis gewinnen. Joshua Hoffman, Technik- und Beschaffungsredakteur bei TechNet Magazin, veröffentlicht das Blog des Magazins unter blogs.technet.com/tnmag. Und ich bin der Moderator eines monatlichen Podcasts auf unserer Website unter www.technetmagazine.com/podcasts. In jeder Ausgabe werde ich mich mit den Autoren der Artikel unterhalten, die Sie lesen. Auf diese Weise gewinnen Sie tiefere Einblicke nicht nur in das „Was“, sondern auch das „Warum“. Sie werden die Gespräche mit unseren führenden Autoren genießen!
Wir scheuen keinerlei Kosten und Mühen, um aus TechNet Magazine die absolut nützlichste Ressource für IT-Profis zu machen. 2006 war ein gutes Jahr, aber wir möchten gerne erfahren, was wir sonst noch für Sie tun können. Wenn Sie Kommentare haben, teilen Sie uns diese mit. Unsere Redaktionshotline ist tnmag@microsoft.com. Per E-Mail sind wir stets für Sie erreichbar.
JOSHUA TRUPIN

Unser Dank gilt den folgenden technischen Experten von Microsoft: Kevin Allison, Jessica Arnold, Sebastian Bengochea, Naveen Chand, Li Chen, Alpa Dave, Jill Frank, Mihai Jalobeanu, Darcy Jayne, Harry Katz, Kerry Landen, Todd Luttinen, Brett Muzzey, Bruce Payette, Tony Smith, Shawn Thomas, Jim Truher und Scot Vidican.


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

Belastungstest für Ihre Internetanwendungen
WAPT Web Application Stress Tool
www.loadtestingtool.com
Im Voraus zu wissen, wie sich die neueste Version Ihrer Webanwendung bewähren wird, ist entscheidend für die korrekte Planung der Infrastruktur. Nebenbei vermeiden Sie auch peinliche Momente wie solche, in denen Sie von Ihrem Manager gefragt werden, warum beim Ausprobieren der neuen Site die Meldung „Server ausgelastet“ angezeigt wird. Und wenn Sie nach einem verhältnismäßig preiswerten, leicht zu verwendenden Tool suchen, das einen Belastungstest Ihrer Internetanwendungen durchführen kann, sollten Sie sich WAPT 4.0 von SoftLogica LLC ansehen.
Die Anwendung kann unter den meisten Versionen von Windows® ausgeführt werden, aber wegen den Socketseinschränkungen von früheren Versionen kann das volle Potenzial nur mit Windows 2000, Windows XP oder Windows Server® 2003 ausgeschöpft werden. Wie bei den meisten Leistungsprüfungstools, die mit virtuellen Benutzern arbeiten, gilt auch hier: je mehr Speicher Sie haben, je schneller die Prozessoren sind und je leistungsfähiger die Netzwerkverbindung ist, desto mehr virtuelle Benutzer können Sie der Simulation hinzufügen.
Laut Dokumentation liegt die Höchstgrenze bei ca. 2000 virtuellen Benutzern bei Verwendung eines Pentium IV 2,4 mit 512 MB Arbeitsspeicher und einer Gigabit-Ethernetschnittstelle. Die genaue Anzahl hängt jedoch von der Art der zu testenden Anwendung und der Einrichtung des Testprofils ab. Ein weiterer Faktor, mit dem Sie Ihre Tests variieren können, ist die Verzögerungszeit zwischen aufeinanderfolgenden Anforderungen. In WAPT können Sie diese Frist als „Benutzerbedenkzeit“ im Profil der virtuellen Benutzer einstellen.
Wenn Sie die Einrichtung eines Profils für die virtuellen Benutzer beendet haben (Sie können über mehrere Vortestszenarios verfügen), können Sie den Testplan für das Profil erstellen. WAPT unterteilt die Testsequenz in drei Abschnitte: Beginn, Hauptteil und Abschluss. Zwar sind diese Unterteilungen eher logischer als funktioneller Natur, doch legen sie nahe, beispielsweise eine Anmeldungs- oder Registrierungsfunktion in einen anfänglichen Abschnitt und einen abschließenden Teil (Abmeldung) zu unterteilen. Mit WAPT können Sie die Anforderungen entweder manuell eingeben oder die integrierte Browseraufzeichnungsfunktion verwenden, um zu überwachen, wie die auf diesem Profil basierenden Benutzer durch Ihre Site surfen sollen. Anschließend können Sie zu den allgemeinen Einstellungen übergehen und bestimmen, welche Last für diesen Test verwendet werden soll und ob das Volumen konstant bleiben oder über einen angegebenen Zeitraum hinweg ansteigen soll. Während des Tests bietet Ihnen WAPT eine Echtzeitansicht der Leistungsstatistik für Ihr Testszenario. Und nach Abschluss des Tests können Sie die Ergebnisse im HTML- oder CSV-Format für die zukünftige Bezugnahme speichern.
Preis: 350 $ pro Computer.
Im Voraus zu wissen, wie sich die neueste Version Ihrer Webanwendung bewähren wird, ist entscheidend für die korrekte Planung der Infrastruktur. Nebenbei vermeiden Sie auch peinliche Momente wie solche, in denen Sie von Ihrem Manager gefragt werden, warum beim Ausprobieren der neuen Site die Meldung „Server ausgelastet“ angezeigt wird. Und wenn Sie nach einem verhältnismäßig preiswerten, leicht zu verwendenden Tool suchen, das einen Belastungstest Ihrer Internetanwendungen durchführen kann, sollten Sie sich WAPT 4.0 von SoftLogica LLC ansehen.
Die Anwendung kann unter den meisten Versionen von Windows® ausgeführt werden, aber wegen den Socketseinschränkungen von früheren Versionen kann das volle Potenzial nur mit Windows 2000, Windows XP oder Windows Server® 2003 ausgeschöpft werden. Wie bei den meisten Leistungsprüfungstools, die mit virtuellen Benutzern arbeiten, gilt auch hier: je mehr Speicher Sie haben, je schneller die Prozessoren sind und je leistungsfähiger die Netzwerkverbindung ist, desto mehr virtuelle Benutzer können Sie der Simulation hinzufügen.
WAPT Web Application Stress Tool
WAPT Web Application Stress Tool (Klicken Sie zum Verkleinern auf das Bild)
WAPT Web Application Stress Tool
WAPT Web Application Stress Tool (Klicken Sie zum Vergrößern auf das Bild)
Laut Dokumentation liegt die Höchstgrenze bei ca. 2000 virtuellen Benutzern bei Verwendung eines Pentium IV 2,4 mit 512 MB Arbeitsspeicher und einer Gigabit-Ethernetschnittstelle. Die genaue Anzahl hängt jedoch von der Art der zu testenden Anwendung und der Einrichtung des Testprofils ab. Ein weiterer Faktor, mit dem Sie Ihre Tests variieren können, ist die Verzögerungszeit zwischen aufeinanderfolgenden Anforderungen. In WAPT können Sie diese Frist als „Benutzerbedenkzeit“ im Profil der virtuellen Benutzer einstellen.
Wenn Sie die Einrichtung eines Profils für die virtuellen Benutzer beendet haben (Sie können über mehrere Vortestszenarios verfügen), können Sie den Testplan für das Profil erstellen. WAPT unterteilt die Testsequenz in drei Abschnitte: Beginn, Hauptteil und Abschluss. Zwar sind diese Unterteilungen eher logischer als funktioneller Natur, doch legen sie nahe, beispielsweise eine Anmeldungs- oder Registrierungsfunktion in einen anfänglichen Abschnitt und einen abschließenden Teil (Abmeldung) zu unterteilen. Mit WAPT können Sie die Anforderungen entweder manuell eingeben oder die integrierte Browseraufzeichnungsfunktion verwenden, um zu überwachen, wie die auf diesem Profil basierenden Benutzer durch Ihre Site surfen sollen. Anschließend können Sie zu den allgemeinen Einstellungen übergehen und bestimmen, welche Last für diesen Test verwendet werden soll und ob das Volumen konstant bleiben oder über einen angegebenen Zeitraum hinweg ansteigen soll. Während des Tests bietet Ihnen WAPT eine Echtzeitansicht der Leistungsstatistik für Ihr Testszenario. Und nach Abschluss des Tests können Sie die Ergebnisse im HTML- oder CSV-Format für die zukünftige Bezugnahme speichern.
Preis: 350 $ pro Computer.

Buchbesprechung
Content Networking Fundamentals
www.ciscopress.com
Auf die Inhalte kommt es an, und Content Networking Fundamentals (Cisco Press, 2006) von Silvano Da Ros unterstützt Sie dabei, Ihre Infrastruktur für die Bereitstellung von Inhalten rasch zu optimieren. Dieses Buch wird als „umfassende Einführung in die Theorie und Praxis von Inhaltsnetworking“ deklariert und wird diesem Anspruch voll und ganz gerecht. In diesem Buch wird zwar deutlich Netzwerkgeräten von Cisco der Vorzug gegeben, doch bietet es eine gute Einführung in die unterschiedlichen Komponenten des Inhaltsnetworkings und enthält praktische Richtlinien zum Implementieren der Prinzipien des Inhaltsnetworkings, die von der Art der Inhaltsnetworking-Produkte in Ihrer Infrastruktur unabhängig sind.
Das Buch beginnt mit einem Überblick über die verschiedenen Elemente des Inhaltsnetworkings, das im Grunde aus einer Optimierung der Leistung und Bereitstellung der Datenübertragung über die Schichten 4 bis 7 des OSI-Modells besteht. Anschließend werden die wichtigsten Darstellungsformate für Inhalte, z. B. XML, HTML, WAP, die Inhaltstransformation durch XSLT am Rand des Netzwerks sowie die Bereitstellung von Streaming-Medien ausführlich erläutert. Zum Schluss werden noch Skalierbarkeit und Verfügbarkeit sowie Serverlastausgleich (sowohl global als auch lokal), Firewall-Lastausgleich und die Verwendung von Inhaltszwischenspeichergeräten wie z. B. die Content Services Switches von Cisco behandelt.
Wenn Sie Content Services Switches von Cisco in Ihrer Infrastruktur verwenden, werden Sie das Kapitel über Switches auf jeden Fall interessant finden. Sie finden darin ausführliche Informationen zur Konfiguration des Inhaltsdienstemoduls für Secure Sockets Layer sowie Informationen zum Konfigurieren der Adresskorrektur durch URL- und Header-Rewriting. Die meisten Netzwerkprofis werden unabhängig von ihrer jeweiligen Markentreue das Kapitel über QoS nützlich finden, das verschiedene Warteschlangenmechanismen sowie das Überlastungsmanagement beschreibt.
Zusammenfassend kann gesagt werden, dass das Buch zwar eindeutig Cisco-Hardware bevorzugt (was auch nicht verwundert, denn es wird schließlich von Cisco Press verlegt), es Ihnen aber trotzdem helfen kann, eine praktische und anwendbare Methodik für Ihre Inhaltslieferungsinfrastruktur zu entwickeln.
Preis: $55.00.

Überwachen Sie Ihre Dienste
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp
Ein guter IT-Profi zeichnet sich durch die Fähigkeit aus, Probleme zu erkennen (und hoffentlich zu beheben), bevor Endbenutzer in der Organisation darauf aufmerksam werden. Daher ist eines der wichtigsten Tools, über die ein IT-Profi verfügen kann, ein effektives Überwachungssystem, das die verschiedenen von Ihnen bereitgestellten Dienste analysieren und ermitteln kann, ob sie wie erwartet funktionieren. Der WebWatchBot von ExclamationSoft ist ein solches Tool.
Diese Anwendung kann jeden allgemeinen Dienst überwachen, den Sie sich vorstellen können. WebWatchBot überprüft jedoch nicht nur, ob ein Dienst ausgeführt wird, sondern geht noch einen Schritt weiter. Die Anwendung testet die Dienste sogar, um sicherzustellen, dass sie ordnungsgemäß funktionieren. Bei der FTP-Überprüfung kann beispielsweise eine echte Datei hoch- und heruntergeladen werden, bei der DNS-Überwachung können 40 verschiedene Abfragebefehle ausgeführt und die Antwort nach einer Zeichenfolge durchsucht werden, und bei POP3- und SMTP-Tests wird eine echte Anmeldung durchgeführt und anschließend ein Bericht über die E-Mail-Leistung erstellt.
WebWatchBot
WebWatchBot (Klicken Sie zum Verkleinern auf das Bild)
WebWatchBot
WebWatchBot (Klicken Sie zum Vergrößern auf das Bild)
Darüber hinaus können Sie mit WebWatchBot eine Schrittfolge in einer Transaktion verketten, und es werden Fehler oder unannehmbare Latenzzeiten (gemäß den von Ihnen eingestellten Grenzwerten) für die Transaktion als Ganzes gemeldet. Die Anwendung überwacht auch HTTP- und HTTPS-URLs und kann auch Prüfungen auf angegebene Inhalte durchführen. Sie können sogar Datenbanküberwachungsmodule einrichten, die Abfragen ausführen, und einen Vergleich zwischen den Daten und den als Vorlagen zurückgegebenen Antworten durchführen.
Preis: 495,95 $ pro Einzelbenutzerlizenz.

Greg Steen ist ein Technologieexperte, Unternehmer und Enthusiast. Er ist immer auf der Suche nach neuen Hilfsmitteln und Methoden, die die Arbeitsprozesse und Entwicklung von IT-Profis erleichtern.


 Windows PowerShell: Einfache Befehle. Leistungsstarke Verwaltung
Windows PowerShell
Einfache Befehle. Leistungsstarke Verwaltung
Don Jones
Dieser Artikel basiert auf einer Vorabversion von Windows PowerShell. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.

Es hat eine Weile gedauert, aber jetzt ist Windows PowerShell fast startbereit. Das heißt, es ist nun an der Zeit, dass Windows-Administratoren darauf aufmerksam werden. Windows PowerShell bietet möglicherweise den leichtesten und flexibelsten Weg, um viele verschiedene Verwaltungsaufgaben zu automatisieren und Ihre Arbeit effizienter und produktiver zu gestalten.
Und was noch wichtiger ist, Microsoft baut die grafischen Verwaltungskonsolen von Produkten wie Exchange Server 2007 und System 2007 auf Windows PowerShell™ auf. Mit anderen Worten, Sie können fast jede Verwaltungsaufgabe innerhalb von Windows PowerShell durchführen. Microsoft plant, das gleiche Prinzip allmählich auf die Verwaltungsfunktionen von mehr und mehr Produkten auszudehnen. So könnte Windows PowerShell schließlich das erste Universaltool zum Verwalten nahezu aller Microsoft-Serverprodukte werden. Als Einführungshilfe wird Windows PowerShell regelmäßig in dieser neuen Rubrik behandelt. Laden Sie sich eine Kopie der Software herunter.

Leistungsstärke und Einfachheit
Wie der Name schon andeutet, handelt es sich bei Windows PowerShell um eine Shell, im Unterschied zur Eingabeaufforderung (Cmd.exe), die es seit Windows NT® 3.1 gibt. Cmd.exe wird fortbestehen, doch mit der Verfügbarkeit von Windows PowerShell gibt es kaum mehr einen Grund, weiterhin Cmd.exe zu verwenden.
In der Anwendung verhält sich Windows PowerShell nicht anders als Cmd.exe, außer dass Windows PowerShell leistungsfähiger ist. Wie Cmd.exe verfügt auch Windows PowerShell über eine integrierte Skriptsprache. Diese ist jedoch weitaus viel flexibler als die ursprüngliche Batchsprache von Cmd.exe. Flexibilitätsgrad Mit Windows PowerShell können Sie äußerst komplizierte Aufgaben mit einer Sprache automatisieren, die nur etwa ein halbes Dutzend integrierter Schlüsselwörter umfasst.
Da die Skriptprogrammierung bereits angesprochen wurde, sollte als Nächstes die Sicherheit erwähnt werden. Windows PowerShell profitiert von dem, was Microsoft im vergangenen Jahrzehnt und darüber hinaus über Sicherheitsfragen gelernt hat. Standardmäßig führt Windows PowerShell keine Skripts aus; es kann nur interaktiv verwendet werden, um einzelne Befehle auszuführen. Wenn Sie die Skriptprogrammierung aktivieren, können Sie Windows PowerShell anleiten, nur digital signierte Skripts auszuführen. All diese Maßnahmen sollen gewährleisten, dass Windows PowerShell nicht zum nächsten VBScript wird – einer hervorragenden Sprache, die oft dazu missbraucht wurde, schädliche Skripts zu erstellen. Auch VBScript wird fortbestehen. Sie werden jedoch wahrscheinlich feststellen, dass Windows PowerShell für viele verschiedene Aufgaben leichter verwendbar ist.
Mit Windows PowerShell kann nahezu alles ausgeführt werden, was Sie mit Cmd.exe ausgeführt hätten. Sie können z. B. ipconfig ausführen und zu einem ähnlichen Ergebnis kommen. Windows PowerShell führt jedoch einen neuen Satz von Befehlen ein, bei denen es sich nicht um externe ausführbare Dateien handelt. Diese so genannten Cmdlets (ausgeschrieben „command-lets“) sind direkt in Windows PowerShell integriert. (Einen Überblick über die nützlichsten Cmdlets, mit denen Sie eine Einführung in Windows PowerShell erhalten, finden Sie in der Randleiste „Die zehn wichtigsten sofort einsatzbereiten Cmdlets“.)
Die zehn wichtigsten sofort einsatzbereiten Cmdlets
  • „Get-Command“ ruft eine Liste aller verfügbaren Cmdlets ab.
  • „Get-Help“ zeigt Informationen zu Cmdlets und Begriffen an.
  • „Get-WMIObject“ ruft Verwaltungsinformationen mithilfe von WMI ab.
  • „Get-EventLog“ ruft Windows-Ereignisprotokolle ab.
  • „Get-Process“ ruft einen einzelnen Prozess oder eine Liste aktiver Prozesse ab.
  • „Get-Service“ ruft einen Windows-Dienst ab.
  • „Get-Content“ liest Textdateien, die jede Zeile als ein untergeordnetes Objekt behandeln.
  • „Add-Content“ fügt einer Textdatei Inhalt hinzu.
  • „Copy-Item“ kopiert Dateien, Ordner und andere Objekte.
  • „Get-Acl“ ruft Zugriffssteuerungslisten (ACLs) ab.
Eine vollständige Liste von Cmdlets, die in der Lieferung von Windows PowerShell enthalten sind, finden Sie unter windowssdk.msdn.microsoft.com/en-us/library/ms714408,aspx.
Alle Cmdlets sind standardmäßig in einem Verbsubstantivformat benannt, und dies erleichtert es, sie zu lernen und sich zu merken. Zum Beispiel werden durch das Cmdlet „Get-Command“ alle verfügbaren Cmdlets aufgelistet. Das nützlichste Cmdlet für einen Administrator ist möglicherweise „Get-WMIObject“. Angenommen, Sie möchten herausfinden, welches Service Pack auf Server2 ausgeführt wird. Dazu führen Sie einfach Folgendes aus:
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
Um die gleichen Informationen mithilfe von VBScript zu erhalten, müssten Sie mehrere Zeilen von Code schreiben. Andere Cmdlets ermöglichen Ihnen die Arbeit mit Diensten („Start-Service“, „Stop-Service“ usw.), Prozessen („Stop-Process“ und andere), Dateien (z. B. „Rename-Item“, „Copy-Item“, „Remove-Item“, „Move-Item“) und vieles mehr. Viele von diesen Cmdlets haben außerdem Verknüpfungsnamen, so genannte Aliase. Im Fall von „Get-WMIObject“ müssen Sie nur „gwmi“ eingeben. Wenn Sie „Get-Alias“ ausführen, erhalten Sie eine Liste dieser Verknüpfungsnamen.

Der Grund für die Objektorientierung
Windows PowerShell ist auf dem Microsoft® .NET Framework aufgebaut und vollständig objektorientiert. Normalerweise würde sich nur ein Softwareentwickler darüber freuen, doch in diesem Fall führt die Objektorientierung zu einer großen Zeitersparnis für Administratoren. Das liegt daran, dass Administratoren jetzt direkt mit umfangreichen Objekten innerhalb einer textorientierten Shell arbeiten können. Betrachten Sie folgendes Beispiel:
Get-Process | Sort-Object pm –desc | Select-Object –first 10
Dies ist nur eine einzelne Zeile mit drei verschiedenen Cmdlets, die von Pipes (mehr dazu folgt etwas später) getrennt wird. Das erste Cmdlet ruft alle ausgeführten Prozesse ab und leitet diese dann an „Sort-Object“ weiter. Das zweite Cmdlet sortiert die jeweiligen Prozessobjekt-PMs (Physical Memory) nach Eigenschaft in absteigender Reihenfolge. Die sortierte Sammlung von Prozessobjekten wird dann an „Select-Object“ weitergeleitet, das die ersten zehn auswählt und anzeigt. Das Ergebnis Diese einfache Zeile zeigt die 10 Elemente an, die den meisten physischen Speicher auf dem Computer verbrauchen, siehe Abbildung 1. Dies ist eine äußerst wirksame Weise, sich bei einer Problembehandlung einen schnellen Überblick zu verschaffen.
Abbildung 1 Verwendung eines einfachen Cmdlets zur Problembehandlung
Abbildung 1 Verwendung eines einfachen Cmdlets zur Problembehandlung (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Verwendung eines einfachen Cmdlets zur Problembehandlung
Abbildung 1 Verwendung eines einfachen Cmdlets zur Problembehandlung (Klicken Sie zum Vergrößern auf das Bild)
Die Verwendung von Pipes (bei einer Pipe handelt es sich um den senkrechten Strich, der sich auf US-amerikanischen Tastaturen in der Regel über dem umgekehrten Schrägstrich befindet) trägt wesentlich zu den Fähigkeiten von Windows PowerShell bei. Durch die Verwendung dieses Zeichens können Sie Objekte von einem Cmdlet zu einem anderem weiterleiten, sodass jeder dieser Befehle die Ergebnisse weiter verfeinern und sie für die Anzeige formatieren kann usw. Dieser Mechanismus funktioniert, weil jedes Cmdlet ein oder mehrere Objekte, anstatt reinen Text, zurückgibt, und somit nachfolgenden Cmdlets das vollständige Objekt bereitstellt.
Die Verwendung von Objekten ist in Windows PowerShell ist umfassend und dringt bis zu den Variablen durch. Und Sie müssen Variablen nicht von Anfang an deklarieren; Sie können sie als ein Dollarzeichen ($) vor einem Variablennamen darstellen. Obwohl dies nicht erforderlich ist, können Sie bei Windows PowerShell auch angeben, welchen Datentyp Sie in der Variable verwenden möchten. Dadurch kann Windows PowerShell die Variable einem der äußerst leistungsfähigen .NET Framework-Typen zuordnen, was Ihnen viel zusätzliche integrierte Funktionalität bietet. Angenommen, Sie möchten z. B. einen Computernamen anfordern und eine Service Pack-Version von diesem Computer abrufen, wissen jedoch nicht, ob die Person, die den Computernamen eingibt, zwei umgekehrte Schrägstriche (wie z. B. \\Server2) verwenden wird. Da Sie wissen, dass das Cmdlet „Get-WMIObject“ die umgekehrten Schrägstriche nicht benötigt, können Sie den Computernamen in einer Zeichenfolgenvariable speichern und die Methode „Replace“ verwenden, um umgekehrte Schrägstriche mit leeren Zeichenfolgen zu ersetzen, z. B. wie folgt:
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
Der Wert für den Parameter „Computer“ wurde in der $c-Variable bereitgestellt. Diese Variable wurde anfänglich als eine Zeichenfolge erstellt, deshalb hat sie die gesamte Funktionalität des .NET Framework-Zeichenfolgetyps, einschließlich der Methode „Replace“, übernommen. Selbstverständlich wird das Erlernen all dieser Möglichkeiten eine Zeit lang dauern, doch es sollte Ihnen relativ leicht fallen, sie sich mithilfe von Beispielen anzueignen. Windows PowerShell selbst vereinfacht den Lernvorgang. Wenn Sie z. B. „$c = $c.“ eingeben (ohne den Punkt zu vergessen) und die Eingabetaste drücken, dann zeigt Windows PowerShell „Clone()“ an – die erste Methode vom Typ Zeichenfolge. Wenn Sie die Eingabetaste gedrückt halten, durchläuft Windows PowerShell alle verfügbaren Methoden. Hierbei zeigt Ihnen Windows PowerShell im Prinzip, was es mit einer Zeichenfolge machen kann.
Hier ist eine komplexere Aufgabe. Zeigen Sie eine Liste von Computernamen in einer Datei an, d. h. einen Namen pro Zeile, und zeigen Sie für jeden Computer die Service Pack-Nummer an. In VBScript würde diese Aufgabe ein Dutzend oder mehr Zeilen von Code erfordern. In Cmd.exe müssten Sie eine komplizierte Batchdatei verwenden. In Windows PowerShell ist für diese Aufgabe nur eine Zeile erforderlich:
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Das Cmdlet „Get-Content“ liest den Inhalt von „C: \Computers.txt“. Jede Zeile der Datei wird zu einem eigenständigen Objekt. Diese Sammlung der Objekte, d. h. Computernamen, wird an den Befehl „foreach“ geleitet, der eigentlich nur ein Alias für das Cmdlet „ForEach-Object“ ist. Die Befehle innerhalb der geschweiften Klammern werden einmal für jedes weitergeleitete Objekt wiederholt, das heißt, in diesem Beispiel werden sie einmal für jeden Computernamen ausgeführt. Die besondere Variable „$_“ enthält also das aktuelle Objekt (d. h. den aktuellen Computernamen).
Innerhalb der geschweiften Klammern sind eigentlich zwei Befehle enthalten: Der erste Befehl zeigt schlicht den aktuellen Computernamen an, indem er den Inhalt von „$_“ zurückgibt. Der zweite Befehl ist der jetzt bereits vertraute Befehl „gwmi“. Das Ergebnis stellt eine Liste von Service Pack-Versionen für jeden Computer dar, der in der Datei aufgelistet ist. Und dieses Ziel wurde mit einer verhältnismäßig einfachen Zeile von Befehlen erreicht.
Beachten Sie, dass die Parameter „Property“ und „Computer“ abgekürzt wurden. Windows PowerShell erfordert nur so viel, wie zur einmaligen Unterscheidung von Parameternamen nötig ist.

Lesbarkeit und Wiederverwendung
Das Schreiben einer einzelnen Zeile von Befehlen und Parametern trägt jedoch nicht zur Lesbarkeit bei. Mit Windows PowerShell können Sie diese Zeile lesbarer gestalten, und dieses lesbare Ergebnis direkt in die Shell eingeben, ohne jemals ein Skript zu schreiben. Dies könnte folgendermaßen aussehen:
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
Diesmal wird der Inhalt der Datei in der Variable „$names“ gespeichert. In diesem Beispiel wird weiterhin „foreach“ verwendet, aber es wird nicht durch eine Pipeline eingegeben. Deshalb müssen Sie angeben, welche Sammlung von Objekten es durchlaufen und in welcher Variable die einzelnen Objekte gespeichert werden sollen – das ist der Teil, der „($name in $names)“ lautet. Alles andere bleibt sich gleich, und sobald Sie die Eingabetaste drücken, wird der Code ausgeführt, und die Ergebnisse werden angezeigt.
Wenn Sie denselben Code immer wieder verwenden möchten, können Sie einfach eine Funktion daraus erstellen. Geben Sie dazu Folgendes direkt in die Shell ein:
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
Wie Sie sehen, hat sich im Grunde nicht viel geändert. Dies schließt einfach das vorherige Beispiel in einer Funktion namens „Get-ServicePacks“ ein (gemäß der Verbsubstantiv-Benennungskonvention von Windows PowerShell). Die Funktion enthält jetzt einen Eingabeparameter namens „$file“, die im Cmdlet „Get-Content“ ersetzt wurde, damit eine unterschiedliche Datei angegeben werden kann, wenn die Funktion ausgeführt wird. Nachdem die Funktion definiert wurde, können Sie sie, fast so wie ein Cmdlet, einfach durch Aufrufen des Namens und durch Weiterleiten des Eingabeparameters ausführen:
PS C:\> Get-ServicePacks c:\computers.txt
In Abbildung 2 werden die Ergebnisse angezeigt.
Der Nachteil ist, dass diese Funktion nur so lange existiert, wie die Instanz von Windows PowerShell ausgeführt wird. Wenn Sie die Shell schließen, verschwindet die Funktion. Sie können die Funktion in Ihr Windows PowerShell-Profil kopieren, bei dem es sich um eine Art automatisches Skript handelt, das bei jedem Start von Windows PowerShell ausgeführt wird. Diese Vorgehensweise würde die Funktion in jedem Windows PowerShell-Fenster zur Verfügung stellen, das Sie öffnen. Alternativ dazu können Sie die Funktion in ein eigenständiges Skript umwandeln, das Sie dann einfach durch Eingabe des Skriptpfads und Dateinamens ausführen können.
Abbildung 2 Ergebnisse beim Ausführen der Funktion „Get-ServicePacks“
Abbildung 2 Ergebnisse beim Ausführen der Funktion „Get-ServicePacks“

Die Welt ist eine Datei (oder ein Ordner)
Windows PowerShell besteht aus mehr als nur Funktionen und Cmdlets. Im Folgenden wird ein Blick auf die Dateiverwaltung geworfen, um Ihnen einen Einblick in weitere Funktionen zu gewähren. Sie sind wahrscheinlich besser mit der Laufwerks- und Ordnernavigation in Cmd.exe vertraut. Geben Sie „C:“ ein, um zum C-Laufwerk zu wechseln, und „cd \test“, um den Ordner „C:\Test“ zu öffnen. Windows PowerShell funktioniert genauso, wobei „cd“ nur ein Alias für das Cmdlet „Set-Location“ ist.
Versuchen Sie, „Get-PSDrive“ auszuführen – das Cmdlet, das alle verfügbaren Laufwerke auflistet. Zusätzlich zu den üblichen Laufwerken C:, D: und möglicherweise A: werden Sie außerdem die so genannten Laufwerke Cert, Env und andere Laufwerke namens HKCU und HKLM finden Windows PowerShell macht viele verschiedene Arten von Speicherressourcen als Laufwerke verfügbar, wobei der lokale Zertifikatsspeicher, Umgebungsvariablen und die Registrierung über eine vertraute dateiartige Navigationsschnittstelle bereitgestellt werden.
Ändern Sie die Registrierungsgruppe „HKEY_LOCAL_MACHINE“ durch Eingabe von „Set-Location HKLM:“ (oder „cd hklm:“, falls sie die Verknüpfung bevorzugen), und drücken Sie die Eingabetaste. Führen Sie dann „cd software\microsoft“ aus, um in den Schlüssel „SOFTWARE\Microsoft“ zu wechseln. Mithilfe von „dir“, einem Alias für das Cmdlet „Get-ChildItem“, können Sie die Unterschlüssel in diesem Teil der Registrierung auflisten. Wenn Sie einen Schlüssel entfernen möchten, verwenden Sie „del“, als ob der Schlüssel eine Datei oder ein Ordner wäre. (An dieser Stelle wird zur Vorsicht geraten, da schwerwiegende Probleme auftreten können, wenn Sie erforderliche Schlüssel entfernen oder die Registrierung falsch ändern).
All diese Flexibilität rührt von den Anbietern her, die Ressourcen (wie z. B. den Registrierungs- und Zertifikatsspeicher) einem Format zuordnen, das wie ein Dateisystem aussieht. Microsoft plant, Windows PowerShell auf zusätzliche Anbieter zu erweitern, die Ihnen die Möglichkeit geben, z. B. so durch einen Exchange Server-Speicher zu navigieren, als ob er ein Dateisystem wäre. Dies ist insofern ein sehr wichtiges Verfahren, als es die große Vielfalt an Repositorys, die von Windows verwendet werden, identisch erscheinen lässt. Außerdem können alle Repositorys durch ein System von Befehlen und Verfahren, mit denen Sie bereits vertraut sind, leicht verwaltet werden.

Entwicklung mit Blick auf Sicherheit
Wie bereits erwähnt, wurde Windows PowerShell im Hinblick auf Sicherheit entworfen. Die primäre Sicherheitsfunktion in Windows PowerShell ist seine Ausführungsrichtlinie. Standardmäßig ist diese Richtlinie auf „Restricted“ (Eingeschränkt) festgelegt. Diese Einstellung können Sie durch Ausführen des Cmdlets „Get-ExecutionPolicy“ überprüfen. Im eingeschränkten Modus funktionieren Skripts nicht. Daran lässt sich nichts ändern. Da dies der Standardmodus ist, können integrierte Skripts mit Windows PowerShell nicht ausgeführt werden.
Sie können mit dem Cmdlet „Set-ExecutionPolicy“ andere Modi angeben. Ich persönlich bevorzuge den Modus „RemoteSigned“. Damit können lokale Skripts (nicht jedoch Remoteskripts) ausgeführt werden, ohne digital signiert zu sein. Dies ist die einfachste Methode zum Entwickeln und Testen von Skripts. Im Modus „AllSigned“ werden keine Skripts ausgeführt, es sei denn sie sind digital anhand eines Zertifikats signiert worden, das von einem vertrauenswürdigen Herausgeber stammt. Mit der Richtlinie „Unrestricted“ wird alles ausgeführt. Von diesem Modus ist abzuraten, da hiermit in Windows PowerShell unter Umständen die Ausführung schädlicher Skripts ermöglicht wird, die auf Ihren Computer gelangen. Beachten Sie, dass die Ausführungsrichtlinie auch von der Gruppenrichtlinie gesteuert werden kann, die alle lokalen Einstellungen außer Kraft setzt. (Sie werden von „Set-ExecutionPolicy“ gewarnt, wenn eine Gruppenrichtlinieneinstellung Ihre lokalen Einstellungen außer Kraft setzt.)
Außerdem führt Windows PowerShell keine Skripts vom aktuellen Verzeichnis aus, falls Sie den Pfad nicht angegeben haben. Dadurch sollen unberechtigte Befehlsaneignungen verhindert werden. Angenommen, ein Benutzer erstellt ein Skript, das die Bezeichnung „IPConfig.ps1“ trägt („PS1“ ist die Dateinamenerweiterung für Windows PowerShell-Skriptdateien). Wenn Dateien aus dem aktuellen Ordner ausgeführt werden könnten, bestünde das Risiko, dass Sie „ipconfig“ eingeben und dieses benutzerdefinierte Skript ausführen, obwohl Sie eigentlich das Windows-Programm Ipconfig.exe ausführen möchten. Da in Windows PowerShell Skripts vom aktuellen Ordner aus nicht ausgeführt werden, kann dies nicht passieren. Wenn Sie kein Skript vom aktuellen Ordner aus ausführen wollen, geben Sie nur den Pfad an, zum Beispiel: .\myscript. Über den expliziten Verweis auf den aktuellen Ordner wird sichergestellt, dass Sie wissen, dass Sie ein Skript und keinen Shellbefehl ausführen.
Windows PowerShell hat außerdem Funktionen, die das Experimentieren sicherer machen. Stellen Sie sich z. B. dieses erschreckende Szenario vor (probieren Sie dies jedoch nicht aus):
Get-Process | Stop-Process
Das Cmdlet „Get-Process“ erstellt eine Sammlung von Prozessobjekten und leitet sie zum Cmdlet „Stop-Process“, das sie tatsächlich beenden wird! Als Ergebnis wird nach ungefähr fünf Sekunden ein blauer Bildschirm mit einem STOP-Fehler angezeigt, während alle wichtigen Windows-Prozesse vernichtet werden. Sie können jedoch sehen, was geschehen wird, ohne es tatsächlich zuzulassen, indem Sie den praktischen Parameter „Whatif“ hinzufügen:
Get-process | Stop-Process -Whatif
Wenn Sie dies in Windows PowerShell ausführen, erhalten Sie Angaben dazu, welche Aktionen durch die Cmdlets ausgeführt worden wären, ohne dass die Ausführung tatsächlich erfolgt. Das Onlinehilfesystem in Windows PowerShell (auf das Sie über den Hilfealias zugreifen können) enthält zwar noch keine Erläuterungen zum Parameter „Whatif“, aber sie sollten diesen Parameter im Gedächtnis behalten. Es handelt sich dabei um ein hervorragendes Tool für das Testen von Skripts und Cmdlets und das Überprüfen der Ergebnisse, ohne potenziell schädliche Auswirkungen.

Schlussbemerkung
Unter den Funktionen, die in dieser Version von Windows PowerShell nicht untergebracht werden konnten, stellt der Support für ADSI (Active Directory® Services Interface) die möglicherweise wichtigste Funktion dar. Während Windows PowerShell die sehr widerstandsfähigen .NET-Klassen verwenden kann, die mit Active Directory und anderen Verzeichnisdiensten kompatibel sind, fehlt ihm noch ein praktisches „Get-ADSIObject“-Cmdlet. Aus diesem Grund ist die Arbeit mit Verzeichnisobjekten etwas schwieriger.
Außerdem bietet Windows PowerShell oft viele verschiedene Wege an, die gleiche Aufgabe durchzuführen. Das ist zwar gut, kann jedoch beim Erlernen von Windows PowerShell Verwirrung stiften, da Ihnen für eine vorgegebene Aufgabe gegebenenfalls ein halbes Dutzend verschiedener Beispiele präsentiert wird.
All dies wird mit der Zeit ausgebessert, und das Windows PowerShell-Team wird dem Produkt weitere Funktionen und Möglichkeiten hinzufügen. Halten Sie sich auf dem Laufenden, besuchen Sie den Blog des Teams.

Don Jones ist der Gründer von ScriptingAnswers.com und der Mitautor von Windows PowerShell: TFM (SAPIEN Press, 2006). Sie erreichen ihn unter: don@scriptinganswers.com.


 Nachbesprechung: Migration von Exchange 5.5
Nachbesprechung
Migration von Exchange 5.5
Whitney Roberts

DAS PROJEKT
Das Bildungsministerium von Kentucky musste von seiner vorhandenen Implementierung von Microsoft ® Exchange Server 5.5 auf Exchange Server 2003 migrieren. Das System unterstützt in jedem Schuljahr ungefähr 600.000 Lehrer/Lehrerinnen, Personal und Schüler/Schülerinnen.
DIE BETEILIGTEN
Das Projekt wurde vom Office of Education Technology (OET) des Bildungsministeriums von Kentucky und mit der Unterstützung von Beratern von KiZAN Technologies geleitet. Das OET-Personal hat einen Verwaltungsüberblick über die bestehenden Exchange 5.5-Implementierungen bereitgestellt. Für die tägliche Verwaltung der Exchange-Server war das örtliche Personal in den Schulbezirken zuständig.
DIE HERAUSFORDERUNGEN
Dem Bildungsministerium unterliegt die technische Leitung der 178 Schulbezirke im Gemeinwesen von Kentucky. Diese Schulbezirke sind über eine WAN-Verbindung miteinander vernetzt, doch jeder Bezirk betreibt seinen eigenen lokal verwalteten Exchange 5.5-Server, und alle Server mussten einzeln aufgerüstet werden. Dieses Upgrade würde Support für Outlook® 2003-Clients im zwischengespeicherten Modus, eine verbesserte Erfahrung mit Outlook Web Access (OWA), ein standardisiertes E-Mail-Adressierungsschema und mehr mit sich bringen.
Zusätzlich zu einem neuen E-Mail-Server und einer neuen Clientinfrastruktur fügten viele Schulbezirke einen E-Mail-Support für Schüler hinzu. Sowohl staatliche als auch bundesstaatliche Richtlinien gaben vor, dass die Informationen über Schüler geschützt werden mussten und außerhalb des jeweiligen Bezirks nicht sichtbar sein durften.
DER PLAN
Da kein Active Directory® Connector (ADC) verwendet werden konnte, wurde eine neue Exchange-Organisation erstellt und die Migration auf diese Weise vorgenommen. Die Standardisierung von E-Mail-Adressen bedeutete, dass sowohl neue Identifizierungsunterdomänen für jeden Schulbezirk als auch über 400 neue Empfängerrichtlinien erstellt werden mussten. Der Schutz von Schüleradressen erforderte die Erstellung eines Systems von globalen Adresslisten (GAL) und benutzerdefinierten Adresslisten für jeden einzelnen Schulbezirk.
Die eigentliche Migration erforderte das Bereitstellen neuer Hardware, das Erstellen und Konfigurieren von Postfächern auf Grundlage von Bezirkszugehörigkeit und Benutzertyp sowie das Einstellen von Erweiterungsattributen auf Grundlage von Bezirkszugehörigkeit und Benutzertyp, sodass die Benutzer in den entsprechenden Adresslisten angezeigt werden.
Es wurde eine auf Visual Basic® basierende Anwendung erstellt, die falsch konfigurierte Kontenattribute oder Gruppenmitgliedschaften erkennt und neue Postfächer korrekt bereitstellt, um sicherzustellen, dass die Anforderungen an die Sichtbarkeit berücksichtigt wurden. Die Anwendung wurde allen 178 Bezirken bereitgestellt und auf einer zeitlich begrenzten Basis von den Schulbezirksservern ausgeführt.

Hintergrund
Oberflächlich betrachtet hört sich dies vielleicht nicht wie eine große Herausforderung oder ein technisch schwieriger Auftrag an. Geschäftsanforderungen geben jedoch den Ton an, und die Geschäftsanforderungen dieses Projekts hatten es in sich.
Im Laufe der Jahre hatten eine dezentralisierte Verwaltung und eine bunte Mischung von Standards zahlreiche Support-„Silos“ ins Leben gerufen, die meistens vom OET verwaltet werden mussten. Außerdem musste das OET sicherstellen, dass die Implementierung von Exchange 5.5 die Voraussetzungen der Schulbezirke und des Bildungsministeriums gleichermaßen erfüllt. Das bedeutete, dass in den Bezirken, die Schüler-E-Mails verwendeten, die Informationen über Schüler geschützt werden mussten und außerhalb des jeweiligen Bezirks nicht angezeigt werden durften – so wie von den staatlichen und bundesstaatlichen Richtlinien vorgegeben (siehe ed.gov/policy/gen/guid/fpco/ferpa/index.html).
In Exchange 5.5 führten diese Richtlinien dazu, dass die Informationen über Schüler innerhalb eines Bezirks in anderen Schulbezirken oder anderen staatlichen Einrichtungen, die globale Adresslistendaten freigaben, nicht repliziert werden konnten. Folglich war ein manueller Export-/Importprozess für jeden der 178 Exchange 5.5-Standorte erforderlich: Ausblenden der Schüler, Replizieren der Liste, Einblenden der Schüler und schließlich Importieren der Adressliste. So würden andere Bezirke nur die Personaldaten sehen, und der die Daten besitzende Schulbezirk würde alle eigenen Daten, aber nur die Personaldaten anderer Schulbezirke sehen.
Angesichts der Stärken und Schwächen des vorhandenen Systems musste das Aufrüsten der Messaginginfrastruktur bestimmten Kriterien gerecht werden. Zuerst wünschte das Bildungsministerium von Kentucky eine Standardisierung nach einer gemeinsamen, lesbaren SMTP-Namensgebung für das gesamte Unternehmen. Die Namensgebung musste getrennte SMTP-Adressräume für Fakultät und Schüler bereitstellen.
Das neue System musste außerdem einen zentral verwalteten Dienst bereitstellen, der den Bezirk von der Messagingverwaltung und der Verantwortung für die Verfügbarkeit entlasten würde. Mit anderen Worten, die Verwaltung der Notfallwiederherstellung, der E-Mail-Verkehr und die Helpdeskaufrufauflösung mussten zentralisiert werden. Das neue System als solches musste eine zentralisierte Methode für die Standardisierung der Benutzerkonfiguration in allen Bezirken, ohne Rücksicht auf den geografischen Ort oder die Bezirksangliederung des jeweiligen Benutzers, bereitstellen.
Des Weiteren musste das neue System einen sicheren webbasierten Zugriff und einen Mobilgerätzugriff auf E-Mails über einen gemeinsamen, einheitlichen Namespace für alle Bezirke bereitstellen.
Bei diesen Anforderungen, von denen viele im bereits vorhandenen Exchange 5.5-System fehlten, sah die Aktualisierung auf Exchange 2003 nicht sehr verheißungsvoll aus.

Lösungsansätze
Um die Geschäftsanforderungen zu erfüllen, wurden für die Bereitstellung mehrere Exchange-spezifische Optionen ausgewählt.
Aufgrund des Mangels von Standardisierung und der Größe der Exchange 5.5-Umgebung sollte kein ADC verwendet werden. Stattdessen wurde eine neue Exchange-Organisation erstellt und die Migration auf diese Weise vorgenommen.
Das Aufräumen und Standardisieren von E-Mail-Adressen für das Personal und die Schüler in jedem Bezirk führte dazu, dass über 400 neue Empfängerrichtlinien erstellt wurden. Die Anforderungen schrieben eine einmalige Identifizierungsunterdomäne für jeden Bezirk vor, einschließlich einer Identifizierungsbezirksbezeichnung für Schüler. Im Fall des Shelby-Bezirks zum Beispiel lautete die primäre Unterdomäne shelby.kyschools.us. Die Schüler in jedem Bezirk erhielten die Unterdomänenbezeichnung „stu.“. Also lauteten die Adressen der Schüler im Shelby-Bezirk stu.shelby.kyschools.us.
Eine andere Einschränkung bestand darin, dass die Adressen von Schülern nur innerhalb ihres Bezirks angezeigt werden durften, während die Adressen des Personals in allen Bezirken angezeigt werden sollten. Es musste also ein umfangreiches System von globalen und benutzerdefinierten Adresslisten aufgestellt werden, siehe Abbildung 1 und Abbildung 2. Ein Vorteil, den die Migration auf Exchange 2003 hatte, bestand darin, dass die Adresslisten durch Berechtigungen abgesichert werden konnten und dass der Zugriff auf die einzelnen Adresslisten durch eine Gruppenmitgliedschaft gesteuert werden konnte. Diese Funktion wurde sinnvoll genutzt, indem zwei Sicherheitsgruppen (eine für das Personal und eine für Schüler) auf Bezirksebene erstellt und dann die entsprechenden Bezirkspersonal- und Schüler-GALs und Adresslisten gesichert wurden, damit nur Benutzerkonten innerhalb eines bestimmten Bezirks Zugriff auf bestimmte Adresslisten hatten. Durch Entfernen der Standard-GALs und Adresslisten und durch die Gewährleistung, dass die Benutzergruppen „Alle“ und „Authentifizierte Gruppen“ auf der Zugriffssteuerungsliste (ACL) der einzelnen Adresslisten nicht aufgelistet werden, konnten wir die Adressliste vorgeben, die ein bestimmter Benutzertyp in einem bestimmten Bezirk anzeigen kann.
Abbildung 1 Benutzerdefinierte rollenbasierte Adresslisten
Abbildung 1 Benutzerdefinierte rollenbasierte Adresslisten (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Benutzerdefinierte rollenbasierte Adresslisten
Abbildung 1 Benutzerdefinierte rollenbasierte Adresslisten (Klicken Sie zum Vergrößern auf das Bild)
Die Berechtigungen haben jedoch nur einen Teil des Sichtbarkeitsproblems gelöst. Es musste eine Lösung gefunden werden, um steuern zu können, wer in welcher Adressliste angezeigt wird. Dazu wurde ein LDAP (Lightweight Directory Access-Protokoll) erstellt, mit dem wir die Sichtbarkeit von Personal und Schülern abfragen konnten; anschließend wurde die Abfrage für jede Adressliste und GAL leicht angepasst. Zum Beispiel so, dass die LDAP-Abfrage für die Shelby-Personal-GAL nur das entsprechende Personal und die Schüler in Shelby und das gesamte Personal (aber keine Schüler) in den anderen Bezirken des Bundesstaats anzeigten. Die Shelby-Schüler-GAL sollte also nur das Personal und die Schüler von Shelby und kein anderes Personal bzw. Schüler in einem beliebigen anderen Bezirk des Bundesstaats anzeigen. Diese Abfrage wurde für alle Bezirke in der Organisation wiederholt. Abbildung 3 zeigt Beispiele für einige LDAP-Abfragen, die bei dieser komplexen Migration verwendet wurden.
Figure 3 LDAP-Abfragen für Adressliste (Close Figure 3)

LDAP-Abfrage für Personal-GAL
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
LDAP-Abfrage für Bezirksadressliste
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
LDAP-Abfrage für Bezirksschüleradressliste
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
LDAP-Abfrage für Offline-Adressliste des Bezirkspersonals
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
Abbildung 2 Trennung von Personal und Schülern durch GALs
Abbildung 2 Trennung von Personal und Schülern durch GALs (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 2 Trennung von Personal und Schülern durch GALs
Abbildung 2 Trennung von Personal und Schülern durch GALs (Klicken Sie zum Vergrößern auf das Bild)
Benutzerdefinierte Werte für die Exchange-Benutzereigenschaften „extensionAttribute14 (Custom Attribute 14)“ und „extensionAttribute15 (Custom Attribute 15)“ stellten den kennzeichnenden Mechanismus der LDAP-Abfragen dar. Das gesamte Personal und alle Schüler im Bundesstaat verwenden einen bestimmten Wert für „extensionAttribute14“, um den Benutzertyp zu bestimmen, und einen einmaligen Wert in „extensionAttribute15“, um die Bezirksangliederung anzuzeigen. Mithilfe eindeutiger Werte für jeden Bezirk und gleicher Werte für jeden Benutzertyp konnten die Adresslisten genau die Informationen anzeigen, die für jeden Benutzertyp in den einzelnen Bezirken erforderlich waren.
Diese Adresslisten eigneten sich gut für Benutzer, die über Outlook im nicht zwischengespeicherten Modus oder über OWA auf E-Mails zugreifen. (Die einzelnen Benutzer wurden mithilfe des Attributs „msExchQueryBaseDN“ zur richtigen Adressliste in OWA geleitet.) Allerdings warfen Benutzer, die Outlook im zwischengespeicherten Modus ausführen, ein anderes Problem auf. Da Outlook keine benutzerdefinierte GAL als das vorgegebene Offline-Adressbuch (OAB) akzeptiert, mussten wir zusätzliche Adresslisten erstellen, die Duplikate der GALs waren. Jeder Bezirkspostfachspeicher wurde dann mit der passenden OAB-Adressliste für seine den Zwischenspeichermodus verwendenden Benutzer konfiguriert. Alles in allem kam diese Lösung auf über 1.500 Adresslisten, mit denen verschiedenen Benutzertypen in allen 178 Bezirken eine volle Funktionalität geboten wurde.

Gewährleistung der Kompatibilität
Um sicherzustellen, dass die Struktur, die erstellt wurde, auch richtig funktionieren würde, kam es entscheidend auf die Einhaltung der neu festgelegten Standards an. Es gab mehrere High-Level-Aufgaben, die für jeden einzelnen Exchange-aktivierten Benutzer in der Organisation stattfinden mussten. Der Grund dafür ist, dass jeder Benutzer in allen Exchange-Servern des Bezirks korrekt platziert sein und in den zutreffenden Adresslisten angezeigt werden muss.
Der Benutzer musste ein Mitglied der zutreffenden Sicherheitsgruppe innerhalb der Bezirksdomäne sein, weil die Sicherheitsgruppe die Berechtigungen dazu verteilt, die entsprechende Adressliste zu öffnen. Außerdem musste das Attribut „msExchQuerybaseDN“ des Benutzers, je nach Zugehörigkeit zu Bezirk und Organisationseinheit, richtig eingestellt sein. Die Organisationseinheit des Benutzers wurde durch den Benutzertyp bestimmt.
Im nächsten Schritt wurde das Postfach des Benutzers, je nach Bezirkszugehörigkeit und Benutzertyp, im richtigen Speicher auf dem richtigen Server erstellt. Dadurch waren die Dienstebenen, Beschränkungen der Postfachgröße und Offline-Adressbuchlisten betroffen, sodass Outlook im Zwischenspeichermodus richtig funktionieren konnte. Die Erweiterungsattribute wurden je nach Bezirkszugehörigkeit und Benutzertyp festgelegt, sodass die Benutzer nur in den zutreffenden Adresslisten angezeigt wurden.
Schließlich musste eine Lösung bereitgestellt werden, damit die Attribute eines Kontos oder Gruppenmitgliedschaften automatisch korrigiert werden konnten, wenn sie durch die Verwendung unzutreffender Werte falsch konfiguriert bzw. geändert wurden. Wenn ein Benutzer innerhalb der Bezirksdomäne von einer Organisationseinheit zu einer anderen verschoben wird, stellt dies eine Benutzerklassifizierungsänderung dar. Der Postfachort, die GAL-Auswahl und die Adresslistensichtbarkeit müssen dann entsprechend aktualisiert werden.
Dafür wurde ein Bereitstellungssystem benötigt, das diese Aufgaben erledigen und die Konsistenz und Genauigkeit von Active Directory sicherstellen würde. Folglich wurde eine konsolen- und Visual Basic-basierte Anwendung erstellt, die auf einer zeitlich begrenzten Basis vom Exchange 2003-Server des Schulbezirks ausgeführt wird. Die Anwendung, die die Einhaltung der Richtlinien und Standards überwacht und außerdem die Erstellung und Bereitstellung neuer Objekte bearbeitet, wurde in allen 178 Bezirken bereitgestellt.
Die vorliegenden Aufgaben schienen zu kompliziert zu sein, als dass sie von einer Reihe von Skripts schnell und zuverlässig hätten ausgeführt werden können. Demzufolge wurde die auf Visual Basic basierte Anwendung als die geeignete Lösung angesehen, da sie effizient war, über einen strukturierten Fehler- und Ausnahmebehandlungssupport verfügte und da ihr interner Code in Zukunft durch minimale Umarbeitung leicht an den MIIS-Erweiterungscode (Microsoft Identity Integration Server) angepasst werden konnte.
Da wir zu einer neuen Organisation migrierten, musste eine bestimmte Methode zur Koexistenz gefunden werden. Es gab mehr als 178 ältere SMTP-Domänen, die in der neuen Umgebung unterstützt werden mussten. Einige Bezirke verfügten über bereits vorhandene Schüler-E-Mail-Domänen und andere nicht, doch glücklicherweise konnten Bezirke nacheinander migriert und die älteren Nachrichten und Adressen auf das neue System übertragen werden, ohne die anderen Bezirke zu stören. Bei der Migration von Exchange 5.5 auf Exchange 2003 musste jedoch darauf geachtet werden, dass der E-Mail-Fluss nicht unterbrochen wurde. Das bedeutete, dass eine Art Verzeichnissynchronisierung zwischen Exchange 2003 Active Directory und dem älteren Verzeichnis von Exchange 5.5 implementiert werden musste. Microsoft gewährte dem Bildungsministerium von Kentucky die begrenzte Verwendung von MIIS für die Dauer der Migration, damit der individuelle Erweiterungscode entwickelt und für die über MIIS erfolgende Synchronisation der beiden Exchange-Organisationen vor, während und nach der Migration verwendet werden konnte.
Die Migration auf eine neue Exchange-Organisation betrifft von Natur aus die MAPI-Clientkonfiguration. Das Bildungsministerium sah sich mit der Tatsache konfrontiert, dass es buchstäblich Zehntausende von MAPI-Profilen auf Bezirksebene gab, die während der Migration konfiguriert werden mussten. Erfreulicherweise veröffentlichte Microsoft das Exchange Profile-Tool (ExProfRe.exe), das für die Profilmigration in den Bezirken verwendet wurde. Es wurde ein verpacktes Installationsprogramm zur Ausführung von ExProfRe.exe mit vorgeladenen Werten erstellt, damit Profilmigrationen auf Bezirksebene automatisch durchgeführt werden konnten. Das Programm wurde über die Gruppenrichtlinie aufgerufen. Dieser Ansatz zeigte eine 100-prozentige Erfolgsrate bei automatisierten Profilmigrationen zwischen Organisationen.

Hardwareupgrades
Da die neuen Exchange 2003-Server die geografisch verteilten Exchange 5.5-Server ersetzten, musste der Hardwareaspekt dieser Lösung die gleiche Anzahl von Benutzern unterstützen wie die Exchange 5.5-Bereitstellungen, und das zusätzlich zu den Schülerkonten. Die Server mussten lokal innerhalb des Bezirks gehostet werden, weil die WAN-Topologie so entworfen war, dass jeglicher Bezirksdatenverkehr (Internet und intern) über eine private T1-Leitung erfolgte (in einigen Bezirken wurden mehrere T1-Leitungen verwendet).
Aufgrund finanzieller, verwaltungs- und ausrüstungsbedingter Einschränkungen stand den Exchange-Servern kein SAN (Storage Area Network) zur Verfügung, sodass der gesamte Speicher entweder intern geregelt oder direkt angehängt werden musste. Da die meisten Bezirke keine Datencenter mit Regallagerung und Zentralkühlung haben, mussten die Server so eigenständig wie möglich sein. Glücklicherweise hatten die meisten Bezirke weniger als 5.000 Benutzer, sodass einzelne Server bereitgestellt werden konnten. Für die Bezirke, die mehr Benutzer aufwiesen, wurden leistungsfähigere Server (oder mehrere Server) und zusätzlicher Speicher eingesetzt; manchmal mit getrennten Front-End-Servern, um die Trennung des Schüler- und Personaldatenverkehrs zu verbessern.
In den meisten Bezirken konnten gut ausgestattete Dualprozessorserver bereitgestellt werden, die mit maximal 15.000 RPM Ultra320 SCSI-Laufwerken, mehrfachen RAID-Controllern und 4 GB Arbeitsspeicher konfiguriert wurden. Größere Bezirke erhielten ein oder mehrere Quad-Prozessorenserver, die bei Bedarf kleinere Front-End-Server verwendeten. Bei Benchmark- und Leistungstests vor der Bereitstellung wurden keine Nutzungs- oder Belastungsprobleme festgestellt. Der entscheidende Faktor für die Gesamtleistung des Servers war jedoch eindeutig in den unterschiedlichen Werten der lokalen Verwendungsmuster zu suchen.

Machbarkeitsstudie (Proof of Concept, POC)
Obwohl die Produktionsumgebung eine Active Directory-Gesamtstruktur mit 178 Domänen umfasst, wurde das Labor für die Machbarkeitsstudie auf 13 Bezirksdomänen und eine leere Stammdomäne reduziert. Alle Testdomänen wurden mit Exporten der Produktionsdomänen aufgefüllt. Virtual Exchange 5.5-Server wurden erstellt und mit Kopien der ausgewählten Bezirksdatenbanken konfiguriert, damit der Migrationsprozess und der Ausbau der geplanten Umgebung getestet werden konnte. Das gesamte POC-Testlabor wurde mit virtuellen Computern erstellt, sodass die Umgebung als Grundlage verwendet, eingefroren und bei Bedarf erneut bereitgestellt werden konnte.
Diverse Kombinationen von Skripts (unter Verwendung von VBScript), SMS (Systems Management Server)-Installationsprogrammpaketen und Konsolenanwendungen wurden erstellt, kodiert, getestet und abgeschlossen. Am Ende lagen Skripts vor, die die anfängliche Installation und Konfiguration von Exchange 2003, einschließlich Empfängerrichtlinien, GAL und benutzerdefinierte Adresslisten sowie Berechtigungen, ausführten. Von Skripts wurden außerdem die administrative Gruppenkonfiguration, die Bezirksdomänenkonfiguration (Erstellen von Sicherheitsgruppen und Delegieren von Berechtigungen) und die der Bereitstellung nachfolgende Konfiguration für die Migration bearbeitet.
Das Bereitstellen der Exchange 2003-Server stellte eine erhebliche Herausforderung dar. Alle Exchange-Server mussten erfolgreich in allen 178 Domänen installiert und dies musste so geschickt ausgeführt werden, dass die restliche Migration nicht gefährdet wurde. Exchange 2003 weicht insofern von Exchange 2000 ab, als die domänenspezifische Exchange-Domänenservergruppe erst dann der Zugriffssteuerungsliste der Organisation hinzugefügt wird, wenn der erste Exchange 2003 Server in der Domäne installiert ist. (In Exchange 2000 wird die Gruppe hinzugefügt, wenn der DomainPrep-Prozess ausgeführt wird.) Um sicherzustellen, dass alle notwendigen Sicherheitsgruppen im Organisationsobjekt in Active Directory aufgelistet wurden, musste die Installation in einer vorgegebenen Domäne erfolgen, Active Directory manuell von der Domäne auf den Active Directory-Replikationshub repliziert und anschließend diese Replikation zur Installation zum nächsten Bezirk hinuntergezogen werden. Erst nachdem bestätigt wurde, dass die Exchange-Domänenservergruppe des vorherigen Bezirks in der Zugriffssteuerungsliste im Organisationsobjekt enthalten war, konnte die Installation des nächsten Bezirks auf sichere Weise beginnen. Wenn dieser Prozess in auch nur einer Domäne nicht planmäßig abgeschlossen wurde, musste jener Bezirk (zumindest) neu installiert werden. Anderenfalls hätten andere Bezirke aufgrund einer Organisationsobjekt-ACL, die nicht alle anderen Bezirke korrekt auflistet, nicht miteinander kommunizieren können.
Die gesamte Bereitstellung, Konfiguration, das Server-Staging und die Migration wurden so lange getestet, bis feststand, dass der Prozess innerhalb der POC-Umgebung gut funktionierte.

Migration und Anfangsschwierigkeiten
Nachdem die POC-Verfahren und -Ergebnisse vom Projektteam genehmigt wurden, konnte die Migration beginnen. Das OET entschied sich dafür, die Migration bei sich zuerst durchzuführen, um den Prozess und die Nachwirkungen direkt kennen zu lernen. Zum Zeitpunkt der Migration waren alle Server bereits bereitgestellt worden, und die anfängliche Umgebung war überprüft worden. Alle Front-End-Protokollserver und Postfachserver waren korrekt platziert und bereit, von Benutzern genutzt zu werden.
Die Ausführung des Migrationsplans gelang problemlos. Nach 21 langen Stunden, in denen der Inhalt von einem Server zum anderen übertragen wurde, stand Exchange 2003 dem OET zum sofortigen Einsatz bereit. Glücklicherweise gab es keine größeren Probleme bei der Migration von Outlook-Profilen von Exchange 5.5 auf Exchange 2003. Es wurde eine Batchdatei verpackt, von der ExProfRe.exe in verschiedenen Konfigurationen, aufgebaut auf einer einfachen Logik, aufgerufen wurde. Dann wurden die Batchdatei und die Datei ExProfRe.exe auf die Netlogon-Freigaben der Domänencontroller in den einzelnen Bezirken verteilt, und zum Abschluss der Migration wurde der Stapel mithilfe der Gruppenrichtlinie für alle Clients ausgeführt. Beim OET funktionierte dies problemlos, und wir waren uns sicher, dass der Prozess gut verlaufen würde.
Zu diesem Zeitpunkt wurde der Migrationsplan überprüft und aufgrund der Erfahrung mit der Bereitstellung beim OET erneut genehmigt. Im weiteren Verlauf der Migration wurden sechs Bezirke ausgewählt, die die ersten Produktionsstandorte sein sollten. Bevor jeder Bezirk migriert wurde, las MIIS die neuesten Informationen über die Postfächer des Bezirks von Exchange 5.5 ab und aktualisierte die zugehörigen Benutzer in der Bezirksdomäne. Der Exchange-Migrations-Assistent (Mailmig.exe) wurde dazu verwendet, um die Postfachdaten zwischen den Organisationen zu verschieben. Beim Verschieben der Postfachdaten durch den Assistenten wurden alle Proxyadressen übertragen und aufgrund dessen, was MIIS ursprünglich nach Active Directory exportiert hatte, aktualisiert. Während der Migration wurden die E-Mails an Front-End-SMTP-Servern aufgereiht und anschließend, nachdem die Migration, die Serverkonfiguration im Anschluss an die Migration und die Prüfung seitens der Benutzer abgeschlossen waren, an den Bezirk freigegeben. Der Bezirk war bereit, eine weitreichende Clientmigration unter Verwendung von ExProfRe.exe durchzuführen.

Der Empfängeraktualisierungsdienst (RUS)
Damit Outlook-Clients ordnungsgemäß funktionieren, musste sichergestellt werden, dass die Bereitstellungslösung die endgültige Instanz für das Einstellen von Attributen war. Es musste außerdem dafür gesorgt werden, dass der Empfängeraktualisierungsdienst (Recipient Update Service, RUS) den Auftrag sozusagen bei der Kontoeinrichtung abschließt, allerdings erst, nachdem das Bereitstellen beendet ist. Um dies zu erreichen, wurden die RUS-Instanzen für die Bezirke (alle 178 Bezirke) in Bezug auf ihre Zeitpläne auf „Nie“ eingestellt, und von der Bereitstellungslösung wurde Code verwendet, der den RUS auslöste, sodass er nach abgeschlossener Bereitstellung startete.
Die meisten Bezirke haben weniger als 5.000 Benutzer und weit weniger tägliche Aktualisierungen. Deshalb war der RUS schnell mit seiner Arbeit fertig, da das Bereitstellungssystem am Ende seines täglichen Pensums statt einer Neuerstellung eine Aktualisierung auslöste. Es gab jedoch mehrere Bezirke mit mehr als 10.000 Benutzern. Aktualisierungen in diesen Umgebungen durchzuführen, war zeitaufwändiger, und sollte eine vollständige RUS-Neuerstellung nötig sein, so würde sie eine Woche oder länger in Anspruch nehmen. Da der RUS bei der Ausführung alle Objekttypen bewertet, wirkt sich eine Neuerstellung in einer derart großen Domäne lähmend aus.
Obwohl sich keine Maßnahme zur Schadensbegrenzung finden ließ (trotz der Zusammenarbeit mit Mitgliedern der Exchange-Produktgruppe, um gemeinsam eine Lösung zu erarbeiten), wurde der Bereitstellungscode so verbessert, dass er viele der Standard-RUS-Aufgaben bearbeitet. Wenn sich Benutzer das erste Mal anmelden, werden die Attribute „showInAddressBook“ und „proxyAddresses“ geladen, sodass sie sich sofort anmelden können, ohne darauf warten zu müssen, dass der RUS seine Arbeit abschließt. Außerdem wurde eine manuelle Aufgabe erstellt, die auf einem der Front-End-Exchange 2003-Protokollserver ausgeführt wird. Sie erledigt einen zeitlich begrenzten LDIFDE-Import und löscht die RUS-GatewayProxy-Adresse. Das bedeutet, wenn eine Empfängerrichtlinie versehentlich in der Umgebung angewendet wird, erscheint sie nicht gleich auf der Aufgabenliste jedes RUS im Unternehmen.

Kategorisierungsprobleme
Einen interessanten Aspekt stellte die Aufgabe dar, dafür zu sorgen, dass die Schülerdaten nicht außerhalb des Schulbezirks gelangten. Dies wurde durch die Implementierung von Steuerungen erreicht, die verhinderten, dass Schüler E-Mails an Benutzer außerhalb ihres eigenen Bezirks oder an Internetadressen außerhalb des Systems schicken. Statt sich durch ein umfangreiches System von Connectors und zugehörigen Elementen durchzuarbeiten, wurde eine weniger bekannte Funktion von Exchange 2003 implementiert, und es wurden Connectoreinschränkungen für den vorhandenen Routinggruppenconnector vom Bezirk zum zentralen Hub verwendet, an dem sich die Front-End-Protokollserver befinden. In jeder Domäne wurden zwei Sicherheitsgruppen erstellt: eine für das Personal und eine für die Schüler. Und diese Gruppen wurden den Connectoreinschränkungen hinzugefügt.
Nachdem die Überprüfung der Connectoreinschränkung in der Registrierung aktiviert war, wurden einige sehr hinderliche Leistungsprobleme festgestellt. Nachrichten hingen stundenlang im Kategorisierungsmodul und in den lokalen Lieferwarteschlangen fest; sogar Nachrichten, die für Empfänger auf dem gleichen Server bestimmt waren. Diese Probleme verschlimmerten sich mit der Zeit, nachdem zusätzliche Bezirke migriert wurden. Als Übergangslösung wurde die Überprüfung der Connectoreinschränkung ausgeschaltet, und die Postlieferungsleistung verbesserte sich. Eine weitere Untersuchung ergab, dass das Kategorisierungsmodul bei der Nachrichtenübermittlung nicht nur die Gruppenmitgliedschaften der beiden Gruppen innerhalb seiner eigenen Domäne, sondern auch die Gruppenmitgliedschaften der gleichen zwei Gruppen in den anderen 177 Domänen überprüfte. Dies galt für jede Nachricht, die am Server ein- oder ausging.
Schließlich richteten wir eine Supportanfrage an Microsoft. Nach einer Evaluierung ist Microsoft derzeit dabei, einen Hotfix für dieses Problems zu generieren, indem das Kategorisierungsmodul befähigt wird, in einem Modus mit einer verminderten Topologiekomplexität zu arbeiten. Weitere Details zu dem Hotfix sind zum Zeitpunkt der Veröffentlichung dieses Artikels nicht verfügbar. Ziel ist es jedoch, eine Einstellung bereitzustellen, die dem Kategorisierungsmodul ermöglicht, bestimmte Annahmen über die Routingtopologie zu machen, ohne die Gruppenmitgliedschaft in allen Connectors zu überprüfen.

Die gelernten Lektionen
Wenn es etwas gibt, das ich bei diesem Projekt wieder neu gelernt habe, dann ist es Folgendes: Geschäftsanforderungen steuern unsere gesamte Arbeit als Berater. Es gab viele Anlässe, bei denen die Durchführbarkeit der Geschäftsanforderungen gegen die Komplexität der Lösung abgewogen werden musste. Die Entscheidungen und die Wahlen, die ich in diesem Artikel beschrieben habe, waren angesichts unserer Umgebung (einschließlich derjenigen Elemente, die ich hier aus Zeitgründen nicht behandeln konnte), unserer Ressourcen und unserer Geschäftsanforderungen die passendsten. Sie treffen gegebenenfalls andere Entscheidungen, und ich hoffe, dass der vorliegende Artikel einen Denkanstoß bietet. Glücklicherweise boten Exchange 2003 und Active Directory mehr als genug Flexibilität, um alle Anforderungen dieser komplizierten Migration zu erfüllen. Nachdem der anfängliche Schreck über den Umfang der Migration für das Bildungsministerium von Kentucky überwunden war, erwies sich die tatsächliche Lösung als einfacher denn gedacht. Sie baut auf Funktionen von Active Directory und Exchange 2003 auf, die meiner Meinung nach nicht ausreichend genutzt werden.
Die zweite wertvolle Lektion lautet: Stehen Sie der Problembehandlung und der Risiko- bzw. Problemverwaltung offen gegenüber. Es gibt Zeiten, in denen sich eine lokale Problembehandlung anbietet, und Zeiten, in denen die erweiterten Ressourcen des Microsoft-Produktsupports herangezogen werden müssen.

Vorschau
Die Umgebung des Bildungsministeriums von Kentucky ist sicher einzigartig. Im Verlauf dieser Bereitstellung ist nahezu jede Funktion in Exchange verwendet oder angepasst worden, um die Anforderungen des Ministeriums zu erfüllen. Jetzt, da die gesamte Umgebung erfolgreich bereitgestellt und migriert wurde, kann zusätzliche Funktionalität implementiert werden. Schulbezirke haben beim Bildungsministerium bereits Interesse an der Windows Mobile®-Plattform angemeldet, und es wird erwartet, dass sich der Trend zur Nutzung mobiler Geräte fortsetzt.
Eine Serverkonsolidierung trägt zu einer beachtlichen Wertschöpfung bei. Das Bildungsministerium von Kentucky untersucht derzeit die Möglichkeiten zur Virtualisierung einiger Aspekte der Active Directory-Umgebung. Und nachdem sich Exchange 2007 bereits am Horizont abzeichnet, hat das Ministerium angefangen, sich über die Anforderungen für ein Upgrade ihrer Nachrichtensysteme zu informieren.
Außerdem untersucht es die zusätzlichen Angebote zur Zusammenarbeit im Live Communication Server, Live Meeting Server und so weiter. Abgesehen davon wird derzeit Microsoft Operations Manager 2005 zum Verwalten und Überwachen der Exchange- und Active Directory-Server bereitgestellt.

Die Ergebnisse
Jedes Kind im öffentlichen Schulwesen von Kentucky wird von der Qualität und der Verbreitung dieser Implementierung betroffen sein. Dazu gehören meine eigenen Kinder und die Kinder der Kollegen und Kolleginnen, mit denen ich an diesem Projekt gearbeitet habe. Diese Implementierung hat dem Bildungsministerium von Kentucky dazu verholfen, dass es seine Technologie auf eine sichere und standardisierte Weise schneller als je zuvor weiterentwickeln kann. Ich bin stolz, Teil einer solchen Unternehmung gewesen zu sein.

Whitney Robertsist ein leitender Berater bei KiZAN Technologies (www.kizan.com) und hat seit der Veröffentlichung von Exchange 4.0 mit Exchange gearbeitet.


 Fragen und Antworten zu SQL: Verhindern von Neustarts, Installieren mehrerer Updates und vieles mehr
Fragen und Antworten zu SQL
Verhindern von Neustarts, Installieren mehrerer Updates und vieles mehr
Herausgegeben von Nancy Michell

Verhindern von Neustarts

F: Wie kann ich beim Anwenden von Hotfixes und ähnlichen Vorgängen auf SQL Server und sogar auf das Serverbetriebssystem im Allgemeinen die Anzahl der Neustarts beschränken?

A: Erstens interessiert es Sie möglicherweise zu erfahren, dass die meisten der nach Installationen erforderlichen Neustarts nicht im Installationsprogramm selbst fest implementiert sind. Sie sind in der Regel die Folge gesperrter Dateien. Dies bedeutet, dass das Installationsprogramm versucht, Dateien zu aktualisieren, die derzeit von einer anderen Anwendung oder vom Betriebssystem verwendet werden und daher gesperrt sind. Es gibt ein einfaches Verfahren, um diese Neustarts zu vermeiden: Stellen Sie sicher, dass die betreffenden Dateien von keinen Prozessen verwendet werden. Wie erreichen Sie das?
Der erste Schritt besteht darin, die Dateien zu ermitteln, die während der Installation in Verwendung und daher gesperrt waren. Am einfachsten können diese Dateien in der Registrierung unter „HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations“ ermittelt werden. Die Überprüfung dieses Registrierungsschlüssels dient zwei Zwecken: Dadurch wird bestätigt, dass die Neustartanforderung tatsächlich durch gesperrte Dateien verursacht wurde, und zugleich erfahren Sie, welche Dateien gesperrt waren. Wenn Sie sich diese Dateien nach der Installation, aber noch vor dem Neustart ansehen, können Sie vielleicht herausfinden, was zu dieser Neustartanforderung geführt hat, und geeignete Maßnahmen ergreifen, um dies bei zukünftigen Installationen zu vermeiden.
Sie können zwei Arten von Einträgen vorfinden. Wenn eine Datei gegen Lesen gesperrt war, sehen Sie einen Eintrag mit einer Zeile pro Datei, was bedeutet, dass sich die aktualisierte Datei zwar bereits auf der Festplatte befindet, Sie aber noch ihre temporäre Kopie löschen müssen, die gerade verwendet wird. Wenn eine Datei gegen Schreiben gesperrt war, sehen Sie einen Eintrag mit zwei Zeilen pro Datei, was bedeutet, dass die Aktualisierung noch nicht durchgeführt wurde und sich die Anwendung in einem unbekannten Zustand befindet und daher nicht verwendet werden darf. Es ist wie beim Unterbrechen einer Installation, die gerade im Gang ist. In diesem Fall zeigt eine Zeile die tatsächliche Datei an, und die andere verweist auf eine temporäre Datei, die beim anschließenden Neustart zur tatsächlichen Datei wird.
Der nächste Schritt hängt von zahlreichen Faktoren ab. Der Zweck besteht jedenfalls darin, die Software zu ermitteln, von der die gesperrten Dateien verwendet werden. Verwenden Sie Abhängigkeitsprüfer, sofern dies möglich ist, oder die DLL HELP-Datenbank auf MSDN® (siehe support.microsoft.com/kb/815065).
Wenn die Software, die Sie ermitteln, einen Dienst besitzt, dann stoppen Sie diesen Dienst manuell, und wiederholen Sie den Test. Handelt es sich um eine Anwendung, dann schließen Sie diese, und versuchen Sie es erneut. Manchmal wird eine einzelne Datei von mehreren Anwendungen verwendet, die Sie dann alle beenden müssen.
Das Ergebnis dieser Tests (in Ihrer Testumgebung) ist eine Liste von Anwendungen und Diensten, die vor der Installation in der Produktionsumgebung beendet werden müssen. Das Beenden dieser Anwendungen und Dienste hat zur Folge, dass kein Neustart der Produktionsumgebung erforderlich ist, weil keine der vom Installationsprogramm installierten Dateien von einer anderen Software gesperrt ist. Denken Sie dabei daran, alle beendeten Anwendungen und Dienste wieder zu starten, sobald die Installation abgeschlossen ist.
Das Gute an der Sache ist, dass meistens dieselben Dateien von denselben Anwendungen und Diensten gesperrt werden. Wenn Sie dieses Muster einmal für Ihr System herausgefunden haben, können Sie dadurch wahrscheinlich noch viele weitere Neustarts vermeiden, solange Sie das System verwenden.
Es gibt noch einen weiteren Trick, der hier erwähnt werden sollte. Möglicherweise haben Sie mehrere unterschiedliche Versionen von SQL Server™ oder einem anderen Produkt gleichzeitig installiert. In diesem Fall sollten Sie immer die neueste Version zuerst aktualisieren. Dabei stehen die Chancen gut, dass bei der Aktualisierung alles durch die neuesten Versionen ersetzt wird und alle übrigen Instanzen erst gar nicht versuchen, eine Datei zu sperren. Wenn Sie z. B. drei Instanzen von SQL Server 2000 SP3 besitzen, wird durch die erste, die Sie zu SP4 aufrüsten, die Datei MSXML3.dll aktualisiert und ein Neustart verlangt. Nehmen wir einmal an, Sie würden diesen Neustart jetzt durchführen. Anschließend können Sie die nächsten zwei Instanzen zu SP4 aufrüsten, ohne neu starten zu müssen, weil die aktualisierte Datei MSXML3.dll ja bereits vorhanden ist. Das gleiche gilt für das Aufrüsten aller Instanzen von SQL Server 2005 vor Instanzen von SQL Server 2000 und aller Instanzen von SQL Server 2000 vor Instanzen von SQL Server 7.0. Dies ist eine generelle Strategie zur Reduzierung der erforderlichen Neustarts, die wirklich funktioniert.
Wenn wir alles aus einer weiten Perspektive betrachten, erkennen wir, dass die Entwicklungsteams von Microsoft schon viel Arbeit geleistet haben, um in vielen Szenarios Neustarts zu vermeiden oder ihre Anzahl zu beschränken. Da dies die Kolumne zu Fragen und Antworten zu SQL ist, wollen wir SQL Server als Beispiel heranziehen.
In SQL Server 2005 hat das SQL Server-Team den für SQL Server erforderlichen MDAC-Code (Microsoft® Data Access Components) in SQLNCLI (neue Dateien) geteilt, statt MDAC selbst zu aktualisieren, und MDAC zurück ins Betriebssystem verlagert. Inwiefern hilft dies? Nun, das Windows®-Betriebssystem selbst verwendet MDAC und sorgt dafür, dass diese Dateien gesperrt bleiben. Daher war bei den meisten Service Packs für SQL Server und bei anderen Paketen immer ein Neustart erforderlich. Jetzt kann SQL Server seine MDAC-Version aktualisieren, ohne die vom Betriebssystem verwendeten Dateien ändern oder ersetzen zu müssen, und dadurch entfällt der sonst notwendige Neustart.
Darüber hinaus ist jetzt im Installationsprogramm von SQL Server 2005 SP1 ein Abhängigkeitsprüfer und eine Pause integriert. Dadurch sehen Sie, was gesperrt ist und wodurch es gesperrt wird, und ist es Ihnen möglich, an Ort und Stelle sofort die Software zu unterbrechen, die diese Sperrung verursacht, und das Installationsprogramm ohne einen Neustart fortzusetzen. Dies bedeutet, dass Sie in Echtzeit experimentieren können, ohne dafür ein Testlabor zu benötigen. Selbstverständlich haben Sie auch immer die Möglichkeit, den üblichen Vorgang einfach fortzusetzen und den Neustart durchzuführen, falls Sie dies vorziehen oder die Installation unbeaufsichtigt ausgeführt wird. Beachten Sie, wie leicht Sie dadurch herausfinden können, welche Software Ihre Dateien sperrt!
Darüber hinaus verarbeitet Microsoft Installer auch die vorhandenen PendingFileRenameOperations (PFRs) viel besser. Denken Sie daran, dass das Installationsprogramm von SQL Server 2000 blockieren würde, wenn im bereits erwähnten Registrierungsschlüssel Dateien auftauchen würden. Das Installationsprogramm von SQL Server 2005 ist intelligent genug, nur zu blockieren, wenn die Dateien zu SQL Server gehören (was auf einen Konflikt hindeuten würde), und kann selbst in diesen Fällen oft auf den PFR-Schlüssel zugreifen und ihn direkt aktualisieren, ohne einen Neustart erforderlich zu machen. Diese Technologie ist zu einem gewissen Grade sowohl in MSI als auch in die Datei „update.exe“ integriert, also in die aktuellen Standardinstallationsprogramme von Microsoft, mit denen alle Aktualisierungen durchgeführt werden.
" Das SQL Server-Entwicklungsteam hat großartige Arbeit geleistet, indem es msxmlsql.dll abgetrennt hat, damit die SQL Server-Updates keinen Neustart verursachen, aber Sie können eine Weile damit rechnen, dass dies dennoch gelegentlich vorkommen wird. Daran lässt sich nichts ändern, denn Sie können SVCHost nicht herunterfahren und trotzdem Aktualisierungen ausführen.
Auch Pakete von update.exe bereiten während des Deinstallationsvorgangs noch einige Probleme. Wenn Sie eines dieser Pakete deinstallieren, sperrt es (natürlich außerhalb der PFR-Schlüssel) die lokal abgelegten Dateien des Installationsprogramms. Dies verhindert die Ausführung anderer Pakete von update.exe, bis Sie einen Neustart ausführen, um diese Sperrung aufzuheben. Ihnen bleibt nur übrig, sich dessen bewusst zu sein und in Ihrem Plan zu berücksichtigen, dass Sie nach allen von Ihnen ausgeführten Hotfix-Deinstallationen einen Neustart durchführen müssen.
Ein weiteres Problem ist die Diskontinuität. Nicht alle Programme blockieren eine Datei ständig. In den meisten Fällen sind freigegebene DLL-Dateien tatsächlich nur von Zeit zu Zeit in Verwendung, weil andere Programme nur bei Bedarf in Abhängigkeit von ihrer eigenen Arbeitsauslastung und ihren Codepfaden auf sie zugreifen. Dies bedeutet, dass Sie u. U. 10 Mal testen, ohne eine gesperrte Datei vorzufinden, und dann bei der Produktionsbereitstellung plötzlich auf eine gesperrte Datei stoßen. Dafür gibt es leider kein Gegenmittel. Bauen Sie einfach Ihre Testumgebung so auf, dass sie Ihrer Produktionsumgebung einschließlich der Arbeitsauslastung möglichst ähnlich ist (dies ist immer ein guter Plan), und führen Sie genug Tests aus, um diese Zufälle auszumerzen.
Service Packs und Upgrades für das Betriebssystem werden einen Neustart erfordern. Beachten Sie auch, dass bei niedrigeren Versionen (Windows 2000, Windows XP und älteren Versionen) die Installation erst nach dem Neustart abgeschlossen ist, selbst wenn der Registrierungsschlüssel „pendingfilerenameoperations“ leer ist. Möglicherweise werden Ausnahmevorgänge zur Paketregistrierung ausgeführt, um während des Neustarts Code zu installieren. Diese Vorgänge sind noch nicht einmal Bestandteil des Service Pack-Installationsprogramms, sondern eingebettete Befehle Ihres derzeitigen Betriebssystems, die durch die Aktualisierungsszenarios ausgelöst werden, um bestimmten Codes, die Sie verwenden, das Überleben zu ermöglichen.
Schließlich führt der PFR-Schlüssel keine Dateiversionsprüfungen durch und erzwingt er auch nicht durch Serialisierung eine bestimmte Reihenfolge. Dies bedeutet, dass er die Ersetzung von Dateien in der Reihenfolge durchführt, in der sie aufgelistet sind. Aber die Reihenfolge, in der sie auf die Festplatte angewendet werden, beginnt erwiesenermaßen bei der zuletzt fertig gestellten Dateiersetzung (und nicht etwa bei der zuerst gestarteten). Das ist zwar logisch, aber es bedeutet auch, dass dann, wenn im selben Pfad zwei Kopien derselben Datei vorliegen, die jeweils auf eine andere Version verweisen, das Endresultat nach dem Neustart vom Zufall abhängt. Sollte Ihnen so etwas jemals auffallen, dann stellen Sie sicher, dass dies behoben wird. Wenn Sie sich nicht sicher sind, dann führen Sie einfach nach dem Neustart beide Installationsprogramme erneut aus. Falls bereits die richtigen Dateien installiert wurden, wird keines der Installationsprogramme etwas daran ändern. Falls die falschen Dateien installiert wurden, wird dies durch das Installationsprogramm behoben, das die richtigen Dateien besitzt. Dies geht offen gesagt schneller und einfacher als herausfinden zu wollen, wie das gewünschte Ergebnis aussieht.

Installieren mehrerer Service Packs

F: Ich habe acht gruppierte SQL Server 2000-Instanzen in einem 4-Knoten-Cluster und möchte mit möglichst wenigen Neustarts SP4 installieren. Kann ich SP4 nacheinander auf allen 8 Instanzen installieren und am Ende alle Knoten neu starten?

A: Sobald Sie auf einem Windows Server (ob nun gruppiert oder nicht) eine einzelne Instanz von SQL Server SP4 vollständig installiert haben (was evtl. einen Neustart erfordert), dürften beim Installieren von SQL Server SP4 auf anderen SQL Server-Instanzen dieses Systems keine weiteren Neustarts erforderlich sein. Der Grund dafür liegt darin, dass alle freigegebenen Dateien – Tools, MDAC, MSXML usw. – bereits in der richtigen Version vorliegen und unabhängig davon, ob sie gesperrt sind oder nicht, keine weitere Aktualisierung erfordern. Alle nicht freigegebenen Dateien werden nur von der ersten Instanz verwendet und bei der Installation heruntergefahren. Es ist auch zu beachten, dass dann, wenn mehrere SQL Server-Instanzen verschiedener Versionen vorliegen, die neueste SQL Server-Instanz aktualisiert werden sollte.

Ausführen als Netzwerkdienst

F: Worum handelt es sich beim Konto NT-AUTORITÄT\NETZWERKDIENST genau und was ist seine Hauptfunktion? Welche Sicherheitsimplikationen sind mit diesem Konto verbunden, insbesondere dann, wenn ihm Systemadministratorrechte zugewiesen werden?

A: Das Konto „Netzwerkdienst“ hat im Netzwerk die gleiche Identität (Computeridentität) wie das Konto „System“, aber im lokalen System sind seine Berechtigungen beschränkt. Wenn ein Dienst auf Netzwerkressourcen zugreifen muss (z. B. um Kontennamen mit dem Domänencontroller aufzulösen), muss er daher entweder als Konto „System“, als Domänenkonto oder als Konto „Netzwerkdienst“ ausgeführt werden. Letzteres ist normalerweise die sicherste Wahl, weil er dann auf ein lokales System begrenzt ist und selbst dort nur über beschränkte Berechtigungen verfügt.
Das Konto „Netzwerkdienst“ in SQL Server zu einem Systemadministratorkonto zu machen, hat zur Folge, dass jeder andere Dienst, der in einem lokalen System als Netzwerkdienst ausgeführt wird, vollständige Kontrolle über den Server hat. Dies geschieht z. B. dann, wenn das SQL Server-Dienstkonto dafür konfiguriert wird, als Netzwerkdienst ausgeführt zu werden. Ein SQL Server-Dienstkonto zu einem Mitglied des Systemadministratorkontos zu machen, ist für die Funktionalität des Servers erforderlich (z. B. um Loopbackverbindungen zu ermöglichen). Während es unter dem Gesichtspunkt der Sicherheit nicht ratsam ist, das Konto „Netzwerkdienst“ in SQL Server als Administratorkonto auszuführen, kann dies eventuell, aber nicht unbedingt, besser sein, als zu diesem Zweck ein Domänenkonto zu verwenden, und es ist viel sicherer, als SQL Server als „LocalSystem“ auszuführen.
Wenn Sie nicht wollen, dass das Konto „Netzwerkdienst“ Systemadministratorberechtigungen besitzt, sollten Sie als Nächstes in Erwägung ziehen, ein Domänenkonto zu verwenden, das speziell dafür vorgesehen ist, SQL Server unter einer oder mehreren Installationen von Windows NT® auszuführen.
Die folgenden Artikel bieten hierzu weitere Informationen: msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp und microsoft.com/technet/security/topics/serversecurity/serviceaccount.

Erstellen mehrerer Datenbanken

F: Ich habe vor, Daten in einzelne Datenbanken aufzuteilen. Ich denke dabei an bis zu 250 Datenbanken, die gleichzeitig online sind. Ich schätze, dass zu einem gegebenen Zeitpunkt nur 20 Prozent für aktive Abfragen verwendet werden. Sind mehr Datenbanken besser als weniger?

A: Die Anzahl der Datenbanken innerhalb einer Datenbankserverinstanz sollte von Geschäftsanforderungen und Verwaltungsaspekten bestimmt werden. Es erfordert nur wenig Aufwand, innerhalb einer einzelnen Serverinstanz mehrere Datenbanken zu erstellen, aber mehr Datenbanken bedeuten auch mehr Verwaltungsaufwand bei Wartungsaufgaben wie z. B. Sicherung und Wiederherstellung, Spiegelung und der Verwaltung von Benutzerkonten und Benutzerrollen. Der Nachteil des zusätzlichen Verwaltungsaufwands könnte die Vorteile, die zusätzliche Datenbanken bieten, überwiegen.
Als Grundregel sollten alle auf eine Anwendung bezogenen Daten in einer einzigen Datenbank verwaltet werden, weil dies die Wiederherstellung nach einem Fehler oder Ausfall leichter macht. Wenn die Daten einer Anwendung über mehrere Datenbanken verteilt sind, müssen bei einem Failover alle Datenbanken wiederhergestellt werden. Dies kann die Wiederherstellung verzögern oder sie dann, wenn eine der Datenbanken nicht wiederhergestellt werden kann, sogar verhindern.
Abgesehen davon kann es natürlich gute Gründe dafür geben, Daten auf mehrere Datenbanken zu verteilen:
  • Für eine Teilmenge der Daten gelten andere Sicherungsanforderungen als für andere Daten.
  • Bestimmte Daten erfordern einen getrennten Sicherheitskontext, d. h. einen anderen Datenbankbesitzer.
  • Manchmal dienen Daten Verlaufszwecken und müssen schreibgeschützt sein.

Unser Dank gilt den folgenden Microsoft-IT-Experten für ihre fachliche Unterstützung: Ramon Arjona, Frank De Waelle, Robert Djabarov, Herman Learmond-Criqui, Maxwell Myrick, Ruslan Ovechkin, Uttam Parui, Shashi Ramaka, Gary Roos, Gavin Sharpe, Vijay Sirohi, Jimmie Thompson und Madhusudhanan Vadlamaani.


 Hey, Scripting Guy!: Wo Sind die Becherhalter?
Hey, Scripting Guy!
Wo Sind die Becherhalter?
Die Scripting Guys von Microsoft
Dieser Artikel basiert auf einer Vorabversion von Windows PowerShell. Die in diesem Artikel enthaltenen Informationen können jederzeit geändert werden.

Wenn eine neue Technologie eingeführt wird, dauert es in der Regel eine Weile, bis die Leute die neue Technologie von dem unterscheiden können, was vorher da war. Denken Sie beispielsweise an die ersten Automobile. Es gibt einen Grund, warum diese Maschinen als pferdelose Kutschen bezeichnet wurden: Dieser Begriff beschreibt diese frühen Fahrzeuge recht gut. Wenn Sie sich die ersten Automobile genauer ansehen, werden Sie bemerken, dass der einzige Unterschied zwischen den ersten Automobilen und den Pferdekutschen nur die Tatsache war, dass die Kutschen von Pferden gezogen wurden und die Automobile nicht. Davon abgesehen ließen sie sich nur schwer auseinander halten.
Heutzutage würden natürlich nur sehr wenige Leute ein Automobil mit einer Pferdekutsche verwechseln. Das liegt daran, dass im Lauf der Zeit die Automobilhersteller Dinge getan haben, die ihre Autos deutlich von Kutschen unterscheiden. Beispielsweise werden die Autos von heute bereits in der Fabrik mit CD-Playern, Klimaanlagen und Satellitennavigationssystemen ausgestattet, was nur von wenigen Pferdekutschen gesagt werden kann. Nehmen Sie einmal an, Sie fahren im Jahr 1880 in einer Pferdekutsche und möchten Ihren Pappbecher mit Frappuccino kurz absetzen: Nun, da haben Sie leider Pech. Viele Automodelle von heute dagegen sind standardmäßig mit bis zu 17 Becherhaltern ausgestattet, und es gibt mindestens ein Automodell, das alleine für den Fahrer 3 Becherhalter besitzt. Einige der neueren Modelle haben sogar Becherhalter, die Ihr Getränk je nach Bedarf erhitzen oder abkühlen können.
Hinweis Ja, es ist wirklich kaum zu glauben, dass die Leute einmal ohne die Möglichkeit auskommen mussten, beim Fahren drei verschiedene Getränke zu sich zu nehmen. Wie soll man denn fahren können, wenn einem nur ein oder zwei Getränke zur Verfügung stehen?
Bevor sich eine neue Technologie wirklich erfolgreich durchsetzen kann, müssen die Leute wissen, warum sie das Neue und Unbekannte dem Alten und Bewährten vorziehen sollen. Als DVDs auf den Markt kamen, machten sie es möglich, sich genau wie mit Videorekordern Kinofilme zu Hause anzusehen. Allerdings waren DVDs wesentlich teurer als Videokassetten, und man konnte mit einem DVD-Player Filme nicht aufnehmen. DVDs haben also die Welt nicht gerade im Sturm erobert. Erst als die DVD-Hersteller auf ihren DVDs auch gelöschte Szenen, Kommentare von Schauspielern, die man im Film überhaupt nicht bemerkt hatte, und andere Dinge unterbrachten, die eine Videokassette nicht bieten kann, begannen DVDs, ihre Vorläufer zu verdrängen. Sich zu Hause einen Film ansehen zu können, war noch nicht genug. Die Hersteller von DVDs mussten mehr Möglichkeiten bereitstellen, als den Leuten bereits durch Videokassetten geboten wurden.
Hinweis Ob dieses Bonusmaterial überhaupt jemals von den Leuten genutzt wird, ist dabei nebensächlich: Es liegt nun einmal in der Natur des Menschen, etwas, das verfügbar ist, unbedingt haben zu wollen. Übrigens spielen die Scripting Guys mit dem Gedanken, eine DVD herauszubringen, die hauptsächlich gelöschten Text aus Artikeln des TechNet Magazins und alternative Versionen von Skripts für die Systemverwaltung enthält.

Verwenden von Windows PowerShell
Windows PowerShell™, die von Microsoft veröffentlichte neue Befehlsshell- und Skriptingtechnologie, ist ein weiteres Beispiel für dieses Phänomen. Wenn die Leute zum ersten Mal von Windows PowerShell hören, erfahren sie in der Regel folgende Dinge:
  • "Mit Windows PowerShell kann man Prozesse und Dienste verwalten."
  • "Mit Windows PowerShell kann man aus Ereignisprotokollen Ereignisse abrufen."
  • "Mit Windows PowerShell kann man WMI zur Verwaltung von Computern nutzen."
Nun, daran ist ja nichts verkehrt. Das sind alles nützliche und wichtige Aufgaben. Das Problem ist nur, dass man alle diese Aufgaben bereits mit VBScript und Windows Script Host erledigen kann. Abwärtskompatibilität ist wichtig, und Windows PowerShell würde keine besonders gute Innovation darstellen, wenn es nicht dieselben Dinge wie VBScript beherrschen würde. (Stellen Sie sich einen DVD-Player vor, mit dem man sich keine Filme ansehen kann. Aber eigentlich brauchen Sie sich das gar nicht vorzustellen: Einer der Scripting Guys hat einen dieser DVD-Player zu Hause stehen.)
Andererseits denkt man natürlich, warum sollte man sich mit dieser neuen Technologie überhaupt befassen, wenn Windows PowerShell lediglich dieselben Dinge tun kann, die sich bereits mit VBScript bewerkstelligen lassen? Zugegeben: VBScript bietet keine Becherhalter, aber das tut Windows PowerShell auch nicht. Welchen Unterschied macht es also, welche Skriptingtechnologie wir verwenden?
Um ehrlich zu sein, macht es unter Umständen nicht den geringsten Unterschied. Andererseits – vom Fehlen der Becherhalter einmal abgesehen – bietet Windows PowerShell einige Möglichkeiten, mit denen VBScript nicht aufwarten kann. Wenn Sie lediglich Prozesse und Dienste verwalten müssen, besteht für Sie kein zwingender Grund, sich Windows PowerShell genauer anzusehen, denn wie heißt es so schön: Wenn etwas nicht kaputt ist, dann repariere es auch nicht. (Was die Scripting Guys anbelangt, sollte man diese Redewendung ein wenig abwandeln und stattdessen sagen: „Jungs, versucht ja nicht, das Ding zu reparieren, sonst ist es hinterher kaputt.“) Wirklich interessant wird Windows PowerShell dann, wenn Sie damit etwas machen können, zu dem VBScript nicht in der Lage ist. Nehmen wir zum Beispiel die Möglichkeit, den Zeitpunkt des letzten Schreibzugriffs zu ändern.

Ändern des Zeitpunkts des letzten Schreibzugriffs
Sie haben richtig gehört: Die Änderung des Zeitpunkts des letzten Schreibzugriffs für eine Datei. Aus verschiedenen Gründen (z. B. als schnelle, einfache Methode der Versionskontrolle) haben Skriptentwickler immer von dem Tag geträumt, an dem sie einmal in der Lage sein werden, den Zeitpunkt des letzten Schreibzugriffs (also die Erstellungszeit) einer Datei oder einer Gruppe von Dateien zu ändern. Leider muss gesagt werden, dass diese Möglichkeit weder von WMI (der Windows-Verwaltungsinstrumentation) noch von FileSystemObject geboten wird. Bei beiden Technologien sind die Datums- und Uhrzeitangaben von Dateien schreibgeschützt.
Bei Windows PowerShell dagegen ist das Ersetzen des Zeitpunkts des letzten Schreibzugriffs auf eine Datei durch das aktuelle Datum und die aktuelle Uhrzeit so leicht wie das Ausführen des folgenden Befehls:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Bevor wir erklären, wie dieser Befehl funktioniert, wollen wir eine Frage beantworten, die wahrscheinlich jedem auf der Zunge brennt: Wie kann Windows PowerShell den Zeitpunkt des letzten Schreibzugriffs auf eine Datei ändern, wenn WMI das nicht kann? Wir haben uns gedacht, dass wir zuerst diese Frage behandeln sollten, bevor wir etwas anderes tun, denn hier liegt ein häufiges Missverständnis in Bezug auf Windows PowerShell begraben. Die Leute neigen dazu anzunehmen, dass Windows PowerShell nichts weiter als eine neue Methode darstellt, WMI zu verwenden. Natürlich können Sie Windows PowerShell auch dazu verwenden, auf WMI-Daten zuzugreifen. Wahr ist auch, dass, während wir auf die Bereitstellung weiterer Cmdlets (systemeigener Windows PowerShell-Befehle) warten, die meisten Skripts sich für die Systemverwaltung weiterhin auf WMI verlassen. Der springende Punkt ist jedoch, dass Windows PowerShell auf .NET Framework basiert und dass die Cmdlets von Windows PowerShell mit .NET-Objekten statt mit WMI-Objekten arbeiten. Dieser Punkt ist wichtig, denn die Eigenschaften, die über .NET Framework verfügbar sind, sind nicht unbedingt dieselben Eigenschaften, die über WMI verfügbar sind.
Wenn wir beispielsweise das Cmdlet „Get-Item“ verwenden, um eine Datei zu binden, erhalten wir als Ergebnis keine Instanz der WMI-Klasse „CIM_Datafile“, sondern ein .NET-Objekt. Macht das wirklich einen so großen Unterschied? Aber natürlich, denn das .NET-Objekt bietet eine etwas andere Gruppe von Eigenschaften und Methoden für die Dateiverwaltung als WMI. Wie wir gerade gesehen haben, können diese geringfügigen Unterschiede sehr wichtig sein, wie zum Beispiel der Unterschied zwischen einer Schreibschutz-Eigenschaft und einer Schreiben/Lesen-Eigenschaft.
Eine kleine Zwischenfrage: Woher wissen wir eigentlich, dass das Cmdlet „Get-Item“ ein .NET-Objekt zurückgibt? Wie in den meisten Fällen lässt sich auch in diesem Fall am leichtesten herausfinden, mit welcher Art von Objekt wir es zu tun haben (und welche Eigenschaften und Methoden uns dadurch zur Verfügung stehen), indem wir es an die Datei binden und dieses Objekt anschließend dem Cmdlet „Get-Member“ übergeben:
Get-Item c:\scripts\test.txt | Get-Member
Die Ergebnisse dieses Befehls sind in Abbildung 1 zu sehen. Wie Sie sehen können, handelt es sich tatsächlich um ein .NET-Objekt. Dachten Sie denn, die Scripting Guys hätten in diesem Punkt etwas falsch gemacht?
Figure 1 Mitglieder des von Get-Item zurückgegebenen Objekts (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
Übrigens veranschaulicht dieser kleine Befehl zwei der interessantesten (und nützlichsten) Fähigkeiten von Windows PowerShell: Pipelining und Metadaten. Wir werden heute zwar nicht auf technische Einzelheiten eingehen, aber das Grundkonzept von Pipelining besteht darin, dass Sie mit einem Cmdlet auf ein Objekt zugreifen und dieses Objekt anschließend einem anderen Cmdlet übergeben. In diesem Befehl haben wir das Cmdlet „Get-Item“ dazu verwendet, ein Objekt abzurufen, das die Datei C:\Scripts\Test.txt repräsentiert, und anschließend dieses Objekt (als Objekt) über die Pipeline dem Cmdlet „Get-Member“ übergeben. (Die Pipeline wird in einem Windows PowerShell-Befehl durch das Symbol | repräsentiert.)
Danach macht „Get-Member“ seine Arbeit, die daraus besteht, die Eigenschaften und Methoden für das abgerufene Objekt abzurufen. Dies ist eines der anderen tollen Features von Windows PowerShell: Es ist sehr leicht, auf Metadaten zuzugreifen, also auf Informationen über Informationen. Mit Cmdlets wie „Get-Member“ und „Get-Command“ können Sie Windows PowerShell so intensiv ins Kreuzverhör nehmen, wie Sie wollen, ungefähr so, wie Sie ein WMI-Skript schreiben können, um Informationen über die Ihnen zur Verfügung stehenden WMI-Klassen, Eigenschaften und Methoden abzurufen.
Beachten Sie dabei jedoch, dass „Get-Member“ noch mehr leistet, als mit WMI möglich ist. Sie können mit WMI zwar Informationen über WMI-Objekte abrufen, aber Sie können WMI nicht dazu verwenden, auf Informationen über andere COM-Objekte (z. B. FileSystemObject) zuzugreifen. Dies ist bei Windows PowerShell nicht der Fall. „Get-Member“ funktioniert mit jedem Objekt, das Sie binden oder erstellen können. Können Sie sich nicht mehr an die Methoden erinnern, die Ihnen zur Verfügung stehen, wenn Sie FileSystemObject verwenden? Dann führen Sie den folgenden Befehl aus:
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
Dies ist eine unglaublich nützliche und daher bei weitem noch nicht voll ausgenutzte Fähigkeit.
Nett, nicht wahr? Wenn wir durch die Liste der Eigenschaften und Methoden scrollen, die uns bei der Arbeit mit der Datei C:\Scripts\Test.txt zur Verfügung stehen, stoßen wir auf folgende Zeile:
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
Interessant. Offenbar ist „LastWriteTime“ eine Eigenschaft, die sowohl „Get“ (Lesen) als auch „Set“ (Schreiben) unterstützt. Bedeutet dies, dass wir Windows PowerShell dazu verwenden können, den Wert für den Zeitpunkt des letzten Schreibzugriffs auf eine Datei zu ändern? Hmmm ...
Glossar zu Windows PowerShell
Alias Ein individuell anpassbarer Name, der ein vorhandenes Cmdlet repräsentiert. Windows PowerShell stellt mehrere Standardaliase bereit, mit denen allgemeine Shellbefehle ihren Cmdlet-Entsprechungen zugeordnet werden.
Cmdlet Die kleinste funktionale Einheit in Windows PowerShell, die den integrierten Befehlen anderer Shells entspricht.
Befehl Eine Ausführungseinheit in Windows PowerShell. Befehle können mehrere Pipeliningvorgänge beinhalten und sich mithilfe des Semikolons (;) über mehrere Zeilen erstrecken.
Frappuccino Ein Kaffee-Mixgetränk mit Eis, das von Starbucks und anderen Cafés verkauft wird.
Monad/MSH/Microsoft-Befehlsshell Ehemalige Codenamen für Windows PowerShell.
Objekt Vom System oder von einem Befehl abgerufene strukturierte Daten. Windows PowerShell verarbeitet Daten als .NET-Objekte und ermöglicht Ihnen, auf Objekteigenschaften nach Namen zuzugreifen, statt textorientierte Befehlausgaben analysieren zu müssen.
Parameter Optionen, die für ein Cmdlet in der Befehlszeile eingestellt werden können. Windows PowerShell verwendet einen einleitenden Bindestrich (-), um einen Parameter als solchen zu kennzeichnen.
Pipeline Pipelines ermöglichen, die Ausgabe eines Befehls als Eingabe an einen anderen Befehl weiterzugeben. Eine Pipeline wird auch kurz als „Pipe“ bezeichnet und in Befehlen durch das Zeichen | dargestellt.
Profil Einstellungen, die beim Starten von Windows PowerShell geladen werden und Ihnen ermöglichen, die Arbeitsweise der Shell zu konfigurieren.
Skript Einer oder mehrere Befehle, die als Datei gespeichert und über eine Datei ausgeführt werden. Windows PowerShell verwendet für Skriptdateien die Namenserweiterung „.ps1“.
Shell Eine Befehlszeilenumgebung, in der sowohl Befehle als auch Cmdlets ausgeführt werden können.
Variable Ein Objekt oder Parameter, dessen Wert bei der Ausführung eines Befehls festgelegt, geändert oder abgerufen werden kann.

Kehren wir jetzt zum Ausgangspunkt zurück, und reden wir über den Befehl, der das aktuelle Datum und die aktuelle Uhrzeit als den Zeitpunkt des letzten Schreibzugriffs auf die Datei Test.txt einstellt. Er sieht folgendermaßen aus:
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
Wie Sie sehen können, ist dieser Befehl wirklich nichts Besonderes. Zunächst deklarieren wir eine Variable namens „$a“. Danach verwenden wir das Cmdlet „Get-Item“, um eine Verbindung zur Datei C:\Scripts\Test.txt herzustellen. Anschließend speichern wir dieses Objekt in der Variable $a. Nach der Eingabe eines Semikolons, das uns ermöglicht, in einer einzigen Zeile mehrere Befehle auszuführen, stellen wir den Wert der Eigenschaft „LastWriteTime“ auf das aktuelle Datum und die aktuelle Uhrzeit ein. Das macht das Fehlen von Becherhaltern fast wieder wett, nicht wahr?

Zu den Feinheiten
Selbstverständlich sind Sie nicht darauf beschränkt, den Zeitpunkt des letzten Schreibzugriffs auf das aktuelle Datum und die aktuelle Uhrzeit einzustellen. Betrachten Sie beispielsweise diesen Befehl:
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
Diesmal haben wir drei Befehle miteinander verkettet. Zunächst erstellen wir mit dem Cmdlet „Get-Date“ ein Datum/Uhrzeit-Objekt für den Zeitpunkt 22.05.2006, 20:15 Uhr. Wieso mussten wir in unserem ersten Skript, in dem der Zeitpunkt des letzten Schreibzugriffs auf das aktuelle Datum und die aktuelle Uhrzeit eingestellt wurde, nicht das Cmdlet „Get-Date“ verwenden, um ein Datum/Uhrzeit-Objekt zu erstellen? Die Antwort ist ganz einfach: Der Befehl „Date“ gibt automatisch ein Datum/Uhrzeit-Objekt zurück. (Um sich selbst davon zu überzeugen, geben Sie in der Windows PowerShell-Konsole den folgenden Befehl ein: Date | Get-Member.)
Nachdem wir ein Datum/Uhrzeit-Objekt für das gewünschte Datum und die gewünschte Uhrzeit erstellt haben, verwenden wir nun den uns mittlerweile vertrauten Befehl „Get-Item“, um ein Objekt abzurufen, das die Datei „Test.txt“ repräsentiert (ein Objekt, das wir in der Variable $a speichern). Zum Schluss stellen wir die Eigenschaft „LastWriteTime“ auf den Wert ein, der durch die Variable $b repräsentiert wird:
$a.LastWriteTime = $b
Ob Sie es glauben oder nicht: Sie haben bisher noch nicht einmal die Hälfte gesehen. Werfen Sie einen Blick auf diesen harmlos aussehenden Befehl:
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
Was an diesem Befehl so interessant ist? Nun, schauen wir uns einmal an, was er macht. Der erste Teil ist leicht: Wir erstellen wieder ein Datum/Uhrzeit-Objekt, das dem Zeitpunkt 22.05.2006, 20:15 Uhr entspricht. Beachten Sie jedoch, dass wir im zweiten Teil nicht das Cmdlet „Get-Item“, sondern folgenden Befehl verwenden:
Get-ChildItem c:\scripts
Was das soll? Nun, bei jeder Anwendung des Cmdlets „Get-ChildItem“ auf einen Ordner wird eine Sammlung aller in diesem Ordner enthaltenen Dateien zurückgegeben. Wir werden diese Sammlung nehmen und anschließend alle darin enthaltenen Elemente über die Pipeline (da ist dieses Symbol | wieder) dem Cmdlet „ForEach-Object“ übergeben.
Und was macht das Cmdlet „ForEach-Object“ mit all diesen Dateien? Na, es wird natürlich für jede einzelne Datei den Wert der Eigenschaft „LastWriteTime“ ändern:
ForEach-Object {$_.LastWriteTime = $b}
Hinweis Obwohl der Artikel dieses Monats kein Einsteigerlehrgang für Windows PowerShell sein soll, sollten wir darauf hinweisen, dass es sich bei „$_“ um eine Spezialvariable handelt, die das aktuelle Element in einer „For Each“-Schleife repräsentiert. Dies entspricht „objItem“ in der folgenden VBScript-Schleife:
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
Wenn die Ausführung unseres Windows PowerShell-Befehls abgeschlossen ist, haben alle Dateien im Ordner C:\Scripts denselben Zeitpunkt des letzten Schreibzugriffs. Das soll uns eine dieser neuartigen pferdelosen Kutschen erst einmal nachmachen!
Wir könnten die ganze Nacht lang eine Variante dieses Befehls nach der anderen ausführen. Möchten Sie beispielsweise den Zeitpunkt des letzten Schreibzugriffs nur bei den TXT-Dateien des Ordners C:\Scripts ändern? Ganz wie Sie wünschen:
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

Kleiner Appetitanreger
Das ist wirklich toll. Wir sollten jedoch anmerken, dass dieser Artikel nicht dem Zweck dient, Ihnen Windows PowerShell zu „verkaufen“, und wir möchten Sie auch nicht dazu ermutigen, Ihre gesamten VBScript-Skripts wegzuwerfen und sie alle durch Windows PowerShell zu ersetzen. Wenn Ihre Skripts das tun, wofür sie geschrieben wurden, dann sollten Sie sie in Ruhe lassen. Das gleiche gilt für Batchdateien, Befehlszeilenprogramme, Zaubersprüche und alle sonstigen Hilfsmittel, die Sie einsetzen, um Ihre Computer zu verwalten. Denken Sie daran: Wenn etwas nicht kaputt ist ...
Der springende Punkt ist nicht, dass Sie mit Windows PowerShell Dinge tun können, die Sie sowieso schon tun konnten, sondern dass Windows PowerShell – zum Teil deswegen, weil es einen Zugriff auf .NET Framework bereitstellt – Ihnen die Möglichkeit bietet, Dinge zu tun, die Sie vorher nicht tun konnten. Ein Beispiel dafür ist das Ändern des Zeitpunkts des letzten Zugriffs für eine Datei oder eine Gruppe von Dateien. Ob es noch weitere Beispiele dafür gibt, hängt davon ab, was Sie vorhaben. Es sind nämlich genau diese Möglichkeiten, die es die Mühe wert machen, sich Windows PowerShell genauer anzusehen.
Für viele von Ihnen war dies wahrscheinlich eine recht ungewöhnliche Einführung in Windows PowerShell: Schließlich haben wir ja nicht mit dem üblichen einfachen Beispiel der Bauart „Hallo Welt“ angefangen, sondern sind sofort mit einem aus mehreren Teilen bestehenden Windows PowerShell-Befehl eingestiegen und haben mit Begriffen wie „Pipeline“ und „Cmdlet“ um uns geworfen, als ob jeder wissen müsste, was wir damit meinen. Das haben wir absichtlich getan. Schließlich wissen wir ja, dass viele von Ihnen Windows PowerShell erst noch ausprobieren müssen. Wir befürchteten, wenn wir Ihnen zeigen, wie man eine Liste der Dienste auf einem Computer abrufen kann, würden Sie nur mit den Achseln zucken und sich wieder dem zuwenden, was Sie gerade getan haben.
Wir hoffen ja, dass Sie nicht gerade dabei waren, Auto zu fahren. Für viele von uns ist es schwer genug, beim Fahren drei Getränke zu trinken, sich eine DVD anzusehen und sich am Handy zu unterhalten, ohne gleichzeitig auch noch das TechNet Magazin zu lesen.
Na, regen Sie sich doch nicht gleich auf: Ich sagte doch „für viele von uns“. Nicht für alle von uns.

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


 SICHERHEIT AUF DEM PR&#220;FSTAND: Stellen Sie eine global vertrauensw&#252;rdige PKI bereit
SICHERHEIT AUF DEM PRÜFSTAND
Stellen Sie eine global vertrauenswürdige PKI bereit
John Morello
Dieser Artikel enthält vorläufige Informationen, die geändert werden können.

Eine Public Key-Infrastruktur (PKI) ist ein grundlegendes Element beim Aufbau von Vertrauen zwischen unterschiedlichen Anwendungen, Betriebssystemen und Identitätsbereichen. Es baut auf einem hierarchischen Vertrauensmodell auf, in dem Endeinheiten einem allgemeinen Schlüssel auf höchster Stammebene vertrauen, und daher wird allen anderen Schlüsseln, die von diesem Stamm signiert werden, implizit vertraut.
Aufgrund dieser Struktur kann eine gut entworfene PKI einfach skaliert werden, indem zusätzliche Zertifizierungsstellen (CAs) ohne eine Änderung der Endeinheiten hinzugefügt werden.
PKIs werden normalerweise auf eine von zwei Arten implementiert. Die gebräuchlichste Methode ist der Erwerb erforderlicher Zertifikate von einem der implizit vertrauenswürdigen globalen Stammanbieter, wie z. B. Cybertrust oder VeriSign. Diese Zertifikate werden häufig für die Sicherung von Datenverkehr auf Websites verwendet, können jedoch auch für die Verschlüsselung von virtuellen privaten Netzwerken (VPNs), die Signierung von E-Mail und ähnliche Aufgaben verwendet werden. Da diese globalen Stämme in jeden modernen Webbrowser und in jedes Betriebssystem integriert sind, kann diese Methode leicht eine Vertrauensstellung über Organisationsgrenzen hinweg schaffen. Da diese Zertifikate jedoch auf einer Bedarfsbasis erworben werden, kann dieser Ansatz für eine weit verbreitete Implementierung innerhalb einer großen Organisation kostspielig sein.
Das interne PKI-Modell ist in letzter Zeit immer häufiger verwendet. Wie der Name sagt, wird einer internen PKI nur innerhalb eines organisationseigenen Netzwerks vertraut. Dieses Modell bietet eine kostengünstigere Lösung für eine Organisation, um jeden Benutzer und Computer im Netzwerk mit Zertifikaten auszustatten. Dieser Ansatz wird häufig verwendet, um Technologien wie Smartcard-Anmeldung, verschlüsselndes Dateisystem (EFS, Encrypting File System) und sicheres, drahtloses Netzwerk zu ermöglichen. Der Nachteil ist, dass diese Zertifikate nicht für nach außen gerichtete Anwendungen geeignet sind, da sie nicht global vertrauenswürdig sind. Folglich setzen die meisten Organisationen, die interne PKIs implementieren, einen kombinierten Ansatz ein und erwerben Zertifikate für öffentliche Anwendungen von einem der global vertrauenswürdigen Stämme.
Aber wie wäre es, wenn Sie das Beste beider Ansätze haben könnten? Was wäre, wenn Ihre Organisation ihre eigene PKI ausführen könnte – mit der Kostenersparnis, die Sie durch Ausgabe interner Zertifikate erzielen können – und gleichzeitig öffentlich vertrauenswürdige Zertifikate bereitstellen kann, und das alles von Ihrem lokalen System aus? So eine Lösung würde die Vorteile von einer internen PKI bieten (wie Active Directory®-Integration, automatische Registrierung und lokalisierten IT-Support), während der Kernvorteil eines global vertrauenswürdigen Stamms zur Verfügung gestellt wird. Die Louisiana State University (LSU) verfügt über genau so ein System. In dieser Ausgabe von „Sicherheit auf dem Prüfstand“ wird die Lösung, die an der LSU implementiert wurde, genau unter die Lupe genommen, das technische Design wird diskutiert, und die Best Practices für die Bereitstellung eines ähnlichen Systems werden vorgestellt. Dabei sollte beachtet werden, dass die hier beschriebene Lösung die speziellen Anforderungen der gegebenen Umgebung, Ressourcen und Geschäftsanforderungen erfüllt. Untersuchen Sie alle Aspekte Ihres Geschäfts im Voraus, um den Lösungstyp zu bestimmen, der für Sie geeignet ist.

Verwendung der PKI an der LSU
Die LSU ist eine wichtige Forschungsuniversität mit über 40.000 Studenten, Lehrenden und sonstigen Mitarbeitern. Es verfügt über zahlreiche öffentliche Websites, von denen viele Transport Layer Security erfordern, der ordnungsgemäße Begriff für SSL-Zertifikate (Secure Sockets Layer). Die LSU gab jedes Jahr tausende von Dollar für Zertifikate der global vertrauenswürdigen Stammanbieter aus.
Abgesehen davon hatte die LSU weitere IT-Sicherheitsziele, die von einer optimal entworfenen, internen PKI profitieren konnten. In Anbetracht der Ziele und Anforderungen der LSU hätten Sie vielleicht erwartet, dass wir ein Hybridmodell ausgewählt hätten. Stattdessen haben wir uns für einen innovativeren Ansatz entschieden.
Wir haben gemeinsam mit einem der global vertrauenswürdigen Stämme, Cybertrust, eine Zertifizierungsstelle auf dem LSU-Gelände bereitgestellt, die einer Cybertrust-Stammzertifizierungsstelle untergeordnet ist (siehe Abbildung 1). Cybertrust bietet diesen Dienst in seinem OmniRoot-Programm an. In diesem Szenario erstellt und betreibt die LSU eine Zertifizierungsstelle, die lokal auf LSU-eigener Technik ausgeführt wird. Im Unterschied zum an früherer Stelle beschriebenen, internen Modell ist die Zertifizierungsstelle von LSU nicht selbst signiert, und ihrem Schlüssel (einschließlich aller, die sie signiert) wird von nahezu allen modernen Betriebssystemen und Browsern implizit vertraut. Genau genommen ist dieses Design eine logische Erweiterung der Offenheit der x.509-Standards. Da eine PKI auf diesen Standards aufbaut, ist es möglich, von verschiedenen Herstellern erstellte Systeme in dieselbe Gesamthierarchie zu integrieren. Besonders interessant bei der OmniRoot-Lösung sind dabei die Nutzungebedingungen für den Dienst.
Abbildung 1 Globales Cybertrust-Stammzertifikat
Abbildung 1 Globales Cybertrust-Stammzertifikat (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 1 Globales Cybertrust-Stammzertifikat
Abbildung 1 Globales Cybertrust-Stammzertifikat (Klicken Sie zum Vergrößern auf das Bild)
Der OmniRoot-Dienst ist speziell für die Art von PKI-Bereitstellung entworfen, die an der LSU implementiert wurde. Im OmniRoot-Programm zahlen Organisationen eine festgelegte jährliche Gebühr an Cybertrust für die Beteiligung am Programm und zahlen zusätzlich eine Gebühr pro Zertifikat für die Zertifikate, die für die öffentliche Verwendung erstellt werden. Anders gesagt kann die LSU so viele Zertifikate ausstellen, wie für die interne Verwendung erforderlich sind, ohne sich Sorgen über die auflaufenden Kosten pro Zertifikat zu machen. Mittlerweile sind die Kosten der öffentlichen Zertifikate nun erheblich günstiger als zu dem Zeitpunkt, als die Universität Zertifikate nach Bedarf erwerben musste.
Um jegliche Verwirrung zu vermeiden – die internen Zertifikate und die öffentlichen Zertifikate sind vom technischen Standpunkt aus gesehen identisch. Sie werden von derselben Zertifizierungsstellenkette ausgestellt, verfügen über dieselben kryptografischen Stärken und werden von demselben Registrierungsstellensystem bereitgestellt. Der einzige Unterschied zwischen den beiden Zertifikaten liegt in den Bestimmungen des Lizenzvertrags.
Es war uns letzten Endes möglich, die IT-Sicherheitsplattform der LSU zu geringeren Kosten zu erweitern und zu verbessern. Diese Art von PKI-Lösung war für die LSU ein großer geschäftlicher Erfolg. Im Folgenden finden Sie eine genauere Betrachtung der technischen Einzelheiten der Bereitstellung.

PKI-Hierarchie
Die PKI-Hierarchie der LSU baut auf einem zweistufigen Design auf, wobei die Stammstufe von Cybertrust verwaltet wird und sich die ausstellenden Onlinezertifizierungsstelle an der LSU befindet (siehe Abbildung 2). Die Stammstufe bildet den Kern des Vertrauens in der Hierarchie. Mit anderen Worten, die Vertrauensstellung aller Zertifikate, die von einer beliebigen Zertifizierungsstelle in der Hierarchie ausgestellt werden, fällt unter die Stammzertifizierungsstelle (siehe Abbildung 3). Folglich bildet die Stammzertifizierungsstelle die gemeinsame Verbindung zwischen allen Zertifizierungsstellen, Zertifikaten und Endeinheiten in der Hierarchie. Da der globale Cybertrust-Stamm bereits in Windows® und praktisch jedes sonstige moderne Computersystem integriert ist, geht diese gemeinsame Verbindung automatisch über das LSU-Netzwerk hinaus.
Figure 2 Zweistufige PKI-Hierarchie (Close Figure 2)

Stammstufe (Cybertrust) | Ausstellende Stufe (LSU)
Verwaltet durch Cybertrust | Verwaltet durch die LSU
Befindet sich im sicheren Datacenter von Cybertrust | Befindet sich auf dem Baton Rouge-Campus der LSU
Im Standardstammzertifikat fast aller modernen Computersysteme enthalten | Stellt Zertifikate für Endeinheiten innerhalb von LSU-Systemorganisationen aus
 | Zertifikate, die von der LSU ausgegeben werden, gehören zum Cybertrust-Stamm und sind daher global vertrauenswürdig
Abbildung 3 Von der ausstellenden Zertifizierungsstelle der LSU ausgestelltes Zertifikat
Abbildung 3 Von der ausstellenden Zertifizierungsstelle der LSU ausgestelltes Zertifikat (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 3 Von der ausstellenden Zertifizierungsstelle der LSU ausgestelltes Zertifikat
Abbildung 3 Von der ausstellenden Zertifizierungsstelle der LSU ausgestelltes Zertifikat (Klicken Sie zum Vergrößern auf das Bild)
Cybertrust verwaltet die Stammzertifizierungsstelle in einer seiner sicheren Hosteinrichtungen. Die Hosteinrichtung verwendet leistungsstarke physische Sicherheitseinrichtungen, einschließlich Schleusen, biometrischer Schlösser und eines vollständig mit Kupfer ummantelten Speichertresors. Cybertrust stellt Zertifikate nur für die ausstellenden Zertifizierungsstellen von Organisationen aus, die eine Kompatibilität mit seinen Sicherheits- und Zertifikatrichtlinien demonstriert haben.
Die ausstellende Zertifizierungsstelle der LSU ist ein auf die Endeinheit ausgerichtetes System, das verantwortlich ist für die Bereitstellung von Zertifikaten für die Benutzer und Computer der LSU. Ihr Zertifikat wird von der in der Hierarchie übergeordneten Cybertrust-Zertifizierungsstelle signiert und gibt Zertifikate aus, die bis zur Cybertrust-Stammzertifizierungsstelle verkettet sind (siehe Abbildung 3).

Ausstellendes Betriebssystem und ausstellende Hardware
Die LSU verwendet Windows Server® 2003 Enterprise Edition mit Service Pack 1 für seine ausstellende Zertifizierungsstelle. Der Windows Server 2003-Zertifizierungsstellendienst bietet zahlreiche neue Funktionen, einschließlich Schlüsselarchivierung, Deltazertifikatssperrlisten (CRLs) und "Version 2"-Vorlagen. Die Instanz von Windows, die als die ausstellende Zertifizierungsstelle verwendet wird, ist gemäß der Windows Server-Standardbuildrichtlinie der LSU aufgebaut. Sie ist mit allen relevanten Sicherheitsupdates aktualisiert und wird mithilfe der standardmäßigen LSU-Änderungsverwaltungsmethoden und Softwareinventur- und Aktualisierungstools verwaltet. Kurz gesagt, während es bestimmte einmalige Aspekte für die Verwaltung des Zertifizierungsstellendienstes an sich gibt, werden die grundlegende Serverhardware und das Betriebssystem einfach in die in der Organisation vorhandenen IT-Vorgänge integriert.
Abgesehen vom Befolgen der standardmäßigen Best Practices der LSU für eine Serverinstallation wurden die Vorteile des Sicherheitskonfigurations-Assistenten (SCW) genutzt, der in Windows Server 2003 Service Pack 1 verfügbar ist. Der SCW verwendet eine Datenbank, die Abhängigkeitsmatrizen der verschiedenen Arbeitslasten enthält, die unter Windows Server ausgeführt werden können, sowie die Sicherheitseinstellungen, die diese Arbeitslasten erfordern. Diese Datenbank enthält die zwei primären Rollen, die die Zertifizierungsstelle bereitstellen wird – den Zertifizierungsstellendienst selbst und IIS (das die PKI-benutzerverantwortliche Website enthält).
Mithilfe des SCW wurde ganz einfach eine Sicherheitsvorlage erstellt, die alle Dienste außer denen deaktiviert hat, die für die Ausführung dieser Arbeitslasten erforderlich sind, und der Netzwerkstapel des Servers wurde abgesichert. Daraufhin wurde scwcmd.exe verwendet, um diese Vorlage in ein Gruppenrichtlinienobjekt (GPO) zu verwandeln, sodass es auf den Server auf Organisationseinheitsebene angewendet werden konnte. Diese Methode vereinfacht das Skalieren und die Notfallwiederherstellung, seit die rollenbasierte Sicherheitskonfiguration für eine LSU-Zertifizierungsstelle in Active Directory gespeichert wird, statt computerspezifisch zu sein.
Die ausstellende Zertifizierungsstelle der LSU basiert auf einem IBM xSeries 346-Server mit doppelten 3,2 GHz-Intel Xeon-Prozessoren, 4 GB Arbeitsspeicher und fünf 146 GB-SCSI-Festplatten. In Anbetracht der Leistungsanforderungen des Zertifizierungsstellendienstes und der Tatsache, dass LSU ein Hardwaresicherheitsmodul verwendet, bietet diese Plattform große Langlebigkeit und Wachstumsspielraum.
Es wurden standardmäßige Best Practices für eine Trennung der Datenbanken und Protokolldateien in separate physische Spindles befolgt, indem zwei RAID 1-Arrays erstellt wurden. Die fünfte Festplatte wird als „Hot Spare“ aufgehoben und ist für eines dieser beiden Arrays verfügbar. Das erste Array wurde als Systemvolume installiert, auf dem die Zertifizierungsstellendatenbank aufbewahrt wird. Das zweite Array wird für Protokolldateien und zahlreiche andere Datendateien wie die CRLs verwendet. Die Zertifizierungsstellendatenbank basiert auf derselben Jet-Technologie, die in anderen Bereichen von Windows gefunden werden kann, wie Active Directory. Deshalb finden werden hier dieselben Best Practices wie für Verwaltung und Datenträgerkonfiguration anderer Jet-basierter Speicherlösungen angewendet.
Ein Hardwaresicherheitsmodul (HSM) ist ein dediziertes Hardwaregerät, das getrennt vom Betriebssystem verwaltet wird. HSMs werden normalerweise als PCI-Adapter zur Verfügung gestellt, sind jedoch auch als netzwerkbasierte Geräte verfügbar. Diese Module stellen einen sicheren Hardwarespeicher für Zertifizierungsstellenschlüssel sowie einen dedizierten kryptografischen Prozessor zur Beschleunigung von Signier- und Verschlüsselungsvorgängen zur Verfügung. Windows verwendet das HSM über die CryptoAPI-Schnittstellen. Das HSM wird als kryptografisches Dienstanbieter (CSP)-Gerät betrachtet. Das OmniRoot-Programm erfordert, dass jede Zertifizierungsstelle mindestens ein FIPS 140-2-zertifiziertes HSM der Ebene 3 (Geräte der Ebene 4 sind ziemlich selten) für Schlüsselgenerierung und Speicherung verwendet. Als einmaliges und extrem sicheres Gerät erfordert ein HSM eine beachtliche finanzielle Investition. Katalogpreise für PCI-basierte HSMs liegen gewöhnlich im Bereich von 10.000 bis 15.000 $.
Im LSU-Design wird ein nCipher nShield 500 TPS (Modell mit 500 Transaktionen pro Sekunde) als ein direkt verbundenes HSM verwendet. ("Direkt verbunden" bedeutet, dass es in den Server integriert ist und nur von diesem Server verwendet werden kann, im Vergleich zu einem netzwerkbasierten HSM, das von mehreren Hosts verwendet werden kann. Das HSM ist ein FIPS 140-2-Gerät der Ebene 3 und bietet K-von-N-Schutz des Schlüsselmaterials. Das HSM bietet erheblichen Schutz gegen eine Gefährdung der privaten Schlüssel. Ein Angreifer müsste sowohl den HSM-Speicher als auch eine festgelegte Anzahl an Zugriffstoken und deren PINs für einen Zugriff auf den Schlüssel besitzen.
Es ist wichtig anzumerken, dass HSMs so entworfen sind, dass ihr Inhalt vor Angriffen geschützt ist. Folglich erzwingen HSMs strenge Beschränkungen für wiederholt fehlgeschlagene Anmeldeversuche. Im LSU-Design wird der Speicher unwiderruflich nach 10 wiederholt fehlgeschlagenen Versuchen gelöscht.
In diesem Setup ist eine einzige Zertifizierungsstelle vorhanden. Daher ist der Aufpreis für ein netzwerkbasiertes HSM nicht gerechtfertigt. Wenn eine Organisation jedoch die Implementierung von zwei oder mehr Zertifizierungsstellen plant, kann es erheblich billiger sein, einzelnes netzwerkbasiertes HSM zu erwerben und für mehrere Zertifizierungsstellen zu verwenden. Durch diese Methode wird auch die Tokenverwaltung einfacher, da alle Schlüsselspeicher durch denselben Tokensatz geschützt werden können.

Active Directory und Registrierung
Einer der Hauptvorteile einer Windows-basierten PKI-Lösung ist, dass die Zertifikatbereitstellung erreicht werden kann, ohne zusätzliche Software auf Entitäten installieren zu müssen, die an der PKI beteiligt sind. Durch eine Kombination von automatischer Registrierung und Gruppenrichtlinien kann der Großteil der Zertifikatbereitstellung autonom und für den Endbenutzer unsichtbar verwaltet werden. Die LSU verwendet diese Technologie, um Computerzertifikate automatisch an Computer zu verteilen, die Mitglieder des Active Directory sind. Des Weiteren wird eine benutzerdefinierte Website verwendet, um Funktionen für benutzerverantwortliche Zertifikatanforderung für Nicht-Windows-Hosts bereitzustellen.
Wie zuvor erwähnt, unterscheidet das OmniRoot-Programm zwischen öffentlich verwendeten und intern verwendeten Zertifikaten. Zertifikate werden als öffentlich betrachtet, wenn sie von Systemen und Benutzern verwendet werden, die nicht Teil der LSU-Organisation sind (zum Beispiel, wenn ein potenzieller Student eine Bewerbung über eine SSL-geschützte Website einreicht). Zertifikate, die innerhalb der LSU Organisation verwendet werden (wie z. B. solche, die für die Verschlüsselung von Daten auf den LSU-Servern verwendet werden), werden als intern betrachtet.
Da die Kosten des OmniRoot-Programms auf der Anzahl öffentlich ausgerichteter Zertifikate basieren, muss es möglich sein, nachzuverfolgen, wie viele öffentliche Zertifikate ausgegeben werden und an wen. Folglich beginnt der eindeutige Name der Vorlage für alle Zertifikate, deren Zweck öffentlich ist, mit "PublicCertificate" und der Anzeigename beginnt mit "Public Certificate". Die öffentlich ausgerichtete LSU-TLS-Zertifikatvorlage basiert z. B. auf der Standard-Windows-Webservervorlage und wird „Public Certificate LSU Web Server“ genannt. Für intern verwendete Webserver ist eine zweite Vorlage verfügbar, die „Internal Certificate LSU Web Server“ genannt wird. Genau genommen sind beide Vorlagen identisch. Die Benennungsunterschiede dienen nur dazu, die Zuordnung zu erleichtern.
Für Massenregistrierungsanforderungen, wie die Registrierung ganzer Abteilungen für Zertifikate, die mit IPSec verwendet werden sollen, wird die automatische Registrierung vorausgesetzt. Dies ist ein einfaches, sehr wirksames Tool, das in Windows integriert ist. Vom Standpunkt eines PKI-Administrators ist die einzige erforderliche Aktion, die Zugriffssteuerungsliste auf der Vorlage zu ändern, und damit allen Benutzergruppen oder Computern, die Zertifikate benötigen, das Recht zur automatischen Registrierung zu gewähren. Diese Entitäten überprüfen daraufhin automatisch Active Directory, bestimmen, auf welche Vorlagen sie für die automatische Registrierung zugreifen können, finden die Zertifizierungsstellen mit diesen Vorlagen und registrieren sich automatisch für Zertifikate. Das Feature für die automatische Registrierung stellt außerdem sicher, dass Zertifikate ersetzt werden, wenn eine Vorlage überflüssig ist und vor Ablaufdatum automatisch erneuert wird.
Bei Zwecken, die keine Masseanforderungen betreffen, wie der Bereitstellung von Zertifikaten für Webserver, wird eine benutzerverantwortliche Website verwendet, mit der Benutzer Zertifikate über einen Webbrowser anfordern können. Bei dieser Site handelt es sich um eine benutzerdefinierte Version der Webregistrierungsseiten, die mit Windows Server 2003 geliefert werden (das virtuelle Verzeichnis /certsrv). Zur Implementierung gehört das Standardwebbranding, das den korrekten Standardeinträgen auf der Anforderungsseite vorausgeht. Weiterhin wird das Standardbeendigungsmodul im Windows-Zertifizierungsstellendienst verwendet, um dem PKI-Verwaltungsteam automatisch per E-Mail mitzuteilen, wenn eine Anforderung, die durch diese Site gesendet wird, eine Genehmigung erfordert.

Sperrungsdesign
Jedes Zertifikat verfügt über eine Gültigkeitsdauer. Von Zeit zu Zeit muss die LSU bestimmte Zertifikate vor Ablauf ihrer Gültigkeitsdauer für ungültig erklären (z. B. wenn ein Arbeitnehmer ein Zertifikat mit einer Gültigkeitsdauer erhält, das im Mai 2007 abläuft, dieser Arbeitnehmer die LSU jedoch im Januar 2007 verlässt). Diese Art der Sperrung wird mit CRLs erreicht, bei denen es sich um Dateien handelt, die eine Liste mit Zertifikatsseriennummern enthalten, die von einer Zertifizierungsstelle signiert wurden. Die Seriennummern, die in einer CRL enthalten sind, beziehen sich auf Zertifikate, deren Gültigkeitsdauer nicht abgelaufen ist, die die LSU jedoch nicht länger für vertrauenswürdig hält. Clients können diese CRL daraufhin herunterladen, um damit die Gültigkeit der Zertifikate zu bestimmen.
Ein x.509 v3-Zertifikat (abgesehen vom Stammzertifizierungsstellen-Zertifikat selbst) sollte über einen Zeiger auf eine gültige CRL verfügen. Dieser Zeiger ist auch als ein CRL-Verteilungspunkt (CDP) bekannt. Der CRL-Verteilungspunkt ist im Zertifikat selbst enthalten (siehe Abbildung 4) und kann nicht geändert werden, nachdem ein Zertifikat ausgegeben wurde. Die CRL ist ein wesentlicher Bestandteil der Bestätigung, dass Zertifikate von einer Zertifizierungsstelle gültig sind. So wird sichergestellt, dass die LSU-CRLs physisch redundant, hochgradig verfügbar und für externe Parteien zugänglich sind.
Abbildung 4 Der CRL-Verteilungspunkt der LSU
Abbildung 4 Der CRL-Verteilungspunkt der LSU (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 4 Der CRL-Verteilungspunkt der LSU
Abbildung 4 Der CRL-Verteilungspunkt der LSU (Klicken Sie zum Vergrößern auf das Bild)
Eine Windows Server-basierte Zertifizierungsstelle, die in Active Directory (wie das von LSU) integriert ist, veröffentlicht ihre CRL automatisch in Active Directory und macht sie dadurch über das Lightweight Directory Access-Protokoll (LDAP) zugänglich. Der Standardveröffentlichungsort ist der CDP-Container (siehe Abbildung 5) innerhalb des Public Key Services-Containers in der Gesamtstruktur. Dieser Veröffentlichungsort ist eine ausgezeichnete Option, da er automatische Replikation, Fehlertoleranz und einen Ort für CDP-Suchen bereitstellt.
Abbildung 5 Der CDP-Container
Abbildung 5 Der CDP-Container (Klicken Sie zum Verkleinern auf das Bild)
Abbildung 5 Der CDP-Container
Abbildung 5 Der CDP-Container (Klicken Sie zum Vergrößern auf das Bild)
Im LSU-Design gibt es allerdings zahlreiche Nicht-Windows und Nicht-Active Directory-Computer, die die PKI einsetzen. Und während es sich bei der LSU um eine große Organisation handelt, befindet sich der Hauptteil ihrer Benutzers in demselben Campusnetzwerk mit einem 10 Gbps-Backbone, der die Vorteile von Active Directory-basierter CDP-Veröffentlichung minimiert.
So wird unsere CRL nur in einem HTTP-Pfad veröffentlicht, was die Erstellung einer redundanten Hostingplattform erleichtert (unsere primäre Website wird bereits gespiegelt). Dies entfernt auch potenzielle Komplexitäten, die mit dem Aktivieren von Client-LDAP-Suchen verbunden sind. Wir veröffentlichen unsere CRL täglich und Delta-CRLs stündlich.

Blick in die Zukunft
Während unsere aktuelle PKI hohe Sicherheit für die Universitätscommunity bietet, planen wir eine Verbesserung ihrer Funktionen. Windows Vista™ und die nächste Version von Windows Server (mit dem Codenamen "Longhorn") werden zahlreiche neue wichtige Verwaltungsmöglichkeiten bereitstellen, die genau unter die Lupe genommen werden. Wir sind insbesondere an den geplanten Funktionen für OCSP-Clients und Responder (Online Certificate Status-Protokoll) interessiert, dem Support für elliptische Kurvenkryptografie- und SHA-256-Algorithmen sowie einer extrem verbesserten Schnittstelle für die automatische Registrierung. Zusätzlich ist für Windows XP Service Pack 3 die Integration eines Features namens „Credential Roaming“ (Roaming von Anmeldedaten) geplant, die sicheres Roaming von Schlüsselpaaren ohne den mit Roamingprofilen verbundenen Verwaltungsaufwand bieten wird. Schließlich wird der Nutzen des Certificate Lifecycle Managers (derzeit als Betaversion verfügbar) untersucht, um die Berichterstattungs- und Verwaltungsfunktionen zu verbessern.
Alles in allem bietet die PKI der LSU der Universität einen grundlegenden Sicherheitsdienst, der für zahlreiche wichtige IT-Funktionen eingesetzt wird. Durch die Verwendung des OmniRoot-Dienstes von Cybertrust kann eine PKI ausgeführt werden, die problemlos in die anderen IT-Systeme der LSU integriert werden kann, deren Vertrauenswürdigkeit jedoch global ist. Und durch die Erstellung der Lösung auf dem Windows-Zertifizierungsstellendienst bietet sie wirksame Funktionen zur Bereitstellung und Verwaltung von Zertifikaten und eine ausgezeichnete Integration in das bereits vorhandene Verzeichnis- und Identitätsverwaltungssystem. Kurz gesagt, wird die PKI-Vision von leistungsstarker Sicherheit und nahtlosem Vertrauens bereits zur Realität an der LSU.

John Morello hat sein Studium an der Louisiana State University mit Auszeichnung abgeschlossen und war sechs Jahre lang für Microsoft als Senior Consultant im Bereich Microsoft Consulting Services tätig. Mit MCS hat er PKIs für strategische Clients wie Deloitte, GE und verschiedene staatliche Organisationen entworfen. Er ist jetzt stellvertretender CISO bei LSU.


 Die Desktopdateien: Einblick in das Windows Imaging-Format
Die Desktopdateien
Einblick in das Windows Imaging-Format
Wes Miller
Dieser Artikel basiert auf Vorabversionen von Windows-Bereitstellungstools. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.

Die Veröffentlichung von Windows Vista bringt wichtige Änderungen im Installations- und Bereitstellungsvorgang von Windows mit sich. Das Setupmodul und die gesamte Suite von Bereitstellungstools für Windows Vista (sowie die bevorstehende Version von Windows Server mit dem Codenamen „Longhorn“) sind umgearbeitet worden. Diese Änderungen und die Anstrengungen des
Windows®-Bereitstellungsteams beim Implementieren dieser Änderungen wurden in zurückliegenden TechNet Magazin-Artikeln behandelt. Dieses Thema eröffnet jedoch viele Diskussionen, und so werden Windows PE, Windows-Installation und -Bereitstellung und andere Windows-Verwaltungs- und Sicherheitsthemen in dieser neuen regelmäßigen Rubrik abgedeckt.
Im vorliegenden ersten Beitrag wird das neue Windows Imaging-Format (WIM) erörtert. Wenn Sie nicht bereits mit den Einzelheiten der Abbilderstellung vertraut sind, lesen Sie unbedingt die Randleiste "Der typische Abbilderstellungsprozess", um einen Überblick zu erhalten. Im nächsten Artikel wird das automatisierte Installationskit für Windows behandelt – eine neue Suite von Tools, die Folgendes umfasst: ImageX (das Befehlszeilenprogramm zum Erstellen und Manipulieren von WIM-Abbildern) und Windows-Bereitstellungsdienste (WDS), die die Remoteinstallationsdienste (RIS) ersetzen. Dabei wird untersucht, wie diese Tools das Bereitstellen von Betriebssystemen erleichtern.

Der Wendepunkt
Jahr für Jahr hat das Windows-Bereitstellungsteam das gleiche Feedback von Originalherstellern (OEM) und Unternehmenskunden erhalten. Sie verlangen nach einer besseren Unterstützung für die Abbilderstellung, und sie möchten, dass Microsoft vereinheitlichte Abbilderstellungstools bereitstellt. Diese Benutzer sind nicht daran interessiert, einen Drittanbieter auszuwählen und sich mit den Feinheiten des jeweiligen Produkts auseinander zu setzen. Außerdem wurde von OEMs und Unternehmenskunden oft beanstandet, dass sie für Abbilderstellungstools bezahlen sollten, die zum Bereitstellen von Windows verwendet werden. Stattdessen wurde gewünscht, dass Microsoft diese Tools bereitstellt.
Schon in der Anfangsphase der Entwicklung von Windows Vista™ ist das Windows-Bereitstellungsteam ein sehr großes Risiko eingegangen. Es wurde entschieden, das gesamte Setupmodul vollständig zu verwerfen – darunter viele Komponenten, die nahezu ein Jahrzehnt lang existierten. Das Setup war schon immer labil und enthielt zu viele Schritte. Der Prozess sollte beschleunigt, unnötige Schritte sollten entfernt und die Zuverlässigkeit des Windows-Setups sollte insgesamt verbessert werden. Zu diesem Zweck musste der gesamte Installationsvorgang von einem langsam arbeitenden Modul, das wir geraume Zeit verwendet hatten, losgelöst und durch einen komplett abbildbasierten Installationsvorgang ersetzt werden.

Entwerfen eines neuen Abbilderstellungsformats
Bereits im Anfangsstadium des Setupneuentwurfs wollten wir definieren, welche Art von Abbild wir verwenden sollten. Das klassische Argument war bislang Sektor im Vergleich zu Datei. D. h., sollten wir ein Abbildformat verwenden, das eine Kopie eines Volumens Sektor für Sektor als ein Duplikat speichert, oder eines, das jede einzelne Datei individuell speichert. Der von den meisten erwartete Vorteil ist Geschwindigkeit (mit einem Sektoransatz) im Vergleich zu Komprimierung (mit einem dateibasierten Ansatz). Am Ende kamen wir auf ein Format, das meiner Meinung nach einen großartiger Kompromiss darstellt. Es liefert sehr gute Leistung, bietet dabei jedoch auch hervorragende Komprimierung.
Am Anfang wurden mehrere Hauptziele definiert, die wir erreichen mussten, um ein Abbilderstellungsformat zu erstellen, das die Bedürfnisse von OEMs und Unternehmensmitarbeitern erfüllt. In unserer Liste überwogen die Argumente für eine dateibasierte Architektur. Die Vorteile, die dieser Ansatz bot, schien allen offensichtlich, und daher entschieden wir uns zuerst für diese Variante. So entstanden bald darauf die WIM-Dateien. (Und falls Sie sich schon gewundert haben, das "M" in WIM hat keine große Bedeutung. Die Bezeichnung WIM wurde gewählt, weil das Ganze auf wiederkehrenden Windows Team-Ereignissen kurz vor wichtigen Lieferterminen beruht, und *.WI schien eine seltsame Abkürzung zu sein.) Im Folgenden werden die Ziele dargestellt, die wir für das neue Abbildformat definiert haben.
Formatneutrales Dateisystem für Windows (NTFS) Das Abbildformat musste in beiden von Windows unterstützten Dateisystemarchitekturen funktionieren. Obwohl fast alle Systeme mit NTFS ausgeführt werden, verwenden viele OEMs und Unternehmen FAT-Dateisysteme als eine Notlösung, die ihnen beim Bereitstellen von Windows die Verwendung von MS-DOS® ermöglichen. Sie konvertieren dann später in NTFS. Dies musste für Windows Vista weiterhin unterstützt werden.
Neutrale Volumengeometrie Hier musste das alte Problem gelöst werden, das darin bestand, ein großes Volumen zu erstellen und es auf ein kleineres anzuwenden. Das Abbilderstellungstool kann dieses Problem zwar durch Tricks bei der Manipulation von Partitionen umgehen. Dies ist jedoch unzuverlässig. In einer dateibasierten Architektur nimmt das Abbild nur so viel Platz ein wie die Dateien, aus denen es besteht. Da das Dateisystem unabhängig wiederhergestellt wird, muss nicht auf die Volumengröße vertraut werden.
Der typische Abbilderstellungsprozess
Wenn ein OEM eine große Anzahl von Systemen dupliziert oder eine große Organisation Windows für zahlreiche Computer bereitstellen muss, verwenden sie gewöhnlich Abbilderstellungstechnologie. Die Voraussetzung dabei ist, dass das Hostsystem genau nach Wunsch erstellt und dann auf die Zielsysteme dupliziert wird. Falls Sie mit dem Abbilderstellungsprozess nicht vertraut sind, folgt hier eine kurze Übersicht.
  1. Der Administrator installiert Windows auf einem System und konfiguriert es wie gewünscht. Dies umfasst das Hinzufügen und Entfernen von Komponenten, das Installieren gebräuchlicher Anwendungen und das Optimieren der UI- und anderer Einstellungen. Im Folgenden wird dies als das Hostsystem bezeichnet.
  2. Der Administrator führt dann Sysprep aus (wird von Microsoft in Form von Windows-Bereitstellungstools zur Verfügung gestellt). Sysprep erledigt die schwierige Aufgabe der Bereinigung der Attribute, die eine Windows-Installation einmalig machen (wie z. B. Computername, Windows Sicherheits-ID (SID) und andere eindeutige Bezeichner im System). Sie werden zurückgesetzt, wenn die zweite Hälfte von Sysprep ausgeführt wird.
  3. Als Nächstes fährt der Administrator den Computer herunter und startet Windows PE, MS-DOS oder ein anderes Betriebssystem, das die Ausführung der Abbilderstellungsanwendung ermöglicht.
  4. Jetzt führt er/sie das Abbilderstellungstool aus, wodurch ein Abbild des Verweissystems erstellt wird. Dieses Abbild ist eine Datei (oder Sammlung von Dateien), die ein genaues Replikat des Verweisdatenträgers oder der Partition enthält.
  5. Das System wird heruntergefahren, und der Administrator archiviert das Abbild, das erforderlichenfalls aktualisiert werden kann (durch Hinzufügen von Anwendungen, Hotfixes und Service Packs).
  6. Das Abbild wird auf ein oder mehrere Computer repliziert, und Sysprep schließt seine Arbeit ab, indem es eine verkürzte Version des Setups durchläuft (als Mini-Setup oder Windows-Willkommenseite bezeichnet, je nachdem unter welcher Windows-Version Sie Sysprep ausführen und wie Sysprep konfiguriert ist). Diese Phase stützt sich auf „setupcl.exe“, eine winzige ausführbare Datei im systemeigenen Modus.

Neutrale Systemarchitektur Die Abbildarchitektur musste mit einer Architektur funktionieren, die von Windows unterstützt werden konnte. Zur damaligen Zeit lief dies auf die Unterstützung der sehr unterschiedlichen Architekturen x86 und IA64 (Intel Itanium) hinaus. Heute umfasst dies auch die x64 (AMD64 und EM64T)-Architektur.
Schnelles Erstellen und Anwenden: Das Abbild musste bei der gegebenen Komprimierung einigermaßen schnell zu erstellen sein. Weitaus wichtiger war es jedoch, dass es bei der Abbildanwendung sehr schnell war.
Unterstützen nicht-destruktiver Abbildanwendung Da wir die Upgradeoption ersetzten (sie ersetzt Windows, ohne Benutzerdaten oder Anwendungen zu schaden) sowie ein Tool ableiteten, das für die Systemwiederherstellung verwendet werden konnte, sollte es in der Lage sein, ein System abzubilden, ohne alles, was sich bereits auf dem Volumen befand, zu zerstören. Sektorbasierte Formate lassen dies ohne beträchtliche Arbeit seitens der Benutzer nicht zu. Im Allgemeinen wird entweder ein ganzes Volumen oder überhaupt nichts wiederhergestellt.
Unterstützen wichtiger Komprimierung Zu Beginn der Entwicklung von Windows Vista konzentrierten wir uns nach wie vor auf die Lieferung auf CD. Angesichts der Tatsache, dass ein Abbild von Windows XP nahezu 1 GB beträgt, war es wichtig, das Abbild so stark wie möglich zu komprimieren. Dafür gibt es Tricks, die Sie mit einem sektorbasierten Abbild durchführen können. Die beweglichen Teile in einer deartigen Implementierung bereiteten uns jedoch Bedenken. Viele sektorbasierte Formate unterdrücken Leerzeichen auf Datenträgern, um Platz zu sparen. (Warum einem Abbild eine 0 zuordnen, wenn es immer eine 0 ist?) Doch mithilfe eines dateibasierten Ansatzes wurde dies intern gelöst, da Leerzeichen nicht erfasst wurden.
Unterstützen des „Single Instancing“ der Dateien Dies ist mit dem vorherigen Problem identisch. Windows ist dafür bekannt, dass es mehrere Kopien der gleichen Datei an verschiedenen Orten speichert. Der dateibasierte Ansatz erleichterte es, nur eine Instanz jeder Datei zu speichern und die Datei bei Bedarf zu verwenden.
Unterstützen der Medien- (Datenträger-)Verteilung Schon in den Anfangsstadien von WIM, als wir ein Abbild auf einer einzelnen CD unterbringen konnten, war uns klar, dass wir mehrere Medien unterstützen mussten. Selbst wenn wir Windows auf einer CD geliefert hätten, hätten die Abbilder nach dem Hinzufügen von Anwendungen, Service Packs usw. seitens der Benutzer wahrscheinlich die Größe einer einzelnen CD oder DVD überschritten. Daher mussten wir sie über mehrere Medien mit eigenen Installations- und Wiederherstellungslösungen verteilen.
Unterstützen mehrfacher Volumenabbilds in einem Dateipaket Ein Abbild ist selten für alles geeignet. Bei der Konstruktion von "Single Instancing" haben wir auch die Möglichkeit eingebaut, mehr als ein Volumen abzuholen – und die gleichen Einstellungen für Komprimierung und Single Instancing funktionieren für alle Volumen. Wenn Sie also ein Abbild von Windows XP Professional abholen und dann ein neues Abbild von Windows XP Tablet PC Edition (die eine Obermenge von Windows XP Professional ist) anhängen, wird das Abbild nur um die Dateien erweitert, die sich in den beiden Versionen explizit unterscheiden.
Demzufolge können ein OEM oder Unternehmensmitarbeiter viele abgeleitete Abbilder ohne einen exponentiellen Anstieg in der Größe zusammenfügen. Diese Fähigkeit wäre mit sektorbasierten Formaten nicht zu erreichen gewesen.

Funktionsweise von WIM
Das WIM-Format wurde so einfach wie möglich entworfen und erfüllt unsere Leitgrundsätze. Dies wurde durch den dateibasierten Ansatz ermöglicht. Aber wie funktioniert das Ganze im Detail?
Im Prinzip verhält es sich bei einer WIM-Datei wie mit einer CAB-Datei (ähnelt dem ZIP-Format, mit dem Unterschied, dass Microsoft das CAB-Format entworfen hat und dessen Eigentümer ist). WIM wird von manchen als die "Miniversion des CAB" bezeichnet. Der Hauptunterschied zwischen einer WIM-Datei und einer CAB-Datei ist, dass ein WIM-Abbild zusätzlich zum Erstellen und Komprimieren der Datei selbst Metadaten speichert, die für die Dateien und die Verzeichnisse gelten, aus denen ein in einem Volumenabbild erstelltes Volumen besteht. Es handelt sich um eine Art Archivdatei mit allen Metainformationen, die erforderlich sind, um das Volumen in dem Zustand wiederherzustellen, in dem es bei der Abbilderstellung vorlag – Zugriffssteuerungslisten (ACLs), kurze/lange Dateinamen, Attribute und so weiter.
Beachten Sie, dass während der Erstellung zu keinem Zeitpunkt Partitionsinformationen (Größe oder Typ) gesammelt werden. Das System wird vom Anwendungsprozess auch nicht partitioniert. ImageX ist im Vergleich zu den meisten Abbilderstellungstools partitionsneutral und erfordert, dass die Partition vor der Anwendung erstellt und formatiert wird. Um den Prozess vor dem Anwenden Ihres Abbilds zu automatisieren, sollten Sie die Diskpart- und Format-Befehlszeilenprogramme verwenden.
Was in einem Volumenabbild gespeichert werden kann, wird durch nichts eingeschränkt. Ein Abbild kann zwei Volumen, das gleiche an einem Dienstag und Donnerstag erstellte Volumen, ein Abbild mit einem Service Pack und eines ohne oder alles, was Ihren Anforderungen entspricht, enthalten. Das Wichtigste ist, dass Dateien, die identisch sind, nur einmal erstellt werden. Je weniger zwei Volumenabbilder gemeinsam haben, desto mehr Platz wird eingenommen.
Es soll außerdem darauf hingewiesen werden, dass das WIM-Format nichts enthält, was seiner Verwendung mit früheren Versionen von Windows im Wege steht. Es funktioniert genauso gut mit Windows 2000 wie mit Windows Vista. Im Folgenden wird erläutert, was im Einzelnen geschieht, wenn Abbilder erstellt und angewendet werden.

Erstellen eines Abbilds
Beim Erstellen eines Abbilds werden die folgenden Schritte ausgeführt:
Volumenmetadaten werden erstellt ImageX sammelt im Volumen Daten über Dateinamen, NTFS-ACLs und andere Dateisystemattribute. (Sie können gewünschtenfalls bestimmte Dateien mit einer Skriptdatei ausschließen.)
Dateidaten werden erstellt Die Datei wird von ImageX geladen. Jede Datei wird auf das Volumen geladen und darauf vorbereitet, bestimmte Daten darüber zu sammeln.
Dateihash wird generiert Ein kryptografisches Dateihash, das auf der Datei selbst basiert, wird generiert. Dieses Hash wird zum eindeutigen Bezeichner der Dateien im Abbild.
Duplikate werden geprüft und entfernt Wenn das Abbild bereits eine andere Datei mit dem gleichen Hash enthält, wird angenommen, dass dies die gleiche Datei ist, und die neue Datei wird mit einem Verweis auf die bereits vorhandene Datei versehen.
Einmalige Dateidaten werden komprimiert Im Unterschied zu CAB und vielen anderen Archivformaten wird jede Datei in einer WIM-Datei einzeln komprimiert und nicht als eine Sammlung von Dateien, die als ein einziger Datenstrom gruppiert sind. Sie haben außerdem die Wahl, keine Komprimierung zu verwenden. In diesem Fall wird dieser Schritt ausgelassen.
Volumenmetadaten werden komprimiert und gespeichert Nachdem alle Dateien archiviert worden sind, wird ein Metadatenzugang für das Volumen erstellt. Dadurch wird jede einzelne Datei aufgelistet, die dem Abbild für das Volumen hinzugefügt wurde.
Abbild-XML-Daten werden generiert und gespeichert Dies ist ein Verweis für jedes Volumenabbild, das erstellt wird. Wenn Sie z. B. ImageX /Info ausführen, werden diese XML-Daten angezeigt.
Zwischengespeicherter WIM-Datenindex wird geschrieben Abschließend wird der Masterdatenindex (zusammen mit den zwischengespeicherten Daten) geschrieben. Hier handelt es sich um die Masterdateitabelle für das gesamte WIM; sie umfasst einen Eintrag pro Hash.
Wie Sie sehen können, wird ein WIM auf einer Datei-für-Datei-Basis erstellt. Ferner verfügen Sie über eine einzige WIM-Datei, unabhängig von der Anzahl der Volumen, die Sie an das Abbild anhängen.

Abbild-Overload
Es gab eine Reihe von Teams, die ähnliche Lösungen entwickelten, als wir mit unserer Arbeit an WIM begannen. Das Team, das für die automatisierten Bereitstellungsdienste zuständig ist, entwickelte eine Abbilderstellungslösung für ein anderes Kundensegment. Der Ansatz, den dieses Team wählte, enthielt einige sehr interessante untergeordnete Implementierungsdetails, doch sein Abbilderstellungsmodul basierte, wie es zu dieser Zeit üblich war, auf Sektoren. Das Windows XP Embedded-Team erstellte außerdem ein sektorbasiertes Abbilderstellungsmodul, mit dem eingebettete unabhängige Hardwarehersteller ihre eigenen Abbilder zum Zeitpunkt der Systemherstellung bereitstellen können. Und als das Virtual PC-Team 2003 von Microsoft übernommen wurde, hat es ein anderes Dateiformat für virtuelle Festplattendateien (VHD) beigesteuert.
Alle diese Formate waren grundsätzlich sektorbasiert. Diese Lösungen haben zwar den Anforderungen der einzelnen Kundensegmente entsprochen, konnten jedoch unsere Richtlinien für WIM nicht erfüllen. Aus diesem Grund haben wir ein neues WIM-Format erstellt und das ImageX-Befehlszeilenprogramm für das Erstellen von Abbildern fortgesetzt. Am Ende hat eine Reihe anderer Teams unser Format übernommen, bevor es allgemein als Teil von Windows Vista Beta angesehen wurde. Das SMS-Team hat z. B. eine frühe Implementierung von WIM in ihrem OS-Bereitstellungspaket geliefert.

Anwenden eines Abbilds
Im Folgenden wird der entgegengesetzte Prozess erläutert: das Anwenden eines Abbilds.
Zwischengespeicherter WIM-Datenindex wird geladen: Dies entspricht dem letzten Schritt im vorherigen Verfahren. Da es sich hier um den Masterindex handelt, wird er als Erstes vom WIM geladen, nachdem Sie festgelegt haben, welches Volumenabbild angewendet werden soll.
Abbildmetadaten werden abgerufen und geladen ImageX lädt die Metadaten, die sich auf das jeweilige Volumenabbild beziehen.
Verzeichnisstruktur wird erstellt Um zu gewährleisten, dass jeder Datei ein Ort zugewiesen ist, an dem sie wiederhergestellt werden kann, wird die gesamte Verzeichnisstruktur des Volumens erstellt.
Dateidaten werden extrahiert Die Dateien werden vom WIM in genau derselben sequenziellen Reihenfolge extrahiert, in der sie archiviert wurden.
Dateidaten werden angewendet In diesem Schritt werden die Dateien geladen, dekomprimiert (falls das Volumenabbild im WIM komprimiert wurde) und auf die einzelnen Verweisorte kopiert. Schließlich werden alle Metadaten auf die einzelnen Datei angewendet.
Alle Verzeichnismetadaten werden angewendet Es ist wichtig, dass dies zuletzt geschieht, da die Möglichkeit besteht, dass ein ACL in einem Verzeichnis die korrekte Anwendung des Abbilds ausschließt.

Flexible Komprimierung
Eine der wichtigsten Ziele, die wir uns für das WIM-Abbilderstellungsformat setzten, war das Bereitstellen flexibler Komprimierungsoptionen. Daher bauten wir die Möglichkeit ein, ein Volumenabbild bei Bedarf mit oder ohne Komprimierung zu erstellen. Letztere Option eignet sich für Szenarios, in denen das Abbild nicht aggressiv komprimiert werden muss oder wenn eine hohe Geschwindigkeit entscheidend ist.
Es gibt ein paar Hauptgrundsätze, die in Bezug auf die Komprimierung zu beachten sind. Eine Komprimierung dauert immer länger als eine Dekomprimierung. Je aggressiver der Komprimierungsalgorithmus ist, desto länger dauert es, einen Datensatz zu komprimieren. Und je mehr Daten einem Komprimierungsalgorithmus zugeführt werden, desto leichter ist die Komprimierung.
WIM-Abbilder können mithilfe der XPress- oder LZX-Komprimierung komprimiert werden, wobei es Ihnen selbstverständlich frei steht, keine Komprimierung anzuwenden. XPress ist ein guter Kompromiss, wenn Sie eine Komprimierung benötigen, dem Erstellungsprozess jedoch nicht zu viel Zeit einräumen möchten. LZX bietet ein ideales Komprimierungsverhältnis. Allerdings dauert diese Methode beträchtlich länger.
Keine Komprimierung zu verwenden, führt zur schnellsten Abbilderstellung, ergibt jedoch das größte Abbild. Der Komprimierungstyp ist eine „pro WIM“-Option. Nachdem Sie ein Volumenabbild in einem WIM erstellt haben, müssen alle zukünftigen Volumenabbilder mit der gleichen Komprimierungseinstellung erstellt werden.
Beachten Sie, dass WIM-Abbilder auf einer Datei-für-Datei-Basis komprimiert werden und die Komprimierung deshalb nicht so vollständig wie möglich ausfällt. Dies war eine bewusste Entscheidung – dadurch kann das Abbild leichter bearbeitet werden. Die Möglichkeit, Abbilder nach der Erstellung zu bearbeiten, ist eine wichtige Option. Damit eine Datei bearbeitet werden kann, nachdem das Abbild erstellt wurde, müssen die Dateidaten und seine Metadaten ersetzt werden. Wenn wir das gesamte WIM auf einmal komprimiert hätten, wäre es verhältnismäßig kompliziert geworden, den Support für das Bearbeiten von Dateien technisch auszuführen (sofern es überhaupt möglich gewesen wäre), und das Ersetzen einer Datei im Abbild hätte eine beachtliche Zeit in Anspruch genommen. Mit diesem Kompromiss sind wir bei einem Format angelangt, das gut komprimiert ist und nach wie vor mit unseren Tools bearbeitet werden kann.
Es bleibt zu wünschen, dass Ihnen dieser Überblick einen Einblick in die Arbeitsweise der Abbilderstellungsfunktionen gewährt, die wir für Windows Vista entworfen haben. Im nächsten Artikel werden einige der Tools behandelt, die Sie zum Verwenden und Bereitstellen von WIM-Abbildern verwenden können. Außerdem werden die ImageX- und Windows-Bereitstellungsdienste näher untersucht.

Wes Miller ist Entwicklungsmanager bei Pluck (www.pluck.com) in Austin, Texas. Davor arbeitete er bei Winternals Software in Austin und bei Microsoft als Programm-Manager und Produktmanager für Windows. Sie erreichen Wes unter: technet@getwired.com. Wes Miller möchte sich bei John Macintyre, dem derzeitigen WIM/ImageX-Programm-Manager bei Microsoft, für seine Hilfe bei diesem Artikel


 Windows Confidential: Warten auf RunOnce
Windows Confidential
Warten auf RunOnce
Raymond Chen

DENKEN SIE an eine Installation, die das System mitten in einem laufenden Prozess neu starten muss. Das Installationsprogramm könnte beispielsweise versuchen, eine System-DLL-Datei zu aktualisieren, die derzeit in Verwendung ist. Sie müssten einen eingreifenden Neustart auslösen, damit die neue DLL-Datei installiert wird, und nach der Aktualisierung der DLL-Datei könnten Sie sie in der nächsten Phase der Installation verwenden.
Der RunOnce-Schlüssel wurde für diese Art von Szenario entwickelt, also zu dem Zweck, von Installationsprogrammen dafür verwendet zu werden, nach einem eingreifenden Neustart ihre Installation abzuschließen. (Dies geschah in der guten alten Zeit, in der man sich noch darauf verließ, dass Programme keine Fehler machen.)
Windows® Explorer wartet, bis die Ausführung des Programms RunOnce vollständig abgeschlossen ist, bevor der Desktop und die Taskleiste erstellt werden. Dies liegt daran, dass RunOnce nach dem Grundsatz ausgeführt wird, für Installationsprogramme verwendet zu werden. Das Programm RunOnce könnte ja Systemkonfigurationsdaten ändern, und Sie wollen daher verhindern, dass der Benutzer ein System verwendet, während es gerade umkonfiguriert wird.
Nehmen wir beispielsweise einmal an, das Programm RunOnce wäre dabei, für die Dateien, die es eben installiert hat, eine neue Basis aufzubauen und die Dateien zu binden, und einige dieser Dateien sind Teil einer Shellerweiterung. Sie wollen unter keinen Umständen, dass der Benutzer versucht, das Programm auszuführen oder die Erweiterung zu aktivieren, während die Aktualisierung der zugehörigen EXE-Datei noch im Gange ist.
Ein anderes Problem des Grundsatzes „es ist für Installationsprogramme vorgesehen“ besteht darin, dass der RunOnce-Schlüssel nur verarbeitet wird, wenn sich ein Benutzer mit Administratorrechten anmeldet. Folglich könnten Benutzer, die keine Administratoren sind, die Installation nicht abschließen. Außerdem würde der RunOnce-Schlüssel, wenn er für Benutzer ausgeführt wird, die keine Administratoren sind, nicht mehr, wie sein Name sagt, nur einmal ausgeführt werden („run once“). Dies würde wirklich zu einem großen Dilemma führen. Wie würden Sie sagen „Gut, ich habe das da ausgeführt, also führe es nicht noch einmal aus“? Um diesen systemweiten Zustand zu ändern, bräuchten Sie Administratorrechte. Doch wie schon gesagt, besitzt ein Benutzer, der kein Administrator ist, auch keine Administratorrechte! Das Programm würde nicht nur einmal, sondern immer wieder aufs Neue ausgeführt werden, bis sich endlich ein Administrator anmeldet.

(Klicken Sie zum Verkleinern auf das Bild)

(Klicken Sie zum Vergrößern auf das Bild)
RunOnce, das für die Fertigstellung von Programminstallationen entwickelt wurde, wird in Windows Setup selbst verwendet. Wenn Sie versuchen, ein Service Pack zu installieren oder Windows auf eine neuere Version zu aktualisieren, überprüft der Installationsassistent den RunOnce-Schlüssel. Ist dieser Schlüssel nicht leer, erhalten Sie eine Fehlermeldung, die besagt: „He, bei Ihnen ist eine noch nicht abgeschlossene Programminstallation im Gange. Bitte schließen Sie diese Installation ab, bevor Sie versuchen, das Betriebssystem zu aktualisieren“. Dies ist auch richtig so, denn Sie wollen ja das Betriebssystem nicht mitten während der Installation eines Programms ändern.
Die ganze Aufbau von RunOnce verrät seine Vergangenheit. Es wurde unter Windows 95 ausgebrütet, also in einem Betriebssystem, das zwischen Administratoren und Nicht-Administratoren noch keinen Unterschied machte. Da unter Windows 95 praktisch jeder ein Administrator war, konnte sich ein Installationsprogramm, das mit RunOnce arbeitete, darauf verlassen, dass die RunOnce-Aktionen beim nächsten Neustart durchgeführt wurden.
Bei neueren Windows-Betriebssystemen – insbesondere bei Windows Vista™ – ist es möglich, dass sich monatelang niemand mit Administratorrechten anmeldet. Demzufolge kann sich ein Programm, das RunOnce ausführen muss, auf eine sehr lange Wartezeit gefasst machen.
Übrigens habe ich einmal auch ein ständig laufendes RunOnce gesehen. Es hat sich bei jeder Ausführung selbst neu zum RunOnce-Schlüssel hinzugefügt. Dies verstößt eindeutig gegen den Zweck des RunOnce-Schlüssels, da es dadurch nicht mehr Teil der Programminstallation, sondern Teil des normalen Ablaufs des Programms ist. Hinzu kommt, dass dieses Verhalten Windows Setup ständig dazu veranlasst, zu melden, dass eine Installation im Gange sei.
Daher kann der Benutzer nie das Betriebssystem aufrüsten, denn dieses einzelne lästige Programm sagt bei jedem Versuch sein Sprüchlein auf: „Ich muss nur noch ein paar Kleinigkeiten erledigen, und danach bin ich fertig, ehrlich“. Das Programm wird die Installation allerdings heute nicht mehr abschließen, „aber morgen ganz bestimmt“. Das ist nicht viel anders als beim Warten auf Godot, aber hoffentlich ohne diese existenzielle Krise.

Raymond Chen, The Old New Thing, beschreibt die Geschichte von Windows und die Win32-Programmierung. Raymond Chen arbeitet derzeit an einem Buch, das zufälligerweise ebenfalls den Titel „The Old New Thing“ (Addison-Wesley, 2007) trägt.