 TechNet Magazine July 2007

TechNet Magazine July 2007

Kommunikation: Datenschutz und Notfallwiederherstellung für Exchange Server 2007

Exchange Server 2007 enthält eine Vielzahl an Optionen, um hohe Verfügbarkeit und Notfallwiederherstellung zu unterstützen. Erfahren Sie mehr über die Alternativen, die Exchange anbietet, und planen Sie die ideale Wiederherstellungslösung für Ihre Organisation.

Lee Benjamin Kommunikation: Verbesserte Sicherheit mit Windows Mobile 6

Smartphones und PDAs bieten Zugriff auf das Netzwerk, wenn Sie nicht im Büro sind, doch sie können das Netzwerk auch für neue Sicherheitsrisiken anfällig machen. Diese Anleitung erläutert, wie Windows Mobile 6 und Exchange Server dazu beitragen können, die mobilen Geräte und die Infrastruktur ihres Unternehmens zu schützen.

Matt Fontaine Kommunikation: Eine leistungsfähige Alternative zu öffentlichen Ordnern

MOSS 2007 stellt eine weitaus leistungsfähigere Lösung für die Freigabe von Daten als öffentliche Exchange-Ordner bereit und bietet erweiterte Funktionen sowie leichtere Verwaltung. Hier erfahren Sie, wie Sie SharePoint zum Freigeben von Kalendern, Kontakten und Dokumenten verwenden können.

Alan Maddison Kommunikation: Anmeldung bei Outlook Web Access mit Smartcards

Eines der schwächsten Glieder in der Sicherheitskette besteht in unsicheren, einfach zu erratenden Kennwörtern. Erfahren Sie, wie Sie für mobile Benutzer die E-Mail-Sicherheit durch Implementieren einer zweistufigen Smartcardauthentifizierung verbessern können.

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Windows-Verwaltung: Der ActiveX-Installationsdienst in Windows Vista

Wie sichern Sie den Desktop gegen schädliche ActiveX-Steuerelemente, ohne die Anwendungskompatibilität einzuschränken? Im Folgenden erhalten Sie einen Überblick über den ActiveX-Installationsdienst (ActiveX Installer Service, AxIS) in Windows Vista, der dieses Problem mit einer neuen Möglichkeit zur Verwaltung von ActiveX-Steuerelementen behandelt.

Rob Campbell and Joel Yoker Mitteilung der Redaktion: Bekannte sechsten Grades

Joshua Trupin Toolbox: Neue Produkte für IT-Profis

Greg Steen SQL – Fragen und Antworten: Clustering, mysteriöse Abstürze, das SA-Konto und mehr

Edited by Nancy Michell Schwerpunkt Dienstprogramme: SMSMap

Jeff Tondt How IT Works: Problembehandlung bei RPC-Fehlern

Zubair Alexander The Cable Guy: IPv6-Datenverkehr über VPN-Verbindungen

Joseph Davies Windows PowerShell: Neuer Ansatz für die Pipeline

Don Jones Hey, Scripting Guy!: Auch bei Skripts kommt es auf das Äußere an

The Microsoft Scripting Guys Exchange Fragen & Antworten: Edge- und Hub-Transport-Funktionen, virtuelle Computer und mehr

KC Lemson and Nino Bilic Sicherheit auf dem Prüfstand: Tools zum Verwalten von ACLs

Jesper M. Johansson Die Desktopdateien: Das Microsoft Desktop Optimization Pack

Wes Miller Windows Confidential: Die magischen Kräfte des abgesicherten Modus

Raymond Chen


 Kommunikation: Datenschutz und Notfallwiederherstellung f&#252;r Exchange Server&#160;2007
Kommunikation Lee Benjamin

Datenschutz und Notfallwiederherstellung für Exchange Server 2007
Kurz zusammengefasst:
  • Einfache Sicherung und Wiederherstellung
  • Datenkontinuität
  • Replikationstechnologien
  • Alternative Lösungen

Bei der Entwicklung von Microsoft Exchange Server stand die Sicherheit im Vordergrund. Organisationen müssen ihre Messagingdaten sichern und auch die Möglichkeit haben, diese Daten wiederherzustellen. Um diese Anforderungen zu erfüllen, hat Microsoft ein vollständiges Spektrum an Datenschutzoptionen, von der traditionellen
Sicherung und Wiederherstellung über betriebliche Kontinuität bis hin zu echten Geschäftskontinuitätslösungen konzipiert, durch die ein hohes Maß an Verfügbarkeit und Notfallwiederherstellung bereitgestellt wird. In diesem Artikel werden die verschiedenen Optionen erläutert, um Sie bei der Entscheidung zu unterstützen, wie Sie die beste Exchange-Wiederherstellungslösung für Ihre Organisation implementieren können.

STUFE 1: EINFACHE SICHERUNG UND WIEDERHERSTELLUNG
Sie können Exchange-Dateien sichern, indem Sie die Datenbanken offline setzen, aber Sie können sie auch online sichern. Letztere Alternative ist für Exchange-Dateien in den meisten Fällen zu empfehlen. Aber Exchange ist mehr als ein Satz von Dateien. Es handelt sich vielmehr um einen Informationsspeicher mit großen Datenbankdateien und Transaktionsprotokollen. Nachrichten, die an Exchange gesendet werden, werden sofort in die Transaktionsprotokolle eingetragen, und wenn das System ein paar freie Zyklen hat (meist ein paar Millisekunden später), werden die Nachrichten in die Datenbank kopiert. Durch die schnellstmögliche Speicherung der Daten auf dem Datenträger stellt Exchange ein sehr hohes Maß an Wiederherstellbarkeit bereit. Grundlage für die Wiederherstellung von Exchange ist die Verfügbarkeit beider Informationssätze. Sollte Ihr System ausfallen, ist es die Kombination aus einer früheren Sicherung zusammen mit allen Transaktionen seit diesem Punkt, die es Ihnen ermöglicht, Exchange wieder mit den neuesten Informationen herzustellen. Beachten Sie, dass Exchange Transaktionen bei Bedarf automatisch in eine wiederhergestellte Datenbank einspielt.
Sicherungsprogramme greifen auf Daten in der Exchange-Datenbank über die Extensible Storage Engine (ESE)-Sicherungs-API oder neuere VSS-Lösungen zu, die weiter unten in diesem Artikel erörtert werden. Wenn eine ESE-Sicherung initiiert wird, hält Exchange vorübergehend alle Schreibvorgänge in die Datenbanken an. Gleichzeitig setzt ESE die Datenbank vorübergehend in einen schreibgeschützten Modus, wodurch die Datenbank komplett gesichert werden kann. Zudem werden neue, während der Sicherung erfolgte Transaktionen in einer temporären Datenbank gespeichert. Wenn die Sicherung abgeschlossen ist, setzt ESE die Datenbank wieder in den normalen Lese-/Schreibmodus zurück und fügt dann die Transaktionen ein, die in der temporären Datenbank gesammelt wurden. Am Ende eines erfolgreichen Sicherungsprozesses werden außerdem alte Transaktionsprotokolle gelöscht.
Dieser Sicherungsprozess ist zwar einfach und transparent, sogar für Benutzer, die sich mitten in der Nacht während der Sicherung anmelden, aber ESE braucht u. U. sehr lange für die Sicherung, insbesondere da Exchange-Datenbanken eine Größe von ein paar Gigabyte bis zu noch überschaubaren 30 bis 50 oder sogar bis zu 100 GB haben können. Bei letzterer Größe ist es beinahe unmöglich, unter Einsatz von Standardtechnologien Daten über Nacht zu sichern. Abbildung 1 zeigt Einsatzbeispiele für NTBackup.exe.
Abbildung 1 Verwenden des NTBackup-Dienstprogramms
Abbildung 1 Verwenden des NTBackup-Dienstprogramms

Best Practices für Exchange
Wenn Sie in der Lage sein wollen, Daten nach Hardware- und Systemfehlern schnell wiederherzustellen, sollten Sie jede Nacht komplette Exchange-Sicherungen ausführen. Um Leistung und Wiederherstellbarkeit zu verbessern, wenn ein Exchange-Server lokale Festplatten verwendet, sollten Sie zum Speichern der Exchange-Datenbanken und Exchange-Transaktionsprotokolle unbedingt separate RAID-Arrays verwenden. Beim Ausfall eines RAID-Arraycontrollers oder beim Ausfall von mehr als einem Datenträger im Array, sodass die übrigen Datenträger die Daten nicht mehr rekonstruieren können, ist eine Wiederherstellung der Daten trotzdem möglich. Wenn Sie die Transaktionsprotokolle verlieren, stehen immer noch aktuelle Exchange-Datenbanken auf den anderen Laufwerken zur Verfügung, die es Ihnen ermöglichen, normale Vorgänge mit neuen Transaktionsprotokollen fortzusetzen. Wenn Sie die Datenbanklaufwerke verlieren, sieht Ihre Wiederherstellungsstrategie so aus, dass die komplette Sicherung der Exchange-Datenbanken von der vorherigen Nacht mit den Transaktionsprotokollen des laufenden Tags aktualisiert wird.
Es ist wichtig, dass Sie die Größe der Exchange-Datenbanken beschränken, damit jede in kürzester Zeit gesichert und, was noch wichtiger ist, wiederhergestellt werden kann. Für die meisten Organisationen bedeutet dies eine Datenbankgröße von 30 bis 50 GB. Wenn eine Datenbank größer wird, ist es ratsam, sie in mehrere Datenbanken zu unterteilen, damit eine schnelle Wiederherstellung möglich ist.

Sicherungs- und Wiederherstellungsfolge
Der Speicherort der Datenbanken und Transaktionsprotokolle ist äußerst wichtig, nicht nur für die Sicherungsleistung, sondern auch für die Wiederherstellungsgeschwindigkeit. Heute unterstützen alle Server verschiedene Ebenen der Laufwerkredundanz, die als RAID bezeichnet werden. Grundsätzlich ermöglicht es RAID, dass ein Laufwerk ausfällt, ohne dass hierbei das System abstürzt. Die Systemleistung wird dabei allerdings langsamer, bis das Laufwerk ersetzt und wieder aufgebaut ist. Bis dahin muss der Arraycontroller die Daten von den übrigen Datenträgern ad hoc rekonstruieren, sobald sie von einem Laufwerk angefordert werden. Weitere Informationen zum Postfachserver-Speicherdesign finden Sie im Microsoft IT Showcase-Artikel Die 64-Bit-Version von Exchange Server 2007.
Ein Hauptfeature von Exchange ist das Einzelinstanz-Datenbankdesign. Das bedeutet, dass innerhalb einer Exchange-Datenbank nur eine einzige Kopie einer bestimmten Nachricht zusammen mit einer einzigen Anlage (sofern vorhanden) gespeichert wird. Wenn die Nachricht an mehrere Empfänger auf dem gleichen Informationsspeicher gesendet wurde, werden zusätzliche Zeiger zu den Objekten (Nachricht, Anlage) erstellt, die Objekte werden aber nicht dupliziert. Das ist nicht nur sehr effizient, sondern kann auch Speicherplatz für Exchange einsparen, sowohl auf dem Datenträger als auch auf dem Band.
Exchange eignet sich zwar gut zum Wiederherstellen der gesamten Datenbank, zur Wiederherstellung einzelner Postfächer, Ordner oder Nachrichten muss jedoch zuerst das ganze Band wiederhergestellt werden. Es ist nicht überraschend, dass Benutzer besser abgestimmte Wiederherstellungsfunktionen fordern. Durch die Einzelinstanz auf dem Band gestaltet sich dies sehr schwierig. Anbieter von Sicherungslösungen haben auf diese Anforderung mit dem „Brick-Level Backup“ reagiert (das ich nicht empfehle). Nach Abschluss einer kompletten Sicherung der Exchange-Datenbank mit der genehmigten ESE-Sicherungs-API fügen die Sicherungsprodukte dem Sicherungsband alle Postfächer hinzu. Da die Sicherungs-API keine Möglichkeit bereitstellt, die Daten aus einzelnen Postfächern herauszuziehen, wird MAPI verwendet. Folglich ist das Sicherungsband erheblich länger, weil alle Nachrichten und Anlagen dupliziert werden.
Microsoft hat einige Verbesserungen vorgenommen, die das Problem teilweise ansprechen. Zum Beispiel werden Elemente nach dem Löschen durch einen Benutzer über einen bestimmten Zeitraum hinweg im Administratorpapierkorb aufbewahrt, falls sie erneut gebraucht werden. Außerdem ist es nicht mehr notwendig, einen zweiten Server als Gesamtstruktur für die Exchange-Notfallwiederherstellung zur Verfügung zu haben. Speichergruppen für die Wiederherstellung (Recovery Storage Groups, RSG) ermöglichen es einem Administrator nämlich, von Band wiederhergestellte Datenbanken teilweise bereitzustellen und Daten zu kopieren oder bis zur Postfachebene hinunter zusammenzuführen.

Übung macht den Meister
Sicherungsmedien und Wiederherstellungsverfahren müssen unabhängig vom Sicherungs- und Wiederherstellungsumfang regelmäßig getestet werden. Viele Organisationen lernen dies spätestens dann, wenn Daten einmal unwiderruflich verloren gegangen sind. Zu viele Administratoren finden erst heraus, ob ihre Sicherungstechnologien und Wiederherstellungsverfahren tatsächlich funktionieren, nachdem ein Notfall eingetreten ist. Der beste Testzeitpunkt ist der Tag, wenn der neue Server aufgebaut, konfiguriert und als Teil der Exchange-Organisation in Betrieb ist, aber erst ein paar Benutzer hat. Zu diesem Zeitpunkt sollte eine komplette Exchange-Sicherung sowie regelmäßige Sicherungen der Laufwerke durchgeführt und auch der Systemstatus erfasst werden, der äußerst wichtige Dateien auf dem Systemdatenträger sowie die IIS-Metabasis enthält (in der die Exchange-Routerkonfiguration gespeichert ist). Formatieren Sie dann den neuen Server in aller Ruhe neu. Aktualisieren Sie dabei die Notizen, die Sie beim ersten Aufbau des Servers dokumentiert haben. Sie müssen in der Lage sein, Einstellungen vom Systemstatus wiederherzustellen, sollten die Systemkonfigurationseinstellungen aber auch ausreichend dokumentiert haben, um sie manuell wiederherstellen zu können.
Durch einen solchen Test lässt sich die Zeit, die Sie in Zukunft für eine Wiederherstellung benötigen, erheblich verringern. Wiederholen Sie den Prozess in regelmäßigen Abständen. Messen Sie während der Testläufe auch gleich die Zeit, die benötigt wird, um Bänder von einem anderen Ort wieder zu Ihrem Server zu bringen. Sie werden sich auf diese Weise ein realistischeres Bild darüber machen können, wie wichtig eine Sicherungs- und Wiederherstellungsstrategie sein kann, selbst wenn Sie sich letztendlich für den Notfall auf Sicherungsbänder verlassen, die an einem anderen Ort aufbewahrt werden.

Herausforderungen bei der Bandsicherung
Eine Wiederherstellung von Band nimmt zu viel Zeit in Anspruch. Exchange ist für Organisationen inzwischen so wichtig, dass Benutzer und das Management ständige Verfügbarkeit erwarten. Wenn ein ernsthaftes Problem auftritt, werden die meisten Organisationen hiervon überrascht. Niemand plant bei seiner Arbeit ein, dass es acht Stunden dauern kann, eine 75 GB große Datenbank von Band wiederherzustellen, und das umfasst noch nicht einmal die Zeit für die Beschaffung der Bänder von einem anderen Ort oder für die Installation des Betriebssystems.
Außerdem besteht noch die Herausforderung, die richtige Datenbank vom Band abzurufen. In den 10 Jahren, seit Exchange erstmals auf den Markt kam, sind Festplattenspeicher und WANs sehr viel preiswerter geworden. Demzufolge können sich viele Organisationen schnellere Methoden zur Sicherung und Wiederherstellung leisten. Organisationen können heute Technologien nutzen, die es ihnen ermöglichen, betriebliche Kontinuität und Notfallwiederherstellung für ihre Exchange-Infrastruktur zu erhalten.

STUFE 2: BETRIEBLICHE KONTINUITÄT
Betriebliche Kontinuität ist ein Satz von Prozessen und Technologien, der eine Wiederherstellung beschleunigen und unerwartete Ausfallzeiten minimieren soll. Bei einer lokalen Wiederherstellung von Band bietet betriebliche Kontinuität eine verkürzte Zeitspanne von einem Ausfall bis zur Wiederaufnahme des Diensts (Recovery Time Objective, RTO) und eine geringere Datenmenge, deren Verlust toleriert werden kann (Recovery Point Objective, RPO). Die Zeit, die benötigt wird, um Bänder von einem anderen Ort zu holen, soll möglichst eliminiert werden. In Abbildung 2 ist ein Vergleich der betrieblichen Kontinuität für Sicherung und Wiederherstellung und DR abgebildet.
Abbildung 2 Wiederherstellungsfolge
Abbildung 2 Wiederherstellungsfolge
Das Schaubild illustriert die Wiederherstellungs- und Verfügbarkeitsfolge von langsam und billig am linken unteren Rand zu schnell und teuer am rechten oberen Rand, mit einem absichtlich verwischten Übergang zwischen betrieblichen Kontinuitäts- und Notfallwiederherstellungslösungen.
Das Schaubild vermittelt Ihnen einen Eindruck über die Kompromisse zwischen Kosten, Wiederherstellungszeiten und Verfügbarkeit bei den verschiedenen Ansätzen. In diesem Artikel unterscheide ich absichtlich ganz deutlich zwischen lokalen Kontinuitätsprozessen und Notfallwiederherstellung. DR wird immer als remote angesehen, mit dem Hauptziel, die Daten an einen anderen Ort zu bringen. Entfernung führt zu zusätzlichen Herausforderungen und ist in der Regel viel teurer, aber bei DR geht es darum. dass der Geschäftsbetrieb nach Notfällen fortgesetzt werden kann. Darauf wird weiter unten in diesem Artikel näher eingegangen.

Ein bisschen Geschichte
In dem Maße, in dem Exchange ein wichtigerer Bestandteil der Infrastruktur wurde und mehr Informationen in Exchange-Datenbanken gespeichert wurden, mussten die Sicherungs- und Wiederherstellungszeiten verkürzt werden. In Zusammenarbeit mit Microsoft entwickelten einige große Organisationen einen Ansatz, der eine bessere Rückkehr zum teilweisen Betrieb bot. Wenn eine Organisation E-Mails empfangen und senden kann, scheint nach außen alles in Ordnung zu sein. Der äußere Eindruck zählt nun mal.
Um diese „Dial-Tone“-Wiederherstellung für Exchange zu implementieren, kam anstelle der beschädigten Datenbank eine neue Datenbank zum Einsatz. Exchange und Active Directory® erstellten dann neue Postfächer mit den entsprechenden Zugriffsrechten, und Benutzer konnten E-Mails senden und empfangen. Wenn dann das Sicherungsband an Ort und Stelle war und die Daten wiederhergestellt waren, konnte es vom Administrator bereitgestellt werden. Der Exchange-Administrator führte dann die wiederhergestellten Postfächer mit den „Dial-Tone“-Postfächern zusammen. Postfächer konnten nach Bedarf priorisiert werden. Obwohl dies eine Verbesserung war, war es ein zeitaufwändiger und komplizierter Prozess, der ursprünglich EXMERGE verwendete und dann auf RSGs zugeschnitten wurde. Es sollte jedoch darauf hingewiesen werden, dass eine komplette Datenwiederherstellung nach einem „Dial-Tone“-Wiederherstellungsszenario mühsam und kompliziert sein kann, insbesondere, da in Exchange 2007 bis zu 50 Speichergruppen möglich sind. Wenn Sie erwägen, ein „Dial-Tone“-Wiederherstellungsszenario zu implementieren, sollten Sie die Vor- und Nachteile gründlich abwägen.

Volumeschattenkopie-Dienste
Um günstigere Datenträger zu nutzen und die Prozessorbelastung für Exchange-Server in der Produktion zu senken, wurde für Microsoft® Windows Server® 2003 und Exchange eine neue Sicherungs-API entwickelt. Der Volumeschattenkopie-Dienst (Volume Shadow Copy Service, VSS) wurde entwickelt, um konsistente Kopien von Daten für einen bestimmten Zeitpunkt zu erstellen. Bei diesen Snapshots handelt es sich um verkürzte, schreibgeschützte Kopien der Exchange-Daten, die fortlaufend nur die Daten enthalten, die sich geändert haben. Die Kopien zeigen gewöhnlich auf einen anderen Server mit verfügbarem Speicherplatz oder auf ein Storage Area Network (SAN). Es können mehrere Snapshots erstellt und auf Band gesichert werden. Der Exchange-Server in der Produktion wird damit also nicht mehr von der Leistung der Sicherungssoftware und der Belastung durch Bandkopien beeinträchtigt.
Es gibt mehrere Vorteile, die für eine Verwendung von VSS für den Exchange-Datenschutz sprechen. Erstens kann der Leistungsaufwand von Bandsicherungsvorgängen aus dem Exchange-Server entfernt werden. Eine Sicherung auf Band ist zwar immer noch erforderlich, aber es kann die Kopie der Exchange-Daten verwendet werden, sodass sich die Sicherung nicht auf die Benutzerleistung auswirkt. Zweitens wird es möglich, Snapshots häufiger als einmal pro Nacht zu erstellen. Als Bonus können Sie mehrere Snapshots auf dem sekundären Server oder einem anderen lokalen Speicher speichern.
Es gibt eine Reihe von Produkten von Drittanbietern auf dem Markt, die die VSS-Snapshotfunktionen nutzen. Einige verkürzen einfach die Zeit, die für eine Sicherung und Wiederherstellung von Exchange-Datenbanken erforderlich ist, während andere Funktionen wie eine besser abgestimmte Wiederherstellung als der systemeigene Exchange Server hinzufügen, wodurch Sie bis zur Postfachebene hinunter wiederherstellen können. Während niemand solche „Brick-Backups“ mag, möchten die Benutzer doch manchmal in der Lage sein, nur bestimmte Ordner oder sogar Nachrichten wiederherzustellen.

Replikationstechnologien
Softwaregestütztes Exchange-Failover wird von einigen Anbietern von Replikationslösungen als Option bereitgestellt. Dabei geht ein Exchange-Standbyserver live und teilt dann Active Directory mit, dass die Postfächer aller Benutzer verschoben wurden. Hierfür gibt es zwei Möglichkeiten, und beide erfordern einige Anpassungen der Exchange- und Windows-Umgebung. Bei der einen Möglichkeit sind ein paar Tricks mit DNS erforderlich, damit der Standbyserver den Namen und die IP-Adresse des ausgefallenen Servers annimmt. Dieser Ansatz hat den Vorteil, die Clientarbeitsstationen nicht zusätzlich zu belasten, da Outlook® denkt, dass immer noch der gleiche Server verwendet wird.
Beim zweiten Ansatz wird ein Standbyserver verwendet, auf dem Exchange ausgeführt wird und auf dem sich Kopien der Datenbank befinden, aber nichts bereitgestellt ist. Bei einem Ausfall informiert der Standbyserver Active Directory, dass alle Benutzerpostfächer zu diesem Server verschoben wurden. Dann wird ein Skript ausgeführt oder eine Gruppenrichtlinie verteilt, die die Clients informiert, dass sie sich auf einem anderen Mailserver befinden. Outlook 2007 erkennt Active Directory, was den Prozess erleichtert, weil diese Zuordnungen automatisch gefunden werden.

Lokale Clusterbildung mit MSCS
Höher in der Verfügbarkeitsfolge ist Microsoft Cluster Services (MSCS). Exchange ist eine clusterorientierte Anwendung. Clusterbildung gibt Informationen zwischen zwei oder mehr Computern frei, damit bei einem Ausfall ein anderer Computer einspringen kann. Heute liegen in den meisten Exchange-Clustern zwei oder vier Knoten vor, obwohl bis zu acht Knoten verwendet werden können. Ein Knoten ist immer passiv und funktioniert, wenn Windows Server ausgeführt wird und Exchange Server installiert ist, aber keine aktiven Postfächer vorhanden sind. Ein 2-Knoten-Cluster (aktiv/aktiv) war in Exchange 2003 möglich, ist aber aufgrund des Leistungsaufwands heute nicht mehr die bevorzugte Option und wird in Exchange 2007 nicht unterstützt.
Wie bei der Exchange 2003-Clusteranordnung können die Exchange 2007-Cluster, die einen passiven Knoten enthalten, immer noch ein einzelnes freigegebenes Speicherarray verwenden. Obwohl Speicherarrays mit Clusterqualität in der Regel über eine Anzahl von Redundanzfeatures verfügen, die vielen Arten von Fehlern widerstehen, stellen sie nach wie vor nur eine Kopie der Daten bereit, wodurch eine Sicherheitslücke verbleibt. Diese Cluster werden als Einzelkopiecluster (Single Copy Cluster, SCC) bezeichnet, um sie von der nächsten Stufe des Datenschutzes zu unterscheiden, die sich in Exchange 2007 in Form von Mehrfachkopieclustern (Multiple Copy Cluster, MCC) präsentiert. Unter dem Thema Notfallwiederherstellung werden MCCs detaillierter beleuchtet.

Lokale ununterbrochene Replikation
Lokale ununterbrochene Replikation (Local Continuous Replication, LCR) ist ein neues Feature in Exchange 2007, das eine verbesserte Möglichkeit bietet, eine zweite Kopie der Exchange-Datenbanken und Transaktionsprotokolle auf demselben Server zu speichern. Hierdurch wird der Best Practice, die Exchange-Datenbank auf einem RAID-Array und die Transaktionsprotokolle auf einem anderem zu speichern, eine Redundanzebene hinzugefügt: LCR ermöglicht es, eine sekundäre Kopie der Protokolle auf dem Array zu speichern, das die primäre Kopie der Datenbank enthält und dann eine sekundäre Kopie der Datenbank auf dem Array zu speichern, das die primäre Kopie der Protokolle enthält (siehe Abbildung 3). Wenn der RAID-Controller oder das Array ausfällt, stehen immer noch die Datenbank und die Transaktionsprotokolle auf dem anderen Array zur Verfügung. Auf diese Weise können Sie weiterarbeiten, wenn auch nicht mit einer gleich hohen Leistung, bis Sie das ausgefallene Array wieder aufbauen können.
Abbildung 3 Konfigurieren von LCR
Abbildung 3 Konfigurieren von LCR
LCR ist eine lokale betriebliche Kontinuitätslösung und keine Sicherungslösung, deshalb benötigen Sie nach wie vor eine komplette Sicherungsstrategie. Mit LCR wird auch die Leistung beeinträchtigt, weil der Server jetzt zwei Kopien der Datenbank und der Transaktionsprotokolle erstellt. Außerdem gibt es in der Exchange 2007-Implementierung einige Beschränkungen, durch die sich LCR lediglich für kleinere Organisationen eignet, weil LCR nur eine Datenbank in einer Speichergruppe und nur eine öffentliche Ordnerdatenbank in einer Organisation unterstützt.
Ein Failover mithilfe einer LCR-Wiederherstellung erfolgt nicht automatisch. Ein erfahrener IT-Mitarbeiter muss Skripts ausführen, um Exchange wiederherzustellen. Der Prozess erfordert die Ausführung von Exchange-Verwaltungsshellbefehlen, die außerhalb der Exchange-Verwaltungskonsole ausgeführt werden.
Exchange Server 2003 Enterprise Edition ermöglichte einer Organisation das Ausführen von bis zu 20 Exchange-Datenbanken (vier Speichergruppen mit bis zu je fünf Datenbanken). Exchange 2007 Enterprise Edition dagegen lässt bis zu 50 Speichergruppen zu, wobei jede ihre eigene Datenbank hat. Die Transaktionsprotokolle wurden außerdem von 5 MB-Dateien in Exchange 2003 auf 1 MB-Dateien in Exchange 2007 verringert. Beide Änderungen sollen LCR und die fortlaufende Clusterreplikation (Cluster Continuous Replication, CCR) unterstützen, deren Relevanz weiter unten deutlich wird.
Für kleine und mittelständische Organisationen bietet LCR einen verbesserten Datenschutz der Exchange-Vorgänge. LCR ist leicht zu implementieren, erfordert aber immer noch manuelle Eingriffe. Als eine „gleicher Server/lokaler Datenträger“-Lösung ist LCR nur ein erster Schritt in Richtung verbesserter betrieblicher Kontinuität. LCR schützt zwar vor Ausfällen eines RAID-Arrays und von RAID-Controllern, aber mehrere simultane Abstürze von Festplatten oder Ausfälle von RAID-Controllern sind relativ selten. Meistens handelt es sich bei einem Ausfallszenario um den Zusammenbruch des gesamten Servers, was eine gute Überleitung zum nächsten Schritt für den Schutz von Exchange bietet.

Lokale Off-Host-Replikation von Drittanbietern
Um die Wiederherstellungsfunktionen von Exchange zu erweitern, haben Drittanbieter Produkte entwickelt, die die Off-Host-Replikation über die Exchange Protokolldateien nutzen, um eine Standbykopie der Exchange-Datenbank auf einem anderen Computer zu speichern. In diesem Fall führt die Datenschutz- oder Archivlösung eine vollständige ESE-Sicherung von Exchange auf einen anderen Computer durch und ruft dann Transaktionsprotokolle ab, sobald Exchange sie schließt. Sie fügt diese Transaktionen in die Exchange-Datenbankkopie ein, damit diese immer auf dem neuesten Stand ist. Wie bereits erwähnt, sind diese Protokolle relativ klein (5 MB in Exchange 2003 und 1 MB in Exchange 2007), damit die Protokolldateien nach der Sicherung auf den Off-Host-Server kopiert werden können, ohne die Leistung des Exchange-Servers zu verringern.

STUFE 3: NOTFALLWIEDERHERSTELLUNG UND HOHE VERFÜGBARKEIT
Notfallwiederherstellung ist die Möglichkeit, schnell wieder den Betrieb aufnehmen zu können, wenn das Hauptdatenzentrum plötzlich nicht mehr verfügbar ist. Exchange benötigt eine effektive Notfallwiederherstellung, weil heute viele Organisationen ohne E-Mail- und Kalenderfunktionen nicht mehr richtig arbeiten können.
Einige Unternehmen sagen sich, dass traditionelle Bandsicherungen, die an einem anderen Ort aufbewahrt werden, eine Form der Notfallwiederherstellung sind, aber wenn Ihr einziges Datenzentrum durch Feuer oder Überschwemmung zerstört wird, ist ein mit Bandspulen beladener Lkw von geringem Wert. Notfallwiederherstellung beinhaltet nicht nur, dass die Daten an einem anderen Ort aufbewahrt werden, sondern auch, dass die Technologien und Prozesse vorliegen, um die Anwendung wiederherzustellen und zum Laufen zu bringen. Um effektiv zu sein, müssen für eine Notfallwiederherstellung primäre und sekundäre Systeme physisch voneinander getrennt werden. Wie weit auseinander die Standorte liegen sollten, hängt von der Größe der Katastrophe ab, die Sie überwinden wollen. Wenn Sie sich am meisten Sorgen darum machen, dass Ihre Daten in Flammen aufgehen, reicht es, die Bänder in einem anderen Gebäude am selben Standort aufzubewahren. Infrastrukturkatastrophen, bei denen Züge oder Flugzeuge beteiligt sind, könnten jedoch einen Radius von einem Kilometer oder mehr betreffen. Viele Katastrophen sind regional: Überschwemmungen, Schneestürme, Erdbeben und sogar Stromausfälle. Aber auch die Kommunikation kann in Mitleidenschaft gezogen werden, angefangen von Problemen, durch die die Verbindung zu Ihrem ISP unterbrochen wird, bis zu Denial-of-Service-Angriffen und Internet-DoS-Angriffen, die allgemein darauf ausgerichtet sind, Unternehmen Schaden zuzufügen.
Ein praktischer Tipp: Wenn Ihre Organisation bereits über mehr als einen Standort mit IT-Personal verfügt, erfüllt einer dieser Standorte vielleicht Ihre Unternehmenskriterien für die Remotekontinuität, um Sie vor genau den gefürchteten Katastrophen zu schützen. Wenn Sie eigene Gebäude und eigenes Personal verwenden, ist dies weit weniger kostspielig als einen Notfallwiederherstellungsanbieter zu beauftragen oder Räume an einem neuen Standort anzumieten.
Ultimativ geht es bei der Notfallwiederherstellung auch um Wahrnehmung: Geben Sie Ihren Kunden die Gewissheit, das Sie immer noch im Geschäft sind. Ihre Kunden werden Verständnis dafür haben, wenn eine Katastrophe eine Stadt oder Region trifft, aber wenn Ihr Unternehmen nicht innerhalb von ein paar Tagen bis zu einer Woche wieder online ist, nehmen Kunden und Lieferanten u. U. das Schlimmste an. Viele Unternehmen scheitern aus diesem Grund. Der Kunde muss den Eindruck erhalten, dass der Geschäftsbetrieb nur kurzzeitig unterbrochen ist und Sie dabei sind, den Betrieb wiederherzustellen. Wie schnell Sie nach Meinung Ihrer Kunden wieder voll einsatzbereit sein sollten, hängt vom einzelnen Kunden ab: Verständlicherweise wird ein Kunde bei einem Finanzdienstleistungsinstitut weniger Geduld an den Tag legen als zum Beispiel bei einem Lieferanten von Büromöbeln.

Anforderungen an die Notfallwiederherstellung
Um in der Lage zu sein, Exchange nach einer Katastrophe wieder online zu bringen, müssen die Daten auf den sekundären Standort repliziert werden. Es müssen Replikationstechnologien eingesetzt werden, die die Daten auf einen laufenden Exchange-Server aufspielen und dann die Outlook-Clients benachrichtigen, dass ihre Postfächer verschoben wurden.
Die Replikation von Exchange ist, besonders über weite Entfernungen, nicht einfach. Es handelt sich um eine echte Transaktionsdatenbank, bei der die Reihenfolge der Schreibvorgänge extrem wichtig ist. Die Herausforderung wird dadurch noch verkompliziert, dass das Transportprotokoll, das Exchange zur Weiterleitung aller Transaktionen und Systeminformationen zwischen den Servern verwendet, SMTP ist. SMTP ist ein bandbreitenintensives Protokoll. Außerdem muss bei Exchange-Clustern alle 500 Millisekunden ein Signal zwischen Systemen gesendet werden. Wenn ein sekundärer Knoten dieses Signal nicht erhält, wird hierdurch u. U. der Start eines Failovers ausgelöst.
Die Schwierigkeit, diese Herausforderungen zu meistern, sind vielleicht ein Grund dafür, warum Microsoft sich erst jetzt mit Exchange 2007 dieses Problems annimmt. In Abwesenheit einer Microsoft-Lösung sind mehrere Drittanbieterlösungen entwickelt worden, um Exchange-Daten über host- oder arraybasierte Replikation zu replizieren.
Anbieter haben erkannt, dass ein Cluster durch die Verteilung der Knoten auf verschiedene Standorte erweitert werden kann. Dies wird als Stretchcluster bezeichnet. Heute werden Stretchcluster meistens über Datenreplikationsprodukte von Drittanbietern oder Produkte, die speziell für die Erweiterung eines Exchange-Knotens ausgelegt sind, implementiert. Dies kann mithilfe von MSCS erfolgen, aber die Subnetzanforderung über ein WAN ist relativ kompliziert. Clusterbildung und die Komplexitäten, zuverlässige Konnektivität hoher Bandbreite zu Remoterechenzentren bereitzustellen, erhöhen verständlicherweise die Kosten und den Personalbedarf, um Notfallwiederherstellungssysteme aufzubauen, zu verwalten und in regelmäßigen Abständen zu testen.

Fortlaufende Clusterreplikation
Mit Exchange 2007 erweitert Microsoft den Clustersupport mit fortlaufender Clusterreplikation. Durch CCR wird in LCR die Möglichkeit erweitert, zwei Kopien einer Exchange-Datenbank und der Transaktionsprotokolle zu speichern, um die gleiche Idee auf zwei Clusterknoten zu implementieren. Notfallwiederherstellung impliziert eine geografische Trennung primärer und sekundärer Systeme, und die Mehrfachkopiecluster von Microsoft werden bis zur Veröffentlichung Windows Server 2008 (früherer Codename „Longhorn“), der Stretchcluster ermöglicht, keine großen Entfernungen überbrücken können.
Die Technologie, die es MCC-Knoten ermöglicht, separate Kopien der Daten zu halten, wird als Majority Node Set (MNS) bezeichnet und bezieht sich auf den Wahlprozess, den die zwei oder mehr Knoten durchführen, um zu bestimmen, wer die Livekopie der Daten hält. Bei einem Ausfall halten die übrigen Knoten eine neue Wahl ab, um zu bestimmen, wer die Rolle des neuen primären Verarbeitungs-/Datenservers übernehmen soll. Unterstützt wird diese technische Demokratie durch CCR, das sicherstellt, dass jeder Knoten über eine aktuelle Datenbank verfügt. Exchange 2007-Cluster, die CCR verwenden, sind auf nur zwei Knoten beschränkt.
In größeren Konfigurationen konfigurieren Exchange-Server in der Regel die lokale Systemfestplatte auf dem Server und stellen dann über ein SAN (über SCSI, Glasfaser oder iSCSI-Festplattenarrays) eine Verbindung zur Exchange-Datenbank her. Bei einem MCC/MNS-Cluster ist eine interessante Frage, ob bei einer High-End-Exchange-Speicherung wieder auf lokale RAID-Arrays für jeden Knoten zurückgegriffen wird. Wenn der Zweck eines MNS-Clusters darin besteht, jedem Knoten die Fähigkeit zu geben, seinen eigenen getrennten Speicher zu halten, ist es dann immer noch sinnvoll, jeden Knoten auf ein SAN zeigen zu lassen, dessen Hauptzweck darin besteht, gemeinsamen Speicher bereitzustellen?
Bei einem normalen MCC-/MNS-Clusterszenario gäbe es wahrscheinlich den primären Knoten mit Speicher auf dem SAN und einen sekundären Clusterknoten mit lokalen Festplatten oder einem preisgünstigeren iSCSI-SAN. Dieser sekundäre Knoten könnte entfernt vom primären Datencenter an einem Ort sein, der nicht über SAN-Infrastruktur verfügt.
Unabhängig vom Resultat ist MCC, das MNS und CCR verwendet, ein weiterer Schritt nach oben in der Hierarchie der Redundanz und verbesserten Verfügbarkeit, weil mehrere Computer ein Failover haben können und die Daten auf getrennten Speicherelementen repliziert sind. Bis Windows Server 2008 auf den Markt kommt, befindet sich dies alles allerdings weiterhin in einem einzigen Datencenter. Windows Server 2008 unterstützt Stretchcluster, wodurch Knoten in einem MNS-Cluster geografisch so weit wie gewünscht getrennt werden können, solange die Netzwerklatenz zwischen Knoten weniger als 500 ms beträgt. Bis dahin (und danach) kann Clustertechnologie von Drittanbietern auf Microsoft MNS und CCR aufgesetzt werden, um die geografische Trennung bereitzustellen, die zum Ausdehnen von Clustern erforderlich ist, und eine effektive Notfallwiederherstellungslösung bereitzustellen.
Clusterbildung befindet sich am oberen Ende der Notfallwiederherstellungsfolge, und CCR ist entsprechend als eine Hochverfügbarkeitsfunktion von Exchange positioniert. Auch wenn diese Kombination erhöhten Kosten- und Personalaufwand erfordert, verspricht sie, eine interessante Lösung für Kunden zu sein, die eine homogene Microsoft-Umgebung betreiben wollen.

Betriebliche Remotekontinuität für Anwendungen von Drittanbietern
Es besteht kein Zweifel daran, dass die Microsoft-Lösung und Erweiterungen von Drittanbietern am oberen Ende der Wiederherstellungsfolge angesiedelt sein werden, wenn die Lösung verfügbar wird. Automatisches Failover innerhalb von Sekunden – besser geht es nicht. Nicht jedes Unternehmen benötigt jedoch dieses Maß an Verfügbarkeit und Geschäftskontinuität, noch kann es sich jedes Unternehmen leisten, die hohen Summen zu investieren, die hierfür erforderlich sind. Für viele Unternehmen liefert eine zuverlässige Lösung, die Exchange vollständig in Minuten wiederherstellt, die gesamte erforderliche betriebliche Kontinuität.
Ein Beispiel: Mimosa Systems, Inc. erweitert die betriebliche Kontinuität innerhalb eines einzigen Datencenters auf Remotekontinuität. An einem Remotestandort bewahrt Mimosa DR eine Kopie von Exchange auf, hält sie mit den Transaktionsprotokollen des primären Exchange-Servers auf dem neuesten Stand, und ist immer in der Lage, diese Livekopie für den Exchange-Standbyserver zur Verfügung zu stellen. Der Exchange Server am Remotestandort verwendet Standardserverhardware und genau wie bei der Implementierung eines einzelnen Datencenters sorgen Sie dafür, dass es im Notfall sofort aktiviert werden kann. Sollte ein Notfall eintreten, initiiert ein Bediener am Remotestandort das Failover und führt es durch, einschließlich der Bereitstellung der Standby-Datenbankdateien, der erneuten Zuordnung von Postfächern und der Outlook-Profile. Beachten Sie, dass Drittanbieterlösungen dieser Art den Supportbegrenzungen unterliegen, die im Knowledge Base-Artikel Microsoft-Supportrichtlinie für Drittanbieterprodukte, die Exchange-Datenbankinhalte verändern oder extrahieren definiert sind.

Schlussbemerkung
Exchange-Datenschutz ist als eine Folge von Technologien und Verfahren verfügbar, die abhängig von Kosten und Funktionen in drei Ebenen gruppiert werden können. Wenn Sie sich über Anforderungen in Bezug auf den Schutz von Exchange-Daten Gedanken machen, sollten Sie sich überlegen, wie viele Ausfallzeiten alle Beteiligten akzeptieren können. Größere Leistung und schnellere Wiederherstellung kosten mehr, und die Preise für High-End-Optionen liegen im sechsstelligen Bereich. Es gibt preisgünstigere Lösungen, die jedoch nicht ganz das höchste Maß an Verfügbarkeit erreichen. Entscheiden Sie sich für die Option, die den Anforderungen Ihrer Organisation entspricht.
Service Pack 1 für Exchange 2007
Service Pack 1 (SP1) für Exchange 2007, das sich momentan in der Betatestphase befindet, enthält eine Reihe von Funktionen, die Administratoren bisher fehlten, darunter Verbesserungen bei OWA, zusätzliche GUI-Funktionen in der Konsole und mehr.
Besonders interessant für Administratoren, die Wiederherstellungslösungen planen, ist eine dritte Verfügbarkeitslösung in Exchange 2007 SP1, um LCR und CCR zu ergänzen: Sekundäre ununterbrochene Replikation (Secondary Continuous Replication, SCR). Dies ist eine mittlere Lösung von Microsoft, die eine höhere Wiederherstellbarkeit ohne die Komplexität einer „hohen Verfügbarkeit“ bietet.
SCR ermöglicht die Replikation der Exchange-Datenbank und der Transaktionsprotokolle auf einem anderen Exchange-Server als dem, auf dem sich Ihre Postfächer normalerweise befinden. Das SCR-Ziel kann lokal oder entfernt und ein Exchange-Standbyserver oder ein Cluster sein. SCR erfordert jedoch keinen Cluster an beiden Orten und unterscheidet sich von CCR dadurch, dass das Ziel eine Standbyumgebung und das Failover ein manueller Prozess ist. Beachten Sie, dass Sie nach wie vor die erste große Kopie (also eine vollständige Sicherung) selbst auf den anderen Computer bringen müssen. Sie müssen eine solche große Replikation u. U. von Zeit zu Zeit durchführen und sich dabei der Folgen für Ihr Netzwerk bewusst sein, genau wie bei CCR und Lösungen von Drittanbietern. Meiner Meinung nach werden SCR und CCR sowie Add-On-Produkte, die ähnliche und sogar mehr Funktionen bieten, in Zukunft eine weite Verbreitung in Unternehmen finden.

Lee Benjamin ist Geschäftsführer von ExchangeGuy Consulting Services, ein Consultingunternehmen, das direkt mit Kunden zusammenarbeitet und Microsoft-Partner berät. Er ist Vorsitzender der größten Exchange-Benutzergruppe der Welt, ExchangeServerBoston, und Direktor der BostonUserGroups. Außerdem ist Lee Benjamin MVP für Exchange, ein Microsoft-zertifizierter Schulungsleiter und regelmäßiger Referent bei Konferenzen.
© 2007 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


 Kommunikation: Verbesserte Sicherheit mit Windows Mobile&#160;6
Kommunikation Matt Fontaine

Verbesserte Sicherheit mit Windows Mobile 6
Kurz zusammengefasst:
  • Sicherheit im Gerät
  • Exchange Server-Sicherheit
  • Netzwerksicherheit

Mobile Geräte erhöhen die Produktivität von Mitarbeitern weltweit, bieten ihnen Zugriff auf Unternehmensdaten und sorgen für Verbindung, selbst wenn die Mitarbeiter nicht im
Büro anwesend sind. Die Folge sind echte Produktivitätssteigerungen: der Mitarbeiter muss lediglich das mobile Gerät einschalten und kann mit der Arbeit beginnen.
Die Kehrseite der Medaille ist, dass IT-Fachleute vor der schwierigen Aufgabe stehen, das virtuelle Büro zu sichern und stabil zu halten. Aus ihrer Perspektive ist jedes mobile Gerät eine potenzielle Lücke in der Netzwerksicherheit, die es zu schließen gilt, und zudem anfällig für Datendiebstahl. Es ist wichtig, für eine sicherere Bereitstellung von mobilen Geräten zu sorgen, doch diese Geräte müssen trotzdem nahtlos, intuitiv und benutzerfreundlich zu bedienen sein.
Microsoft® Windows Mobile® 6 und sein Vorgänger Windows Mobile 5.0 mit dem Messaging and Security Feature Pack (MSFP) umfassen viele Features, die Ihnen unter minimalen Schwierigkeiten bei der Sicherung der Unternehmensinfrastruktur behilflich sind, und das unter möglichst wenig Unannehmlichkeiten für Ihre Benutzer. Die Verwendung von Microsoft Exchange Server als Messagingplattform erhöht die verfügbaren Sicherheitsoptionen noch weiter. In diesem Artikel wird erörtert, wie Sie Windows Mobile, Exchange Server und einige bewährte Methoden der Netzwerksicherheit als Grundlage für den Schutz der mobilen Geräte ihres Unternehmens einsetzen können.

Architektur für mobile Kommunikation
Beim Planen oder Aktualisieren einer mobilen Bereitstellung gilt es, drei Schichten zu beachten: das Gerät, den Messagingserver und das Netzwerk (siehe Abbildung 1). Auf der Geräteebene gehören zu den wichtigsten Herausforderungen ein autorisierter Zugriff auf das Gerät und das Verhindern nicht autorisierter Anwendungen auf dem Gerät. Windows Mobile hilft durch PIN-Authentifizierung und Kennwortschutz, Sperren des Geräts nach einem Zeitlimit und die Möglichkeit, den Speicher des Geräts bei Verlust oder Diebstahl durch lokale oder Remoteausführung zu „bereinigen“ oder zu löschen, einen nicht autorisierten Zugriff auf das Gerät zu verhindern. Die Datenverschlüsselung des Kommunikationskanals und des Wechseldatenträgers wird unterstützt. Zudem ist es äußerst wichtig, die Installation nicht autorisierter Anwendungen wie Viren oder Spyware oder deren Zugriff auf kritische Bereiche des Geräts zu verhindern. Die Definition von Verwaltungsrollen, Stufen für den Anwendungszugriff, Einstellungen für die Codesignatur, Sicherheitseinstellungen und Sicherheitszertifikate tragen gemeinsam zum Schutz auf Geräteebene bei.
Abbildung 1 Schichten mobiler Kommunikation
Abbildung 1 Schichten mobiler Kommunikation
Die nächste Sicherheitsschicht ist der Messagingserver wie beispielsweise Exchange Server 2003 mit Service Pack 2 (SP2) oder Exchange Server 2007. Diese Schicht umfasst sowohl die Nachrichtensicherheit (die Technologie, mit der Nachrichten sicher zum und vom Gerät übertragen werden) als auch die Interaktion zwischen dem Messagingserver und dem mobilen Gerät über Exchange ActiveSync®. Exchange Server ist für die Verwendung von Windows Mobile-Geräten nicht erforderlich, doch die Verwendung von Exchange bietet Vorteile bei Kosten, Skalierbarkeit, Leistung und Verwaltung.
Gute Sicherheitspraktiken auf der Geräteebene und beim Messagingserver sind unentbehrlich, doch der Schutz der Netzwerkschicht ist ebenfalls äußerst wichtig. Durch Konfigurieren des Unternehmensnetzwerks anhand bewährter Methoden und durch Implementieren leistungsfähiger Sicherheitsprotokolle können Sie das Netzwerk vor Schaden schützen, selbst wenn ein oder mehrere mobile Geräte gefährdet sind.

Sicherheitsrichtlinien für das Gerät
Die erste Verteidigungslinie gegen Sicherheitsverletzungen ist das Windows Mobile-Gerät selbst. Das Windows Mobile-Betriebssystem stellt umfangreiche Sicherheitsdienste auf Geräteebene bereit, die Authentifizierung, Speicherkartenverschlüsselung, virtuelle private Netzwerke (VPN), Wi-Fi-Verschlüsselung und SSL-Dienste (Secure Sockets Layer) unterstützen. Bei der Sicherheit auf Geräteebene geht es um die Verwaltung des Zugriffs auf Gerät und Daten, die Steuerung der Anwendungen, die auf dem Gerät ausgeführt werden können, und die Festlegung, wie Daten zum und vom Gerät übertragen werden. Im Allgemeinen haben Administratoren beim Festlegen und Durchsetzen der Sicherheitsrichtlinien bei Windows Mobile 5.0 mit MSFP und Windows Mobile 6 viel Flexibilität.
Der Benutzerzugriff wird durch eine PIN oder Kennwortauthentifizierung verwaltet. Ein Gerät kann so eingestellt werden, dass es nach einem bestimmten Zeitraum der Inaktivität oder nach dem Ausschalten automatisch gesperrt wird, sodass der Benutzer es vor der Weiterverwendung entsperren muss (siehe Abbildung 2). Die Einzelheiten der Benutzerzugriffssteuerung werden mithilfe von Sicherheitsrichtlinien festgelegt, die abhängig von der Sicherheitsrolle des Administrators geändert werden können.
Abbildung 2 Festlegen von Kennwortrichtlinien
Abbildung 2 Festlegen von Kennwortrichtlinien
Durch Sicherheitsrichtlinien werden globale Sicherheitsstufen für das mobile Gerät definiert (siehe Abbildung 3). Wer diese Sicherheitsrichtlinien festlegen und ändern kann, wird durch Sicherheitsrollen bestimmt. Die normalerweise Mobilfunkbetreibern vorbehaltene Managerrolle bietet vollständige Kontrolle über die Sicherheitsrichtlinieneinstellungen. Die Enterprise-Rolle dient bei Exchange zum Verwalten bestimmter Geräterichtlinien, die vom Exchange-Administrator konfiguriert werden. Abhängig von Ihrer Vereinbarung mit dem Geräteanbieter können Sie möglicherweise Sicherheitsrichtlinien für Ihr Unternehmen anpassen.
Figure 3 Sicherheitsrichtlinien für mobile Geräte (Close Figure 3)

Umgebung Mobiles Gerät
Sperrung nicht autorisierter Eindringversuche in das Gerät

Windows Mobile 5.0 mit MSFP

Legen Sie fest, dass sich der Benutzer immer auf dem Gerät authentifizieren muss, um es zu entsperren, oder ermöglichen Sie es dem Benutzer, eine PIN auf dem Desktop-PC einzugeben.
Standardrolle: Manager, Enterprise.

Windows Mobile 6

Ermöglichen oder verweigern Sie dem Benutzer die Berechtigung, mobile Verschlüsselungseinstellungen für Wechselspeichermedien zu ändern.
Standardrolle: Manager, Enterprise.
Geben Sie an, ob sich der Benutzer auf dem Gerät bei einer Verbindung authentifizieren muss, wenn die Gerätesperre aktiv ist. Standardrolle: Manager, Enterprise.
Schützen Sie vertrauliche Daten im Fall von Gerätediebstahl oder -verlust

Windows Mobile 5.0 mit MSFP

Legen Sie fest, dass sich der Benutzer immer auf dem Gerät authentifizieren muss, um es zu entsperren, oder ermöglichen Sie es dem Benutzer, eine PIN auf dem Desktop-PC einzugeben.
Standardrolle: Manager, Enterprise.

Windows Mobile 5.0 mit MSFP und Windows Mobile 6

Legen Sie fest, ob ein Kennwort auf dem Gerät konfiguriert werden muss. Konfigurieren Sie Einstellungen für die lokale Bereinigung des Geräts oder die Bereinigung von einem Remotestandort aus.
Standardrolle: Manager, Enterprise.
Von Windows Mobile verwendete anpassbare Authentifizierungsmethoden werden von lokalen Authentifizierungs-Plug-Ins (Local Authentication Plug-Ins, LAPs) gesteuert, die mit dem lokalen Authentifizierungssubsystem (Local Authentication Subsystem, LASS) interagieren. Diese Technologie ermöglicht es Exchange Server, die Gerätekonfiguration auf fein abgestimmter Ebene zu kontrollieren, indem beispielsweise Anforderungen an Kennwortlänge und -stärke durchgesetzt oder einfache PIN-Authentifizierung aktiviert werden.
Windows Mobile 6 verfügt über einen erweiterten Satz an LAP-Funktionen, die mithilfe von Exchange Server 2007 konfiguriert werden. Sie können die PIN-Mustererkennung aktivieren (und beispielsweise die Verwendung einfacher Muster wie „1111“ oder „1234“ unterbinden), Ablauffristen für Kennwort oder PIN konfigurieren, Benutzern die Anforderung einer PIN-Rücksetzung unter bestimmten Bedingungen ermöglichen oder einen PIN/Kennwortverlauf erstellen, sodass Benutzer alte PINs oder Kennwörter nicht wiederverwenden können, wenn sie zum Erstellen neuer aufgefordert werden.

Der Schutz von Daten auf Geräten
Falls eine falsche PIN oder ein falsches Kennwort häufiger eingegeben wird als dies aufgrund des vom Administrator festgelegten Limits zulässig ist, setzt die lokale Bereinigungsfunktion das Gerät zurück, wobei der Speicher einschließlich Benutzeranmeldeinformationen für die Authentifizierung gelöscht wird. Das Limit wird als Teil der Sicherheitsrichtlinien in Exchange Server festgelegt. Nach jeweils zwei falschen Eingaben fordert das Gerät den Benutzer zur Eingabe einer strukturierten Schlüsselzeichenfolge auf, um fortzufahren (siehe Abbildung 4). Dies verhindert, dass das Gerät unbeabsichtigt aufgrund zufälliger Tastatureingaben bereinigt wird. Die Bereinigung der Speicherkarte von einem Remotestandort aus ist bei Verwendung von Windows Mobile 6 und Exchange Server 2007 ebenfalls möglich.
Abbildung 4 Durchsetzen der PIN- und Kennwortverwendung
Abbildung 4 Durchsetzen der PIN- und Kennwortverwendung
Das Sperren eines Geräts ist wenig sinnvoll, wenn jemand eine 2-GB-Speicherkarte mit vertraulichen Unternehmensdaten in einem Taxi vergisst. Glücklicherweise können Sie Windows Mobile 6 auch zur Behandlung dieses Problems verwenden. Das Programm kann Speicherkartendaten verschlüsseln, sodass nur das Gerät, auf dem auf die Speicherkarte geschrieben wurde, diese auch lesen kann. Wie bei vielen anderen erweiterten Sicherheitsfeatures von Windows Mobile 6 kann Exchange Server 2007 verwendet werden, um dieses Sicherheitsfeature von einem Remotestandort aus bereitzustellen. Die Speicherkartenverschlüsselung ist für den Benutzer größtenteils transparent. Mithilfe von Exchange Server 2007 kann der Administrator auswählen, ob Benutzer ihre Einstellungen für die Speicherkartenverschlüsselung ändern können.
Ob Anwendungen auf einem Windows Mobile-Gerät ausgeführt werden können oder nicht, basiert auf drei Berechtigungsebenen: Privilegiert, Normal und Gesperrt. Anwendungen der privilegierten Ebene (anhand eines Zertifikats im Zertifikatsspeicher „Privilegiert“ signiert) können in die Registrierungs- und Systemdateien schreiben und auch Zertifikate installieren. Wie bei einem Desktop-PC oder Server ist die Chance einer Gefährdung dieser Umgebung umso höher, je mehr Anwendungen die Betriebssystemumgebung ändern können. Allgemein ist es eine gute Vorgehensweise, die Anzahl von Anwendungen mit dem Zugriff „Privilegiert“ möglichst gering zu halten. Die meisten Anwendungen müssen nur auf der Ebene „Normal“ ausgeführt werden (Anwendungen, die entweder von einem Zertifikat im Unpriv-Zertifikatsspeicher signiert werden oder nicht signierte Anwendungen, deren Ausführung der Benutzer zugestimmt hat), sodass die Ausführung erfolgt, aber der Zugriff auf Systemdateien verhindert wird Gesperrte Anwendungen sind, wie der Name schon sagt, gesperrt. Sie können aufgrund falscher Signatur oder Benutzeraktionen nicht ausgeführt werden.
Geräte können eine ein- oder zweistufige Sicherheitszugriffskonfiguration haben. Bei einstufiger Zugriffskonfiguration werden nicht signierte Anwendungen entweder mit dem Zugriff „Privilegiert“ ausgeführt oder gesperrt, sodass sie nicht ausgeführt werden können. Eine zweistufige Zugriffskonfiguration führt nicht signierte Anwendungen auf normaler Ebene aus, wenn die Richtlinienprüfung erfolgreich ist oder wenn der Benutzer die Ausführung der Anwendung ermöglicht. Abhängig von den Geräteeinstellungen kann der Benutzer gefragt werden, ob eine nicht signierte Anwendung ausgeführt werden soll oder nicht.
Digitale Zertifikate – eine der gebräuchlichsten Formen der Personen-, Geräte- und Anwendungsauthentifizierung – sind ein entscheidender Teil der Windows Mobile-Sicherheit auf Geräte-, Server- und Netzwerkebene. Das Windows Mobile-Betriebssystem speichert mehrere Arten von Zertifikaten in verschiedenen Zertifikatsspeichern auf dem Gerät. In Bezug auf Anwendungen bestimmen Zertifikate, welche Anwendungen installiert und ausgeführt werden können. Damit eine Anwendung auf einem Windows Mobile-Gerät ausgeführt werden kann, ohne dass der Benutzer zu einer Eingabe aufgefordert wird, muss sie mit einem Zertifikat signiert werden, das beweist, dass sie vom Microsoft Mobile2Mobile-Programm akzeptiert wurde. Anwendungen erhalten Berechtigungsebenen auf der Grundlage der Zertifikate, die ihnen zugeordnet sind.
Zur Netzwerkauthentifizierung ist jedes mobile Gerät mit einer Reihe vertrauenswürdiger Stammzertifikate ausgestattet, die von einer Zertifizierungsstelle (CA) ausgestellt wurden, wie in Abbildung 5 dargestellt. Der Messagingserver (beispielsweise Exchange Server) überprüft die Echtheit des Stammzertifikats eines Geräts, bevor eine SSL-Verbindung mit diesem Gerät eingerichtet wird. Wenn Ihr Unternehmen benutzerdefinierte Zertifikate verwendet, können Sie diese möglicherweise auf den Windows Mobile-Geräten installieren, die Sie erwerben. Andernfalls müssen Sie neue Zertifikate erstellen. Auf diesen Punkt wird im Abschnitt über Netzwerksicherheit dieses Artikels noch näher eingegangen.
Abbildung 5 Verwalten digitaler Zertifikate
Abbildung 5 Verwalten digitaler Zertifikate
ActiveSync und Internet Explorer® Mobile können SSL zum Sichern der Datenübertragung zwischen dem Gerät und einem Unternehmenswebserver verwenden. Dies gilt unabhängig davon, ob die Verbindung zum Synchronisieren von Microsoft Exchange-Daten, zum Konfigurieren des Geräts oder zum Herunterladen von Anwendungen besteht. SSL verschlüsselt den Kommunikationskanal mit 128-Bit-RC4- oder 3DES-Verschlüsselung, sodass Daten von Außenstehenden nicht gelesen werden können. Windows Mobile unterstützt außerdem VPN, wobei die Paketverschlüsselung verwendet wird, um Sicherheit ähnlich wie bei einer Standleitung bereitzustellen, wenn über das Internet auf einen Server zugegriffen wird.

Exchange Server-Sicherheit
Obwohl Windows Mobile-Geräte Exchange Server nicht benötigen, um zu funktionieren, wurden die beiden Systeme so entwickelt, dass sie eng zusammenarbeiten und eine stabile mobile End-to-End-Messaging- und Produktivitätslösung bieten. Seit der Veröffentlichung von Windows Mobile 5.0 mit MSFP wurde ActiveSync verbessert, sodass die Verwaltung der Einstellungen von Windows Mobile-Geräten von einem Remotestandort aus möglich ist. Dies ist ein einfaches, aber leistungsstarkes Mittel zum Übertragen und Durchsetzen globaler Sicherheitseinstellungen für die meisten Windows Mobile-Geräte.
ActiveSync wird auf IIS, der Anwendungs-/Webserverkomponente von Microsoft Windows Server 2003 ausgeführt. IIS bietet integrierte Sicherheit, die ActiveSync selbst vor über das Netzwerk eingehenden Angriffen schützt. Da Microsoft Office Outlook® Web Access (OWA) ebenfalls auf IIS basiert ist, können dieselben Sicherheitszertifikate sowohl für ActiveSync als auch für OWA verwendet werden.
Bei Verwendung von ActiveSync zum Übertragen einer Unternehmensrichtlinie wird diese Richtlinie für die Geräte bereitgestellt, wenn sie das nächste Mal mit Exchange Server synchronisiert werden. Benutzer müssen die Änderungen akzeptieren, bevor sie eine Verbindung zum Server herstellen können. Viele Netzwerke haben mit einer Vielzahl von Geräten einschließlich veralteter Hardware zu tun, die technisch ausgereifte Sicherheitsrichtlinien nicht akzeptieren kann. Falls erforderlich, können Sie bestimmte Geräte wie beispielsweise veraltete Hardware von der Sicherheitsrichtlinienanforderung ausnehmen, sodass sie weiterhin eine Verbindung herstellen können.
Exchange Server 2003 SP2 und Exchange Server 2007 verfügen über etwas andere Steuerungsfunktionen in Bezug auf Sicherheitsrichtlinien. Exchange Server 2003 SP2 kann verwendet werden, um eine Mindestkennwortlänge von 4 bis 18 Zeichen anzugeben, wobei sowohl Zahlen als auch Buchstaben in einem Kennwort erforderlich sind, und festzulegen, wie lang der Zeitraum der Inaktivität sein darf, bevor das Gerät gesperrt wird. Bei dieser Version von Exchange Server kann auch festgelegt werden, wie oft Sicherheitseinstellungen an Geräte übertragen werden, wobei die bereits erwähnten Ausnahmen für veraltete Geräte möglich sind.
Mit der Veröffentlichung von Exchange Server 2007 wurden die ActiveSync-Verwaltungsfunktionen für mobile Geräte verbessert, sodass sie nun alle Exchange Server 2003 SP2-Funktionen sowie die folgenden umfassen:
  • Zulassen oder Verbieten einfacher Kennwörter (wie „1234“ oder „1111“)
  • Aktivieren oder Deaktivieren von Anlagendownloads
  • Anforderung von Speicherkartenverschlüsselung
  • Festlegen der maximalen Anlagengröße
  • Ermöglichen der Wiederherstellung eines Gerätekennworts durch den Benutzer über OWA
  • Ermöglichen des Zugriffs auf UNC- (Universal Naming Convention) und WSS-Dateien (Microsoft Windows SharePoint® Services)
Exchange Server 2007 bietet IT-Fachleuten die Flexibilität, Richtlinien für jeden Benutzer oder jedes Gerät zuzuschneiden, Richtlinien für Gruppen von Benutzern zu verwalten sowie bestimmte Benutzer gänzlich von Sicherheitsrichtlinien auszunehmen.

Bereinigung per Remotezugriff
Neben der lokalen Gerätebereinigung, auf die bereits ausführlich eingegangen wurde, können Windows Mobile-Geräte mithilfe von Exchange Server 2003 SP2, Exchange Server 2007 oder OWA von einem Remotestandort aus bereinigt werden. Die Bereinigung von einem Remotestandort aus, die nach der Synchronisierung stattfindet, kann auch dann durchgeführt werden, wenn keine ActiveSync-Sicherheitsrichtlinien verwendet werden. Das Zurücksetzen durch eine Bereinigung von einem Remotestandort aus kann vom Gerät aus nicht abgebrochen werden. Daten, Einstellungen und Sicherheitsschlüssel werden mit wiederholten Nullen überschrieben, sodass es äußerst schwierig wird, Daten, die nicht Teil des Kernbetriebssystems sind, wiederherzustellen.

Netzwerksicherheit
Die Netzwerksicherheit ist für die mobile Sicherheit genauso wichtig wie die Geräte- und Messagingserverkomponenten. Sie ist zudem der Teil der mobilen Infrastruktur, den Sie am meisten steuern können. Selbst wenn ein oder mehrere mobile Geräte gefährdet sind, kann das Konfigurieren Ihres Unternehmensnetzwerks gemäß bewährter Methoden und das Implementieren der richtigen Sicherheitsprotokolle dazu beitragen, Schaden vom Netzwerk abzuwenden.
Windows Mobile ist für verschiedene Netzwerkarten gut geeignet. Mit standardmäßigen Internetsicherheitsprotokollen und Firewalls können Sie eine Lösung erstellen, die Ihren Anforderungen an Leistung, Stabilität und Sicherheit entspricht.
Wenn Messagingserver innerhalb des Unternehmensnetzwerks eingesetzt werden, können sie von einer Edgefirewall geschützt werden, die als Puffer zwischen dem Internet und den Unternehmensservern dient. Microsoft Internet Security and Acceleration (ISA) Server 2004 oder ISA Server 2006 (beide verfügen über Features speziell zu diesem Zweck) prüft die Identität aller eingehenden Pakete, bevor sie an die Exchange-Server weitergeleitet werden, und sendet dann ausgehende Informationen über das Internet zurück an den Client.
Zum Konfigurieren von ISA Server muss die SSL-Verschlüsselung aktiviert und Port 443 als überwachender SSL-Webport für den Exchange Server-Datenverkehr bestimmt werden. So wird das Gefahrenpotenzial des Internets durch die Begrenzung auf einen einzelnen Port minimiert. Außerdem sollten alle Clients vor der Verbindung über ActiveSync eine SSL-Verbindung herstellen müssen.
ISA Server kann Benutzer von Webanwendungen wie OWA im Voraus authentifizieren, sodass nicht authentifizierte Benutzer daran gehindert werden, die Anwendungsserver zu erreichen. Mit ISA Server 2006 wird das SSL-Bridgingmodell von ISA Server 2004 verbessert, indem die Software als SSL-Endpunkt für Windows Mobile-Geräte dient. Dies ermöglicht die Authentifizierung von Windows Mobile-Geräten gegenüber Exchange Server, ohne eine direkte Verbindung herzustellen. Stattdessen leitet ISA Server 2006 den Datenverkehr hin und her. Da sich der empfohlene Standort von ISA Server 2006 im Umkreisnetzwerk befindet, bietet dies eine zusätzliche Sicherheitsschicht zwischen dem öffentlichen Internet und dem Exchange-Front-End-Server.

Authentifizierung
Es stehen zwei grundlegende Arten der Authentifizierung zur Auswahl: Standard- und zertifikatbasierte Authentifizierung. Die Standardauthentifizierung bezieht sich auf eine standardmäßige, mit Namen und Kennwort aktivierte, SSL-basierte Verbindung zwischen einem Windows Mobile-Client und dem Exchange-Front-End-Server. Ein Zertifikat ist nach wie vor erforderlich, da Exchange Server vor der Authentifizierung nach einem passenden Stammzertifikat auf dem Gerät sucht. Windows Mobile und IIS ermöglichen die Verwendung einer der vielen Verschlüsselungsmethoden von SSL.
Die zertifikatbasierte Authentifizierung, die sowohl bei Windows Mobile 5.0 mit MSFP als auch bei Windows Mobile 6 zur Verfügung steht, verwendet TLS (Transport Layer Security) anstelle der SSL-Standardauthentifizierung. Neben dem Stammzertifikat ist bei TLS erforderlich, dass jeder Benutzer über ein Zertifikat mit öffentlichen und privaten Schlüsseln verfügt. Da TLS einen Verschlüsselungsschlüssel (bis zu 2.048 Bit) anstelle eines Kennworts verwendet, bietet dieses Protokoll stärkere Authentifizierung.
Bei Windows Mobile 6 erfordert das Registrieren eines Benutzerzertifikats mithilfe von Desktop Enroll, dass das Gerät bei einem Desktop-PC angedockt wird, der sich in derselben Domäne wie der zur Zertifikatsregistrierung verwendete Server befindet. Der Benutzer authentifiziert die Registrierung mithilfe eines Kennworts, einer Smartcard oder einer anderen Methode und verbindet das Gerät dann mit einem Desktop-PC. Der Benutzer greift nun über den Desktop-PC auf das Zertifikatssystem zu, wobei der Desktop-PC wiederum das Zertifikat auf dem mobilen Gerät installiert. Desktop Enroll steht für eine ganze Reihe von Windows Mobile-Sicherheitszwecken zur Verfügung, darunter Zertifikatserneuerung sowie die Verteilung von ActiveSync-Authentifizierungszertifikaten, SSL/TLS-Authentifizierungszertifikaten, 802.1x Wi-Fi-Zertifikaten oder S/MIME-Zertifikaten für die digitale Signatur.
Sicherheitsprotokolle wie SSL schützen Nachrichtendaten während der Übermittlung, verschlüsseln sie jedoch nicht, wenn sie auf dem Windows Mobile-Gerät oder dem Exchange-Server eingehen. S/MIME ist eine sichere Form des vertrauten MIME-E-Mail-Standards, der digital signierte bzw. verschlüsselte E-Mail unterstützt. Dies bietet eine zusätzliche Schutzschicht neben der SSL-Transportschichtverschlüsselung.

Zusammenfassung
Jede der vielen Schichten, aus denen eine Lösung besteht, muss berücksichtigt werden, um eine ausreichend sichere Infrastruktur zu erstellen. Windows Mobile, Exchange Server und Microsoft-Netzwerksicherheitsprodukte wie ISA Server arbeiten zusammen, um die Probleme beim Verwalten einer mobilen Infrastruktur zu verringern. Damit wird die Arbeit von IT-Abteilungen erleichtert, sodass diese sich nicht hauptsächlich auf die durch mobile Geräte hervorgerufenen Sicherheitsherausforderungen konzentrieren müssen, sondern sich den hierdurch ermöglichten Produktivitätssteigerungen zuwenden können.

Mein besonderer Dank geht an Kathy Esser, Katharine Holdsworth, Sarah Norton und Chip Vollers für ihre Hilfe beim Verfassen dieses Artikels.

Matt Fontaine ist Autor technischer Artikel für BuzzBee Company.


 Kommunikation: Eine leistungsf&#228;hige Alternative zu &#246;ffentlichen Ordnern
Kommunikation Alan Maddison

Eine leistungsfähige Alternative zu öffentlichen Ordnern
Kurz zusammengefasst:
  • Freigeben von Kalendern und Kontakten
  • Kommunikation mit Blogs und Wikis
  • Freigeben und Verwalten von Dokumenten

Öffentliche Ordner gibt es seit der ersten Version von Microsoft Exchange, wobei das ursprüngliche Ziel darin bestand, eine grundlegende Plattform für die Freigabe von Dokumenten, Verteilerlistenarchivierung und benutzerdefinierte Anwendungsentwicklung bereitzustellen. Fast von
Anfang an hatten Administratoren jedoch mit der Verwaltung und der Verwendung eines zunehmend komplexen Teils vieler Exchange-Umgebungen zu kämpfen. Obwohl in Exchange Server 2007 einige bedeutende Verbesserungen bei der Verwaltung öffentlicher Ordner eingeführt wurden, bleiben die Herausforderungen bestehen. Öffentliche Ordner bieten einfach nicht die stabile Plattform für Zusammenarbeit und Dokumentverwaltung, die heutige Unternehmen benötigen.
Microsoft hat bekannt gegeben, dass Exchange Server 2007 möglicherweise die letzte Version des Produkts ist, das öffentliche Ordner unterstützt. Obwohl öffentliche Ordner nach wie vor unterstützt werden und nach der Veröffentlichung von Exchange Server 2007 weitere 10 Jahre Unterstützung zur Verfügung stehen, ist dies ein guter Zeitpunkt, sich nach einer Alternative umzusehen.
Glücklicherweise hat Microsoft mit der Veröffentlichung von Microsoft® Office SharePoint® Server (MOSS) 2007 eine überzeugende Option bereitgestellt. MOSS 2007 bietet die Plattform, die IT-Administratoren und Unternehmen brauchen, um die Funktionen öffentlicher Ordner zu ersetzen und zu erweitern. In diesem Artikel wird erläutert, in welcher Weise MOSS ein stabiles und leistungsfähiges Framework zur Verfügung stellt, das weitaus mehr Funktionen als öffentliche Exchange-Ordner bietet. Speziell geht es um die Verwendung von SharePoint für Aufgaben, für die öffentliche Ordner normalerweise verwendet werden, beispielsweise die Freigabe von Kalendern, Kontakten und Dokumenten.
Beachten Sie, dass Sie öffentliche Ordner weiterhin brauchen, bis Sie zumindest Ihre Clients aktualisieren. Die Microsoft Outlook®-Clients von Outlook 97 bis Outlook 2003 benötigen öffentliche Ordner aus einer Reihe von Gründen, zu denen Offlineadressbücher, die Organisationsformularbibliothek und die Suche nach Frei/Gebucht zählen. Wenn Sie auf Outlook 2007 und Exchange Server 2007 umsteigen, können Sie die Verwendung öffentlicher Ordner jederzeit einstellen.

SharePoint-Kalender
Freigegebene Kalender sind ein typisches Szenario für öffentliche Ordner, und SharePoint macht es sehr einfach, einen Kalender im öffentlichen Ordner durch einen SharePoint-Kalender zu ersetzen. Die Standardinstallation einer SharePoint-Site umfasst zwar einen Kalender, Sie müssen aber wahrscheinlich mehrere Kalender erstellen, um die Anforderungen Ihrer Organisation zu erfüllen. Zur Erläuterung wird hier die Erstellung eines freigegebenen Kalenders für eine Personalabteilung dargestellt. Der erste Schritt besteht in der Auswahl von „Alle Websiteinhalte einblenden“. Dies wird normalerweise in der oberen, linken Ecke der SharePoint-Site angezeigt (siehe Abbildung 1).
Abbildung 1 Erstellen von neuem Siteinhalt
Abbildung 1 Erstellen von neuem Siteinhalt
Nachdem Sie „Alle Websiteinhalte einblenden“ ausgewählt haben, klicken Sie auf die Schaltfläche „Erstellen“ (die ebenfalls in Abbildung 1 dargestellt ist). Nach Laden der Seite „Erstellen“, werden die standardmäßigen Optionen für den Inhaltstyp angezeigt (wie in Abbildung 2 dargestellt). Zum Erstellen eines Kalenders müssen Sie „Kalender“ in der Spalte „Nachverfolgen“ auswählen. Anschließend füllen Sie das Namens- und Beschreibungsfeld aus und entscheiden, ob der Kalender in den Quicklinks-Bereich aufgenommen werden soll.
Abbildung 2 Die Seite „Erstellen“ zeigt viele Standardoptionen an.
Abbildung 2 Die Seite „Erstellen“ zeigt viele Standardoptionen an.
Jetzt ist der Kalender erstellt. Der Benutzer kann entscheiden, ob er sich den freigegebenen Kalender über die SharePoint-Site oder direkt in Outlook anzeigen lassen will. Für letztere Möglichkeit muss der Benutzer mithilfe des Webbrowsers eine Verbindung zum Kalender herstellen und dann das Menü „Aktionen“ öffnen und die Option zum Herstellen einer Verbindung mit Outlook auswählen.
Wenn die Verbindung erstmalig hergestellt wird, zeigt Outlook eine Sicherheitswarnung an. Diese erinnert Benutzer daran, eine Verbindung nur zu bekannten und vertrauenswürdigen Quellen herzustellen. Durch Bestätigen mit „Ja“ wird eine Verbindung zwischen dem Kalender und Outlook hergestellt. Abbildung 3 zeigt die Standardansicht, die den SharePoint-Kalender und den Outlook-Kalender nebeneinander zeigt.
Abbildung 3 Anzeigen des SharePoint- und des Outlook-Kalenders nebeneinander
Abbildung 3 Anzeigen des SharePoint- und des Outlook-Kalenders nebeneinander
Nachdem die Verbindung des Kalenders mit Outlook hergestellt wurde, kann die gegenseitige Synchronisierung stattfinden. Ereignisse, die über Outlook eingegeben wurden, werden mit SharePoint synchronisiert, und alle Benutzer, die sich den Kalender anzeigen lassen, sehen die aktualisierten Einträge. Wenn Sie SMTP-Support in SharePoint aktiviert haben, können Ereignisse auch direkt per E-Mail an den Kalender gesendet werden, und SharePoint fügt diese Einträge hinzu.

SharePoint-Kontakte
Freigegebene Kontakte, für die ebenfalls öffentliche Ordner erforderlich sind, werden von vielen Organisationen verwendet. Auch hier bietet SharePoint eine stabilere Alternative, mit der sich Kontaktlisten leicht erstellen und verwalten lassen. Anhand desselben Beispiels sehen Sie hier, wie eine freigegebene Kontaktliste für die als Beispiel verwendete Personalabteilung erstellt wird.
Zu diesem Zweck wählen Sie ebenfalls „Alle Websiteinhalte einblenden“ aus und klicken auf die Schaltfläche „Erstellen“. Jetzt wählen Sie den Link „Kontakte“ in der Kommunikationsspalte aus. Ein Bildschirm wird angezeigt, in den Sie Informationen für den Namen, die Beschreibung und die Quicklink-Konfiguration eingeben (siehe Abbildung 4). Anschließend klicken Sie einfach auf die Schaltfläche „Erstellen“, und die neue Kontaktliste ist erstellt.
Abbildung 4 Ausfüllen von Namen, Beschreibung und Quicklink-Konfiguration
Abbildung 4 Ausfüllen von Namen, Beschreibung und Quicklink-Konfiguration

Benutzerkommunikation
Sie können SharePoint auch zum Erstellen einer Diskussionsrunde verwenden, die auch als Diskussionsliste bezeichnet wird. Wie bei den Kalendern und Kontakten ist die Erstellung höchst einfach: Wählen Sie „Alle Websiteinhalte einblenden“ aus, klicken Sie auf die Schaltfläche „Erstellen“, und wählen Sie den Link „Diskussionsrunde“ in der Kommunikationsspalte aus. Wie zuvor geben Sie die entsprechenden Informationen für den Namen, die Beschreibung und die Quicklink-Konfiguration ein und klicken dann auf die Schaltfläche „Erstellen“. Abbildung 5 zeigt eine Diskussionsrunde mit einigen Beispielbeiträgen.
Abbildung 5 Beispiel einer Diskussionsrunde mit einigen Beiträgen
Abbildung 5 Beispiel einer Diskussionsrunde mit einigen Beiträgen
Neben Diskussionsrunden unterstützt SharePoint Server jetzt zwei sehr populäre Kommunikationstools: Blogs und Wikis. Blogs und Wikis, die bei öffentlichen Ordnern nicht zur Verfügung stehen, sind neu in SharePoint Server 2007. Diese Tools ergänzen die Features mit interessanten und nützlichen Funktionen für die Zusammenarbeit.
Blogs bieten ein interaktives Forum, in dem Blogger Gedanken und Ideen einfach miteinander austauschen können, indem sie diese an eine Website senden. In der Regel sind solche Beiträge nach Kategorien geordnet, sodass Leser die für sie interessanten Beiträge leichter finden können. Leser können auch Antworten zu den Kommentaren eines Bloggers geben. In einem Unternehmen könnten beispielsweise Mitglieder des Vorstands einen Blog unterhalten. Dies kann ein leistungsfähiges Instrument für die Kommunikation mit den Mitarbeitern sein und bietet die Möglichkeit, Ideen auszutauschen und den Informationsfluss auf allen Ebenen aufrechtzuerhalten.
Das Erstellen eines Blogs in SharePoint ist einfach. Der erste Schritt ist das Auswählen von „Alle Websiteinhalte einblenden“ sowie das Klicken auf die Schaltfläche „Erstellen“ und auf „Websites und Arbeitsbereiche“ in der Webseitenspalte. Sie gelangen nun auf die Seite „Neue SharePoint-Website“, wo Sie Titel, Namen und URL für die Website angeben müssen. Dann wählen Sie eine Vorlage für die Website aus. In diesem Fall ist es die Blogvorlage. Die letzten drei Konfigurationsoptionen dienen für Berechtigungen, Navigation und die Websiteverzeichnisliste. Nach Ausfüllen aller erforderlichen Optionen klicken Sie auf die Schaltfläche „Erstellen“. Dadurch wird eine Unterwebsite innerhalb Ihrer Website auf höchster Ebene erstellt, und innerhalb der Unterwebsite sind Bibliotheken und Listen enthalten, die Blogfunktionen bereitstellen. Abschließend gelangen Sie zum neuen Blog.
Ein Wiki ist ein weiteres hervorragendes Tool für erhöhte Zusammenarbeit bei der Dokumenterstellung. Die Benutzer können Inhalt auf der Website hinzufügen, entfernen und bearbeiten und viele Seiten miteinander verknüpfen. Die einfachste Möglichkeit zum Erstellen eines Wikis ist die Wahl von „Alle Websiteinhalte einblenden“, das Klicken auf den Link „Erstellen“ und die Wahl von „Wiki-Seitenbibliothek“ in der Bibliotheksspalte. Nach Ausfüllen der erforderlichen Namens-, Beschreibungs- und Navigationskonfigurationsfelder klicken Sie zum Abschließen des Vorgangs auf die Schaltfläche „Erstellen“. Weitere Informationen zum Verwenden von Wikis in SharePoint finden Sie im Artikel „Nutzen Sie Wikis bei der Arbeit“ in der Ausgabe des TechNet Magazins vom Januar 2007.

SharePoint-Bibliotheken
Öffentliche Ordner sind praktisch zu Dokumentrepositorys geworden und bieten einen zentralen Speicherort, an dem Benutzer leicht auf Dokumente zugreifen und diese freigeben können. Exchange-Administratoren haben im Lauf der Zeit festgestellt, dass dies eine der hauptsächlichen Verwendungsformen ist, durch die öffentliche Ordner so unhandlich wurden. Dies führt nämlich nicht nur zu einer Zunahme bei Exchange-Ein- und -Ausgaben für die Datenbank der öffentlichen Ordner, sondern wirkt sich auch auf die Replikation innerhalb der Exchange-Infrastruktur aus. SharePoint-Bibliotheken stellen eine ausgezeichnete Alternative dar, da hierdurch der Zugriff auf Exchange und Exchange-Ressourcen verringert wird.
Eine SharePoint-Bibliothek ist ein Speicherort innerhalb einer SharePoint-Site, die das Speichern und Verwalten von Dateien ermöglicht. Es gibt mehrere Arten von Bibliotheken, darunter Bibliotheken für Bilder, Wiki-Seiten, Formulare und Dokumente. Wenn Sie einen Ersatz für öffentliche Ordner in Betracht ziehen, ist die Dokumentbibliothek die richtige Wahl. Eine Dokumentbibliothek unterstützt das Speichern, Verwalten und in einigen Fällen auch das Erstellen von Dokumenten innerhalb der SharePoint-Site.
In einer Dokumentbibliothek können viele verschiedene Dateitypen gespeichert werden, aber bestimmte Dateitypen wie ausführbare Dateien und Skripts sind aus Sicherheitsgründen standardmäßig eingeschränkt. Diese Einschränkungen können jedoch über den Abschnitt „Operations“ (Vorgänge) der Website für die SharePoint-Zentraladministration konfiguriert werden.
Die Standardinstallation von MOSS umfasst eine anpassbare Dokumentbibliothek. Die meisten Organisationen wollen wahrscheinlich mehrere Bibliotheken erstellen, um die verschiedenen Geschäftsbereiche innerhalb der Organisation zu unterstützen. Dies lässt sich mit den Tools von SharePoint leicht bewerkstelligen. Um beispielsweise eine Dokumentbibliothek für die Personalabteilung bereitzustellen, wählen Sie „Alle Websiteinhalte einblenden“aus, klicken Sie auf den Link „Erstellen“, und wählen Sie anschließend „Dokumentbibliothek“ in der Bibliotheksspalte aus. Hier müssen eine Reihe von Einstellungen konfiguriert werden: geben Sie einen Namen und eine Beschreibung für die Bibliothek an, bestimmen Sie, ob die Bibliothek in den Quicklinks-Bereich aufgenommen werden soll, entscheiden Sie, ob die Versionskontrolle aktiviert werden soll, und wählen Sie ein Standardformat für neue Dokumente aus, die direkt in der Bibliothek erstellt werden.
Beachten Sie besonders die Option für den Dokumentversionsverlauf. Diese ist standardmäßig deaktiviert. Die Versionskontrolle kann jedoch nützlich und in vielen Umgebungen angemessen sein. Neben der Speicherung von Verlaufskopien von Dokumenten verfolgt diese Funktion, wann und von wem Änderungen durchgeführt wurden, und bietet die Möglichkeit, frühere Versionen anzuzeigen und wiederherzustellen.
Abbildung 6 zeigt die neu erstellte Dokumentbibliothek mit einigen Dokumenten, die hochgeladen wurden. Wenn Sie die Dokumentbibliotheken erstellt haben, können Sie diese Repositorys mit Microsoft Outlook und Windows® Explorer zur Verfügung stellen. Mithilfe von Outlook können Sie sich den Inhalt einer Dokumentbibliothek offline anzeigen lassen. Benutzer, die keinen Zugriff auf das Netzwerk haben, erhalten so eine schreibgeschützte Kopie. Beim Zugriff mit Windows Explorer wird die Netzwerkumgebung genutzt. Durch Eingeben der URL der Dokumentbibliothek können Sie Benutzern den Zugriff ermöglichen. In größeren Umgebungen könnten Sie die Verwendung von Gruppenrichtlinien in Betracht ziehen, um diese Netzwerkumgebung bereitzustellen.
Abbildung 6 Dokumentbibliothek, die einige hochgeladene Dokumente enthält
Abbildung 6 Dokumentbibliothek, die einige hochgeladene Dokumente enthält

Über die Grundlagen hinaus
SharePoint bietet Features, die deutlich über die Funktionen von öffentlichen Ordnern hinausgehen. Neben den allgemeinen Funktionen öffentlicher Ordner bietet SharePoint Server leistungsfähigere Funktionen, durch die diese allgemeinen Funktionen erweitert werden. Diese verbesserten Möglichkeiten umfassen:
  • Versionsverlauf
  • Genehmigungssteuerung
  • Checkoutverfahren
  • Workflowsteuerung
  • Dokumentaufbewahrungsrichtlinien
  • Überwachung
  • RSS
Diese Features sind für jede Unternehmensplattform zum Verwalten von Inhalten wichtig, und SharePoint bietet ein stabiles Framework, das Administratoren einfach verwenden können. Diese erweiterten Funktionen können für viele SharePoint-Features einschließlich Kalender, Aufgaben, Diskussionsrunden und Dokumentbibliotheken aktiviert werden.
Zum Konfigurieren dieser Funktion wählen Sie das Menü „Einstellungen“ und dann die jeweilige Einstellungsoption aus, z. B. die Option für Dokumentbibliothekseinstellungen, wie in Abbildung 7 dargestellt. Nun wird die Seite mit den Einstellungen angezeigt, auf der alle verfügbaren Konfigurations- und Anpassungsoptionen angezeigt werden. Der Link für die Einstellungen der Versionskontrolle in der Spalte „Allgemeine Einstellungen“ beispielsweise ermöglicht die Konfiguration des Versionsverlaufs.
Abbildung 7 Auswahl der Einstellungsoption zum Konfigurieren erweiterter Funktionen
Abbildung 7 Auswahl der Einstellungsoption zum Konfigurieren erweiterter Funktionen
Wie bereits erwähnt, bietet diese Funktion die Aufzeichnung von Dokumentänderungen mit Angaben dazu, wer die Änderungen wann durchgeführt hat. Außerdem kann der Benutzer sich frühere Versionen anzeigen lassen und diese gegebenenfalls wiederherstellen. Es kann auch festgelegt werden, wie viele Versionen von SharePoint gespeichert werden. Wenn dieses Limit erreicht wird, werden Elemente gelöscht, ohne zum SharePoint-Papierkorb gesendet zu werden.
Im Abschnitt für die Versionskontrolle können Sie auch die gewünschten Anforderungen für Inhaltsgenehmigung und Checkout konfigurieren. Wenn die Inhaltsgenehmigung aktiviert ist, müssen alle eingereichten Elemente genehmigt werden, bevor sie anderen Benutzern zur Verfügung gestellt werden. Elemente, die nicht genehmigt wurden, werden auf den Status „ausstehend“ gesetzt. Das Checkoutverfahren stellt eine Inhaltssteuerung bereit, indem verhindert wird, dass mehrere Benutzer gleichzeitig an einer Datei arbeiten.
Workflows sind ein weiteres nützliches Feature von SharePoint, das bei öffentlichen Ordnern nicht zur Verfügung steht. Workflows bieten einen strukturierten Ansatz für Geschäftsprozesse, der zur Rationalisierung der Vorgänge in Ihrem Unternehmen beitragen kann. In SharePoint implementierte Workflows sind eine Reihe von vordefinierten Aufgaben, durch die das Verschieben eines Dokuments im festgelegten Prozess automatisiert wird. Der Prozess kann iterativ sein, wobei jeder Schritt abgeschlossen sein muss, bevor der nächste Schritt eingeleitet wird, oder er kann parallel verlaufen, wobei die jeweilige Aufgabe jederzeit abgeschlossen werden kann. Die Standardworkflows in SharePoint sind:
  • Genehmigung
  • Rückmeldungen sammeln
  • Signaturen sammeln
  • Dispositionsgenehmigung
Zur Einhaltung von Regelungen und Geschäftsanforderungen werden Informationsverwaltungsrichtlinien verwendet. Eine Richtlinie besteht aus einem Satz an Regeln, die sich auf die Verwaltung und Steuerung von Dokumenten beziehen. SharePoint Server unterstützt benutzerdefinierte Regeln, umfasst jedoch auch praktische Standardregeln wie:
  • Überwachung
  • Ablauf
  • Beschriftungen
  • Barcodes
Die Überwachung bietet die Möglichkeit, Ereignisse auf der Grundlage einer Reihe von Aktionen zu protokollieren, die Sie unter Websiteeinstellungen definieren. Sie können Aktionen wie das Öffnen eines Dokuments, das Herunterladen oder Anzeigen eines Elements oder seiner Eigenschaften, das Bearbeiten eines Dokuments, das Aus- oder Einchecken eines Dokuments, das Verschieben oder Kopieren von Elementen und das Löschen und Wiederherstellen von Elementen nachverfolgen.
Der Inhaltsablauf ermöglicht das Löschen von Inhalt, um die Datenaufbewahrungsrichtlinien Ihrer Organisation einzuhalten. Dieser Datenablauf kann an einem bestimmten Datum oder nach einer festgelegten Zeitspanne nach einem bestimmten Ereignis wie der Dokumenterstellung eintreten.
Beim Drucken wird dem Ausdruck mithilfe von Beschriftungen Text hinzugefügt. In der Praxis gibt es eine Reihe von Einsatzmöglichkeiten für diese Richtlinie. Sie könnten beispielsweise festlegen, dass alle Dokumente aus der freigegebenen Dokumentbibliothek einen Vertraulichkeitshinweis enthalten, damit die Vorschriften der Rechtsabteilung eingehalten werden.
Barcodes bieten eine formelle Überwachungsmethode für gedruckte und Onlinedokumente. SharePoint erstellt für jedes Dokument einen eindeutigen Bezeichner. Die Benutzer haben dann die Möglichkeit, ein Bild des Barcodes in ihr Dokument einzufügen.
Eine weitere deutliche Verbesserung von SharePoint ist die Integration mit RSS-Feeds. Kalender, Kontakte, Dokumentbibliotheken und Diskussionsrunden stellen einen RSS-Feed bereit, den ein Benutzer abonnieren kann. Die Benutzer erhalten auf Wunsch automatische Updates, um den Überblick über ihre täglichen Aufgaben zu behalten. Dazu ist lediglich ein RSS-Reader wie Outlook 2007 erforderlich.

Zusammenfassung
Microsoft Office SharePoint Server 2007 bietet nützliche Features für Unternehmen und stellt eine leistungsfähigere Alternative zu öffentlichen Exchange-Ordnern dar. Ein stabiles Administrationssystem ermöglicht die einfache Implementierung einer Lösung für die Freigabe von Kalendern, Kontakten und Dokumenten. Zudem können Sie verschiedene Kommunikationsmöglichkeiten wie Diskussionsrunden, Blogs und Wikis erstellen.

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


 Kommunikation: Anmeldung bei Outlook Web Access mit Smartcards
Kommunikation Victor Akinnagbe and Ted Dressel and Jason Opdycke

Anmeldung bei Outlook Web Access mit Smartcards
Kurz zusammengefasst:
  • Zweistufige Authentifizierung
  • Eingeschränkte Kerberos-Delegierung
  • ISA Server- und Exchange-Konfiguration

Mobile Mitarbeiter stellen für IT-Unternehmen eine außergewöhnliche Sicherheitsherausforderung dar. Remotebenutzer benötigen sicheren Zugriff auf Daten und Dienste wie z. B. E-Mail. Die bedauerliche Realität ist jedoch, dass zu den
schwächsten Gliedern in der Sicherheitskette unsichere Kennwörter, Malware (z. B. Protokollierung der Tastatureingabe) und Viren auf den Remotecomputern gehören, die auf die internen Ressourcen Ihrer Organisation zugreifen.
Eine Möglichkeit, die Sicherheit in dieser mobilen Umgebung zu erhöhen, besteht in der Beseitigung eines dieser schwächsten Glieder: der Kennwörter (obwohl der Gedanke, den Zugriff auf ein Konto ohne Authentifizierungskennwort zu ermöglichen, beunruhigend erscheinen mag). Ein Hauptverfahren zur Beseitigung der Probleme im Zusammenhang mit Kennwörtern ist die zweistufige Authentifizierung, manchmal auch mehrstufige Authentifizierung genannt. Statt sich für den Zugriff auf eine einzige Methode, also ein Kennwort zu verlassen, setzt die zweistufige Authentifizierung die Verwendung zusätzlicher Authentifizierungsmethoden durch, einschließlich einer Kombination aus Benutzernamen und Kennwort, eines physischen Geräts wie eine Smartcard oder einer biometrischen Kennung wie ein Fingerabdruck.
Für Remotebenutzer müssen Sie in der Regel die Firewall ein wenig öffnen, um den Remotezugriff auf das Unternehmensnetzwerk zu ermöglichen. Eine Standardfirewall bietet grundlegende Risikominderung, indem sie auf Netzwerkebene das interne und das externe Netzwerk voneinander trennt (siehe Abbildung 1). Für zusätzliche Sicherheit werden Ports einfach gesperrt, und wenn Kommunikation mit einem Gerät auf dem internen Netzwerk erforderlich ist, werden die Ports dann zum richtigen Ort weitergeleitet. Diese Verfahren bieten auf Netzwerkebene beträchtlichen Schutz. Inzwischen aber sind mehrere Schichten von Netzwerksicherheit notwendig, da die Angriffe immer raffinierter werden.
Abbildung 1 Standardfirewall mit blockierten oder weitergeleiteten Ports
Abbildung 1 Standardfirewall mit blockierten oder weitergeleiteten Ports
Da die von mobilen Mitarbeitern am häufigsten verwendeten Unternehmensdienste wohl E-Mail und Messaging sind, ist es wichtiger denn je, dass Sie Ihre Exchange-Infrastruktur sicher konfigurieren. Eine Möglichkeit, mobilen Mitarbeitern sichere Dienste bereitzustellen, ist es, Benutzern den Zugriff auf E-Mails über Outlook® Web Access (OWA) zu ermöglichen. Ein weiterer entscheidender Schritt besteht in der Bereitstellung einer sichereren zweistufigen Authentifizierung für OWA über Smartcards. In diesem Artikel werden die Konfigurations- und Setupprobleme näher beleuchtet, über die Sie bei einer Bereitstellung von smartcardaktiviertem OWA informiert sein sollten.

Besser als eine Firewall
Durch Verwendung von Microsoft® Internet Security and Acceleration (ISA) Server 2006 auf Ihrem Netzwerk lässt sich das sichere Öffnen des Netzwerks für Remotebenutzer vereinfachen. ISA Server 2006 umfasst sicherheitserhöhende Features wie smartcardaktivierte virtuelle private Netzwerke (Virtual Private Network, VPN), LDAP (Lightweight Directory Access Protocol)-Authentifizierung via Active Directory® und eingeschränkte Kerberos-Delegierung. ISA Server unterscheidet sich vielleicht etwas von einer üblichen Firewall. Es werden nämlich mehrere Sicherheitsebenen bereitgestellt, da nicht nur auf Netzwerkebene gearbeitet wird (anstelle von Standardfirewallhardware oder in Verbindung mit dieser), sondern auch zusätzliche Sicherheitsfeatures bereitgestellt werden, die in der Regel in herkömmlichen Firewalls nicht unterstützt werden, z. B. Anwendungsfilter. Sie wollen nicht, dass jemand die HTTP POST-Methode zu einer bestimmten gehosteten Website verwendet? Sie möchten RFC-Konformität von SMTP-Nachrichten erzwingen, bevor diese Ihren Exchange-Server erreichen? Sie möchten verschlüsselte SSL (Secure Sockets Layer)-HTTP-Pakete prüfen, bevor sie ins Netzwerk gelangen? ISA Server kann alle diese Aufgaben und vieles mehr bewältigen, um sicherzustellen, dass nur sauberer, gefilterter Datenverkehr zu Ihrer DMZ oder Ihrem internen Netzwerk weitergeleitet wird.
SSL-Sitzungen stellen für Standardfirewalls ein gewisses Problem dar. Wenn Pakete die Firewall passieren, bleiben sie verschlüsselt, was bedeutet, dass SSL ordnungsgemäß funktioniert. Wenn also eine Anwendung wie OWA mithilfe von SSL durch eine Hardware- oder Softwarefirewall veröffentlicht wird, gibt es außer einer statusbehafteten Paketprüfung wirklich keinerlei sinnvolle Prüfung, die von der Standardfirewall durchgeführt werden kann. Bei bloßem Öffnen und Weiterleiten von Ports kann Angreifern eine große Angriffsfläche zugänglich gemacht werden. Da am Rand des Netzwerks keine wirkliche Prüfung erfolgt, könnten ungeprüfte und nicht authentifizierte Pakete in das interne Netzwerk weitergeleitet werden.
ISA Server 2006 kann als SSL-Endpunkt für HTTP-Clients fungieren und sicherstellen, dass nur authentifizierter Datenverkehr den veröffentlichten Exchange-Server erreicht. ISA Server unterstützt ein nützliches Feature namens „SSL-Bridging“. In der Regel wird ein Paket von einem Client verschlüsselt, der über eine Standard-SSL-Sitzung mit ISA Server kommuniziert. Mit SSL-Bridging kann ISA Server die SSL-Verschlüsselung lokal aufheben, das jetzt unverschlüsselte Paket prüfen, den Benutzer ggf. via Active Directory authentifizieren, das Paket mithilfe von SSL wieder verschlüsseln und das verschlüsselte Paket zum entsprechenden Exchange-Server weiterleiten (siehe Abbildung 2). Mithilfe dieses Verfahrens reduziert SSL-Bridging Angriffe, die in einer SSL-Sitzung versteckt sind und die einer nicht anwendungsorientierten Firewall nur wie verschlüsselte Daten-BLOBs erscheinen würden.
Abbildung 2 ISA Server sichtet den Datenverkehr auf Anwendungsebene.
Abbildung 2 ISA Server sichtet den Datenverkehr auf Anwendungsebene.
Vorauthentifizierter Datenverkehr, der den Server erreicht, ist im Zusammenhang mit eingeschränkter Kerberos-Delegierung ein wichtiger Punkt. In einer Standardfirewall werden Ports einfach zum Exchange-Server weitergeleitet, und der Front-End-Server ist selbst für die Durchführung von Authentifizierungsaufgaben gegenüber möglicherweise böswilligen Benutzern verantwortlich. Wenn Authentifizierung erforderlich ist, kann sich ISA Server direkt an Active Directory wenden und die Anmeldeinformationen im Namen des Benutzers anfordern. Wenn der Benutzer erfolgreich authentifiziert ist, leitet ISA Server die Nachricht zum Exchange-Front-End-Server weiter. Der Front-End-Server muss keine zufälligen, unbekannten Benutzeranforderungen mehr authentifizieren und kann ausschließlich zum Senden von Proxyanforderungen zu den Back-End-Servern verwendet werden. ISA Server 2006 kann außerdem eingeschränkte Kerberos-Delegierung verwenden, um zertifikatbasierten Zugriff auf Technologien wie Windows SharePoint Services und Exchange ActiveSync zu ermöglichen.
In Exchange Server 2003 war die Unterstützung für Kerberos-basierte Authentifizierung zwischen Front-End- und Back-End-Servern für Anmeldungen bei OWA enthalten. (Sie verwenden doch sicher IPSec, um den Clientdatenverkehr zu schützen?) Exchange Server unterstützt auch die Kerberos-Authentifizierung gegenüber Postfachclusterservern.

Aktivieren der Smartcardauthentifizierung
Es war eine Herausforderung, smartcardbasierte Authentifizierung für OWA zu implementieren. Es wurde jedoch auf Grundlage des jetzt in ISA Server 2006 verfügbaren Features der eingeschränkten Kerberos-Delegierung eine Lösung entwickelt. Die Lösung ermöglicht es einem Benutzer, Anmeldeinformationen über ein Zertifikat zu übermitteln, um sich erfolgreich bei OWA zu authentifizieren. Eingeschränkte Kerberos-Delegierung bringt eine willkommene Verbesserung gegenüber der Unterstützung von Kerberos-Delegierung in Windows® 2000, die uneingeschränkte Delegierung verwendete. Die eingeschränkte Funktion von Kerberos ist sicherer und begrenzt das potenzielle Risiko durch raffinierte Angriffe mithilfe eines Identitätswechsels.
Im smartcardaktivierten Szenario wendet sich ISA Server 2006 an Active Directory, um den Benutzer zu authentifizieren, da der Benutzer vom externen Netzwerk aus keinen routbaren Zugriff auf ein Schlüsselverteilungscenter (Key Distribution Center, KDC) hat. ISA Server verweist auf die Zuordnung zwischen Zertifikat und Benutzer in Active Directory, um den Benutzer zu authentifizieren, und holt dann auf Grundlage des Benutzerprinzipalnamens (User Principal Name, UPN) die entsprechenden Kerberos-Tickets ein. In diesem Fall stellt ISA Server die Funktionalität der eingeschränkten Kerberos-Delegierung über Filterungsdienste auf Anwendungsebene und Reverseproxydienste an einen Exchange-Front-End-Server bereit. Wenn eine Delegierung ohne Reverseproxy versucht wird, könnte die erhöhte Gefahr von Sicherheitslücken die Integrität des Netzwerks oder der Active Directory-Domäne beeinträchtigen.
Sowohl Exchange Server 2003 als auch Exchange Server 2007 ermöglichen Standard- und integrierte Authentifizierung. Sie müssen jedoch eine Softwareaktualisierung von Exchange Server 2003 bereitstellen, damit die smartcardbasierte Authentifizierung gegenüber OWA funktioniert. (Weitere Informationen finden Sie im Artikel Beschreibung des neuen Features in Exchange Server 2003, das Smartcardauthentifizierung bei Outlook Web Access unterstützt.) Sie müssen eine Domäne im einheitlichen Funktionsmodus von Windows Server® 2003 besitzen, auf allen beteiligten Exchange Server 2003-Servern muss SP2 oder höher installiert sein, und Sie benötigen einen ISA Server 2006-Server, der als Reverseproxy für die OWA-Site fungiert.
Nach der Installation des Softwareupdates und der Konfiguration der ISA- und Exchange-Server können Benutzer eine OWA-Sitzung mithilfe von Smartcards authentifizieren. Abbildung 3 zeigt den Ereignisablauf, der für die Smartcardauthentifizierung erforderlich ist. Ein Benutzer beginnt durch Öffnen der OWA-Site in Internet Explorer® (1). Tatsächlich stellt der Benutzer eine Verbindung zu ISA Server her und wird zur Eingabe eines Zertifikats anstelle eines Benutzernamens und Kennworts aufgefordert, um die OWA-Sitzung zu beginnen. Das entsprechende Zertifikat ist auf der Smartcard gespeichert, für die der Benutzer eine PIN braucht.
Abbildung 3 Authentifizieren von OWA mit einer Smartcard
Abbildung 3 Authentifizieren von OWA mit einer Smartcard
Die Zertifikatsüberprüfung (2) erfolgt je nach Konfiguration von ISA Server und anderer installierter Software über eine Anforderung der Zertifikatssperrliste (Certificate Revocation List, CRL) oder des OCSP (Online Certificate Status-Protokoll). ISA Server sendet an einen Domänencontroller (DC) die Anforderung, die Anmeldeinformationen des Benutzers zu überprüfen. Wenn die Anforderung fehlschlägt, stellt ISA Server dem Benutzer eine Fehlerseite bereit, und es gelangt keine Anforderung zum Exchange-Front-End-Server.
Nach Überprüfung der Anmeldeinformationen wird das Kerberos-Ticket generiert und die Anforderung mithilfe integrierter Authentifizierung zum Exchange-Front-End-Server weitergeleitet (3). Wenn der Exchange-Front-End-Server die Anforderung erhält, überprüft er das Kerberos-Ticket und sucht den Back-End-Postfachserver des Benutzers (4).
Der Front-End-Server fordert ein Kerberos-Ticket für den entsprechenden Back-End-Server über eingeschränkte Kerberos-Delegierung an und übergibt die Postfachanforderung mithilfe integrierter Authentifizierung an den Back-End-Server (5). Die Anforderung wird vom Back-End-Server bearbeitet (6) und die Postfachdaten zum Exchange-Front-End-Server zurückgegeben (7). Die HTML-Daten für die OWA-Seite werden dem ISA-Server (8) übergeben, der sie dann an den Clientcomputer (9) zurückgibt.

Konfigurieren der Exchange-Umgebung
Der bereits erwähnte Knowledge Base-Artikel beschreibt die Softwareaktualisierung für Exchange Server 2003 und enthält Anleitungen für den Prozess, mit dem Sie eingeschränkte Kerberos-Delegierung unter Verwendung von ISA Server 2006 und Exchange Server 2003 aktivieren.
Hauptsächlich wird durch das Softwareupdate die Automatisierung des Prozesses der eingeschränkten Kerberos-Delegierung vom Exchange-Front-End-Server zu den jeweiligen Back-End-Servern aktiviert. Durch das Update wird der Prozess der eingeschränkten Kerberos-Delegierung von ISA Server zum Front-End-Server nicht automatisiert, da ISA Server nicht Teil der Exchange-Organisation ist. Diese Delegierung muss manuell von jeder ISA Server-Instanz aus bei jedem Exchange-Front-End-Server aktiviert werden.
Das Softwareupdate fügt im Exchange-System-Manager (ESM) eine neue Registerkarte hinzu, mit der Sie einen Exchange-Front-End-Server als KCD-FE bestimmen können (siehe Abbildung 4), wodurch wiederum ermöglicht wird, dass dieser Server in der Registerkarte „Delegierung“ der jeweiligen Exchange-Back-End-Server aufgefüllt wird.
Abbildung 4 Aktivieren der eingeschränkten Kerberos-Delegierung
Abbildung 4 Aktivieren der eingeschränkten Kerberos-Delegierung
Mit dieser neuen Benutzeroberfläche können Sie in den Eigenschaften der Administratorgruppe angeben, welche Anmeldeinformationen beim Auffüllen des msDS-AllowedToDelegateTo-Attributs (A2D2) zu verwenden sind, wie in Abbildung 5 gezeigt. Dies ist das Attribut, das für die eingeschränkte Kerberos-Delegierung verantwortlich ist.
Abbildung 5 Einstellung des Kontos, das die Delegierung steuert
Abbildung 5 Einstellung des Kontos, das die Delegierung steuert
Entsprechend dem Prinzip der geringsten Rechte können Sie ein Standardbenutzerkonto verwenden und es befähigen, Benutzer und Computer über ein Gruppenrichtlinienobjekt (Group Policy Object, GPO) zu delegieren. Wenn das Konto mit dieser erweiterten Berechtigung ausgestattet ist, kann es als Dienstkonto verwendet werden, um den Prozess der eingeschränkten Kerberos-Delegierung für die jeweilige Administratorgruppe zu automatisieren.
Vergewissern Sie sich, dass Sie die richtigen Schritte ausführen, damit ein böswilliger Benutzer das Dienstkonto der eingeschränkten Kerberos-Delegierung auf keinen Fall gefährden kann. Selbst wenn das Konto kein Domänenadministrator ist, könnte der Zugriff darauf durch Ausnutzung der Kerberos-Delegierung zu raffinierten Angriffen führen. Da über das Konto die Fähigkeit erlangt wird, neue Kerberos-Zuordnungen einzurichten, muss es mit Vorsicht verwendet werden. Ergreifen Sie die notwendigen Vorsichtsmaßnahmen, um die Sicherheit und Integrität dieses Kontos zu gewährleisten: ein langes, komplexes Kennwort, verstärkte Überwachung, Verfahren zur Kontodeaktivierung und so weiter.
Das Exchange-Softwareupdate führt auch zu einer sehr wichtigen Änderung bei der ESM-Schnittstelle hinsichtlich der integrierten Authentifizierung. Früher wurde in Exchange Server 2003 bei der Festlegung eines Servers als Front-End-Server die Option zum Aktivieren der Integrierten Windows-Authentifizierung für virtuelle HTTP-Verzeichnisse (unter HTTP Virtual Server) abgeblendet dargestellt (siehe Abbildung 6).
Abbildung 6a Das Update aktiviert die integrierte Authentifizierung
Abbildung 6a Das Update aktiviert die integrierte Authentifizierung
Abbildung 6b Das Update aktiviert die integrierte Authentifizierung
Abbildung 6b Das Update aktiviert die integrierte Authentifizierung
Dies war der Fall, weil die integrierte Authentifizierung auf Exchange-Front-End-Servern wegen technischer Probleme nicht unterstützt wurde, z. B. weil diese Proxyserver NTLM-Sitzungen unterbrachen, weil Benutzer, die die Kerberos-Authentifizierung verwendeten, eine Verbindung zu Active Directory brauchten, und weil Internetbenutzer normalerweise nicht zu einer Domäne gehörten. Das im oben genannten Knowledge Base-Artikel beschriebene Update beseitigt diese Einschränkungen. Nach Installieren des Updates können Sie einfach zum virtuellen Verzeichnis wechseln und als Mechanismus zur Überprüfung der Anmeldeinformationen des Benutzers das Feld für die integrierte Windows-Authentifizierung markieren. Wenn dieses Feld markiert ist, legt es für das virtuelle Verzeichnisobjekt in Active Directory ein Attribut namens „msexchAuthenticationFlags“ fest. (Dieses ist über das Adsiedit.msc-Snap-In für Microsoft Management Console sichtbar.)
Benutzer, die E-Mail über OWA überprüfen, kennen möglicherweise den Namen ihrer Exchange-Back-End-Server und können mithilfe integrierter Authentifizierung eine Verbindung zu ihnen herstellen, während sie sich im Unternehmensintranet befinden. Der Unterschied in der Benutzerfreundlichkeit besteht bei integrierter Authentifizierung darin, dass Sie beim Netzwerk angemeldet sind und daher nicht zur Eingabe eines Benutzernamens und Kennworts aufgefordert werden, weil Internet Explorer Sie automatisch bei der Website authentifiziert. Das ist nützlich für Benutzer im Unternehmensnetzwerk, aber externe Benutzer – und OWA-Benutzer sind in der Regel eher extern – sind gewöhnlich nicht bei einer Domäne angemeldet, wenn sie von außerhalb des Netzwerks auf einen Exchange Front-End-Server zugreifen. (Dieser Prozess wird ausführlich im Knowledge Base-Artikel zum Authentifizieren von Browserclients durch IIS erläutert.)
In Exchange Server füllt das Update die Registerkarte „Delegierung“ so auf, dass in Active Directory das A2D2-Attribut anstelle des SPN-Attributs (Service Principal Name, Dienstprinzipalname) verwendet wird. Wenn Sie sich mithilfe von Adsiedit.msc das Exchange-Computerobjekt ansehen, erkennen Sie zwei verschiedene Attribute: Das A2D2-Attribut, das die Liste der eingeschränkten Kerberos-Delegierung ist, und das SPN-Attribut, das als Kerberos-Locator und Spezifikationspunkt für das Konto dient. Es trifft zwar zu, dass beide Attribute zusammenwirken, um die eingeschränkte Kerberos-Delegierung zu ermöglichen, aber Sie dürfen über die grafische Oberfläche nur das A2D2-Attribut verändern.
Windows kann den integrierten HOST-SPN als Alias verwenden, um andere Dienste zu suchen. Es ist also nicht erforderlich, setspn.exe zu verwenden, damit die eingeschränkte Kerberos-Delegierung für die Delegierung von Exchange-Front-End zu -Back-End funktioniert. (Obwohl die explizite Angabe von HTTP/Servername in der SPN-Attributliste mit dieser Lösung funktioniert, verursacht sie für den Administrator ein höheres Fehlerrisiko und ist für das Funktionieren der eingeschränkten Kerberos-Delegierung nicht erforderlich.) Die eingeschränkte Kerberos-Delegierung sucht das A2D2-Attribut in Active Directory. Wenn dieses Attribut nicht (oder mit dem falschen SPN-Wert) aufgefüllt ist, funktioniert die eingeschränkte Kerberos-Delegierung zwischen den jeweiligen Servern nicht. Auf einem Exchange-Cluster jedoch muss das A2D2-Attribut vom Front-End-Server nur auf das Computerkonto des Clusterknotens verweisen, um ordnungsgemäß zu funktionieren.
Wie bereits erwähnt, muss eine Windows Server 2003-Domäne, die die Exchange 2003-Server enthält, sich im einheitlichen Funktionsmodus von Windows Server 2003 befinden. Die eingeschränkte Kerberos-Delegierung kann erst verwendet werden, wenn diese Stufe der Domänenfunktionalität vorhanden ist. Wenn sich Ihre Domäne nach wie vor im gemischten Modus befindet und Sie das bereits erörterte Softwareupdate installieren, scheint es zu funktionieren. Die SPN-Registrierungen schlagen jedoch in Wirklichkeit fehl. Weiterhin ist die eingeschränkte Kerberos-Delegierung eine Domänenfunktion, keine Funktion auf Gesamtstrukturebene. Das bedeutet, dass Exchange Server 2003 ISA Server und die Exchange-Front-End- und -Back-End-Server Mitglieder derselben Domäne sein müssen, obwohl sich Benutzer von verschiedenen Domänen trotzdem bei der eingeschränkten Kerberos-Delegierung authentifizieren können. Eine ISA Server-Instanz, die Mitglied keiner Domäne oder Mitglied einer anderen Domäne ist, funktioniert nicht als Teil dieser Lösung.

Konfigurieren der OWA-Site
IIS Admin darf auf keinen Fall für Änderungen an der Authentifizierung bei OWA verwendet werden. Obwohl OWA unter IIS ausgeführt wird und wie jede andere Website auf Änderungen in der Metabasis reagiert, erhöht Exchange mit dem DS2MB-Prozess (Directory Services to Metabase) ein wenig die Komplexität. Der DS2MB-Prozess repliziert Änderungen von Active Directory zur IIS-Metabasis in einem Einbahnprozess, der etwaige direkt an IIS vorgenommene Änderungen überschreibt. Wenn ein Administrator daher damit beginnt, Änderungen direkt an der IIS-Metabasis vorzunehmen (z. B. das Einstellen der integrierten Authentifizierung), funktioniert die Lösung scheinbar, führt jedoch bei Beginn des nächsten DS2MB-Replikationszyklus zum Abbruch.
Die Option zum Aktivieren der integrierten Windows-Authentifizierung für virtuelle HTTP-Verzeichnisse wurde in ESM zur Verfügung gestellt, weil ESM die Bearbeitungen direkt an Active Directory vornimmt und die Änderungen anschließend zur IIS-Metabasis repliziert werden. Bedenken Sie, dass ein Beenden des Systemaufsichtsdiensts auch den DS2MB-Prozess beendet und dass Sie dadurch die Möglichkeit erhalten, Änderungen an der IIS-Metabasis vorzunehmen, ohne dass diese überschrieben werden. Dies ist jedoch nicht ratsam. Beim nächsten Start der Systemaufsicht fragt diese die Änderungen von Active Directory ab, und die Lösung wird dann automatisch deaktiviert.
Die Registerkarte Delegierung zeigt die Optionen „Nur Kerberos verwenden“ und „Beliebiges Authentifizierungsprotokoll verwenden“. Es erscheint logisch, „Nur Kerberos verwenden“ auszuwählen, da die Lösung, mit der wir uns befassen, die eingeschränkte Kerberos-Delegierung verwendet. Aber hier liegt eine der vielen IT-Situationen vor, in denen gewöhnliche Logik nicht gilt. Sie müssen stattdessen die Option „Beliebiges Authentifizierungsprotokoll verwenden“ auswählen (siehe Abbildung 7), da die Anforderung nicht als Kerberos-Anforderung eingeht, sondern als HTTP-Anforderung mit einem entsprechenden Zertifikat, das einem Active Directory-Konto zugeordnet ist.
Abbildung 7 Richtige Authentifizierungseinstellungen für Smartcards
Abbildung 7 Richtige Authentifizierungseinstellungen für Smartcards
In diesem Fall fordert ISA Server über SSL das PKI-Zertifikat des Benutzers an. Die eingehende Anforderung ist kein Kerberos-Ticket, sodass ein Übergang erforderlich ist, damit die eingeschränkte Kerberos-Delegierung ordnungsgemäß funktioniert. Aus diesem Grund unterbricht die Einstellung „Nur Kerberos verwenden“ die Kommunikationskette bei ISA Server. Beachten Sie jedoch, dass die Option „Nur Kerberos verwenden“ bei der Delegierung vom Exchange-Front-End- zum Back-End-Server funktioniert, da der Front-End-Server nur Kerberos-Tickets von ISA Server erhält.
Die virtuellen Verzeichnisse \Exchange und \Public sind die einzigen Orte, die Ordnerinformationen privater Benutzer und öffentliche Ordnerinformationen enthalten dürfen. Die SSL-Konfiguration in Exchange ist für eingeschränkte Kerberos-Delegierung oder zweistufige Authentifizierung nichts Neues, sondern ein Übertrag von standardmäßiger SSL-Aktivierung von OWA mit standardmäßigen Authentifizierungsanmeldeinformationen. Befolgen Sie die dokumentierten Verfahren zum Aktivieren von SSL auf OWA, denn falsches Erzwingen von SSL kann OWA unterbrechen und außerdem Probleme mit ESM verursachen.

Zusätzliche Konfigurationsdetails
Das Implementieren dieser Lösung wird erheblich erleichtert, wenn ISA Server und Exchange zunächst in der Standardweise bereitgestellt werden. Stürzen Sie sich nicht gleich in die gesamte eingeschränkte Kerberos-Delegierungslösung mit allen konfigurierten Einstellungen, besonders, wenn ISA Server vorher nicht Teil Ihrer Bereitstellung war. Dies kann den Problembehandlungsprozess erschweren, falls eine Komponente oder ein Schritt im Prozess fehlschlagen sollte. Es ist viel leichter, ISA Server und Exchange in der Standardweise bereitzustellen (mit Benutzernamen und Kennwort, aber ohne formularbasierte Authentifizierung), sich zu vergewissern, dass die Installation funktioniert, und dann zu eingeschränkter Kerberos-Delegierung und Zertifikatauthentifizierung überzugehen.
In der Regel kann formularbasierte Authentifizierung nicht mit smartcardaktiviertem OWA verwendet werden. Formularbasierte Authentifizierung zeigt an, dass ein Benutzer einen Benutzernamen und ein Kennwort hat, die über das standardmäßige Outlook-Formular übermittelt werden. Bei smartcardbasierter zweistufiger Authentifizierung hingegen verfügt der Benutzer nur über eine Smartcard und kein Kennwort. Folglich verfügt formularbasierte Authentifizierung über kein Mittel, um lediglich das Authentifizierungszertifikat anzunehmen oder zu übermitteln. Das Verwenden formularbasierter Authentifizierung an einem beliebigen Punkt in der Kette (z. B. auf einem Front-End-Server hinter ISA Server) unterbricht die smartcardaktivierte OWA-Konfiguration. Wenn Sie formularbasierte Authentifizierung aktivieren, wird das virtuelle Exchange-Verzeichnis zwangsweise auf Standardauthentifizierung eingestellt, und folglich wird auch die IIS-Metabasis auf Standardauthentifizierung eingestellt.
Wenn manche Ihrer Benutzer sowohl über Benutzernamen/Kennwörter als auch Smartcards verfügen, können Sie auf dem ISA-Weblistener die Fallbackauthentifizierung aktivieren. Wenn dann ein Benutzer auf die Schaltfläche „ESC“ klickt, nachdem er zur Eingabe zertifikatbasierter Anmeldeinformationen aufgefordert wurde, wird er zur Eingabe der Standardanmeldeinformationen Benutzername/Kennwort aufgefordert, auch wenn hinter ISA Server auf dem Exchange-Server die integrierte Authentifizierung aktiviert ist. Außerdem kann ISA Server die SSL-Sitzung auf ganz ähnliche Weise beenden, wie dies bei formularbasierter Authentifizierung der Fall ist.

Schlussbemerkung
Smartcardunterstützung zur Authentifizierung bei OWA ist eine willkommene Ergänzung sowohl für Exchange Server 2003 als auch für Exchange Server 2007. Dank der Möglichkeit, sich über ein Zertifikat bei OWA anzumelden, brauchen sich Benutzer keine Sorgen mehr darum zu machen, wie sie sich lange und komplexe Kennwörter merken können, und Administratoren haben jetzt ein wirksames Tool gegen Protokollierung der Tastatureingabe und andere Arten von Malware, durch die Benutzeranmeldeinformationen von einem infizierten System aus ausspioniert werden. Weitere Informationen finden Sie in der Randleiste „Ressourcen“.
Die richtige Konfiguration von ISA Server für die zweistufige Authentifizierung mit Smartcards erhöht die Gesamtsicherheit noch stärker, wenn die veröffentlichte OWA-Anwendung einer Filterung auf Anwendungsebene unterzogen wird. Darüber hinaus verfügt ISA Server 2006 über integrierte Unterstützung für das Veröffentlichen von Exchange Server 2003 und Exchange Server 2007 anhand der einfach zu verwendenden Veröffentlichungsassistenten. Daher ist ISA Server nach wie vor eine gute Investition für Unternehmen, die auf Exchange Server 2007 umstellen.
Ressourcen
  • Freigabe von Dateien, die von der Filterfunktion „Safe HTML“ in Outlook Web Access für Exchange Server 2003 entfernt werden
  • Problembehandlung bei Kerberos-Delegierung
  • Metabasis-Aktualisierungsdienst
  • Authentifizierung in ISA Server 2006
  • Kerberos-Protokolltransfer und eingeschränkte Kerberos-Delegierung
  • TechNet-Webcast: Implementieren mehrstufiger Authentifizierung mithilfe von Smartcards

Victor Akinnagbe arbeitet als Premier Field Engineer bei Microsoft im Raum Washington, D.C. Er befasst sich hauptsächlich mit Sicherheit, Infrastruktur und Messaging.
Ted Dressel arbeitet als Berater bei Microsoft im Raum Washington, D.C. Er befasst sich hauptsächlich mit Sicherheit, Infrastruktur und Messaging.
Jason Opdycke arbeitet als Premier Field Engineer bei Microsoft in der Gegend von Charlotte. Seine Hauptgebiete sind Sicherheit und Infrastruktur.


 Windows-Verwaltung: Der ActiveX-Installationsdienst in Windows&#160;Vista
Windows-Verwaltung Rob Campbell and Joel Yoker

Der ActiveX-Installationsdienst in Windows Vista
Kurz zusammengefasst:
  • Häufige Herausforderungen bei ActiveX-Steuerelementen
  • Installation von ActiveX-Steuerelementen
  • Gefährliche Berechtigungen
  • Ein sichererer Prozess in Windows Vista

Es ist immer dasselbe: Um die Sicherheit wesentlich zu erhöhen, müssen Sie ein gewisses Maß an Freiheit oder Flexibilität aufgeben. Wenn Ihre Umgebung den meisten anderen Organisationen gleicht, werden Sie Ihr Desktopbetriebssystem bestimmt so absichern wollen, dass eine sicherere Computerumgebung
für Ihre Endbenutzer bereitgestellt wird. IT-Administratoren gehen bei der Sicherung des Desktops üblicherweise so vor, dass sie eine Kombination aus Sicherheitsrichtlinieneinstellungen, Benutzerberechtigungen, Datei- und Registrierungs-Zugriffssteuerungslisten (Access Control Lists, ACLs) sowie Systemdiensteinschränkungen verwenden.
Eine häufig auftretende Hürde bei der Entwicklung einer sicheren Desktopumgebung ist die Begrenzung der Bedrohungen durch schädliche ActiveX®-Steuerelemente bei gleichzeitiger Bereitstellung einer nach wie vor angemessenen Anwendungskompatibilität in Ihrer Umgebung. Bei Desktopbetriebssystemen war dies jahrelang eine Herausforderung. Glücklicherweise geht der neue Installationsdienst für ActiveX-Steuerelemente (AxIS) in Windows Vista™ die für die Verwaltung von ActiveX-Steuerelementen in Unternehmensumgebungen spezifischen Probleme an. AxIS bietet Standardbenutzern, die normalerweise für die Installation von ActiveX-Steuerelementen nicht berechtigt sind, eine einfache und überschaubare Möglichkeit, diese von genehmigten Websites zu installieren. Gruppenrichtliniensteuerung über AxIS ermöglicht IT-Administratoren zu bestimmen, welche Steuerelemente Benutzer unabhängig von ihren Berechtigungen installieren dürfen.
In diesem Artikel werden die administrativen Herausforderungen im Zusammenhang mit ActiveX-Steuerelementen behandelt, die Art und Weise, wie diese Probleme in früheren Versionen von Windows® behandelt wurden, und wie AxIS in Windows Vista eine einmalige und effiziente Möglichkeit bietet, die Installation von ActiveX-Steuerelementen zu verwalten.

Was ist ein ActiveX-Steuerelement?
Ein ActiveX-Steuerelement ist ein Stück ausführbaren Codes (in der Regel eine OCX-Datei, die in einer CAB-Datei verpackt ist), das installiert und durch den Benutzer über Internet Explorer® aufgerufen wird. Webentwickler erstellen ActiveX-Steuerelemente, um ihren Webanwendungen Funktionen hinzuzufügen, die sie mit Standard-HTML oder einem einfachen Skript nur schwer erzielen können.
Ein Schlüsselfeature von ActiveX-Steuerelementen ist das einfache Bereitstellungskonzept in Form von „Downloaden und ausführen“. ActiveX-Steuerelemente werden über das HTML-Objekttag installiert und aufgerufen, das ein Attribut namens CODEBASE hat. Dieses Attribut gibt Internet Explorer (mithilfe einer URL) an, wo das Steuerelement abzurufen ist, wenn es nicht bereits auf dem Computer des Benutzers installiert ist. In diesem Fall lädt Internet Explorer das entsprechende Installationspaket herunter, führt eine Vertrauensüberprüfung am Objekt durch und fordert den Benutzer zur Eingabe der Installationsgenehmigung über die Internet Explorer-Informationsleiste auf (siehe Abbildung 1). Während der Installation wird das Steuerelement durch die Ausgabeseite registriert und aufgerufen. Nach der Installation können alle Standardbenutzer das Steuerelement aufrufen. Dieser einfache Verteilungs- und Ausführungsmechanismus soll Entwicklern eine leichte Möglichkeit bieten, Komponenten an Benutzer ihrer Webanwendung zu verteilen. Das Problem bei dieser Verteilungsmethode ist, dass Standardbenutzer ActiveX-Steuerelemente nicht direkt installieren können, weil zur Durchführung der Installation Administratorrechte erforderlich sind.
Abbildung 1 Installationsinformationsleiste des ActiveX-Steuerelements
Abbildung 1 Installationsinformationsleiste des ActiveX-Steuerelements
Als ActiveX-Steuerelemente erstmals in Internet Explorer 4.0 eingeführt wurden, schien das Internet noch ein viel freundlicherer Ort zu sein. Heute kann ausführbarer Code, der über das Web verteilt wird, eine erhebliche Bedrohung darstellen. Deshalb dürfen in Windows ausschließlich Benutzer mit lokalen Administratorrechten ActiveX-Steuerelemente installieren, und auch nur dann, wenn die Installation gemäß Richtlinieneinstellungen genehmigt ist. Wenn ein ActiveX-Steuerelement erst einmal von einem Administrator installiert ist, kann es von jedem Benutzer des Systems aufgerufen werden. Dieses Verhalten wird durch einen Satz von Datei- und Registrierungs-ACLs in Windows ermöglicht. Dies hindert Standardbenutzer zwar daran, ActiveX-Steuerelemente zu installieren, verringert aber nicht die Risiken für lokale Administratoren und Standardbenutzer (mit geänderten Standardberechtigungen), die sie installieren.
Der Standardschutz in Windows, nämlich dass nur Personen mit Administratorrechten eine Installation durchführen können, berücksichtigt also ActiveX-Steuerelemente auf der Ebene des einzelnen Benutzers. Die Verwaltung von ActiveX-Steuerelementen innerhalb großer Organisationen wird allerdings nicht behandelt. Eine häufige Herausforderung in Unternehmensumgebungen ist die Frage, wie die Verwendung der von der IT-Organisation als vertrauenswürdig anerkannten ActiveX-Steuerelemente zugelassen werden kann, gleichzeitig aber potenzielle Bedrohungen reduziert werden, die von externen, nicht vertrauenswürdigen Steuerelementen ausgehen. Letztendlich wird die Entscheidung, ob ein bestimmtes ActiveX-Steuerelement installiert wird, sei es gut oder bösartig, oft einem einzelnen Benutzer je nach dessen Rechten überlassen. Um Bedrohungen entgegenzuwirken, sperren manche Organisationen alle ActiveX-Steuerelemente, während andere die Installation durch Endbenutzer zulassen, jedoch versuchen, womöglich installierte Malware abzuwehren.
Eine andere Möglichkeit, die Installation schädlicher Steuerelemente zu verhindern, besteht darin, beim Standardbenutzer eingeschränkte Rechte zu erzwingen und den IT-Administrator alle erforderlichen Steuerelemente auf der Desktopplattform vorinstallieren zu lassen. Dies ist effektiv, wenn die verwendeten ActiveX-Steuerelemente entweder von verhältnismäßig statischer Natur sind, wenn sie gemäß einem geplanten Veröffentlichungsprozess in Verbindung mit Desktopupdates geändert werden, oder wenn die Organisation einen Softwareverteilungsmechanismus wie Systems Management Server verwendet. Allerdings stellen bei diesen Vorgehensweisen die alltägliche Verwaltung, die sich ständig ändernden Anforderungen interner Anwendungsentwickler sowie Abhängigkeiten von externen Steuerelementen weiterhin eine Herausforderung dar.
Wenn Benutzer Administratorrechte haben, sieht das Problem anders aus, da diese Benutzer dann an der Installation nicht genehmigter Steuerelemente gehindert werden müssen. In diesem Fall wird das Recht des Endbenutzers vorausgesetzt, ActiveX-Steuerelemente zu installieren, da er über Administratorrechte verfügt. (Beachten Sie, dass eine Konstellation, in der Endbenutzer als lokale Administratoren fungieren, für die Organisation ein hohes Risiko darstellt und für die meisten Unternehmensumgebungen nicht empfohlen wird.)
Eine Lösung besteht in der Einrichtung eines internen Downloadservers für Internetkomponenten, der die genehmigten Steuerelemente hostet. Diese Lösung erfordert die Änderung der CodeBaseSearchPath-Zeichenfolge in der Registrierung des Clients. Wenn in der angeforderten HTML-Seite ein Objekttag gefunden wird, das das Attribut CODEBASE enthält, werden die Windows-Clients normalerweise zu den Orten geleitet, die in den CodeBaseSearchPath-Daten angegeben sind. Standardmäßig enthält diese Registrierungszeichenfolge das CODEBASE-Schlüsselwort und Internet-URLs für die ActiveX-Steuerelementsammlung. Um einen Downloadserver für Internetkomponenten zu implementieren, müssen Sie die Standarddaten im CodeBaseSearchPath durch die URL des internen Servers ersetzen, auf dem Sie die von Ihrer Organisation genehmigten Steuerelemente hosten. Wie bei der vorherigen Vorgehensweise erfordert diese Lösung fortlaufende Verwaltung, und das Hosten eines internen Servers für ActiveX-Steuerelemente verursacht Kosten und Komplexität.
Es gibt andere Lösungen, z. B. die Modifizierung der URLActions der Internet Explorer-Zone, wobei die von Administratoren genehmigten Steuerelemente über die Gruppenrichtlinien angegeben und die Installation aller Steuerelemente aus dem Umkreisnetzwerk durch Firewallrichtlinien gesperrt werden. Bei allen diesen Ansätzen gibt es offensichtlich gewisse Probleme, und viele werden wegen ihres Mangels an Flexibilität schließlich verworfen. Schlimmer noch ist, dass manche dieser Lösungen nach wie vor Administratorrechte des Benutzers erfordern. Letztendlich versuchen diese Modifizierungen, Teile des Problems zu behandeln, z. B. die Steuerung (oder Sperrung) der Orte, von denen die ActiveX-Steuerelemente stammen, von denen aus sie aufgerufen werden können, und so weiter. Diese Lösungen verringern jedoch nicht das grundlegende Problem, dass Benutzer ohne Administratorrechte keine ActiveX-Steuerelemente installieren können.

Was kann AxIS für Sie tun?
AxIS in Windows Vista ermöglicht dem Unternehmensadministrator, ActiveX-Steuerelemente unter Aufrechterhaltung einer starken Sicherheit zu verwalten, indem Benutzer unter den Standardeinstellungen des Dateisystems als Standardbenutzer angesehen werden. AxIS stellt Gruppenrichtlinienoptionen bereit, um vertrauenswürdige Quellen von ActiveX-Steuerelementen zu konfigurieren, sowie einen Brokerprozess, um Steuerelemente aus diesen vertrauenswürdigen Quellen im Namen von Standardbenutzern zu installieren. Der wichtigste Vorteil ist, dass Sie auf Benutzerarbeitsstationen eine nicht administrative Sicherheitsfunktion unter der zentralen Kontrolle durch den Administrator unterhalten können. Bei Verwendung von AxIS identifiziert der IT-Administrator vertrauenswürdige Quellen für ActiveX-Steuerelemente (in der Regel Internet- oder Intranet-URLs). Wenn ein Objekttag Internet Explorer anweist, ein Steuerelement aufzurufen, führt AxIS die folgenden Schritte aus:
  1. Überprüfung, ob das Steuerelement installiert ist. Ist dies nicht der Fall, muss es vor Verwendung installiert werden.
  2. Prüfung anhand der AxIS-Richtlinieneinstellung, ob das Steuerelement aus einer vertrauenswürdigen Quelle stammt. Die spezifische Überprüfung vergleicht den im Attribut CODEBASE des Objekttags angegebenen Hostnamen der URL mit der in den Richtlinien angegebenen Liste vertrauenswürdiger Orte.
  3. Herunterladen und Installieren des Steuerelements im Namen des Benutzers.
Wenn der Hostname der Quell-URL nicht in der AxIS-Richtlinieneinstellung aufgelistet ist, wird die normale Eingabeaufforderung der Benutzerkontensteuerung (User Account Control, UAC) aufgerufen, die für die Durchführung der Installation Administratorrechte erfordert. Darüber hinaus hält AxIS im Anwendungsereignisprotokoll von der Quelle AxInstallService ein Ereignis mit der Kennung 4097 fest. Darin wird die versuchte Installation eines ActiveX-Steuerelements unter Angabe des spezifischen Downloadpfads zum Steuerelement beschrieben. Ein Beispiel für das Ereignis 4097 wird in Abbildung 2 dargestellt. Der Unternehmensadministrator kann mithilfe der Daten aus diesem Ereignisprotokolleintrag die Gruppenrichtlinien dahingehend ändern, dass das Steuerelement durch AxIS bei nachfolgenden Besuchen der Website installiert werden kann.
Abbildung 2 Das AxInstallService-Ereignis 4097
Abbildung 2 Das AxInstallService-Ereignis 4097
AxIS ist eine optionale Komponente, die in den SKUs Business, Enterprise und Ultimate von Windows Vista enthalten ist. Sie kann durch eine unbeaufsichtigte Option oder über das Dialogfeld Systemsteuerung (Programme | Programme und Funktionen | Windows-Funktionen ein- oder ausschalten), wie in Abbildung 3 gezeigt, aktiviert werden. Nach der Aktivierung durchläuft AxIS die oben skizzierten Schritte, wann immer von Internet Explorer ein Steuerelement angefordert wird.
Abbildung 3 Aktivieren von AxIS in der Systemsteuerung
Abbildung 3 Aktivieren von AxIS in der Systemsteuerung
Die Tatsache, dass sich in Windows Vista Aufgaben an Ereignisse anfügen lassen, bietet einem Administrator eine einfache Möglichkeit, vom AxIS-Dienst eine Benachrichtigung zu erhalten, z. B. wenn die Installation eines ActiveX-Steuerelements gesperrt ist. Es kann allerdings nicht immer davon ausgegangen werden, dass das ActiveX-Steuerelement von demselben URL-Hostnamen installiert wird, auf den der Endbenutzer von seiner Website aus zugreift. Aus diesem Grund können sich die vom AxInstallService-Ereignis 4097 bereitgestellten Informationen (versuchte Installation) als äußerst nützlich erweisen, um den Host, von dem aus die Installation des Steuerelements versucht wird, zu identifizieren.
Mit den Informationen aus dem Ereignis können Sie den vertrauenswürdigen Ort in den Gruppenrichtlinien konfigurieren. AxIS-Einstellungen für lokale oder Gruppenrichtlinien finden Sie in den Computerkonfigurationseinstellungen (siehe Abbildung 4). Die Richtlinieneinstellung für genehmigte Installationssites für ActiveX-Steuerelemente ermöglicht Ihnen, Host-URLs vertrauenswürdiger Orte anzugeben (siehe Abbildung 5). Für die Einstellung genehmigter Sites sind zwei Informationen erforderlich: von wo aus das ActiveX-Steuerelement installiert werden darf, sowie das Verhalten bei der Installation.
Abbildung 4 Einstellungen im Gruppenrichtlinienobjekt-Editor
Abbildung 4 Einstellungen im Gruppenrichtlinienobjekt-Editor
Abbildung 5 Von AxIS genehmigte Installationssites
Abbildung 5 Von AxIS genehmigte Installationssites
Wie oben erwähnt, ist zunächst eine Host-URL erforderlich, um den vertrauenswürdigen Ort des Steuerelements anzugeben. Im Unterschied zu früheren Lösungen, bei denen die CLSID des Steuerelements bekannt sein musste (die sich oft ändert, wenn Steuerelemente von Entwicklern überarbeitet werden), ermöglicht AxIS die Installation eines beliebigen Steuerelements vom vertrauenswürdigen Ort aus, was die administrative Gesamtbelastung verringert. Die zweite Information ist eine durch Komma getrennte Zeichenfolge von vier Werten, von denen jeder das Downloadverhalten des ActiveX-Steuerelements bestimmt. Die Werte geben vier Eigenschaften an: TPSSignedControl, SignedControl, UnsignedControl und ServerCertificatePolicy. Die ersten zwei Eigenschaften (TPSSignedControl und SignedControl) können einen der folgenden drei Werte annehmen: 0, 1 oder 2. Diese Werte ähneln denjenigen in URLAction-Einstellungen. Der Wert 0 verhindert die Installation des Steuerelements, beim Wert 1 wird der Benutzer aufgefordert, die Installation zu genehmigen, und beim Wert 2 wird das Steuerelement automatisch im Namen des Benutzers installiert. Nicht signierte Steuerelemente können nicht automatisch installiert werden. Daher kann UnsignedControl nur den Wert 0 oder 1 annehmen. Beachten Sie, dass die Standardwerte 2, 1 und 0 verwendet werden, wenn keine Richtlinie angegeben ist.
Die letzte Eigenschaft gibt das Installationsverhalten auf Grundlage der Zertifikatseinstellungen der signierten Einstellungssteuerung an. Wie die meisten SSL-Sites müssen Zertifikate einen Satz von Sicherheitstests durchlaufen, um zu gewährleisten, dass das Zertifikat gültig ist. In der Praxis treten ungültige Zertifikateigenschaften bei der Implementierung signierter ActiveX-Steuerelemente zuweilen auf. AxIS ermöglicht Administratoren aufgrund seiner Konfiguration, ungültige Informationen zu reduzieren, die manchmal von Zertifikaten auf einer URL-für-URL-Basis anzeigt werden. Die letzte Eigenschaft stellt sich als eine Bitmaskenkombination der in Abbildung 6 gezeigten Werte dar.
Figure 6 ServerCertificatePolicy (Close Figure 6)

Wert | Definition
0x00001000 | Ignorieren eines ungültigen kanonischen Namens (canonical name, CN) im Zertifikat.
0x00000100 | Ignorieren unbekannter Zertifizierungsstellen.
0x00002000 | Ignorieren eines ungültigen Zertifikatsdatums.
0x00000200 | Ignorieren einer falschen Zertifikatsverwendung.
Die Standardeinstellung ist 0, was bedeutet, dass alle Sicherheitsüberprüfungen zu durchlaufen sind, bevor AxIS die Installation durchführt. Die Kombinationen aus Hosteinstellung und diesen vier Werten sind in der Richtlinieneinstellung angegeben, wie in Abbildung 7 gezeigt.
Abbildung 7 Genehmigte AxIS-Host-URLs
Abbildung 7 Genehmigte AxIS-Host-URLs

Schlussbemerkung
Mit AxIS können Sie die Gruppenrichtlinie so konfigurieren, dass sie steuert, welche ActiveX-Steuerelemente von Benutzern ohne Administratorrechte oder komplexe Konfigurationen installiert werden können. Eine Steuerung auf dieser Ebene war in früheren Versionen von Windows oft eine Herausforderung, und früher verfügbare Lösungen brachten oft erhebliche Einschränkungen oder vermehrten Verwaltungsaufwand mit sich. Mit AxIS erhalten Organisationen ein weiteres Tool für einen Ansatz mit geringsten Rechten im Hinblick auf Endbenutzerrechte für Desktopsysteme, was die Implementierung eines Standardbenutzermodells ermöglicht, bei dem Endbenutzer keine Administratorrechte benötigen. Dank Windows Vista liegt die Kontrolle wieder beim IT-Administrator, da er und nicht der Endbenutzer auswählt, welche ActiveX-Steuerelemente in der durch die Organisation festgelegten Unternehmensumgebung vertrauenswürdig sind.

Rob Campbell ist Senior Technical Specialist im Microsoft Federation Team. Rob Campbell befasst sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.
Joel Yoker ist Senior Consultant im Microsoft Federation Team. Joel Yoker befasst sich hauptsächlich mit der Entwicklung und Bereitstellung von Sicherheitslösungen für die Bundesregierung der USA.


 Mitteilung der Redaktion: Bekannte sechsten Grades
Mitteilung der Redaktion
Bekannte sechsten Grades
Joshua Trupin

Überkommt Sie ab und zu ein Gefühl der Einsamkeit? Sitzen Sie manchmal allein in Ihrem Büro, in Gedanken versunken, und fragen sich, ob es da draußen wohl intelligente Lebewesen gibt? Oder ob da draußen überhaupt jemand ist? Vielleicht nicht – besonders wenn Ihr Posteingang ständig fast überläuft, so wie es bei mir der Fall ist.
Trotzdem habe ich vor Kurzem den Beschluss gefasst, dass ich endlich etwas tun muss, um meinen Bekanntenkreis zu erweitern. Ich habe mich also bei einer dieser Social Networking-Sites angemeldet und angefangen, Leute hinzuzufügen – alle, mit denen ich jemals gearbeitet habe, von denen ich jemals einen Artikel erworben habe und die ich auf einer Konferenz getroffen habe. Innerhalb einer Woche hatte ich 58 Kontakte in meiner Liste. Klasse!
Aber das war erst der Anfang. Anschließend kamen Bekannte von Bekannten dazu, und im Nu hatte ich über 3.500 Bekannte zweiten Grades. Die 3.500 Kontakte hatten natürlich auch alle ihre eigenen Kontakte, und so war ich schnell bei 277.000 Kontakten dritten Grades angelangt. Eine fixe Kalkulation auf einem Blatt Papier brachte folgendes Ergebnis: wenn jede Person im Durchschnitt 50 Kontakte hat, dann habe ich über 34 Milliarden Bekannte sechsten Grades. Unglaublich! Ich kenne also mehr Menschen, als es auf dem Planeten Erde gibt. Dann überkam es mich plötzlich:
Ich stehe vor einem neuen Problem. Wie in aller Welt soll ich nur so viele Bekanntschaften pflegen? Ich bin offen für Vorschläge. Haben Sie sich je bei einer Social oder Business Networking-Site angemeldet? Wie trennen Sie die Spreu vom Weizen? Sprich, wie wählen Sie aus, mit wem Sie sprechen wollen und mit wem nicht? Teilen Sie uns im TechNet Magazin-Blog Ihre Meinung zu diesem topaktuellen Thema mit.
Wenn dieses ganze Web 2.0-Networking nicht Ihr Ding ist, keine Angst! In dieser Ausgabe des TechNet Magazins zeigen wir Ihnen, wie Sie Exchange Server besser nutzen und somit besser kommunizieren können. In fünf Artikeln geht es darum, wie Ihre Organisation noch mehr Menschen erreichen kann.
Smartcard-Authentifizierung mit Outlook Web Access ist das Thema in einem unserer Featureartikel dieses Monats. Es ist immer empfehlenswert, eine Authentifizierung anzufordern, bevor Sie Zugang zu den Ressourcen Ihres Unternehmens gewähren, und mit Smartcards ist das von überall aus möglich. Weitere Themen sind die Notfallwiederherstellung mit Exchange Server, das Ersetzen öffentlicher Ordner mit SharePoint in Exchange Server 2007 und die Verbesserung der Sicherheit von Mobilgeräten mit Windows Mobile 6. Natürlich gibt es auch wieder Fragen und Antworten zu Exchange, die Rubrik, in der es rund um das Thema Messaging geht. Oje, es sind gerade noch drei Leute in meinem Netzwerk aufgetaucht. Mal gucken, wer es ist, und ob ich mich melden oder lieber so tun soll, als ob ich gerade nicht da bin ...
Joshua Trupin

Unser Dank gilt folgenden technischen Experten von Microsoft: Kristian Andaker, Chris Corio, Jim Harrison, Chad Jones, Michael Lee, Shawn McGrath, Michael Murgolo, Eric Perlin, Michelle Rutzer, Gavriella Schuster und Jim Truher.


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

Überwachen von Remoteverbindungen
RecordTS
www.tsfactory.com
Wollten Sie schon immer einen Blick hinter die Kulissen Ihrer Terminalserver- oder Remotedesktopsitzungen werfen? Vielleicht möchten Sie wissen, was genau passiert ist, bevor Ihre Remotedesktopsitzung Ihre Website abstürzen ließ. Möglicherweise gibt es auf Ihrem Terminalserver ein Problem, das nicht repliziert werden kann. Eventuell machen Sie sich Gedanken über die Sicherheit geistigen Eigentums. Vielleicht müssen Sie ein Protokoll oder eine Präsentation über die Konfiguration Ihres SharePoint®-Servers in einer Testumgebung erstellen. Wenn Ihnen diese Szenarios bekannt vorkommen, sollten Sie RecordTS von TSFactory ausprobieren. (TSFactory wurde von Cláudio Rodrigues, Microsoft MVP für Terminal Services gegründet).
RecordTS steht in zwei Editionen zur Verfügung: Terminalserver und Remotedesktop. Die für Sie geeignete Edition hängt von der Art der zu überwachenden Verbindungen ab. Laut Produktwebsite fungiert RecordTS als „Überwachungskamera“ für Terminalserver- oder Remotedesktopsitzungen. Die Software bildet im Grunde einen Proxy zwischen Terminal Services und der Endbenutzersitzung, wodurch jede Aktion während einer Sitzung aufgezeichnet wird.
Bei der intuitiven Installation wird ein einfacher Assistent verwendet, mit dem die Anwendung auf das Datenverzeichnis gelenkt wird, in dem die Sitzungen gespeichert werden sollen. Die Anwendung installiert ein MMC-Snap-In (mit dem der Dienst konfiguriert werden kann), den RecordTS-Dienst und ein Dienstprogramm zur Sitzungswiedergabe aufgezeichneter Sitzungen. Nach dem Öffnen des MMC-Snap-Ins wird durch Klicken mit der rechten Maustaste auf den Dienstordner ein Eigenschaftenbildschirm angezeigt, in dem Einstellungen konfiguriert werden können, z. B. der Port, auf dem der Dienst ausgeführt werden soll. (Diese Einstellung ist hilfreich, wenn Sie die Terminaldienstsitzungen auf einen nicht standardisierten Port verschoben haben.) Auf der Registerkarte „Storage“ (Speicher) können Sie den Standardspeicherordner auf einen lokalen Ordner oder einen UNC-Pfad festlegen.
Außerdem können Sie die Verzeichnisstruktur der gespeicherten Sitzungen konfigurieren. Zum Beispiel können Sie Domäne, Benutzer sowie Datum und Zeit zum Organisieren der gespeicherten Daten verwenden. Die vielleicht wichtigste Einstellung beim Speichern von Sitzungen auf einer lokalen Festplatte ist die Anweisung an den Dienst, welche Aktion im Fall eines vollen Datenträgers erfolgen soll. Sie können entweder keine weiteren Verbindungen zulassen und aktuelle Sitzungen beenden (die richtige Wahl für äußerst Sicherheitsbewusste) oder die Sitzungsaufzeichnung ausschalten (die richtige Wahl, wenn die Produktivität nicht beeinträchtigt werden soll).
Auf der Registerkarte „Security“ (Sicherheit) können Sie festlegen, ob alle aufgezeichneten Sitzungen digital signiert werden sollen, indem Sie ein vorhandenes Zertifikat auswählen oder ein selbst signiertes Zertifikat erstellen. Dies empfiehlt sich, wenn das Tool für Überwachungs- oder Haftungszwecke verwendet werden soll. Auf der Registerkarte „Users“ (Benutzer) können Sie festlegen, welche Benutzersitzungen aufgezeichnet werden sollen und welche nicht.
Insgesamt ist RecordTS ein wertvolles Tool für Sicherheit und Überwachung, das noch weitere Einsatzmöglichkeiten bietet. So können Sie z. B. eine Anleitung als Präsentation aufzeichnen. Für mich ist es eine praktische Ergänzung meiner Toolbox.

Preis: RecordTS Remote Desktop Edition – ab 495 €. RecordTS Terminal Services Edition – ab 995 €.

Hostüberwachung
Advanced Host Monitor
www.ks-soft.net
Wenn Sie betrieblichen Support für eine wichtige Infrastruktur bereitstellen müssen, gibt es nur einen Faktor, der Sie ruhig schlafen lässt: eine solide, zuverlässige Hostüberwachung. Selbst wenn Sie über unerschütterliche Hardware und stabile, zuverlässige Anwendungen ohne Fehlerquellen verfügen, benötigen Sie trotzdem eine umfassende Hostüberwachung, die anzeigt, wenn das redundante System eingreifen muss.
Der Advanced Host Monitor von KS-Soft verfügt über 58 unterschiedliche Testmethoden und 30 Warnmethoden. Sie können Elemente wie Prozessinformationen, Benutzersitzungen, durchschnittliche Auslastung, Speicher und so weiter prüfen. Die Anwendung bietet Windows®-spezifische Tests, Linux-/UNIX-Tests und plattformunabhängige Prüfungen. Im Gegensatz zu Windows-Tests erfordern Linux-/UNIX-Tests die Installation eines Remoteüberwachungsagent auf dem Client.
Außerdem gibt es einen Überwachungstest für die Windows-Verwaltungsinstrumentation (WMI). Mit dem eingebetteten WMI-Explorer können Sie nach einer bestimmten Abfrage suchen. Navigieren Sie einfach zum entsprechenden Objekt, wählen Sie es aus, und führen Sie die Abfrage aus, um die benötigten Daten zu erhalten.
Der Advanced Host Monitor verfügt außerdem über eine Reihe von Datenbanktests wie einen ODBC-Abfragetest, der die Verfügbarkeit einer ODBC-Datenquelle überprüft, eine Abfrage ausführt und das Ergebnis mit einem bekannten Wert vergleicht. Sie können außerdem prüfen, ob der Host in der Lage ist, eingehende Sitzungen für SQL Server™-, MySQL-, Oracle-, Postgres-, Sybase- und Interbase-Datenbankserver anzunehmen.
Weiterhin stehen eine Reihe von Tests für Festplatten und Dateien zur Verfügung, mit denen freier Speicherplatz, Quoten, Ordner- oder Dateiverfügbarkeit sowie Verfügbarkeit von UNC-Freigaben überprüft werden kann. Darüber hinaus erhalten Sie die standardmäßigen Netzwerktests: allgemeine TCP-/UDP-Überprüfungen, E-Mail-Tests (für SMTP, POP3 und IMAP), Überprüfungen der E-Mail-Weiterleitung, Tests von HTTP-Inhalten und Systemzeiten und so weiter. Eine weitere nützliche Option ist die Überwachung von Testabhängigkeiten um Prüfungen der Reihe nach vorzunehmen. Die Tests können in regelmäßigen Abständen oder unregelmäßig geplant werden, wodurch sich Testmuster fein abstimmen lassen.
Zu den Warnmethoden gehören das Senden von Nachrichten per SMS, ICQ, E-Mail, über ein Ereignisprotokoll oder ein Popupfenster. Durch die Warnungen können auch andere Ereignisse ausgelöst werden, z. B. das Starten oder Anhalten von Diensten, Neustarten des Computers oder Ausführen eines externen Programms.
Die Professional und die Enterprise Edition von Advanced Host Monitor umfasst die IP-Tools von KS-Soft, einen Satz von 19 TCP/IP-Netzwerkdienstprogrammen, der Port-/Protokollscanner und eine SNMP-Trapüberwachung enthält, mit der Sie SNMP-Trapnachrichten empfangen und verarbeiten können. Außerdem verfügen beide Versionen über eine Protokollanalyse- und Berichterstattungskomponente, mit der Sie Verlaufsüberwachungsdaten für Betriebszeitberichte und Leistungsanalysen hochrechnen können.
Die Benutzeroberfläche bietet eine gute Möglichkeit, gleichzeitig einen kurzen Überblick über eine Reihe von Tests zu erhalten. So können Sie Probleme auf den überwachten Hosts schnell ermitteln.
Preis: 599 $ für die Enterprise Edition. 275 $ für die Professional Edition.

Datenträgerbereinigung
WinDirStat
www.windirstat.info
Ähnlich wie Wohnungen oder Häuser neigen Dateispeicherorte dazu, sich nach einer gewissen Zeit mit inzwischen unnötigem Material zu füllen, das wertvollen Platz einnimmt. Ein Frühjahrsputz kann hier Wunder wirken, aber anders als bei Ihnen zu Hause erhalten Sie von einer Verzeichnisbaumstruktur keine sichtbaren Hinweise, wo Sie am besten mit dem Aufräumen beginnen. Glücklicherweise gibt es ein großartiges Visualisierungstool, mit dem Sie ermitteln können, von welchen Dateien Speicherplatz belegt wird.
Mit dem GPL-Programm WinDirStat, einem Windows-basierten Tool, das von Linux KDE kdirstat inspiriert wurde, werden Dateien auf ausgewählten Laufwerken als ein Satz farbiger Quadrate angezeigt. Die Größe der Quadrate entspricht der Größe der Dateien, wodurch unnötige, alte ISO- oder ZIP-Dateien leicht erkannt werden können.
Nachdem Sie Ihr lokales Laufwerk (oder einen Satz lokaler Laufwerke) ausgewählt haben, wird die Verzeichnisstruktur vom Programm gescannt und ein speicherinternes Schema der Dateien erstellt. Dann wird die Visualisierung im unteren Fensterbereich der grafischen Benutzeroberfläche angezeigt. Durch Klicken auf ein farbiges Quadrat im unteren Fensterbereich wird der dem Windows Explorer ähnliche obere Fensterbereich zum Speicherort der Datei geleitet. Mithilfe des oberen Fensterbereichs erhalten Sie nützliche Statistiken wie Dateigröße, Datum der letzten Änderung und andere Attribute. Zusätzlich wird angezeigt, welcher Prozentsatz der Unterstruktur von dieser Datei eingenommen wird.
Hilfreicherweise erhalten verschiedene Dateitypen unterschiedliche Farben, und durch Klicken auf einen Dateityp oben rechts werden alle Dateien dieses Typs im unteren Fensterbereich hervorgehoben. Das ist beispielsweise praktisch, wenn Sie alle ausgeblendeten MP3s Ihrer Benutzer auf dem Dateiserver identifizieren müssen. Außerdem ist ersichtlich, welcher Prozentsatz an Bytes diese Dateien auf der Partition einnehmen.
Preis: Kostenloser Download.

Buchbesprechung
Enemy at the Water Cooler
syngress.oreilly.com
Beinahe jedes Unternehmen muss heutzutage über eine Internetverbindung verfügen. Die meisten sind sich der Gefahren bewusst, die durch die nahezu konstanten Angriffe auf die Verbindungspunkte entstehen, die das „Äußere“ von „Inneren“ der IT-Infrastruktur trennen. Doch viele Unternehmen übersehen eine potenziell größere Bedrohung innerhalb der Organisation. Die Macht dieser so genannten Insiderbedrohungen wird in „Enemy at the Water Cooler“ anschaulich dargestellt. Wirklichkeitsnahe Geschichten über Insiderbedrohungen und Gegenmaßnahmen der Sicherheitsverantwortlichen im Unternehmen von Brian Contos (Syngress, 2006).
Contos beschreibt Angriffe aus dem wirklichen Leben und deren Auswirkung auf die betroffenen Unternehmen. Laut Contos ist Sicherheit ein fortwährender Prozess, der aus einer Verschmelzung von Menschen, Prozessen und Technologien besteht. In diesem Buch zeigt er die potenzielle Wirkung von Sicherheitsverwaltungssoftware im Unternehmen (Enterprise Security Management, ESM) zur Verringerung von Insiderbedrohungen auf.
Als Hauptsicherheitsbeauftragter bei ArcSight stellt Contos hauptsächlich die unternehmenseigene ESM-Software vor, was den Gesamtwert des Buchs jedoch nicht beeinträchtigt. Es fehlt an technischen Details, doch Sie erhalten durch den Einblick in Fehler anderer Organisationen Anregungen für Verbesserungsmöglichkeiten des Sicherheitsprozesses in Ihrem eigenen Unternehmen. Außerdem wird vermittelt, wie eine effektiv umgesetzte ESM-Lösung die Gefahr eines Insiderangriffs verringern kann.
Im Kapitel „Cyber Crime and Cyber Criminals 101“ bietet Contos als Hintergrundinformationen einen Überblick über unterschiedliche Angreifertypen und ihre Motivationen. Außerdem erhalten Sie eine kurze Zusammenfassung ihrer Techniken, z. B. Pufferüberläufe, Codepakete und Warhol-Bedrohungen.
Im nächsten Kapitel werden die Spezifika von Insiderbedrohungen näher beleuchtet, einschließlich der Möglichkeiten zur Schädigung eines Unternehmens durch einen Insider, dem Konzept der Risikoverwaltung sowie der Verringerung von Bedrohungen aus einer technischen Perspektive. Im Thema zur technischen Perspektive wird ein kurzer Überblick über geringste Rechte, leistungsfähige Authentifizierung, Zugriffssteuerung sowie Vorfallserkennung und -verwaltung bereitgestellt. Dies bietet eine Überleitung zu ESM-Softwarelösungen. Wie bereits erwähnt neigt der Autor dazu, sich ausschließlich mit dem Produkt von ArcSight zu beschäftigen, doch der Funktionsabriss lässt sich auf jedes System übertragen.
Das Buch bietet eine Vielzahl von Fallbeispielen aus unterschiedlichen Branchen und Umgebungen. Es wird aufgezeigt, wie unterschiedliche Arten von Insiderbedrohungen erkannt und die Gefahren möglicherweise verringert wurden. Diese Fallstudien spiegeln vielleicht einige Ihrer eigenen Geschäftsmethoden wider und bieten u. U. Lösungen zur Risikoreduzierung bei Insiderangriffen in Ihrer Umgebung.
Preis: $49.95.

Kontaktaufnahme mit Toolbox
Wenn Sie ein Lieblingswerkzeug oder -dienstprogramm haben, das Ihrer Meinung nach hier vorgestellt werden sollte, dann schreiben Sie eine E-Mail (in englischer Sprache) an den Autor unter tntools@microsoft.com.

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


 SQL&#160;– Fragen und Antworten: Clustering, mysteri&#246;se Abst&#252;rze, das SA-Konto und mehr
SQL – Fragen und Antworten
Clustering, mysteriöse Abstürze, das SA-Konto und mehr
Herausgegeben von Nancy Michell

F: Ich möchte mehr darüber erfahren, wie Clustering funktioniert. Unsere Umgebung besteht aus der 64-Bit-Edition von Windows Server® 2003, auf der SQL Server™ 2005 ausgeführt wird, sowie aus einer SSRS-Webfarm (SQL Server Reporting Services) (eine Skalierungsbereitstellung des Berichtsservers), einem SSRS TempDB-Katalogserver und SQL Server, der Daten aus einer Drittanbieterdatenbank über einen verknüpften Server weiterleitet und die Daten für SSRS speichert.
Es soll ein 3-Knoten-Cluster (aktiv/aktiv/passiv) implementiert werden. Knoten 1 ist soll aktiv sein und die Daten speichern, die aus der Drittanbieterdatenbank weitergeleitet werden. Knoten 2 soll aktiv sein und den SSRS-Katalog speichern. Knoten 3 soll passiv sein und als Failover für Knoten 1 oder 2 dienen. Können Sie weiterhelfen?

A: Leider werden viele Benutzer von den Begriffen „aktiv/aktiv“ und „aktiv/passiv“ in Bezug auf das SQL Server-Clustering irregeführt. Sie sind der Meinung, dass SQL-Clustering das „Ausskalieren“ einer Datenbank oder SQL-Instanz über mehrere Server unterstützen kann. Dies ist nicht der Fall. Bei SQL Server gibt es keine aktiv/aktiv-Datenbank oder Instanz. Eine „Instanz“ ist eine Installation von SQL Server mit entsprechenden Datenbanken. Das Clustering pro SQL Server-Instanz ist immer aktiv (1) nach passiv (n) (der Wert n liegt abhängig von Ihrer SQL Server-Version zwischen 1 und 7). Deswegen heißt es Failoverclustering.
Wenn dies klar ist, kann die Installation mehrerer Instanzen von Failoverclustering auf mehreren Knoten in Betracht gezogen werden. Drei physische Server beispielsweise, die alle freigegebene Datenträger verwenden, könnten eine standardmäßig aktive Instanz auf Knoten 1 und eine zweite standardmäßig aktive Instanz auf Knoten 2 haben, und bei beiden kann ein Failover zu Knoten 3 stattfinden. Die Instanzen sind völlig getrennt. Sie geben keine Daten frei und sind nicht aktiv/aktiv. Beide sind aktiv/passiv und haben dieselbe Failoverinstanz. Wenn bei beiden Knoten ein Failover zu Knoten 3 stattfindet, besteht die Herausforderung darin, abzuschätzen, ob diese Last mit der Zeit zu viel für Knoten 3 sein wird. Vom Entwurf her soll beim Failover eine gleichwertige Verarbeitungsleistung zur Verfügung stehen. Wenn bei Spitzenbeanspruchung zwei Knoten für die Verarbeitung im Normalbetrieb erforderlich sind, ist es unwahrscheinlich, dass Knoten 3 die Spitzenbeanspruchung überstehen würde, die normalerweise zwei Knoten zugewiesen ist.
Aufgrund der relativen Kosten der zum Ausführen eines Clusters fähigen Hardware ist es natürlich verständlich, dass die Wahrscheinlichkeit des gleichzeitigen Versagens beider Hauptknoten und Übertragen der Gesamtlast auf einen Knoten von einem Unternehmen abgewogen wird. Daher treffen Unternehmen oft die Entscheidung, das Risiko einzugehen, statt 100 Prozent Failoverkapazität zu gewährleisten.
Glücklicherweise gibt es ein paar guten Nachrichten: SQL Server 2005 bietet viele weitere Optionen für hohe Verfügbarkeit (High Availability, HA) einschließlich Alternativen, bei denen ein Failover schneller stattfindet als bei einem Cluster und sogar Duplikate von Daten möglich sind (beim Clustering wird ein einzelnes SAN eingesetzt). Die Optionen umfassen Spiegelung, Peer-to-Peer-Replikation und mehr. Mit diesen neuen Alternativen stehen erheblich mehr Optionen zur Verfügung, um unterschiedliche Anforderungen zu erfüllen, so auch einige, bei denen eine Reihe von HA-Features kombiniert werden.
Der Microsoft® Cluster Configuration Validation Wizard (ClusPrep), der jetzt als Download zur Verfügung steht, ersetzt die HCL-Tests (Hardware Certification List, Hardwarezertifizierungsliste), die bisweilen Monate zum Überprüfen einer Konfiguration brauchten, um sie für das Clustering als „supportfähig“ einzustufen. Dies stellt dem Datenbankadministrator ein Tool zur Hardwareüberprüfung zur Verfügung, sodass der Kosten- und Zeitaufwand bei der Installation zertifizierter Hardware weiter reduziert wird. Hierdurch wird u. U. sogar die Überprüfung und Bereitstellung heterogener Hardware innerhalb eines Clusterknotensatzes ermöglicht.

F: Ein Löschverfahren auf einem meiner Computer scheint nach 12 Stunden nicht mehr zu reagieren. Es ist nicht blockiert. Im langsamsten Abfrageplan wird ein Auslöser angezeigt, der für 87.327 Sekunden ausgeführt wird. Daher nehme ich an, dass das Verfahren in diesem Auslöser zum Stillstand kommt. Wie kann ich genau feststellen, welche Anweisung nicht reagiert?

A: Es ist durchaus möglich, dass eine Schleife innerhalb des Auslösers aus verschiedenen Gründen nicht beendet wird. Wenn längere Zeit keine Reaktion erfolgt und Sie sehen wollen, welche Anweisung ausgeführt wird, führen Sie den Code in Abbildung 1 aus. Sie erfahren, welche Anweisung derzeit ausgeführt wird. Dies dürfte die Anweisung sein, die dazu führt, dass Ihr Computer nicht reagiert.
Figure 1 Suche nach der derzeit ausgeführten Anweisung (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

F: Ich muss die Transaktionsreplikation über eine Firewall unterstützen. Der Herausgeber und der Verteiler befinden sich außerhalb und der Abonnent innerhalb der Firewall. Der Abonnent ist zum Abhören von Port 1433 eingestellt. Die Computernamen lauten wie folgt: Herausgeber: PUBMACHINE, Verteiler: DISTMACHINE, Abonnent: SUBMACHINE. Welche Ports muss ich öffnen, damit der ursprüngliche Snapshot und der Veröffentlichungspush erfolgreich sind?

A: Wenn Sie ein Pushabonnement verwenden, sollte das Öffnen des SQL Server-Ports (in Ihrem Fall 1433) ausreichen, da der Verteilungsagent auf dem Verteilercomputer (außerhalb der Firewall) ausgeführt wird und wahrscheinlich lokalen Zugriff auf die Snapshotdateien hat, die vom Snapshotagent generiert werden. Wenn Sie dagegen ein Pullabonnement verwenden, muss der Verteilungsagent, der auf dem Abonnentencomputer ausgeführt wird, irgendwie über die Firewall auf die Snapshotdateien zugreifen. Sie können folgende Optionen in Betracht ziehen.
Angenommen die Snapshotdateien sind bereits von einer Dateifreigabe außerhalb der Firewall zugänglich. In diesem Fall können Sie die Windows®-Dateifreigabeports über die Firewall öffnen, sodass der innerhalb der Firewall ausgeführte Verteilungsagent auf die Snapshotdateien zugreifen kann, die sich außerhalb befinden. (Sie sollten jedoch die Sicherheitsimplikationen bedenken, die dies für andere Teile Ihrer Infrastruktur haben könnte.) Beachten Sie, dass Sie bei Konfiguration eines lokalen Pfads als Standard-Snapshotspeicherort (SSMS-Standard) möglicherweise die Option „/AltSnapshotFolder“ des Verteilungsagents verwenden müssen, um den PICKUP-Pfad für die Snapshotdatei zu überschreiben.
Sie können außerdem die Replikation konfigurieren, um FTP für das Übertragen von Snapshotdateien zu verwenden. (Dafür müssten Sie Port 21 öffnen.)

F: Ich möchte wissen, ob es Nachteile gibt, wenn das SA-Konto in SQL Server 2005 deaktiviert wird, und ob die SA-Deaktivierung die Sicherheit wirklich erhöht. Gibt es ein Whitepaper zu dieser Frage?

A: Bei einer neuen SQL Server 2005-Installation ist das SA-Konto bei nicht aktiviertem gemischtem Modus standardmäßig deaktiviert. Für dieses Konto wird ein zufälliges Kennwort generiert. Sie können es auch selbst deaktivieren. Es gibt zu diesem Thema kein Whitepaper, aber das Deaktivieren und Umbenennen von Anmeldungen wird in einem Artikel zu Best Practices erörtert.
Wenn Sie das SA-Konto vor Zerstörungsversuchen schützen wollen, können Sie es auch umbenennen. Doch denken Sie daran, dass Sie ein neues Kennwort festlegen sollten, wenn Sie ein deaktiviertes Konto aktivieren.
Zu Ihrer Frage, ob dies wahre Sicherheit bietet: Bedenken Sie, dass die zusätzliche Sicherheit durch Deaktivieren des Kontos darauf zurückzuführen ist, dass das Erraten eines Kennworts nutzlos ist, solange das Konto deaktiviert ist. Egal, wie viel Zeit ein Hacker oder Virus hat, wird ein Brute-Force-Angriff auf ein gesperrtes Konto nicht gelingen. Das Umbenennen oder Deaktivieren des SA-Kontos zerstört Anwendungen, die für ihre Konnektivität von der Verwendung des SA-Kontos abhängig sind. Die Suche nach diesen Anwendungen und ihre anschließende Reparatur oder Eliminierung sollte sowieso eine Priorität sein. Wie bereits erwähnt, kann das Konto erst für eine Verbindung zur Datenbank verwendet werden, wenn es wieder aktiviert wird. Da zudem der Authentifizierungsprozess früher fehlschlägt, wirkt sich ein fehlgeschlagener Versuch weniger auf das angegriffene System aus.

F: In einer meiner größeren OLTP-Datenbanken befindet sich eine Protokolldatei, die doppelt so groß wie die Datendatei ist. Ich habe bereits die folgenden Befehle ausprobiert, um die Protokolldatei auf eine vernünftige Größe zu reduzieren, aber ich muss sie noch weiter verkleinern:
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

A: Sie sollten die Sicherungsdatenbank in eine Sicherungsprotokollanweisung umändern. Als Alternative könnten Sie die Datenbank in den einfachen Wiederherstellungsmodus setzen und die shrinkfile-Anweisung ausgeben. Nach Verkleinern des Protokolls setzen Sie die Datenbank auf ihr vorheriges Wiederherstellungsmodell zurück. Sichern Sie anschließend die Datenbank. Wenn die Datei immer noch nicht kleiner wird, prüfen Sie (mithilfe von dbcc opentran), ob offene Transaktionen vorhanden sind. Der folgende Knowledge Base-Artikel enthält weitere Informationen: support.microsoft.com/kb/907511.

F: Wenn während eines geplanten SQL Server-Agent-Auftrags ein Failover stattfindet, was geschieht dann mit diesem Auftrag nach dem Failover? Muss er manuell neu gestartet werden?

A: Ja, er muss manuell gestartet werden, wenn kein anderer Prozess vorhanden ist. Wenn Sie Aufträge nicht manuell neu starten möchten, könnten Sie ein Skript schreiben, das eine Tabelle nach Auftragsabschluss aktualisiert. Wenn der Wert gleich 1 ist, wurde der Auftrag ausgeführt. Andere Werte zeigen an, dass der Auftrag nicht abgeschlossen wurde, und ein zweiter Auftrag wird später gestartet, um den Startbefehl auszugeben. Obwohl der Auftrag erneut ausgeführt werden muss, wenn ein Failover während des Vorgangs erfolgt, können Sie mit einem Skript zumindest sicherstellen, dass wichtige Aufträge über Nacht vor dem nächsten Arbeitstag abgeschlossen werden können.
Tipp: Aktualisieren und DBCC UPDATEUSAGE
Aktualisieren Sie von SQL Server 2000 auf SQL Server 2005?
In diesem Fall sollten Sie unbedingt DBCC UPDATEUSAGE direkt nach Aktualisieren der Datenbanken ausführen.
DBCC UPDATEUSAGE meldet und korrigiert Ungenauigkeiten bei der Seiten- und Zeilenanzahl in den Katalogansichten. Diese Ungenauigkeiten müssen korrigiert werden, da sie dazu führen könnten, dass von dem im System gespeicherten sp_spaceused-Verfahren falsche Berichte zur Speicherplatznutzung zurückgegeben werden. In SQL Server 2005 werden diese Werte immer richtig verwaltet, sodass es bei diesen Datenbanken nie zu einer falschen Anzahl kommen sollte. Doch auf SQL Server 2005 aktualisierte Datenbanken können eine ungültige Anzahl enthalten, sodass Sie DBCC UPDATEUSAGE nach der Aktualisierung ausführen sollten.
So funktioniert DBCC UPDATEUSAGE: Es korrigiert die Anzahl der Zeilen, verwendeten Seiten, reservierten Seiten, Blattseiten und Datenseiten für jede Partition in einer Tabelle oder einem Index. Wenn in den Systemtabellen keine Ungenauigkeiten enthalten sind, gibt DBCC UPDATEUSAGE keine Daten zurück. Wenn Ungenauigkeiten gefunden und korrigiert werden und Sie WITH NO_INFOMSGS nicht verwendet haben, gibt DBCC UPDATEUSAGE die Zeilen und Spalten zurück, die in den Systemtabellen aktualisiert werden.
DBCC UPDATEUSAGE kann auch zum Synchronisieren von Speicherplatznutzungsindikatoren verwendet werden. Da das Ausführen von DBCC UPDATEUSAGE bei großen Tabellen oder Datenbanken einige Zeit dauern kann, sollte dieses Tool normalerweise nur verwendet werden, wenn Sie meinen, dass falsche Werte von sp_spaceused zurückgegeben werden. Beachten Sie, dass sp_spaceused einen optionalen Parameter zum Ausführen von DBCC UPDATEUSAGE akzeptiert, bevor Informationen zur Speicherplatznutzung für die Tabelle oder den Index zurückgegeben werden.
DBCC CHECKDB wurde in SQL Server 2005 verbessert, sodass jetzt auch erkannt wird, wenn eine Seiten- oder Zeilenanzahl negativ wird. Wenn negative Zahlen entdeckt werden, gibt DBCC CHECKDB eine Warnung und die Empfehlung aus, DBCC UPDATEUSAGE zum Beheben des Problems auszuführen. Obwohl es den Anschein haben könnte, dass die Aktualisierung der Datenbank auf SQL Server 2005 dieses Problem verursacht hat, kann davon ausgegangen werden, dass die ungültigen Anzahlen bereits vor dem Upgradeverfahren vorhanden waren.
Als Beispiel sehen Sie hier, wie eine Seiten- oder Zeilenanzahl oder beides für alle Objekte in der aktuellen Datenbank aktualisiert wird. Der folgende Befehl gibt 0 für den Datenbanknamen an, und DBCC UPDATEUSAGE meldet aktualisierte Informationen für die aktuelle Datenbank:
DBCC UPDATEUSAGE (0);
GO
Um beispielsweise eine Seiten- oder Zeilenanzahl oder beides für AdventureWorks zu aktualisieren und gleichzeitig Informationsmeldungen zu unterdrücken, führen Sie einen Befehl ähnlich wie den folgenden aus, der AdventureWorks als Datenbanknamen angibt und dann alle Informationsmeldungen unterdrückt:
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
Weitere Informationen finden Sie in der SQL Server-Onlinedokumentation unter DBCC UpdateUsage.

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 Schwerpunkt Dienstprogramme: SMSMap
Schwerpunkt Dienstprogramme
SMSMap
Jeff Tondt
Laden Sie den Code für diesen Artikel herunter: UtilitySpotlight2007_07.exe (2477KB)

Ein Bild sagt mehr als tausend Worte. Dieses bekannte Sprichwort bringt den Gedanken zum Ausdruck, dass über ein einziges Bild komplexe Geschichten erzählt werden können oder dass ein Bild einflussreicher sein kann, als selbst der längste Text. Es beschreibt auch treffend die Ziele der Visualisierung, bei der große Datenmengen schnell aufgenommen werden müssen.
Als Experte für Systemverwaltungsserver (System Management Server, SMS) kann ich besser verstehen, wie die Infrastruktur aufgebaut ist, wenn ich die gesamte SMS-Hierarchie in einem Bild vor mir sehe. Ein solches Bild könnte auch verwendet werden, um der Unternehmensleitung einen Vorher-Nachher-Vergleich einer SMS-Migration darzulegen. Bei der Fehlerbehebung könnte eine solche Abbildung möglicherweise bei der Lösungssuche oder zumindest für die Hilfestellung durch andere nützlich sein. Als verantwortlicher SMS-Administrator müssen Sie die Systemhierarchie natürlich auch aus verschiedenen anderen Gründen dokumentieren.

So machen Sie sich ein Bild
Natürlich ist es möglich, ein solches Diagramm selbst zu zeichnen. Sie können die Ärmel aufkrempeln, die SMS-Hierarchie manuell zeichnen und die Standorteinstellungen von Hand dokumentieren. Wenn Ihre SMS-Server vom Microsoft® Operations Manager (MOM) überwacht werden, kann dieser die Hierarchie zeichnen, allerdings ist MOM für die Darstellung von Bildern nicht ideal, und die Standorteinstellungen werden gar nicht dokumentiert. Es gibt sicher andere Methoden und praktische Tools, aber ich habe bisher noch nichts gefunden, womit gute Bilder angemessen erstellt und die Standorteinstellungen zu meiner Zufriedenheit dokumentiert werden.
Ich habe mich daher entschieden, mein eigenes Tool zu schreiben. So entstand SMSMap 1.0. SMSMap ist eine Visual Basic® .NET-Anwendung, die SMS-verwaltete Bibliotheken im SMS SDK verwendet und Microsoft Visio® über COM automatisiert. Das Dienstprogramm fragt einen Ziel-SMS-Standortserver ab, erstellt ein visuell ansprechendes Visio-Diagramm und exportiert Standorteinstellungen in eine XML-Datei. Ich habe mich für XML entschieden, da es die kompatibelste Möglichkeit ist, die Standorteinstellungen zu dokumentieren. Außerdem wollte ich die SMS-Rollen zeigen und nicht nur die physischen Server, die sich auf andere SMS-Server beziehen. Dadurch kann über Visio-Layer am Diagramm herumgebastelt werden, um von unterschiedlichen Standpunkten auf die SMS-Hierarchie zu sehen.
Abbildung 1 Strahlenförmiges Format
Abbildung 1 Strahlenförmiges Format
Derzeit können Sie mit dem Programm sechs verschiedene Formate für das Visio-Diagramm auswählen. Zum Beispiel zeigt Abbildung 1 eine sehr einfache SMS-Hierarchie mithilfe des strahlenförmigen Formats, während in Abbildung 2 dieselbe Hierarchie als Flussdiagramm dargestellt ist. Das Dienstprogramm funktioniert auch mit viel größeren Hierarchien sehr gut, doch für diese Zwecke sollte es einfach bleiben.
Abbildung 2 Flussdiagramm
Abbildung 2 Flussdiagramm
In Zukunft wird SMSMap wahrscheinlich alle Standorteinstellungen dokumentieren können. Derzeit werden nur die SMS-Standortrollen und alle Begrenzungen dokumentiert. Mit geringem Aufwand könnten viele weitere Standorteinstellungen in die XML-Datei exportiert werden.

Verwenden von SMSMap
Der Quellcode und die Installationsdateien für SMSMap sind auf der TechNet Magazin-Website verfügbar. Führen Sie zum Installieren SMSMapSetup.msi aus, und Sie werden durch die Installation geführt. Beachten Sie, dass SMSMap Visio verwendet. Daher muss dieses Tool ebenfalls installiert sein. Führen Sie nach der Installation C:\Programme\Microsoft\smsmap\smsmap.exe aus (es sei denn, SMSMap wurde nicht im Standardordner installiert).
SMSMap kann auf einem beliebigen Computer ausgeführt werden, es muss sich dabei nicht um den Standortserver handeln. Außerdem ist es unwahrscheinlich, dass Visio auf SMS-Standortservern installiert ist. Geben Sie den Namen des SMS-Standortservers ein, von dem die Abfrage ausgehen soll. Das kann der zentrale Standort sein, wenn Sie die gesamte Hierarchie abfragen wollen, oder ein untergeordneter primärer Standortserver. In diesem Fall erhalten Sie jedoch lediglich die Hierarchie vom untergeordneten primären Standort abwärts. Geben Sie anschließend das Konto mit Berechtigung zum Abfragen des SMS im Format Domäne\Benutzername gefolgt vom Kennwort für das Konto ein. (Das Kennwort wird nicht angezeigt. Sie können diesen Vorgang also in Anwesenheit anderer ausführen.)
Über sechs Optionsfelder kann das Layout ausgewählt werden. Außerdem können Sie festlegen, ob SMS-Rollen in der Zeichnung aufgeführt werden sollen. Diese Kontrollkästchen befinden sich unter der Registerkarte „Options“ (Optionen). Durch Klicken auf die Schaltfläche „Draw“ (Zeichnen) wird das Dienstprogramm gestartet. Zunächst wird geprüft, ob Visio verfügbar ist, dann wird der primäre SMS-Standortserver abgefragt, und die Objekte werden zum Visio-Diagramm hinzugefügt. Eventuell sieht das Visio-Diagramm zunächst unschön aus, wenn SMSMap Objekte ablegt, doch am Ende werden alle Objekte durch das Dienstprogramm im zu Beginn festgelegten Format organisiert.
Ein tieferer Einblick
Oben wurde aufgezeigt, warum und wie Sie Ihre SMS-Hierarchie mithilfe von SMSMap dokumentieren. Im Folgenden wird die Arbeitsweise des Dienstprogramms für Entwickler näher beleuchtet.
SMSMap verwendet die verwalteten SMS-Standortserverschnittstellen, um Informationen zu sammeln, und die primären Interopassemblys für Visio, um ein Visio-Diagramm zu generieren, in dem alle erforderlichen Formen enthalten sind. SMS 2003 SDK Version 3.1 enthält die neueste Version der verwalteten SMS-Standortserverschnittstellen. Mit diesem Satz verwalteter Schnittstellen können Sie einen SMS-Standortserver über eine beliebige Microsoft .NET Framework-fähige Sprache oder Anwendung konfigurieren.
Diese Schnittstellen verwenden den System.Management-Namespace zum Interagieren mit einem SMS-Anbieter über die Windows® Verwaltungsinstrumentation (Windows Management Instrumentation, WMI). Die Anwendung muss mit einer .Net-kompatiblen Sprache (z. B. C#, Visual Basic .NET und so weiter) entwickelt werden, um die Schnittstellen zu verwenden, und auf die Microsoft.SystemsManagementServer.Automation.dll verweisen, die die .NET-Assembly mit dem SMS SDK bereitgestellt hat.
Durch die .NET-Verwaltungsklassen werden viele Eigenheiten des WMI-Objektmodells bereinigt und ein gleichmäßiges, objektorientiertes Modell angezeigt. Die grundlegenden Aufgaben der WMI-Verbindung wie Objektenumeration, Methodenausführung, Objektlöschung, Objektabruf und Ereignisaufzeichnung können über die .NET-Verwaltungsklassen erzielt werden.

Primäre Interopassemblys für Visio
Eine primäre Interopassembly ermöglicht Ihnen das Verwenden von verwaltetem Code zur programmatischen Steuerung von COM-Anwendungen wie Visio. Mit den primären Interopassemblys für Visio können Sie Visio-Funktionalität in verwaltete Anwendungen integrieren und anschließend erweitern.
Wenn .NET Framework bereits auf Ihrem Computer installiert ist und Sie danach Visio installieren, fügt das Installationsprogramm die primären Interopassemblys für Visio auf Ihrem Computer zum globalen Assemblycache (Global Assembly Cache, GAC) hinzu. Sie können von den verwalteten Anwendungen einen Verweis auf die primären Interopassemblys für Visio hinzufügen.
Nach dem Hinzufügen des Verweises zum Projekt ist das Arbeiten mit Visio-Objekten von der verwalteten Anwendung aus möglich. Visio verfügt über ein umfangreiches Objektmodell, das einen Satz Klassen, Schnittstellen und Enumerationen zum programmgesteuerten Erstellen von Diagrammen bietet.

Programmablauf
Nach der Beschreibung der wesentlichen Komponentenschnittstellen für Visio und SMS soll nun der Ablauf des Dienstprogramms beschrieben werden.
Der erste Schritt bei der Verwendung der verwalteten Schnittstellen besteht in der Herstellung einer Verbindung zum SMS-Anbieter. Dies kann durch Erstellen einer neuen Instanz der SMS-Anbieterklasse erreicht werden. Intern sucht diese Klasse nach dem SMS-Anbieter für den angegebenen Standortserver und stellt eine Verbindung mit einem bestimmten Satz Anmeldeinformationen her. Wenn sich der Anbieter auf dem lokalen Computer befindet, werden die momentan protokollierten Anmeldeinformationen anstatt der bei der Verbindung zum Anbieter bereitgestellten Anmeldeinformationen verwendet. Obwohl SMSMap auf dem SMS-Server ausgeführt werden kann, empfehle ich das Ausführen auf einer separaten Arbeitsstation, auf der Visio installiert ist. Aus offensichtlichen Gründen ist Visio auf den meisten SMS-Standortservern nicht installiert.
Wenn Sie über die SMS-Anbieterklasse auf Daten auf dem SMS-Standort zugreifen, werden Sicherheitsrechte so gehandhabt, als würden Sie die SMS-Administratorkonsole verwenden. Das bedeutet beispielsweise, dass beim Versuch, die Einstellungen für einen Standortserver über einen SMS-Anbieter zu konfigurieren, das Konto für die Herstellung der Verbindung zum Anbieter über dieselben Rechte verfügen muss wie bei der Verwendung der Administratorkonsole.
Die SMS-Anbieterklasse bietet eine GetSiteSettings-Methode, mit der die Standorteinstellungen für den aktuellen Standort (zum dem der Anbieter gehört) oder einen anderen Standort mit einem speziellen Standortcode abgerufen werden können. Der Codeausschnitt in Abbildung 3 zeigt, wie sich SMSMap mit dem Anbieter des Zielstandortservers verbindet. Die Benutzeranmeldeinformationen müssen im Format Domäne\Benutzer weitergegeben werden. Sie können auch „.“ angeben, um den aktuellen Computer festzulegen. Abbildung 3 umfasst außerdem Code, mit dem die Ergebnisse in der Benutzeroberfläche und zum Protokollieren angezeigt werden können.
Figure 3 GetSiteSettings-Ausschnitt (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
Im nächsten Schritt wird die XML-Datei zum Sammeln und Aufzeichnen der SMS-Informationen für den Zielstandortserver eingerichtet, wie in Abbildung 4 dargestellt.
Figure 4 Erstellen der XML-Datei (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
Danach muss der Zielstandort in das Visio-Diagramm eingezeichnet und in der Benutzeroberfläche und dem Protokoll aktualisiert werden, wie aus Abbildung 5 hervorgeht.
Figure 5 Zeichnen des Standorts in Visio (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
Der oben beschriebene grundlegende Code, der SMS abfragt und in Visio zeichnet, wird für die gesamte Hierarchie des Zielstandorts ausgeführt. Dabei handelt es sich um eine Funktion namens Level, die rekursiv aufgerufen wird, damit auch untergeordnete Standorte unabhängig von der Größe der Hierarchie abgefragt werden. Level sammelt die SMS-Standortinformationen und zeichnet sie in XML, der Benutzeroberfläche und dem Protokoll für jeden untergeordneten Standort des Zielstandorts auf. Abbildung 6 schließlich zeigt, wie das Visio-Diagramm im zu Beginn des Dienstprogramms ausgewählten Format formatiert wird. Danach werden die XML- und Protokolldateien geschlossen.
Figure 6 Abschließen (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

Wie geht es weiter?
Selbstverständlich ist dies erst der Anfang. Es gibt noch zahlreiche Verbesserungsmöglichkeiten. Es muss untersucht werden, ob Medienverwaltungspunkte im SDK enthalten sind. Zur vollständigen Dokumentation eines Standorts könnten zusätzliche Standorteinstellungen hinzugefügt werden. Eventuell müssen unterschiedliche Visio-Layouteinstellungen entwickelt und hinzugefügt werden, damit kleine und große Hierarchien besser dargestellt werden. Bei der Erstellung effektiver Anzeigen treten für jeden Layouttyp andere Probleme auf. Selbstverständlich ist das Hinzufügen von Unterstützung für System Center Configuration Manager 2007 ein wichtiger nächster Schritt. Doch selbst mit dieser ersten Version von SMSMap können sich SMS-Administratoren einen Überblick verschaffen und mit Was-wäre-wenn-Szenarios mit Visio-Schichten und -Transparenzen experimentieren.
Wenn Sie den Quellcode herunterladen, können Sie das Dienstprogramm an Ihre Anforderungen anpassen. Ich habe SMSMap auf Windows XP SP2 mit Visio 2003 und Windows Vista™ Enterprise mit Visio 2007 getestet. Wenn Sie Vorschläge zur Verbesserung dieses Dienstprogramms haben, senden Sie eine E-Mail an jeff.tondt@microsoft.com.

Jeff Tondt ist Senior Consultant II für Microsoft Consulting Services. Seine Schwerpunkte sind die Bereiche Systemverwaltung, Automatisierung und Patchverwaltung. Er ist Experte für SMS und kann über jeff.tondt@microsoft.com erreicht werden.


 How IT Works: Problembehandlung bei RPC-Fehlern
How IT Works
Problembehandlung bei RPC-Fehlern
Zubair Alexander

Wenn Sie in den letzten Jahren mit Windows-Serverplattformen gearbeitet haben, sind Sie wahrscheinlich hin und wieder auf RPC-Fehler (Remote Procedure Call, Remoteprozeduraufruf) gestoßen. Sie erhalten die Nachricht, dass der RPC-Server nicht verfügbar ist oder keine Endpunkte mehr verfügbar sind, oder eine andere merkwürdige Warnung. Wenn derartige Nachrichten für Sie verwirrend sind, sollten Sie weiterlesen. Im Folgenden werden
einige häufige Fehler sowie verschiedene Verfahren zum Identifizieren angezeigter RPC-Fehler aufgezeigt sowie Lösungen für bestimmte Probleme erörtert. Doch bevor ich auf bestimmte RPC-Fehler und -Lösungen eingehe, sollen Ihnen die Grundlagen der RPC-Terminologie vermittelt werden.

Was ist RPC?
RPC ist eine Methode für die Kommunikation zwischen Prozessen (Interprocess Communication, IPC), die von Clients und Servern zur Kommunikation untereinander verwendet wird. Einfach ausgedrückt, wird RPC von Programmen (normalerweise auf einem Clientcomputer) verwendet, um ein Programm auf einem Servercomputer auszuführen. Microsoft® Outlook®-Clients beispielsweise kommunizieren mit Microsoft Exchange Server mithilfe von RPC. Der Clientcomputer sendet eine Nachricht mit bestimmten Argumenten an den Servercomputer. Der Server antwortet dem Client mit einer Nachricht, die die Ergebnisse des ausgeführten Programms enthält.
Wesentlich für diesen Prozess ist der Endpunkt – der Name, Port oder die Gruppe von Ports auf einem Computer, die von einem Server auf eingehende Clientanforderungen überwacht wird. Genauer gesagt ist es die netzwerkspezifische Adresse eines Serverprozesses, die für RPCs verwendet wird.
Die Endpunktzuordnung als Teil des RPC-Subsystems ist dafür verantwortlich, auf die Anforderungen der Clients zu antworten, um dynamische Endpunkte aufzulösen. In manchen Situationen ist die Endpunktzuordnung auch für die dynamische Zuweisung von Endpunkten zu Servern verantwortlich.
Eine weitere wichtige RPC-Komponente ist der Locatordienst. Er verwaltet eine Liste von RPC-Diensten und Servern auf dem Netzwerk. Ein Windows®-Client stellt eine Verbindung zum Domänencontroller über die SMB-Ports (Server Message Block) (TCP 139 und 445) her und sucht über den Locatordienst nach RPC-Diensten oder Servern.
Die meisten integrierten Windows-Dienste kommunizieren mithilfe von RPC miteinander. Zertifikatsdienste, DCOM, FRS, MSMQ, MAPI und Active Directory® Replication Service beispielsweise verwenden RPC für die Kommunikation. Wenn daher der RPC-Dienst in einem Netzwerk nicht richtig funktioniert, kann es zu einer Reihe von Kommunikationsproblemen kommen.

RPC-Fehler
Hier werden einige Fehler näher beleuchtet, die auftreten können, wenn der RPC-Dienst versagt. (Dies ist keinesfalls eine vollständige Liste.)
Wenn der Dateireplikationsdienst (File Replication Service, FRS) versagt, könnte der gefürchtete Fehler „RPC nicht verfügbar“ am Werk sein. Wenn Sie versuchen, ein Laufwerk zuzuordnen, könnte der Fehler „Zugriff verweigert“ auftreten. Bei der Verwendung von Active Directory-Benutzer und -Computer könnte folgende Fehlermeldung angezeigt werden: „Die angegebene Domäne ist nicht vorhanden, oder es konnte keine Verbindung mit ihr hergestellt werden.“ Beim Anmelden bei der Domäne könnte folgender Fehler auftreten: „The system cannot log you on to this domain because the system’s computer account in its primary domain is missing or the password on that account is incorrect“ (Das System kann Sie an diese Domäne nicht anmelden, da das primäre Domänencomputerkonto des Systems fehlt oder das Kennwort für dieses Konto ungültig ist).
Wenn der Microsoft Outlook-Client versucht, mit Exchange Server zu kommunizieren, können RPC-Fehler dem Client eine irreführende Fehlernachricht angeben wie: „Your logon information is incorrect“ (Die Anmeldeinformationen sind ungültig) oder „Outlook could not log on“ (Outlook konnte sich nicht anmelden).
Neben diesen Fehlern kann es zu anderen Problemen kommen, wenn der RPC-Dienst nicht verfügbar ist. Sie können möglicherweise die Domäne in „Netzwerkumgebung“ nicht besuchen oder das Gruppenrichtlinien-Snap-In nicht öffnen.
Dies sind nur einige Situationen, in denen RPCs unerwartete Probleme verursachen. Es gibt noch viele weitere Beispiele, und jedes Mal, wenn Sie an Remoteprozessen beteiligt sind, sind RPC-Probleme möglicherweise die Hauptursache für auftretende Schwierigkeiten. Doch wie können Sie das genau feststellen, und, was noch wichtiger ist, wie können Sie den entsprechenden Fehler aufspüren? Genau darum geht es hier.

Problembehandlung
Wenn Sie vermuten, dass Sie Probleme mit dem RPC-Dienst haben, gibt es mehrere Tools für Diagnosezwecke.
Eins davon ist das Repadmin-Tool. Dieses Programm wird normalerweise zum Überwachen und zur Problembehandlung von Active Directory-Replikationsproblemen verwendet, doch Sie können mit seiner Hilfe auch Probleme mit der RPC-Endpunktzuordnung behandeln. Zum Ausführen des Tools geben Sie in der Eingabeaufforderung repadmin /bind ein. Bei RPC-Problemen könnten Sie etwa folgende Nachricht sehen: „In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.“ Das ist ein erster Anhaltspunkt, dass das Problem mit RPC im Zusammenhang steht.
Eine weitere Option ist die Verwendung des Diagnosetools Domain Controller (DCDiag), eines Befehlszeilenprogramms zum Diagnostizieren von Problemen mit Domänencontrollern. Wenn Sie folgenden Fehler sehen: „Status ist 1722: Der RPC-Server ist nicht verfügbar“, wissen Sie, dass ein RPC-Problem vorliegt, das vom Domain Controller-Diagnosetool aufgedeckt wurde.
Bei der Verwendung von Ntdsutil (ein Befehlszeilenprogramm zum Verwalten von Active Directory und Durchführen zahlreicher Wartungsaufgaben) könnte es bei einem Verbindungsversuch mit dem Server zu RPC-Fehlern kommen. Wahrscheinlich wird einer der häufigeren Fehler angezeigt, z. B.: „In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.“ Wieder ist dies ein Anhaltspunkt, dass es sich um Probleme mit dem RPC-Dienst handeln könnte. Das Gpotool-Tool, das die Konsistenz von Gruppenrichtlinienobjekten auf Domänencontrollern prüft, zeigt ähnliche Fehler an, wenn Schwierigkeiten mit RPC auftreten.
Das Dcpromo.log, das generiert wird, wenn Sie einen Windows 2000 Server- oder Windows Server® 2003-Server mithilfe des Dcpromo-Tools zu einem Domänencontroller hochstufen, kann ebenfalls Probleme mit RPC offen legen. Wenn die Hochstufung fehlschlägt, sollten Sie sich das Protokoll ansehen. Es befindet sich im Ordner %windir%\debug. Die aufgeführten Fehler zeigen beispielsweise an, dass der Verzeichnisdienst die Partition nicht repliziert oder das Objekt nicht erstellt hat. Am Ende der Nachricht wird ein Fehlercode angegeben. Hier sehen Sie ein Beispiel für eine Fehlermeldung im Dcpromo.log:

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
Beachten Sie den Fehlercode 1722, der in dieser Nachricht viermal auftaucht und anzeigt, dass der RPC-Server nicht verfügbar ist. In Abbildung 1 sind einige Fehlercodes und ihre Beschreibungen aufgeführt. Weitere Fehlercodes können Sie hier einsehen: msdn2.microsoft.com/ms681386.
Figure 1 Fehlercodes und ihre Beschreibungen (Close Figure 1)

Fehlercode | Beschreibung
58 | Der angegebene Server kann den angeforderten Vorgang nicht ausführen.
1721 | Für diesen Vorgang sind nicht genügend Ressourcen verfügbar.
1722 | Der RPC-Server ist nicht verfügbar.
1723 | Der RPC-Server ist für diesen Vorgang zu stark ausgelastet.
1727 | Der Remoteprozeduraufruf ist fehlgeschlagen und wurde nicht ausgeführt.
1753 | In der Endpunktzuordnung sind keine weiteren Endpunkte verfügbar.

Beheben von RPC-Fehlern
Sie wissen nun, wie Sie manche RPC Fehler erkennen können. Nachstehend werden Lösungen erörtert.
Microsoft-Clients stellen eine Verbindung zur RPC-Endpunktzuordnung an Port 135 her. Dann teilt die Endpunktzuordnung dem Client mit, an welchem Port ein angeforderter Dienst abfragt. Die Portnummern werden dynamisch zugewiesen und liegen zwischen 1024 und 65.535. Wenn Fehler wie 1753 angezeigt werden, denen zufolge keine Endpunkte mehr von der Endpunktzuordnung zur Verfügung stehen, bedeutet dies, dass die RPC-Endpunktzuordnung für einen Dienst keinen Port verwenden konnte, der größer als 1024 ist. Dieses Thema wird weiter unten eingehender beleuchtet.
Zunächst sollten Sie den Status des RPC-Diensts auf dem Server überprüfen. Abhängig von der Art der Serverrolle sollten der RPC- und RPC-Locatordienst den in Abbildung 2 aufgeführten Status haben. Wenn einer der beiden Dienste nicht wie in der Abbildung dargestellt konfiguriert ist, passen Sie den Status an, starten Sie den Server neu, und testen Sie, ob das Problem auf diese Weise gelöst wird.
Figure 2 Status des RPC-Diensts (Close Figure 2)

Serverrolle | RPC-Dienst | RPC-Locatordienst
Windows Server 2003 – Domänencontroller | Gestartet, automatisch | Beendet, manuell
Windows Server 2003 – Mitgliedsserver | Gestartet, automatisch | Beendet, manuell
Windows Server 2003 – Eigenständiger Server | Gestartet, automatisch | Beendet, manuell
Windows 2000 Server – Domänencontroller | Gestartet, automatisch | Beendet, automatisch
Windows 2000 Server – Mitgliedsserver | Gestartet, automatisch | Gestartet, manuell
Windows 2000 Server – Eigenständiger Server | Gestartet, automatisch | Beendet, manuell
Überprüfen Sie, ob Ihr Client erfolgreich eine Pinganforderung an den Server senden kann, der Konnektivitätsprobleme hat. Wenn Sie beispielsweise Schwierigkeiten haben, mit einem Server mit der Bezeichnung DC1 zu kommunizieren, dessen IP-Adresse 192.168.1.200 ist, verwenden Sie folgenden Befehl in der Eingabeaufforderung, um zu überprüfen, ob DNS den Host DC1 richtig auflöst:
Ping –a 192.168.1.200
Stellen Sie sicher, dass Sie den –a-Schalter mit der IP-Adresse und nicht den Hostnamen verwenden.
Wenn alles richtig funktioniert, sollten Sie eine Antwort von DC1 erhalten, die etwa wie die Pingantwort in Abbildung 3 aussieht. Beachten Sie, dass anstelle einer einfachen Auflösung der IP-Adresse 192.168.1.200 die Pinganforderung auch den Hostnamen dc1.contoso.com aufgelöst hat. Hierdurch wird bestätigt, dass die DNS-Namensauflösung richtig funktioniert und den Hostnamen dc1.contoso.com wie erwartet auflöst.
Figure 3 Pingantwort (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
Sie sollten außerdem sicherstellen, dass die Registrierung auf dem Windows XP- oder Windows 2000-Client mindestens die vier im rechten Bereich in Abbildung 4 aufgeführten ClientProtocols enthält.
Abbildung 4 In der Registrierung aufgeführte RPC-ClientProtocols
Abbildung 4 In der Registrierung aufgeführte RPC-ClientProtocols
Wenn Einträge fehlen, fügen Sie einen neuen Zeichenfolgenwert mit dem in Abbildung 4 dargestellten Namen und Datentyp hinzu. Standardmäßig gibt es einen fünften Eintrag namens „ncacn_nb_tcp“, der zum Identifizieren von NetBIOS über TCP als Protokollfamilie für den Endpunkt dient. Abhängig von Ihrer Konfiguration wird dieser Eintrag möglicherweise nicht unter ClientProtocols aufgeführt. Fügen Sie ihn in diesem Fall manuell hinzu, um festzustellen, ob die RPC-Fehler dadurch gelöst werden.
Beachten Sie die Schlüssel, die unter dem Rpc-Ordner im linken Bereich in der Abbildung aufgelistet sind, nämlich ClientProtocols, NameService, NetBIOS und SecurityService. Wenn Sie einen Schlüssel namens „Internet“ sehen, der keine Werte hat, versuchen Sie, den Schlüssel zu entfernen und den Computer neu zu starten. Auf diese Weise könnte das Problem behoben werden. Sie sollten jedoch wie immer vorsichtig sein, wenn Sie die Windows-Registrierung ändern.
Wie bereits erwähnt, verwendet RPC Ports zwischen 1024 und 65.535, und Sie müssen sicherstellen, dass diese Ports nicht durch eine Firewall gesperrt sind. Mithilfe des Port Query-Tools lässt sich am einfachsten sicherstellen, dass ein Port offen ist. Dieses Tool liegt in zwei Versionen vor: in einer Befehlszeilenversion (PortQry) und in einer Version mit grafischer Benutzeroberfläche (PortQueryUI).
PortQry kann im Microsoft-Downloadcenter heruntergeladen werden. Zusätzliche Informationen finden Sie im Artikel Beschreibung des Befehlszeilenprogramms Portqry.exe. Dort finden Sie kurze Beschreibungen von PortQry- Statusberichten und Beispiele für Befehle zur Problemlösung. Natürlich können Sie auch die einfacher zu verwendende Version mit der grafischen Benutzeroberfläche einsetzen. Sie finden diesen Download unter go.microsoft.com/fwlink/?LinkId=73740.
Port Query muss auf einem Computer ausgeführt werden, bei dem keine RPC-Fehler vorliegen. Das Tool muss für einen Computer ausgeführt werden, bei dem Probleme mit RPC vorhanden sind. Wenn Sie beispielsweise überprüfen wollen, ob Port 135, der von der RPC-Endpunktzuordnung verwendet wird, offen ist, verwenden Sie PortQry folgendermaßen in der Eingabeaufforderung:
portqry -n [servername] -e 135
Egal, ob Sie PortQuery oder PortQueryUI verwenden, erhalten Sie etwa folgende Ergebnisse:
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
Die letzten Zeile zeigt, dass Port 135 offen ist. Andernfalls wird in dieser letzten Zeile NOT LISTENING angegeben.
Um mehrere Ports auf einmal zu prüfen, geben Sie die Portnummern durch Kommas getrennt ein, z. B. „135,1024-5000“.

Zusätzliche Lösungen
Wenn Sie alle bisher aufgeführten Tricks ausprobiert haben und das Problem immer noch nicht behoben ist, stehen Ihnen weitere Optionen offen. Abhängig von den spezifischen Problemen in Ihrer Umgebung könnten Sie eine der folgenden Änderungen an der Registrierung durchführen. (Vorsicht! Bevor Sie Änderungen an der Registrierung vornehmen, müssen Sie unbedingt eine Sicherungskopie Ihres System und speziell von der Registrierung erstellen, damit Sie den ursprünglichen Zustand des Computers wiederherstellen können, falls der Lösungsversuch fehlschlägt.)
Eine Option besteht darin, MaxUserPort so anzupassen, dass von TCP die höchstmögliche Portnummer angegeben wird, wenn eine Anwendung einen verfügbaren Benutzerport vom System anfordert. Standardmäßig stellt Windows Server 2003 den MaxUserPort-Wert auf 5000 ein, d. h. 5000 wird als höchste Portnummer verwendet, selbst wenn der Eintrag nicht existiert. Abhängig von Ihrer Konfiguration ist dieser Eintrag u. U. nicht in der Registrierung vorhanden. In diesem Fall können Sie ihn an der in Abbildung 5 dargestellten Stelle hinzufügen.
Abbildung 5 MaxUserPort-Einstellung in der Registrierung
Abbildung 5 MaxUserPort-Einstellung in der Registrierung
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
Beim Ändern der Registrierung müssen Sie sich anderer möglicher Nebeneffekte bewusst sein, was nicht immer einfach ist. Die Änderung dieses Eintrags könnte sich auf Microsoft Exchange Server auswirken, wenn der Wert auf unter 50.000 eingestellt wird. Wenn der Exchange Server Best Practices Analyzer (BPA) feststellt, dass der Wert des MaxUserPort- Registrierungsschlüssels unter 50.000 liegt, wird eine Warnung angezeigt. Microsoft empfiehlt, den Wert auf 60.000 einzustellen. Andernfalls könnten Sie NSPI-Proxywarnungen (Name Service Provider Interface) wie Ereignis 9040 verursachen. Weitere Informationen finden Sie im Microsoft-Dokument MaxUserPort-Wert ist zu niedrig.
Sie können außerdem den Wert für TcpMaxDataRetransmissions einstellen. TCP-Pakete erwarten eine Bestätigung von der Empfangsseite. Wenn keine Bestätigung erfolgt, bevor der Zeitgeber abläuft, werden die Pakete bis zum TcpMaxDataRetransmissions-Wert erneut übertragen. Der Standardwert für diesen Parameter ist 5, doch Sie könnten den Wert 4 oder sogar 3 ausprobieren. Verwenden Sie keinen Wert unter 3.
Wenn der TcpMaxDataRetransmissions-Registrierungseintrag nicht vorhanden ist, können Sie ihn der Registrierung wie unten angegeben an der folgenden Stelle hinzufügen:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
Weitere Informationen zu TcpMaxDataRetransmissions finden Sie im Microsoft Knowledge Base-Artikel 170359: Ändern des maximalen TCP/IP-Zeitüberschreitungswertes.
Ein weiterer Registrierungswert, mit dem Sie experimentieren könnten, ist TcpTimedWaitDelay. Wenn ein Client zu viele Ports verwendet, ist es durchaus möglich, dass nicht genug Ports vorhanden sind, bevor TCP/IP getrennte Verbindungen freigibt. Der Grund dafür ist, dass TCP/IP die Verbindung erst freigibt, wenn zwei MSLs (Maximum Segment Lives) vergangen sind (dies wird als Wartezeitzustand bezeichnet). Da jedes MSL zudem als 120 Sekunden definiert wird und TCP/IP die Verbindung erst freigibt, wenn zwei MSLs vergangen sind, dauert es bis zu 240 Sekunden (4 Minuten), bis TCP/IP eine getrennte Verbindung freigibt. Dies war ein bekanntes Problem in Windows NT®, das mit einem Service Pack korrigiert wurde. Daher ist das Auftreten dieses Problems heute relativ unwahrscheinlich. Microsoft empfiehlt allerdings das Anpassen dieser Einstellung als eine mögliche Lösung für die Fehler bei der RPC-Endpunktzuordnung, wie im Knowledge Base-Artikel Beheben von Fehlern bei der RPC-Endpunktzuordnung erläutert wird.
TcpTimedWaitDelay wird der Registrierung an folgender Stelle hinzugefügt:
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
Weitere Informationen zu TcpTimedWaitDelay finden Sie in diesem Knowledge Base-Artikel: Nicht genug Ports für Windows NT-Clients. Obwohl der Artikel keine bestimmten Zahlen empfiehlt, könnten Sie TcpTimedWaitDelay auf 60 (Sekunden) als Dezimalzahl reduzieren, was einem Hexadezimalwert von 3c entspricht.

Schlussbemerkung
RPC-Fehler können die Hauptursache zahlreicher Kommunikationsfehler in Ihrem Netzwerk sein. Glücklicherweise gibt es mehrere kreative Möglichkeiten, um diese schwer fassbaren Probleme zu beheben. Einige der hier vorgeschlagenen Tools sind integriert, während andere im Windows Server Ressource Kit zur Verfügung stehen. Viele sind in Abbildung 6 aufgeführt. Sie können diese Tools einsetzen, um Ursache und Ort von RPC-Fehlern festzustellen, und dann die in diesem Artikel aufgeführten Verfahren zur Fehlerbehebung verwenden.
Figure 6 Tools zur RPC-Problembehandlung (Close Figure 6)

Tool | Beschreibung
DCDiag | Analysiert den Zustand der Domänencontroller.
Ereignisanzeige | Zeigt protokollierte Ereignisse an.
Gpotool | Stellt fest, ob die Richtlinien gültig und konsistent sind.
NetDiag | Dient zum Testen der Netzwerkkonnektivität.
Netzwerkmonitor | Überwacht den Netzwerkverkehr und zeichnet ihn auf.
Ntdsutil | Stellt Verwaltungsfunktionen für Active Directory bereit.
PortQry, PortQueryUI | Dient zum Testen der TCP/IP-Konnektivität.
Repadmin | Diagnostiziert Replikationsprobleme zwischen Windows-DCs.
RPCDump | Wird normalerweise zusammen mit dem Netzwerkmonitor verwendet.
RPCPing | Dient zum Bestätigen der RPC-Konnektivität.

Zubair Alexander, MCSE, MCT und Microsoft MVP, ist Geschäftsinhaber von SeattlePro Enterprises, ein Unternehmen für IT-Schulung und -Beratung. Seine Erfahrung deckt das gesamte Spektrum der IT-Schulung ab: Autor, Hochschullehrer, Berater, Netzwerktechniker, Referent, Sicherheitsarchitekt, Systemadministrator, technischer Redakteur und Ausbilder. Sie können Zubair Alexander unter alexander@techgalaxy.net erreichen.


 The Cable Guy: IPv6-Datenverkehr &#252;ber VPN-Verbindungen
The Cable Guy
IPv6-Datenverkehr über VPN-Verbindungen
Joseph Davies

Wenn Sie mit der Bewertung der Rolle von Internetprotokoll Version 6 (IPv6) auf Ihrem Intranet und der Planung für die Bereitstellung beginnen, sollten Sie wissen, wie IPv6-Datenverkehr über Verbindungen im virtuellen privaten Netzwerk (Virtual Private Network, VPN) in Windows unterstützt wird. Mit VPN-Verbindungen können Sie Ihr Netzwerk ausdehnen und Links über öffentliche
Netzwerke wie das Internet einbeziehen. VPN-Verbindungen werden durch sichere Authentifizierungsprotokolle geschützt, die die Anmeldeinformationen des verbindenden Benutzers überprüfen, sowie Verschlüsselungsmethoden, um die Vertraulichkeit der Daten zu gewährleisten.
Windows® XP und Windows Server® 2003 umfassen einen IPv6-Protokollstapel, doch viele Kerndienste und Netzwerkkomponenten unterstützen IPv6 nicht. Windows Vista™ und Windows Server 2008, früher mit dem Codenamen „Longhorn“ bezeichnet, verfügen über umfassenden Support für IPv6, der standardmäßig installiert und aktiviert wird. Fast alle Netzwerkanwendungen und Dienste, die in Windows Vista und Windows Server 2008 enthalten sind, unterstützen IPv6. In diesem Monat geht es um den Support in Windows Vista, Windows Server 2008, Windows XP und Windows Server 2003 für IPv6-Datenverkehr über VPN-Verbindungen, die über das Internetprotokoll Version 4 (IPv4) und IPv6-Internetverbindungen eingerichtet werden.

VPN-Verbindungen über das IPv4-Internet
Bei den meisten heutigen Intranets werden VPN-Verbindungen über das IPv4-Internet erstellt. Abbildung 1 zeigt Windows-basierte Komponenten für VPN-Verbindungen dieser Art. Diese Komponenten bestehen aus Folgendem:
Abbildung 1 Windows-basierte Komponenten für VPN-Verbindungen über das IPv4-Internet
Abbildung 1 Windows-basierte Komponenten für VPN-Verbindungen über das IPv4-Internet
VPN-Client Dies ist ein Computer, der eine RAS-VPN-Verbindung zu einem VPN-Server initiiert und mit Intranetressourcen kommuniziert. Eine RAS-VPN-Verbindung ermöglicht es dem VPN-Client so zu arbeiten, als sei er direkt mit dem Intranet verbunden. Ein VPN-Client kann Client- oder Serverversionen von Windows ausführen.
VPN-Server Dieser Computer überwacht RAS-VPN-Verbindungsversuche, setzt Authentifizierungs- und Verbindungsanforderungen durch und leitet Pakete zwischen VPN-Clients und Intranetressourcen weiter. Ein VPN-Server führt normalerweise eine Serverversion von Windows mit dem Routing- und RAS-Dienst aus.
VPN-Router Ein VPN-Router ist ein Computer, der Standort-zu-Standort-VPN-Verbindungsversuche initiiert oder überwacht. Eine Standort-zu-Standort-VPN-Verbindung verbindet zwei Teile eines Intranets. Ein VPN-Router führt eine Serverversion von Windows sowie den Routing- und RAS-Dienst aus.
VPN-Verbindung Eine VPN-Verbindung ist die logische Verbindung zwischen dem VPN-Client und dem VPN-Server oder zwischen VPN-Routern entsprechend der Kapselung eines VPN-Protokolls.
IPv6-aktiviertes Intranet Dieses Intranet kann IPv6-Datenverkehr systemintern oder als getunnelte IPv4-Pakete weiterleiten.
IPv6/IPv4-Host Dieser Intranetknoten sendet und empfängt IPv6-Datenverkehr systemintern oder als getunnelte IPv4-Pakete.
Windows-basierte VPN-Clients, Server und Router können folgende VPN-Protokolle verwenden, um die über die VPN-Verbindung gesendeten Pakete zu kapseln: Point-to-Point-Tunneling-Protokoll (PPTP), Layer Two Tunneling-Protokoll mit Internet Protocol Security (L2TP/IPsec) und Secure Socket Tunneling-Protokoll (SSTP). SSTP wird nur von Windows Vista mit Service Pack 1 (SP1, derzeit in der Betatestversion) und Windows Server 2008 unterstützt.
Für VPN-Verbindungen über das IPv4-Internet gibt es zwei Methoden zum Senden von IPv6: Als IPv4-Pakete getunnelte IPv6-Pakete, die nachstehend als IPv6-over-IPv4-Datenverkehr bezeichnet werden, und systemeigener IPv6-Datenverkehr.
In diesem Artikel wird die Unterstützung für IPv6-Datenverkehr über VPN-Verbindungen mithilfe von VPN-Protokollen und Versionen von Windows aufgezeigt. Bei RAS-VPN-Verbindungen bedeutet eine bestimmte Kombination aus einem VPN-Protokoll und einer Version von Windows Unterstützung sowohl durch RAS-Client- als auch RAS-Serverkomponenten von Windows.

IPv6-over-IPv4-Datenverkehr
Bei dieser Methode kapselt ein RAS-Client oder ein IPv6/IPv4-Host im Intranet IPv6-Pakete mit einem IPv4-Header und sendet das Ergebnis als IPv4-Paket. Für Intranets ermöglicht die IntraSite Automatic Tunnel Addressing Protocol (ISATAP) IPv6-Übergangstechnologie (RFC 4214) es IPv6/IPv4-Knoten, den IPv6-Datenverkehr über ein reines IPv4-Intranet auszutauschen. Mit ISATAP können Sie IPv6-Konnektivität in einem reinen IPv4-Intranet aktivieren, ohne vorhandene Router konfigurieren oder aktualisieren zu müssen, damit sie die systemeigene IPv6-Adressierung und -weiterleitung unterstützen. Weitere Informationen zu ISATAP finden Sie unter „IPv6-Übergangstechnologien“ unter microsoft.com/technet/network/ipv6/ipv6coexist.mspx.
Abbildung 2 zeigt die allgemeine Paketstruktur für VPN-Datenverkehr beim Senden eines IPv4-Pakets mithilfe einer VPN-Verbindung über das IPv4-Internet. Das IPv4-Paket wird vom VPN-Protokoll mit einem Header und – abhängig vom VPN-Protokoll – mit einem Nachspann gekapselt. Das Ergebnis wird mit einem IPv4-Header gekapselt, der das Weiterleiten über das IPv4-Internet ermöglicht.
Abbildung 2 IPv4-Pakete, die eine VPN-Verbindung über das IPv4-Internet verwenden
Abbildung 2 IPv4-Pakete, die eine VPN-Verbindung über das IPv4-Internet verwenden
Bei IPv6-over-IPv4-Datenverkehr ist die Nutzlast des über die VPN-Verbindung gesendeten IPv4-Pakets ein IPv6-Paket. Abbildung 3 zeigt die allgemeine Paketstruktur für VPN-Datenverkehr beim Senden eines IPv6-over-IPv4-Pakets mithilfe einer VPN-Verbindung über das IPv4-Internet.
Abbildung 3 IPv6-over-IPv4-Pakete, die eine VPN-Verbindung über das IPv4-Internet verwenden
Abbildung 3 IPv6-over-IPv4-Pakete, die eine VPN-Verbindung über das IPv4-Internet verwenden
Für RAS-VPN-Verbindungen wird IPv6-over-IPv4-Datenverkehr über das IPv4-Internet von PPTP und L2TP/IPsec in Windows Vista, Windows Server 2008, Windows XP SP1 oder höher und Windows Server 2003 und von SSTP in Windows Vista SP1 und Windows Server 2008 unterstützt. Für Standort-zu-Standort-VPN-Verbindungen wird IPv6-over-IPv4-Datenverkehr über das IPv4-Internet von PPTP und L2TP/IPsec in Windows Server 2008 und Windows Server 2003 unterstützt.

Systemeigener IPv6-Datenverkehr
Für systemeigenen IPv6-Datenverkehr sendet der VPN-Client, Server oder Router IPv6-Pakete über die VPN-Verbindung ohne anfängliche IPv4-Kapselung. Dies funktioniert für Intranets, die über systemeigene IPv6-Konnektivität verfügen, und erfordert, dass die VPN-Clients, Server, und Router das IPv6-Steuerungsprotokoll (IPV6CP), RFC 2472, unterstützen, das definiert, wie IPv6-Knoten IPv6-Konfigurationsoptionen für Verbindungen auf Basis des Point-to-Point-Protokolls (PPP) aushandeln. Windows Vista und Windows Server 2008 unterstützen IPV6CP, während dies bei Windows XP und Windows Server 2003 nicht der Fall ist. Abbildung 4 zeigt die allgemeine Paketstruktur für VPN-Datenverkehr beim Senden eines systemeigenen IPv6-Pakets mithilfe einer VPN-Verbindung über das IPv4-Internet.
Abbildung 4 Systemeigene IPv6-Pakete, die eine VPN-Verbindung über das IPv4-Internet verwenden
Abbildung 4 Systemeigene IPv6-Pakete, die eine VPN-Verbindung über das IPv4-Internet verwenden
Für RAS-VPN-Verbindungen wird systemeigener IPv6-Datenverkehr über das IPv4-Internet von PPTP und L2TP/IPsec in Windows Vista und Windows Server 2008 und von SSTP in Windows Vista SP1 und Windows Server 2008 unterstützt. Für Standort-zu-Standort-VPN-Verbindungen wird systemeigener IPv6-Datenverkehr, der über das IPv4-Internet übermittelt wird, von PPTP und L2TP/IPsec in Windows Server 2008 unterstützt.

VPN-Verbindungen über das IPv6-Internet
Sie können VPN-Verbindungen auch über das IPv6-Internet herstellen. Solche VPN-Verbindungen sind heute noch selten. In Zukunft aber werden immer mehr Internetdienstanbieter ihren Kunden IPv6 anbieten und immer mehr Organisationen IPv6-Internetkonnektivität an der Intranetgrenze ihrer Netzwerke zur Verfügung stellen.
Um VPN-Verbindungen über das IPv6-Internet zu unterstützen, müssen die verwendeten VPN-Protokolle Verbindungen über IPv6 unterstützen. In Windows Vista und Windows Server 2008 unterstützen die L2TP/IPsec- und die SSTP-VPN-Protokolle RAS-VPN-Verbindungen über IPv6. In Windows Server 2008 unterstützt L2TP/IPsec Standort-zu-Standort-Verbindungen über IPv6. VPN-Verbindungen über das IPv6-Internet verwenden denselben Satz an Komponenten wie für VPN-Verbindungen über das IPv4-Internet für RAS- und Standort-zu-Standort-VPN-Verbindungen.
Es gibt zudem zwei Möglichkeiten, IPv6-Pakete über das IPv6-Internet zu senden: IPv6-over-IPv4-Datenverkehr und systemeigener IPv6-Datenverkehr. Abbildung 5 zeigt die allgemeine Struktur von IPv6-over-IPv4-Paketen, wenn sie über eine VPN-Verbindung über das IPv6-Internet gesendet werden.
Abbildung 5 IPv6-over-IPv4-Pakete, die eine VPN-Verbindung über das IPv6-Internet verwenden
Abbildung 5 IPv6-over-IPv4-Pakete, die eine VPN-Verbindung über das IPv6-Internet verwenden
Für RAS-VPN-Verbindungen wird IPv6-over-IPv4-Datenverkehr über das IPv6-Internet von L2TP/IPsec in Windows Vista und Windows Server 2008 und von SSTP in Windows Vista SP1 und Windows Server 2008 unterstützt. Für Standort-zu-Standort-VPN-Verbindungen wird IPv6-over-IPv4-Datenverkehr über das IPv6-Internet von L2TP/IPsec in Windows Server 2008 unterstützt. Genau wie bei IPv6-over-IPv4-Datenverkehr über das IPv4-Internet erfordert IPv6-over-IPv4-Datenverkehr über das IPv6-Internet die Bereitstellung einer IPv6-Übergangstechnologie wie ISATAP auf Ihrem Intranet.
Abbildung 6 zeigt die allgemeine Struktur von systemeigenen IPv6-Paketen, wenn sie über eine VPN-Verbindung über das IPv6-Internet gesendet werden. Genau wie bei systemeigenem IPv6-Datenverkehr über das IPv4-Internet erfordert systemeigener IPv6-Datenverkehr über das IPv6-Internet IPV6CP-Support und die Bereitstellung von systemeigener IPv6-Konnektivität auf Ihrem Intranet.
Abbildung 6 Systemeigene IPv6-Pakete, die eine VPN-Verbindung über das IPv6-Internet verwenden
Abbildung 6 Systemeigene IPv6-Pakete, die eine VPN-Verbindung über das IPv6-Internet verwenden
Für RAS-VPN-Verbindungen wird systemeigener IPv6-Datenverkehr über das IPv6-Internet von L2TP/IPsec in Windows Vista und Windows Server 2008 und von SSTP in Windows Vista SP1 und Windows Server 2008 unterstützt. Für Standort-zu-Standort-VPN-Verbindungen wird systemeigener IPv6-Datenverkehr über das IPv6-Internet von L2TP/IPsec in Windows Server 2008 unterstützt.

Zusammenfassung
Abbildung 7 zeigt die vier Methoden zum Senden von IPv6-Datenverkehr über VPN-Verbindungen und die Unterstützung in Windows für die zwei verschiedenen Arten von VPN-Verbindungen. Kurz gesagt: wenn Sie eine IPv6-Übergangstechnologie wie ISATAP auf Ihrem Intranet verwenden, können Sie IPv6-over-IPv4-Datenverkehr über VPN-Verbindungen über das IPv4- und IPv6-Internet senden. Wenn Ihr Intranet systemeigene IPv6-Konnektivität unterstützt, können Sie systemeigenen IPv6-Datenverkehr über VPN-Verbindungen mit Windows Vista und Windows Server 2008 sowohl über das IPv4- als auch das IPv6-Internet senden.
Figure 7 Unterstützung für IPv6-Datenverkehr über VPN-Verbindungen in Windows (Close Figure 7)

Methode zum Senden von IPv6-Datenverkehr | RAS-VPN-Verbindungen | Standort-zu-Standort-VPN-Verbindungen
IPv6-over-IPv4-Datenverkehr über das IPv4-Internet | PPTP und L2TP/IPsec in Windows Vista, Windows Server 2008, Windows XP SP1 oder höher und Windows Server 2003 SSTP in Windows Vista SP1 und Windows Server 2008 | PPTP und L2TP/IPsec in Windows Server 2008 und Windows Server 2003
Systemeigener IPv6-Datenverkehr über das IPv4-Internet | PPTP und L2TP/IPsec in Windows Vista und Windows Server 2008 SSTP in Windows Vista SP1 und Windows Server 2008 | PPTP und L2TP/IPsec in Windows Server 2008
IPv6-over-IPv4-Datenverkehr über das IPv6-Internet | L2TP/IPsec in Windows Vista und Windows Server 2008 SSTP in Windows Vista SP1 und Windows Server 2008 | L2TP/IPsec in Windows Server 2008
Systemeigener IPv6-Datenverkehr über das IPv6-Internet | L2TP/IPsec in Windows Vista und Windows Server 2008 SSTP in Windows Vista SP1 und Windows Server 2008 | L2TP/IPsec in Windows Server 2008

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


 Windows PowerShell: Neuer Ansatz f&#252;r die Pipeline
Windows PowerShell
Neuer Ansatz für die Pipeline
Don Jones

Es wurde viel darüber geredet, wie anders, neuartig und interessant Windows PowerShell ist. Trotzdem basiert Windows PowerShell auf Konzepten im Bereich Befehlszeilenschnittstellen, die es bereits seit Jahrzehnten hauptsächlich in UNIX- und Linux-basierten Betriebssystemen gibt. Die Tatsache, dass die Terminologie von Windows PowerShell und ihren Vorläufern sehr ähnlich ist, führt oft dazu, dass
die flexiblen und einzigartigen Features von Windows PowerShell™ in einer Windows®-Umgebung leicht übersehen werden.
Eines der am häufigsten diskutierten, aber auch am häufigsten missverstandenen Features von Windows PowerShell ist die Pipeline. Dies ist darauf zurückzuführen, dass die entsprechende Terminologie in den frühen 70er Jahren definiert wurde, die damals ganz andere und weniger leistungsfähige Funktionen repräsentierte.

Der Ursprung von Pipes
Eine der ersten UNIX-Shells überhaupt war die Thompson-Shell. Sie war sehr einfach und enthielt nur die grundlegendsten Elemente der Skriptsprache ohne Variablen. Die Shell war absichtlich schlicht gehalten, da ihr Zweck einzig im Ausführen von Programmen bestand. Sie führte jedoch ein wichtiges Konzept ein, das damaligen Shells überlegen war: Pipes. Mithilfe der Symbole < und > konnte die Shell angewiesen werden, die Eingabe und Ausgabe an und von verschiedenen Befehlen umzuleiten. Der Benutzer war jetzt in der Lage, beispielsweise die Befehlsausgabe an eine Datei umzuleiten.
Diese Syntax wurde später erweitet, sodass die Ausgabe eines Befehls auch zur Eingabe eines anderen Befehls geleitet werden konnte. Somit bestand die Möglichkeit, lange Befehlsfolgen zum Durchführen komplizierterer Aufgaben zu verketten. In Version 4 der Shell wurde der senkrechte Strich „|“ für das Weiterleiten übernommen, der seitdem als Pipezeichen bezeichnet wird. Selbst in den frühesten Versionen von MS-DOS® wurden einfache Weiterleitungsfunktionen mithilfe dieser Zeichen implementiert, sodass Benutzer beispielsweise die Ausgabe des Befehls „type“ in die Eingabe des Befehls „more“ leiten konnten, wodurch für lange Textdateien eine Anzeige von jeweils einer Seite erstellt werden konnte.
Obwohl die Thompson-Shell mit der Veröffentlichung von UNIX-Version 6 im Jahr 1975 allgemein als unzulänglich angesehen wurde, hatte sich das Konzept von Pipes bei Shellentwicklern und Benutzern durchgesetzt. Noch heute wird es bei einer Reihe von Technologien verwendet.

Weiterleiten von Text
Eine Einschränkung fast aller Shells besteht darin, dass sie von Natur aus textorientiert sind. In UNIX-basierten Betriebssystemen ist dies eigentlich keine Einschränkung, sondern spiegelt wider, wie das Betriebssystem an sich funktioniert. Fast jede Ressource in UNIX kann als Datei dargestellt werden, sodass das Weiterleiten von Text von einem Befehl in einen anderen eine leistungsstarke und flexible Funktion darstellt.
Im Bereich Verwaltungsinformationen hat Text jedoch eine eher einschränkende Wirkung. Wenn Sie sich beispielsweise eine Liste von auf einem Windows-Computer ausgeführten Diensten ansehen, wäre Ihnen diese sehr wahrscheinlich verständlich. Der Dienstname wäre vielleicht in der ersten Spalte enthalten, der Startmodus in der zweiten. Das menschliche Gehirn ist leistungsfähig genug, um, diese Textanzeige sofort klar zu analysieren und in sinnvolle und nützliche Informationen zu übersetzen. Computer sind leider nicht so clever: Damit ein Computer mit dieser Liste sinnvoll arbeiten kann, müssten Sie ihm beispielsweise mitteilen, dass die erste Spalte aus den Zeichen 1 bis 20 besteht und die zweite Spalte aus den Zeichen 22 bis 40 und so weiter.
Lange Zeit war diese Art der Textdateianalyse die einzige Möglichkeit für Administratoren, mehrere Befehle miteinander zu verketten. Tatsächlich zeichnen sich Skriptprogrammiersprachen wie VBScript und Perl hauptsächlich durch die Zeichenfolgemanipulation aus, weil sie in der Lage sind, die Textausgabe eines Programms oder Befehls aufzunehmen, zu analysieren und schließlich nützliche Daten auszugeben, die für eine nachfolgende Aufgabe verwendet werden können. Ich habe beispielsweise VBScript-Aufträge geschrieben, bei denen die Textausgabe des Dir-Befehls aufgenommen, diese Ausgabe auf Dateinamen und Daten analysiert und dann alte, nicht verwendete Dateien in ein Archiv verschoben wurden. Die Zeichenfolgenanalyse ist äußerst knifflig, da es fast immer zu Ausnahmen, also Varianten bei den Eingabedaten kommt, sodass die Logik im Skript geändert werden muss, um alle möglichen Kombinationen zu berücksichtigen.
Als Form der administrativen Skripterstellung oder Automatisierung in einer Windows-Umgebung ist die Zeichenfolgenanalyse weniger nützlich. Dies ist darauf zurückzuführen, dass in Windows nicht viele Informationen in einem leicht zugänglichen Textformat gespeichert werden. Stattdessen werden Datenspeicher wie Active Directory®, die Windows-Registrierung und der Zertifikatsspeicher eingesetzt, sodass Skriptersteller zunächst mithilfe eines Tools eine Textausgabe generieren und diese anschließend mit einem Skript analysieren und schließlich einsetzen müssen.

Objekte sind einfacher
Windows-Softwareentwickler hatten es schon immer ein bisschen leichter. Zu Anfang wurde COM von Microsoft speziell entwickelt, um die komplexen internen Funktionsweisen von Windows auf benutzerfreundlichere Art und Weise darzustellen. Heute führt Microsoft® .NET Framework dieselbe Aufgabe durch: es bietet eine standardisierte Darstellung der internen Funktionsweise der Software.
Generisch stellt sowohl COM als auch .NET Elemente als Objekte zur Verfügung. (Ein Softwareentwickler ist mit dieser Vereinfachung möglicherweise nicht einverstanden, aber im Kontext dieses Artikels reicht ein einfacher Begriff aus.) Alle diese Objekte verfügen über Mitglieder verschiedener Arten. Im Rahmen dieser Abhandlung sind die Eigenschaften und Methoden der Objekte von besonderem Interesse. Eine Eigenschaft beschreibt im Wesentlichen ein Objekt auf eine bestimmte Art und Weise bzw. ändert das Objekt oder sein Verhalten. Ein Dienstobjekt beispielsweise könnte über eine Eigenschaft verfügen, die den Namen des Diensts enthält, und eine andere, die den Startmodus enthält. Methoden sorgen dafür, dass ein Objekt eine bestimmte Aktion durchführt. Ein Dienstobjekt enthält beispielsweise Methoden mit der Bezeichnung „Stop“, „Start“, „Pause“ und „Resume“, also die verschiedene Aktionen, die mit dem Dienst durchgeführt werden können.
Programmierer oder Skriptersteller verweisen auf die Mitglieder eines Objekts mit einer punktierten Schreibweise. Objekte werden oft Variablen zugeordnet, sodass das Objekt physisch manipuliert werden kann. Wenn ein Dienst beispielsweise der Variablen „$service“ zugeordnet ist, kann dieser Dienst mithilfe der Syntax „$service.Stop“ angehalten werden. Der Anzeigename des Diensts lässt sich durch Anzeigen von $service.Name abrufen.

Objekte in der Pipe
Da Windows ein großes, komplexes Betriebssystem ist und die Verwaltungsdaten nicht als Textdarstellung speichert, eignen sich ältere Shellverfahren nicht besonders gut für Windows. Angenommen ein Befehlszeilentool namens „SvcList.exe“ erstellt eine formatierte Liste von Diensten und deren Startmodi. In der Windows-Befehlszeilenshell (eine Shell, die ihren Ursprung in der Jahrzehnte alten MS-DOS-Shell hat) ließe sich etwa Folgendes ausführen:
SvcList.exe | MyScript.vbs
Diese Anweisung ruft eine Liste von Diensten ab und leitet diese Liste an eine VBScript-Datei weiter. Die VBScript-Datei müsste so geschrieben werden, dass die formatierte Liste analysiert und die gewünschten Aufgaben ausgeführt werden, beispielsweise die Ausgabe aller Dienste mit dem Startmodus „Disabled“. Diese Aufgabe wäre zeitaufwändig. Letztendlich besteht das Problem darin, dass die Ausgabe von SvcList.exe einmalig ist und kein einheitliches Format vorliegt, über das andere Befehle die Ausgabe nutzen können.
Objekte können dieses einheitliche Format jedoch bereitstellen, und aus diesem Grund funktioniert die Windows PowerShell-Pipeline mit ganzen Objekten und nicht nur mit Text. Beim Ausführen eines Cmdlet wie Get-WMIObject wird eine Gruppe bzw., aus Sicht des Programmierers, eine Sammlung von Objekten erstellt. Jedes Objekt ist mit umfassenden Eigenschaften und Methoden für die Bearbeitung ausgestattet. Beim Weiterleiten der Objekte zum Where-Object-Cmdlet ist eine Filterung möglich, sodass nur die gewünschten Objekte angezeigt werden. Where-Object muss keinen Text analysieren, weil es keinen Text, sondern Objekte empfängt. Beispiel:
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
Oder vorzugsweise die kürzere Syntax in Form von Aliasen:
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
Interessant ist, dass Windows PowerShell immer Objekte entlang der Pipeline weiterleitet. Erst am Ende der Pipeline, wenn die Objekte nicht weitergeleitet werden können, generiert die Shell eine Textdarstellung der Objekte mithilfe integrierter Formatierungsregeln. Sehen Sie sich zum Beispiel Folgendes an:
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
Dieser aus drei Cmdlets bestehende Satz ruft alle Dienste von meinem lokalen Computer ab, filtert alle Dienste aus, die nicht das LocalSystem-Konto zum Anmelden verwenden, und übergibt die übrigen an das Select-Object-Cmdlet, das nur die beiden Eigenschaften ausgibt, die es auswählen sollte (Name und StartMode). Das Ergebnis ist ein einfacher Bericht der Dienste, die sich (vielleicht zur Sicherheitsüberwachung) als LocalSystem anmelden.
Da alle Cmdlets ein einheitliches Datenformat, also Objekte haben, können sie Daten ohne komplizierte Zeichenfolgenanalyse gemeinsam verwenden. Da Windows PowerShell systemeigen die Möglichkeit hat, eine Textdarstellung eines Objekts zu erstellen, ist das Ende dieser Pipe also eine für den Benutzer lesbare Textausgabe. Abbildung 1 zeigt ein Beispiel für die erstellte Ausgabe.
Abbildung 1 Eine Textausgabe, die von einer Reihe weitergeleiteter Cmdlets erstellt wird, die anhand von Objekten übergeben werden
Abbildung 1 Eine Textausgabe, die von einer Reihe weitergeleiteter Cmdlets erstellt wird, die anhand von Objekten übergeben werden

Das Potenzial von Pipes
Das Weiterleiten in Windows PowerShell funktioniert auf so eindrucksvolle Weise, weil in Windows PowerShell ausschließlich Objekte sowie ihre zu verwendenden Eigenschaften und Methoden vorliegen. Selbst eine Textdatei ist aus technischer Sicht eine Sammlung von Zeichenfolgeobjekten, wobei jede Zeile in der Datei als einmaliges und unabhängiges Zeichenfolgeobjekt dient. Erstellen Sie beispielsweise eine Textdatei (mithilfe von Editor) mit der Bezeichnung C:\Computers.txt. Füllen Sie die Datei mit Text, und führen Sie Folgendes in Windows PowerShell aus:
Get-Content C:\Computers.txt | Select-Object Length | Format-List
Wenn Sie lieber weniger Code eingeben, können Sie auch hier wieder Aliase verwenden:
gc C:\Computers.txt | select Length | fl
Dieser Code stellt eine Liste bereit, die anzeigt, wie lang jede Zeile Ihrer Textdatei in Zeichen ist. Get-Content ruft die Zeichenfolgeobjekte aus der Datei ab, Select-Object erfasst die Eigenschaft „Length“ jedes Zeichenfolgeobjekts, und Format-List erstellt eine einfache, für den Benutzer lesbare Textausgabe. Dies ist zwar kein wirklich praktisches Verwaltungstool, trotzdem wird illustriert, dass in Windows PowerShell sogar eine einfache Textzeile ein Objekt ist.
Das Weiterleiten von Objekten von Cmdlet zu Cmdlet (oder auch von Cmdlet zu Skript) ermöglicht das Erstellen unglaublich leistungsfähiger „Einzeiler“. Dabei handelt es sich um einfache Zeichenfolgen von Cmdlets, die in einer langen Pipeline verbunden sind und einen Satz von Objekten ganz nach Wunsch weiter verfeinern. Praktisch ohne jede Skripterstellung oder Programmierung können Windows PowerShell-Cmdlets bemerkenswerte Ergebnisse erzielen, wenn sie in einer entsprechenden Pipeline miteinander verkettet sind.

Unterstützung zukünftiger Generationen
Diese Funktionen werden noch erweitert, da zukünftige Microsoft-Serverprodukte ebenfalls auf Grundlage der Windows PowerShell erstellt werden. Wenn Sie beispielsweise einen neuen Exchange Server 2007-Computer implementieren, können Sie mithilfe von Windows PowerShell alle Postfächer abrufen, diejenigen ausfiltern, die sich nicht im selben Büro befinden wie der neue Mailserver, und diese Postfächer dann zum neuen Server verschieben – und das alles in einer einzigen Textzeile ohne Skripterstellung. Das Exchange Server 2007-Team hat eine ausführliche Liste leistungsfähiger Einzeiler veröffentlicht. Hierdurch wird verdeutlicht, wie leistungsstark die Pipeline ist und welche administrativen Aufgaben sich mit ihrer Hilfe durchführen lassen.
Windows PowerShell baut zwar auf den traditionellen Prinzipien und Philosophien der UNIX-Welt auf, ist aber speziell für die Windows-Verwaltung konzipiert. Lassen Sie sich aufgrund der Gemeinsamkeiten in der Terminologie nicht zu der Annahme verleiten, dass Windows PowerShell lediglich eine Ableitung der UNIX-Shell für Windows ist. Windows PowerShell ist eng mit der Arbeitsweise von Windows verknüpft und enthält völlig neue Konzepte, die die Windows-Plattform auf ideale Weise nutzen.

Don Jones ist Windows PowerShell MVP und Autor von Windows PowerShell 101 (ScriptingTraining.com). Sie erreichen Don Jones unter www.ScriptingAnswers.com.


 Hey, Scripting Guy!: Auch bei Skripts kommt es auf das &#196;u&#223;ere an
Hey, Scripting Guy!
Auch bei Skripts kommt es auf das Äußere an
Die Scripting Guys von Microsoft

Seit hunderten oder sogar schon tausenden von Jahren bestehen Philosophen und Weise darauf, dass beim Beurteilen von Menschen oder Dingen nicht rein auf Äußerlichkeiten geachtet wird. (Natürlich sollten Menschen überhaupt nicht beurteilt werden, schließlich liegt Schönheit im Auge des Betrachters.) Aber Sie wissen ja: Wahre Schönheit kommt von innen und nicht von außen, und Charakter ist entscheidender als Aussehen.
Dem können die Scripting Guys nur eines hinzufügen: Unsinn.
Sie haben richtig gehört, Unsinn. Die Scripting Guys geben gerne zu, dass die äußere Erscheinung in einer perfekten Welt keine Rolle spielt. Doch wir leben nicht in einer perfekten Welt. Wenn dem so wäre, würden Pommes frites und Schokoladeneis zu den zwei wichtigsten Nahrungsmitteln gehören. Ob es Ihnen gefällt oder nicht, Äußerlichkeiten sind wichtig. Das gilt ebenso für Ihre Skripts.
Die Scripting Guys wissen natürlich, dass nur wenige von der reinen Schönheit eines VBScripts, das in einem Befehlsfenster ausgeführt wird, zu Tränen gerührt sind. (Mit Ausnahme des Scripting Guy Dean Tsaltas vielleicht.)
Andererseits sind die Skriptersteller unseres Hightechzeitalters nicht mehr unbedingt auf Befehlsfenster angewiesen. Dank HTML-Anwendungen (HTAs) können Schreiber von Skripts mithilfe von DHTML grafische Benutzeroberflächen für ihre Skripts erstellen. Diese HTML-Fähigkeiten können auch zur Erstellung von Minianwendungen für Windows Vista™ eingesetzt werden. Dadurch könnte sich die bisher bekannte Skripterstellung für die Systemadministration grundlegend verändern. Aber wissen Sie was? Sobald das Gespräch auf grafische Benutzeroberflächen kommt, gelten herkömmliche Ansichten über oberflächliche Schönheit nicht mehr. Für Skripts, die in einer grafischen Umgebung ausgeführt werden, ist das Äußere ebenso wichtig wie Funktion und Leistung.
Aber das ist ein Problem. Schließlich sind wir Skriptersteller, was wissen wir schon über die Erstellung grafischer Benutzeroberflächen? Damit wäre die Sache dann wohl erledigt, oder?
Vielleicht. Dies hängt von den Umständen ab. Hat da gerade jemand gesagt: „Ohne die Scripting Guys wären wir aufgeschmissen?“
Wirklich. Das habe ich mir nicht eingebildet. Nun, vielleicht war es etwas genuschelt ...
Aber das macht nichts. Jemand hätte es zumindest sagen sollen, weil die Scripting Guys wirklich helfen wollen (ganz gleich, ob Sie Hilfe benötigen oder nicht).
Sehen wir uns zum Einstieg in die wunderbare Welt der grafischen Benutzeroberflächen eine einfache HTA an. (Weitere Informationen zum Erstellen von HTAs finden Sie im HTA-Entwicklercenter.)
In Abbildung 1 ist der erste Teil eines Desktopinformationssystems dargestellt. Wie Sie sehen, wurde zunächst in der oberen rechten Ecke des HTA-Fensters eine nette kleine Grafik erstellt. Die Idee ist, dass die HTA beim ersten Laden den Namen des angemeldeten Benutzers abfragt und diesen Namen zusammen mit den Computernamen über diesem Bild anzeigt. Dies ist erst der Anfang, später werden der HTA noch andere tolle Dinge hinzugefügt.
Abbildung 1 Der Anfang einer hübschen kleinen grafischen HTA-Schnittstelle
Abbildung 1 Der Anfang einer hübschen kleinen grafischen HTA-Schnittstelle
Wir sind uns nicht wirklich sicher, wer das ist. Wahrscheinlich einer von diesen Philosophen. Vielleicht Voltaire. Es klingt jedenfalls nach Voltaire.
Zugegeben, das ist eine einfache kleine Anwendung und ihre Schönheit würde wohl nicht einmal Scripting Guy Dean zu Tränen rühren. Doch Sie dient als nützliches Vorführungstool, dessen Grundkonzept sich auf unterschiedliche Situationen anwenden lässt. Schließlich arbeiten viele dieser Windows Vista-Minianwendungen nach einem ähnlichen Prinzip. Sie zeigen einfach eine Grafik (z. B. eine Skala oder Scheibe) an, über der Text geschrieben wird. So scheint es, als hätten Sie eine nette kleine Fortschrittsanzeige für verfügbaren Speicherplatz, wenn es sich letztendlich nur um eine generische Grafik handelt, über die dynamischer Text gelegt wurde.
Uns erscheint das eigentlich auch ziemlich sinnlos. Aber im Verlauf dieses Artikels dürften alle Unklarheiten beseitigt werden.
Es gibt nur ein Problem bei der Anzeige einer Grafik, über die dann Text geschrieben wird: Es funktioniert nicht. Unter Einsatz normaler HTML-Tags ergibt sich etwas Ähnliches wie in Abbildung 2. Das hatten wir uns eigentlich anders vorgestellt. Vielleicht hatte Nietzsche mit seiner Feststellung Recht, dass Menschen nie in der Lage sein würden Text über eine Grafik zu legen, zumindest nicht mit einer HTA.
Abbildung 2 Ein erster Versuch, Text zu überlagern
Abbildung 2 Ein erster Versuch, Text zu überlagern
Vielleicht lag Nietzsche aber doch falsch: Hat da nicht gerade jemand gesagt ... Aber lassen wir das jetzt lieber. Es stellt sich heraus, dass unser Ziel mit einfachem HTML nicht zu erreichen ist. Theoretisch könnten wir die Grafik in eine Hintergrundgrafik umwandeln und dann Tabellen und geschützte Leerzeichen und alle möglichen anderen Tricks einsetzen, damit der Text das Bild überlagert. Das Wort „theoretisch“ ist dabei allerdings wichtig. Außer in den einfachsten Fällen funktioniert diese Strategie nämlich nicht.
Es gibt aber eine wesentlich bessere Möglichkeit, attraktive Layouts in einer HTA oder Windows Vista-Minianwendung zu erstellen: Cascading Style Sheets, besser bekannt als CSS.
CSS wird zum Festlegen der Schriftarten, Ränder, Ausrichtungen, Farben und anderer Präsentationsaspekte eines Dokuments verwendet. (Das betrifft vor allem Webseiten. Da jedoch HTAs und Minianwendungen im Prinzip nichts anderes als Webseiten sind, ist CSS für sie gleichermaßen geeignet.) An dieser Stelle kann auf die Vielzahl an Möglichkeiten, die CSS bietet, nicht genau eingegangen werden. Weitere Informationen finden Sie jedoch in der praktischen und umfassenden CSS-Referenzdokumentation auf MSDN®. Im Rahmen dieses Artikels reicht die Feststellung, dass CSS zur exakten Steuerung des Layouts der HTA verwendet werden kann, einschließlich dem Überlagern eines Elements (des Texts) über ein anderes (die Grafik).
Im Folgenden wird erläutert, wie dabei vorzugehen ist. Werfen Sie zunächst einen Blick auf den Code für eine sehr einfache HTA in Abbildung 3.
Figure 3 Vielleicht kommen wir der ganzen Sache damit ja etwas näher ... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
Wie Sie sehen, ist das wirklich nichts Besonderes. Es gibt eine Window_OnLoad-Unterroutine, die (wie der Name schon sagt) immer dann automatisch ausgeführt wird, wenn die HTA gestartet oder aktualisiert wird. Auf diese Unterroutine wird gleich noch näher eingegangen. Außerdem gibt es zwei HTML-Elemente: die Grafik und ein Span-Element Wie Sie wahrscheinlich wissen, werden diese Tags zum Einfügen der Grafik mithilfe des Ausrichtungsattributs verwendet, um sicherzustellen, dass das Bild auf der richtigen Seite des Fensters angezeigt wird:
<img src=”test2.jpg” align=”right”>
Somit kommen wir zu den HTML-Tags für das Span-Element:
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
Hier wurde ein Span-Tag verwendet. Doch was ist ein Span-Tag eigentlich? Ein Span-Tag ist einfach ein benannter Bereich der HTA. Es ist ein begrenzter Abschnitt des HTA-Fensters, der programmatisch festgelegt werden kann (da dem Span-Tag die Kennung „UserData“ zugewiesen wurde). Nach dem Einrichten eines Span-Tags kann eine Unterroutine geschrieben werden, die dem Tag Text oder HTML-Code zuweist. Tatsächlich ist genau dies in der HTA erfolgt.
Aber wie gesagt, das wird später noch erörtert. Zuvor soll ein Blick auf den Stilparameter geworfen werden, der dem Span-Tag hinzugefügt wurde:
style=”position:absolute;left:770px;top:150px”
Dieser Parameter ist offensichtlich der Schlüssel für eine erfolgreiche Positionierung des dynamischen Texts über die Grafik. Tatsächlich werden an dieser Stelle drei getrennte Stilattribute festgelegt.
Position Der HTA wird mitgeteilt, dass die Position des Span-Tags absolut sein soll. Das bedeutet im Wesentlichen, dass sich das Span-Tag immer am selben Ort befinden soll, auch wenn das wie in diesem Fall heißt, dass der Text über die Fläche eines anderen Elements (z. B. der Grafik) geschrieben wird.
Left Legt einfach die Position des Span-Tags relativ zur linken Kante des HTA-Fensters fest. In diesem Fall soll das Span-Tag bei 770 Pixeln (770px) von links aus beginnen.
Top Diese Einstellung gleicht dem Left-Attribut, außer dass diesmal die Position des Span-Tags in Bezug auf die obere Kante des HTA-Fensters festgelegt wird. In diesem Fall werden vom oberen Rand des Fensters 150 Pixel (150px) nach unten gezählt, bevor das Span-Tag beginnt.
Woher wissen wir, dass die linke Seite der Spanne bei 770 Pixeln und der obere Rand bei 150 Pixeln festgelegt wird? Um die Wahrheit zu sagen, wir wussten es nicht. Wir haben die Grafik auf die Seite platziert, ein wenig herumgeraten und dem Span-Tag Werte für die Attribute „Top“ und „Left“ zugewiesen. Danach haben wir die HTA geöffnet und uns die Ergebnisse angesehen. Natürlich lag unsere Annnahme etwas daneben. Also wurden die Werte angepasst, die HTA aktualisiert und das Ergebnis erneut überprüft. Genau wie Goldlöckchen haben wir dann so lange herumprobiert, bis wir mit der Position zufrieden waren.
Hinweis: Sie kennen doch sicher Goldlöckchen und die drei Bären, die Geschichte von den Betten, den Stühlen und dem Brei, der zu heiß oder zu kalt war. Ob Goldlöckchen als große Philosophin zu bezeichnen ist, sei dahingestellt. Da sie jedoch keine Probleme damit hatte, in ein fremdes Haus einzubrechen, fremden Brei zu essen, auf fremden Stühlen zu sitzen und in fremden Betten zu schlafen, könnte man meinen, sie hatte auf jeden Fall ihre ganz eigene Philosophie.
Jedenfalls zeigt Abbildung 4, wie die HTA jetzt aussieht. Sie ist vielleicht kein Kunstwerk, aber wenn Picasso beispielsweise programmatisch Informationen über eine Grafik malt, sieht das auch nicht besser aus.
Abbildung 4 Stil ist wichtig
Abbildung 4 Stil ist wichtig
Vielleicht sollte an dieser Stelle erwähnt werden, wie Informationen programmatisch über eine Grafik gedruckt werden. Nun kommen wir endlich auf den Punkt: Es ist an der Zeit, über die Window_OnLoad-Unterroutine zu sprechen, die in Abbildung 5 gezeigt wird.
Figure 5 Window_OnLoad-Unterroutine (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
Bei genauerer Betrachtung dieser Unterroutine stellt sich heraus, dass es darüber gar nicht so viel zu sagen gibt. Zunächst wird eine Instanz des Wscript.Network-Objekts erstellt. Mithilfe dieser Codezeilen wird der Benutzername, die Domäne und der Computername abgerufen:
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
Das sind natürlich genau die Informationen, die in das HTA-Fenster geschrieben werden sollen. Es müssen lediglich die strUser- und strComputer-Variablen mit einem HTML-Tag kombiniert und dann die sich ergebende Zeichenfolge an die InnerHTML-Eigenschaft des Span-Tags zugewiesen werden.
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” _
  & strUser & “<br>” & strComputer & _
  “</font></p>”
Der Code sieht etwas kompliziert aus. Aber so schlimm ist es gar nicht. Er sieht einfach kompliziert aus, weil verschiedene Elemente in einer Zeichenfolge kombiniert werden. In einem Tag für den Anfangsabsatz wird zunächst angegeben, dass der Text im Absatz zentriert werden soll.
“<p align = ‘center’> “
Darauf folgt ein Tag für die Anfangsschrift, in dem angegeben wird, dass weißer Text mit der Schriftgröße 18 verwendet werden soll:
“<font style=’font-size:18pt;color:white’>”
Die Variable, die den Benutzernamen im Format Domäne/Benutzername enthält, lautet strUser. "<br>" fügt einen Zeilenumbruch ein. Dieser wird eingefügt, damit der Benutzername auf einer Zeile erscheint und der Computername auf der nächsten. Die Variable, die den Namen des Computers enthält, lautet strComputer. Schließlich werden die Tags für Abschlussschrift und Abschlussabsatz hinzugefügt:
“</font></p>”
Die einzelnen Codeteile sehen gar nicht so kompliziert aus, wie auf den ersten Blick zu vermuten war.
Auf diese Weise kann fast jedes beliebige HTML-Element positioniert werden. Angenommen es soll eine Schaltfläche unterhalb der Grafik positioniert werden. Fügen Sie dem HTA-Code dafür einfach Folgendes hinzu:
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
Dadurch ergibt sich die in Abbildung 6 aufgeführte HTA:
Abbildung 6 Was für eine schöne Schaltfläche
Abbildung 6 Was für eine schöne Schaltfläche
Auch hier müssen Sie wieder etwas experimentieren, bis die Schaltfläche richtig positioniert ist, doch das sollte nicht allzu lange dauern. Wenn Sie jedoch nicht vor etwas Rechenarbeit zurückschrecken, können Sie die korrekte Position bereits im Vorfeld bestimmen. Es müssen lediglich die Breite und Höhe jedes Objekts bekannt sein – diese können eventuell mithilfe des Stilparameters bestimmt werden – sowie die Breite und Höhe des HTA-Fensters. Standardmäßig, zumindest auf dem Testcomputer der Scripting Guys, sind HTAs ungefähr 1020 Pixel breit und 685 Pixel hoch (selbstverständlich können die Ergebnisse abweichen). Nehmen Sie diese Zahlen ggf. zunächst als Grundlage, und passen Sie sie auf Ihre Bedürfnisse an.
Diese Einführung in CSS ist offensichtlich viel zu kurz, doch mit ihrer Hilfe können Sie hoffentlich in Zukunft schönere Skripts erstellen. Philosophen mögen weiterhin darauf bestehen, dass die wahre Schönheit eines Skripts von innen kommt und nicht von außen. Überlegen Sie sich aber einmal Folgendes: Wer sind die größten Philosophen aller Zeiten? Stimmt: Platon, Sokrates, Aristoteles usw. Vor diesem Hintergrund möchten wir eine Frage stellen: Haben Sie je ein Foto von einem dieser Philosophen gesehen? Finden Sie es nicht auch interessant, dass es keine Fotos von den Menschen gibt, die behaupten, Schönheit spiele keine Rolle? Schon ziemlich seltsam. Darüber sollte einmal nachgedacht werden.

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-Skriptcenter. Besuchen Sie es unter www.scriptingguys.com.


 Exchange Fragen &amp; Antworten: Edge- und Hub-Transport-Funktionen, virtuelle Computer und mehr
Exchange Fragen & Antworten
Edge- und Hub-Transport-Funktionen, virtuelle Computer und mehr
KC Lemson and Nino Bilic

Im Artikel zu Exchange Fragen & Antworten vom Mai 2007 wurden die Probleme bei der Speicherung von PST-Dateien auf Netzwerkfreigaben erörtert. Das Team, das sich mit der Leistung von Windows Server befasst, startete kürzlich einen Blog und diskutierte
dieses Thema in allen technischen Einzelheiten, und wir wollten Ihnen diesen Link nicht vorenthalten. Nun zu den Fragen.

F: Muss bei der Bereitstellung von Microsoft Exchange Server 2007 die Edge-Transport-Serverfunktion bereitgestellt werden?

A: Nein, bei der Bereitstellung von Exchange Server 2007 muss Edge-Transport nicht bereitgestellt werden. Die zentralen Serverfunktionen (z. B. Mailbox, ClientAccess und Hub-Transport) können von einem einzelnen Computer ausgeführt werden, der Internet-E-Mail für Ihre Domäne annimmt und Antispam- und Antivirenprogramme ausführt.

F: Was sind die Unterschiede zwischen den Edge- und den Hub-Transport-Serverfunktionen? Welche Funktionen gehen verloren, wenn Edge nicht bereitgestellt wird?

A: Der Hauptzweck der Hub-Funktion ist das Weiterleiten von E-Mail innerhalb der Organisation und das Anwenden von Geschäftsrichtlinien auf diese Nachrichten. Bei der Hub-Funktion basieren Transportregeln auf Active Directory®-Objekten wie Benutzern, Verteilerlisten und so weiter. Mithilfe der Hub-Funktion können außerdem Haftungsausschlüsse zu Nachrichten oder Journalnachrichten hinzugefügt werden, die an Benutzergruppen gesendet werden, da diese Regeln auf einer Active Directory-Mitgliedschaft basieren sollten. Beispielsweise können Sie alle Nachrichten erfassen, die an DLOfUsersOnLitigationHold gesendet werden oder Haftungsausschlüsse zu ausgehenden E-Mails hinzufügen, die von DLOfMembersOfLegalTeam gesendet werden. Obwohl es möglich ist, Antispamagents auf dem Hub-Server auszuführen, sind sie nicht standardmäßig aktiviert. Deshalb müssen sie manuell durch Ausführen des Skripts „install-antispamagents“ im \scripts-Verzeichnis auf dem Server installiert werden.
Der Hauptzweck der Edge-Funktion ist das Weiterleiten von E-Mail an und von Organisationen ebenso wie der Nachrichtenschutz (Antispam-, Antivirus-, Inhalts- oder Anhangfilterung und so weiter). Die Antispamfunktionalität wird bei der Installation des Edge-Servers aktiviert. Eine der einzigartigen Features der Edge-Funktion besteht darin, dass sie nicht an eine Windows®-Domäne angeschlossen werden muss. Sie kann auf einer eigenständigen Windows Server®-Installation ausgeführt werden, die nicht Teil einer Windows-Domäne ist. Edge kann jedoch weiterhin als Teil der Exchange 2007-Organisation in der Gesamtstruktur Ihres Unternehmens verwaltet werden.
Das ist besonders in einem Umkreisnetzwerk vorteilhaft, in dem der Server unter Umständen in einer Arbeitsgruppe organisiert sein sollte, oder wenn eine separate Gesamtstruktur für die Computer im Umkreisnetzwerk vorliegt. Günstigerweise können Edge-Server, die in einer solchen Situation bereitgestellt werden, alle Aufgaben des Nachrichtenschutzes und des Weiterleitens von E-Mail zwischen dem Unternehmensnetzwerk und dem Internet durchführen und trotzdem genau wie alle anderen Komponenten der Exchange 2007-Systemverwaltung verwaltet werden.
In einem Edge-Server basieren Transportregeln auf SMTP-Adressen und nicht auf Active Directory-Objekten. Selbstverständlich können die SMTP-Adressen von Verteilerlisten oder Benutzern in Active Directory verwendet werden. Die Edge-Transportregeln sind in erster Linie eine Teilmenge der Hub-Transportregeln, wobei die Quarantäneaktion eine Ausnahme bildet, da sie nur auf Edge-Servern verfügbar ist.
Einige Funktionen von Edge-Servern sind durch Agents verfügbar, die Hub-Transport-Servern nicht zur Verfügung stehen: Entfernen von Anlagen und Umschreiben von Adressen Das Entfernen von Anlagen ist die Fähigkeit, selektiv möglicherweise gefährliche Anlagen mit Erweiterungen wie .exe oder .com zu entfernen. Der Agent zum Umschreiben von Adressen ermöglicht das Umschreiben von E-Mail-Headern. Ihre Domäne und standardmäßigen SMTP-Proxyadressen auf Benutzerkonten lauten also beispielsweise @contoso.com, Nachrichten ins Internet scheinen allerdings von @northwindtraders.com zu kommen. Außerdem führen Edge-Server Routing nur basierend auf Domäne oder Adressbereich durch. Wenn Sie daher denselben SMTP-Adressbereich für Exchange und ein anderes E-Mail-System verwenden, müssen Sie die Weiterleitung entweder auf dem Hub-Server oder gemeinsam mit dem Agent zum Umschreiben von Adressen durchführen.
Eine andere wichtige Überlegung ist die Frage, ob ein Exchange 2007-Server direkt mit dem Internet verbunden ist (sei es über die Hub- oder die Edge-Serverfunktion). Anders ausgedrückt, sind Verbindungen zu Port 25 auf dem MX-Datensatz Ihrer Domäne auf eine Weise mit Exchange 2007 verbunden? Unter Umständen verwenden Sie bereits ein SMTP-Gateway, einen Virenschutz oder eine andere Lösung im Internet, die E-Mail von Ihrer Domäne annimmt und dann innerhalb des Unternehmensnetzwerks an Exchange weiterleitet. Wenn Sie Edge- oder Hub-Server mit direkter Verbindung zum Internet bereitstellen, wird eine der raffiniertesten Features von Exchange 2007 von Vorteil sein: die Aggregation von Listen sicherer Adressen. Wenn Benutzer Absender zu ihrer Liste sicherer Adressen in Microsoft Outlook® hinzufügen (normalerweise für Newsletter oder E-Mail von Einzelhändlern), werden diese Listen mithilfe der Aggregation von Listen sicherer Adressen sicher an die Edge- oder Hub-Funktionen weitergeleitet, sodass Nachrichten von diesen Absendern den Inhaltsfilter umgehen. Was für einen Benutzer Spam ist, ist für einen anderen ein nützlicher Newsletter. Daher findet die Aggregation von Listen sicherer Adressen auf individueller Basis statt. Näheres über die Funktionsweise erfahren Sie in der Dokumentation zu Exchange 2007.
Wenn in Ihrer Bereitstellung ein Server mit der Hub-Funktion Internet-E-Mails für Ihre Domäne akzeptieren soll, dann sollten Sie einige Dinge beachten. Stellen Sie zunächst sicher, dass eine gute Firewall oder Portfilterung eingerichtet wurde, damit der Server lediglich Verbindungen auf den erforderlichen Ports, z. B. Port 25 empfängt. Denken Sie außerdem daran, Antispamagents zu installieren, da diese nicht standardmäßig installiert oder aktiviert sind. Da das am weitesten verbreitete Bereitstellungsszenario des Hub-Servers innerhalb des Unternehmensnetzwerks ist, werden zunächst keine anonymen Verbindungen zugelassen. Sie müssen daher die AnonymousUsers-Berechtigungsgruppe auf dem Port 25-Empfangsconnector aktivieren. Außerdem sollten Sie die Aggregation von Listen sicherer Adressen aktivieren und deren regelmäßige Ausführung planen. Wenn Benutzer die Listen sicherer Adressen in ihren Postfächern aktualisieren, wird die Inhaltsfilterung für sichere Absender umgangen. Weitere Details stehen auf unserem Blog zur Verfügung.
Der folgende Code zeigt einen AT-Befehl, der alle Postfächer täglich um 23:00 Uhr auf allen Servern mithilfe einer Stapelverarbeitungsdatei namens SafeList.bat aktualisiert:
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
Dieser Code zeigt den Inhalt der Datei SafeList.bat:
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
Weitere Informationen zur Überprüfung Ihrer Einstellungen finden Sie in der Dokumentation zu Exchange 2007.

F: Nach dem Start meines Virtual PC-Abbilds mit Exchange treten Probleme beim Kontaktieren des Verzeichnisses bzw. des LDAP-Servers auf. Die Telnetverbindung zu Port 389 funktioniert, und alle Dienste arbeiten. Woran liegt das?

A: Dieses Problem hatte ich im letzten Jahr bei der Tech•Ed. Ich hatte zu Demonstrationszwecken eine Kopie von Virtual PC von einem Computer im Büro auf meinen Laptop übertragen. Die versammelte Presse wollte nämlich wegen der im darauf folgenden Monat anstehenden Veröffentlichung von Exchange 2007 Beta 2 entsprechende Artikel veröffentlichen.
Ich hatte das Produkt bereits unzählige Male vorgeführt und wusste, dass es zuverlässig war. Deshalb bereitete ich mich nicht übermäßig vor. Sie können sich vorstellen, wie ich ins Schwitzen geriet, als ich am Montag morgen meinen Virtual PC startete, nur wenige Stunden vor der ersten Vorführung, und der Build absolut keine Verbindung mit einem Domänencontroller zuließ. Zum Glück hatte ich viele wirklich schlaue Leute um mich, und wir konnten das Problem schnell aufdecken.
Das Problem bei der Tech•Ed bestand darin, dass ich Virtual PC auf meinem extrem langsamen Laptop ausführte. Ursache des Problems war eine Racebedingung zwischen DNS und Active Directory. Der DNS-Server auf dem Abbild war so konfiguriert, dass er in Active Directory integriert war, doch aufgrund der Reihenfolge, in der die Dienste auf dem Abbild geladen wurden (und der fehlenden Geschwindigkeit meines Laptops), waren die benötigten Verzeichnisdienste noch nicht gestartet, als der DNS-Server versuchte, Active Directory zu kontaktieren.
Diese Situation kann auf jedem Server auftreten, bei dem DC und Exchange auf demselben Computer installiert sind (dabei muss es sich nicht um ein virtualisiertes Abbild handeln). Doch das Auftreten in einer virtualisierten Umgebung ist wahrscheinlicher, da es hier eine zusätzliche Verlangsamung gibt – vor allem mit einem wenig leistungsstarken Laptop wie meinem.
Ein ähnliches Problem tritt auch bei Virtual PC-Abbildern auf, die zwischen zwei Computern kopiert werden, insbesondere wenn sich einer dieser Computer in einem anderen Netzwerk befindet. Wenn Ihnen genau das passiert ist, überprüfen Sie die IP-Adresse des Betriebssystems im Abbild. Eventuell liegt eine feste IP-Adresse aus dem alten Netzwerk vor. Durch Aktualisieren erhalten Sie eine IP vom neuen Netzwerk. Unter Umständen hilft das bereits.
Das Problem kann vermieden werden, wenn der DNS-Server auf dem Gast nicht Active Directory-integriert und DNS sowohl auf dem Host als auch auf dem Gast installiert ist. Lassen Sie den Gast unbekannte Datensätze an den Host weiterleiten und den Host wiederum an den betreffenden DNS-Server. Wenn das Abbild gestartet wird und versucht, die DNS-Datensätze zu aktualisieren, ist es dann weniger fehleranfällig.

F: Das Exchange 2007-Setup scheint sich von früheren Exchange-Versionen erheblich zu unterscheiden. Wie funktioniert es genau?

A: Ja, es gibt in der Tat verschiedene Stufen des Exchange 2007-Setup. Im Folgenden finden Sie einen allgemeinen Überblick über die Funktionsweise des Prozesses.

Wenn Sie setup.exe das erste Mal ausführen, erhalten Sie Informationen zu Links für den Großteil von Voraussetzungen, die vor Installation der eigentlichen Serverfunktionen installiert werden müssen. Nach Installation aller dieser Voraussetzungen wird der Link zum Installieren von Microsoft Exchange aktiviert (siehe Abbildung 1).
Abbildung 1 Installationslink ist nach Installation aller Voraussetzungen verfügbar
Abbildung 1 Installationslink ist nach Installation aller Voraussetzungen verfügbar
Wenn Sie setup.exe vom Netzwerk ausgeführt und auf den Installationslink geklickt haben, werden die zentralen Setupdateien in den Ordner %TEMP%\ExchangeServerSetup\ auf dem lokalen Computer kopiert. Danach wird der Setup-Assistent gestartet.
Der Setup-Assistent führt Sie durch die unterschiedlichen Auswahloptionen, darunter Lizenzvereinbarung, Fehlerberichterstattung und Installationstyp (dort können Sie die zu installierenden Serverfunktionen auswählen). Die angezeigten Assistentenseiten unterscheiden sich je nach Vorhandensein und Zustand der aktuellen Exchange-Organisation.
Nach Abschluss des Assistenten führt Setup eine Bereitschaftsprüfung durch. Dabei handelt es sich um eine optimierte Version des Microsoft Exchange Server Best Practice Analyzer (BPA), der sich standardmäßig mit dem Internet verbindet, um die aktuellste erforderliche XML-Datei herunterzuladen. Dadurch bietet sich die Möglichkeit, die Voraussetzungen regelmäßig zu aktualisieren oder Probleme zu beheben, die das Exchange-Team seit Auslieferung des Produkts entdeckt hat. Wenn die Voraussetzungsprüfung abgeschlossen ist, haben Sie die Möglichkeit, die Ergebnisse zu überprüfen und fortzufahren. Andernfalls werden Probleme angezeigt, die unter Umständen behoben werden müssen, bevor Sie mit dem Setup fortfahren können. Wenn die Voraussetzungsprüfung des Servers fehlschlägt, können Sie die Überprüfung in den meisten Fällen wiederholen.
Nach Bestehen der Voraussetzungsprüfung wird die Schaltfläche „Installation“ angezeigt, mit der Sie die Installation der zuvor ausgewählten Funktionen beginnen können. Es werden lediglich die Dateien für die zuvor ausgewählten Funktionen kopiert und installiert.
Am Ende des Setups können Sie die Exchange-Verwaltungskonsole starten und Exchange 2007-Aktualisierungen installieren, die möglicherweise verfügbar sind.

KC Lemson ist User Experience Manager für Exchange Server. Ihr Onlinebankkonto wurde vorübergehend gesperrt.
Nino Bilic ist Supportability Program Manager für Exchange Server. Er hat seiner Kreditkarte vor Kurzem eine zweite E-Mail-Adresse hinzugefügt.


 Sicherheit auf dem Pr&#252;fstand: Tools zum Verwalten von ACLs
Sicherheit auf dem Prüfstand
Tools zum Verwalten von ACLs
Jesper M. Johansson

In Windows bieten Zugriffssteuerungslisten (Access Control Lists, ACLs) eine äußerst detaillierte Steuerung der Fähigkeiten von Benutzern und Prozessen beim Verwenden von Ressourcen wie Dateien und Ordnern. Das Verwalten von ACLs kann eine der komplexeren Aufgaben im Zusammenhang mit dem Sicherheitsschutz für die Systeme Ihrer Benutzer sein. Glücklicherweise gibt es eine Reihe nützlicher Dienstprogramme,
die beim Automatisieren und Vereinfachen von Aufgaben im Zusammenhang mit Berechtigungen und ACLs helfen.
Die meisten Leser werden mit dem cacls.exe-Tool vertraut sein, das in jeder Version von Windows NT® seit der Erstveröffentlichung enthalten ist. Wenn Sie cacls.exe in Windows Vista™ ausführen, erhalten Sie die folgende Begrüßungsnachricht:
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
Zusätzlich zu den Updates bei ACLs in Windows Vista (die im TechNet Magazin vom Juni 2007 erörtert wurden – siehe technetmagazine.com/issues/ 2007/06), hat Microsoft ebenfalls verschiedene Tools zum Verwalten von ACLs aktualisiert. Interessanterweise handelt es sich bei den wichtigsten Updates um Befehlszeilentools.
Icacls.exe ist neu in Windows Vista (und auch in der Vorgängerversion Windows Server® 2003 Service Pack 2). Icacls.exe soll cacls.exe zu einem späteren Zeitpunkt ersetzen. Wie Sie vielleicht wissen, wurde cacls.exe nie vollständig aktualisiert, um die fein abgestimmten Berechtigungen zu unterstützen, die mit Windows® 2000 eingeführt wurden. Es handelt sich also hierbei um ein Update, das etwa sieben Jahre überfällig ist.
Obwohl cacls.exe veraltet ist, umfasst es überraschenderweise einige neue Features. Erstens kennt das Tool Verknüpfungspunkte und symbolische Verknüpfungen und kann sie übertragen. Zweitens kann es eine ACL mithilfe einer SDDL-Zeichenfolge (Security Description Definition Language) sowohl drucken als auch einrichten.
Doch trotz der Updates bei cacls.exe benötigen Sie die Funktionen von icacls.exe.

Speichern und Wiederherstellen von ACLs
Einer meiner nie erfüllten Wünsche der letzten 10 Jahre war die Möglichkeit, eine ACL zu speichern, sodass sie zu einem späteren Zeitpunkt wiederhergestellt werden kann. Dies ist einer der komplexesten Vorgänge, die Sie bei ACLs durchführen können. Mit Ausnahme bestimmter Sonderfälle ist es unwahrscheinlich, dass Sie genau dasselbe Ergebnis erhalten, das Sie erhalten hätten, wenn Sie die ACLs nicht zerstört hätten. Dennoch kann diese Funktion recht nützlich sein.
Bevor dargelegt wird, wie ACLs gespeichert oder wiederhergestellt werden, soll zunächst erläutert werden, warum dies so schwer ist. Angenommen Sie haben eine Hierarchie, die Benutzerdaten für Studenten an einer örtlichen Hochschule enthält. Sie speichern die ACL am 1. Februar. Am 17. April stellen Sie fest, dass die ACL beschädigt wurde, und begeben sich daran, sie aus der gespeicherten Kopie wiederherzustellen. Welche Komplikationen könnte es bei diesem Vorgang geben?
Erstens hat das neue Quartal am 2. April begonnen. Ungefähr 15 Prozent der Studenten haben ihr Studium abgeschlossen, sodass ihre Verzeichnisse nicht mehr existieren. Daher liegen in der Sicherungsdatei ungültige ACLs vor. Außerdem hat eine Reihe neuer Studenten (weitere 15 Prozent) im neuen Quartal ihr Studium aufgenommen. Diese verfügen jetzt über Basisverzeichnisse, aber keine ACLs in der Sicherungsdatei. Wie sollten ihre ACLs aussehen? Dann gibt es natürlich noch die 70 Prozent vorhandener Studenten, doch viele haben neue Dateien und Ordner erstellt und andere gelöscht. Die gelöschten Elemente können ignoriert werden, doch wie lassen sich die neu erstellten Ordner konfigurieren? Was geschieht, wenn ein Student am 4. März beschlossen hat, einen Ordner für seine Freunde freizugeben? Wird dies blockiert, wenn Sie die ACL wiederherstellen?
Das Speichern und Wiederherstellen von ACLs ist keinesfalls so einfach, wie es oft dargestellt wird. Sie müssen dabei äußerst vorsichtig vorgehen. Es ist möglich und sogar wahrscheinlich, dass es dadurch zu einem nicht definierten Verhalten kommt. Das Wiederherstellen von ACLs ist auf jeden Fall der letzte Ausweg. Je länger die letzte Sicherung zurückliegt, desto wahrscheinlicher ist es, dass bei einer Wiederherstellung etwas zerstört wird.
Wenn Sie diese Funktion trotzdem ausprobieren möchten, führen Sie icacls.exe mit dem /save-Schalter aus:
icacls <target> /save acls.bin /t
Dabei werden die ACLs in einer Datei namens „acls.bin“ gespeichert. Die Datei enthält eine Zeile für jedes Objekt mit einer ACL, gefolgt von einer Zeile, die die ACL in SDDL spezifiziert. Mithilfe des /t-Schalters wirkt sich der Befehl auf das von Ihnen bestimmte Objekt und alle Objekte und Container darunter aus.
Die Speicherfunktion ist eine willkommene Erweiterung des Toolkit, doch sie weist einige Fehler auf. So speichert sie beispielsweise nur die freigegebene Zugriffssteuerungsliste (DACL), nicht die Systemzugriffssteuerungsliste (SACL). Wenn eine SACL vorhanden ist, speichert die Funktion einen unechten Wert, der darauf hinweist, aber von der SACL an sich wird kein Teil gespeichert.
Außerdem führt die Art und Weise, wie die ACL gespeichert wird, zu einem interessanten Problem. Bevor Sie die gespeicherte ACL in einem Texteditor Ihrer Wahl öffnen, sollten Sie sich unbedingt an Folgendes halten:
Bearbeiten Sie die gespeicherte ACL nicht!
Wenn die Datei mit der gespeicherten ACL in einem Texteditor geöffnet wird, wird sie anscheinend als Unicode (UTF-16)-formatierte Textdatei angezeigt. Tatsächlich trifft dies fast zu. Das könnte Sie dazu verleiten, die Datei zu bearbeiten und in einem Texteditor zu speichern. Tun Sie dies auf keinen Fall!
Wenn Sie die Datei, die die gespeicherten ACLs enthält, in einem Texteditor öffnen und dann speichern, können Sie die ACLs aus dieser Datei nicht wiederherstellen. Es stellt sich nämlich heraus, dass es sich nicht um eine Unicode-Textdatei handelte. Eine solche Datei muss mit dem aus 2 Bytes bestehenden 0xfffe beginnen. Wenn Sie die Datei mit einem Texteditor wie Editor speichern, wird dieses Kennzeichen in die ersten 2 Bytes gesetzt. Das icacls.exe-Tool erwartet jedoch, dass die ACL-Daten bei Byte 0 in der Datei beginnen. Daher kann das Tool die ACLs in der Datei nicht analysieren, da es erwartet, dass die ersten zwei Bytes Teil der Zeichenfolge sind, die das Objekt angibt, an dem der Befehl durchgeführt werden soll. Ihre Sicherungsdatei ist unbrauchbar.
Microsoft ist sich dieses Problems bewusst, doch da es erst sehr spät im Betazyklus für Windows Vista gemeldet wurde, wurde dieser Fehler nicht vor der Veröffentlichung behoben. Bisher ist nicht bekannt, wann oder ob der Fehler überhaupt behoben wird. Daher ist es am besten, gespeicherte ACLs nicht zu bearbeiten. Wenn dies unbedingt erforderlich ist, speichern Sie die Datei als BIN-Datei, und verwenden Sie einen Hexadezimaleditor, beispielsweise Ihre bevorzugte Entwicklungsumgebung.
Wenn Sie eine ACL mit dem /save-Schalter gespeichert haben, können Sie sie mithilfe von icacls.exe mit dem /restore-Schalter wiederherstellen. Der Wiederherstellungsbefehl verwendet in seiner einfachsten Form diese Syntax:
icacls <directory> /restore acls.bin
Das Wiederherstellungsverfahren wirkt sich nicht auf Dateien aus. Sehen Sie sich dazu die Befehlsfolge in Abbildung 1 an. Durch Verweisen von icacls.exe auf eine Datei wird eine Speicherdatei erstellt. Dann wird die Wiederherstellung versucht, indem /save einfach durch /restore ersetzt wird. Dies funktioniert nicht, da sich der Wiederherstellungsbefehl nur auf Verzeichnisse auswirkt. Die Dateien, die geändert werden sollen, sind bereits in der acls.bin-Datei angegeben. Zum Wiederherstellen der ACL muss auf das Verzeichnis statt auf die Datei verwiesen werden. Die erfolgt im letzten Befehl, in dem „.“ als das Objekt angegeben wird, an dem die Funktion durchgeführt werden soll.
Figure 1 Speichern und Wiederherstellen von ACLs (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
Es ist außerdem zu beachten, dass der Wiederherstellungsbefehl erweitert ausgeführt werden muss. Sie können den Speicherbefehl von einer Eingabeaufforderung für einen Administrator mit niedrigen Rechten oder sogar als Standardbenutzer ausführen, solange Sie das Recht haben, die ACL zu lesen. Zum Wiederherstellen der ACL benötigen Sie jedoch ein vollständiges, unverfälschtes Administratortoken.

Ersetzen von SIDs
Ein weiteres sehr nützliches Feature von icacls.exe ist die Möglichkeit, die Berechtigungen für einen Benutzer durch Berechtigungen für einen anderen Benutzer zu ersetzen. Dies geschieht während der Wiederherstellung mit dem /substitute-Schalter. In der Dokumentation für den Ersetzungsschalter wird eine SID gefordert, doch dann wird erläutert, dass es sich auch um einen normalen Benutzernamen handeln kann. Daher funktioniert die in Abbildung 2 dargestellte Folge.
Figure 2 Ersetzen von SIDs während der Wiederherstellung (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
Das Ergebnis ist also dieselbe ACL wie zuvor, doch der ACE, der Berechtigungen für „foo“ angegeben hat, gibt sie nun stattdessen für „bar“ an.

Ändern eines Besitzers
Das chown-Tool ist seit Jahren wichtiger Bestandteil von UNIX-Systemen. In Windows gab es ursprünglich keine integrierte Möglichkeit, den Besitzer eines Objekts zu ändern. Dann wurde das setowner-Tool im Resource Kit entwickelt. Später gab es das takeown.exe-Tool in Windows NT 4.0, doch dieses Dienstprogramm ermöglichte es dem Benutzer nur, den Besitz zu übernehmen. Der Betreffende konnte anderen das Besitzrecht nicht gewähren, es sei denn, er verfügte über das entsprechende Kennwort. Jetzt bietet icacls.exe die integrierte Möglichkeit, für Objekte, bei denen Sie diese Berechtigung haben, den Besitzer festzulegen.
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
Leider kann icacls.exe den Besitzer eines Objekts nicht anzeigen. Es gibt von der Befehlszeile aus keine Möglichkeit zu sehen, wer der Besitzer eines Objekts ist. Zudem wird der Besitzer des Objekts nicht gespeichert, wenn Sie die ACL für ein Objekt speichern.
Bei icacls.exe ist zudem ein Fehler vorhanden, da SeTakeOwnershipPrivilege nicht aufgerufen wird, um den Besitzer zu ändern. Wenn Sie das Recht haben, den Besitzer eines Objekts auf der Grundlage der ACL zu ändern, funktioniert icacls.exe wie vorgesehen. Doch wenn Sie Administrator, aber nicht berechtigt sind, den Besitzer auf der Grundlage der ACL des Objekts zu ändern, können Sie icacls.exe aufgrund dieses Fehlers nicht dazu verwenden. In diesem Fall müssen Sie das takeown.exe-Tool verwenden, das SeTakeOwnershipPrivilege aufruft, aber Sie können nur den Besitzer in Ihr Konto oder die Administratorengruppe und nicht in ein beliebiges Konto umändern:
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
Weiterhin ist das subinacl-Tool zu erwähnen, das im Microsoft-Downloadcenter heruntergeladen werden kann und über einen setowner-Schalter verfügt. Subinacl arbeitet in vielen Fällen intuitiver als icacls, ist aber komplizierter in der Verwendung.

Suchen von Dateien für einen bestimmten Benutzer
Icacls bietet eine weitere nützliche Funktion: Das Tool kann für die Suche nach Dateien eingesetzt werden, die Berechtigungen für bestimmte Benutzer enthalten. Beispiel:
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
Dies könnte hilfreich sein, um festzustellen, worauf ein bestimmter Benutzer Zugriff hat.

Zurücksetzen und Ändern von ACLs
Wenn eine ACL beschädigt oder zerstört wurde, bietet icacls.exe eine Möglichkeit, sie zurückzusetzen, sodass sie vom übergeordneten Element erbt. Dies wäre beim Zero-Day-Sicherheitsproblem äußerst nützlich gewesen, das im Herbst 2006 eintrat. Eine Methode, das Problem in einer Windows-Komponente zu begrenzen, bestand darin, allen den Zugriff auf das Objekt zu verweigern. Dies war relativ einfach, doch das Entfernen des Zugriffssteuerungseintrags (Access Control Entry, ACE) war mithilfe der in Windows XP und Windows Server 2003 integrierten Tools fast unmöglich. Doch in Windows Vista kann einfach der folgende Befehl ausgeführt werden:
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
Icacls.exe verfügt selbstverständlich über alle standardmäßigen grant-/deny-/remove-Vorgänge. Das einzige wirklich neue Element in dieser Liste ist „remove“. Mithilfe dieses Schalters können Sie alle allow-ACEs, alle deny-ACEs oder beides für einen bestimmten Benutzer aus einem bestimmten Objekt oder einer Hierarchie entfernen. Abbildung 3 zeigt Beispiele für einige andere grant-, remove- und deny-Vorgänge.
Figure 3 Grant-, deny- und remove-Vorgänge (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
Die Möglichkeit, nur die deny-ACEs zu entfernen, kann nützlich sein, wenn Sie einer bestimmten Gruppe oder einem Benutzer Zugriff auf ein Objekt gewähren möchten.

Festlegen von Integritätsebenen
Icacls.exe bietet auch die Möglichkeit, Integritätsebenen anzuzeigen und festzulegen. Windows Vista unterstützt die Angabe von Integritätsbeschriftungen bei Objekten. Dies erfolgt mit dem Befehlszeilentool icacls.exe:
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
Beachten Sie, dass icacls.exe eine Integritätsbeschriftung nur anzeigt, wenn eine solche für das Objekt ausdrücklich festgelegt wurde. Bei den meisten Dateien ist dies nicht der Fall.
Außerdem kann icacls.exe überprüfen, ob ein Objekt über eine kanonische ACL verfügt. Wie bereits erwähnt, stellen manche Drittanbietertools ACEs in der falschen Reihenfolge in ACLs. Mithilfe von icacls.exe können solche Probleme, wie hier dargestellt, überprüft und behoben werden:
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

ACL-Benutzeroberfläche
Die ACL-Benutzeroberfläche wurde gegenüber der Benutzeroberfläche in Windows XP leicht geändert. In Abbildungen 4 und 5 ist der Dialog auf der ACL-Benutzeroberfläche in Windows XP beziehungsweise Windows Vista dargestellt.
Abbildung 4 Dialog auf der ACL-Benutzeroberfläche in Windows XP
Abbildung 4 Dialog auf der ACL-Benutzeroberfläche in Windows XP
Abbildung 5 Dialog auf der ACL-Benutzeroberfläche in Windows Vista
Abbildung 5 Dialog auf der ACL-Benutzeroberfläche in Windows Vista
Wie Sie sehen, wurden hier einige Änderungen vorgenommen. Zum einen ist im Dialog das Objekt, an dem Sie arbeiten, deutlich zu erkennen. Dies kann nützlich sein, wenn Sie an mehreren Objekten gleichzeitig arbeiten. Zweitens ist unten ein Hyperlink zu einer Hilfe vorhanden. Als größte Änderung wurden die Schaltflächen „Hinzufügen“ und „Entfernen“ entfernt und durch die Schaltfläche „Bearbeiten“ ersetzt. Diese dient zur Unterstützung der Benutzerzugriffssteuerung (User Access Control, UAC) in Windows Vista. Wie anhand des Schildsymbols auf der Schaltfläche ersichtlich ist, ist der Benutzer, der diesen Dialog gestartet hat, nicht zum Bearbeiten der ACL berechtigt und muss daher vor dem Bearbeiten von Berechtigungen erweiterten Zugriff erhalten. Beachten Sie, dass dies keine standardmäßige Einstellung ist, wenn Sie einen Ordner im Stamm von Laufwerk C: erstellen und sofort die Eigenschaften überprüfen. Als Besitzer des Ordners haben Sie implizite Berechtigungen zum Bearbeiten der ACL. Das Schildsymbol wird in diesem Fall nicht angezeigt. Das Schildsymbol stellt einen COM-Moniker dar, also einen Mechanismus, der zum Starten einer Benutzeraufforderung für einen Teil eines Prozesses dient, der ausgeführt wird. Wenn Sie auf die Schaltfläche „Bearbeiten“ klicken, wird der Ihnen bekannte Erweiterungsdialog angezeigt, und wenn Sie im Erweiterungsdialog auf „Weiter“ klicken, wird ein Dialog angezeigt, der fast identisch mit dem in Windows XP durch Klicken auf die Schaltfläche „Hinzufügen“ angezeigten Dialogs ist. In der ACL-Benutzeroberfläche tritt dieses Doppeldialogkonzept an mehreren Stellen auf: Ein Dialog wird so lange angezeigt, bis eine Erweiterung durchgeführt wurde. Wenn dies erfolgt ist, wird der vertraute Dialog aus früheren Versionen von Windows angezeigt.
Wenn Sie auf die Schaltfläche „Erweitert“ und anschließend auf die Registerkarte „Überwachung“ klicken, wird immer eine Erweiterungsschaltfläche angezeigt, wie in Abbildung 6 dargestellt. Sie können die Überwachung nicht ohne Erweiterung ändern, selbst wenn Sie vollständige Kontrolle über das Objekt haben und der Besitzer sind. Dies ist darauf zurückzuführen, dass die Möglichkeit zum Ändern einer Objekt-SACL mithilfe der SE_SECURITY_NAME-Berechtigung geregelt wird, was bei den Tools der grafischen Benutzeroberfläche als „Verwalten von Überwachungs- und Sicherheitsprotokollen“ bezeichnet wird. Nur Administratoren verfügen standardmäßig über dieses Recht. Die Berechtigung wird jedoch bei einem Administrator im Administratorbestätigungsmodus (Admin Approval Mode) entfernt (wenn UAC aktiviert ist), sodass die Erweiterung erforderlich ist, selbst wenn Sie Administrator sind.
Abbildung 6 Zum Modifizieren von Überwachungseinstellungen in Windows Vista ist immer eine Erweiterung erforderlich.
Abbildung 6 Zum Modifizieren von Überwachungseinstellungen in Windows Vista ist immer eine Erweiterung erforderlich.
Ein letzter Hinweis zu den Erweiterungsanforderungen beim Ändern von ACLs: Alle diese Anweisungen hängen davon ab, dass Sie die Benutzerzugriffssteuerung nicht deaktivieren. Wenn Sie UAC deaktivieren, wird der Zustand wie in Windows XP mit Ausnahme der anders aussehenden Dialoge wiederhergestellt. Es ist jedoch keine Erweiterung erforderlich, vorausgesetzt Sie melden sich als Administrator an, da Ihr Token jetzt immer die Administratoren-SID enthält.

Weitere Tools
Icacls.exe ist ein sehr nützliches Tool und eine erhebliche Verbesserung gegenüber cacls.exe, doch es sind immer noch einige Unzulänglichkeiten vorhanden. Der vielleicht größte Mangel liegt darin, dass nur auf Objekte zugegriffen werden kann, wenn es sich um Dateien und Verzeichnisse handelt. Windows Vista nimmt im Vergleich zu Windows XP geringe Änderungen an den ACLs anderer Objekte vor, aber in bestimmten Fällen sollte es Ihnen möglich sein, ACLs in einem Dienst, einem Registrierungsschlüssel oder sogar einem Active Directory®-Objekt zu verwalten.
Wenn Sie ein Anhänger von Befehlszeilen sind, brauchen Sie dazu subinacl.exe. Subinacl.exe ist in den Supporttools enthalten und auch als Download verfügbar.
Es muss allerdings angemerkt werden, dass die Verwendung von subinacl.exe nicht ganz einfach ist. Bisweilen scheint das Tool sogar ziemlich beschränkt zu sein. Subinad.exe dagegen ist ein unglaublich leistungsfähiges Tool zum Verwalten der Zugriffssteuerung. Jeder Poweradministrator benötigt dieses Tool.

Registrierungs-ACLs
Bei den Registrierungs-ACLs hat es genau wie bei den Dateisystem-ACLs Änderungen gegeben. Die Änderungen sind jedoch vom Umfang her sehr viel geringer als beim Dateisystem. Der augenfälligste Unterschied gegenüber früheren Versionen von Windows besteht darin, dass aufgrund der veralteten Poweruserfunktion fast keine Poweruser-ACEs mehr vorhanden sind. Poweruser haben nicht mehr Berechtigungen als andere Benutzer. Es ist jedoch ein Beweis für die Komplexität von ACLs, dass nicht alle ACEs für Poweruser abgeschafft wurden. Ein paar wurden leider übersehen.
In den ACLs in der Registrierung wird Ihnen an einigen Stellen ein ACE für eine SID mit der Bezeichnung RESTRICTED auffallen. Dies ist zwar keine Neuerung in Windows Vista, aber trotzdem eine interessante und oft falsch verstandene SID. Die RESTRICTED-SID kennzeichnet einen Prozess, der ein eingeschränktes Token enthält. Ein eingeschränktes Token wird mithilfe eines besonderen Features der CreateRestrictedToken-API erstellt. Aus einem solchen Token resultieren eine oder mehrere einschränkende SIDs, die in einer separaten Zugriffsüberprüfung verwendet werden. Angenommen ein Prozess wird mit einem eingeschränkten Token ausgeführt. Wenn dieser Prozess versucht, auf ein Objekt mit einem ACE für die RESTRICTED-SID zuzugreifen, führt Windows zwei Zugriffsüberprüfungen durch. Die erste ist die normale Zugriffsüberprüfung. Die zweite funktioniert genau wie erste, wird aber nur bei den eingeschränkten SIDs im Token durchgeführt. Beide Zugriffsüberprüfungen müssen erfolgreich ausgeführt werden.
Derzeit gibt es mehrere ACLs, die die RESTRICTED-SID verwenden, speziell in der Registrierung. Der Screenshot einer solchen ACL ist in Abbildung 7 dargestellt.
Abbildung 7 Die Registrierungs-ACLs umfassen an mehreren Stellen einen ACE für RESTRICTED.
Abbildung 7 Die Registrierungs-ACLs umfassen an mehreren Stellen einen ACE für RESTRICTED.
Derzeit nutzen nur wenige Prozesse die eingeschränkte Tokenfunktion, besonders im Zusammenhang mit einschränkenden SIDs. Ein Beispiel für einen Prozess, der diese Funktion verwendet, ist der Dienstprozess, der die Windows Firewall, das Basisfiltermodul und den Diagnoserichtliniendienst hostet. Er verwendet auch ein Token mit eingeschränktem Schreiben. Auf Grundlage meiner Ermittlungen verwenden derzeit nur neun Dienste RESTRICTED-Tokens und Tokens mit eingeschränktem Schreiben in Windows Vista.
Wie bei Neuausgaben vorheriger Versionen von Windows sollte in Bezug auf Registrierungsberechtigungen sehr vorsichtig vorgegangen werden. Mit Ausnahme von außergewöhnlichen, sehr speziellen Umständen sollten Berechtigungen in der Registrierung nicht geändert werden. Aufgrund des komplizierten Vererbungsmodells und der vertraulichen Daten in der Registrierung erhöht sich die Wahrscheinlichkeit eines schwerwiegenden Fehlers erheblich, wenn Sie ACLs in der Registrierung unbedacht ändern.

Zusammenfassung
Wie bei den meisten Versionen von Windows gibt es auch bei Windows Vista geringfügige Änderungen bei der Zugriffssteuerung. Doch im Unterschied zu anderen neuen Versionen sind viele kleinere Änderungen vorhanden, die zusammen zu einer bedeutenden Verhaltensänderung führen. Besonders bei UAC waren mehrere Änderungen erforderlich, z. B. die Integritätsbeschriftungen und Änderungen an der ACL-Benutzeroberfläche. Außerdem wurde die bisher erste größere Bereinigung bei ACLs vorgenommen.
In vielerlei Hinsicht wurden die standardmäßigen Windows-ACLs in Windows Vista vereinfacht, was etwas völlig Neues ist. Doch wie bei vorherigen Versionen sollten Sie bei der Zugriffssteuerung sehr vorsichtig vorgehen, wenn Sie nicht über eingehende Kenntnisse auf diesem Gebiet verfügen. Dies gilt besonders für neue Versionen des Betriebssystems. Es bleibt zu hoffen, dass Ihnen die in diesem Artikel erörterten Tools eine gründlichere Untersuchung von ACLs erleichtern.

Jesper M. Johansson ist Principal Security Engineer, der an Problemen mit der Softwaresicherheit arbeitet und redaktionelle Beiträge für das TechNet Magazin schreibt. Er verfügt über einen Ph.D. in MIS und kann auf mehr als 20 Jahre Erfahrung in der Computersicherheit zurückblicken. Dieser Artikel beruht auf dem neuen Buch von Roger Grimes und Jesper Johansson mit dem Titel Windows Vista Security: Securing Vista Against Malicious Attacks (Wiley, 2007).


 Die Desktopdateien: Das Microsoft Desktop Optimization Pack
Die Desktopdateien
Das Microsoft Desktop Optimization Pack
Wes Miller
Dieser Artikel basiert auf Elementen der Vorabversion des Microsoft Desktop Optimization Pack. Änderungen an den in diesem Artikel enthaltenen Informationen sind vorbehalten.

Seit Beginn des Software Assurance (SA)-Lizenzierungsprogramms vor einigen Jahren, hat Microsoft ständig neue Features hinzugefügt und somit dessen Wert für Kunden erhöht. Zusätzlich zur Bereitstellung von Aktualisierungen für in der Lizenz enthaltene Microsoft-Produkte hat das Unternehmen
Produkte und Technologien (Windows® PE war z. B. eines der ersten) angeboten, mit denen Unternehmen ihre Erfahrungen mit Windows, Office und anderer Microsoft-Software verbessern können.
Mit vielen dieser Tools und Programme wollte Microsoft zusätzliche Möglichkeiten zur Reduzierung der Gesamtbetriebskosten von Windows, Office und anderen Microsoft-Anwendungen in der SA einer Organisation bieten.
Microsoft hat 2006 mehrere Unternehmen mit ähnlichen Zielsetzungen akquiriert: Verringerung der Gesamtbetriebskosten und Komplexität im Zusammenhang mit der Verwaltung und Reparatur von Windows und Windows-basierten Anwendungen. Microsoft hat eine Reihe dieser neu erworbenen Technologien in einem zusätzlichen Produktangebot für Kunden mit SA gebündelt. Technologien von Softricity, DesktopStandard, AssetMetrix und Winternals Software werden im kommenden Jahr als Komponenten des Microsoft® Desktop Optimization Pack (MDOP) verfügbar sein. Zusätzlich wird MDOP eine Komponente namens Microsoft System Center Desktop Error Monitoring enthalten, die Microsoft intern entwickelt hat.
Nach Schätzungen von Microsoft lassen sich mit MDOP Einsparungen im Bereich von 100 bis 500 $ pro Jahr und Desktop erzielen, abhängig von den bewährten Methoden, die Sie bei der Verwendung von MDOP einsetzen. Weitere Informationen zu MDOP sind online unter windowsvista.com/optimizeddesktop verfügbar.

Ziele des Microsoft Desktop Optimization Pack
Das Hauptziel von MDOP ist, kurz gesagt, die Bereitstellung neuer Verwaltungstechnologien durch Microsoft auf Basis eines flexibleren Zeitplans unabhängig von der Veröffentlichung neuer Betriebssysteme. Natürlich möchte Microsoft sicherstellen, dass nicht erneut eine solch große Zeitspanne wie zwischen Windows XP und Windows Vista™ entsteht. Durch die Bereitstellung von Tools in einem vorhersehbaren Zeitrahmen zwischen den Veröffentlichungen kann Microsoft mit MDOP flexibel auf die Bedürfnisse der Benutzer eingehen. Dadurch können Unternehmenskunden den Wert ihrer Softwareinvestitionen maximieren.
Damit Unternehmen flexibler handeln können, hat Microsoft eine Strategie entwickelt, mit der Kunden auf eine dynamischere Infrastruktur umsteigen können – dynamisch in dem von Microsoft mit der Dynamic Systems Initiative (DSI) festgelegten Sinn. Weitere Informationen zu DSI finden Sie unter microsoft.com/business/dsi.
Aber genug von der Strategie. Werfen wir einen Blick auf die fünf in MDOP enthaltenen Technologien:
  • SoftGrid Application Virtualization
  • Asset Inventory Service
  • Toolset für Diagnose und Wiederherstellung
  • Erweiterte Gruppenrichtlinienverwaltung
  • System Center Desktop Error Monitoring

SoftGrid Application Virtualization
SoftGrid Application Virtualization, erworben von Softricity, bietet, wie der Name schon sagt, Anwendungsvirtualisierung. Bei meiner ersten eingehenden Beschäftigung mit SoftGrid merkte ich, dass so die Anwendungsveröffentlichung für Windows 2000 IntelliMirror® hätte aussehen sollen. Warum? Weil Anwendungen nicht an Clients veröffentlicht sondern komplett virtualisiert werden. Dadurch können Anwendungen einfach auf Client- oder Terminal Server-Systemen zur Verfügung gestellt werden. Ebenso wichtig ist, dass Anwendungen zentral verwaltet und wenn nötig sogar zurückgerufen oder aktualisiert werden können. Verglichen mit dem traditionellen Modell von MSIs und Transformationen wird die Anwendungsbereitstellung wesentlich erleichtert und ist weniger riskant.
Stellen Sie sich SoftGrid als virtuelles Bild vor. Vielleicht sind Sie bereits mit dem Konzept eines Datenträgerbilds vertraut, das zur Bereitstellung von Windows (und oft auch darin enthaltenen Anwendungen) an Systeme verwendet wird. SoftGrid verpackt die Anwendung in ein Anwendungsbild anstatt in das Bild eines kompletten Betriebssystems.
SoftGrid Application Virtualization umfasst drei Hauptkomponenten: Anwendungsvirtualisierung, Anwendungslieferung und zentrale Verwaltungskonsole.
Die Anwendungsvirtualisierung selbst besteht aus virtuellen Darstellungen des Windows-Dateisystems (einschließlich Systemdateien), der Windows-Registrierung, Schriftarten, .ini-Dateien, COM-/DCOM-Objekten, Diensten, Kernelobjekten (Semaphoren, Mutexe), benannten Objekten und Namespaces aller Komponenten.
Die SoftGrid-Virtualisierung ist nicht mit der Umleitung durch die Windows Vista-Benutzerzugriffssteuerung (User Access Control, UAC) zu verwechseln. Wenn eine Anwendung versucht, in geschützte Bereiche der Registrierung oder des Dateisystems zu schreiben oder diese zu ändern, wird sie von der UAC zu einer benutzerspezifischen Ansicht der Registrierung und des Dateisystems umgeleitet. SoftGrid wiederum verwendet ein Konzept der wahren Virtualisierung der Anwendung für das Betriebssystem, einschließlich aller Registrierungs- und Dateisystemkomponenten, aus denen es besteht. Das Besondere an SoftGrid ist jedoch die Tatsache, dass eine Anwendung nicht durch ein einzelnes BLOB definiert wird. Sie besteht stattdessen aus Folgendem:
  • Eine SFT-Datei von bis zu 4 GB. Diese enthält eine oder mehrere Anwendungen und all ihre Abhängigkeiten außer Windows-Abhängigkeiten, bei denen davon ausgegangen wird, dass sie sich auf den Zielsystemen befinden.
  • Eine OSD-Datei von ungefähr 2 KB. Diese enthält eine Definition darüber, wie die Anwendung angefordert und ausgeführt werden kann. Sie können sich die OSD-Datei als EXE vorstellen.
  • Eine ICO-Datei von ca. 24 KB. Diese ist im Wesentlichen eine Verknüpfung zum Starten der Anwendung.
  • Eine SPRJ-Datei von ca. 13 KB. Diese wird vom Sequencer (dem Kern von SoftGrid) zum Veröffentlichen, Öffnen, Aktualisieren und Reparieren vorhandener Pakete verwendet.
Ein umfassendes Diagramm über die Funktionsweise von SoftGrid Application Virtualization ist auf der Website softricity.com/products/architecture.asp verfügbar.
Ein großer Vorteil der SoftGrid-Lösung besteht darin, dass eine zentrale Verwaltungskonsole (siehe Abbildung 1) zur Bestimmung verwendet werden kann, welche Anwendungen für einen bestimmten Benutzer oder eine Gruppe von Benutzern von Active Directory® verfügbar sind. Die Anwendungen können dann nach Bedarf über ein Streamingprotokoll nach Industriestandard schnell an die Benutzer geleitet werden. Nach der Installation verhalten sich die Anwendungen wie bei einer lokalen Installation. Sie beachten Benutzeranpassungen (sogar über Roaming-Benutzerprofile) und funktionieren selbst dann, wenn die Clients nicht mit dem Netzwerk verbunden sind. Administratoren können sogar die Verfügbarkeit von Anwendungen beenden, entweder dynamisch oder automatisch (z. B. nach einer festgelegten Zeit).
Abbildung 1 SoftGrid-Verwaltungskonsole
Abbildung 1 SoftGrid-Verwaltungskonsole
Das wichtigste ist, dass Anwendungen aufgrund ihrer Bereitstellung nicht vollständig zur Verfügung gestellt werden müssen. Stattdessen werden lediglich die Teile heruntergeladen, die zur Ausführung der vom Benutzer verwendeten Anwendung erforderlich sind. Stellen Sie sich ein Szenario vor, in dem Microsoft Office komplett als Paket zur Verfügung gestellt wird. Wenn ein Benutzer lediglich Word ausführt, werden nur die dafür notwendigen Komponenten heruntergeladen – nicht die Teile für Excel®, Powerpoint® und so weiter. Sobald der Benutzer eine dieser Anwendungen ausführt, z. B. Excel, werden die damit verbundenen Komponenten nach Bedarf angefordert.
Was ist in ERD?
  • Eingabeaufforderung
  • Explorer
  • Suche
  • Editor
  • Lösungsassistent
  • Verwaltung: Autoruns, Datenträgerverwaltung, Ereignisanzeige, Registrierungseditor, Dienste und Treiber, Systeminformationen
  • Netzwerktools: Dateifreigabe, Zuordnung des Netzlaufwerks, TCP/IP-Konfiguration
  • Systemprogramme: Absturzanalysator, Disk Commander, DiskWipe, FileRestore, Hotfixdeinstallation, Locksmith, Systemdateireparatur, Systemwiederherstellung

Eine weitere Komponente von SoftGrid ist die Fähigkeit der automatischen Lizenzüberwachung. Dadurch können Sie Softwarelizenzen ohne zusätzliche Software einhalten.
Fast jede Anwendung kann virtualisiert werden. Die wichtigsten Ausnahmen sind Internet Explorer® und andere Windows-Komponenten (einschließlich Hotfixes und Service Packs), Antivirenprogramme und Gerätetreiber. Wenn Sie sich eingehender mit der Funktionsweise und den Möglichkeiten von SoftGrid beschäftigen möchten, empfehle ich das Whitepaper unter Softricity.com.

Erweiterte Gruppenrichtlinienverwaltung
DesktopStandard hat sich mit der Entwicklung von Tools für die Schwachstellen bei Gruppenrichtlinien einen Namen gemacht. Durch das Anbieten des ehemals als GPOVault bekannten Tools in MDOP – jetzt unter der Bezeichnung erweiterte Gruppenrichtlinienverwaltung – stellte Microsoft seinen Kunden ein großartiges Tool zur Verfügung, mit dem das leistungsstarke (und gelegentlich gefährliche) GPO zu einem wesentlich verfeinerten und gesteuerteren Prozess wird.
Wenn Sie mit den Grundlagen von Quellcodeverwaltungssoftware vertraut sind, dann stellen Sie sich die erweiterte Gruppenrichtlinienverwaltung als Quellcodeverwaltung für Ihre Active Directory-Gruppenrichtlinien vor. (In Abbildung 2 sehen Sie einen Screenshot der Verwaltungskonsole für erweiterte Gruppenrichtlinien.) Administratoren prüfen vorhandene Richtlinienrevisionen, nehmen Änderungen vor und checken die Dokumente wieder ein, wobei die Ergebnisse mit Berichten ähnlich denen der Gruppenrichtlinien-Verwaltungskonsole überwacht werden. Wenn sich der Administrator davon überzeugt hat, dass der gewünschte Richtlinienzustand erreicht ist, kann er die Änderungen übertragen und bereitstellen. Wie bei guter Quellcodeverwaltungssoftware üblich können die Änderungen schnell und sicher und ohne die sonst erforderlichen Annahmen auf eine frühere Revision zurückgesetzt werden, sollte etwas schief gehen.
Abbildung 2 Verwaltungskonsole für erweiterte Gruppenrichtlinien
Abbildung 2 Verwaltungskonsole für erweiterte Gruppenrichtlinien
Ein weiterer wichtiger Aspekt dieses Prozesses ist die Möglichkeit, Richtlinien offline bearbeiten zu können. Änderungen an aktiven Systemen sind nicht erforderlich. Dadurch sind isolierte Tests der Änderungen möglich, bevor sie an der Domäne oder OU ausgeführt werden.
Schließlich ermöglicht die erweiterte Gruppenrichtlinienverwaltung über ein rollenbasiertes Modell die Steuerung von Änderungen über einen speziell entwickelten Workflowprozess. Durch das Erstellen von Rollen (z. B. Editor, Prüfer und Genehmiger) kann ein Administrator sicherstellen, dass ein Prozess eingesetzt wird, der die Durchführung von Änderungen auf kontrollierte Art und Weise ermöglicht. Folglich wird dem Implementierer beim Übertragen der Änderungen ein leistungsfähiger Änderungsverwaltungsmechanismus zur Verfügung gestellt, um sicherzustellen, dass spontane GPO-Änderungen nicht ohne entsprechende Bestätigung erfolgen.

Asset Inventory Service
Der Asset Inventory Service (AIS) enthält Technologie, die Microsoft durch die Übernahme von AssetMetrix erworben hat und ist eine leistungsstarke Bestandserfassungs- und Verwaltungssoftware. Im Gegensatz zu den anderen Komponenten des MDOP setzt AIS ein gehostetes Webmodell ein. AIS verwendet einen Agent mit sehr geringem Speicherbedarf und geringer Bandbreite, der entweder einmal oder in periodischen Abständen ausgeführt werden kann. Somit kann der Administrator mithilfe einer umfassenden von Microsoft gehosteten Datenbank mit über 400.000 Anwendungen nach Anwendungen suchen und feststellen, welche auf Clientsystemen installiert sind. Die erhaltenen Daten werden von AIS dann mit den erworbenen Lizenzen synchronisiert. Auf diese Weise wird eine Einhaltung sichergestellt sowie Verschwendung aufgrund unnötig erworbener Lizenzen reduziert.
Möglicherweise stehen einige Administratoren der Verwendung von AIS zunächst skeptisch gegenüber, da es sich um ein gehostetes Modell außerhalb der Firewall handelt und interne Systeme auf installierte Software hin erfasst werden. Es sollte jedoch bedacht werden, dass Microsoft große Anstrengungen unternommen hat, um den Datenschutz von Organisationen zu sichern, angefangen mit dem Umschreiben von Hauptkomponenten der Anwendung, die AIS ausmacht. Individuelle Computerdaten sind nicht an Unternehmensdaten gebunden. Außerdem lässt Microsoft die Datenübertragungstechnologie bei einem Drittanbieter zertifizieren, damit Kunden keine Bedenken in Bezug auf das von AIS verwendete Modell haben.

Toolset für Diagnose und Wiederherstellung
Wahrscheinlich ist Ihnen bekannt (wenn Sie in den vergangenen Monaten meine persönlichen Angaben in den Artikeln gelesen haben), dass ich Mitglied von Winternals war, als es von Microsoft erworben wurde. Während meiner Anstellung dort war ich Produktmanager für den Großteil der Produkte von Winternals, einschließlich Winternals Administrator's Pak. Das war der Vorgänger des Microsoft Diagnose- und Wiederherstellungstoolsets (Microsoft Diagnostics and Recovery Toolset, DaRT). Obwohl einige der Tools aus dem Administrator’s Pak in DaRT nicht enthalten sind, blieben die Hauptkomponenten des ERD Commander erhalten.
DaRT soll einen Satz Tools bereitstellen, mit denen Sie Systemprobleme diagnostizieren können, selbst wenn das System nicht ordnungsgemäß startet. Oft können Sie diese Probleme offline beheben.
ERD Commander verwendet Windows PE zum Starten eines Systems, das überhaupt nicht oder nicht normal startet. Unter einer benutzerdefinierten Benutzeroberfläche, die Windows Explorer gleicht, steht ein Satz Tools zur Verfügung. Zwei dieser Tools, Absturzanalysator und FileRestore, sind ebenfalls für die Onlineverwendung verfügbar. Diese müssen jedoch auf jedem System installiert werden, auf dem sie ausgeführt werden sollen, wenn Sie nicht ERD Commander für die Offlinediagnose und -wiederherstellung verwenden.
Die DaRT-Version von ERD Commander ist in Abbildung 3 dargestellt. Eine Liste der in der ERD Commander-Komponente enthaltenen Tools finden Sie in der Randleiste. Mit Ausnahme des Explorer-Tools sind die ersten fünf aufgeführten Tools dieselben, die für eine normale Windows-Installation verwendet werden. Explorer ist, wie die Startmenüanwendung, von der aus das Programm gestartet wird, eine spezialisierte (kleinere) Version für Windows PE.
Abbildung 3 ERD Commander
Abbildung 3 ERD Commander
Autoruns ist ein Tool, das von einem Sysinternals-Tool desselben Namens abgeleitet wurde, mit dem Sie alle Anwendungen anzeigen können, die beim Systemstart oder einer Benutzeranmeldung gestartet werden. Datenträgerverwaltung, Ereignisanzeige, Dienste und Treiber und Systeminformation sind Bestandteile einer normalen Benutzeroberfläche und mit ähnlich benannten Tools unter Windows vergleichbar. Dienste und Treiber ist besonders nützlich, da es ein System starten kann, wenn der Fehler aufgrund eines Gerätetreibers oder Diensts auftritt, der nicht korrekt arbeitet. Nicht zuletzt ist der Windows-Registrierungseditor enthalten, damit Sie die Registrierung eines Offlinesystems ändern können.
Außerdem ist Vernetzung unter ERD Commander verfügbar. Obwohl das System über DHCP automatisch konfiguriert wird, können Sie mithilfe des TCP/IP-Konfigurationsapplets eine statische IP-Adresse festlegen. Unabhängig von der Verwendung einer DHCP- oder statischen IP-Adresse können Sie entweder ein Netzlaufwerk zuordnen oder Dateien zum oder vom ausgefallenen System kopieren oder die Dateifreigabe verwenden, um das System in einen Dateiserver zu verwandeln. Somit kann ein funktionierendes System verwendet werden, um Dateien vom ausgefallenen System zu kopieren.
Schließlich ist noch eine Sammlung verschiedener Tools enthalten. Der Absturzanalysator verwendet die Debuggingtools für Windows (die getrennt heruntergeladen und installiert werden müssen – sie sind kostenlos, werden jedoch häufig aktualisiert), um die Ursache des Absturzes herauszufinden. Sie können das Tool entweder offline unter ERD Commander ausführen, wenn das System nicht startet, oder eine DMP-Datei auf ein laufendes System kopieren, auf dem DaRT installiert ist, und dort eine Diagnose ausführen. Nachdem erkannt wurde, ob das Problem bei einem neuen Dienst oder Treiber liegt, können Sie das Tool Dienste und Treiber zum Deaktivieren verwenden und prüfen, ob das System dann normal ausgeführt wird.
Disk Commander ist hilfreich bei der Wiederherstellung versehentlich gelöschter oder beschädigter Partitionen, Dateigruppen oder Verzeichnisse. Am anderen Ende des Spektrums ermöglicht DiskWipe eine DoD-kompatible Festplatten- oder Volumelöschung. Mit FileRestore können Sie eine einzelne Datei, die unbeabsichtigt gelöscht wurde, (entweder online oder offline) wiederherstellen. Es ist zu beachten, dass der Dateityp und die Zeit/Datenträgeraktivität seit dem Löschen der Datei die Wiederherstellbarkeit unabhängig vom verwendeten Tool beeinflussen.
Für den Fall, dass das System aufgrund eines Windows-Hotfix oder Service Pack nicht normal starten kann, können Sie die Hotfixdeinstallation zum selektiven Deinstallieren eines oder mehrerer Hotfixe oder Service Packs verwenden. Der Prozess wird durch Neustart beendet, da Windows nicht die komplette Offlineentfernung von Anwendungen unterstützt. Oft wird dadurch ein Neustart ermöglicht.
Locksmith war eines der beliebtesten Tools des ERD Commander-Toolsets bei Winternals. Damit können Sie jedes beliebige lokale Benutzerkennwort zurücksetzen. Es funktioniert nicht bei Domänencontrollern und kann keine Kennwörter von Domänenbenutzern zurücksetzen. Im Allgemeinen wird es zum Zurücksetzen des Administratorkennworts verwendet, wenn dieses vergessen wurde oder der Benutzer die Organisation verlassen hat. Mit Systemdateireparatur werden alle geschützten Systemdateien auf Beschädigung überprüft und wenn erforderlich ersetzt. Wie der Name bereits sagt, können Sie mit der Systemwiederherstellung einen Windows-Systemwiederherstellungspunkt auf einem Windows XP-System nach hinten oder nach vorn verschieben. (Windows XP mit bereits vorhandenen Wiederherstellungspunkten ist für diese Funktion erforderlich.) Ich gehöre zu den vielen Benutzern, für die diese einzigartige Funktion bereits eine Rettung war.
Die Tools in ERD Commander und DaRT erscheinen möglicherweise etwas zufällig, doch sie sind eine leistungsfähige Zusammenstellung von Dienstprogrammen, die Winternals im Laufe der Zeit entwickelt hat. Sicher werden Sie sie bei der Wiederherstellung und Problembehebung sehr nützlich finden.

System Center Desktop Error Monitoring
System Center Desktop Error Monitoring (DEM) bietet Organisationen eine schnelle und leichte Möglichkeit für die Zentralisierung und Diagnose von Windows-Abstürzen und Anwendungsblockaden. Statt Absturz- und Blockadeberichte an Microsoft zu senden, verwendet DEM Gruppenrichtlinien und die integrierte Windows-Fehlerberichterstattung, um Bereichte zur Diagnose an einen von Ihnen bestimmten Server innerhalb Ihrer Organisation zu senden. (Dafür wird kein zusätzlicher Softwareagent benötigt.) Die gesamten DEM-Serverdaten werden in einer SQL Server-Datenbank gespeichert, wodurch Sie die gesammelten Daten Ihrer internen Anwendungen und Berichterstattung einfach abfragen können. Somit können Sie Probleme innerhalb der Organisation proaktiv diagnostizieren. Mithilfe dieser Informationen können Sie die Berichterstattung solcher Vorfälle fordern, die häufigsten Ursachen von Abstürzen und Blockaden entdecken und sicherstellen, dass Windows- und Anwendungspatches priorisiert werden, um die Systemausfallzeiten zu minimieren bzw. zu eliminieren.
Sie können Ihren DEM-Server auch zum Senden der Ergebnisse an Microsoft konfigurieren, oder mit DEM die aktuellsten Problembehandlungsdaten für Anwendungen von Microsoft und Drittanbietern automatisch herunterladen. Im Fall eines Absturzes oder einer Blockade können zusätzliche Daten von Clients gesammelt werden.

Lizenzierung des MDOP
Die erste Voraussetzung zur Lizenzierung des MDOP ist eine bestehende Microsoft SA-Vereinbarung. Mit dieser liegen die Lizenzierungskosten bei einem Minimum von 7 bis 10 $ pro Desktop. Mengenrabatte und Preise für Schulungszwecke sind verfügbar.
MDOP steht außerhalb der SA-Vereinbarung nicht zur Verfügung, mit einer Ausnahme: Kunden, die SoftGrid-Technologien mit ihren Terminalservern (siehe softricity.com/solutions/sbc.asp) oder SMS (siehe softricity.com/products/softgrid-sms.asp) verwenden möchten, können dies tun. In zukünftigen Versionen von SMS und System Center Configuration Manager werden AssetMetrix-Technologien zur Verfügung gestellt.

Verfügbarkeit und Updates
Die ersten Komponenten von MDOP sind bereits verfügbar. Die Komponenten werden folgendermaßen geliefert:
  • SoftGrid ist von Microsoft seit Anfang 2007 verfügbar.
  • Microsoft DaRT ist seit Mai 2007 verfügbar.
  • Die GPOVault-Technologien sollen ab Juli 2007 verfügbar sein.
  • Desktop Error Monitoring soll in MDOP ab Juli 2007 verfügbar sein.
  • AssetMetrix-Technologien sollen in der Betaversion ab Juli 2007 und zur Veröffentlichung im August verfügbar sein.
  • Ein Update der DaRT-Komponenten ist für Ende 2007 geplant, wobei die Haupterweiterung Windows Vista-Kompatibilität betrifft.
In zukünftigen Versionen von MDOP sollen zweimal jährlich Verbesserungen, Aktualisierungen und neue Features bereitgestellt werden.

Zukunft für MDOP
Wie erwähnt werden die Hauptkomponenten von AssetMetrix-Technologies in zukünftige Versionen von System Center Configuration Manager integriert. Tatsächlich kann davon ausgegangen werden, dass mit der Weiterentwicklung der MDOP-Funktionalität einiges in die grundlegenden Entwicklungs-, Verwaltungs- und Konfigurationstechnologien von Microsoft übernommen wird. Neue Technologien (einige von Microsoft entwickelt, einige von anderen Unternehmen erworben) werden dann in zukünftigen Versionen von MDOP zur Verfügung stehen. Im Wesentlichen soll MDOP ein Paket aus neuesten Verwaltungs- und Konfigurationstechnologien sein, das ständig weiterentwickelt wird.

Wes Miller ist Entwicklungsmanager bei Pluck in Austin, Texas. Davor arbeitete er bei Winternals Software in Austin und bei Microsoft als Programmmanager und Produktmanager für Windows. Sie können Wes Miller unter technet@getwired.com erreichen.
Ich möchte Chad Jones und Gavriella Schuster, Produktmanager für Microsoft Desktop Optimization Pack, für ihre Unterstützung bei diesem Artikel danken.


 Windows Confidential: Die magischen Kr&#228;fte des abgesicherten Modus
Windows Confidential
Die magischen Kräfte des abgesicherten Modus
Raymond Chens

Als der abgesicherte Modus für Windows erstmals für Windows® 95 entwickelt wurde, sollte er mehr tun als nur Treiber deaktivieren. Er sollte auch alles reparieren, was automatisch repariert werden konnte.
Wenn Sie den Computer im abgesicherten Modus starten, prüft Windows Explorer zum Beispiel die Positionen aller Symbole auf dem Desktop, um sicherzustellen, dass alle sichtbar sind, denn es ist möglich, den Computer in einen Zustand zu versetzen, bei dem ein Symbol aus dem sichtbaren Bereich des Bildschirms „herausrutscht“.
Wenn Sie das einmal ausprobieren möchten, positionieren Sie zwei Symbole auf dem Desktop, eins am linken Rand und eins am rechten Rand. Klicken Sie dann auf das erste Symbol, drücken Sie die Strg-Taste, und klicken Sie bei gedrückter Strg-Taste auf das zweite Symbol (hierdurch werden beide Symbole markiert). Ziehen Sie dann das linke Symbol zur rechten Seite des Bildschirms. Hierdurch wird das zweite Symbol ebenfalls verschoben, wobei der Abstand zwischen den beiden Symbolen gleich groß bleibt. Das zweite Symbol verschwindet jetzt vom Bildschirm.
Im abgesicherten Modus können Probleme in Windows behoben werden.
Im abgesicherten Modus können Probleme in Windows behoben werden.
Wenn Windows Explorer Positionen von Symbolen im abgesicherten Modus nicht reparieren würde, würden Anweisungen zur Fehlerbehebung u. U. eher verwirrend als hilfreich sein.
  1. Starten Sie den Computer im abgesicherten Modus. (OK.)
  2. Doppelklicken Sie auf das Symbol „Arbeitsplatz“. (Ich sehe das Symbol „Arbeitsplatz“ nicht.)
  3. ...
Das Symbol „Arbeitsplatz“ ist nicht auf dem Bildschirm zu sehen. Sie können also noch nicht einmal Schritt 2 der Problembehandlung durchführen.
Einige Benutzer haben sich darüber beschwert, dass die Symbole automatisch repariert werden. Wenn dieses Problem bei einem Benutzer auftritt und er sich an den technischen Support wendet, bittet der Supporttechniker den Benutzer einfach, mit der rechten Maustaste auf den Desktop zu klicken und die Option zum Zurücksetzen der Symbolpositionen auszuwählen. Das Problem ist damit gelöst, und der abgesicherte Modus hat die Symbole nicht verändert.
Das eigentliche Problem hierbei ist jedoch, dass der Benutzer überhaupt beim technischen Support anrufen muss. Wenn ein Benutzer zum Telefon greift, haben Sie versagt.
Denn in diesem Fall ist das ganze Konzept des abgesicherten Modus fehlgeschlagen. Benutzer starten den Computer im abgesicherten Modus, wenn das Gerät nicht richtig funktioniert, wissen aber nicht unbedingt, was sie tun sollen, sobald der Modus aufgerufen ist. In der Regel warten sie also nur ab, was passiert. „Irgendwas funktioniert nicht, ich versuche mal, den PC im abgesicherten Modus zu starten.“ Unter Windows 95 wurden im abgesicherten Modus verschiedene automatische Reparaturfunktionen integriert, weil Benutzer den abgesicherten Modus genau für diesen Zweck verwendeten. Das hat ziemlich gut funktioniert.
Wenn ein Benutzer anrief und Sie empfahlen, den PC im abgesicherten Modus zu starten, weil sich dadurch das Problem mit ziemlicher Sicherheit beheben ließe, war der Benutzer meist der Meinung, dass das ja ganz einfach sei und er auch selbst auf diese Idee hätte kommen können.
Aber wenn Sie eine längere Anweisung geben wie „Starten Sie den PC im abgesicherten Modus, klicken Sie mit der rechten Maustaste auf diese Option, wählen Sie dann jene Option aus, und klicken Sie dann auf dieses Kästchen“, befolgt der Benutzer zwar Ihre Anweisungen, und das Problem wird behoben, aber er ist in der Regel trotzdem etwas verwirrt. Oftmals wird der Benutzer dadurch vielmehr verunsichert und entmutigt. Statt dem Benutzer Kontrolle zu geben, fühlt er sich eher hilflos. „Hierauf wäre ich nie im Leben gekommen. Computer sind ja so kompliziert.“

Raymond ChensWebsite, The Old New Thing, und sein gleichnamiges Buch (Addison-Wesley, 2007) befassen sich mit der Windows-Geschichte und der Win32-Programmierung. Raymond Chen verzieht sich in der Regel lieber, bevor es richtig brenzlig wird.