Juli 2008 Juli 2008
IIS: Bereitstellung mit IIS 7.0
Die Veröffentlichung von Internetinformationsdienste 7.0 setzt neue Standards und bietet grundlegende Verbesserungen und neue Funktionen für die Konsolidierung von Webumgebungen. Lernen Sie die wichtigsten Verbesserungen kennen, und erhalten Sie ein detailliertes Handbuch zum Testen, Bereitstellen und Migrieren Ihrer Webanwendungen zu IIS 7.0. Fergus Strachan
Kommunikation und Zusammenarbeit: Planen Ihrer Migration zu Unified Messaging
Das Verschieben eines Legacyvoicemailsystems zu einer Unified Messaging-Plattform kann ziemlich problemlos und mit geringen Unterbrechungen Ihrer Endbenutzer durchgeführt werden, so lange Sie einen guten Plan haben. Hier erfahren Sie alles, was Sie für die Planung Ihrer Migration, zum Testen der neuen Systeme und Implementieren von Unified Messaging in Ihrer Organisation wissen müssen. Jeff Goodwin
Kommunikation und Zusammenarbeit: Wie die Sprache OCS 2007 steuert
Microsoft Office Communication Server bringt für die Unternehmenstelefonie wichtige Änderungen. Untersuchen Sie, wie Sprachanrufe Schicht für Schicht durchgeführt werden, erfahren Sie, wie Anrufe zu verschiedenen Endpunkten weitergeleitet werden können, und erforschen Sie die Wichtigkeit von Gesprächen in der OCS-Kommunikation. Rajesh Ramanathan
Kommunikation und Zusammenarbeit: Erstellen leistungsfähiger Verbindungen mit Groove und SharePoint
Microsoft Office Groove und SharePoint Server liefern gemeinsam leistungsfähige Funktionen für die Zusammenarbeit. Informieren Sie sich über die Unterschiede zwischen den beiden Programmen und finden Sie heraus, wie sie sich gegenseitig ergänzen. Sie erfahren, wie sich Groove und SharePoint zu einer einfachen und flexiblen Lösung für die Zusammenarbeit integrieren lassen, die Benutzer an verschiedenen Standorten unterstützt. Alan Maddison
Windows-Verwaltung: Einführung in Failoverclustering für Windows Server 2008
Benutzer haben sich jahrelang darüber beschwert, dass Clustering in Windows Server zu kompliziert ist. Mit der Veröffentlichung von Windows Server 2008 wurde Clustering rundum überarbeitet. Lernen Sie die wichtigsten Verbesserungen des neuen Failoverclustering kennen, und erfahren Sie, wie durch diese neue Implementierung das Einrichten und Verwalten von Clustern erheblich erleichtert wird. Chuck Timon
Columns
Mitteilung der Redaktion: Printmedien sind tot: | Briefe: Leser sagen ihre Meinung: | Toolbox: Neue Produkte für IT-Experten:
Exchange Fragen & Antworten: Lastenausgleich, Edge-Transport und mehr: Haben Sie Fragen zu Exchange? In dieser Ausgabe beantworten wir Fragen über die Verwendung von Exchange mit SharePoint, das Arbeiten mit der fortlaufenden Standbyreplikation, das Installieren von Exchange 2007-Postfachservern auf Windows Server 2008 und mehr.Henrik Walther | Schwerpunkt Dienstprogramme: Microsoft SharedView: Suchen Sie eine Möglichkeit, schnell mit jemandem zusammenzuarbeiten, der sich in einer anderen Stadt befindet? Sehen Sie selbst, wie Sie mit Microsoft SharedView, einem kostenlosen Dienstprogramm, problemlos Dokumente und Bildschirme mit einer kleinen Gruppe anderer Benutzer sogar über physische Grenzen hinaus gemeinsam verwenden können.Greg Steen | Inside SharePoint: Integrieren von Office-Anwendungen: Erfahren Sie, wie Microsoft Office-Anwendungen in SharePoint integriert werden können und mit SharePoint kommunizieren, und erforschen Sie, wie Sie Nicht-Microsoft-Anwendungen in SharePoint auf der Grundlage derselben Prinzipien integrieren können.Pav Cherny
Windows PowerShell: Die Drop Box: Don Jones bespricht Filterfunktionen, die Pipeline, benutzerdefinierte Objekte und warum Tischtennisbälle der Schlüssel für das Verständnis der Windows PowerShell sind.Don Jones | Hey, Scripting Guy!: Der Adrenalinschub: Die Scripting Guys diskutieren Skriptprogrammierung voller Adrenalin und zeigen Ihnen, wie mithilfe von Skripts auf den neuen Startkonfigurations-Datenspeicher von Windows Vista und Windows Server 2008 zugegriffen werden kann.Die Scripting Guys von Microsoft | Die Desktopdateien: Windows-Netzwerkstart: Informieren Sie sich über die Entwicklung der Remoteinstallationsdienste (Remote Installation Services, RIS) und andere PXE-Technologien, die bei Microsoft verwendet werden.Wes Miller
Sicherheit auf dem Prüfstand: Kennwörter und Kreditkarten, Teil 1: In diesem ersten Teil einer dreiteiligen Serie geht es um die Frage, warum allgemeine sicherheitsrelevante Empfehlungen und gängige Methoden veraltet sind und oft eine Behinderung von Sicherheitsmaßnahmen darstellen.Jesper M. Johansson | Berichte aus der Praxis: Sicherstellen von Wahlgenauigkeit: Untersuchen Sie die Sicherheitsrisiken im heutigen Wahlsystem der USA, und erfahren Sie, wie mithilfe von Kryptografie vollständig überprüfbare Wahlergebnisse erzielt werden können.Josh Benaloh | Windows Confidential: Geschichte, die viel Raum einnimmt: Microsoft Bob ist viel weiter verbreitet, als Sie denken. Raymond Chen erklärt, wie sich Microsoft Bob seinen Weg in das Zuhause von Millionen von Benutzern gebahnt hat.Raymond Chen


IIS
Bereitstellung mit IIS 7.0
Fergus Strachan
Auf einen Blick:
  • Bereitstellen von IIS 7.0 in einer Webfarmumgebung
  • Sicherheitsverbesserungen und Leistungsoptimierung
  • Migrieren von ASP.NET-Webanwendungen von IIS 6.0 zu IIS 7.0
  • Migrieren von PHP-Webanwendungen zu IIS 7.0

Inhalt
Auf die Plätze, fertig, testen
Meine Testeinrichtung
Wichtige Verbesserungen für IT-Administratoren
IIS-Architektur
Integrierter und klassischer Modus
Module und Funktionalität
Migration von Webanwendungen
Zusammenfassung
Nach Aussage des IIS-Teams bei Microsoft sind Internetinformationsdienste (IIS) 7.0 die bisher wichtigste Version in der Geschichte von IIS. Diese Version setzt neue Standards und bietet grundlegende Verbesserungen sowie
neue Funktionen für die Konsolidierung von Webumgebungen. Das im Lieferumfang von Windows Server® 2008 und Windows Vista® SP1 enthaltene IIS 7.0 ist bereits der Motor hinter Microsoft.com, und mehrere Webhostingunternehmen haben damit begonnen, Webdesignern und Entwicklern, die ihre vorhandenen Webanwendungen auf die neue Webserverplattform portieren möchten, IIS 7.0-Hosting bereitzustellen.
In diesem Artikel sollen wichtige Verbesserungen in IIS 7.0 untersucht werden, die für IT-Experten eine bedeutende Rolle spielen. Anschließend folgen detaillierte Informationen zur Migration von ASP.NET- und PHP-Webanwendungen. Zunächst jedoch möchte ich eine Testumgebung skizzieren, die einer einfachen Produktionsumgebung ähnelt.
Dies ist eine wichtige Aufgabe. Bevor Sie IIS 7.0 auf Ihren Produktionsservern bereitstellen, müssen Sie Zeit in gründliche Tests in einer Testumgebung investieren. Nur so können Sie sicherstellen, dass Ihre Webanwendungen auf dem neuen Webserver reibungslos funktionieren.

Auf die Plätze, fertig, testen
Meine Testumgebung umfasst Systeme mit Windows Server 2003 und IIS 6.0, die ASP.NET-Anwendungen hosten sowie Server, auf denen die Ubuntu 7.10 Linux-Distribution ausgeführt wird, sowie Apache HTTP Server 2.2 als Host für PHP-basierte Webanwendungen. Mein endgültiges Ziel besteht darin, Windows Server 2008 auf Bereitstellungs- und Produktionssystemen bereitzustellen und dann komplexe Webanwendungen zu übertragen, um IIS 6.0 und Apache-Instanzen durch IIS 7.0 zu ersetzen.
Ich habe zwei wichtige Webanwendungen: DotNetNuke 4.7 und osCommerce 3.0a4. DotNetNuke ist ein Webanwendungsframework auf der Grundlage von ASP.NET 2.0 und Microsoft® SQL Server®. Bei der anderen Anwendung, osCommerce, handelt es sich um die neueste Alphaversion einer E-Commercelösung mit umfassenden Funktionen auf Basis von PHP und MySQL. Der Plan besteht darin, diese hoch entwickelten Anwendungen auf IIS 7.0 zu übertragen!
Ich möchte klarstellen, dass es mir nicht darum geht, Softwareversionen, Produkte oder Plattformen zu vergleichen. Es gibt jedoch einige Vorteile der Standardisierung in Windows Server 2008 und IIS 7.0, auf die ich aufmerksam machen möchte. Die Komplexität der Verwaltung wird verringert, und Sie können die Gesamtzahl der Webserver, die Sie ausführen, minimieren.
Abbildung 1 bietet einen Überblick über die Testumgebung, die ich für diesen Artikel verwende. Wenn Sie meinen Erklärungen in Ihrer eigenen Testumgebung folgen wollen, finden Sie Links zu den erforderlichen Softwarekomponenten sowie ausführliche schrittweise Installationsanweisungen im Begleitmaterial, das Sie im Bereich mit den Codedownloads der TechNet Magazin-Website unter .com herunterladen können.
Abbildung 1 Die Testumgebung für die Bereitstellung von IIS 7.0 (zum Vergrößern auf das Bild klicken)
Zum Zeitpunkt der Abfassung dieses Artikels veröffentlichte Microsoft ein Befehlszeilentool (MSDeploy.exe), um Kunden bei der Bereitstellung, Synchronisierung und Migration von Webanwendungen zu IIS 6.0 und 7.0 zu unterstützen. Dieses Tool sollten Sie sich näher ansehen. Ausführliche Informationen finden Sie im Blog des Webbereitstellungsteams von Microsoft unter go.microsoft.com/fwlink/?LinkId=118272.

Meine Testeinrichtung
Zum Zeitpunkt der Abfassung dieses Artikels lag Windows Server 2008 noch in einer Vorabversion vor. Daher habe ich Windows Server 2003 auf Domänencontroller- oder Datenbankservern nicht ersetzt. Nach der offiziellen Veröffentlichung von Windows Server 2008 könnten Sie nun auch Ihre Active Directory®-Infrastruktur migrieren. Auf die Migration von SQL Server® 2005- und MySQL-Datenbanken zu SQL Server 2008 wird in diesem Artikel ebenfalls nicht eingegangen.
Ich habe SQL Server 2008 in erster Linie deshalb auf meinem Bereitstellungsserver bereitgestellt, weil dies einen geringeren Aufwand bedeutet als die Installation von SQL Server 2005 mit Service Pack 2. DotNetNuke konnte ohne Probleme mit einer SQL Server 2008-Datenbank ausgeführt werden. Auch die Installation von MySQL 5.0 auf Windows Server 2008 verlief ohne Komplikationen.
IIS 7.0 ist zwar auf Server Core verfügbar, dennoch habe ich aufgrund bestimmter Anforderungen für das Testen keine Server Core-Installation gewählt. Mein Bereitstellungsserver erforderte eine vollständige Installation, da es sich um mein primäres Testsystem handelte. Außerdem ist Microsoft .NET Framework auf Server Core nicht verfügbar.
PHP lässt sich problemlos auf Server Core ausführen. Da mein Ziel jedoch darin besteht, ASP.NET- und PHP-Anwendungen zu konsolidieren, kommt Server Core ganz einfach nicht in Frage. Solange .NET Framework nicht auf Server Core unterstützt wird, müssen Sie eine vollständige Installation durchführen, um ASP.NET-Anwendungen zu unterstützen. Ausführliche schrittweise Anleitungen zur Installation der Testumgebung finden Sie in der Datei „01_install_testlab.htm“ im Begleitmaterial.
Ich habe mich für eine Neuinstallation von Windows Server 2008 (im Gegensatz zur Aktualisierung vorhandener Server) entschieden. Unter anderem ist es bei einer Neuinstallation einfacher, ein Szenario einer gestaffelten Migration wie das in Abbildung 2 zu implementieren. Die zugrunde liegende Strategie besteht darin, mit den vorhandenen Webfarmen so lange zu arbeiten, bis alle relevanten Webanwendungskomponenten erfolgreich auf dem Bereitstellungsserver getestet und in die neue IIS 7.0-Webfarm verschoben wurden.
Abbildung 2 Gestaffelte Umstellung auf IIS 7.0 (zum Vergrößern auf das Bild klicken)
Sie können alle vorhandenen Webanwendungen auf einmal oder nacheinander verschieben, je nach der Komplexität Ihrer Umgebung. Für jede Webanwendung oder Website können Sie nach der Durchführung eines abschließenden Akzeptanztests auf der neuen Webfarm den Wechsel vornehmen, indem Sie die relevanten DNS-Datensätze so ändern, dass Browser zur neuen IIS 7.0-Webfarm geleitet werden. So verringern Sie die Ausfallzeiten und Unterbrechungen auf ein Minimum.

Wichtige Verbesserungen für IT-Administratoren
Im MSDN® Magazin finden Sie einen hervorragenden Artikel von Mike Volodarsky mit dem Titel „Webserver für Windows Vista und mehr“ (verfügbar unter msdn2.microsoft.com/magazine/cc163453.aspx), in dem Sie sich über die Verbesserungen in IIS 7.0 informieren können.
Eine weitere gute Quelle ist ein Blogbeitrag des Microsoft.com-Teams mit dem Titel „The Tasty Morsels Found in Dogfood“ (verfügbar unter go.microsoft.com/fwlink/?LinkId=117436). Im Beitrag werden die ersten Erfahrungen der Teammitglieder mit IIS 7.0 resümiert. Kurz gefasst, sind die wichtigsten Verbesserungen die folgenden:
  1. Vereinfachtes Setup.
  2. Hervorragende Kompatibilität.
  3. Keine Metabasis mehr.
  4. Zentralisierung der Konfiguration erfolgt über die Datei „applicationHost.config“, die in einer UNC-Freigabe abgelegt wird.
  5. Delegierung der Konfiguration mittels Web.config-Dateien in Anwendungsverzeichnissen
  6. Verbesserte Verwaltungstools.
  7. Ablaufverfolgung für Anforderungsfehler.
  8. Anforderungsfilterung ohne die Notwendigkeit von URLScan.
  9. Verfügbarkeit vereinfachter Inhaltssynchronisierung durch UNC-Freigaben.
Ausgabezwischenspeicherung dynamischer Inhalte.
Vereinfachtes Setup steht ganz sicher auf meiner Liste. In seinem Blogbeitrag veranschaulicht das Microsoft.com-Team, wie Sie sämtliche Features (oder auch nur die gewünschten) von IIS 7.0 mit einer einzelnen Befehlszeile bereitstellen können. Ich habe diesen Ansatz sofort in meine Anweisungen zur Einrichtung der Testumgebung integriert. Die Befehlszeile wird in Abbildung 3 gezeigt.
Zugegeben, dieser Befehl ist ziemlich lang. (Wenn Sie den Befehl kopieren möchten, sollten Sie ihn von der TechNet Magazin-Website kopieren und dann einfügen, anstatt ihn per Hand einzugeben.) Mit diesem Befehl werden zwar alle verfügbaren Module auf dem IIS 7.0-Computer installiert, PHP wird jedoch nicht berücksichtigt. In IIS 7.0 ist PHP nicht enthalten, und das Konzept des Herunterladens und Installierens von Debian-Paketen über das Internet ist dem Windows®-Paket-Manager (pkgmgr.exe) fremd. Hier kommt Windows Automated Installation Kit (AIK) ins Spiel.
Abbildung 3 Bereitstellen von IIS 7.0-Features mit einer einzelnen Befehlszeile
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
Mit AIK können Sie eine benutzerdefinierte Installations-DVD für Windows Server 2008 erstellen, die IIS 7.0 und PHP 5 enthält. Außerdem können Sie MySQL, Webanwendungsdateien und andere Komponenten einbeziehen, die für Ihre Bereitstellung erforderlich sind. Alle Komponenten können Teil Ihres Windows Server 2008-Setups sein, was Ihnen ermöglicht, einheitlich Anpassungen auf allen Webservern durchzuführen. Befehlszeilen oder die Bearbeitung von Konfigurationsdateien sind überflüssig.
Sie können sogar eine benutzerdefinierte DVD für vollständig unbeaufsichtigte Installationen erstellen. Das AIK umfasst Dokumentationsmaterial und Tools zur Erstellung der Datei „AutoUnattend.xml“, die Sie dann im Stammordner der DVD ablegen können. In der Datei „Custom Image Deployment.htm“ im Begleitmaterial finden Sie schrittweise Anleitungen.
Viele Administratoren sind sich außerdem darin einig, dass Kompatibilität zu den wichtigsten Verbesserungen zählt. Anfangs habe ich mit einigen Kompatibilitätsproblemen mit DotNetNuke und osCommerce gerechnet. Der Übergang zu IIS 7.0 verlief jedoch recht problemlos, und das trotz der Tatsache, dass beide Webanwendungen erweiterte Features enthalten (z. B. Formularauthentifizierung und suchmaschinenfreundliche URLs).
Bei DotNetNuke traten keinerlei Probleme auf, bis ich zu einem komplexen Webfarmszenario mit UNC-Inhaltsfreigabe auf einer 64-Bit-Plattform wechselte. Das Problem war jedoch ziemlich unbedeutend. Die bessere Kompatibilität bedeutet letzten Endes, dass Sie weniger Zeit benötigen, bis Ihre Webanwendungen unter IIS 7.0 zur Ausführung bereit sind.
Wenn Sie tatsächlich auf Kompatibilitätsprobleme mit Ihren Webanwendungen stoßen, werden die integrierte Diagnose und die Ablaufverfolgungsunterstützung bald zu Ihren neuen Lieblingsfunktionen gehören. Die ausführlichen Diagnoseinformationen sind sehr aussagekräftig, und die vorgeschlagenen Lösungswege sind nützlich und funktionieren.
Abbildung 4 zeigt die Diagnoseinformationen, die bei Ausführung von DotNetNuke 4.7 unter IIS 7.0 im integrierten Modus angezeigt werden. In diesem Beispiel gibt es drei Optionen (siehe den Abschnitt „Mögliche Vorgehensweise“). Die beste Option für DotNetNuke-Entwickler besteht vermutlich darin, die Anwendung so zu ändern, dass sie den integrierten Modus unterstützt. Den Fehler zu ignorieren ist sicher keine gute Idee. Mir persönlich gefällt die dritte Option, die Aktivierung des klassischen Modus. Hierzu aktiviere ich die Webanwendung für einen Anwendungspool im klassischen Modus, Classic .NET AppPool, weil ich DotNetNuke 4.7 unter IIS 7.0 unverändert ausführen möchte.
Abbildung 4 Diagnoseinformationen für DotNetNuke bei Ausführung im integrierten Modus (zum Vergrößern auf das Bild klicken)

IIS-Architektur
Vielleicht fragen Sie sich, was diese integrierten und klassischen Modi eigentlich sind und warum sie zwar die ASP.NET-Anwendung (DotNetNuke), jedoch nicht die PHP-Anwendung (osCommerce) beeinflussen. Um dies zu verstehen, sollten Sie zuerst die Architektur von IIS 7.0 näher betrachten. In früheren Versionen war die ASP.NET-Laufzeit in den zentralen Webserver integriert, hauptsächlich durch eine ISAPI-Erweiterung (aspnet_isapi.dll). In IIS 7.0 hingegen ist es möglich, ASP.NET-Module direkt mit dem zentralen Webserver zu verbinden, und zwar über ein HTTP-Modul auf globaler Ebene namens „ManagedEngine“, das die ASP.NET-Support-DLL (webengine.dll) in die Pipeline für die Anforderungsverarbeitung von IIS 7.0 lädt.
Systemeigene Module verwenden die Core-API des IIS-Webservers zur Registrierung für spezifische Ereignisse in der Pipeline, z. B. „BeginRequest“, „AuthenticateRequest“, „AuthorizeRequest“ und „ExecuteRequestHandler“. „ManagedEngine“ bietet ebenfalls die notwendige Unterstützung für die Integration von ASP.NET-Modulen in die Anforderungspipeline. Dank dieser neuen Architektur kann IIS 7.0 systemeigene und ASP.NET-Module in jeder Phase während der Anforderungsverarbeitung aufrufen, unabhängig von der Art des angeforderten Inhalts.
Betrachten wir als Beispiel die ASP.NET-Benutzerauthentifizierung. In IIS 6.0 kann ein ASP.NET-basiertes HTTP-Modul sich für OnAuthenticate-Ereignisse registrieren (z. B. „FormsAuthentication.OnAuthenticate“ und „WindowsAuthentication.OnAuthenticate“), um die Identität des Benutzers im aktuellen HttpContext festzulegen. Dies funktioniert innerhalb der ASP.NET-Laufzeit ohne Probleme, Sie können diesen ASP.NET-Code jedoch nicht zum Schutz von Ressourcen verwenden, die durch eine PHP-basierte Webanwendung verfügbar gemacht werden.
Gemäß seiner Skriptzuordnungskonfiguration leitet IIS 6.0 Anforderungen für ASP.NET-Inhaltstypen an „aspnet_isapi.dll“ weiter. Anforderungen für PHP-Inhaltstypen werden jedoch nicht an die ISAPI-Erweiterung für ASP.NET weitergeleitet. ASP.NET verarbeitet schließlich keinen PHP-Code, dies bedeutet jedoch auch, dass der ASP.NET-Authentifizierungscode bei Anforderung einer PHP-Seite nicht ausgeführt wird. Folglich müssen Sie bei IIS 6.0 die Authentifizierungslogik duplizieren, da PHP-Anwendungen ihre eigenen Authentifizierungsmechanismen implementieren müssen.
IIS 7.0 verwendet ein ereignisgesteuertes Verarbeitungsmodell, das Unterstützung für das Mischen und Anpassen einzelner Module in der Anforderungspipeline bietet. Zu den Komponenten von IIS 7.0 gehören u. a. verwaltete WindowsAuthentication- und FormsAuthentication-Module, die OnAuthenticate-Ereignisse auslösen, wenn die Anforderungspipeline das AuthenticateRequest-Ereignis auslöst. Sie können jetzt festlegen, dass ein systemeigenes Modul wie „RequestFilteringModule“ oder „IpRestrictionModule“ das BeginRequest-Ereignis so handhabt, dass kritische Anforderungen so früh wie möglich abgelehnt werden, dann benutzerdefinierter ASP.NET-Authentifizierungscode am AuthenticateRequest-Ereignis ausgeführt und das FastCgiModule zur Ausführung des PHP-Skriptmoduls (php-cgi.exe) am ExecuteRequestHandler-Ereignis veranlasst wird, um PHP-Seiten zu verarbeiten.
Das Ergebnis dieser integrierten Architektur besteht darin, dass Webentwickler Code nicht duplizieren müssen, um allgemeine Geschäftslogik zu implementieren. Sie können benutzerdefinierten ASP.NET-Authentifizierungscode dazu verwenden, alle Ihre IIS-Ressourcen einschließlich PHP-Anwendungen zu schützen. Sie können ASP.NET-Module außerdem für andere nachträglich durchgeführte Verarbeitungsaufgaben verwenden. Hierzu gehören z. B. URL-Umschreibung, benutzerdefinierte Ablaufverfolgung und Fehlerprotokollierung.

Integrierter und klassischer Modus
Der von dieser neuen Architektur verursachte Nebeneffekt besteht darin, dass für vorhandene ASP.NET-Anwendungen möglicherweise Code- und Konfigurationsänderungen erforderlich sind, die von Anwendungsentwicklern durchgeführt werden sollten, um sicherzustellen, dass die Änderungen nicht zu Modulkonflikten in der Anforderungspipeline führen. Wenn Sie eine vorhandene Webanwendung jedoch nicht sofort portieren können, haben Sie die Möglichkeit, den klassischen Modus im Anwendungspool zu aktivieren, den der Arbeitsprozess zur Ausführung der Webanwendung verwendet. IIS 7.0 lädt „ManagedEngine“ nicht in Arbeitsprozesse im klassischen Modus, was in diesem Fall bedeutet, dass die Anforderungspipeline ASP.NET-Module nicht auflösen oder aufrufen kann. Stattdessen aktiviert IIS 7.0 einige auf „IsapiModule“ (aspnet_isapi.dll) basierende ISAPI-Handler, um ASP.NET-Inhaltstypen ähnlich wie in IIS 6.0 zu verarbeiten. Sie können sich davon überzeugen, wenn Sie den Abschnitt „Handler“ unter „system.webServer“ in der Datei „applicationHost.config“ analysieren, die Sie standardmäßig im Ordner „%WinDir%\System32\InetSrv\Config“ finden.
Wenn Sie nach der Zeichenfolge „aspx“ als Beispiel suchen, finden Sie einen Eintrag, der auf „PageHandlerFactory-Integrated“ verweist (geladen in Arbeitsprozesse im Anwendungspool im integrierten Modus gemäß der Einstellung „preCondition="integratedMode"“), und andere Einträge, die auf „PageHandlerFactory-ISAPI-2.0“ und „PageHandlerFactory-ISAPI-2.0-64“ verweisen (geladen in Arbeitsprozesse im Anwendungspool im klassischen Modus gemäß der Einstellung „preCondition="classicMode"“).
Weil der Pipelinemodus auf der Ebene des Anwendungspools festgelegt wird, kann IIS 7.0 Webanwendungen im integrierten und klassischen Modus gleichzeitig ausführen. Die Arbeitsprozesse müssen dabei nur in verschiedenen Anwendungspools ausgeführt, können jedoch auf demselben Server gehostet werden.
Bedenken Sie, dass durch den integrierten und den klassischen Modus nur beeinflusst wird, wie IIS 7.0 ASP.NET in die Anforderungspipeline integriert. Diese Pipelinemodi haben keine direkten Auswirkungen auf PHP-Anwendungen. Das Modul „FastCgiModule“ und alle anderen systemeigenen Module werden ohne Vorbedingungen für den Pipelinemodus sowohl im integrierten als auch klassischen Modus geladen. FastCGI ist die bevorzugte Schnittstelle für die Ausführung des PHP-Skriptmoduls unter IIS 7.0. Anstatt FastCGI zu verwenden, können Sie auch eine Handlerzuordnung für das PHP-Skriptmodul über CGI erstellen, oder Sie können das Modul „IsapiModule“ in Verbindung mit PHP-ISAPI (php4isapi.dll) verwenden.
Meiner Ansicht nach sind diese Konfigurationsalternativen im Stil von IIS 6.0 jedoch veraltet, zumal FastCGI eine deutlich verbesserte Leistung und Stabilität zu bieten hat. CGI ist langsamer, da IIS einen neuen CGI-Prozess für jede HTTP-Anforderung initialisieren muss, während FastCGI CGI-Prozesse für mehrere Anforderungen wieder verwendet. ISAPI erfordert einen threadsicheren PHP-Build, was einen größeren Aufwand zur Folge hat als beim Ausführen eines nicht threadsicheren PHP-Builds.
Noch wichtiger ist vielleicht, dass nicht alle PHP-Erweiterungen in einer threadsicheren Version verfügbar sind, und von der Ausführung nicht threadsicherer Erweiterungen mit ISAPI ist abzuraten, da es hierdurch zu Stabilitätsproblemen auf dem Server kommen kann. FastCGI hingegen ist eine Umgebung mit Einzelparallelität wie CGI. FastCGI, das zur Ausführung nicht threadsicherer PHP-Dateien verwendet wird, ist stabil und schnell, und ist ganz sicher die Lösung für PHP 5 unter IIS 7.0. Außerdem ist FastCGI unter IIS 6.0 verfügbar, falls Sie für den Übergang zu IIS 7.0 noch nicht bereit sind.

Module und Funktionalität
IIS 7.0 verfügt über eine stark modularisierte Architektur oder (um es mit den Worten der IIS-Entwickler zu sagen) eine in Komponenten gegliederte Featuregruppe. Dies sind gute Nachrichten für Webadministratoren, die den Speicherbedarf und die Angriffsfläche von IIS 7.0 so klein wie möglich halten möchten. Durch Aktivierung verschiedener Module oder vielleicht gar das Ersetzen von Standardmodulen durch benutzerdefinierte Module können Sie die vollständige Kontrolle über die IIS 7.0-Features auf Ihren Webservern gewinnen.
Um ASP.NET im integrierten oder klassischen Modus sowie PHP-Anwendungen auf demselben Server ausführen zu können, müssen Sie mindestens die Webserverrolle und die zentralen Module installieren, um Anforderungsverarbeitung, Serverkonfiguration, ASP.NET, ISAPI und CGI zu unterstützen (einschließlich des FastCGI-Moduls). Hierzu können Sie die folgenden Befehlszeile verwenden:
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
Ich installiere in der Regel lieber IIS 7.0 mit allen verfügbaren Optionen auf meinem Bereitstellungsserver, um sicherzustellen, dass alle Komponenten und Verwaltungstools verfügbar sind, die ich benötige, um meine Webanwendungen schnell einsatzbereit zu machen. Meine Strategie besteht darin, zunächst dafür zu sorgen, dass alles funktioniert, und anschließend die Konfiguration durch Deinstallieren von Rollendiensten und Deaktivieren von Modulen einzugrenzen. Wenn eine Webanwendung Probleme bereitet, füge ich Rollendienste oder Module, die ich gerade entfernt habe, wieder hinzu.
Sie können ferner auswählen, ob Sie Paket-Manager (pkgmgr.exe) oder das IIS 7.0-Befehlszeilentool (appcmd.exe) verwenden oder den Abschnitt „globalModules“ in der Datei „applicationHost.config“ direkt bearbeiten möchten. Meiner Ansicht nach sind die grafischen Tools jedoch sehr praktisch. Beachten Sie, dass einige Module (z. B. „RequestFilteringModule“ und „StaticCompressionModule“) recht nützlich sind, obwohl sie genau genommen nicht für die Ausführung Ihrer Webanwendungen benötigt werden. Wenn Sie ein Modul deinstallieren, das für einen Anwendungspool erforderlich ist, erhalten Sie beim Zugriff auf Ihre Webanwendung einen HTTP-Fehler, wie in Abbildung 5 gezeigt.
Abbildung 5 Eine ASP.NET-Anwendung kann nicht im klassischen Modus ausgeführt werden, da IsapiModule fehlt (zum Vergrößern auf das Bild klicken)
Hinweis: Eine bewährte Methode besteht darin, sicherzustellen, dass auf allen IIS 7.0-Servern die gleiche Gruppe von Modulen installiert und aktiviert ist. Um die installierten Komponenten zu überprüfen, wechseln Sie zu „HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\“, und überprüfen Sie die Registrierungsschlüssel. Ein REG_DWORD-Wert von 0000 0001 für einen Registrierungsschlüssel, z. B. für NetFxEnvironment oder CGI, zeigt an, dass die entsprechende Komponente installiert ist.

Migration von Webanwendungen
Genug der Theorie. Nun ist es Zeit, die Ärmel hochzukrempeln und einige Webanwendungen auf IIS 7.0 zu verschieben. Wie bereits erwähnt, werden auf meinem Bereitstellungsserver IIS 7.0 mit allen verfügbaren Komponenten und der nicht threadsichere PHP 5-Build ausgeführt, registriert bei FastCGI. Zunächst muss ich jedoch einige grundlegenden Fragen stellen:
  • Erfordert die Webanwendung ein Datenbankverwaltungssystem, z. B. SQL Server oder MySQL?
  • Muss ich zusätzliche Komponenten installieren oder konfigurieren, z. B. ODBC-Verbindungen, COM-Objekte oder SSL-Zertifikate?
  • Erfordert die Webanwendung besondere Dienstkonten und erhöhte Berechtigungen für den lokalen oder Remotezugriff auf Dateifreigaben und andere Ressourcen?
  • Bestehen Abhängigkeiten von plattformspezifischen Features, die unter IIS 7.0 nicht verfügbar sind, z. B. Abhängigkeiten vom Apache-Modul für die URL-Umschreibung (mod_rewrite)?
Wenn Sie Fragen wie diese stellen, benötigen Sie weniger Zeit, Ihre Webanwendungen unter IIS 7.0 startbereit zu machen. Wenn Sie beispielsweise versuchen, eine PHP-Anwendung von Apache 2.2 zu migrieren, die „mod_rewrite“ verwendet (z. B. zum Zweck der Suchmaschinenfreundlichkeit oder um Bandbreitenaneignung durch Inline-Verknüpfung von Bildern zu verhindern), treten Probleme auf, bis Sie eine kompatible benutzerdefinierte Lösung für die URL-Umschreibung unter IIS 7.0 implementieren. Glücklicherweise erfordert osCommerce keine mod_rewrite-Funktion unter IIS 7.0, auf einige Pakete zur Suchmoduloptimierung könnte dies jedoch zutreffen.
Nachdem ich die erforderlichen zusätzlichen Komponenten bestimmt und auf dem Bereitstellungsserver installiert habe, kann ich nun meine Webanwendungen startklar machen. Auch jetzt gibt es wieder einige Fragen, die ich mir stellen möchte:
  • Wie sieht die einfachste Konfiguration aus, die ich zur Unterstützung der Webanwendung verwenden kann?
  • Welche Konfiguration wird derzeit in der Produktionsumgebung verwendet?
  • Kann ich die Webanwendungskonfiguration auf der neuen Plattform optimieren?
  • Welchen Mindestsatz an Rollendiensten und Modulen benötigt die Webanwendung, um in der gewünschten Konfiguration zu funktionieren?
Wenn Sie die Webanwendung in der einfachsten Konfiguration ausführen, können Sie rasch herausfinden, ob sie funktioniert. Verläuft alles ohne Probleme, können Sie eine Konfiguration anwenden, die der in der vorhandenen Produktionsumgebung ähnelt, und Produktionsdaten in die Testdatenbanken importieren. Einige Probleme dürften selbstverständlich nur in erweiterten Konfigurationen auftreten.
Vielleicht entdecken Sie beim Spiegeln Ihrer Produktionskonfiguration in einer Testumgebung auch Möglichkeiten für Verbesserungen. Das Ablegen der Datei „applicationHost.config“ in einer UNC-Freigabe bietet eine hervorragende Möglichkeit, die Konfiguration mehrerer Webserver zu zentralisieren. Um die Fehlertoleranz durch Redundanz und Inhaltssynchronisierung zu erhöhen, sollten Sie die Implementierung von DFS-Replikation erwägen, einem statusbasierten Multimasterreplikationsmodul, das in Windows Server 2003 R2 und Windows Server 2008 verfügbar ist. Außerdem können Sie die Speicheranforderungen auf Web-Front-End-Computern minimieren, indem Sie die Inhaltsdateien Ihrer Webanwendungen in UNC-Freigaben ablegen.
Weitere potenzielle Optimierungen betreffen die Sicherheit oder dynamische Zwischenspeicherung. Auf Sicherheits- und Leistungsoptimierungen bin ich in meiner Testumgebung nicht eingegangen, weil dies den Rahmen dieses Artikels sprengen würde. Ebenso wenig habe ich DFS konfiguriert, um die Installation weiterer Server zu vermeiden. In den Schritt-für-Schritt-Anweisungen im Begleitmaterial finden Sie ein vereinfachtes Beispiel für das Hosten der Datei „applicationHost.config“ und des Webinhalts in UNC-Freigaben. In Abbildung 6 wird gezeigt, wie eine UNC-basierte Webfarm in DFS implementiert werden kann.
Abbildung 6 Webfarmbereitstellung mit der Datei „applicationHost.config“ und Webinhalt in UNC-Freigaben (zum Vergrößern auf das Bild klicken)

Zusammenfassung
IIS 7.0 ist eine beeindruckende Webserverplattform. Trotz der neu gestalteten Kernarchitektur bleibt die Abwärtskompatibilität mit IIS 6.0 fast zu 100 Prozent erhalten. IIS 7.0 sollte in der Lage sein, die meisten vorhandenen ASP.NET-Webanwendungen ohne Änderung auszuführen. Angesichts des Umfangs der Änderungen an der Architektur können Sie sich jedoch nicht darauf verlassen, dass keine Kompatibilitätsprobleme auftreten.
Ganz gleich, ob Sie ASP.NET- oder PHP- Webanwendungen zu IIS 7.0 migrieren – am besten eignet sich ein gestaffelter Ansatz. Wichtig sind richtige Planung, Vorbereitung, gründliches Testen und das Dokumentieren von Code- und Konfigurationsänderungen.
IIS 7.0 ist den Arbeitsaufwand wert. In Bereichen wie Sicherheit, Leistung, Konfigurierbarkeit und Flexibilität gibt es viele Verbesserungen. Die umfassende Erläuterung aller dieser Verbesserungen würde ein ganzes Buch füllen. Zentralisierte Konfiguration und Inhaltsfreigabe auf der Basis von UNC-Freigaben, delegierte Konfiguration mittels web.config-Dateien in Anwendungsverzeichnissen, verbesserte Verwaltungstools, detaillierte Diagnoseinformationen und Ablaufverfolgung für Anforderungsfehler sowie dynamische Ausgabezwischenspeicherung sind mit Sicherheit Features, die den Beifall von Webadministratoren finden.
Entwickler profitieren von der Fähigkeit, systemeigene und verwaltete Module in der Pipeline für die Anforderungsverarbeitung zu mischen. Entwickler von PHP-Anwendungen sind ganz sicher von den Verbesserungen in puncto Leistung und Stabilität beeindruckt, die FastCGI unter IIS 7.0 mit sich bringt.
Schließlich muss noch ein weiterer wichtiger Faktor erwähnt werden, der IT-Experten zum Erfolg mit IIS 7.0 verhilft: das Microsoft IIS Community Portal (www.iis.net). Dort finden Sie alle Informationen, die Sie benötigen. Dazu gehören ausführliche Artikel über die neue Architektur, Quellcode für C++- und ASP.NET-Entwickler, der veranschaulicht, wie IIS 7.0-Module erstellt werden, sowie Schritt-für-Schritt-Anweisungen, um PHP-Anwendungen zum Laufen zu bringen. Diese Website sollten Sie sich unbedingt ansehen. Sie ist ein gute Adresse, wenn Sie Antworten auf IIS-bezogene Fragen suchen.

Fergus Strachan ist Gründer und Leiter von Maestra Ltd London, einer Beratungsfirma mit Spezialisierung auf IT-Infrastrukturentwurf und Projektmanagement-Unterstützung. Zu den Kunden des Unternehmens gehören internationale Banken und Bildungsinstitutionen in Großbritannien. Fergus Strachan verfasst Artikel über Microsoft-Servertechnologie und ist Autor der Publikation Integrating ISA Server 2006 with Microsoft Exchange 2007. Er ist Mitautor von Microsoft Exchange Server 2003 Resource Kit.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig


Kommunikation und Zusammenarbeit
Planen Ihrer Migration zu Unified Messaging
Jeff Goodwin
Auf einen Blick:
  • Ein kurzer Überblick über die Geschichte von Voicemail
  • Dinge, die es beim Planen Ihrer Migration zu beachten gilt
  • Migrationsstrategien
  • Herausforderungen bei mehreren Standorten

Inhalt
Ein kurzer Überblick über die Geschichte von Voicemail
Planen Ihrer Migration
Praktische Migrationsstrategien
Exemplarische Vorgehensweise für eine Migration
Die Bedeutung der Einhaltung eines Plans
Die Migration von einem Legacyvoicemailsystem zu einer Unified Messaging-Plattform kann ein herausforderndes Projekt sein. Doch bei richtiger Planung kann diese Migration ziemlich problemlos ablaufen, wobei Störungen für die Endbenutzer gleichzeitig minimiert werden können. Tatsächlich sollte das Minimieren der
Dienstunterbrechung beim Ausführen eines Migrationsprojekts dieser Art Ihr Hauptziel sein.
Um zu wissen, was während der Migration eingeplant werden sollte, müssen Sie zuerst verstehen, warum Voicemail in Unternehmen als erfolgsentscheidende Anwendung gilt. Mithilfe dieser grundlegenden Informationen werden Sie verstehen, welche Features beim Migrieren zu Unified Messaging implementiert werden müssen und warum diese Features für Administratoren wichtig sind.

Ein kurzer Überblick über die Geschichte von Voicemail
Da Sie Ihren Reiseverlauf nicht richtig planen können, wenn Sie nicht wissen, welches Ihr Ausgangsort ist, erhalten Sie hier einen kurzen Überblick über Voicemailsysteme, über ihren Ursprung und ihre Architektur. Es ist strittig, wer das erste Voicemailsystem erfunden hat. Das erste kommerziell erhältliche Voicemailsystem hieß VMX, und die Abkürzung stand für Voice Message Exchange.
VMX sollte ursprünglich eine Möglichkeit für die Sprachkommunikation mit anderen Mitarbeitern innerhalb eines Unternehmens bieten, so wie heute E-Mail-Nachrichten verwendet werden. Das System verfügte über Befehle zum Senden einer Nachricht, Weiterleiten einer Nachricht und Antworten auf eine Nachricht. Wenn eine Nachricht hinterlassen wurde, erhielt der Benutzer eine Benachrichtigung. Es gab verschiedene Benachrichtigungsmethoden einschließlich Anrufen nach außerhalb (Anrufen der betreffenden Person über eine bestimmte Telefonnummer) und einem Licht zur Nachrichtenanzeige (eine Blinkanzeige auf dem Telefon des Betreffenden).
Als VMX an Popularität gewann, vernetzten Organisationen ihre Voicemailsysteme miteinander. Dies sorgte für eine unternehmensweite Voicemaillösung, mit der Mitarbeiter Broadcastnachrichten an unternehmensweite Verteilerlisten senden konnten.
Um mit dem Voicemailsystem interagieren zu können, musste eine Tonwahlbenutzeroberfläche (TUI) erstellt werden. Diese TUIs haben sich im Verlauf der Jahre verändert, und leider gibt es keine Standardbenutzeroberfläche für Voicemail. Wenn Ihr Handy mit Voicemail ausgestattet ist, sind Sie wahrscheinlich daran gewöhnt, etwas Ähnliches wie folgende Nachricht zu hören: „Für Voicemail drücken Sie die 1“. Doch da sich sprachgesteuerte Voicemailsysteme mit Sprachbenutzeroberflächen (VUIs) immer mehr durchsetzen, ist die TUI nicht mehr so wichtig wie früher. Doch die Vorliebe von Benutzern für eine bestimmte Benutzeroberfläche sollte nicht unterschätzt werden.
Voicemailsysteme in Unternehmen beruhen heute auf zwei unterschiedlichen Architekturen: verteilt und zentralisiert. In Abbildung 1 haben die Büros in Seattle, New York und Austin eine verteilte Voicemailarchitektur, bei der sich die Voicemailsysteme für die einzelnen Orte jeweils am betreffenden Standort befinden. Im Gegensatz dazu haben die Büros in London, Paris und Glasgow ein zentralisiertes Modell, wobei die PBX-Infrastruktur vernetzt ist und alle Anrufe an den zentralen Standort in London zurückgeleitet werden. Beide Modelle haben Vor- und Nachteile. Doch selbst in einem verteilten Modell können die Voicemailsysteme zur Nachrichtenübermittlung zwischen den Standorten vernetzt werden.
Abbildung 1 Die beiden gebräuchlichen Voicemailarchitekturmodelle (Klicken Sie auf das Bild, um es zu vergrößern)
Es gibt drei Hauptgründe, warum sich eine Organisation für ein verteiltes Modell entscheidet: Bedarf an lokaler Verfügbarkeit, die Verwendung verschiedenartiger PBX-Systeme, die nicht vernetzt werden können, sowie Einschränkungen in Bezug auf einheitliche Wählpläne.
Einige Organisationen benötigen dieses Voicemailsystem, damit das lokale PBX- und Voicemailsystem im Fall eines Netzwerkausfalls noch normal funktioniert und der Standort über vollständige Systemfunktionalität verfügt. Interaktive Sprachantwortsysteme (IVR) funktionieren noch, und Anrufer von außerhalb können Nachrichten hinterlassen. Für die Endbenutzer gibt es praktisch keine Auswirkungen, und die Arbeit kann normal fortgesetzt werden. Vielleicht kommt Ihnen das bekannt vor. Es ist derselbe Grund, warum sich viele Organisationen dafür entscheiden, ihre Server, auf denen Microsoft® Exchange Server ausgeführt wird, zu lokalisieren. Ihre Organisation könnte eine Risikoanalyse durchführen, um festzustellen, ob diese lokale Überlebensfähigkeit notwendig ist.
Wenn eine Organisation durch Akquisitionen wächst, verfügen die Remotestandorte oft über PBX-Plattformen, die nicht mit der übrigen Infrastruktur vernetzt werden können. In diesem Fall können Organisationen die PBX entweder austauschen, was teuer sein kann, oder den Standort so belassen und die Voicemailplattform vernetzen, um einen nahtlosen Voicemessagingaustausch bereitzustellen. Drittanbieterserver sind ebenfalls zum Vernetzen Ihrer verschiedenartigen Voicemailsysteme verfügbar.
Zum Vernetzen von PBXs ist ein einheitlicher Wählplan (oder UDP) erforderlich. Ein UDP besagt, dass sich Telefon- und Voicemailnebenanschlüsse nicht überlappen können. In Abbildung 1 sehen Sie, dass Seattle, New York und Austin sich überlappende Nebenanschlussbereiche haben. Dies ist darauf zurückzuführen, dass es keinen UDP für die Standorte in den USA gibt. Ein UDP könnte durch Erweitern der Nebenanschlussbereiche auf 7 oder 10 Ziffern erstellt werden, doch das führt zu anderen Problemen.
Möglicherweise müssten die Wahlvorlagen bei jedem Telefon, alle Benutzernebenstellen in der PBX und alle in das System integrierte Anwendungen geändert werden. Dies kann bei Mitarbeitern, die sich 7- oder 10-stellige Zahlen merken und diese wählen müssen, um einen Kollegen in einem benachbarten Büro anzurufen, zu Frustration führen
Obwohl diese grundlegenden Features und architektonischen Herausforderungen im Laufe der Jahre verbessert wurden, sind die Grundlagen von Voicemail unverändert geblieben. Nachrichtenaustausch, Vernetzen, Benachrichtigungsmethoden, Benutzeroberfläche und Architektur sind wichtige Faktoren, die es beim Planen einer Migration zu bedenken gilt.

Planen Ihrer Migration
Unified Messaging bringt Änderungen für alle Bereiche der Organisation mit sich, angefangen bei der Interaktion der Benutzer mit Voicemail über den Entwurf der Architektur bis hin zur Handhabung der Verwaltung durch die Administratoren. Alle diese Unterschiede müssen beim Migrieren zu einem Unified Messaging-System angesprochen werden. Hier finden Sie eine Prüfliste der Dinge, die beim Planen Ihrer Migration berücksichtigt werden müssen.
Nachrichtenvernetzung In jeder Organisation, die von einer Legacyvoicemailplattform zum Exchange Unified Messaging übergeht, müssen beide Systeme für eine gewisse Zeit nebeneinander bestehen. Wenn Ihre Organisation die Nachrichtenvernetzung, also ein System, bei dem verschiedene Voicemailsysteme eingesetzt werden, bereits bereitgestellt hat, fügen Sie das Unified Messaging-System einfach zur Liste vorhandener Systeme hinzu. Ich empfehle die Nachrichtenvernetzung für alle Organisationen, die über mehrere Standorte mit separaten Voicemail- oder PBX-Systemen verfügen.
Infrastruktur Beim Entwerfen der Infrastruktur für Unified Messaging sind Entscheidungen zu Vernetzungsanforderungen, Telefonieintegration, Serververteilung und Ähnlichem erforderlich. Wenn Sie mit grundlegenden Bereitstellungsstrategien nicht schon vertraut sind, sollten Sie meinen vorherigen Artikel „Bereitstellen von Unified Messaging mit Exchange Server 2007" lesen (siehe technet.microsoft.com/magazine/cc137737).
Automatisierte Telefonzentralen Viele Systeme enthalten mehrere automatisierte Telefonzentralen, beispielsweise für tagsüber, nachts und verschiedene Abteilungen. Sie müssen mit dem Telekomteam Ihrer Organisation zusammenarbeiten, um die automatisierten Telefonzentralen auf den Legacyvoicemailsystemen zu spiegeln.
Nachrichtenanzeige Sie würden es vielleicht bevorzugen, wenn Ihre Lösung auf Nachrichtenanzeigen verzichten könnte, doch Ihre Benutzer wünschen sich dieses Feature möglicherweise. Unterschätzen Sie daher nicht, wie sehr die Benutzer an die Benachrichtigung per roter Leuchte gewöhnt sein können. Glücklicherweise gibt es mehrere Unternehmen, die Anwendungen für die Nachrichtenanzeige für Exchange Server entwickelt haben.
Faxunterstützung Viele Legacyvoicemailplattformen unterstützen eingehende Faxnachrichten. Exchange Unified Messaging unterstützt eingehende Faxfunktionen ebenfalls, sodass Sie die Unterstützung dieser Funktionen in Ihrer neuen Bereitstellung möglicherweise einplanen möchten.
Interaktive Sprachantwort Einige Legacyvoicemailplattformen unterstützen interaktive Sprachantwortanwendungen (IVR), die von Exchange Unified Messaging nicht dupliziert werden können. Sie können diese Systeme so belassen, bis es eine passende Alternative gibt.
Verwaltung Exchange Unified Messaging stützt sich auf Active Directory® und die Exchange-Postfachserverrolle. Sie müssen einplanen, wie sich eine Unified Messaging-Bereitstellung auf die Verwaltung, Systemanforderungen und Ähnliches auswirkt.
Benutzeroberfläche Beim Einführen einer neuen Benutzeroberfläche müssen Schulungen für Ihre Benutzer bereitgestellt werden. Exchange Unified Messaging setzt eine Benutzeroberfläche ein, die der der meisten Handyanbieter ähnelt, sodass sie für die meisten Benutzer intuitiv sein sollte. Zudem wird die Spracherkennung verwendet, sodass die Benutzer keine Tonwahl verwenden müssen. In Exchange Server wird dies als Outlook® Voice Access bezeichnet.
Schulung Unified Messaging sorgt für einen Paradigmenwechsel bei der Art und Weise, wie Benutzer kommunizieren und Voicemail verwenden. Über die Benutzeroberfläche hinausgehend müssen Sie Ihren Benutzern Schulungsmöglichkeiten anbieten, damit diese bewährte Methoden erlernen und die neuen, effizienteren Möglichkeiten zur Kommunikation vorgestellt werden. Die Benutzer wissen möglicherweise nicht, wie sie mit Voicemail in ihrem E-Mail-Posteingang interagieren sollen oder wie einige erweiterte Unified Messaging-Einstellungen konfiguriert werden.

Praktische Migrationsstrategien
Beim Migrieren einer großen Organisation zu einer Unified Messaging-Lösung gibt es zweifellos Herausforderungen. Ich bin jedoch bereits seit 10 Jahren in der einheitlichen Kommunikation tätig und weiß, dass selbst sehr komplexe Organisationen mit sehr spezifischen Anforderungen die Migration erfolgreich durchgeführt haben.
Egal, ob Sie es mit einer Organisation mit nur einem oder mehreren Standorten zu tun haben, ist es hilfreich, Ihre Migrationsstrategie um diese fünf grundlegenden Schritte herum aufzubauen:
  1. Planen und Entwerfen Ihrer Lösung.
  2. Installieren und Konfigurieren der Unified Messaging-Serverrolle.
  3. Migrieren einer Pilotgruppe.
  4. Überarbeiten Ihres Entwurfs auf der Grundlage von Feedback aus der Pilotgruppe.
  5. Migrieren Ihrer Benutzer.
Selbstverständlich stehen Organisationen mit mehreren Standorten bestimmten Herausforderungen gegenüber, die in Szenarios mit nur einem Standort gewöhnlich nicht gelten. Diese Herausforderungen werden in der Randleiste „Herausforderungen bei mehreren Standorten“ gesondert erörtert.
Das Planen und Entwerfen Ihrer Lösung ist der wichtigste Schritt im Migrationsprozess. Ich empfehle, dem Projekt ein Unified Messaging-Team zuzuordnen. Dieses Team sollte Vertreter aus verschiedenen Bereichen Ihrer Organisation mit Fachkenntnissen in der Telekommunikation, Active Directory, Exchange, Vernetzung, Sicherheit, Schulung und Projektmanagement umfassen. Und besorgen Sie sich eine ausführliche architektonische Zeichnung der vorhandenen PBX-, Voicemail- und E-Mail-Infrastrukturen Ihres Unternehmens.
Wenn der Entwurf vorliegt, kann die Unified Messaging-Serverrolle installiert und konfiguriert werden. Sie können problemlos einen Unified Messaging-Server parallel zu Ihrem vorhandenen Legacyvoicemailsystem installieren. Dabei sollten jedoch die dokumentierten, bewährten Methoden befolgt werden.
Jetzt können Sie Ihren Unified Messaging-Server ausprobieren. Legen Sie eine kleine Pilotgruppe von Benutzern fest, und migrieren Sie diese zu dem neuen System. Eine Gruppe von 25 bis 50 Benutzern reicht aus. Wählen Sie diese Benutzer sorgfältig aus, und erstellen Sie eine Pilotgruppe, die aus einer Gruppe unterschiedlicher Benutzer besteht, angefangen bei IT-und Telekommunikationsmitarbeitern bis hin zu Abteilungsleitern und Vertriebspersonal. Durch das Einbeziehen einer großen Auswahl an Personen können Sie besser feststellen, ob Ihr Entwurf zielgerecht ist, welche spezifischen Anforderungen berücksichtigt werden müssen, welche Schulung für die Benutzer notwendig sein könnte und so weiter.
Nachdem Sie Feedback von der Pilotgruppe erhalten haben, müssen Sie Ihren Entwurf überarbeiten, um die in den Tests aufgedeckten Probleme zu behandeln. Insbesondere sollten die Elemente erneut unter die Lupe genommen werden, die in dem Abschnitt „Dinge, die es zu beachten gilt“ erörtert wurden. Stellen Sie sicher, dass diese Punkte für Ihre Organisation entsprechend behandelt wurden. Beachten Sie, dass die häufigsten Änderungen hier die Schulung betreffen.
Der letzte Schritt ist das Migrieren Ihrer Benutzer. Es gibt viele Meinungen und Strategien darüber, wie das System in die gesamte Produktion zu migrieren ist. Die zwei primären Methoden sind die schrittweise Migration und die einmalige Übertragung.
Wenn Sie sich für die schrittweise Migration Ihrer Benutzercommunity über einen Zeitraum von Wochen oder Monaten entscheiden, erstellen Sie Voicemailinseln zwischen Ihren Legacy- und Unified Messaging-Benutzern. Dies verhindert, dass Benutzer Nachrichten gegenseitig über Voicemail weiterleiten. Wenn Ihr Entwurf außerdem keine Nachrichtenvernetzungslösung umfasst, wird ein Teil Ihrer Geschäftskommunikation unterbrochen. Wenn Sie sich für diese Methode entscheiden, ist es empfehlenswert, eine Nachrichtenvernetzungslösung in Ihren ursprünglichen Entwurf aufzunehmen.
Bei der einmaligen Übertragung werden alle Benutzer in einer einzelnen Phase migriert. Organisationen führen diese Art der Migration in der Regel an einem Wochenende durch, sodass Zeit zum Testen des Systems vorhanden ist, Konfigurationsänderungen durchgeführt werden können und die Migration zurückgezogen werden kann, falls eine ernste Blockierung vorhanden ist.
Egal, für welche Methode Sie sich entscheiden, das Helpdeskpersonal sollte unbedingt bezüglich allgemeiner Fragen und Antworten geschult werden, die aus der Pilotgruppe hervorgegangen sind. Es sollte auch sichergestellt werden, dass die Helpdeskmitarbeiter das Durchführen von Hauptaufgaben, einschließlich Aktivieren eines Benutzers, Überprüfen der Aktivierung eines Benutzers und Ändern eines Kennworts, beherrschen.

Exemplarische Vorgehensweise für eine Migration
Beim Durchführen meiner Beispielmigration sollten Sie bedenken, dass das Hauptziel für eine erfolgreiche Migration zu Unified Messaging darin besteht, das Voicemailfach des Benutzers von einer Legacyvoicemailplattform zu Unified Messaging mit möglichst geringen Unterbrechungen für die (internen und externen) Benutzer zu migrieren.
Abbildung 2 stellt die Architektur einer Organisation dar. Es bestehen keine Pläne, diese gemischte Exchange-Architektur zu ändern. Die Büros in den USA haben ein primäres Datencenter, das sich in Seattle befindet. Alle IT-Anwendungen für Austin werden von Seattle aus bedient, und das New Yorker Büro benötigt lokalisierte Exchange-Dienste. Voicemail für die USA-Standorte wird aufgrund der verschiedenartigen PBX-Infrastruktur verteilt. Aus technischer Sicht kann die PBX-Infrastruktur zum Bereitstellen von zentralisierter Voicemail nicht vernetzt werden. Im Gegensatz dazu haben die europäischen Büros ein zentralisiertes Datencenter, das sich in London befindet. Alle IT- und die Telekommunikationsanwendungen in Europa werden von diesem zentralen Datencenter aus bedient.
Abbildung 2 Beispielarchitektur vor der Migration (Klicken Sie auf das Bild, um es zu vergrößern)
Die gesamte Voicemailinfrastruktur basiert auf der Octel-Plattform (diese ist auch unter dem Namen „Avaya“ bekannt). Alle Voicemailsysteme wurden mithilfe von Octel Analog Networking (OAN) vernetzt, wobei es sich um ein proprietäres Netzwerkprotokoll handelt, bei dem Analogtelefonleitungen und Ferngespräche zum Senden von vernetzten Voicemailnachrichten verwendet werden. Diese Architektur ermöglicht unternehmensweites Voicemessaging zwischen den Standorten.
Herausforderungen bei mehreren Standorten
Organisationen mit mehrere Standorten stehen beim Bereitstellen von Unified Messaging vor einer ganzen Reihe von Herausforderungen. Glücklicherweise können Sie aus einigen Herausforderungen lernen, mit denen sich andere Organisationen auseinandersetzen mussten. Dieser Artikel kann nicht auf alle Herausforderung eingehen, aber ich kann die häufigsten Herausforderungen beschreiben, denen ich bei der Arbeit mit verschiedenen Organisationen begegnet bin.
„Ich habe eine zentralisierte Exchange Server-Architektur und eine gemischte Telefonieumgebung.“
Das Entwerfen einer verteilten Umgebung ist einfach. Sie platzieren einen Unified Messaging-Server und integrieren ihn an jedem Standort in die lokale PBX. Doch was tun Sie bei einer zentralisierten oder sogar gemischten Umgebung? Die Frage, die Sie sich stellen müssen, lautet, ob das Vermeiden lokaler Unified Messaging-Störungen am Standort erforderlich ist. In diesem Fall kann die Verbindung dieses Standorts zum zentralisierten Exchange-Server unterbrochen werden, wobei die Funktion der automatisierten Telefonzentrale dennoch bereitgestellt wird und Anrufer von außerhalb (bei denen es sich um Kunden handeln könnte) Nachrichten hinterlassen können. Die Antwort hängt wahrscheinlich davon ab, wie erfolgsentscheidend dieser Standort ist und wie überschaubar die Lösung sein wird.
Wenn das Vermeiden lokaler Störungen für Ihren Standort erforderlich ist, könnte ein Unified Messaging-Remoteserver an diesem Standort eine gute Option sein. Wenn dies nicht erforderlich ist, können Sie einen SIP-Gateway an dem lokalen Standort installieren. Exchange Unified Messaging bietet die Flexibilität, dass die PBX-Infrastruktur nicht vernetzt werden muss und kein einheitlicher Wählplan erforderlich ist.
„Ich bin dabei, meine Exchange-Architektur zu aktualisieren.“
Viele Kunden zögern, mit einer Unified Messaging-Migration zu beginnen, wenn sie dabei sind, ihre Exchange-Infrastruktur zu aktualisieren. Wenn Sie bereits entschieden haben, zu Unified Messaging zu migrieren, rate ich dazu, dies zu tun, während der Exchange-Server aktualisiert wird. Richten Sie sich einfach nach Ihren Aktualisierungsplänen, wodurch das Projekt nicht wesentlich komplexer gestaltet wird.
„Ich habe viele kleine Standorte mit weniger als 10 Mitarbeitern, und einige dieser Standorte verfügen nicht über eine PBX.“
Bei kleineren Standorten, die vor Ort mit einer PBX ausgestattet sind, muss einfach nur ein SIP-Gateway am lokalen Standort installiert werden. Für Standorte ohne PBX vor Ort gibt es Telefonieverfahren, die verwendet werden können, um die Telefone an die zentrale PBX zum Anrufrouting an das Unified Messaging-System weiterzuleiten. Sie können also Unified Messaging-Dienste für die kleineren Remotestandorte Ihrer Organisation recht preiswert bereitstellen.
Es sollte beachtet werden, dass diese kleineren Standorte einen hervorragenden Prüfstand für Ihre Migration bieten. Eine allgemeine Migrationsstrategie besteht darin, am Rand des Netzwerks zu beginnen und dann zum Kern vorzudringen. Die kleineren Standorte werden zuerst migriert, bevor Sie eine Nachbesprechung mit dem Unified Messaging-Team durchführen, um zu erfahren, was reibungslos verlaufen ist und welche Herausforderungen vorhanden waren. Diese gewonnenen Erfahrungen können dann beim Migrieren des nächsten Standorts implementiert werden.
Das Unified Messaging-Team hat beschlossen, die Migration vom Rand des Netzwerks zum Kern durchzuführen. Bei allen Standorten erfolgt die Platzierung des Unified Messaging-Servers durch Befolgen der Exchange-Serverarchitektur, wobei es sich um eine bewährte Methode handelt. Das Team erstellt seine eigene Planungsdokumentation für jeden Standort, wobei die im Abschnitt „Dinge, die es zu beachten gilt“ erörterten Elemente berücksichtigt werden. Die Dokumentation wird während der Installation und Konfiguration der Server, während der Benutzerschulung und beim Planen der Migrationsstrategien verwendet.
Bei jedem Standort plant das Team eine einmalige Übertragung der Benutzer zum Unified Messaging-System und Belassen der Legacyplattform, um IVR-Anwendungen zu unterstützen, die weiterhin verwendet werden, bis eine alternative Lösung gefunden werden kann. Das Team beschloss, nach der Migration 30 Tage lang zu warten, bis der nächste Standort an der Reihe war. Die Wartezeit soll sicherstellen, dass sich jeder Standort an die neue Plattform angepasst hat, bevor weitere Benutzer migriert und dem Helpdesk weitere Supportanrufe hinzugefügt werden.
Die Organisation entscheidet, den Standort Austin zuerst zu migrieren. Da der E-Mail-Dienst in Austin von Seattle aus bedient wird, installiert das Team die Unified Messaging-Serverrolle in Seattle und stellt PBX-Integration durch Installieren eines SIP-Gateways in Austin bereit. Und da die Legacyvoicemailplattform vernetzt ist, muss das Team die Notwendigkeit zum Vernetzen der Unified Messaging-Plattform durch Installieren eines Nachrichtenvernetzungsservers erfüllen. Die Benutzer werden auf dem neuen System geschult, und die Migration verläuft reibungslos, sodass das Team entscheidet, New York als nächsten Standort zu migrieren.
Der Standort New York verfügt über eigene Postfach- und Hubtransportserver. Den bewährten Methoden zufolge sollte deshalb ein Unified Messaging-Server in New York installiert werden. Das Team installiert den Server, wobei den Vorgaben der Migrationsplanungsdokumente gefolgt wird. Der Server wird der Liste der Knoten im Nachrichtvernetzungsserver hinzugefügt, um in das Voicemailnetzwerk integriert zu werden. Die Benutzer werden geschult, und die Migration zu Unified Messaging verläuft reibungslos.
Am Standort Seattle wurde bereits ein Unified Messaging-Server aus der Migrationsphase in Austin bereitgestellt. Das Team entscheidet, dass der Server über genug Voicemailports verfügt, um sowohl den Standort Seattle als auch Austin zu unterstützen. Die Benutzer in Seattle werden geschult, und die Migration zu Unified Messaging verläuft reibungslos.
Das Entwerfen der Architektur in Europa ist viel einfacher. Die PBX-Infrastruktur wird vernetzt, und Exchange wird zentralisiert. Ein Unified Messaging-Server wird in London bereitgestellt, und jeder Standort wird migriert, wobei mit dem kleinsten begonnen wird. Abbildung 3 stellt die endgültige Architektur dar.
Abbildung 3 Beispielarchitektur nach der Migration (Klicken Sie auf das Bild, um es zu vergrößern)

Die Bedeutung der Einhaltung eines Plans
Ich werde oft gebeten, Probleme bei fehlgeschlagenen Unified Messaging-Migrationen zu beseitigen. Viele dieser Organisationen haben sich nicht an eine oder mehrere wichtige Regeln gehalten.
Zuerst gilt es zu bedenken, dass es sich nicht nur um ein Voicemailsystem handelt. Es ist eine erfolgsentscheidende Anwendung und sollte als solche behandelt werden. Die Benutzer nutzen Voicemailtechnologien zum Austausch von Informationen. Bedenken Sie, dass es sich um eine Geschäftsanwendung handelt, und planen Sie Ihre Migration so, dass alle in diesem Artikel erörterten Überlegungen berücksichtigt werden.
Das Telekommunikationsteam muss bei jeder Migration zu Unified Messaging unbedingt einbezogen werden. Das Telekomteam kennt die in die Unternehmensinfrastruktur integrierten Telefonieanwendungen am besten.
Beim Migrieren zu Unified Messaging sollte die Unternehmenslösung geplant werden. Obwohl Sie zu Anfang möglicherweise nur einen einzelnen Standort implementieren, sollten Sie immer das große Ganze vor Augen haben. So wirkt sich das Implementieren eines einzelnen Standorts ohne Bereitstellen von Nachrichtenvernetzung für die anderen Standorte auf die Kommunikation der Benutzer untereinander aus. Dies kann eine große Aufgabe sein, und Sie sollten sich nicht fürchten, einen Spezialisten zum Entwerfen einer Architektur hinzuzuziehen, die Ihre gesamten IT-Anwendungen berücksichtigt.
Und schließlich sollten Sie die Bedeutung der Schulung nicht unterschätzen. Unified Messaging sorgt für einen Paradigmenwechsel bei der Art und Weise, wie Benutzer kommunizieren und Voicemail verwenden. Was Ihnen intuitiv scheint, mag für andere nicht so intuitiv sein. Gute Schulung ist für einen reibungslosen Übergang wesentlich.

Jeff Goodwin ist Senior Technologist bei der VIA Group und spezialisiert sich auf Entwurf und Bereitstellung von Exchange und Unified Messaging. Er ist unter goodwin@theviagroup.com zu erreichen.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Kommunikation und Zusammenarbeit
Wie Sprache OCS 2007 steuert
Rajesh Ramanathan
Auf einen Blick:
  • Durchführen von Anrufen in OCS 2007
  • Sichern von Anrufen
  • Multimodale Gespräche in OCS
  • Integration in Exchange UM für Voicemail

Inhalt
Einfache Sprachanrufe
Verwenden von Telefonnummern
Sichere Anrufe
Durchqueren von NATs und Firewalls
Weiterleiten von Telefonnummern
Eingangsrouting
Qualitätsberichterstellung und Problembehandlung
Der Gesamtprozess
Multimodales Verhalten und Gespräche
Voicemail
Zusammenfassung
Im ersten Teil dieser Reihe über Microsoft Office Communication Server (OCS) 2007 wurde aufgezeigt, wie OCS auf den Stärken von Live Communication Server (LCS) 2005 aufbaut, um
für den Unternehmensbereich verbesserte Instant Messaging (IM)- und Anwesenheitsfunktionen sowie erweiterte Medien- und Telefonfunktionalität zu bieten (siehe TechNet Magazin vom Februar 2008 unter technet.microsoft.com/magazine/cc194409). In diesem Artikel wird dabei der Aspekt Voice over IP (VoIP) eingehender behandelt. Es wird erläutert, wie sich im OCS-System einfache Sprachanrufe tätigen lassen, und die Technologie wird Schicht für Schicht besprochen, sodass auf jede Komponente und der entsprechenden Funktionalität gesondert eingegangen wird.
Wie im vorigen Artikel bereits erwähnt wurde, kann OCS so eingerichtet werden, dass den Benutzern Telefonie in einer Reihe verschiedener Konfigurationen zur Verfügung steht:
Enterprise Voice Dies ist die vollständige einheitliche Kommunikationslösung, bei der OCS zusammen mit dem Microsoft® Mediation Server ohne Nebenstellenanlage verwendet wird. Exchange Unified Messaging (UM) bietet in diesem System Voicemailfeatures. Benutzer, die über diesen Dienst verfügen, werden im nachfolgenden Teil dieses Artikels als „UC-Benutzer“ bezeichnet. Mit dem Begriff „UC-Endpunkt“ wird im Folgenden ein Client in dieser Konfiguration bezeichnet.
Enterprise Voice mit PBX-Integration Bei dieser Konfiguration können Benutzer die Vorteile der einheitlichen Kommunikation nutzen und parallel dazu die vorhandenen PBX-Telefone auf ihren Desktops beibehalten. OCS und PBX lassen sich parallel zueinander so einrichten, dass für eingehende Anrufe an Endpunkten von Office Communicator und der Nebenstellenanlage gleichzeitig ein Klingelsignal erfolgt. Anrufrouting und Voicemaildienste laufen immer noch über die Nebenstellenanlage.
Remote Call Control Bei diesem Feature wird das PBX-Telefon als Haupttelefon verwendet, und das Telefon lässt sich über den Office Communicator-Client steuern.

Einfache Sprachanrufe
Dieser Artikel konzentriert sich auf die Prozesse von Enterprise Voice-Benutzern. Einfache Sprachanrufe werden im OCS-System, wie in RFC 3261 beschrieben, mithilfe des SIP INVITE-Mechanismus eingerichtet. Der OCS-Server übernimmt die Rolle eines Proxys, ähnlich wie ein Postmaster, der Nachrichten zwischen Clients (oder Endpunkten) überträgt. Clients lösen neue SIP INVITEs aus, wann immer eine Echtzeitsitzung, z. B. eine Anruf- oder Instant Messaging-Sitzung, erstellt wird. Wenn auf INVITE eine Antwort erfolgt, (d. h. der Remoteendpunkt sendet eine 200 OK-Antwort), wird der Anruf eingerichtet (siehe Abbildung 1).
Abbildung 1 INVITE-Format und 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
In Abbildung 2 ruft Alice Bob an: Sie wählt den Communicator-Anruf aus Office Communicator (OC) 2007 aus, und OC 2007 löst eine INVITE-Nachricht an Bobs SIP-URI (sip:bob@example.com) aus. Die INVITE-Nachricht überträgt den Audiositzungsdeskriptor (genannt SDP, Session Description-Protokoll) der Medienendpunkte, an denen Alice Audio empfangen kann. OCS leitet die INVITE-Nachricht an die für Bob registrierten SIP-Endpunkte (zum Beispiel den Communicator Phone Edition- und den Communicator-Desktop). Die INVITE-Nachricht enthält als Absender „sip:alice@example.com“. Diesen verwenden Bobs Clientendpunkte in einem Reverse-Lookup von Namen (RNL), um den Namen (Alice) zu finden, der in der Benachrichtigung über eingehende Anrufe angezeigt werden soll.
Abbildung 2 Weiterleiten von Anrufen zu mehreren Endpunkten (Klicken Sie zum Vergrößern auf das Bild)
Der URI des Globally Routable User Agent (GRUU) ist für jeden Endpunkt dargestellt. Der GRUU erkennt eindeutig einen SIP-Endpunkt und wird während des Registrierungsprozesses vom OCS-Server abgerufen. Die GRUU-Adresse hilft beim Weiterleiten von SIP-Nachrichten, sodass nach Beantwortung des Anrufs durch einen Endpunkt die nachfolgende SIP-Signalisierung für weitere Vorgänge während des Anrufs direkt mithilfe der GRUU-Adresse zwischen den Endpunkten befördert werden kann.
In Abbildung 3 wird der Prozess fortgesetzt, da Bob vom Communicator-Desktop aus antwortet. Bobs OC sendet eine 200 OK-Nachricht, die mitteilt, wo er Audio empfangen kann. Sobald der OCS-Proxy erkennt, dass ein Endpunkt geantwortet hat, bricht er den Anruf zu den anderen Communicator Phone Edition-Endpunkten ab. Wenn die 200 OK-Antwort den Communicator-Endpunkt von Alice erreicht, haben beide Communicator-Endpunkte ausreichende Informationen (IP-Ports, Verschlüsselungsparameter usw.), um das Medium zu starten.
Abbildung 3 Antworten von einem Endpunkt aus (Klicken Sie zum Vergrößern auf das Bild)

Verwenden von Telefonnummern
Bisher wurde gezeigt, wie der Benutzer auf Communicator-Anruf klickt, um die Einladung zu erstellen. Der Prozess ist ein wenig anders, wenn der Benutzer eine Telefonnummer wählt oder eingibt:
  • Der Client normalisiert zuerst die Telefonnummer und stellt sie als einen TEL-URI dar, der mit Telefonnummern gekennzeichnete Ressourcen beschreibt, wie in RFC 3966 angegeben.
  • Da der OCS-Server nur SIP-URIs erkennt, konvertieren Clients den TEL-URI durch Hinzufügen des Domänensuffixes und eines Benutzerkennzeichens (= Telefonkennzeichen) in einen entsprechenden SIP-URI.
  • Wenn die Nummer einem internen Benutzer entspricht, leitet OCS die Einladung direkt weiter. Bei einer externen Nummer wird die Einladung zum nächsten SIP-PSTN-Gateway geleitet.
Für manche Anrufe zu Telefonfestnetznummern (PSTN-Nummern) muss vor Beantwortung des Anrufs der Medienpfad eingerichtet werden, damit externe Ansagen wiedergegeben oder zusätzliche Ziffern erfasst werden können, um den Anruf zu vervollständigen. In solchen Szenarios sendet das PSTN-Gateway eine 183-Sitzungsfortschrittsanzeige mit einem Audio-SDP. Communicator richtet mithilfe dieser Informationen einen bidirektionalen Medienpfad mit einem Zielendpunkt ein, bevor der Anruf vom Remotebenutzer beantwortet wird.
Sobald der erste Medienpfad vollständig eingerichtet ist, aktiviert Communicator die Zweiton-Mehrfrequenz- oder DTMF-Tastatur (Tastatur für die Telefonsignaltöne), sodass der Benutzer etwa erforderliche zusätzliche Ziffern über das Remotesystem eingeben kann. Eingegebene DTMF-Ziffern werden dann als RFC 2833-Pakete im Medienpfad gesendet. Das PSTN-Gateway sorgt dafür, dass auf der PSTN-Seite die entsprechenden DTMF-Tonsignale generiert werden.
Wenn Bob „Gleichzeitiges Klingeln“ für sein Mobiltelefon aktiviert hat, leitet der OCS-Proxy den Anruf zum Gateway weiter, während gleichzeitig ein Klingelsignal bei Bobs anderen Communicator-Endpunkten erfolgt. In solchen Szenarios zeigt der OCS-Proxy an, dass das Verzweigen in der 183-Sitzungsfortschrittsantwort aktiv ist, und dies veranlasst Communicator, einen unidirektionalen Medienempfangskanal mit dem PSTN-Gateway einzurichten.

Sichere Anrufe
Eines der Hauptfeatures der durch OC eingerichteten Sprachanrufe besteht darin, dass Medien standardmäßig mit dem Secure Real-Time Transport Protocol (SRTP), wie in RFC 3711 definiert, verschlüsselt werden. SRTP sorgt im RTP-Datenverkehr für Vertraulichkeit, Nachrichtenauthentifizierung und Schutz vor Wiedergabeangriffen. Während der Einrichtung des Anrufs handeln Clients die Sicherheitsfunktionen untereinander aus und tauschen als Teil des INVITE-Mechanismus kryptografische Schlüssel aus.
Die Standardverschlüsselungseinstellung für OC ist „optional“, was zwei OC-Endpunkten die Einrichtung eines verschlüsselten Medienkanals ermöglicht. Diese Einstellung kann vom Administrator entsprechend den Kompatibilitätsanforderungen der Organisation angepasst werden. Die Verschlüsselung kann beispielsweise so verdichtet werden, dass sie für alle Anrufe erzwungen wird, oder sie kann vollständig ausgeschaltet werden.

Durchqueren von NATs und Firewalls
Clients im OCS-System verwenden die ICE-Technologie (Interactive Connectivity Establishment), um für Benutzer hinter Geräten mit Netzwerkadressübersetzung (Network Address Translation, NAT) und Firewalls Medienverbindungen bereitzustellen, ohne dass Änderungen an den vorhandenen NAT-Komponenten erforderlich sind. Die ICE-Technologie wird derzeit von der Internet Engineering Task Force (IETF) normiert. Jeder Client kennt den Audio-/Video-Edgeserver (A/V-Edgeserver), der ihn über einen Inband-Bereitstellungsmechanismus bedient, und hält während der Anmeldung eine authentifizierte Verbindung zum A/V-Edgeserver aufrecht.
Vor der Durchführung eines Anrufs weist der Client an den möglichen Verbindungszielen (den Adressen und Ports, die auch als Kandidaten bekannt sind) auf dem A/V-Edgeserver (für Mediarelay), auf dem NAT-Gerät oder auf dem Hostclient selbst Ressourcen zu. Wenn die INVITE-Nachricht des Session Initiation-Protokolls (SIP) gesendet wird, werden diese Verbindungsinformationen als Teil der INVITE-Nachricht übertragen. Die 200 OK-Antwort überträgt ähnliche Kandidateninformationen hinsichtlich des Peer. Sobald jeder Endpunkt über eine Liste von Peer-Kandidaten verfügt, wählt ein ausgeklügelter Klassifizierungs- und Prüfmechanismus den optimalsten Pfad zwischen den zwei Peers aus, auf dem die Medienübertragung garantiert erfolgreich ist.

Weiterleiten von Telefonnummern
Durch das Weiterleiten von Telefonnummern gestaltet sich der grundlegende Anrufmechanismus aufgrund folgender Faktoren etwas komplexer:
  • Organisationen haben möglicherweise verschiedene Wählpläne, die intern für Kurzwahlen bereitgestellt werden.
  • Nummern werden möglicherweise in nicht standardmäßigen Formaten gespeichert (zum Beispiel könnten Benutzer siebenstellige Zeichenfolgen in Microsoft Office Outlook® gespeichert haben).
  • Es gibt möglicherweise verschiedene Richtlinien, die verschiedenen ausgehenden Nummern zugeordnet werden. So kann beispielsweise das Wählen internationaler Nummern für bestimmte Benutzer gesperrt sein.
Beim OCS-System müssen Telefonnummern im Format RFC 3966 TEL URI vorliegen, bevor sie richtig weitergeleitet werden können. Nummern, die nicht dieses Format aufweisen, werden konvertiert, bevor der Client eine INVITE-Nachricht ausgibt. Das Diagramm in Abbildung 4 zeigt, wie dies innerhalb des OCS-Systems vor sich geht.
Abbildung 4 Weiterleiten von Telefonnummern (Klicken Sie zum Vergrößern auf das Bild)
Die dem Client verfügbaren Nummern können aus verschiedenen Quellen stammen. Vornormalisierte Nummern stammen vom Adressbuchdienst (Address Book Service, ABS), der über administratordefinierte Normalisierungsregeln zum Konvertieren von Nummern in ein normalisiertes E.164-Format verfügen kann. Wenn ein Client eine SIP INVITE-Nachricht an eine normalisierte Nummer ausgibt, wendet OCS einen Übersetzungsprozess an, um die Nummer einem internen Benutzer zuzuordnen.
  • Schritt 1 zeigt, dass in das System eingegebene Nummern entweder eindeutig (normalisiert gemäß dem Nummerierungsplan E.164) oder mit einem Telefonkontext versehen sind, der den Standort bezeichnet. Diese Nummern werden als Teil der SIP INVITE-Nachricht zum Server gesendet. OCS leitet die INVITE-Nachricht zu einem Übersetzungsprozess weiter.
  • Der Übersetzungsprozess (Schritt 2) versucht, die Telefonnummer mithilfe eines serverseitigen RNL einem UC-Endpunkt zuzuordnen. Bei der Übersetzung kann für diese Nummer eine Route zu einem Ausgangsrouting oder zu einem UC-Benutzer ermittelt oder der Anruf mit einem 4xx-Code als fehlgeschlagen gemeldet werden, wenn die Nummer nicht richtig übersetzt werden kann.
  • Wenn die Nummer in eine Nummer übersetzt wird, die weder eine UC-Nummer noch eine externe Nummer ist, so wird sie zur Ausgangsroutingkomponente gesendet. Diese leitet die INVITE-Nachricht nach Anwendung anruferbezogener Richtlinien für die Nummer zur weiteren Verarbeitung zum entsprechenden SIP-PSTN-Gateway um (Schritt 3A). Ausgangsrouting sorgt für den Ausgleich der Anruflast über Gateways hinweg oder bei Bedarf für das Failover zu alternativen Gateways. Der Ausgangsroutingprozess kann den Anruf als fehlgeschlagen melden oder abweisen und einen SIP 403-Antwortcode zurückgeben, wenn der Zugriff für eine bestimmte Nummer verboten ist. Beachten Sie, dass das Ausgangsrouting nur gilt, wenn der Anrufer ein UC-Benutzer ist. Ist dies nicht der Fall, so versucht OCS, die statischen Routen zu Gateways zu verwenden, die für diesen URI eingerichtet wurden.
  • Wenn die Nummer in die Nummer eines UC-Benutzers übersetzt wird, wird die INVITE-Nachricht zum SIP-URI dieses Benutzers weitergeleitet (Schritt 3B). Eingangsrouting ist eine Funktion von OCS, die nur für UC-Benutzer und alle an den SIP-URI gerichteten Anrufe gilt. Das Eingangsrouting wendet Regeln für Klingeltimeouts, Anrufweiterleitung und Voicemailweiterleitung für den UC-Benutzer an.
Beachten Sie, dass die aus dem Normalisierungsprozess hervorgehende Nummer je nach Clientstandort unterschiedlich sein kann. Administratoren können Standortprofile konfigurieren und einem bestimmten Standort spezifische Konvertierungsregeln für die Nummern zuweisen (z. B. die Funktionsweise vierstelliger Wahlnummern an diesem Standort). Jedem UC-Benutzer wird ein Standortprofil zugewiesen, und alle Clients im System laden mithilfe eines Inband-Bereitstellungsmechanismus die Regeln herunter, die für ihre eigenen Standortprofile spezifisch sind. Als Nächstes soll das Eingangsrouting näher erörtert werden.

Eingangsrouting
Eingangsroutingregeln geben an, wie Anrufe an einen Benutzer bei Anwesenheit oder Abwesenheit registrierter Clients im System weiterzuleiten sind. Die Eingangsroutingkomponente sorgt auch dafür, dass anwesenheitsbasierte Regeln auf den eingehenden Anruf angewendet werden: sie kann zum Beispiel eingehende Anrufe an die Voicemail senden, wenn der Benutzer als Anwesenheitsstatus „Nicht stören“ eingestellt hat. Das Eingangsrouting erkennt die Ebenen des Anwesenheitscontainers und weist automatisch Anrufe von Benutzern in gesperrten Containern ab. Abbildung 5 zeigt eine Zusammenfassung der Optionen, die von der OCS-Eingangsroutingkomponente unterstützt werden.
Abbildung 5 Eingangsroutingfunktionen
Funktion | Bemerkung
Klingeldauer | Standardeinstellung ist 20 Sekunden. Der Benutzer kann die Dauer auf maximal 60 Sekunden verlängern. Anrufe werden nach dieser Zeitüberschreitung an den Zielort für unbeantwortete Anrufe umgeleitet.
Unbeantwortete Anrufe an Voicemail weiterleiten | Standardeinstellung, wenn der Benutzer für Voicemail aktiviert ist. Anruf wird gemäß Eingangsroutingregeln weitergeleitet.
Benachrichtigungen über verpasste Anrufe generieren, wenn der Anrufer auflegt, bevor der Anruf die Voicemail erreicht | Benachrichtigt Exchange UM über solche verpassten Anrufe.
Anrufsperre | Weist Anrufe von gesperrten Anrufern ab (es können nur Anrufe von Benutzern mit SIP-Identitäten gesperrt werden).
Nicht stören | Leitet Anrufe an die Voicemail weiter. An Zielorten für gleichzeitiges Klingeln ertönt kein Klingelzeichen, wenn der Benutzer in diesem Modus ist.
Liste für zulässige Unterbrechungen | Lässt Anrufe von Anrufern im Teamcontainer zu, selbst wenn der Benutzer auf „Nicht stören“ eingestellt ist.
Gleichzeitiges Klingeln | Konfiguriert eingehende Anrufe so, dass sowohl eine PSTN-Nummer als auch Communicator- und Communicator Phone Edition-Clients klingeln.
Sofortige Anrufweiterleitung | Leitet einen eingehenden Anruf sofort an einen anderen Benutzer, eine PSTN-Nummer oder die Voicemail weiter.
Weiterleitung unbeantworteter Anrufe | Leitet einen unbeantworteten Anruf an einen anderen Benutzer, eine PSTN-Nummer oder die Voicemail weiter.
Arbeitszeiten | Verwendet die im Outlook-Kalender konfigurierten Arbeitszeiten, um für einen Benutzer Anrufweiterleitungseinstellungen zu aktivieren.
Eingangsroutingregeln werden als XML-Schema als Teil der automatischen Bereitstellungsinformationen eines Benutzers auf den Server hochgeladen. Abbildung 6 zeigt die Funktionsweise des Eingangsroutings. Ein eingehender Anruf für einen Benutzer im OCS-System klingelt standardmäßig beim Benutzer (dargestellt als „Ich“). Wenn der Anruf innerhalb der Klingeldauer nicht beantwortet wird, wird der unbeantwortete Anruf standardmäßig an die Voicemail gesendet. Der Benutzer kann die Standardkonfiguration ändern und sofortige Weiterleitung an eine Nummer, an eine andere Person oder direkt an die Voicemail auswählen.
Abbildung 6 Weiterleiten von Anrufen (während der Arbeitszeiten) (Klicken Sie zum Vergrößern auf das Bild)
Alle Anrufe, die sofort an eine andere Person oder Nummer weitergeleitet werden, führen dazu, dass die Eingangsroutingregeln für diese Person oder Nummer wirksam werden. Der Benutzer kann auch festlegen, dass unbeantwortete Anrufe an eine andere Nummer oder Person weitergeleitet werden.
Wenn der Benutzer in den Weiterleitungsregeln die Option „Nur während meiner Outlook-Arbeitszeiten anwenden“ aktiviert, so werden die in Abbildung 6 gezeigten Regeln während der Arbeitszeiten angewendet, und außerhalb dieser Zeiten gilt das Standardverhalten, wonach an den registrierten Endpunkten das Klingelzeichen ertönt. Beachten Sie, dass für dieses Verhalten die Bereitstellung von Microsoft Exchange Server 2007- und Outlook 2007-Clients in der Organisation erforderlich ist, da Communicator die Arbeitszeitinformationen vom Verfügbarkeits-Webdienst in Exchange 2007 verwendet und die Unterstützung von Auto-Discovery in Outlook 2007 nutzt, um den Serverstandort zu ermitteln.

Qualitätsberichterstellung und Problembehandlung
Obwohl Clients im OCS 2007-System RTAudio verwenden, einen Audiocodec der neueren Generation, der mangelhafte Netzwerkbedingungen wie Jitter, Paketverluste usw. tolerieren kann, bleibt Überwachung dennoch unerlässlich, damit Administratoren potenziell kritische Stellen lokalisieren und korrigieren können. Clients im OCS 2007-System liefern am Ende jedes Anrufs einen Qualitätsbericht an einen zentralen QoE-Server. Dazu gehört auch eine ausführliche Statistik einschließlich Bandbreite, Verlust, Jitter, mittlere subjektive Bewertung (ein Maß für die Benutzermeinung), verwendete Geräte und mehr. Dies erfolgt durch Senden der Nutzlast in einer SIP SERVICE-Anforderung an den QoE-Server, dessen Adresse mithilfe eines Inband-Bereitstellungsmechanismus programmiert wird.
Beachten Sie, dass alle Clientendpunkte die Anrufqualität unabhängig voneinander an den QoE-Server melden. Sollte ein Anruf aufgrund eines Fehlers in der Signalisierung fehlschlagen, melden Clients dies ebenfalls an OCS, wo alle von Clients gemeldeten Fehler archiviert werden.﻿

Der Gesamtprozess
Nach diesen Ausführungen zu verschiedenen Aspekten der Einrichtung eines Anrufs, einschließlich Eingabe von Nummern, Eingangs- und Ausgangsrouting sowie Verbindungsprüfungen, soll nun der Prozess als Ganzes beleuchtet werden. Abbildung 7 fasst zusammen, was ab dem Zeitpunkt geschieht, zu dem ein Benutzer einen Anruf tätigt. Clients im OCS-System spielen bei der Einrichtung eines Anrufs eine wichtige Rolle, und sie verwalten den gesamten Einrichtungsprozess des Anrufs. OCS ist am anfänglichen Routing des Anrufs beteiligt, und Edgeserver sorgen dafür, dass Clients die optimalste Medienroute finden. Schauen wir uns jetzt an, was als Nächstes geschieht: das Gespräch
Abbildung 7 Anruffluss zwischen Endpunkten (Klicken Sie zum Vergrößern auf das Bild)

Multimodales Verhalten und Gespräche
Der Begriff des Gesprächs ist im OCS-System zentral. Ein Gespräch ist eine multimodale Sitzung zwischen zwei oder mehr Personen und kann Sprache, Video und IM gleichzeitig enthalten, außerdem Artefakte wie Dateiübertragungen während der Sitzung, E-Mails in Outlook oder in Microsoft Office OneNote® gespeicherte Anmerkungen.
Es gibt bei Gesprächen mehrere Aspekte, die sich auf den Entwurf von OCS-Clientsystemen auswirken können:
  • Alle an einem Gespräch beteiligten Modalitäten verwenden dasselbe Fenster. Wenn einem Audiogespräch eine Sofortnachricht hinzugefügt wird, ist sie mit demselben Fenster verbunden.
  • Gespräche können über mehrere Geräte stattfinden. Benutzer können sich entscheiden, Audio über Communicator Telefon Edition zu empfangen, Sofortnachrichten jedoch auf dem Communicator-Desktop.
  • Alle Modi können gemeinsam zu einer Konferenz erweitert werden: Wenn eine Erweiterung stattfindet, müssen alle Modalitäten eines Gesprächs gemeinsam erweitert werden, unabhängig davon, auf welchem Gerät sich die Modalität derzeit befindet. Ist beispielsweise auf Communicator Phone Edition ein Audiomodus und auf dem Communicator-Desktop für dasselbe Gespräch ein IM-Modus verfügbar, dann stellt die Ausweitung zu einer Konferenz sicher, dass sowohl Audio als auch IM dieselbe Teilnehmergruppe für dieses Gespräch haben.
  • Gespräche, nicht einzelne Sitzungen, werden protokolliert. Anrufprotokolle enthalten vollständige Informationen über das Gespräch, einschließlich Details über während des Gesprächs aufgeschriebene Notizen, Austausch von Sofortnachrichten, Dauer des Audiogesprächs und so weiter. So erhalten Benutzer eine praktische, kompakte Ansicht des gesamten Gesprächs, wenn sie das Anrufprotokoll in Outlook öffnen.
  • Gespräche können von den Gesprächsprotokollen aus fortgesetzt werden. OCS-Clients fassen Gespräche mithilfe einer Gesprächs-ID zusammen (eine Nummer, die das Gespräch geräte- und anwendungsübergreifend eindeutig identifiziert). Es gibt eine ausgeklügelte Methode, Deltas von Gesprächen zu berechnen, wenn neue Gespräche vom Verlaufsprotokoll eines alten Gesprächs aus gestartet werden. Dieselbe Gesprächs-ID wird auch als die ID der E-Mail in Outlook gespeichert.
Die Gesprächs-ID wird als Teil der SIP INVITE-Nachricht als benutzerdefinierte Eigenschaft „Ms-Conversation-Id“ übermittelt. Abbildung 8 zeigt eine solche Transaktion, bei der zuerst Sprache und dann eine Sofortnachricht hinzugefügt wird. Beachten Sie, dass am Ende des multimodalen Gesprächs das in Outlook gespeicherte Verlaufsprotokoll dieselbe Gesprächs-ID hat.
Abbildung 8 Multimodale Gespräche und Gesprächs-ID (Klicken Sie zum Vergrößern auf das Bild)

Exchange UM ist das Voicemailsystem für OCS 2007. OCS leitet Anrufe nur für solche Benutzer weiter, die bei Exchange UM als UC-Benutzer geführt sind. OCS bietet mehrere Features für die Integration in Exchange UM:
  • Mit der Option „Voicemail anrufen“ von der Communicator-Telefonbenutzeroberfläche (siehe Abbildung 9) kann der Benutzer ohne PIN-Eingabe das UM-Postfach verwalten, Ansagen ändern usw., da er bereits authentifiziert ist.
  • Mit der Nachrichtenanzeige in der Communicator-Benutzeroberfläche (siehe Abbildung 10) kann der Benutzer den Voicemailordner in Outlook öffnen, während er mit derjenigen in Communicator Phone Edition die Sprachnachrichten direkt vom Telefon abhören kann.
  • Anrufe können von der Communicator-Benutzeroberfläche an die Voicemail weitergeleitet werden.
  • Abgelehnte Anrufe werden automatisch an die Voicemail weitergeleitet.
  • „Wiedergabe über Telefon“ des Voicemailelements in Outlook lässt Office Communicator-Clients direkt klingeln.
Abbildung 9 Option „Voicemail anrufen“ in Communicator
Abbildung 10 Nachrichtenanzeige in Communicator
Der Mechanismus, mit dem OC die Voicemailbenachrichtigung empfängt, unterscheidet sich von dem in Communicator Phone Edition. OC registriert sich für neue Posteingangsbenachrichtigungen beim Voicemailsuchordner in Outlook und meldet neue Nachrichten in diesem Ordner. Communicator verwendet auch Protokolle über verpasste Gespräche und Anrufe.

Zusammenfassung
In diesem Artikel wurde aufgezeigt, wie Sprachanrufe in OCS 2007 funktionieren, einem auf SIP basierenden System, das mehrere RFCs nutzt. Clientendpunkte spielen beim Verwalten von Anrufen in OCS eine zentrale Rolle. Alle Sprachanrufe sind standardmäßig sicher verschlüsselt. OCS bietet flexible Komponenten, um Nummern zu ändern und deren Fluss durch das System zu verwalten.
Gespräche sind in OCS ein zentraler Begriff, der Sprache, IM und Video umfasst. OCS wird in Exchange UM integriert und ermöglicht die Benachrichtigung von Communicator-Endpunkten über Voicemaileingang sowie den Zugriff auf Voicemail über Outlook oder direkt vom Server aus.

Rajesh Ramanathan beschäftigt sich seit 14 Jahren mit Kommunikation und hat Sprachprotokolle, Benutzerfunktionen sowie Sprach- und Konferenzfeatures für Office Communicator 2007 entworfen. Er arbeitet derzeit als leitender Programmmanager im Office Communicator-Team bei Microsoft. Sie erreichen ihn unter rajeshra@microsoft.com.


Kommunikation und Zusammenarbeit
Erstellen leistungsfähiger Verbindungen mit Groove und SharePoint
Alan Maddison
Auf einen Blick:
  • Erstellen einer SharePoint-Dokumentbibliothek
  • Erstellen eines Groove-Arbeitsbereichs
  • Synchronisieren von Groove und SharePoint
  • Ermöglichen des Zugriffs auf den Arbeitsbereich

Inhalt
Gemeinsamer Einsatz von Groove und SharePoint
Erste Schritte
Einrichten der Genehmigungssteuerung
Erstellen eines Groove-Arbeitsbereichs
Synchronisieren von Groove und SharePoint
Ermöglichen des Zugriffs auf den Arbeitsbereich
Zusammenfassung
IT-Experten wundern sich häufig über die scheinbare Ähnlichkeit zwischen Microsoft Office Groove 2007 (Groove) und Microsoft Office SharePoint Server 2007 (SharePoint) und sind sich nicht sicher, wann welches
Produkt eingesetzt werden soll. Auf den ersten Blick scheinen beide Produkte sehr ähnlich zu sein, da beide Funktionen zu Zusammenarbeit bieten. Wenn Sie sich jedoch die Architektur genauer ansehen, verstehen Sie, wie die Produkte sich unterscheiden.
SharePoint® ist ein stabiles und skalierbares Content Management-Framework und ein Toolset für die Zusammenarbeit, das strukturierte Workflows unterstützt. Groove™ ist im Gegensatz dazu ein Toolset für die Zusammenarbeit, mit dem sich Arbeitsbereiche mit keinem oder geringem IT-Aufwand schneller bereitstellen lassen. Weil Groove unter anderem gemeinsame Nutzung von Dokumenten, Diskussionsforen und Kalenderfeatures unterstützt, ist Groove das ideale Framework für eine dynamische, sichere und zweckgebundene Zusammenarbeit. Die meisten Benutzer setzen diese Produkte also am Ende für unterschiedliche Zwecke ein.
Außerdem ist in der Version von Groove 2007 die Unterstützung für die Integration von SharePoint mithilfe des SharePoint-Dateitools bereits integriert. Durch dieses Tool können Groove-Arbeitsbereiche mit SharePoint-Dokumentbibliotheken synchronisiert werden. Außerdem können Sie, wie im Weiteren noch erläutert wird, aufgrund der integrierten Integrationsfunktionen problemlos beide Produkte optimal nutzen. Durch Kombination der Flexibilität und Dynamik von Groove mit der Raffinesse und Leistungsfähigkeit von SharePoint ergeben sich für viele Benutzer enorme Vorteile.
Gemeinsamer Einsatz von Groove und SharePoint
Die heutige IT-Welt verlangt nach immer mehr Zusammenarbeit zwischen Organisationen und ihren Partnern und Lieferanten. Die leistungsfähigen Lösungen für eine Zusammenarbeit, die z. B. mithilfe von SharePoint implementiert werden, konzentrieren sich sehr stark auf interne Teams und die Notwendigkeit, Informationen innerhalb einer Organisation allen zur Verfügung zu stellen. Daher sind die Herausforderungen sowohl aus verwaltungs- als auch aus sicherheitstechnischer Perspektive äußerst groß, wenn Benutzern Zugriff auf Personen außerhalb der Organisation gewährt werden soll. Angesichts solcher Herausforderungen ist es das Ziel, dass Benutzer für bestimmte Zwecke auf externe Partner zugreifen dürfen.
Die Kombination von Groove und SharePoint löst genau dieses Problem. SharePoint ermöglicht die Zusammenarbeit innerhalb einer Organisation, bietet eine Inhaltssuche und stellt ein Workflowframework bereit. Wird Groove hinzugefügt, können Unternehmen diese Funktionen um eine einfache Zusammenarbeit zwischen Organisationen erweitern. Mit Groove können Benutzer schnell Arbeitsbereiche für eine Zusammenarbeit einrichten, die sich über Unternehmensgrenzen hinweg erstrecken. Außerdem sorgt die Unterstützung von symmetrischen Schlüsseln mit einem erweiterten 192 Bit-Verschlüsselungssystem (Advanced Encryption System, AES) für eine sichere Zusammenarbeit. Sicherheit ist in Groove integriert und automatisch aktiviert, daher ist keine Benutzerkonfiguration erforderlich.
Durch die Sicherheitsarchitektur von Groove werden diese Arbeitsbereiche und ihre Inhalte in hohem Maße geschützt, sowohl bei der lokalen Speicherung als auch während der Übertragung im Netzwerk. Durch das SharePoint-Dateitool können diese Informationen bidirektional mit einer SharePoint-Dokumentbibliothek synchronisiert werden. Dadurch wird sichergestellt, dass die Informationen für den einfachen internen Zugriff zentral verfügbar sind. Schauen wir uns anhand eines konkreten Beispiels an, wie dieser Prozess funktioniert.
Erste Schritte
Organisationen arbeiten während ihrer täglichen Geschäftsaktivitäten häufig mit vielen Unternehmen zusammen. Dies umfasst in der Regel nicht nur externe Organisationen, sondern auch einzelne Benutzer aus Abteilungen, die nicht immer regelmäßig zusammenarbeiten, z. B. aus Finanzwesen, Unternehmenskommunikation und Rechtsabteilung. Deshalb müssen diese Organisationen ein internes Team für die Zusammenarbeit zusammenstellen, das die Ergebnisse dieser Zusammenarbeit den Benutzern zur Verfügung stellt, die nicht daran beteiligt sind, aber dennoch auf das endgültige Ergebnis zugreifen müssen. Mithilfe von SharePoint und Groove können Sie diese Ziele ganz einfach erreichen.
Wenn Sie nicht bereits über eine SharePoint-Dokumentbibliothek verfügen, die Sie mit Ihrem Groove-Arbeitsbereich synchronisieren möchten, besteht der erste Schritt darin, eine Bibliothek zu erstellen. Zu diesem Zweck stellen Sie eine Verbindung mit SharePoint her und wählen dann die Verknüpfung „View All Content“ (Gesamten Inhalt anzeigen) aus. Nach dem Laden der Seite wählen Sie „Erstellen“ und dann, wie in aus Abbildung 1 gezeigt, die Dokumentbibliothek aus der Spalte „Bibliothek“ aus.
Abbildung 1 Erstellen einer SharePoint-Dokumentbibliothek (Zum Vergrößern auf das Bild klicken)
Auf der Seite der neuen Dokumentbibliothek sind einige Einstellungen festzulegen: der Name und die Beschreibung der Bibliothek, ob die Bibliothek im Abschnitt „QuickLinks“ enthalten sein soll, ob die Versionsverwaltung aktiviert werden soll sowie das Standardformat für neue Dokumente, die direkt in der Bibliothek erstellt werden. Die Auswahl für den Dokumentversionsverlauf ist standardmäßig deaktiviert, aber Sie sollten dieses Feature aktivieren, wenn eine Versionsverwaltung für Ihre Umgebung sinnvoll ist. Sie sollten auch einige der erweiterten Funktionen von SharePoint in Betracht ziehen, die als Teil Ihrer Implementierung von Groove und SharePoint verwendet werden können. Diese verbesserte Funktionalität umfasst:
  • Versionsverlauf
  • Genehmigungssteuerung
  • Checkoutverfahren
  • Workflowsteuerung
  • Dokumentaufbewahrungsrichtlinien
  • Überwachung
  • RSS (Really Simple Syndication)
Diese zusätzlichen Funktionen, die mit SharePoint verfügbar sind, können bei der Arbeit mit Groove äußerst wertvoll sein. In diesem Beispiel wird sich diese zusätzliche Funktionalität als sehr nützlich erweisen, insbesondere bei der Genehmigungssteuerung. Nehmen Sie zum Beispiel an, die Teammitglieder arbeiten innerhalb von Groove gemeinsam am Entwurf eines Dokuments. Wenn der endgültige Entwurf für eine Überprüfung bereit ist, könnte er mit SharePoint synchronisiert und dann Gegenstand des Genehmigungsprozesses werden.

Einrichten der Genehmigungssteuerung
Sie können diese Funktion konfigurieren, indem Sie in der Dokumentbibliothek das Menü „Einstellungen“ und dann den Eintrag „Einstellungen“ auswählen. Dadurch werden alle Konfigurations- und Anpassungsoptionen angezeigt. Sie konfigurieren die Genehmigung, indem Sie im Abschnitt „Berechtigungen und Verwaltung“ die Verknüpfung der Workfloweinstellungen auswählen. Dadurch wird die Seite „Workflow hinzufügen“ angezeigt. Wählen Sie jetzt die Workflowvorlage aus, also in diesem Beispiel die Genehmigungsvorlage, und geben Sie dann einen Namen für den Workflow ein. Anschließend müssen Sie entscheiden, ob Sie eine vorhandene Aufgabenliste verwenden oder eine neue erstellen wollen. Eine neue Aufgabenliste ermöglicht eine bessere Geheimhaltung, da dies aber in unserem Beispiel kein Problem ist, wählen Sie die Standardvorgabe aus.
Nach Auswahl der Aufgabenliste müssen Sie entscheiden, womit der Genehmigungsprozess beginnen soll. Hier soll es um einen manuellen Prozess gehen, den jeder authentifizierte Benutzer mit den korrekten Berechtigungen starten kann. Mithilfe der anderen Optionen können Sie diesen Prozess auf Basis der Versionsverwaltung automatisieren, wenn er in der Dokumentbibliothek aktiviert ist, wenn ein neues Dokument hinzugefügt wird oder wenn ein vorhandenes Dokument geändert wird.
Durch Klicken auf „Weiter“ akzeptieren Sie diese Konfigurationsoptionen und müssen jetzt abschließende Konfigurationsdaten eingeben. Als erste Option sollten Sie konfigurieren, wie Aufgaben zugewiesen werden. Da möglicherweise mehrere Benutzer am Genehmigungsprozess beteiligt sind, können Sie die Genehmigungsberechtigten seriell zuweisen, sodass ein Benutzer das Element genehmigt und es dann an den nächsten Benutzer weitergibt, oder parallel zuweisen, sodass jeder Benutzer das Element jederzeit genehmigen kann. Sie müssen dann entscheiden, ob Genehmigungsberechtigte anderen Benutzern Aufgaben zuweisen dürfen und ob sie Änderungen anfordern dürfen, bevor die Aufgabe abgeschlossen wird.
Im nächsten Schritt wählen Sie die eigentlichen Genehmigungsberechtigten aus und entscheiden dann, bis wann die Aufgabe abgeschlossen werden soll. Zum Schluss entscheiden Sie, wann der Workflow abgeschlossen sein soll. Bei der Standardoption ist der Workflow abgeschlossen, sobald alle Aufgaben erledigt wurden. Bei der endgültigen Konfiguration legen Sie fest, ob der Genehmigungsstatus aktualisiert wird, wenn der Workflow abgeschlossen ist. Wenn Sie auf „OK“ klicken, wird der Genehmigungsprozess erstellt, und Sie können mit der Genehmigung von Dokumenten beginnen.

Erstellen eines Groove-Arbeitsbereichs
Nach Erstellen der SharePoint-Dokumentbibliothek wird im nächsten Schritt ein Groove-Arbeitsbereich erstellt. Stellen Sie dazu als Erstes sicher, dass Sie über ein Groove-Konto und mindestens eine Identität verfügen. Identitäten sind die Basis für die Anwesenheit von Groove und die Kommunikation innerhalb dieses Programms. Jedem Groove-Konto können mehrere Identitäten zugeordnet werden, und jeder Identität wird eine eindeutige Kontaktdatei zugeordnet, damit Sie die Kontaktinformation für jede der von Ihnen verwendeten Identitäten anpassen können. Sie können Ihr Groove-Konto und die damit verknüpften Identitäten auch exportieren, um sie auf mehreren Computern zu verwenden.
Wenn ein Konto und eine Identität erstellt wurden, öffnen Sie den Groove-Startbereich durch Doppelklicken auf das Groove-Symbol in der Taskleiste. Klicken Sie auf die Option „Neuer Arbeitsbereich“, geben Sie einen geeigneten Namen für den Arbeitsbereich ein, und wählen Sie einen Standardtyp für den Arbeitsbereich aus. Der Standardarbeitsbereich von Groove vereinfacht die Zuweisung von Anwesenheit, Warnungen und Rollen an Arbeitsbereichsmitglieder. Wenn Sie auf „OK“ klicken, erstellt Groove den Arbeitsbereich und öffnet ihn. Abbildung 2 zeigt einen neuen Arbeitsbereich mit einigen Dateien, die dem Dateitool hinzugefügt wurden. Jetzt kann mit dem Arbeitsbereich gearbeitet werden, und Sie können die Einrichtung vervollständigen, indem Sie Warnungen konfigurieren oder eines der entsprechenden Tools hinzufügen.
Abbildung 2 Ein neuer Groove-Arbeitsbereich (Zum Vergrößern auf das Bild klicken)
Warnungen können auf Tool-, Arbeitsbereichs- oder auf einzelner Dateiebene konfiguriert werden. Die vier Warnebenen sind „Keine“, „Mittel“, „Hoch“ und „Auto“. Die Einstellung „Mittel“ hebt neuen Inhalt hervor, die Einstellungen „Hoch“ oder „Auto“ spielen eine Audiodatei ab. Sie können auch Warnungen konfigurieren, die Sie benachrichtigen, sobald ein Benutzer in einen bestimmten Arbeitsbereich eintritt. Warnungen werden durch Auswahl des Eintrags „Set Alerts“ (Warnungen festlegen) im Menü „Optionen“ ausgewählt. Warnungen für einzelne Dateien werden direkt über die Eigenschaften der Datei festgelegt. Klicken Sie mit der rechten Maustaste auf eine Datei im Arbeitsbereich, und wählen Sie „Eigenschaften“ aus.
Zusätzlich zum Dateitool für die gemeinsame Nutzung von Dokumenten und dem Diskussionstool für Diskussionsforen, die Teil des Standardarbeitsbereichs sind, gibt es viele weitere Tools, darunter Kalender, Formulare, Problemverfolgung, Besprechungen, Skizzenblock und selbstverständlich das SharePoint-Dateitool. Jedes von ihnen liefert nützliche, zusätzliche Funktionalität für die Zusammenarbeit. Zum Hinzufügen eines Tools wählen Sie im unteren rechten Bereich des Arbeitsbereichs die Schaltfläche „Diesem Arbeitsbereich ein Tool hinzufügen“ aus und fügen dann das gewünschte Tool hinzu, siehe Abbildung 3. Sie können ein Tool auch jederzeit ganz einfach löschen.
Abbildung 3 Hinzufügen eines Tools zum Groove-Arbeitsbereich (Zum Vergrößern auf das Bild klicken)

Synchronisieren von Groove und SharePoint
Nach dem Hinzufügen des SharePoint-Dateitools, muss nun die URL der SharePoint-Website festgelegt werden, auf der sich die Dokumentbibliothek befindet, mit der eine Synchronisierung vorgenommen werden soll. Wählen Sie zunächst die Registerkarte „SharePoint-Dateien“ im unteren Bereich des Arbeitsbereichs aus, und klicken Sie anschließend im Groove-Arbeitsbereich auf die Schaltfläche „Setup“, wie in Abbildung 4 gezeigt.
Abbildung 4 Einrichten des SharePoint-Dateitools (Zum Vergrößern auf das Bild klicken)
Nach Eingabe der URL werden alle Bibliotheken angezeigt, die auf dieser SharePoint-Website verfügbar sind. Wählen Sie dann so wie in Abbildung 5 die gewünschte Bibliothek aus. Groove stellt eine Verbindung her und startet die automatische Synchronisierung. Alle Dokumente, die sich momentan in der SharePoint-Bibliothek befinden, werden damit in den Groove-Arbeitsbereich heruntergeladen und dort zur Verfügung gestellt. Abbildung 6 zeigt ein Beispiel.
Abbildung 5 Nach dem Festlegen der URL werden die SharePoint-Bibliotheken in Groove verfügbar (Zum Vergrößern auf das Bild klicken)
Abbildung 6 Synchronisieren von Groove und SharePoint (Zum Vergrößern auf das Bild klicken)
Die Dokumente werden im Groove-Arbeitsbereich als ungelesen angezeigt, da sie gerade erst heruntergeladen wurden. Alle über SharePoint synchronisierten Dateien können die Vorteile der Anmelde- bzw. Abmeldefunktionalität von SharePoint nutzen. Wenn Sie eine Datei abmelden, stellen Sie sicher, dass keine anderen Benutzer Änderungen durchführen können, während Sie das Dokument bearbeiten.
Weiterhin sollten Sie berücksichtigen, dass das SharePoint-Dateitool für eine bidirektionale Synchronisierung sorgt. Wenn Sie dem SharePoint-Dateitool also Dateien mithilfe von Groove hinzufügen, werden sie mit der SharePoint-Dokumentbibliothek synchronisiert. Auch wenn standardmäßig eine automatische Synchronisierung festgelegt ist, können Sie die Synchronisierung manuell durch Klicken auf die Schaltfläche „Synchronize Now“ (Jetzt Synchronisieren) starten. In diesem Fall wird für jede zu synchronisierende Datei eine Zusammenfassung aller Änderungen und eine entsprechende Aktion angezeigt: Empfangen (von SharePoint) oder Senden (an SharePoint), siehe Abbildung 7.
Abbildung 7 Nach einer manuellen Synchronisierung wird eine Zusammenfassung aller Änderungen angezeigt (Zum Vergrößern auf das Bild klicken)
Anzumerken ist, dass sich das Dateitool, das als Teil des Standardarbeitsbereichs von Groove bereitgestellt wird, vom SharePoint-Dateitool unterscheidet. Das Groove-Dateitool führt keine Synchronisierung mit SharePoint durch und kann ggf. entfernt werden. Weil keine Synchronisierung mit SharePoint stattfindet, kann das Tool jedoch auch als Speicherort für temporäre Dateien verwendet werden, die das Team im Verlauf eines Projekts benötigt. Die dort abgelegten Dateien werden ebenfalls zwischen den Mitgliedern des Arbeitsbereichs synchronisiert.

Ermöglichen des Zugriffs auf den Arbeitsbereich
Nachdem die grundlegende Infrastruktur für eine Zusammenarbeit bereitgestellt wurde, können Sie jetzt den Benutzern Zugriff auf den Arbeitsbereich ermöglichen. Vorher aber müssen Sie sie einladen, was über E-Mail oder über Groove Instant Messaging erfolgt. Alternativ können Sie die Einladungen aus Groove in eine Datei exportieren. Diese Datei besitzt die Erweiterung .grv, die standardmäßig der Groove-Anwendung zugeordnet wird, und kann dann auf eine andere Art und Weise ausgeliefert werden. Die Einladung kann z. B. auf eine Website gestellt werden, über die der Empfänger sie herunterladen kann.
In Groove Instant Messaging wird durch Sicherheitsprüfungen gewährleistet, dass nur der Empfänger eine Einladung lesen darf. Stellen Sie bei einer Einladung über E-Mail oder mithilfe einer Einladungsdatei sicher, dass die Option „Zustimmungsbestätigung erforderlich“ aktiviert ist. Dadurch erhalten Sie eine weitere Bestätigung, dass der jeweils richtige Benutzer dem Arbeitsbereich beitritt. Dadurch wird zusätzlicher Schutz für den Arbeitsbereich gewährt. Beachten Sie, dass ausstehende Einladungen abgebrochen werden können.
Wenn Sie Benutzer in den Arbeitsbereich einladen, müssen Sie jedem Empfänger eine Rolle zuweisen. Mögliche Rollen sind Manager, Teilnehmer und Gast. Die Standardzuweisung ist Teilnehmer. Jede Rolle hat bestimmte Rechte innerhalb des Arbeitsbereichs, und Sie sollten die Managerrolle wirklich nur den Benutzern zuweisen, die alle Rechte im Arbeitsbereich benötigen, also etwa Tools löschen dürfen. Erstellern von Arbeitsbereichen wird standardmäßig die Managerrolle zugewiesen. Zugewiesene Rollen können jederzeit geändert werden.
Am Schluss muss der Groove-Arbeitsbereich nach dem Abschluss der Arbeit gelöscht werden, da das Projekt in diesem Artikel zweckgebunden ist. Nachdem Sie den Arbeitsbereich mit der SharePoint-Bibliothek synchronisiert haben, können Sie den Arbeitsbereich öffnen und im Menü „Datei“ den Eintrag „Arbeitsbereich löschen“ auswählen. Sie erhalten die Option, den Arbeitsbereich entweder vom Computer oder für alle Mitglieder zu löschen. (Jeder Benutzer besitzt eine Kopie des Arbeitsbereichs auf seinem Computer, die erst dann gelöscht wird, wenn Sie ihn für alle Mitglieder löschen.)
Der Höhepunkt des Projekts wäre eine weitere Gelegenheit, die komplementäre Natur von Groove und SharePoint zu nutzen. Nach der endgültigen Synchronisierung der Dokumente wären Sie in einer idealen Position, die Vorteile der Richtlinieneinstellungen für die Informationsverwaltung in SharePoint zu nutzen. Insbesondere kann eine Funktion zum Ablauf von Daten aktiviert werden, durch die sich die gespeicherten Daten automatisch verwalten lassen.
Dabei können Sie einen Zeitraum angeben, für den die Daten aufbewahrt werden sollen. Am Ende des Aufbewahrungszeitraums kann SharePoint die Daten automatisch löschen oder einen Workflowprozess starten. Durch diese großartige Möglichkeit können Sie die Daten von Groove in die Lebenszyklus-Informationsverwaltungsrichtlinien Ihres Unternehmens integrieren. Sie können die Richtlinie für die Datenaufbewahrung jederzeit konfigurieren. Wenn dies nicht bereits bei der ersten Konfiguration der Bibliothek erfolgt ist, haben Sie jetzt eine weitere Möglichkeit dazu.
Zum Aktivieren der Ablauffunktion wählen Sie innerhalb der Dokumentbibliothek das Menü „Einstellungen“ und dann den Menüeintrag „Dokumentbibliothekseinstellungen “ aus. Im Abschnitt „Berechtigungen und Verwaltung“ wird jetzt die Menüoption „Einstellungen für die Informationsverwaltungsrichtlinie“ angezeigt. Wenn Sie auf die Verknüpfung „Einstellungen für die Informationsverwaltungsrichtlinie“ geklickt haben, können Sie entweder eine neue benutzerdefinierte Richtlinie festlegen, oder Sie können auswählen, dass die Dokumentbibliothek die auf Standortebene festgelegte Richtlinie verwenden soll.
Beachten Sie, dass Sie beim Festlegen einer benutzerdefinierten Richtlinie einige Konfigurationsinformationen eingeben müssen. Deshalb wird in diesem Beispiel der Ablauf aktiviert sowie ein Aufbewahrungszeitraum und eine Aktion ausgewählt, die nach Ablauf des Aufbewahrungszeitraums ausgeführt werden soll.
Groove ist ein umfassender Client für die Zusammenarbeit und wurde entworfen, um ein dynamisches, intuitives und sicheres Framework für die zweckgebundene Zusammenarbeit zu ermöglichen. Durch das umfangreiche Toolset ist Groove eine einfache und anpassungsfähige Plattform für die Zusammenarbeit. Sie kann problemlos innerhalb einer Organisation oder zwischen verschiedenen Organisationen verwendet werden.
Wenn SharePoint bereits ein stabiles und leistungsfähiges Content Management-Framework und Toolset für die Zusammenarbeit in Ihrem Unternehmen ist, dann ist die Kombination mit Groove eine hervorragende Lösung. Beide Produkte ergänzen sich außerordentlich gut und ermöglichen so bedeutende Produktivitätssteigerungen bei der Zusammenarbeit von Teams.﻿

Alan Maddison ist Senior Consultant bei Strategic Business Systems, einer Tochtergesellschaft von Brocade.


Windows-Verwaltung
Einführung in Failoverclustering für Windows Server 2008
Chuck Timon
Auf einen Blick:
  • Failovercluster-Verwaltungs-Snap-In
  • Neue Features und Verbesserungen
  • Sicherungs- und Wiederherstellungsfunktion
  • Migrieren von Windows Server 2003

Inhalt
Neue Verwaltungsschnittstelle
Verbesserte Konfigurationsprozesse
Eingebettete Validierungsprozedur
Neues Quorummodell
Verbesserte Sicherheitsfeatures
Erweiterte Netzwerkfunktionen
Höhere Zuverlässigkeit bei Interaktion mit dem Speicher
Integrierte Wiederherstellungsprozesse
Neue Sicherungs- und Wiederherstellungsfunktion
Migrieren von Windows Server 2003-Serverclustern
Seit der Einführung des Clustering in Windows NT 4.0 Enterprise Edition beklagen sich Benutzer darüber, dass es sich nur schwer einrichten und noch schwerer verwalten lässt. Die Verwaltung eines Clusters
erfordert einen Administrator, der über mehr als nur Grundkenntnisse des Clustering verfügt. Der Administrator muss sich außerdem detailliert mit Speichertechnologien auskennen und wissen, wie der Clusterdienst mit verschiedenen Speicherlösungen interagieren würde. In vielen Organisationen gab es nicht genügend Fachleute, die über die erforderlichen umfassenden Fähigkeiten zur Einrichtung und Verwaltung einer Lösung mit hoher Verfügbarkeit verfügten.
Zwar erfuhr Clustering im Laufe der Jahre Verbesserungen, hatte jedoch noch immer erhebliche Mängel, als Microsoft mit der Arbeit an Windows Server® 2008 begann. Vor diesem Hintergrund machte sich das Team an einen Neuentwurf des Clustering mit dem Ziel der Vereinfachung. In Windows Server 2008 erhielten die vollständig überarbeiteten Microsoft®-Clusterdienste (MSCS) auch einen neuen Namen: Failoverclustering.
Allerdings ist Einfachheit nicht die einzige Neuerung, mit denen die neue Failoverclustering-Implementierung aufwartet. Im Laufe der Jahre hat Microsoft viel dazugelernt, nicht zuletzt dank des wertvolles Feedbacks von Organisationen, die ihre Wünsche für eine Clusteringlösung mitteilten. Mit der neuen Failoverclusteringfunktion werden viele der wichtigsten Probleme, die von Benutzern genannt wurden, gelöst. Darüber hinaus gibt es einige interessante neue Features, die sehr vielversprechend klingen. In diesem Artikel möchte ich daher einige der interessanten neuen Features in Windows Server 2008-Failoverclustering vorstellen.

Neue Verwaltungsschnittstelle
Nach der Installation des Failoverclustering können Sie auf die Failovercluster-Verwaltungsschnittstelle über die Option „Verwaltung“ oder durch Ausführung von „Cluadmin.msc“ zugreifen. Das Failovercluster-Verwaltungs-Snap-In ist genau wie andere Verwaltungsschnittstellen in Windows Server 2008 eine Microsoft Management Console (MMC) 3.0. Clusterexperten, die das Failovercluster-Verwaltungs-Snap-In zum ersten Mal öffnen, werden sich ein bisschen wie in einem fremden Land ohne Karte zur Orientierung fühlen.
Die neue Schnittstelle ist in drei verschiedene Bereiche unterteilt, wie in Abbildung 1 gezeigt. Im linken Bereich werden alle Windows Server 2008-Failovercluster in Ihrer Organisation aufgeführt. Im mittleren Bereich finden Sie Details zu dem Teil der Clusterkonfiguration, den Sie im linken Bereich ausgewählt haben, und im rechten Bereich werden die Aktionen angezeigt, die ausgeführt werden können.
Abbildung 1 Failovercluster-Verwaltungs-Snap-In (Zum Vergrößern auf das Bild klicken)
Angenommen, Sie wählen im linken Fensterbereich „Speicher“ aus. Im mittleren Bereich wird dann detailliert aufgeführt, welcher Speicher im Cluster bereitgestellt wurde und welcher Speicher derzeit verfügbar ist (falls zutreffend). Wie Sie in Abbildung 1 sehen, enthält der Cluster eine Speicherkomponente, die einen Zeugendatenträger unterstützt, für einen Dateiserver bereitgestellten Speicher und eine bestimmte Menge verfügbaren Speicher. Im rechten Bereich werden relevante Aktionen aufgeführt, z. B. das Hinzufügen von mehr Speicher. Beachten Sie, dass das Failovercluster-Verwaltungs-Snap-In nicht zur Verwaltung früherer Versionen von Microsoft-Clusterdiensten verwendet werden kann.

Verbesserte Konfigurationsprozesse
Die Konfiguration eines Failoverclusters ist eine ziemlich einfache Aufgabe. Für viele der Aktionen für die Konfiguration, Neukonfiguration und Verwaltung eines Clusters gibt es Assistenten. Dank dieser Assistenten muss sich der Administrator nicht mehr darum kümmern, ob Ressourcen richtig konfiguriert sind oder ob sie in der richtigen Reihenfolge online geschaltet werden.
Abbildung 2 zeigt den Assistenten für hohe Verfügbarkeit. In diesem besonderen Beispiel wurde ein Dateiserver konfiguriert. Auf der linken Seite sehen Sie die Liste der Schritte, durch die der Administrator vom Assistenten geführt wurde. Nach Abschluss des Prozesses wird eine Zusammenfassungsseite angezeigt. Außerdem kann ein Bericht angezeigt werden.
Abbildung 2 Assistent für hohe Verfügbarkeit (Zum Vergrößern auf das Bild klicken)

Eingebettete Validierungsprozedur
In früheren Versionen von Windows Server mussten Hardwarekonfigurationen, um als unterstützte Clusterlösung zu gelten, als Clusterlösung im Windows Server-Katalog aufgeführt werden. Dazu gehörten Multisite-Cluster, die separat unter der Kategorie für geografisch verteilte Sites aufgelistet wurden. Für die Aufnahme in den Katalog mussten die Hardwarehersteller eine Reihe von WHQL-Tests (Windows Hardware Quality Labs) durchführen und die Ergebnisse an Microsoft übermitteln. Dies war eine kostspielige Angelegenheit für Anbieter, und die Datenbank für den Windows Server-Katalog war schwierig zu verwalten.
In Windows Server 2008 ist ein integrierter Validierungsprozess im Failoverclustering inbegriffen. Dieser Prozess besteht aus einer Reihe von Tests, die in vier Hauptkategorien eingeteilt werden, wie in Abbildung 3 gezeigt.
Abbildung 3 Testkategorien für die Failovercluster-Validierung (Zum Vergrößern auf das Bild klicken)
Sie sehen, dass die Netzwerkkategorie erweitert wurde und die ausgeführten Tests anzeigt. Jede Kategorie enthält eine Reihe von Tests. Die Kategorie „Speicher“ (vielleicht die wichtigste der vier Kategorien) enthält Tests, mit denen sichergestellt wird, dass Speicherlösungen den neuen Anforderungen entsprechen, die an Windows Server 2008-Failovercluster gestellt werden.
Insbesondere müssen Hardwarehersteller jetzt Treiber auf Basis des Storport-Treibers von Microsoft verwenden, und sie müssen die permanente SCSI-3-Reservierung unterstützen. Darüber hinaus müssen Multipfadgeräte-spezifische Module (sofern verwendet) auf dem Microsoft-Standard für Multipfadeingabe/-ausgabe basieren.
Mit der Integration des Validierungsprozesses hat sich das Supportmodell geändert. Alle Hardwarekomponenten müssen mit einem Windows Server 2008-Logo versehen sein, und alle Validierungstests müssen bestanden werden. Die einzige Ausnahme bilden Multisite-Cluster mit zwei separaten und unterschiedlichen Speichersystemen (eines an jedem Standort) und die Implementierung der fortlaufenden Clusterreplikation in Exchange Server 2007, die keinen freigegebenen Speicher verwendet.

Neues Quorummodell
Das Quorummodell hat sich im Windows Server 2008-Failoverclustering ebenfalls geändert. In älteren Systemen dachte ein Administrator beim Wort „Quorum“ an einen freigegebenen Datenträger, auf dem sich die Clusterkonfiguration und einige replizierte Dateien befanden. Dies war eine einzelne Fehlerquelle im Cluster. Bei Ausfall des Quorumdatenträgers wurde der Clusterdienst beendet, und die hohe Verfügbarkeit ging verloren.
Windows Server 2003-Servercluster boten einen zweiten Quorumtyp namens Hauptknotensatz-Quorum. Diese Art Quorum wurde in der Regel in Multisite-Clustern implementiert und erforderte keinen freigegebenen Speicher. Das Hauptknotensatz-Quorum bestand aus einer Dateifreigabe, die sich auf dem Systemlaufwerk auf jedem Clusterknoten befand. Die Verbindung zu diesem Quorumtyp wurde über SMB-Verbindungen (Server Message Block) hergestellt. Auch hier musste die Mehrheit der Knoten beteiligt sein, wenn der Cluster funktionieren sollte.
Mit der Einführung der fortlaufenden Clusterreplikation (CCR) in Exchange Server 2007 wurde Windows Server 2003-Serverclustern die Dateifreigabenzeugenfunktion (FSW) hinzugefügt. Damit konnte ein einzelner Exchange 2007-CCR-Clusterknoten (oder jeder Multisite-Cluster) weiterhin Dienste zur Verfügung stellen, solange eine Verbindung zum Dateifreigabenzeugen dazu führte, dass eine Mehrheit erreicht wurde.
In Windows Server 2008-Failoverclustering bedeutet das Konzept des Quorums jetzt wahrhaft Konsens. Quorum oder Konsens wird nun dadurch erreicht, dass genügend Stimmen vorhanden sind, um den Cluster dienstbereit zu machen. Genügend Stimmen können auf verschiedene Weise erlangt werden, je nach der Quorumkonfiguration. Die vier in einem Windows Server 2008-Failovercluster verfügbaren Quorummodi werden in Abbildung 4 gezeigt. Von den vier aufgeführten Modi können nur die ersten beiden („Knotenmehrheit“ und „Knoten- und Datenträgermehrheit“) während des Prozesses der Clustererstellung automatisch ausgewählt werden. Die folgende Logik sollte verwendet werden:
  • Bei Konfiguration einer ungeraden Zahl von Knoten im Cluster wählen Sie den Modus „Knotenmehrheit“ aus.
  • Wenn eine gerade Zahl von Knoten im Cluster konfiguriert wird und freigegebener Speicher angeschlossen und zugänglich ist, wählen Sie den Modus „Knoten- und Datenträgermehrheit“ aus.
Abbildung 4 Quorummodi im Assistenten zum Konfigurieren des Clusterquorums (Zum Vergrößern auf das Bild klicken)
Um einen Zeugendatenträger aus dem verfügbaren Speicher auszuwählen, wählen Sie den ersten Datenträger aus, der mindestens 500 Megabyte groß ist und auf dem eine NTFS-Partition konfiguriert wurde. Die übrigen Quorummodi können Sie nur manuell auswählen, indem Sie den Assistenten zum Konfigurieren des Clusterquorums ausführen. Die Option „Knoten- und Dateifreigabemehrheit“ wird in der Regel in einer Multisite-Clusterkonfiguration oder in einem Exchange 2007-CCR-Cluster verwendet. Die letzte Option „Keine Mehrheit: Nur Datenträger“ entspricht dem Modell des freigegebenen Quorums in Legacyclustern. Als eine einzelne Fehlerquelle sollte diese Option normalerweise nicht verwendet werden.
Es gibt nur zwei Arten von Zeugenressourcen, einen physikalischen Datenträger und eine Dateifreigabe, die im Cluster konfiguriert werden können, um Konsens zu erreichen.
Ein Zeugendatenträger ist eine Speicherkomponente, die der Clusterdienst online schalten kann. Dieser Datenträger befindet sich in der Gruppe der Clusterkernressourcen, zusammen mit dem Clusternetzwerknamen und den dazugehörigen IP-Adressressourcen. Wenn der Zeugendatenträger konfiguriert wird, werden ein Clusterordner und eine vollständige Kopie der Clusterkonfiguration (eine Clusterstruktur oder ein Replikat) auf dem Datenträger abgelegt.
Ein Dateifreigabenzeuge ist eine Netzwerkfreigabe, die sich idealerweise auf einem Server im Netzwerk befindet, der nicht Teil des Clusters ist. Zum Dateifreigabenzeugen wird eine SMB-Verbindung hergestellt, und der Dateifreigabenzeuge verwaltet eine Kopie der Zeugenprotokolldatei, die Versionsinformationen für die Clusterkonfiguration enthält.
In einem Cluster kann nur eine Zeugenressource konfiguriert werden. Diese Ressource stellt eine zusätzliche Stimme bereit, falls der Cluster diese Stimme benötigt, um das Quorum zu erreichen. Mit anderen Worten: Wenn dem Cluster eine Stimme (und daher ein Knoten) am Konsens fehlt, wird die Zeugenressource online geschaltet, damit das Quorum erreicht werden kann. Wenn dem Cluster mehr als eine Stimme zum Erreichen des Quorums fehlt, bleibt die Zeugenressource unbehelligt. Der Cluster verbleibt in einem inaktiven Zustand und wartet auf den Beitritt eines anderen Clusterknotens.

Verbesserte Sicherheitsfeatures
Failovercluster zeichnen sich durch mehrere neue Sicherheitsverbesserungen aus. Die vielleicht wichtigste besteht darin, dass die Notwendigkeit eines Clusterdienstkontos entfällt. In früheren Versionen des Microsoft-Clusterdiensts war während des Konfigurationsprozesses ein Domänenbenutzerkonto erforderlich. Dieses Konto, das zum Starten des Clusterdiensts verwendet wurde, wurde der lokalen Administratorengruppe an jedem Knoten des Clusters hinzugefügt. Ihm wurden die erforderlichen lokalen Benutzerrechte gewährt, die gewährleisteten, dass der Clusterdienst richtig funktionierte. Als Domänenbenutzerkonto war das Clusterdienstkonto abhängig von verschiedenen Richtlinien auf Domänenebene, die auf Clusterknoten angewendet werden konnten. Diese Richtlinien wirkten sich mitunter negativ auf die hohe Verfügbarkeit aus, indem sie den Ausfall des Clusterdiensts verursachten.
Der Clusterdienst wird jetzt unter einem lokalen Systemkonto mit spezifischen Berechtigungen auf dem lokalen Clusterknoten ausgeführt, die das richtige Funktionieren gewährleisten. Der Sicherheitskontext für den Cluster wurde auf das Clusternamenobjekt übertragen. Dies ist das Computerobjekt, das bei der Erstellung des Clusters standardmäßig im Container „Computer“ in Active Directory® erstellt wird. Wenn ein Cluster erstellt wurde und das Clusternamenobjekt in Active Directory besteht, wird das Benutzerkonto, das zur Installation und Konfiguration des Clusters verwendet wurde, nicht länger benötigt.
Weitere in Active Directory im Container „Computer“ erstellte Computerobjekte werden einem Failovercluster zugeordnet. Diese Objekte, die virtuelle Computerobjekte genannt werden, entsprechen Cluster-Netzwerknamenressourcen, die als Teil von Clientzugriffspunkten im Cluster erstellt werden. Das Clusternamenobjekt, das für die Erstellung aller virtuellen Computerobjekte in einem Cluster verantwortlich ist, wird der Systemzugriff-Steuerungsliste für das Objekt in Active Directory hinzugefügt (siehe Abbildung 5).
Abbildung 5 Sicherheit in einem virtuellen Computerobjekt in Active Directory (Zum Vergrößern auf das Bild klicken)
Das Clusternamenobjekt übernimmt auch die Verantwortung für die Synchronisierung der Domänenkennwörter für alle von ihm erstellten virtuellen Computerobjekte. Dieser Prozess wird gemäß der konfigurierten Domänenrichtlinie für Kennwortrotation ausgeführt. Da das Clusternamenobjekt für die Erstellung aller Computerobjekte für die virtuellen Computerobjekte in einem Cluster verantwortlich ist, muss das Computerkonto auf Domänenebene über die Berechtigung verfügen, Computerobjekte in dem Container zu erstellen, in dem die virtuellen Computerobjekte erstellt werden (standardmäßig ist dies der Container „Computer“).
Eine weitere Änderung besteht darin, dass Kerberos jetzt als Standardauthentifizierungsmethode verwendet wird. Die Existenz von Computerkonten in Active Directory ermöglicht dieses verbesserte Sicherheitsfeature. Der Cluster verfügt jedoch über die Fähigkeit, NT LAN-Manager-Authentifizierung zu verwenden, wenn eine Anwendung, die Kerberos nicht zur Authentifizierung verwenden kann, den Zugriff auf Clusterressourcen erfordert.
Auch die Sicherheit der Kommunikation zwischen Clusterknoten, die direkt mit dem Clusterprozess arbeiten, wurde erhöht. Die interne Clusterkommunikation ist standardmäßig signiert. Mithilfe des Common Language Interface (CLI) für „cluster.exe“ kann diese Clustereigenschaft so geändert werden, dass die Kommunikation zwischen Knoten grundsätzlich verschlüsselt wird, was die Sicherheit zusätzlich erhöht.

Erweiterte Netzwerkfunktionen
Neue Netzwerkfunktionen in Failoverclustern ermöglichen mehr Flexibilität beim Entwerfen von Lösungen für hohe Verfügbarkeit und zur Notfallwiederherstellung. Gleichzeitig sorgen diese Netzwerkverbesserungen für zuverlässigere Konnektivität unter den Knoten im Cluster.
Das wahrscheinlich am häufigsten von Kunden gewünschte Feature war die Fähigkeit, Clusterknoten in separaten Netzwerken zu suchen. Dies ist jetzt möglich. Der Clusternetzwerktreiber wurde vollständig umgeschrieben und bietet nun höchst zuverlässige und fehlertolerante Kommunikation unter Knoten in einem Cluster, vorausgesetzt, jeder Knoten ist mit mindestens zwei separaten und klar gerouteten Netzwerken verbunden.
Der Clusternetzwerktreiber erstellt seine eigene interne Routingtabelle auf der Grundlage der Konnektivitätsinformationen, die er während des Clusterstarts erhält. Diese enthält lokale Konnektivitätsinformationen sowie Informationen aus der Clusterkonfigurationsdatenbank (Clusterregistrierungsstruktur).
Teil des Clustervalidierungsprozesses ist ein Prozess der Ermittlung der Netzwerkkonnektivität. Dank der Fähigkeit, Clusterknoten in verschiedenen, gerouteten Netzwerken ausfindig zu machen, sind die Netzwerkanforderungen für Multisite-Cluster geringer. Damit wird die Bereitstellung für Organisationen einfacher und weniger kostspielig. Außerdem wird die Verwendung von iSCSI-Speicher als Speicherlösung in Failoverclustern attraktiver.
Clusterknoten können zudem IP-Adressinformationen über DHCP (Dynamic Host Configuration-Protokoll) abrufen. Dies kann Netzwerkadministratoren die Arbeit erleichtern, wenn die Verwendung dynamischer Adressierung für die Server in ihrer Umgebung in Frage kommt.
Von der Konfiguration der Netzwerkschnittstellen eines Clusters wird bestimmt, welche Netzwerke statische oder dynamische IP-Adressen verwenden. Auch wenn eine IP-Adressressource in einem Cluster von einem DHCP-Server abgerufen wird, kann sie im Failovercluster-Verwaltungs-Snap-In in eine statische IP-Adresse geändert werden.
In der Vergangenheit wurde für die Clusterkommunikation grundsätzlich UDP-Broadcast verwendet, in einigen Fällen Multicast. Multicastfunktionen stehen nicht länger zur Verfügung, und die Clusterkommunikation verwendet jetzt UDP-Unicast. (Der allgemein von Microsoft-Clustern verwendete Port ist nach wie vor Port 3343.) Viele Netzwerkadministratoren werden froh sein, dass Broadcast nicht mehr verwendet wird. Der wahre Vorteil liegt jedoch in den neuen Messagingprozessen, die dem Clusterdienst eigen sind. (Dies zu erläutern würde jedoch den Rahmen dieses Artikels sprengen.) Die interne Clusterkommunikation verfügt jetzt über Merkmale einer zuverlässigeren TCP-Kommunikation, obgleich UDP als Transportmechanismus verwendet wird.

Höhere Zuverlässigkeit bei Interaktion mit dem Speicher
Die Art und Weise der Interaktion zwischen Failoverclustern und Speicher hat sich radikal geändert. Der Clusterdatenträger (clusdisk.sys) wurde vollständig umgeschrieben und ist jetzt ein echter PnP-Treiber (Plug and Play). Die Interaktion des Clusterdatenträgers mit dem Speicher hat sich ebenfalls geändert.
In Windows Server 2003 war der Clusterdatenträgertreiber in einem direkten Pfad zum Speicher konfiguriert. In Windows Server 2008 jedoch kommuniziert der Clusterdatenträgertreiber mit dem Treiber des Partitions-Managers (partmgr.sys), um mit dem Speicher zu interagieren. Diese beiden Ansätze werden in Abbildung 6 gezeigt.
Abbildung 6 Änderung des Speicherstapels in Windows Server 2008 (Zum Vergrößern auf das Bild klicken)
Der Partitions-Manager trägt die primäre Verantwortung für den Schutz der Clusterdatenträgerressourcen. Alle Datenträger in einem freigegebenen Speicherbus werden bei der ersten Zuordnung zu einem Clusterknoten automatisch in einen Offlinezustand versetzt. Damit ist es möglich, allen Knoten in einem Cluster gleichzeitig Speicher zuzuordnen, noch bevor der Cluster erstellt wird. Es ist nicht mehr notwendig, Knoten einzeln nacheinander zu starten, Datenträger auf einem Knoten vorzubereiten und den Knoten dann herunterzufahren, einen anderen Knoten zu starten, die Datenträgerkonfiguration zu verifizieren und so weiter.
Im Rahmen des Clustervalidierungsprozesses müssen jedoch nach wie vor Speichertests ausgeführt werden. Diese Tests erfordern die Initialisierung der Datenträger. Dies kann auf einem der Knoten des Clusters erfolgen, bevor der Validierungsprozess ausgeführt wird. Nachdem einem Cluster Speicher hinzugefügt wurde, erhalten die Datenträger in der Schnittstelle „Datenträgerverwaltung“ den Status „Reserviert“ und befinden sich nie in einem ungeschützten Zustand.
Eine weitere Änderung betrifft die SCSI-Befehle. In Windows Server 2003 wurden SCSI-2-Befehle zum Reservieren\Freigeben für den Clusterdatenträgertreiber verwendet, der in Sektoren auf dem Datenträger selbst schreibt. In Windows Server 2008 sind SCSI-3-Befehle für permanente Reservierung erforderlich. Clusterknoten müssen registriert werden, bevor sie eine Reservierung im Speicher vornehmen dürfen, und Clusterknoten verteidigen ihre Reservierungen regelmäßig mithilfe des Reservierungs- und Verteidigungsprotokolls.
Mit einem der Speichertests im Validierungsprozess wird diese Funktion überprüft. Wenn eine Speicherlösung keine Unterstützung für SCSI-3-Befehle für permanente Reservierung bietet, kann sie in einem Failovercluster nicht unterstützt werden.
Viele Organisationen verwenden Multipfadsoftware für Redundanz bei der Herstellung einer Verbindung zum Speicher. Dies wird unterstützt und sogar als bewährte Methode eingestuft. Multipfadsoftwarelösungen von Drittanbietern oder gerätespezifische Module müssen jedoch unter Verwendung des Microsoft-Standards für Multipfadeingabe/-ausgabe, der in einem Failovercluster unterstützt werden soll, umgeschrieben werden. Dadurch wird sichergestellt, dass alle SCSI-3-Befehle für permanente Reservierung gleichzeitig auf allen Pfaden zum Speicher gesendet werden, unabhängig davon, ob der Pfad aktiv ist oder nicht. Diese Funktion wird ebenfalls im Rahmen des Validierungsprozesses überprüft.
Weitere Speicherverbesserungen sind ein verbesserter Prozess der Datenträgerüberprüfung (chkdsk.exe), eine integrierte Funktion zur Datenträgerreparatur, die davor Teil des Dienstprogramms für die Clusterserverwiederherstellung war, sowie sich selbst reparierende Datenträger. In Failoverclustern werden die Datenträgersignatur und die LUN-ID zur Identifizierung einer Clusterdatenträgerressource verwendet. Wenn sich eine von beiden ändert, wird die Clusterkonfiguration aktualisiert. Dies bedeutet eine geringere Zahl von Fehlern, da eine Attributsänderung auf einem physikalischen Datenträger zu höherer Verfügbarkeit führt.

Integrierte Wiederherstellungsprozesse
Die bereits erwähnte Datenträgerreparatur ist offensichtlich eine der integrierten Wiederherstellungsfunktionen. Eine weitere ist die Funktion zur Active Directory-Reparatur. Wenn das Computerobjekt, das das Clusternamenobjekt darstellt, gelöscht wird, können Sie keine Computerobjekte mehr erstellen, die Cluster-Clientzugriffspunkten zugeordnet sind. Das erste auftretende Problem besteht jedoch wahrscheinlich darin, dass hoch verfügbare Anwendungen oder Benutzer nicht mehr auf Ressourcen außerhalb des Clusters zugreifen können, da kein Sicherheitstoken abgerufen werden kann.
Die Wiederherstellung eines gelöschten Clusternamenobjekts ist ein zweistufiger Prozess. Zuerst müssen Sie einen Domänenadministrator bitten, das gelöschte Computerobjekt aus dem Container „DeletedObjects“ in Active Directory wiederherzustellen. Nach der Reaktivierung des Objekts führen Sie den Prozess „Active Directory-Objekt reparieren“ im Failovercluster-Verwaltungs-Snap-In aus.
Bei Windows Server 2003-Serverclustern bestand die Möglichkeit, dass die Clusterkonfigurationsdatei im Unterverzeichnis „%systemroot%\cluster“ beschädigt wurde und dann ersetzt werden musste. In Failoverclustern kann die Funktion zur Selbstreparatur helfen. Wenn der Clusterdienst auf einem Knoten startet und die Konfigurationsdatenbank beschädigt ist, wird eine minimale Konfigurationsvorlage unter Verwendung der Informationen im Registrierungsschlüssel „HKLM\System\CCS\Services\ClusSvc\Parameters“ geladen. Der Knoten versucht, einem bereits gebildeten Cluster beizutreten. Wenn dieser Versuch erfolgreich ist, wird eine neue Kopie der Clusterregistrierungsstruktur auf den Knoten übertragen. Kann ein Knoten keinem Cluster beitreten, wird der Clusterdienst beendet.

Neue Sicherungs- und Wiederherstellungsfunktion
Failoverclustering ist mit einem eigenen Volumeschattenkopie-Dienst-Writer ausgestattet. Dies spielt eine wichtige Rolle bei der Sicherung und Wiederherstellung einer Clusterdatenbank und der Daten auf den physikalischen Datenträgerressourcen. Eine Sicherungskopie der Clusterkonfiguration zu erstellen, ist eine ziemlich einfache Aufgabe. Sofern der Systemstatus in die Sicherung einbezogen wird, kann die Clusterkonfiguration wiederhergestellt werden. Beachten Sie jedoch, dass die Sicherung eines Clusters nur dann erfolgen sollte, wenn für den Cluster Quorum besteht. So wird garantiert, dass die neueste Clusterkonfiguration gesichert wird.
Es gibt zwei unterschiedliche Arten der Clusterwiederherstellung: autorisierend und nicht autorisierend. Bei einer nicht autorisierenden Wiederherstellung wird mithilfe der Windows Server-Sicherung oder einer Anwendung eines Drittanbieters eine Wiederherstellung von einer ausgewählten Sicherung ausgeführt. Für eine autorisierende Wiederherstellung eines Clusterknotens hingegen ist die CLI der Windows Server-Sicherung (wbadmin.exe) erforderlich.
Bei einer autorisierenden Wiederherstellung wird die Clusterkonfiguration im Grunde „in die Vergangenheit“ zurückversetzt, an den Zeitpunkt, zu dem die Sicherung durchgeführt wurde. Um eine autorisierende Wiederherstellung durchzuführen, wird der Clusterdienst auf allen Knoten beendet, mit Ausnahme des Knotens, auf dem die Wiederherstellung ausgeführt wird. Wenn die Wiederherstellung abgeschlossen ist und der Clusterdienst auf dem wiederhergestellten Knoten gestartet wurde, wird die wiederhergestellte Konfiguration des Clusters zur endgültigen neuen Clusterkonfiguration. Wenn der Clusterdienst dann auf den übrigen Knoten im Cluster neu gestartet wird, wird die wiederhergestellte Konfiguration während des Beitrittsprozesses übertragen.
In bestimmten Szenarios lassen sich so Zeit und Geld in großem Umfang sparen. Angenommen, Sie arbeiten mit einem Druckcluster, der mehrere Druckerspoolerressourcen hostet, von denen jede 1.500 Drucker unterstützt, und Sie löschen versehentlich eine der Druckerspoolerressourcen. Zahlreiche Benutzer können nun nicht drucken. Anstatt alle diese Drucker der Clusterkonfiguration manuell wieder hinzuzufügen, können Sie in wesentlich kürzerer Zeit eine autorisierende Wiederherstellung der Clusterkonfiguration durchführen. Dies hängt selbstverständlich davon ab, ob eine solide Sicherungs- und Wiederherstellungsstrategie existiert.

Migrieren von Windows Server 2003-Serverclustern
Aufgrund dieser zahlreichen Architekturänderungen in Windows Server 2008-Failoverclustering werden direkte oder parallele Aktualisierungen von Windows Server 2003 nicht unterstützt. Beim Aktualisieren von Windows Server 2000-Clustern auf Windows Server 2003 würden viele Organisationen systematisch jeden Knoten im Cluster entfernen, eine Neuinstallation des Betriebssystems ausführen und dann den Knoten dem Cluster wieder hinzufügen. Dieses Verfahren eignet sich nicht für die Migration zu Windows Server 2008, da Windows Server 2003- und Windows Server 2008-Clusterknoten nicht Teil desselben Clusters sein können.
Glücklicherweise steht ein assistentenbasierter Migrationsprozess zur Verfügung, der die Migration erleichtert. Die Migration zu einem Windows Server 2008-Failovercluster erfordert trotz allem einige Planung. Es gibt drei grundlegende Migrationsszenarios:
  • Verwenden derselben Server und Speichersysteme.
  • Verwenden derselben Server, jedoch mit neuem Speicher.
  • Verwenden neuer Server und neuer Speichersysteme.
Bei allen diesen Szenarios muss sichergestellt werden, dass die Hardware unter dem Windows Server 2008-Logo-Programm zertifiziert wurde, dass der Prozess der Failovercluster-Validierung abeschlossen ist und alle Tests bestanden wurden. Nach Abschluss dieser Schritte kann der Migrationsprozess fortgesetzt werden.
Nicht für alle Ressourcen in einem Windows Server 2003-Servercluster ist eine Migration möglich. Sie können Netzwerknamen, IP-Adressen, physikalische Datenträger, Dateifreigaben, DFS-Stämme, DHCP und WINS migrieren. In begrenztem Umfang lassen sich auch allgemeine Dienste, generische Anwendungen und Ressourcen für allgemeine Skripte migrieren.
Für Anwendungen wie Microsoft Exchange und SQL Server® existieren eigene Verfahren für die Migration zu einem Failovercluster. Drucker können mithilfe des Snap-Ins „Druckverwaltung“ (das mit der Druckserverrolle installiert wird) zu Windows Server 2008 migriert werden, um Drucker zuerst zu exportieren und dann in einen neu konfigurierten Druckserver mit hoher Verfügbarkeit zu importieren. Ressourcentypen von Drittanbietern für die Migration nicht geeignet.
Beim Migrationsprozess werden keine Daten migriert. Dabei werden Clusterkonfigurationseinstellungen von Windows Server 2003 zu Windows Server 2008 migriert.
Alle migrierten Ressourcen befinden sich nach Abschluss des Migrationsprozesses zunächst in einem Offlinezustand. Dies wird deshalb so gehandhabt, weil möglicherweise zusätzliche Schritte erforderlich sind. Deshalb ist es wichtig, den Postmigrationsbericht daraufhin zu überprüfen, welche zusätzlichen Schritte (außer der Datenmigration, wenn zu neuem Speicher migriert wird) erforderlich sind, um den Cluster dienstbereit zu machen. Wenn beispielsweise ein DHCP-Server migriert wird, muss die Funktion des DHCP-Servers auf allen Knoten im Cluster installiert werden. Bei Migration eines WINS-Servers muss das WINS Server-Feature auf allen Knoten im Cluster installiert werden.

Chuck Timon ist Support Escalation Engineer bei Microsoft und unterstützt Cluster- und Installationstechnologien. Er hat das Schulungsmaterial für Windows Server 2008-Failovercluster verfasst und arbeitet momentan an der Hyper-V-Schulung.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Mitteilung der Redaktion Printmedien sind tot
Joshua Hoffman

Printmedien sind tot. Oder zumindest sollen wir das glauben. Welchen Sinn hat in der Ära unbegrenzter Informationen, die in jeder Form jederzeit und überall auf unzähligen fantastischen Geräten verfügbar sind, eine Sammlung von Blättern, die mit Leim zusammengehalten werden? Ist diese Ära nicht längst vergangen? Sollten Zeitschriften und Zeitungen in die Hallen des Smithsonian Instituts verbannt werden, damit wir eines Tages in einem Anflug von Nostalgie über die gute, alte Zeit schwärmen können, in der wir zusammengepresste Baumteile und Druckerschwärze mit uns herumgetragen haben?
Ist das nicht ein bisschen melodramatisch? Ja. Wahrscheinlich haben Sie schon erraten, dass dies eine Prämisse ist, mit der ich absolut nicht einverstanden bin (und nicht nur aus Gründen der Arbeitsplatzsicherheit, denn schließlich gibt es bei Microsoft viele andere Dinge, die ich tun könnte). Ich glaube fest daran, dass das gedruckte Wort eine unglaublich tiefgehende und umfassende Erfahrung bietet, trotz (oder vielleicht gerade wegen) seiner Einfachheit. Wenn ich mich hinsetze, um einen langen Artikel zu lesen, nehme ich vorzugsweise ein Druckprodukt zur Hand, statt an meinem Computerbildschirm zu sitzen. Für mich ist das einfach viel ansprechender. Ist diese Einstellung veraltet? Das mag sein, aber unserer aktuellen Leserumfrage zufolge sind 90 Prozent unserer Leser genau derselben Meinung.
Natürlich bin ich nicht der Meinung, dass wir unseren Kopf in den Sand stecken sollten. Ich bin computerbesessen und liebe Technologie. Doch eine Publikation wie die unsere kann – und sollte – eine ganzheitliche Erfahrung sein, die viele Formen annimmt – online, offline und persönlich. Wenn ich einen langen, sehr technischen Artikel von Mark Russinovich lese, möchte ich, dass er mir im Druck vorliegt. Doch ich möchte Mark auch während eines Vortrags hören und sehen, wie er das erläuterte Verfahren vorführt.
Dieser Gedanke ist ein Leitprinzip für das TechNet Magazin geworden. Obwohl wir weiterhin stolz sind auf die Publikation, die wir jeden Monat an die Druckerei liefern, ist der gesamte Inhalt, den wir je veröffentlicht haben, auch unter .com verfügbar. Und bald wird es mehr Inhalt geben, der die besondere Plattform nutzen kann, die uns im Internet zur Verfügung steht. So haben wir beispielsweise in unserer letzten Ausgabe mit unserer Screencast-Reihe mit Don Jones und seiner Windows Power-Shell-Kolumne begonnen. Sie können sich jetzt ein Video von Don ansehen, in dem er Sie durch das Thema des Artikels des jeweiligen Monats führt. Auf unserer Website gibt es auch eine neue Kolumne zur nachhaltigen Computernutzung, die sich umfassend mit den Umweltauswirkungen der Informationstechnologie und damit befasst, was wir als IT-Experten tun können, um verantwortliche globale Bürger zu sein.
Wie immer ist Ihr Feedback wichtig für uns, während wir damit fortfahren, das TechNet Magazin zu einer umfassenden Medienerfahrung auszubauen. Schreiben Sie uns unter tnmag@microsoft.com.
– Joshua Hoffman

Unser Dank gilt folgenden technischen Experten von Microsoft: Ed Banti, Avronil Bhattacharjee, Nino Bilic, Mai-lan Tomsen Bukovec, Eric Charran, Elden Christensen, Trina Gorman, Scott Landry, Michael Murgolo, Sanjeev Nair, Hugh Pyle, Amritansh Raghav, Jez Sadler und Jim Truher.

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Briefe Leser sagen ihre Meinung

Active Directory-Domänendienste
Die Ausgabe des TechNet Magazin vom März 2008 hat mir sehr gefallen. Ich glaube, ich habe sie mittlerweile zwölfmal gelesen! Besonders interessant war der Artikel „Neuerungen in Active Directory-Domänendiensten“ von Gil Kirkpatrick. In seinem Artikel erwähnt Gil ein Produkt mit der Bezeichnung Microsoft® Audit Collection Services. Ist dieses Produkt schon verfügbar, und funktioniert es als eigenständige Anwendung?
– Erasmo M.

Microsoft Audit Collection Services (ACS) ist Teil von System Center Operations Manager (SCOM). Dabei handelt es sich um die Verwaltungssoftware, die früher als Microsoft Operations Manager (MOM) bezeichnet wurde. ACS ist nicht als eigenständiges Produkt verfügbar, sondern nur als Teil von SCOM.
– Gil Kirkpatrick, NetPro CTO und Autor des TechNet Magazin

Signaturen
Im zweiten Absatz des Windows PowerShell-Artikels der Ausgabe des TechNet Magazin vom April 2008 („Hier signieren, bitte“ technet.microsoft.com/magazine/cc434702) erklärt der Autor Don Jones: „Das Wort „Signatur“ ist der richtige technische Begriff für das, was hier behandelt werden soll, obwohl das Wort selbst keine wirklich gute Beschreibung dafür ist, was dabei tatsächlich vor sich geht. Ein Skript zu signieren, heißt nicht, dass Sie es genehmigen oder autorisieren, wie das bei einem Vertrag oder einer Kreditkartenquittung der Fall ist.“
Ich würde argumentieren, dass das Unterzeichnen eines Vertrags oder einer Kreditkartenquittung ebenfalls nicht unbedingt eine Genehmigung oder Autorisierung der betreffenden Dokumente ist. Die durchgeführte Aktion ist nur im Kontext einer umfassenderen Sichtweise der Umgebung bedeutsam. Als Kind spielte ich mit den Kreditkartenquittungen in der Tankstelle meines Vaters. Niemand versuchte jemals, die Schulden einzutreiben, die durch diese Transaktionen entstanden.
Im Kontext einer „richtig konfigurierten“ Active Directory®-Netzwerkimplementierung ist es die Signatur, die das Ausführen des Skripts autorisiert. Das Vorhandensein der Signatur zeigt an, dass die signierende Person die Verantwortung dafür übernimmt, was sie signiert hat, und das Vorhandensein der Signatur kann dann weitere Aktivitäten auslösen, etwa die Rechnungsstellung durch das Kreditkartenunternehmen oder die Annahme des Codes als authentischen Code durch das Netzwerk.
Bitte macht weiter so. Das TechNet Magazin ist von sehr großem Nutzen.
– Jeremy P.

Danke für das Feedback, Jeremy. Es ist gut zu wissen, dass unsere Leser dem TechNet Magazin so scharfe, kritische Aufmerksamkeit schenken.

SharePoint Services
Sind beim Ausführen von Windows® SharePoint® Services (WSS), nicht Microsoft Office SharePoint Server, zusätzliche CAL-Lizenzen für Benutzer erforderlich, die über eine Website-Benutzeroberfläche/URL darauf zugreifen?
– Douglas M.

Zu diesem Thema gibt es einige Dokumente. Hier sind einige hilfreiche Links: msmvps.com/blogs/cgross/archive/2005/04/02/40723, microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx und windowsserver/sharepoint/bb684457.
– Pav Cherny, Autor, Einblicke in SharePoint, TechNet Magazin

Idee für „Einblicke in SharePoint“
Kürzlich las ich den SharePoint-Artikel in der Ausgabe des TechNet Magazin vom Mai 2008 (technet.microsoft.com/magazine/cc462809). Dort wurden die Leser zum Unterbreiten von Themenvorschlägen aufgefordert. Ein umfassender Artikel zum Integrieren von SharePoint in Project/Project Server wäre wunderbar.
– Phil H.

Project/Project Server ist eine hervorragende Idee! Wir werden dieses Thema für einen zukünftigen Artikel mit Sicherheit in Betracht ziehen. Danke für Ihre Antwort.

Weitere Ideen für „Einblicke in SharePoint“
Das Web bietet eine Vielzahl von Dokumenten zur Websiteanpassung mithilfe der standardmäßigen SharePoint-Benutzeroberfläche oder SharePoint Designer, aber es gibt wenig Informationen zu Websitedefinitionen (und die vorhandenen Artikel sind so elementar, dass sie bei realen Problemen kaum Nutzen bieten). Da dies ein Bereich ist, mit dem sich immer mehr Personen beschäftigen, könnte eine Vielzahl von Anleitungen bei der Akzeptanz von SharePoint helfen. In meinem Unternehmen hatten wir besonders mit folgenden Themen zu kämpfen:
  1. Einstellen von benutzerdefinierten Berechtigungen auf Listen innerhalb einer Websitedefinition.
  2. Benutzerdefinierte Listenelementformulare innerhalb einer Websitedefinition.
  3. Webpartverbindungen innerhalb einer Websitedefinition.
  4. Wie eine Websitedefinition inkrementell bereitgestellt werden könnte.
– Adam C.

Vielen Dank für Ihre Vorschläge. Dies ist genau die Art von Leserfeedback, die wir berücksichtigen werden, wenn wir diesen Inhalt weiterentwickeln.


Toolbox Neue Produkte für IT-Experten
Greg Steen

Automatisieren von Administratoraufgaben
Automise 2
automise.com/automise.aspx
Wiederkehrende Aufgaben, die keinen Gedankenaufwand erfordern, sind langweilig, mühsam und fehleranfällig. Die Automatisierung dieser Aufgaben ist ein Schlüssel zur erfolgreichen Administration und kann die Zufriedenheit am Arbeitsplatz erhöhen. Neben tristen Batchdateien und benutzerdefinierten VBScripts zur Automatisierung von Aufgaben gibt es einige makroähnliche Dienstprogramme für Windows® und eine Reihe von Dienstprogrammen, bei denen Sie sogar zwangsweise eine benutzerdefinierte Skriptsprache erlernen müssen. Aber es gibt eine Alternative. Mit Automise 2 von VSoft Technologies erstellen Sie Automatisierungsroutinen in einer grafischen Benutzeroberfläche mit Drag & Drop und anschließender Anpassung.
Die Oberfläche der Anwendung ist ähnlich wie eine einfache Programmierungs-IDE gestaltet und bietet vertraute Optionen. Sie erhalten eine Toolbox, aus der Sie Elemente auf Ihre Entwurfsoberfläche ziehen, außerdem Debug-Steuerelemente, mit denen Sie den Programmcode schrittweise abarbeiten, eine Ansicht der verschiedenen Projekte, Ausgabeausführungsprotokolle, Verlaufsprotokolle und diverse Eigenschaftsfenster. Aber mit Automise wird Ihr „Code“ tatsächlich zu einer visuellen Darstellung der Arbeitsabläufe von automatisierten Aufgaben.
Die Toolbox von Automise umfasst Aktionen, die jeweils für einen einzelnen Schritt im Automatisierungsprozess zuständig sind. Es gibt 380 Aktionen in der Anwendung, womit die gesamte Bandbreite möglicher Vorgänge abdeckt ist, vom Erstellen von ZIP-Dateien bis hin zum Neustarten von IIS.
Beim Entwerfen einer Aufgabe können Sie diese Aktionen hierarchisch ordnen und damit einen Großteil Ihrer regelmäßigen Verwaltungsaufgaben abdecken. Außerdem können Sie die Aktionen über Ablaufsteuerungselemente miteinander verbinden, z. B. Try/Catch-Blöcke, Ausnahmeauslösung, If-Then-Else-Anweisungen, Schleifen, Schalter, Verzögerungen und asynchrone Aktionsgruppen.
Jedes Ihrer Automatisierungsprojekte kann auch andere Projekte enthalten, sodass Sie die Hauptablaufsteuerung von den Unteraufgaben trennen können. Es gibt auch Aktionen zum Ändern von Zeichenfolgen und XML-Daten, zum Festlegen von Variablen, zum Warten auf Prozesse und Befehle und vieles mehr. Dank all dieser Ablaufsteuerungsoptionen rücken sogar komplexe Vorgänge in die Reichweite der Automatisierung.
Mit Automise können Sie geplante Aufgaben erstellen, ausführen, bearbeiten und löschen. Folglich können Sie mit Automise auch Ihre vorhandenen Prozesse verwalten. Im Rahmen dieses Artikels können nicht alle Aktionen aufgeführt werden, aber hier sind einige weitere Glanzlichter: Aktionen zum Registrieren einer DLL im globalen Assemblycache (Global Assembly Cache, GAC), Neuerstellung von SQL Server®-Indizes, Ausführen von chkdsk, Bearbeiten der Registrierung, Erstellen einer Sicherungskopie des Ereignisprotokolls, Bearbeiten von Active Directory®-Benutzern, Bereitstellen von Volumes, Anlegen von Wiederherstellungspunkten, Erstellen eines virtuellen Verzeichnisses. Sollten die integrierten Aktionen für Ihre Zwecke trotzdem nicht ausreichen, bietet Automise auch Aktionen für die Ausführung benutzerdefinierter Skripts, Befehle und Ad-hoc-SQL-Anweisungen.
Alles in allem ist dies ein äußerst nützliches Tool. Wenn Sie nur Ihre eigene Windows-Arbeitsstation automatisieren möchten, also nicht gleich die gesamte Netzwerkinfrastruktur, dann werfen Sie einen Blick auf Automise Lite. Diese Version bietet zwar nicht alle Features, dürfte aber den meisten Poweruser-Anforderungen genügen.
Preis: Einzelbenutzerlizenz ab 195 $ (Direktversand).
Visuelle Automatisierung von Aufgaben mit Automise 2 (Zum Vergrößern auf das Bild klicken)

Überwachen von Protokollen in Echtzeit
BareTailPro
baremetalsoft.com/baretailpro
Protokolldateien gibt es jede Menge. Die Herausforderung ist, sie auch richtig zu nutzen. Es ist großartig, dass Ihre Anwendung ein Protokoll der Transaktionen liefert. Aber wie können Sie neben den normalen Protokolltools feststellen, was in Echtzeit vor sich geht? Eine Lösung ist das bewährte BareTailPro von Bare Metal Software. Obwohl seit 2006 keine Aktualisierungen mehr veröffentlicht wurden, ist und bleibt dieses einfache Dienstprogramm immer noch ein verbessertes Windows-Pendant zum *nix-Befehl „tail -f“ .
Auf einer einfachen grafischen Benutzeroberfläche können Sie mehrere Protokolldateien beliebiger Größe gleichzeitig anzeigen und beobachten, was in Echtzeit in die Protokolle geschrieben wird. Um zwischen den Dateien zu wechseln, klicken Sie einfach auf die zugehörige Registerkarte. Und noch ein sehr nettes Merkmal: Jede Registerkarte enthält ein Symbol für den Zustand der einzelnen Protokolldateien, aus dem hervorgeht, ob in die Datei geschrieben wird oder der Schreibvorgang beendet ist.
Die meisten Anwendungen bieten ein Protokoll, aber die Vorgehensweisen beim Protokollieren unterscheiden sich meist deutlich. BareTailPro kann glücklicherweise Unicode-, UTF-8-, ANSI- und ASCII-Dateien lesen, und auch CR/LF-Paare, einzelne LFs und Nullen am Zeilenende sind dabei kein Problem. Sie können problemlos sowohl Zeilenumbrüche als auch eine Erweiterung der Registerkarte konfigurieren, um so die beste Darstellung für eine bestimmte Protokolldatei zu erzielen. Außerdem können Sie die Lesbarkeit der Protokolldatei erhöhen, indem Sie den Schriftgrad, die Schriftart, die Abstände und die Zeilenhöhe konfigurieren.
Ein weiteres großartiges Feature ist die konfigurierbare Hervorhebungsfunktion der Anwendung, die Sie auf eine Protokollansicht anwenden können. Dabei können über eine Zeichenfolge beliebig viele Regeln für die Vordergrund-/Hintergrund-Farbcodierung festgelegt werden. Lassen Sie Fehler beispielsweise rot hervorheben und Warnungen gelb, oder geben Sie an, dass alle Zeilen hervorgehoben werden sollen, die eine bestimmte IP-Adresse oder einen bestimmten Hostverweis enthalten. Sie können die Zeilen fett oder kursiv formatieren, und Sie können auch die Groß-/Kleinschreibung in der Zeichenfolge außer Acht lassen.
Sogar mit Texthervorhebungen kann eine umfangreiche Protokolldatei den Rahmen der Ansicht sprengen, sodass es schwierig wird, die gesuchten Ereignisse tatsächlich aufzufinden. BareTailPro bietet ein weiteres Feature, das genau dabei hilft. Mit den Suchfunktionen für reguläre Ausdrücke und Text verkleinern Sie die Protokollansicht im Handumdrehen, wobei die wichtigen Zeileninstanzen in einer überschaubaren Teilmenge isoliert werden. Die Syntax für reguläre Ausdrücke in BareTailPro besteht aus einer Teilmenge der Standardschreibweise, die von Java, Perl, und PHP verwendet wird. Falls Sie mit dieser Schreibweise nicht vertraut sind, erhalten Sie auf der Produktwebsite schnelle Hilfe.
Das Dienstprogramm zeigt die gefilterten Ergebnisse in tabellarischer Form und fügt dabei einige nützliche Spalten an, z. B. ein Zeitstempel, die Zeilennummer und die Ergebnisse aller Erfassungsgruppen, die Sie ggf. zusammen mit der ursprünglichen Zeilenquelle definiert haben. In der gefilterten Ansicht lassen sich diese Spalten auch sortieren.
Ich kann mich nie an die Syntax des „magischen“ regulären Ausdrucks erinnern, der mir genau die Ergebnisse lieferte, die ich brauchte. Daher finde ich das Feature zur Musterspeicherung des Tools wirklich nützlich. Damit können Sie Muster benennen, bearbeiten und für die Wiederverwendung speichern. Sobald die wichtigen Zeilen in der gefilterten Ansicht angezeigt werden, können Sie mit BareTailPro auch die Ergebnisse in maßgeschneiderter Form in eine Datei oder in die Zwischenablage exportieren, wobei Sie beispielsweise die Breite, die Ausrichtung, das Präfix und das Suffix der einzelnen Ergebnisspalten festlegen können.
Beeindruckenderweise kommt dieses winzige Dienstprogramm mit einer einzigen kleinen ausführbaren Datei aus. Damit ist es äußerst portabel und wirkt sich nur minimal auf Ihre Arbeitsumgebung aus. Wenn Sie Ihre Protokolldateien lediglich anzeigen wollen und die Funktionen zum Filtern regulärer Ausdrücke, Speichern von Suchmustern und Exportieren der Such- und Filterergebnisse nicht benötigen, dann ist die kostenlose Version BareTail voll und ganz ausreichend.
Preis: Ab 35 $ für eine Einzelbenutzerlizenz.
Überwachen des Netzwerks mit BareTailPro (Zum Vergrößern auf das Bild klicken)

Inventarisieren von Systemen
Total Network Inventory
softinventive.com
Der schnelle Zugriff auf detaillierte Informationen zu den Computern in Ihrer gesamten Arbeitsumgebung ist ein entscheidender Aspekt für die erfolgreiche Systemverwaltung. Tabellen und Anbieterlisten dieser Informationen werden leicht unübersichtlich, lassen sich nur schwer vollständig halten und sind rasch veraltet.
Hier kann ein dynamisches Tool sehr hilfreich sein, dass die Informationen „auf Abruf“ liefert und dabei Daten darüber sammelt, wer was installiert hat und welche Art von Hardware genutzt wird. Ein solches Tool eröffnet auch die praktische Möglichkeit, die von Benutzern auf ihren Computern installierten Anwendungen und Programme nachzuhalten. (Dies gilt natürlich nur dann, wenn Ihre Gruppenrichtlinie nicht bereits die Installationsrechte beschränkt oder schnell die Anzahl der nötigen Lizenzen liefert, die für die Installation eines bestimmten Softwarepakets vorliegen müssten.) Ein passendes Tool für diese Aufgaben ist Total Network Inventory von Softinventive Lab.
Nach der Installation von Total Network Inventory können Sie gleich die Bestandserfassung mit dem Scanassistenten starten, der Sie durch die Ermittlung der Knoten in Ihrem Netzwerk führt. Sie können wahlweise den Scanvorgang sofort über einen bestimmten IP-Adressbereich oder die Suche nach Computern im Netzwerk einleiten bzw. ein Anmeldeskript für den Scan verwenden, mit dem Informationen gesammelt werden, wenn ein Computer sich bei der Domäne anmeldet.
Beim Scannen greift Total Network Inventory auf die Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) zurück – entweder IPC$\ADMINISTRATOR$ oder RPC/DCOM – und auf die klassische Freigabe lokaler Konten. Sie müssen diese Anwendung daher im Kontext eines Administratorkontos ausführen.
Sobald der Scan abgeschlossen ist, können Sie durch die Angaben zu den Computern blättern oder die Ressourcen bestimmter Computer inventarisieren lassen. Total Network Inventory gliedert die gesammelten Bestandsinformationen in drei Bereiche: Hardware, Software und sonstige Informationen. Der Hardwarebereich enthält Details zum Prozessor, zur Hauptplatine und zum Chipsatz, zum Arbeitsspeicher, Videosubsystem, Speicher (auch physische und logische Geräte), zu Netzwerkadaptertypen und Konfigurationen, zu Peripheriegeräten und zu anderen Geräten, die im System installiert sind.
Der Softwarebereich bietet Informationen zum Betriebssystem, z. B. Produktschlüssel, Seriennummern, Systemverzeichnisse und installierte Service Packs. Es gibt Details zu Hotfixes (mit Nummer des zugehörigen Knowledge Base-Artikels) und zu sämtlichen installierten Antivirus- und Datenbankanwendungen. Außerdem erhalten Sie eine Liste der installierten Programme (zusammen mit einer Ansicht des Verzeichnisses „Programme“, sodass Sie auch die Anwendungen sehen, die in der Standardliste unter „Software“ ausgeblendet sind) sowie eine Liste der Autorun-Anwendungen.
Der Bereich mit den „sonstigen Informationen“ schließlich ist der Sammelpunkt für Details aus der Systemumgebung, z. B. Benutzer- und Systemvariablen, freigegebene Ressourcen, laufende Prozesse, installierte Dienste und lokale Benutzerkonten.
Mit Total Network Inventory erhalten Sie genau die Informationen, die Sie zum Durchführen von Bestandsprüfungen, Lizenzprüfungen, Aktualisierungsberechnungen und Leistungsevaluierungen brauchen. Eine der besten Komponenten dieses Tools ist der Berichtsgenerator. Dieses Feature liefert mehrere gut strukturierte, ausführliche Berichte für alle möglichen Daten, von schnellen Referenzen bis hin zu kompletten Auditunterlagen. Die Berichte können alle Computer oder nur einen einzelnen Computer umfassen. Ein Feature, das ich besonders nützlich finde, ist die Registerkartenansicht über die Software- und Lizenzbuchführung. Hier sehen Sie die Gesamtanzahl der Installationen für jede Software in der gesamten Arbeitsumgebung und können somit sicherstellen, dass Verträge mit Anbietern eingehalten werden.
Preis: Ab 95 $ für eine 25-Knoten-Lizenz.
Der Scanassistent dient zur Ermittlung von Netzwerkknoten (Zum Vergrößern auf das Bild klicken)

Buchbesprechung
Mastering Microsoft Exchange Server 2007
sybex.com
E-Mail ist wohl oder übel eine zentrale Voraussetzung für reibungslose Abläufe in Organisationen. (Ich finde allerdings manchmal wirklich, dass Benutzer vor der Verwendung von E-Mails einen Kurs über effektive schriftliche Kommunikation belegen sollten.) Im Lauf der Jahre hat sich ganz deutlich der Wunsch herauskristallisiert, dabei Features wie Sprachkommunikation, Kalenderfunktionen, Ressourcenplanung, einheitlichen Clientzugriff und E-Mail-Filter (z. B. für Spam, Viren und ähnliches) einzugliedern. Genau hier tritt Microsoft® Exchange Server 2007 auf den Plan.
Bei der aktuellen Version von Exchange sind diese ganzen Komponenten reibungslos in eine skalierbare, stabile Lösung integriert. Aber angesichts ganzen verfügbaren Features brauchen der Administrator, der Architekt und die Supportmitarbeiter schon einige gute Nachschlagewerke, mit denen sie eine solche dynamische Lösung für elektronische Nachrichten planen, bereitstellen, verwalten und pflegen können.
In der letzten Ausgabe der Toolbox-Rubrik wurde das Administratorhandbuch für Microsoft Exchange Server 2007 vorgestellt. Eine weitere gute Ressource ist das Buch „Mastering Microsoft Exchange Server 2007“ von Barry Gerber und Jim McBee (Sybex, 2007). Dieses klar formulierte Handbuch führt Sie durch den gesamten Lebenszyklus von Exchange Server.
Die ersten drei Kapitel in diesem Buch („Understanding and Planning“) befassen sich mit den Grundlagen und der Planung. In diesem Abschnitt werden die grundlegenden Komponenten und die Implementierungsanforderungen von Exchange Server 2007 vorgestellt. Wenn Sie bereits mit früheren Versionen von Exchange vertraut sind, wird Sie der Abschnitt über Funktionen interessieren, die nicht mehr dieselbe Bedeutung tragen oder sogar ganz verschwunden sind. Vor allem die Beschreibung der verschiedenen Serverrollen und der Komponenten einer Bereitstellung von Exchange Server 2007 dürfte allgemein von großem Nutzen sein. Die Bereitstellung eines so komplexen Servers erfordert auf jeden Fall gewisse Vorüberlegungen. Diese Aspekte werden in den Abschnitten über Wachstumsplanung, Speicherplatzanforderungen und Active Directory-Integration behandelt.
Im nächsten Abschnitt wird die eigentliche Installation erörtert, wobei sowohl eine Neuinstallation als auch die Aktualisierung von Exchange Server 2000 oder Exchange Server 2003 erläutert werden. (Die direkte Aktualisierung von Exchange Server 5.5 ist nicht möglich.) Hier erhalten Sie auch weitere Details zu den verschiedenen Rollen, die jeder Exchange Server einnehmen kann, z. B. Edge-Transport, Clientzugriff, Hub-Transport, Postfächer, Unified Messaging und Verwaltungstools.
Anschließend geht es an die Skalierbarkeit. Sie erfahren, wie Sie die Leistung überwachen, weitere Postfachspeicher hinzufügen und vieles mehr. An dieser Stelle wird auch das wirklich coole neue Feature zur fortlaufenden lokalen Replikation (Local Continuous Replication, LCR) erkundet, mit der Sie eine aktuelle lokale Sicherung Ihres E-Mail-Speichers führen. Wenn ein Fehler in der Hauptdatenbank auftritt, können Sie schnell zur Sicherung wechseln, ohne erst die Daten aus einer anderen, weniger verfügbaren und weniger aktuellen Sicherungskopie wiederherstellen zu müssen.
Der nächste Abschnitt dieses Buchs bietet ausführliche Übersichten zu den verschiedenen Verwaltungsaufgaben und Tools, die Sie bei der Bereitstellung von Exchange Server 2007 erhalten. Hierzu gehören beispielsweise die Exchange-Verwaltungsshell (auf der Grundlage der Windows PowerShell™) und die grafische Benutzeroberfläche der Exchange-Verwaltungskonsole (die ebenfalls auf dem Windows PowerShell-Modul aufbaut). In diesem Abschnitt erfahren Sie, wie sich Postfächer, Adresslisten und Benutzerkonten verwalten lassen. Auch die Verwaltung der Messagingdatensätze sowie die Verwaltung von Nachrichtenklassifizierungs-, Journal- und Transportregeln werden erläutert.
Der vierte Abschnitt enthält detaillierte Informationen zu Verfügbarkeit und Zuverlässigkeit. Viele Unternehmen verlassen sich mittlerweile auf die elektronische Nachrichtenübermittlung, und dieser Abschnitt bietet viele wichtige Informationen zu diesem Thema.
Hier erlernen Sie die Grundlagen zu Lastenausgleich, Serverredundanz, Speicherredundanz, Netzwerkredundanz und Clustering. Sie erhalten einen kurzen Überblick über bewährte Methoden für die geplante Wartung, die Ausführung von Sicherungen und Notfallwiederherstellungsszenarien – also im Grunde über alle Dinge, die Sie wissen müssen, damit die elektronischen Nachrichtensysteme Ihres Unternehmens selbst dann noch funktionsfähig bleiben, wenn Probleme auftreten.
Die nächsten beiden Abschnitte in diesem Buch befassen sich mit dem Clientzugriff, z. B. Microsoft Office Outlook® 2007, Outlook Web Access, IMAP und POP3. Der letzte Abschnitt im Buch befasst sich mit den Bereichen Sicherheit und Audits, beides äußerst wichtige Aspekte für Exchange-Administratoren. Es werden grundlegende Sicherheitsverfahren und Vorsichtsmaßnahmen sowie verschiedene Audittools vorgestellt. Dieses detaillierte Referenzhandbuch bietet alle Informationen, die für eine erfolgreiche Exchange-Bereitstellung erforderlich sind.
Preis: 49,99 $ (Direktversand).

Greg Steen ist Technologieexperte, Unternehmer und Enthusiast. Er ist immer auf der Suche nach neuen Tools, um IT-Experten Betriebs-, Qualitätssicherungs- und Entwicklungsprozesse zu erleichtern.
© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Schwerpunkt Dienstprogramme Microsoft SharedView
Greg Steen

Ich arbeite häufig mit Teammitgliedern am anderen Ende der Welt zusammen und finde mich ständig in Situationen, in denen es vorteilhaft wäre, wenn jeder denselben Desktop anschauen und benutzen könnte, damit wir alle unsere Ansichten wirksamer illustrieren und klarer darstellen könnten.
Angenommen Ihr Vertriebsteam ist unterwegs, und die Teammitglieder müssen schnell zusammenkommen, um Informationen gemeinsam zu nutzen, Angebote zu prüfen und doppelte Arbeit zu vermeiden. Überlegen Sie, wie viel höher die Produktivität wäre, wenn alle im Team dieselbe Microsoft® Office Excel®-Tabelle oder dasselbe Word-Dokument fast gleichzeitig betrachten und bearbeiten könnten, statt ein „Live-Dokument“ mühsam per E-Mail hin- und herzusenden, was schnell dazu führt, dass verschiedene Versionen kursieren. Jetzt gibt es ein einfaches Tool für die Zusammenarbeit, das genau diese Funktion erfüllt: Microsoft SharedView 1.0.
Mit Microsoft SharedView können sich bis zu 15 Personen zusammenfinden und den Desktop des Besprechungsleiters gemeinsam so nutzen, als würden alle Teilnehmer denselben Desktop betrachten. Vielleicht denken Sie jetzt spontan, dass der gleichzeitige Zugriff von 15 Personen auf denselben Desktop nur zum absoluten Chaos führen dürfte. Aber tatsächlich kann die Kontrolle über den Desktop von einem Teammitglied zum nächsten weitergereicht werden.
Wenn Sie gerade das Wort haben, sehen Sie die Mausbewegungen Ihrer Kollegen (jeder bekommt einen personalisierten Zeiger), die auf Elemente in einem Dokument oder einer Anwendung zeigen. Leider bietet SharedView keine integrierten Audiofunktionen, aber mit Windows Live™ (dem Audio-Client von Messenger) oder mit Ihrem bevorzugten VoIP-Client (Voice over IP) können Sie eine Konferenz halten, während der Desktop freigegeben ist.
Microsoft SharedView ermöglicht die gemeinsame Nutzung des Desktops des Besprechungsleiters (Zum Vergrößern auf das Bild klicken)
Die Installation von SharedView ist einfach, und der Client ist so intuitiv aufgebaut, dass sogar technisch weniger begabte Benutzer schnell die Arbeit damit aufnehmen können. Wenn Sie sich bei Ihrem Windows Live-Konto angemeldet haben, können Sie eine SharedView-Sitzung mit wenigen Mausklicks starten. Der Beitritt zu einer Sitzung ist ebenso einfach: Geben Sie den Namen der Sitzung (meist die Live-ID des Leiters) ein, mit der Sie eine Verbindung herstellen möchten, und geben Sie das zugehörige Kennwort ein. Einladungen werden per E-Mail oder durch Einfügen des erzeugten Einladungstexts in den IM-Client verschickt.
SharedView bietet noch weitere Optionen. So können Sie beispielsweise das Kopieren und Einfügen im Remoteverfahren aktivieren und deaktivieren (sodass Sitzungsbenutzer in der Lage sind, dem Computer des Hosts Text von ihrer lokalen Arbeitsstation hinzuzufügen), die Änderungsverfolgung in Word direkt aktivieren, damit sichtbar wird, wie die Benutzer das freigegebene Dokument bearbeiten, und auch eine explizite Sperrliste aufstellen, mit der bestimmte Windows Live-IDs von der Teilnehme ausgeschlossen werden. Die Anwendung bietet außerdem ein fantastisches Verteilungsfeature, mit der Sie den Sitzungsteilnehmern ergänzende Dateien zur Verfügung stellen können, und zwar bis zu 25 Dateien oder insgesamt 200 MB pro Sitzung.
Außerdem können Sie Nachrichten an Teilnehmer senden, die oberhalb der verbundenen Sitzung angezeigt werden. Sie können wahlweise den gesamten Desktop freigeben. Wenn Sie lieber einige Dinge unter Verschluss halten möchten, dann kann die Fensterfreigabe auf dem Hostcomputer schnell und einfach während der laufenden Besprechung aktiviert und deaktiviert werden. Alles in allem gilt: Wenn Sie ein schnelles und einfaches Tool für die Zusammenarbeit suchen, dürfte Microsoft SharedView das Richtige für Sie sein.
Zum Einstieg können Sie Microsoft SharedView aus dem Bereich mit den Codedownloads auf der TechNet Magazin-Website unter technetmagazine.com herunterladen.

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

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Einblicke in SharePoint Integrieren von Office-Anwendungen
Pav Cherny

Inhalt
Office-Anwendungsintegration
Erweitern der SharePoint-Benutzeroberfläche
Verwenden des Office OpenDocuments-Steuerelements
Kommunizieren mit SharePoint
Implementieren einer benutzerdefinierten OpenControl-Lösung
Schlussbemerkung
Microsoft Windows SharePoint Services (WSS) 3.0 und Microsoft Office SharePoint Server (MOSS) 2007 lassen sich nahtlos mit Desktopanwendungen im Microsoft Office 2007-System integrieren, was die Zusammenarbeit in Dokumenten, Tabellen, Kalendern, Kontaktinformationen und mehr vereinfacht. Tatsächlich ist die Integration so nahtlos, dass
das Office 2007-System als einheitliche Plattform für Office-Lösungen bezeichnet werden könnte.
Dies ist nützlich für Organisationen, in denen die Microsoft® Office-Technologie im Mittelpunkt steht, um die Produktivität von IT-Mitarbeitern zu fördern. Doch Organisationen mit einem vielfältigen Portfolio an Office-Anwendungen kommen nicht in den Genuss derselben standardmäßigen Interoperabilität. Das Office 2007-System bietet die notwendigen Integrationsfunktionen, doch die Benutzeroberflächen und Komponenten sind minimal dokumentiert und funktionieren nicht in allen Situationen. Dies erschwert es Drittanbieteranbietern, die SharePoint®-Technologie in ihre Anwendungen zu integrieren. Für ihre Kunden wird es sogar noch schwieriger, IT-Mitarbeitern eine einheitliche Erfahrung zu bieten.
In diesem Artikel erfahren Sie, wie Office-Anwendungen in SharePoint integriert werden können und mit SharePoint kommunizieren und wie Sie Nicht-Microsoft-Anwendungen in SharePoint auf der Grundlage derselben Prinzipien integrieren können. Doch zuerst folgt eine kurze Erläuterung der Serverkonfigurationseinstellungen, clientseitigen Komponenten und Kommunikationsprotokolle, die zum Erzielen einer nahtlosen Integration verwendet werden.
Nach Klärung dieser Einzelheiten geht es um die Integration von Anwendungen ohne integrierte SharePoint-Unterstützung. Dabei gehe ich über das übliche Maß hinaus, das sich in der Regel auf das Implementieren von IFilter-Komponenten zum Erweitern von Suchfunktionen und Hinzufügen benutzerdefinierter Symbole auf SharePoint-Servern konzentriert. Das Erweitern der Suche und die Rückgabe mit richtigen Symbolen führt nicht zur vollständigen Anwendungsintegration; vielmehr möchten die Benutzer diese Dokumente auch direkt von ihrer SharePoint-Benutzeroberfläche aus öffnen können.
Hier wird es kompliziert. Sie benötigen eine clientseitige Komponente, die nicht sogleich verfügbar ist, wenn Sie Office nicht auf Ihren Arbeitsstationen bereitgestellt haben. Doch selbst wenn Office bereitgestellt wurde, könnten Sie feststellen, dass diese Komponente nicht zuverlässig funktioniert, was von Ihrer SharePoint-Sitetopologie und Konfiguration abhängt.
Zum Lösen dieses Problems habe ich eine benutzerdefinierte Lösung erstellt, mit der beliebige Anwendungen wie Editor, Adobe Reader oder Autodesk AutoCAD integriert werden können, ohne dass Office bereitgestellt werden muss. Diese benutzerdefinierte Lösung zeigt auch, warum die Anwendungsintegration, die auf Office-Standardkomponenten basiert, bisweilen fehlschlägt. Sie finden diese Lösung sowie Anweisungen zur schrittweisen Bereitstellung und Konfiguration im Begleitmaterial zu diesem Artikel, das im Codedownloadbereich von .com zur Verfügung steht.

Office-Anwendungsintegration
Aus der Benutzerperspektive scheinen SharePoint-Menüs wie das Windows®-Startmenü zu funktionieren. Das Erstellen eines neuen Dokuments in einer Dokumentbibliothek ist einfach: Klicken Sie auf „Neu“, dann auf „Neues Dokument“, und Microsoft Office Word 2007 startet. Das Bearbeiten eines vorhandenen Dokuments ist ähnlich einfach. Bewegen Sie den Mauszeiger über das Dokument, öffnen Sie das ECB-Dropdownmenü (Edit Control Box, „Steuerelementfeld bearbeiten“), und klicken Sie dann auf „Bearbeiten“ in Word. Es wird selten bedacht, dass Word 2007 von einer Webseite aus über Javascript gestartet wurde, dass die Anwendung lokal ausgeführt wird, während sich das Dokument weit entfernt in einer SQL Server®-Datenbank befindet, und dass sich ein Webserver innerhalb des Datenzugriffspfads befindet, wie in Abbildung 1 dargestellt.
Abbildung 1 Arbeiten mit einem Word-Dokument in SharePoint (Klicken Sie auf das Bild, um es zu vergrößern)
Trotz dieser Komplexität ist die Benutzererfahrung auf einer Windows-Arbeitsstation, auf der das Office 2007-System installiert ist, nahtlos. Das Arbeiten mit Dokumenten in einer SharePoint-Bibliothek ist sehr ähnlich wie das Arbeiten mit lokalen Dateien oder Dateien auf einer Netzwerkfreigabe.
Doch auf einer Windows-Arbeitsstation ohne Office 2003 oder das Office 2007-System ist die Benutzeroberfläche anders. Wenn Sie in Word auf „Neues Dokument“ oder „Bearbeiten“ klicken, wird nur ein Dialogfeld mit der Information angezeigt, dass eine mit Windows SharePoint Services kompatible Anwendung nicht verfügbar ist.
Dies überrascht nicht weiter. Es gibt mehrere Elemente, die zusammenarbeiten müssen, um die einheitliche Erfahrung zu bieten, wie Office-Benutzer sie kennen. SharePoint muss die Inhaltstypen kennen, die in der Dokumentbibliothek verwaltet werden, um die gewünschten Befehle im Menü „Neu“ und „ECB“ zu rendern. Als Reaktion auf Mausklicks auf diese Befehle muss JavaScript-Code mit dem Ausführen der zugeordneten Anwendung beginnen und den Pfad zu dem Dokument weiterleiten. Dieser Teil ist nicht unabhängig von der Arbeitsstationskonfiguration, da der JavaScript-Code lokal ausgeführt wird. Darüber hinaus muss die zugeordnete Anwendung mit SharePoint kommunizieren, um Dateien zu lesen und möglicherweise zu schreiben. Dies sind die Elemente, die zusammengeführt werden müssen, wenn Sie Ihre Anwendungen in SharePoint integrieren möchten.
Andererseits ist die Kommunikation zwischen SharePoint und dem Datenbankserver für die Anwendung transparent, was auch für die Indizierungsprozesse auf dem Webserver zum Vereinfachen der Suche gilt. Aus diesem Grund werden diese Aspekte in diesem Artikel nicht weiter erörtert, doch Sie sollten sich das Microsoft Filter Pack ansehen, das im Microsoft Knowledge Base-Artikel „Registrieren von Microsoft Filter Pack bei Windows SharePoint Services 3.0“, verfügbar unter support.microsoft.com/kb/946338, dokumentiert wird. Jetzt geht es um das Hinzufügen von Befehlen, das Implementieren notwendiger clientseitiger Komponenten und das Vereinfachen der Anwendungskommunikation.

Erweitern der SharePoint-Benutzeroberfläche
Zum Erweitern der SharePoint-Benutzeroberfläche und -Funktionen steht eine Fülle von Optionen zur Verfügung. Sie können den Entwurf Ihrer Websites ändern, ASP.NET-Seiten anpassen, Webparts entwickeln oder den in WSS und MOSS integrierten JavaScript-Code ändern, um Ihre Anwendungen direkt zu starten.
Sie können die Ows.js-Datei in einem Texteditor öffnen (die Datei befindet sich im Ordner „COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033“ auf Ihren SharePoint-Front-End-Servern) und die Arbeitsweise der Funktionen „createNewDocumentWithProgIDCore“, „editDocumentWithProgIDNoUI“ und „DispDocItem“ ändern. Doch es gibt eine bessere Methode, bei der es nicht erforderlich ist, die WSS-Codebasis auf nicht unterstützte Weise zu ändern: das Verwenden von Inhaltstypen und Dokumenttypzuordnungen.
In meinem Artikel „Standardisieren der Datenverwaltung mit benutzerdefinierten Inhaltstypen“ (siehe TechNet Magazin, Februar 2008, technet.microsoft.com/magazine/cc194408.aspx) wurde erläutert, wie globale und standortspezifische Inhaltstypen zum Verwalten von Dokumenten und anderem Inhalt in SharePoint-Dokumentbibliotheken und Listen erstellt werden können. Sie können sich auch das Arbeitsblatt „Text Content Type.pdf“ im Begleitmaterial zu diesem Artikel ansehen, das zeigt, wie ein neuer Inhaltstyp für .text-Dateien erstellt und dieser Inhaltstyp einer Dokumentbibliothek zugeordnet werden kann. Sie können dann den Befehl „Text Content“ (Textinhalt) im Menü „Neu“ genau wie den Befehl „Dokument“ für Word-Dokumente auswählen (siehe Abbildung 2).
Abbildung 2 Ein benutzerdefinierter Inhaltstyp auf der SharePoint-Benutzeroberfläche (Klicken Sie auf das Bild, um es zu vergrößern)
Das ECB-Menü ist ähnlich erweiterbar. Vielleicht haben Sie erwartet, dass das ECB-Menü Inhaltstypen unterstützt, doch die aktuelle WSS-Version implementiert dieses Menü nicht auf diese Weise. Stattdessen müssen Sie Ihren Dokumenttyp in Docicon.xml registrieren. Sie finden diese Datei im Ordner %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml auf jedem SharePoint-Front-End-Server.
Durch Hinzufügen der folgenden Dokumenttypzuordnung zum Bereich <ByExtension> von Docicon.xml beispielsweise wird dafür gesorgt, dass SharePoint den Befehl „Mit Editor bearbeiten“ anzeigt (die Datei „Text Content Type.pdf“ enthält ausführlichere Anweisungen):
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Der Key-Parameter identifiziert die Dateinamenerweiterung, der Value-Parameter definiert das Dokumentsymbol, das auf der Benutzeroberfläche angezeigt wird, der EditText-Parameter definiert die Zeichenfolge, die von SharePoint an den Befahl „Edit in“ (Bearbeiten in) angehängt wird, und der OpenControl-Parameter gibt die ProgID einer clientseitigen COM-Komponente an. Dies ist die ProgID, die von den SharePoint-JavaScript-Funktionen an einen ActiveXObject-Aufruf übergeben wird (Einzelheiten dazu finden Sie in Ows.js), um das COM-Objekt zu instanziieren, bei dem es sich um die Anwendung selbst oder ein Hilfssteuerelement handeln kann, das die Anwendung auf der Grundlage des zugeordneten Dateityps startet.
Website zu SharePoint-Produkten und -Technologien

  • Website zu SharePoint-Produkte und -Technologien
  • Windows SharePoint Services-TechCenter
  • Windows SharePoint Services-Developer Center
  • Teamblog zu Microsoft SharePoint-Produkten und -Technologien
Sie sollten beachten, dass das als SharePoint.OpenDocuments bezeichnete OpenControl-Steuerelement auf ein ActiveX®-Steuerelement verweist, das in aktuellen Office-Versionen enthalten ist (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll). Wenn diese Datei auf Ihren Arbeitsstationen vorhanden ist und sich das angegebene Dokumentsymbol (Value-Parameter) im Ordner „%COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images“ auf Ihren SharePoint-Servern befindet, dürfte der größte Teil der notwendigen Integrationsarbeit bereits erledigt sein.
Das Windows SharePoint Services 3.0 SDK enthält einige Informationen zu den clientseitigen APIs (einschließlich des OpenDocuments-Steuerelements), die im Office 2007-System enthalten sind. Weitere Informationen finden Sie in dem Abschnitt „Client-Side API Reference“ unter msdn2.microsoft.com/ms440037.

Verwenden des Office OpenDocuments-Steuerelements
Das OpenDocuments-Steuerelement behandelt die wichtigsten Anforderungen an die Anwendungsintegration. Für seine Verwendung ist jedoch das Office 2003- oder das Office 2007-System erforderlich, und seine Funktionen sind begrenzt. Die Befehle im Menü „Neu“ funktionieren möglicherweise nicht immer, und bisweilen werden irreführende Benutzerbenachrichtigungen angezeigt.
Wie in Abbildung 3 dargestellt, informiert das OpenDocuments-Steuerelement den Benutzer, dass die erforderliche Anwendung nicht richtig installiert ist oder dass die Vorlagendatei nicht geöffnet werden kann, doch weder das eine noch das andere trifft zu. Bei der Funktion „Edit in“ gibt es ebenfalls Probleme. Die zweite, im Vordergrund in Abbildung 3 dargestellte Fehlermeldung wird häufig angezeigt. Sie ist mein absoluter Favorit, da sie sogar SharePoint-Experten in die Irre führt, doch dazu gleich mehr.
Abbildung 3 Irreführende Fehlermeldungen des OpenDocuments-Steuerelements (Klicken Sie auf das Bild, um es zu vergrößern)
Dennoch ist das OpenDocuments-Steuerelement nützlich in Umgebungen mit neuen Versionen von Office, die auf allen Arbeitsstationen installiert sind. Unter anderem können Sie Ihre Inhaltstypen aus dem Menü „Neu“ ausblenden (lassen Sie sich die Dokumentbibliothekseinstellungen anzeigen, klicken Sie auf „Reihenfolge der neuen Schaltflächen und Standardinhaltstyp ändern“, und deaktivieren Sie dann das Kontrollkästchen „Visible“ (Sichtbar) für alle betreffenden Inhaltstypen), sodass die Benutzer die erste Fehlermeldung nicht erhalten. Sie können auch Ihre Sitetopologie einfach halten, um WebDAV (Web-based Distributed Authoring and Versioning)-Kommunikationsprobleme zu vermeiden. Dadurch wird diese zweite Fehlermeldung beseitigt.

Kommunizieren mit SharePoint
Bisher wurde die SharePoint-Benutzeroberfläche erweitert und möglicherweise eine Anwendung mithilfe des OpenDocuments-Steuerelements gestartet, doch für meine Anwendung ist immer noch eine Möglichkeit zum Kommunizieren mit SharePoint erforderlich, um auf die Daten zuzugreifen. Wie immer unterstützt SharePoint dazu mehrere Methoden, z. B. Microsoft Office Frontpage®-Servererweiterungen, WSS-Remoteprozeduraufrufe (RPC), WebDAV und Webdienste. Tatsächlich können Office-Anwendungen wie Word 2007 einige oder alle dieser Kommunikationsmethoden verwenden, was davon abhängt, wie Sie auf ein Dokument zugreifen, beispielsweise über Webordner, zugeordnete Netzwerklaufwerke oder die SharePoint-Benutzeroberfläche.
Die SharePoint-Client-/Serverkommunikationsmethoden verlassen sich auf HTTP als das zugrunde liegende Protokoll. Frontpage- und WSS-RPCs beispielsweise verwenden HTTP POST- und HTTP GET-Anforderungen, die an ISAPI-Erweiterungen gerichtet sind, die sich auf SharePoint-Servern innerhalb des Ordners %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI und allen seinen Unterordnern befinden.
Eine der wichtigsten ISAPI-Erweiterungen ist Owssvr.dll, die unter anderem Funktionen zur Arbeit mit Listen und Dokumentbibliotheken implementiert. Abbildung 4 zeigt das SharePoint-Dialogfeld „Speichern“ in Word 2007 (links) und in einem Browser (rechts), das direkt über die URL-Anforderung http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.doc geöffnet wurde. Die Ähnlichkeiten zwischen den beiden Screenshots sind offensichtlich.
Abbildung 4 Das SharePoint-Dialogfeld „Speichern“ in Word 2007 und im Internet Explorer (Klicken Sie auf das Bild, um es zu vergrößern)
Andere wichtige ISAPI-Erweiterungen sind Author.dll zum Implementieren von Frontpage- und WSS-RPCs für clientseitige Bearbeitungsvorgänge wie das Hochladen, Umbenennen und Löschen von Dokumenten, Admin.dll zum Verwalten von Websites und zum Durchführen einiger anderer Verwaltungsaufgaben sowie Shtml.dll zum Unterstützen von HTML-Formularübertragungen.
Es ist im Allgemeinen unmöglich, Frontpage- und WSS-RPC-Unterstützung zu vorhandenen Anwendungen wie Editor oder Adobe Reader hinzuzufügen, ohne Zugriff auf den Quellcode zu haben. Doch Sie könnten die notwendige Kommunikationseinrichtung mithilfe des in Windows enthaltenen Webclient-Features bereitstellen.
SharePoint unterstützt auch WebDAV über Httpext.dll. Diese Datei befindet sich im Ordner %WINDIR%\System32\Inetsrv\, doch wir wollen uns weiter mit der Clientseite befassen. Auf Computern, auf denen Windows Server® 2008 oder Windows Vista® ausgeführt wird, ist das Webclient-Feature standardmäßig installiert. Sie können einen entsprechenden WebClient-Dienst im Applet „Dienste“ in „Verwaltung“ in der Systemsteuerung finden. Bei Windows XP und Windows Server 2003 muss der Webclient explizit installiert werden. Auf jeden Fall ist sicherzustellen, dass der WebClient-Dienst gestartet und der Starttyp auf „Automatisch“ gesetzt wurde.
Abbildung 5 stellt die Architektur des Webclients dar. Der WebClient-Dienst wird in einer Benutzermodus-DLL (Webclnt.dll) implementiert, und der Dienststeuerungs-Manager wird in einem Svchost.exe-Hostprozess geladen. Webclnt.dll stellt die Netzwerkanbieteroberfläche für Nicht-E/A-Vorgänge bereit (z. B. Authentifizieren des Benutzers für WebDAV-Zugriff, Bereitstellen von SharePoint-Sites als Netzlaufwerke, Aufzählungen von SharePoint-Sites, Listen und Dokumentbibliotheken als Netzwerkressourcen und Trennen von bereitgestellten Laufwerken).
Abbildung 5 Die Architektur für die WebDAV-Clientumleitung (Klicken Sie auf das Bild, um es zu vergrößern)
Zum Durchführen dieser Arbeit kommuniziert Webclnt.dll mit einem Dateisystemtreiber im Kernelmodus, der die eigentliche Umleitungsfunktion bereitstellt. Der WebDAV-Clientumleitungstreiber (Mrxdav.sys) basiert auf dem Redirected Drive Buffering Subsystem (RDBSS), das in den E/A-Manager und andere Kernelkomponenten integriert wird, um die Dienste eines Remotedateisystems zu bieten. Mrxdav.sys implementiert die WebDAV-Kommunikationsfunktion zum Unterstützen von Zugriff auf Dateisystemebene auf SharePoint-Sites und -Dokumentbibliotheken.
Die Zugriffsmöglichkeit auf SharePoint-Sites und -Dokumentbibliotheken über einen Netzwerkredirector beseitigt den Bedarf an Frontpage- und WSS-RPC-Unterstützung in Benutzeranwendungen. Netzwerklaufwerke können Dokumentbibliotheken zugeordnet werden (z. B. „net use x:“ http://wss/doclib/Shared%20Documents), und Sie können auf SharePoint-Ressourcen auch über UNC-Pfade zugreifen.
Die URL http://wss/doclib/Shared%20Documents ist \wss\doclib\Shared%20Documents zugeordnet. So haben Sie Auswahlmöglichkeiten zum Öffnen eines Dokuments in einer Anwendung. Sie können beispielsweise ein Dokument im Editor mit dem HTTP-Pfad http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt oder dem UNC-Pfad \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt öffnen.
Leider hat das Webclientfeature mehrere Einschränkungen. Auf benutzerdefinierte Eigenschaften oder Webanwendungen, die benutzerdefinierte TCP-Ports verwenden, kann nicht zugegriffen werden. Der in Windows Vista enthaltene Webclient schlägt ebenfalls fehl, wenn der Benutzer keinen Zugriff auf eine übergeordnete Website in der Hierarchie hat, wie in der Datei WebDAV Access. pdf dargestellt (siehe Begleitmaterial).
Der Pfad http://sharepoint/HR/Administration/Shared%20Documents/ enthält eine nicht vorhandene Stammwebsite (d. h. http://sharepoint), doch ohne Zugriff auf den Stamm kann der Webclient die Funktionen des Webservers nicht ermitteln. Der Webserver weist die OPTIONS-Anforderung des Webclients mit dem Statuscode 401 zurück, welcher besagt, dass der Zugriff nicht autorisiert ist. Folglich fordert der Webclient weiterhin Benutzeranmeldeinformationen an, wie in Abbildung 6 dargestellt, obwohl der Benutzer Administratorzugriff auf die Websitesammlung sharepoint/HR und alle darin enthaltenen Websites hat.
Abbildung 6 Erfolgloser WebDAV-Zugriff (Klicken Sie auf das Bild, um es zu vergrößern)
Beim Verwenden des Steuerelements OpenDocuments erhalten Sie die erste, in Abbildung 3 dargestellte Fehlermeldung, wenn der Webclient ein Dokument nicht öffnet. Die Anwendung ist verfügbar, und die Dokumenttypzuordnung ist korrekt. Es ist das Dokument, auf das über den WebDAV-Redirector nicht zugegriffen werden kann.

Implementieren einer benutzerdefinierten OpenControl-Lösung
Grundsätzlich haben Sie zwei Optionen zum Behandeln von Unzulänglichkeiten des Webclients. Sie können warten, bis Microsoft eine aktualisierte Webclientversion bereitstellt, oder Sie können eine benutzerdefinierte OpenControl-Lösung implementieren, die die aktuelle Situation behandeln kann. Das Implementieren eines benutzerdefinierten OpenControl-Steuerelements ist keine einfache Aufgabe, doch Office muss dann auf Ihren Arbeitsstationen nicht vorhanden sein. Sie können dann den Befehl „Neu“ zusätzlich zum Befehl „Bearbeiten in“ verwenden, und Sie können Situationen behandeln, in denen der Webclient fehlschlägt.
Wenn eins dieser Probleme für Sie interessant ist, sollten Sie sich den AppStart-Quellcode ansehen, der im Begleitmaterial enthalten ist. Er zeigt, wie die OpenControl COM-Schnittstellen in einer Microsoft .NET Framework-Assembly verfügbar gemacht werden können, die vom SharePoint JavaScript-Code aufgerufen werden kann. Der AppStart-Quellcode demonstriert auch eine Möglichkeit zum Prüfen der Dateieingabehilfe und zum Herunterladen einer Datei auf den lokalen Computer über HTTP, wenn der Direktzugriff über WebDAV nicht möglich ist. Schließlich reagiert der AppStart-Quellcode auf den Befehl „Neu“, indem die dem Inhaltstyp zugeordnete Vorlage auf den lokalen Computer heruntergeladen wird, sodass der Benutzer mit der Arbeit an dem Dokument beginnen kann. Die Arbeitsblätter „Text Content Type.pdf“ und „Adobe Reader Support.pdf“ erläutern, wie diese OpenControl-Lösung bereitgestellt wird.
Das in Abbildung 7 dargestellte Diagramm zeigt die AppStart-Architektur. Meine benutzerdefinierte OpenControl-Komponente (Biblioso.dll genannt) macht zwei identische COM-Schnittstellen verfügbar, die von SharePoint JavaScript aufgerufen werden, um neue Dokumente zu erstellen oder vorhandene Dokumente zum Bearbeiten zu öffnen (Biblioso.AppStart.2 und Biblioso.AppStart.3).
Abbildung 7 Die AppStart-Architektur (Klicken Sie auf das Bild, um es zu vergrößern)
Wenn ein Dokument zum Bearbeiten geöffnet wird, überprüft Biblioso.dll, ob die Datei vorhanden ist, und startet die zugeordnete Anwendung zusammen mit dem Pfad zum Dokument, wenn die Datei direkt über WebDAV zugänglich ist. Wenn die Datei nicht zugänglich ist, startet Biblioso.dll einen prozessexternen COM-Server, der wiederum OpenDocsUtility.dll lädt, um die Datei über HTTP herunterzuladen, und die Anwendung zusammen mit dem Pfad zu dem heruntergeladenen Dokument startet.
Der prozessexterne COM-Server ermöglicht der Lösung, den Internet Explorer®-Prozess zu verlassen, der Downloads in den Ordner für temporäre Internetdateien im geschützten Modus einschränkt. Benutzer müssen in der Lage sein, Dateien ohne die Einschränkungen des geschützten Modus herunterzuladen, und ein prozessexterner COM-Server, der als Anwendungs-Broker arbeitet, bietet diese Option.
Das Entwickeln von prozessexternen COM-Servern wird in .NET nicht unterstützt, sodass ich für diese ausführbare Datei zu C/C++ gewechselt bin. Ich habe nur das absolut erforderliche Dialogfeld „Speichern unter“ in C++ implementiert. Um die Lösung möglichst einfach und den Entwicklungsaufwand gering zu halten, wurde der eigentliche Downloadcode in eine .NET-Assembly (OpenDocsUtility.dll) gestellt, die dann über eine andere COM-Schnittstelle aufgerufen wird.
Zum Vereinfachen der Bereitstellung wurde der Lösung ein Setup-Projekt hinzugefügt. Unter anderem registriert die Setuproutine alle COM-Komponenten und schreibt anwendungsspezifische Einstellungen in HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart. Die wichtigsten Parameter sind AllowedApps und AllowedFileTypes. Die AppStart-Lösung funktioniert nur mit diesen Anwendungen und Dateitypen, die in diesen Parametern ausdrücklich angegeben werden müssen.
Die Setuproutine erstellt auch eine Erhöhungsrichtlinie für den prozessexternen COM-Server, sodass Biblioso.dll im Internet Explorer-Prozess AppBrokerEngine.exe starten kann, ohne Sicherheitswarnungen auszulösen. Wenn Sie mehr über den geschützten Modus für Internet Explorer und darüber erfahren möchten, wie damit in der Anwendungsentwicklung umgegangen wird, empfehle ich den Artikel „Understanding and Working in Protected Mode Internet Explorer“ von Marc Silbey und Peter Brundrett, der unter msdn2.microsoft.com/bb250462 verfügbar ist
Beim Untersuchen der AppStart-Komponenten sollte bedacht werden, dass diese Lösung entwickelt wurde, um einfach nur Möglichkeiten aufzuzeigen. Sie ist noch nicht in Produktionsumgebungen einsatzbereit. Es war nicht genug Zeit zum Optimieren des Codes und zum gründlichen Testen der Lösung oder zum Dokumentieren der Features mit Ausnahme von Quellcodekommentaren vorhanden.
Sie sollten diese Lösung auf eigenes Risiko verwenden. Wenn Sie den Quellcode untersuchen möchten, um Ihre eigene Lösung zu erstellen, beginnen Sie mit AppStart.cs im Biblioso-Codeprojekt. Diese Datei implementiert die OpenControl COM-Schnittstelle und die Einstiegspunkte für die JavaScript-Aufrufe aus Ows.js.
Schlussbemerkung
WSS 3.0 und MOSS 2007 bieten umfangreiche Funktionen zur Anwendungsintegration für eine nahtlose Benutzererfahrung beim Arbeiten mit Dokumenten und anderen Elementen in SharePoint-Dokumentbibliotheken und -Listen. Die Desktopanwendungen im Office 2007-System veranschaulichen dies sehr gut, und es ist möglich, dasselbe Maß an Integration und Benutzerfreundlichkeit auch mit Nicht-Office-Anwendungen zu erzielen.
Kern der Anwendungsintegrationsarchitektur sind neben dem Dokumentpfad zum Starten der Anwendung COM-Komponenten, die von den SharePoint JavaScript-Funktionen verwendet werden. Das Office 2007-System bietet mehrere dieser COM-Komponenten, die für spezifische Office-Anwendungsanforderungen optimiert wurden, obwohl es auch möglich ist, das Office-OpenDocuments-Steuerelement zum Integrieren von Nicht-Microsoft-Anwendungen wiederzuverwenden. Das OpenDocuments-Steuerelement erfüllt die grundlegendsten Anforderungen. Für erweitertere Anforderungen an die Anwendungsintegration kann ein benutzerdefiniertes Steuerelement implementiert werden.
Das vollständige Integrieren einer Anwendung in SharePoint ist nicht nur mit dem Installieren von IFilter-Komponenten und Dokumentsymbolen zum Erweitern der Such- und Anzeigefunktionen verbunden, sondern umfasst auch das Erstellen benutzerdefinierter Inhaltstypen und Dokumenttypzuordnungen auf den SharePoint-Servern zum Bereitstellen der entsprechenden Befehle „Neu“ und „Bearbeiten in“ auf der SharePoint-Benutzeroberfläche. Diese Befehle rufen JavaScript-Funktionen auf, mit denen Methoden aufgerufen werden, die durch eine OpenControl-Komponente verfügbar gemacht werden. Die OpenControl-Komponente muss ebenfalls auf der Arbeitsstation verfügbar sein.
Ein weiteres wichtiges Stück des Puzzles ist der Webclient, der standardmäßig in Windows Vista enthalten und installiert ist. Der Webclient implementiert einen WebDAV-Redirector und Remotedateisystemtreiber, damit ähnlich wie bei Dateifreigaben auf dem Netzwerk beliebige Anwendungen auf Ressourcen in SharePoint-Listen und -Dokumentbibliotheken zugreifen können. Obwohl der in Windows Vista enthaltene Webclient Mängel hat, ist er wichtiges Bestandteil der Anwendungsintegration.
WebDAV-Unterstützung schließt auch die Lücke zwischen auf Nicht-Windows-Arbeitsstationen ausgeführten Anwendungen und SharePoint. Die COM- und ActiveX-Steuerelementtechnologie ist im Allgemeinen auf diesen Betriebssystemen nicht verfügbar, sodass Sie keine OpenControl-Komponenten zum automatischen Starten von Anwendungen verwenden können, doch die meisten Betriebssysteme enthalten WebDAV-Redirectordienste, sodass Benutzer zumindest auf Dokumente in Dokumentbibliotheken direkt zugreifen können, ohne die Dateien auf die lokale Arbeitsstation herunterladen zu müssen.
WSS 3.0 und MOSS 2007 sind Grundsteine der Erfolgsgeschichte des Office 2007-Systems, und Benutzer von Drittanbieteranwendungen auf der Grundlage von Office können gleichermaßen von SharePoint profitieren. Die Integrationsfunktionen gehen weit über Office hinaus. Durch die umfassende Nutzung von SharePoint können Sie eine einheitliche Plattform von Office-Lösungen erstellen, die dieselbe Benutzererfahrung für Office- und Drittanbietersoftware bietet und somit die Produktivität von IT-Mitarbeitern fördert.

Pav Cherny ist IT-Experte und Autor und ist auf Microsoft-Technologien für die Zusammenarbeit und einheitliche Kommunikation spezialisiert. Seine Veröffentlichungen enthalten Whitepapers, Produkthandbücher und Bücher mit Fokus auf IT-Vorgänge und Systemverwaltung. Pav ist Präsident der Biblioso Corporation. Dieses Unternehmen ist auf verwaltete Dokumentations- und Lokalisierungsdienste spezialisiert.


Windows PowerShell Die Drop Box
Don Jones

Inhalt
Cmdlets in Aktion
Die Filterfunktion
Physisches Denken
Praktische Anwendungen
Zeit zum Spielen
In einer meiner letzten Windows PowerShell-Schulungen hatten einige Studenten Schwierigkeiten, sich das Konzept der Pipeline in der Shell vorzustellen. Zugegeben, die Pipeline ist vom Konzept her nicht ganz intuitiv, und deshalb kann es für visuell Lernende ziemlich schwierig sein, sich die einzelnen Vorgänge vorzustellen. Als das
Konzept der Filterfunktionen vorgestellt wurde, die direkt in der Pipeline arbeiten, wurde es richtig kompliziert, und es stand förmlich in ihren Gesichtern geschrieben, dass einige nicht mehr folgen konnten.
Um den Studenten zu helfen, brachte ich am nächsten Tag einen Pappkarton, einige Namensschildaufkleber und ein paar Tischtennisbälle mit. (Windows PowerShell® kann doch schließlich Spaß machen.) Für eine Demonstration verwendete ich die folgende Befehlszeile:
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

Cmdlets in Aktion
Mithilfe der Namensschildaufkleber (Sie wissen schon, die Aufkleber von der Sorte „Hallo, Mein Name ist …“, die Sie immer bei Klassentreffen und ähnlich öden Veranstaltungen tragen müssen) wurde jedem Studenten ein Cmdlet-Name zugewiesen. Die Tischtennisbälle sollten Windows®-Prozessobjekte repräsentieren (insbesondere Objekte vom Typ „System.Diagnostics.Process“). Die Studenten sollten mir mitteilen, welcher der Cmdlet-Namen sich so anhört, als würde er wahrscheinlich Prozessobjekte generieren.
Nach Ansicht aller Schilder entschieden sich die Teilnehmer für den offensichtlichen Namen „Get-Process“. Dies ist einer der Hauptgründe, warum mir die Cmdlet-Namen gefallen, die in Windows PowerShell verwendet werden: sie sind meist offensichtlich.
Daher nahm sich der Student, der Get-Process repräsentierte, alle Tischtennisbälle und warf sie in den Pappkarton. Der Karton repräsentierte die Pipeline der Shell, und der Student führte ziemlich genau das aus, was auch ein Cmdlet vornimmt. Ein Cmdlet generiert ein oder mehrere Objekte und steckt sie dann in die Pipeline.
Sie werden dann vom nächsten Cmdlet in der Pipeline übernommen. In diesem Beispiel nimmt sich der Student, der das Cmdlet „Where-Object“ repräsentiert, alle Tischtennisbälle und überprüft für jeden einzelnen, ob die VM-Eigenschaft eines bestimmten Balls größer als 1.000 ist. In der Shell steht „VM“ für den virtuellen Arbeitspeicher, und für diese Übung wurde die jeweilige Größe des virtuellen Arbeitsspeichers mit einem Marker auf jeden Tischtennisball geschrieben.
Jeder Ball (auch bekannt als Prozess) mit einem VM von mindestens 1.000 ging zurück in den Karton (die Pipeline). Alle Bälle mit einem kleineren Wert wurden für immer in einen Papierkorb gelegt. (Das ist in Wirklichkeit nicht ganz richtig – ich habe sie nämlich für eine zukünftige Lektion wieder eingesammelt.)
Als Nächstes ging der Student, der vorgab, das Sort-Objekt zu sein, durch den Karton mit den Tischtennisbällen und sortierte sie anhand ihrer VM-Eigenschaft. Zugegeben, dies war der Teil der Übung, der nicht so gut durchdacht war: Es war ziemlich schwierig, die Bälle am Wegrollen zu hindern! Vermutlich sind für das nächste Seminar Tischtenniswürfel oder Eierkartons besser geeignet.
Zum Schluss sammelte der Student, der die Rolle der Export-CSV übernommen hatte, die Bälle auf und übertrug die Informationen in eine CSV-Datei. Durch Notieren der Prozesseigenschaften auf ein Flipchart (das für die CSV-Datei stehen sollte), wurde der Vorgang physisch dargestellt.

Die Filterfunktion
Nach Erörtern der einfachen Pipeline waren die Filterfunktionen an der Reihe, ein etwas komplizierteres Thema. Dazu sollte die in Abbildung 1 gezeigte Filterfunktion und Befehlszeile verwendet werden.
Abbildung 1 Beispiel für eine Filterfunktion und Befehlszeile
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
Zunächst folgt ein kurzer Überblick über die Funktionsweise von Filterfunktionen. Eine Funktion enthält drei Skriptblöcke mit den Namen BEGIN, PROCESS und END.
Bei Verwendung der Funktion in der Pipeline wird als Erstes der Skriptblock BEGIN ausgeführt. Dieses Skript führt beliebige Setupaufgaben durch, z. B. das Öffnen einer Datenbankverbindung.
Dann wird der Skriptblock PROCESS ein Mal für jedes Objekt ausgeführt, das an die Funktion weitergeleitet wurde. Innerhalb des Skriptblocks PROCESS wird die $_-Variable automatisch mit dem aktuellen Pipelineobjekt belegt. Wenn also 10 Objekte an die Pipeline gesendet werden, wird der Skriptblock PROCESS 10 Mal ausgeführt.
Nach Ausführung aller an die Pipeline gesendeten Objekte wird der Skriptblock END ausgeführt und alle erforderlichen Bereinigungsaufgaben vorgenommen, z. B. das Schließen einer Datenbankverbindung.
Alles, was innerhalb dieser Skriptblöcke mithilfe von Write-Output geschrieben wird, geht in der Pipeline an das nächste Cmdlet weiter. Alles, was nicht mithilfe von Write-Output geschrieben wird, wird verworfen.
Da der Befehl mit einem Get-Process startete, sammelte der obige Student alle Tischtennisbälle ein (wir machten eine kurze Pause, und aus irgendeinem unerfindlichen Grund waren danach die Bälle im ganzen Raum verteilt) und legte sie in den Pipelinekarton. Nach Abschluss dieser Aufgabe war der Student, der die Filterfunktion „Do-Something“ repräsentierte, an der Reihe.
Er führte als Erstes seinen Skriptblock BEGIN aus. Da der Skriptblock leer war, war das nicht allzu anstrengend. Als Nächstes nahm er sich alle Pipelineobjekte (die Tischtennisbälle) zur Hand und sah sie sich einen nach dem anderen an. Das war ziemlich witzig, denn er versuchte, alle Bälle – mehr als ein Dutzend – auf dem Schoß zu balancieren.
Jedenfalls nahm er jeweils ein Prozessobjekt auf und führte den Skriptblock PROCESS aus. Dieser Skriptblock ermöglichte ihm das Erstellen eines vollständig neuen benutzerdefinierten Objekts. (Dafür wurden spezielle gelbe Tischtennisbälle verwendet, und glauben Sie bloß nicht, dass die in den lokalen Sportläden besonders leicht zu finden waren.) Auf diese neuen Tischtennisbälle schrieb er das aktuelle Datum und die Uhrzeit sowie den Namen des Prozessobjekts, das er sich gerade ansah.
Dieses neue benutzerdefinierte Objekt wurde dann in die Pipeline geschrieben, das heißt, der gelbe Tischtennisball wurde im Karton platziert und der ursprüngliche Tischtennisball des Prozessobjekts verworfen. Der Student wiederholte dies für jeden Prozessobjekt-Tischtennisball im Karton, also etwa 12 Mal. Am Ende hatte er jeden weißen Tischtennisball durch einen gelben benutzerdefinierten Objekt-Tischtennisball ersetzt. Zum Schluss führte er den Skriptblock END aus, wofür so gut wie keine Zeit benötigt wurde, da er leer war.
Als Letztes übernahm der Format-Table-Student. Er nahm alle Bälle im Karton (das waren zu diesem Zeitpunkt alle gelben „benutzerdefinierten“ Objekte) und begann mit dem Erstellen einer Tabelle, wobei er die beiden Eigenschaften verwendete, die auf jedem Ball notiert waren. Auf dem Flipchart entstand eine Tabelle mit zwei Spalten (Zeitstempel und ProcessName) und etwa einem Dutzend Zeilen.

Physisches Denken
Erst durch diese Übung wurden die Pipeline und die Filterfunktion wirklich jedem in der Klasse klar. Mithilfe der Tischtennisbälle wurde die Darstellung der Objekte wirklich gut veranschaulicht. Diese Darstellung kann ziemlich abstrakt werden, wenn Sie nur über die Shell reden.
Jeder konnte sehen, wie die Cmdlets die Objekte änderten, wie die Ergebnisse in die Pipeline platziert wurden und wie das nächste Cmdlet die Ergebnisse aufnahm und die Objekte weiter änderte. Der Ablauf der Ereignisse in einer Filterfunktion sowie die Arbeitsweise des Skriptblocks PROCESS, jeweils ein Eingabeobjekt gleichzeitig zu bearbeiten, wurden verdeutlicht.
Weiterhin wurde die Art und Weise aufgezeigt, wie ein neues benutzerdefiniertes Objekt erstellt und in der Pipeline platziert werden kann. Außerdem wurden die Vorteile benutzerdefinierter Objekte im Gegensatz zu reinem Text demonstriert. Die neuen benutzerdefinierten Objekte konnten von anderen Cmdlets genutzt werden, z. B. von Format-Table. Dadurch können die Daten anschließend auf flexiblere Weise verwendet und dargestellt werden.

Praktische Anwendungen
Die wichtigste Frage der Studenten war, wie sich die Pipeline und die Filterfunktionen für praktische Anwendungen nutzen lassen. Die Antwort fiel mir nicht schwer, da ich bereits mehrere Beispiele für eine frühere Konferenz vorbereitet hatte (Sie finden die Beispiele unter scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples).
Das Ziel bei einem der Beispiele war, von mehreren Computern mehrere Eigenschaften der Win32_UserAccount-Klasse in der Windows-Verwaltungsinstrumentation (Windows Management Instrumentation, WMI) aufzulisten. Wenn die Computernamen in „C:\Computers.txt“ aufgelistet sind, können Sie diesen einfachen Befehl verwenden:
Gwmi win32_useraccount –comp (gc c:\computers.txt)
Das Problem besteht darin, dass die Win32_UserAccount-Klasse keine Eigenschaft enthält, aus der ersichtlich ist, welche Instanz von welchem Computer stammt. Daher ist die sich ergebende Liste eine nutzlose Mischung an Konten von vielen Computern. Das Problem wurde durch Erstellen eines neuen benutzerdefinierten Objekts gelöst, das den ursprünglichen Computernamen sowie die ausgewählten Klasseneigenschaften enthält, die hier wichtig sind. Der Code für dieses benutzerdefinierte Objekt wird in Abbildung 2 gezeigt.
Abbildung 2 Verwenden eines benutzerdefinierten Objekts zum Sammeln von Computernamen und Auswahl von Eigenschaften
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
Die endgültige Befehlszeile übergibt alle Computernamen an die Filterfunktion, die dann die benutzerdefinierten Objekte erzeugt. Als Nächstes wurden alle Benutzer außer denen herausgefiltert, bei denen die PasswordRequired-Eigenschaft auf „False“ festgelegt wurde (es sollte nämlich ein Prüfbericht der problematischen Konten erstellt werden). Dann wurden ganz einfach die Computer- und die Name-Eigenschaften beibehalten. Der Abschlussbericht besteht somit aus einer Liste von Computer- und Kontennamen, die näher untersucht werden müssen, weil die Kennwörter niemals ablaufen. Die Filterfunktion ermöglicht einen solchen Bericht über mehrere Computer hinweg, da der ursprüngliche Computername der Ausgabe hinzugefügt wird, während die Eigenschaften gleichzeitig auf die wichtigsten reduziert werden.
Obwohl es vergleichbare Möglichkeiten zum Ausführen dieser Aufgabe gibt, ist dieser Ansatz wohl der einfachste. Außerdem werden dadurch auch wichtige Konzepte und Verfahren demonstriert.

Zeit zum Spielen
Selbst wenn Sie mit der Pipeline vertraut sind, können Sie etwas aus diesem Artikel lernen. Durch Übertragen Ihrer Denkweise auf physische Objekte lassen sich Vorgehensweisen oft verdeutlichen.
Wenn Sie also beim nächsten Mal Schwierigkeiten mit einem Windows PowerShell-Konzept haben, gehen Sie vom Computer weg, und stellen Sie die Aufgabe als Beispiel mithilfe alltäglicher Gegenstände dar. Halten Sie zu diesem Zweck immer ein paar Tischtennisbälle bereit (oder auch Würfel, wenn Sie sie irgendwo finden).
Cmdlet des Monats: Out-File
Wie oft schon haben Sie die Ausgabe eines Cmdlet mithilfe des Symbols „>“ in eine Datei umgeleitet? Dieses Verfahren ähnelt „Get-Process > Processes.txt“. Wissen Sie, dass sich dahinter eigentlich das Out-File-Cmdlet verbirgt? Mit dem folgenden Befehl wird genau das Gleiche ausgeführt: Get-Process | Out-File Processes.txt.
Natürlich erfordert dies mehr Tipparbeit, warum also sollten Sie das vollständige Out-File-Cmdlet eingeben? Ein Grund ist, dass sich Out-File erheblich besser lesen lässt. In 6 Monaten schaut sich vielleicht jemand Ihr Skript an und fragt sich, wofür das „>“ steht (es handelt sich dabei irgendwie um eine Art Altlast).
Im Gegensatz dazu wird durch Out-File ziemlich offensichtlich, dass eine Datei erstellt und in sie geschrieben werden soll. Außerdem erhalten Sie durch Out-File den -append-Parameter (stimmt ziemlich genau mit „>>“ überein) sowie die Parameter -force und -noClobber, mit denen das Überschreiben vorhandener Dateien gesteuert werden kann. Schließlich erhalten Sie durch Ausschreiben von Out-File auch Zugriff auf den Parameter -whatif. Dieser nützliche Parameter zeigt Ihnen die Auswirkungen von Out-File, ohne dass der Vorgang tatsächlich durchgeführt wird! Das ist eine großartige Möglichkeit, eine komplizierte Befehlszeile möglichst gefahrlos zu testen.
Video
Sehen Sie, wie Don Jones diese Cmdlets praktisch einsetzt.

Don Jones ist Mitautor von Windows PowerShell: TFM und bietet Schulungen zu Windows PowerShell an (www.ScriptingTraining.com).

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Hey, Scripting Guy! Der Adrenalinschub
Die Scripting Guys von Microsoft

Zweifellos ist das Schreiben für das TechNet Magazin unserer Meinung nach eine hochgradig angesehene und lohnenswerte Aufgabe. (Es wäre natürlich noch viel besser, wenn wir dafür Geld sehen würden, aber das ist eine Sache für sich.) Wie angesehen ist denn nun diese Aufgabe? Sagen wir es mal so: Überall auf der Welt schauen Kinder, die gerade ins Bett gesteckt werden, in diesem Moment zu ihren Müttern hoch und sagen: „Mami, wenn ich groß bin, will ich jeden Monat die Skripting-Rubrik für das TechNet Magazin schreiben.“
Anmerkung: Allerdings glauben eine ganze Menge Leute bereits, dass diese Rubrik sowieso von Kindern geschrieben wird. Aber darum geht es hier nicht.
Die Scripting Guys genießen es wirklich, wenn sie von anderen wegen ihrer Artikel im TechNet Magazin bewundert werden. Selbst mit Autogrammjägern und Paparazzi können sie inzwischen umgehen. Aber eigentlich geht es uns bei der Arbeit nicht um Ruhm und Ehre. Uns reizt der pure Adrenalinschub, den die Skriptprogrammierung für die Systemverwaltung mit sich bringt.
Zugegeben, Sie werden die Ausdrücke „purer Adrenalinschub“ und „Skriptprogrammierung für die Systemverwaltung“ nicht oft im selben Satz hören. (Es sei denn, der pure Adrenalinschub ergibt sich daraus, dass letztere bisher überhaupt nicht vorhanden war.)
Der Durchschnittsbenutzer hält die Skriptprogrammierung für die Systemverwaltung für äußerst nützlich, aber vermutlich nicht für besonders spannend. Wahrscheinlich findet er das Ganze etwas langweilig. Der Grund dafür: Keiner dieser Benutzer hat je versucht, Startkonfigurationsdatenskripts für Windows Vista® oder Windows Server® 2008 zu schreiben.
Ah, da schlägt Ihr Herz gleich etwas schneller, nicht wahr? Wie die meisten von Ihnen wahrscheinlich wissen, wurde in Windows Vista und Windows Server 2008 die alte boot.ini-Datei zugunsten eines neuen Startkonfigurations-Datenspeichers verworfen, der eine flexiblere Verwaltung des Startvorgangs (und mehr Funktionen) bietet.
Das ist schon toll. Aber wirklich fantastisch ist Folgendes: Dank eines neuen Windows® Verwaltungsinstrumentations-Anbieters (Windows Management Instrumentation, WMI) kann jetzt auf den Startkonfigurations-Datenspeicher (Boot Configuration Data, BCD) problemlos zugegriffen und dieser mithilfe von Skripts vollständig verwaltet werden.
Sie fragen sich, was das merkwürdige Gefühl ist, das Ihnen über den Rücken läuft? So fühlt sich ein purer Adrenalinschub an. Daran werden Sie sich gewöhnen müssen, wenn Sie erst einmal mit BCD-Skripts arbeiten.
Zunächst sollte an dieser Stelle darauf hingewiesen werden, dass wir nicht einmal ansatzweise alles behandeln können, was mit dem BCD-Anbieter möglich ist, zumindest nicht in diesem einen Artikel. (Wir schickten den Herausgebern des Magazins eine E-Mail, in der wir eine Doppelausgabe des Magazins anregten, die sich ausschließlich dem Schreiben von Startkonfigurations-Datenspeicherskripts widmet, aber wir haben bis heute noch keine Antwort erhalten.)
Wenn Sie detailliertere Informationen suchen, sollten Sie sich die Dokumentation zum BCD WMI-Anbieter unter go.microsoft.com/fwlink/?LinkId=116953 genauer ansehen. In der Zwischenzeit zeigen wir Ihnen einige Beispielcodes, die für Mehrfachstartcomputer entworfen wurden, also für Computer, auf denen mehr als ein Betriebssystem installiert ist.
Leider funktionieren diese Skripts nur unter Windows Vista und Windows Server 2008. Wie bereits erwähnt, sind dies die beiden einzigen Betriebssysteme, die BCD momentan unterstützen.
Werfen Sie zunächst einen Blick auf ein Skript, das angibt, welches Betriebssystem derzeit auf dem Computer verwendet wird. Zugegeben, den BCD-Anbieter auf diese Art zu verwenden ist nicht besonders aufregend. Schließlich können Sie bereits mit der WMI-Klasse „Win32_OperatingSystem“ herausfinden, welches Betriebssystem aktuell auf dem Computer verwendet wird. Dieses relativ einfache Skript (zumindest, was die Größe des BCD-Skripts betrifft) ist aber ein gutes Beispiel, um die grundlegenden Techniken beim Arbeiten mit BCD zu demonstrieren. (Techniken, die gelinde gesagt ein bisschen … ungewöhnlich sind.)
Außerdem dürfen wir in unserer Rubrik nicht zu viel Aufregung einbauen: TechNet Magazin hat uns bereits mitgeteilt, dass wir für sämtliche Schäden gerade stehen müssen, die von erregten und übereifrigen Fans von „Hey, Scripting Guy!“ verursacht werden. In Anbetracht des allgemeinen Chaos, das auf der ganzen Welt nach dem Artikel über reguläre Ausdrücke ausgebrochen ist, können wir uns etwas Ähnliches nun nicht mehr leisten.
Hinweis: Erinnern Sie sich noch an die Videos, auf denen die Beatles von ihren Fans umlagert wurden, und an die Bilder der Mädchen, die kreischten und ohnmächtig wurden, als sie John, Paul, George und Ringo zu Gesicht bekamen? Das ist ziemlich genau das, was uns nach der Veröffentlichung eines neuen Artikels immer passiert.
Na gut, zugegeben, das ist vielleicht etwas übertrieben. Aber zweifellos gibt es viele Leser, sowohl männlichen als auch weiblichen Geschlechts, die nach der Lektüre eines unserer Artikel tief ergriffen sind.
Wie auch immer, schauen Sie sich das Skript in Abbildung 1 an. Hier wird mithilfe des BCD-Anbieters ermittelt, welches Betriebssystem derzeit auf dem Computer verwendet wird. Beachten Sie vor der Ausführung dieses Skripts, dass es nur erfolgreich als Administrator ausgeführt werden kann.
Abbildung 1 Abrufen des aktuellen Betriebssystems
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
Das heißt nicht, dass Sie sich einfach mit einem Konto anmelden, das Administratorrechte besitzt. Es bedeutet vielmehr, dass Sie ein Eingabeaufforderungsfenster öffnen müssen, indem Sie im Startmenü mit der rechten Maustaste auf Eingabeaufforderung klicken und „Als Administrator ausführen“ auswählen. Dann können Sie dieses Skript von der Eingabeaufforderung aus ausführen.
Also, wie funktioniert dieses Skript? Wir haben schon befürchtet, dass Sie das fragen. Kein Problem: Wir werden versuchen, es Ihnen so gut wie möglich zu erklären (was zumindest die Aufregung auf ein Minimum reduzieren dürfte, zumindest für eine Weile).
Zunächst werden zwei Konstanten definiert: BcdLibraryString_Description und Current. BcdLibraryString_Description verweist auf das Objekt, das abgerufen werden soll. In diesem Fall enthält das Objekt die Beschreibung (den Namen) des aktuellen Betriebssystems.
Das ist übrigens eine der netten Eigenarten bei der Arbeit mit dem BCD-Anbieter. In der Regel rufen Sie den Wert einer Eigenschaft nicht einfach nur ab, Sie verwenden stattdessen einen dieser konstanten Werte (und die GetElement-Methode), um ein anderes Objekt abzurufen, und geben dann den Wert der Eigenschaft, die zu diesem Objekt gehört, wieder zurück. Sicher, das ist etwas merkwürdig, aber wie heißt es so schön: Der Weg ist das Ziel.
Anmerkung: Wobei man sich fragen könnte, wohin es hier eigentlich geht.
Was die Current-Konstante angeht, so ist sie einfach eine GUID, die das aktuell verwendete Betriebssystem repräsentiert. Der Wert
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
wird als „bekannte“ GUID angesehen (was zumindest beweist, dass die Leute bei Microsoft tatsächlich Sinn für Humor haben).
Trotz der Tatsache, dass dies eine bekannte GUID ist, gingen wir einen Schritt weiter und nahmen den Wert für den Fall auf, dass sich einige von Ihnen beim Lesen nicht daran erinnern können, welcher der beiden folgenden Werte korrekt ist:
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
Anmerkung: Falls Sie sich fragen, wie GUID ausgesprochen wird: entweder wie „gwid“ oder wie „guu-id“. Wir könnten Ihnen sogar noch mehr erzählen, so etwa die Tatsache, dass die obige GUID eine V1-GUID sein muss, weil die dritte Zifferngruppe mit einer 4 beginnt. Aber schließlich sollte die Aufregung ja auf ein Minimum reduziert werden. Ein solches Versprechen muss man einhalten.
Wie Sie vielleicht schon erraten haben, müssen Sie beim Arbeiten mit dem BCD-Anbieter relativ häufig Konstanten, hexadezimale Werte und GUIDs verwenden. In diesem Artikel können nicht sämtliche dieser Punkte behandelt werden, aber auf der bereits erwähnten BCD-Seite in MSDN® finden Sie weitere Informationen (go.microsoft.com/fwlink/?LinkId=116953). Das heißt, wenn Sie die ganze Aufregung aushalten können.
Nach der Definition der beiden Konstanten stellen Sie eine Verbindung zum WMI-Dienst des lokalen Computers her. Können Sie dieses Skript verwenden, um die Startkonfigurationsdaten eines Remotecomputers abzurufen? Aber selbstverständlich.
Ehrlich gesagt, wenn Sie das nicht könnten, wäre BCD kaum etwas wert. Sie können die Startkonfigurationsdaten eines Remotecomputers abrufen (auf dem entweder Windows Vista oder Windows Server 2008 ausgeführt wird), indem Sie einfach der Variablen „strComputer“ den Namen dieses Computers zuweisen:
strComputer = "atl-fs-001"
Weiterhin soll auf einige wichtige Elemente in der WMI-Verbindungszeichenfolge hingewiesen werden. Zunächst ist Ihnen vielleicht aufgefallen, dass sowohl die Berechtigungen „Backup“ als auch „Restore“ in die Verbindungszeichenfolge eingebaut wurden, nämlich in der Konstruktion {(Backup,Restore)}. Ist das wirklich wichtig? Wenn Ihr Skript funktionieren soll, dann ist das sehr wichtig: Wenn das Skript nicht explizit die beiden Berechtigungen enthält, tritt ein Fehler auf.
Beachten Sie weiterhin, dass keine Verbindung mit dem Namespace „root\cimv2“ hergestellt wird, also mit dem Namespace, der in Skripts zur Systemverwaltung am häufigsten verwendet wird. Stattdessen wird eine Verbindung mit dem Namespace „root\WMI“ hergestellt, der direkt an die BCDStore-Klasse gebunden wird. Das wird durch folgendes Codeelement erreicht:
"\root\wmi:BcdStore"
Nein, das war nicht der aufregende Teil. Der aufregende Teil kommt noch.
Abgesehen von ein oder zwei Ausnahmen müssen für die meisten BCD-Skripts zunächst die folgenden drei Schritte ausgeführt werden: Definieren der Konstanten, Herstellen einer Verbindung zum WMI-Dienst und schließlich Öffnen des BCD-Speichers. Schritte 1 und 2 sind bereits abgeschlossen. Mit der folgenden Codezeile wird Schritt 3 ausgeführt:
objStoreClass.OpenStore "", objStore
Wie bereits erwähnt, wird hier der BCD-Speicher geöffnet, also die Betriebssystementität, in der die gesamten Startkonfigurationsinformationen gespeichert werden. Sie können den Speicher öffnen, indem Sie einfach die OpenStore-Methode aufrufen und ihr zwei Parameter übergeben:
  • Eine leere Zeichenfolge („“). Dadurch wird dem Skript mitgeteilt, dass der Standardspeicher geöffnet werden soll.
  • objStore. Dies ist ein „out“-Parameter, der dem Skript bereitgestellt wird. Die Methode erhält den Namen einer Variablen, und als Dank gibt die Methode ein Objekt zurück (in diesem Fall ein Objekt, das den BCD-Speicher repräsentiert), das diesen Variablennamen als Objektverweis verwendet.
Nach dem Öffnen des Speichers können Sie mit der OpenObject-Methode noch ein weiteres Objekt abrufen (wird im Out-Parameter „objDefault“ gespeichert):
objStore.OpenObject Current, objDefault
Worum handelt es sich bei diesem neuen Objekt? Richtig: Es ist das Betriebssystem, das gerade verwendet wird. Dies wissen Sie, weil Sie die Konstante „Current“ an OpenObject übergeben haben, also die bekannte GUID, die das aktuelle Betriebssystem repräsentiert.
Sie wissen damit also, welches Betriebssystem auf dem Computer verwendet wird, oder? Nun, fast jedenfalls. Zum Abrufen dieser Informationen verwenden Sie noch GetElement, um ein Objekt abzurufen, das die Beschreibung des Betriebssystems repräsentiert:
objDefault.GetElement _
  BcdLibraryString_Description, objElement
Sie müssen aber versprechen, dass Sie sich nicht übermäßig aufregen und vor Freude ein allgemeines Chaos anrichten. Gut. In diesem Fall können wir Ihnen mitteilen, dass Sie nun den Inhalt der String-Eigenschaft zurückgeben und schließlich das Betriebssystem bestimmen können, das derzeit auf dem Computer verwendet wird:
Wscript.Echo "Current operating system: " _
  & objElement.String
Bleiben Sie ganz ruhig. Erinnern Sie sich an Ihr Versprechen: Kein allgemeines Chaos. Ja, einfach ist das nicht. Sie sollten sich aber wirklich bemühen. Atmen Sie tief ein, das funktioniert bei uns immer, wenn wir BCD-Skripts schreiben.
Wie bereits erwähnt, ist dieser Vorgang für das reine Bestimmen des Betriebssystems ziemlich umständlich. Dazu gibt es einfachere Möglichkeiten. Aber jetzt verstehen Sie, wie ein BCD-Skript funktioniert. Sie können daher nun vieles bewerkstelligen, das Skriptentwicklern bisher vorenthalten blieb. (Bleiben Sie ruhig, ganz ruhig.) Zum Beispiel wird ein Betriebssystem auf einem Mehrfachstartcomputer immer als „Standard“ markiert. Wenn ein Computer neu startet und keine anderen Anweisungen vorliegen, wird automatisch das Standardbetriebssystem geladen. Vor Windows Vista (und dem BCD-Anbieter) gab es für einen Skriptentwickler keine Möglichkeit, das Standardbetriebssystem auf einem Computer festzulegen. Jetzt aber ist das genauso einfach, wie das Ausführen eines Skripts, wie das in Abbildung 2.
Abbildung 2 Bestimmen des Standardbetriebssystems
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
Sie haben Recht: Das verlangt nach ein bisschen allgemeinem Chaos. Aber wirklich nur ein bisschen! Dieses Skript wird hier nicht in allen Einzelheiten erläutert. Wenn Sie nicht die letzten 10 bis 12 Absätze übersprungen haben, dann müssten Sie der Logik folgen können. Sie haben vielleicht bemerkt, dass ein Zwischenschritt durchgeführt werden muss, um das Standardbetriebssystem abzurufen: Zum Öffnen einer Instanz des Startmanagerobjekts muss die OpenObject-Methode verwendet werden. Nach dem Öffnen des Startmanagers können Sie mit der DefaultType-Konstante ein Objekt abrufen, das das Standardbetriebssystem repräsentiert.
Zugegeben, das ist jetzt ziemlich aufregend: Sie können das aktuelle Betriebssystem bestimmen, und Sie können das Standardbetriebssystem bestimmen. Wissen Sie, was jetzt wirklich unglaublich wäre? Wenn eine Liste aller auf einem Computer installierten Betriebssysteme abgerufen werden könnte. Das wäre jetzt wirklich erstaunlich. Schnallen Sie sich an, und werfen Sie einen Blick auf Abbildung 3.
Wie funktioniert das alles? Zunächst werden zwei neue Konstanten definiert: WindowsImages, mit der Instanzen von allen Betriebssystemen abgerufen werden können, die BCD unterstützen (also Windows Vista und Windows Server 2008), und LegacyImages, mit der Instanzen von allen „Vorgänger“-Betriebssystemen auf dem Computer abgerufen werden können. Nach Herstellen einer Verbindung zum BCD-Speicher wird die EnumerateObjects-Methode verwendet, um alle Instanzen der BCD-fähigen Betriebssysteme abzurufen, die auf dem Computer installiert sind:
objStore.EnumerateObjects _
  WindowsImages, colObjects
Abbildung 3 Ermitteln aller Betriebssysteme auf einem Computer
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wenn EnumerateObjects seine Arbeit erledigt hat, richten Sie eine For-Each-Schleife ein, die alle Betriebssysteme dieser Sammlung durchläuft. Innerhalb dieser Schleife werden diese beiden Codezeilen verwendet, um erst die Beschreibung des Betriebssystems abzurufen und sie dann anzuzeigen:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
Dann wiederholen Sie den Prozess für jedes Vorgänger-Betriebssystem, das auf dem Computer installiert wurde:
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Anmerkung: Wir verstehen den damit verbundenen Nervenkitzel, aber führen Sie bitte Ihre BCD-Skripts verantwortungbewusst aus. Vermutlich kann der menschliche Körper nur eine begrenzte Anzahl an Adrenalinschüben aushalten. Aktuell, zukünftig oder vormals schwangere Frauen und Frauen, die in Wirklichkeit keine Frauen, sondern Männer sind, sollten BCD-Skripts nicht ohne Rücksprache mit ihrem Arzt ausführen.
Na gut, Sie müssen sich nicht sofort mit Ihrem Arzt besprechen. Aber die Meinung eines Arztes über das Ausführen von BCD-Skripts wäre sicherlich interessant.
Jetzt kommt etwas wirklich Verrücktes: Sie sollen versuchen, ob Sie das Standardbetriebssystem ändern können. Nehmen Sie zum Beispiel an, es liegt ein Dual-Boot-Computer vor, auf dem sowohl Windows Vista als auch Windows Server 2008 ausgeführt wird. Windows Vista soll als Standardbetriebssystem festgelegt werden. Wie können Sie vorgehen? Sehen Sie sich Abbildung 4 an. Darin wird eine Möglichkeit aufgezeigt.
Abbildung 4 Ändern des Standardbetriebssystems
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
Mit diesem Skript öffnen Sie noch einmal den BCD-Speicher und rufen dann mit EnumerateObjects eine Sammlung aller BCD-fähigen Betriebssysteme ab, die auf dem Computer installiert sind. Danach richten Sie eine For-Each-Schleife ein, die mithilfe der folgenden (Ihnen mittlerweile vertrauten) Codezeile alle Elemente der Sammlung durchläuft, um eine Beschreibung aller Betriebssysteme zu erhalten:
objObject.GetElement _
  BcdLibraryString_Description, objElement
Sobald die Beschreibung für ein bestimmtes Betriebssystem vorliegt, ermitteln Sie mithilfe der InStr-Funktion, ob das Wort „Vista“ irgendwo in dieser Zeichenfolge enthalten ist:
If Instr(objElement.String, "Vista") Then
Sie haben Recht, das wirkt vielleicht etwas plump. Es wäre elegant, die GUID für Windows Vista zu verwenden, und dann direkt das Betriebssystem zu öffnen, ohne erst alle Betriebssysteme auf dem Computer aufzuzählen und durchlaufen zu müssen.
Leider müssten Sie dafür die GUID von Windows Vista kennen. So brauchen Sie überhaupt nichts zu wissen (für die Scripting Guys immer ein Bonus). Sie suchen lediglich so lange, bis Sie ein Betriebssystem mit dem Wort „Vista“ im Titel finden.
Anmerkung: Was ist, wenn mehrere Instanzen von Windows Vista auf dem Computer installiert sind? In dem Fall sollten Sie vielleicht nach einer Zeichenfolge wie „Vista Ultimate“ oder „Vista Enterprise“ suchen.
Wenn Sie Windows Vista gefunden haben, verwenden Sie diese beiden Codezeilen, um den Windows-Startmanager zu öffnen, und legen dann das Standardbetriebssystem auf Windows Vista fest:
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
Das ist genug für diesen Monat. Schließlich können sogar die Scripting Guys nicht rund um die Uhr mit Nonstop-Aufregung umgehen. Keine Sorge, im nächsten Monat wird mit einer weiteren aufregenden Ausgabe von „Hey, Scripting Guy!“ aufgewartet. Mit etwas Glück haben Sie sich bis dahin erholt.
Der Scripting Perplexer von Dr. Scripto
Die monatliche Herausforderung, die nicht nur Ihr Talent zum Rätsellösen testet, sondern auch Ihre Skriptingfähigkeiten.

Juli 2008: VBScript-Quadrate
Na ja, es sind wohl eher Rechtecke als Quadrate, aber das ist nebensächlich. Lösen Sie dieses Rätsel, indem Sie jedes Quadrat zur Rechten in ein leeres Quadrat zur Linken einsetzen und so die Namen von VBScript-Funktionen erzeugen. Jedes Quadrat darf nur ein Mal verwendet werden. Hier ist ein Beispiel:
Sie lösen dieses Beispiel, indem Sie das OU-Quadrat (Rechteck) in das leere Quadrat im ersten Wort sowie MS und OX in die leeren Quadrate im zweiten Wort verschieben. Dies ergibt die VBScript-Funktionen „UBound“ und „MsgBox“, wie hier gezeigt:
Jetzt versuchen Sie es:

Antwort:
Der Scripting Perplexer von Dr. Scripto
Antwort: VBScript-Quadrate, Juli 2008

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


Die Desktopdateien Windows-Netzwerkstart
Wes Miller

Inhalt
Funktionsweise von PXE
Einstieg in RIS
Die Anfänge von WDS
Weitere Entwicklungen
Zusammenfassung
Über die kommenden Monate werde ich mich mit den Windows-Bereitstellungsdiensten (Windows Deployment Services, WDS) befassen, die für Windows Server 2003 verfügbar und in Windows Server 2008 integriert sind. Die WDS können eine sehr wichtige Komponente in Ihrer Bereitstellungsinfrastruktur bilden, und hier erhalten Sie eine gute Grundlage zu diesem Thema. In diesem
ersten Artikel werden die Architektur der Pre-boot eXecution Environment (PXE, sprich: „Pixie“), die Entwicklung der Remoteinstallationsdienste (Remote Installation Services, RIS) sowie weitere bei Microsoft verwendete PXE-Technologien behandelt.
Als ich im Jahr 2001 zur Windows-Kernbetriebssystem-Gruppe wechselte, war RIS eine der dort bereits etablierten Technologien. Aufgrund ihrer Komplexität und ihrer Abhängigkeit von BIOS-Implementierungen und Hardware machte mich diese Technologie ziemlich nervös. Aber sie wurde neben Windows® PE eine der Technologien, mit denen ich in meiner Rolle als Programmmanager am liebsten gearbeitet habe.
Ich erinnere mich an meine erste Installation von Windows 3.0 – mit einem Satz von 3,5-Zoll-Disketten. Im Lauf der Zeit ist die Installation einfacher geworden, weil startbare CDs aufkamen (in einigen Versionen von Windows 98). Aber das Problem war, dass die Installation immer lokale Medien erforderte und auch eine lokale Festplatte.
Im Lauf der Jahre haben Kunden immer wieder die Möglichkeit gefordert, Windows über das Netzwerk zu starten – also einen vollständigen Systemstart über das Netzwerk vorzunehmen, ganz ohne Festplatte. Obwohl einige frühe Versionen von Windows diese Möglichkeit boten, gab es sie in Windows NT® nicht mehr. Während aktuelle Versionen von Windows Server® 2003 und Windows Server 2008 über einen iSCSI-Initiator gestartet werden können, unterscheidet sich dieser Prozess dadurch, dass er nicht vollständig lokal ist, sondern eine kontinuierliche Abhängigkeit von einem Remotelaufwerk als Startlaufwerk voraussetzt.
Vorkonfigurieren von Clients
  • Prozessevaluierung für die Vorkonfigurierung von RIS-Clients
  • Erhöhung der Netzwerksicherheit mit vorkonfigurierten Clients
  • Vorkonfigurieren von Clientcomputern
  • Remoteinstallation des Betriebssystems
Ab Windows 2000 entwickelte Microsoft die Technologie, die schließlich als RIS bezeichnet werden und eine netzwerkbasierte Installation ermöglichen sollte. Das Ziel von RIS war relativ simpel: ein Betriebssystemabbild per PXE auf den lokalen Datenträger des Zielcomputers zu stellen.

Funktionsweise von PXE
Abbildung 1 zeigt die PXE-Startsequenz. PXE ist ein relativ einfaches Protokoll, das von Intel und anderen Anbietern als Teil der Initiative „Wired for Management“ entwickelt wurde. PXE ist vom Dynamic Host Configuration-Protokoll (DHCP) abgeleitet, das wiederum von BootP abstammt, und ist in der Regel in der Netzwerkkarte (Network Interface Card, NIC) implementiert. Einfach ausgedrückt, laufen die folgenden Vorgänge ab:
Abbildung 1 PXE-Startsequenz (Zum Vergrößern auf das Bild klicken)
Schritt 1 Das System-BIOS fährt hoch und bestimmt die Startreihenfolge.
Schritt 2 Wenn PXE in der Startreihenfolge vor Festplatten oder Flashlaufwerken oder CD-ROM-Laufwerken steht, oder wenn diese Geräte nicht vorhanden sind, dann wird die universelle Netzwerktreiberschnittstelle (Universal Network Driver Interface, UNDI) von der NIC geladen. Die NIC ist mit einem äußerst kleinen Netzwerkgerätetreiber und einer TFTP-Implementierung (Trivial File Transfer Protocol) ausgestattet. (Bei einigen BIOS-Implementierungen muss der Endbenutzer für den PXE-Start die Taste F12 drücken. Das ist nicht standardmäßig, daher kann diese Funktion deaktiviert werden.)
Schritt 3 Das System beginnt mit einer einfachen UDP-Übertragung (User Datagram-Protokoll) und sucht einen DHCP-Server. Dies ist tatsächlich der erste Schritt der PXE-Startsequenz und wird als „Discover“ (Ermitteln) bezeichnet. Denken Sie daran, dass UDP als Protokoll verwendet wird. Falls Sie dieses Protokoll noch nicht besitzen, müssen Sie etwas Zeit mit Ihren Routern und Switches verbringen, um sicherzustellen, dass alle Geräte die PXE-Kommunikation akzeptieren können.
Schritt 4 Wenn ein DHCP-Server die Übertragung hört, antwortet er mit einer IP-Adresse. Dieser Schritt wird als „Offer“ (Anbieten) bezeichnet. Das Wichtigste hierbei ist, dass PXE statusfrei ist und dass der Client zu diesem Zeitpunkt recht wenige systemspezifische Statusinformationen zu bieten hat (die MAC-Adresse und, falls verfügbar, die BIOS-GUID der Systemverwaltung, auch als SMBIOS-GUID bezeichnet).
Schritt 5 Sobald der Client das Paket mit der IP-Adresse erhalten hat, gibt er an, dass eigentlich noch weitere Informationen benötigt werden, nämlich die Adresse des PXE-Servers. Eine andere Übertragung findet statt, die die Informationen vom DHCP-Server enthält, der ursprünglich geantwortet hat. Hier teilt der Client dem DHCP-Server mit: „Ich brauche mehr Informationen, insbesondere den Speicherort eines Netzwerkstartprogramms (Network Boot Program, NBP)”. Dieser Schritt wird als „Request“ (Anfordern) bezeichnet.
Schritt 6 Der PXE-Server antwortet mit der Adresse des PXE-Servers und dem Speicherort des NBP, einer äußerst kleinen ausführbaren Startdatei, die kleiner als 32 KB sein muss. Dieser Schritt wird als „Acknowledge“ (Bestätigen) bezeichnet. Die Namen der Schritte bilden das Akronym DORA (Discover, Offer, Request, Acknowledge, also Ermitteln, Anbieten, Anfordern, Bestätigen). Damit können Sie sich die Sequenz gut merken.
Falls Sie Microsoft DHCP und WDS installiert haben (oder die Technologien eines anderen Anbieters verwenden), findet der Anforderungsschritt nicht statt, und das ursprüngliche Offer-Paket vom DHCP-Server enthält bereits den Speicherort des PXE-Servers und des NBP-Programms (wodurch zwei Schritte entfallen und etwas Zeit eingespart wird).
Schritt 7 Der Client, auf dem sich der bereits erwähnte kleine TFTP-Protokollstack befindet, lädt das NBP vom Netzwerkspeicherort herunter, der vom PXE-Server angegeben wurde. TFTP ist ein älteres, äußerst kleines, statusfreies Protokoll. Dieses Protokoll wurde nicht wegen seiner Sicherheit oder seiner Leistung ausgewählt. Viele Routeradministratoren deaktivieren es demzufolge standardmäßig. Es muss aktiviert werden, damit PXE funktionsfähig ist.
Eine Reihe von PXE-Implementierungen (darunter auch RIS) bieten die Möglichkeit, den Benutzer zu diesem Zeitpunkt aufzufordern, die Taste F12 zu drücken, um den Vorgang fortzusetzen, aber in der Regel kann dies durch den Administrator des PXE-Servers deaktiviert werden. Nächsten Monat werde ich mich näher mit WDS befassen und dabei einige der Verbesserungen erläutern, die Microsoft zur Leistungssteigerung in den TFTPD (TFTP-Daemon) in WDS für Windows Server 2008 eingebracht hat.
Schritt 8 Das NBP wird initialisiert. Bei RIS wird hierbei ein Windows-Startladeprogramm gestartet, mit dem die Bereitstellung erfolgt. PXE (zumindest das eigentliche Protokoll auf der Startebene) ist keine Komponente dieses Prozesses mehr.
Denken Sie immer daran: PXE (RIS, WDS oder andere Infrastrukturen) funktioniert weder gut über langsame Verbindungen (unter Umständen werden beträchtliche Datenmengen übertragen), noch über Verbindungen mit hoher Latenz wie Satelliten (die Kommunikation läuft schlichtweg nicht gut ab und lässt sich ggf. gar nicht aufrechterhalten).
Beim PXE-Startvorgang bemerken Sie vielleicht, dass der Client beim Senden der Anforderung gar nicht erst nachfragt, ob der Empfänger das übergeordnete Gerät für ihn ist. Es gibt einfach nicht viele Statusinformationen, aus denen der PXE-Server die entsprechenden Schlüsse ziehen könnte. Meistens gilt eine Racebedingung: Der erste Server, der auf die Clientanforderung antwortet, gewinnt. Dieses Problem lässt sich durch gewisse Aktionen verringern:
  • Passen Sie die Antwortgeschwindigkeit des einen oder anderen PXE-Servers an. Die Netzwerklatenz und die Serverleistung wirken sich auf die Antwortzeit der Server aus. Bei Microsoft war es manchmal so, dass die von Microsoft IT verwendeten Server so gut waren, dass die Unternehmensserver selbst dann gewannen, wenn der PXE-Server direkt in Ihrem Büro stand. In diesem Fall mussten Sie nur auf dem lokalen PXE-Server angeben, dass für die vorkonfigurierten Clients kein Timeout gelten soll.
  • Konfigurieren Sie die Clients vor. Dies ist sehr wichtig, wenn Sie den PXE-Server so manipulieren, dass er vor anderen IT-Unternehmensservern antwortet. Durch die Vorkonfigurierung der Clients kann Active Directory® gegenüber WDS oder RIS behaupten: „Ich bin das übergeordnete Gerät“. Die Verwendung des SMBIOS-GUID ist als eindeutiger Bezeichner für Ihre Systeme in Active Directory weitaus beliebter, aber wenn keine SMBIOS-GUID in den Systemen implementiert ist (meist bei relativ alter Hardware), können (und müssen) Sie eine GUID auf Grundlage der MAC-Adresse verwenden. Weitere Informationen finden Sie in der Randleiste „Vorkonfigurieren von Clients“.
  • Lassen Sie es nicht zu, dass die PXE-Kommunikation über Switches oder Router abläuft. Richten Sie stattdessen je einen PXE-Server auf jeder Seite ein. Dies hat den Nachteil, dass sowohl die Implementierung als auch die Wartung teuer ist. (Jeder Server muss sein eigenes Abbild pflegen.)
RIS-Server (und jetzt WDS-Server) müssen wie Microsoft DHCP-Server anhand der Active Directory-Implementierung authentifiziert werden, der sie zugeordnet sind. Das Ziel besteht darin, die Probleme einzuschränken, die diese PXE-Server verursachen (z. B. PXE-Broadcaststorm), indem Sie Active Directory auf diese Server aufmerksam machen.
Denken Sie daran, dass Sie damit nur den Schutz vor Servern erzielen, über die Active Directory informiert wurde. Wenn Sie Ihre eigene Domäne einrichten (oder einen PXE-Server, der nicht von Microsoft stammt), trifft dies nicht zu.
Bei Microsoft hat ein übereifriger Mitarbeiter einmal einen PXE-Server ohne RIS, aber mit „Zero Touch“-Bereitstellung konfiguriert. Bei dieser Implementierung wurde die komplette Festplatte gelöscht und ein neues Abbild aufgespielt. Das wäre schon in Ordnung gewesen, wenn die Bereitstellung in einer isolierten Testumgebung (außerhalb des Netzwerks) stattgefunden hätte. Das war aber leider nicht der Fall, weshalb der Datenträger eines Microsoft-Mitarbeiters gelöscht wurde, bei dem PXE in der Startreihenfolge vor der Festplatte stand.
Das ist oft kein Problem, weil bei Microsoft IT zum Start von PXE immer die Taste F12 gedrückt werden musste, aber dieser PXE-Server bot keine Verzögerung, keine Aufforderung zum Drücken der Taste F12 oder sonst eine Benachrichtigung. Der Mitarbeiter verlor also im Prinzip seinen gesamten Computer und obendrein sämtliche Daten, die nicht durch sein servergespeichertes Benutzerprofil geschützt wurden.
Lassen Sie sich dies ein warnendes Beispiel dafür sein, die PXE-Server immer zu isolieren, wenn Sie sich für „Zero Touch“ entscheiden, oder zumindest das Drücken der Taste F12 zu fordern.

Einstieg in RIS
Ich hatte nach der Markteinführung von Windows 2000 zum ersten Mal näher mit RIS zu tun. RIS hatte es im Hinblick auf Windows 2000 nicht einfach. Tests, Leistungen und andere Einschränkungen führten dazu, dass RIS für Windows Server 2000 ausschließlich für Bereitstellungen von Windows 2000 Professional verwendet wurde. Allerdings konnten die Serverprodukte leider nicht über RIS bereitgestellt werden. Windows 2000 war nur für x86-Computer verfügbar, weshalb dies ein guter Prüfstand für RIS war, da es genau ein Produkt auf einer Architektur anbot. RIS enthielt (und erforderte) die vollständige Integration in Active Directory, ließ sich gut in den Microsoft DHCP-Server integrieren und umfasste einen eigenen TFTPD.
RIS verwendet das NBP, um den TFTP-Download fortzusetzen und einen ausreichenden Teil des Windows-Kernels herunterzuladen, um den Installationsvorgang beginnen zu können. (An einem bestimmten Zeitpunkt, nachdem Windows von TFTPD zu einer SMB-gestützten Verbindung [Server Message Block] zum Server gewechselt hat, wird der eigentliche Codepfad mit einer herkömmlichen, diskettengestützten Installation von Windows 2000 oder Windows XP gemeinsam genutzt.) Sobald Windows im einheitlichen Modus initialisiert ist, startet Windows-Setup den RIS-Operating System Chooser (OSC)-Assistenten.
Die OSC-Bildschirme sind teilweise konfigurierbare, HTML-2.0-ähnliche Seiten. Es gelten strenge Einschränkungen, und die Seiten können keine Abbilder oder Ähnliches enthalten. Auch ANSI-Zeichen sind nicht zulässig (was die Bereitstellung bestimmter Gebietsschemas von Windows erschwerte).
Das Endprodukt von RIS ist eine „txtsetup.sif“-Datei, die sich auf dem RIS-Server befindet. Wenn der OSChooser-Assistent abgeschlossen ist, wird ein Warmstart des Servers durchgeführt, aber der Speicherort des RIS-Servers und der „txtsetup.sif“-Datei werden beibehalten und nach dem Warmstart erneut geladen. Diese „txtsetup.sif“-Datei ist im Grunde identisch mit einer „unattend.txt“-Datei, wobei mehrere zusätzliche Felder dazu beitragen, dass RIS den Installationsvorgang abschließen kann.
RIS konnte auch ein Setup durchführen, das praktisch identisch mit der traditionellen unbeaufsichtigten Installation ist (RISetup). RIS enthielt zudem eine auf Klonen gestützte Infrastruktur, die ähnlich aufgebaut war wie Sysprep (RIPrep), und nutzte einigen Programmcode gemeinsam mit Sysprep. RIPrep konnte aber auch ein Abbild von sich selbst auf einen RIS-Server hochladen.
Es gab bei RIS jedoch einige grundlegende Einschränkungen, die schnell offensichtlich wurden. Das erste Problem war die fehlende Unterstützung für die Serverbereitstellung. Bestimmte Sicherheitsrisiken, z. B. Code Red und Sasser, zusammen mit den IT-Komplexitäten, die mehrere Hauptkunden bei der Wiederherstellung nach der Tragödie vom 11. September 2001 erlebten, führten dazu, dass eine Lösung für vorhandene Windows 2000-RIS-Server im Schnellverfahren entwickelt und damit eine Windows-Serverbereitstellung ermöglicht wurde. An einer solchen Lösung hatte Microsoft schon für Windows Server 2003 gearbeitet, aber sie wurde nicht offiziell veröffentlicht.
Weitere Informationen zu PXE-Technologien
  • PXE-Interaktion zwischen PXE-Client, DHCP und RIS-Server
  • PXE-initiierte Betriebssystem-Bereitstellungen
  • Die PXE-Architektur
  • Remoteinstallationsdienste
  • Remoteinstallation des Betriebssystems
  • Schrittweise Anleitung für die Remoteinstallation des Betriebssystems
  • WDS-PXE-Anbieter
  • Was sind die Remoteinstallationsdienste?
  • Automatische Bereitstellungsdienste für Windows Server 2003
Zweitens: RIS bot keine Möglichkeit, den OSChooser-Assistenten vollständig zu automatisieren. Dies wurde erst später mit dem Element <META ACTION="AUTOENTER"> in Windows Server 2003 realisiert. Weiterhin konnte der OSChooser nicht richtig mit ANSI-fremden Zeichen arbeiten – eine wichtige Schwäche, die von mehreren Kunden außerhalb der USA gemeldet wurde.
Demzufolge könnten Sie die RIS-Installation beispielsweise nicht mit einer französischen Tastatur vornehmen. Es war äußerst kompliziert, ANSI-fremde Zeichen auf BIOS-Ebene auf Computern in der ganzen Welt zum Funktionieren zu bringen.
Mit der Markteinführung von Windows Server 2003 wurde die offizielle Unterstützung für die Intel Itanium-Architektur und alle Servervarianten von Windows 2000 und Windows Server 2003 hinzugefügt. In Windows Server 2003 wurde mit der Unterstützung für die x64-Architektur noch ein weiterer Schritt vorgenommen.
RIS wurde außerdem zur Leistungssteigerung mit einem umfassend überarbeiteten TFTPD-Dienst ausgestattet. Windows Server 2003 unterstützte das Starten von bis zu 75 Clients gleichzeitig. Beachten Sie hierbei, dass die Obergrenze erreicht wird, wenn die SMB-Pipeline mit Netzwerkverkehr zu den Clients gefüllt ist.

Die Anfänge von WDS
Mit den Arbeiten an RIS für „Longhorn“ (unter diesem Codenamen wurde Windows Server 2008 bearbeitet) wurde es offensichtlich, dass wir einen Schritt zurückgehen mussten. Wie bereits erwähnt, hatten wir bereits alles auf das abbildgestützte Setup (WIM) von Windows PE gesetzt. Demzufolge war die entscheidende Grundlage von WDS die abbildgestützte Bereitstellung von einer mit PXE gestarteten Instanz von Windows PE.
Außerdem war uns bekannt, dass Windows Server 2003 die allgemeine Plattform für die Bereitstellung von Windows Vista® bilden würde und dass eine „außerplanmäßige“ Lösung für WDS-Vorgängerversionen erforderlich war. Als Ergebnis konnte WDS unter Windows Server 2003 SP1 ausgeführt werden und wurde in Windows Server 2003 SP2 integriert.
WDS kann als RIS-Server (Legacymodus), als Hybridserver (gemischter Modus) oder als reiner WDS-Server (einheitlicher Modus) arbeiten, sodass Sie mit WDS zu offiziellen Bereitstellungen im WDS-Stil wechseln können. Einige Kunden haben nachgefragt, ob es eine Möglichkeit gibt, RIS auf einem System mit Windows Server 2003 SP2 zu installieren. Diese Möglichkeit gibt es: Führen Sie WDS nach der Installation im Legacymodus aus. Abbildung 2 zeigt die unterstützten Betriebssysteme.
Abbildung 2 Unterstützte Plattformen für die Bereitstellung
Betriebssystem | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X (x86 und IA64)*** | X | X
Windows Server 2003 |  | X (x86 und IA64)*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* Unter support.microsoft.com/kb/308508 und support.microsoft.com/kb/313069 wird mittlerweile Support für Windows 2000 Server über RIS angeboten. ** Der WDS-Legacymodus und der gemischte Modus unterstützen dieselbe Matrix für Legacyinstallationen. *** Bei Windows Server 2003 SP1 wurde der Support für x64-gestützte Systeme eingeführt. IA64-Systeme unterstützten bisher nur RISetup-gestützte Installationen. **** Unterstützung für den einheitlichen Modus.
Durch WDS in Windows Server 2003 SP1 und SP2 dürfte die Migration zu WDS eingeläutet werden. Wie bereits oben erwähnt, bot WDS in Windows Server 2008 einige zusätzliche Features, darunter einen überarbeiteten TFTPD, die EFI-Startunterstützung (Extensible Firmware Interface) und natürlich die multicastgestützte Bereitstellung.

Weitere Entwicklungen
Ein anderes Team bei Microsoft entwickelte die automatischen Bereitstellungsdienste (Automated Deployment Services, ADS), hauptsächlich mit dem Ziel, die Bereitstellung von Servern zu beschleunigen. ADS umfasste eine formelle sektorbasierte Abbilderstellung, einen eigenen Startagent (kleiner als Windows PE, aber nicht so umfangreich), einen eigenen TFTPD und äußerst fortschrittliche Multicastfunktionen. Die Funktionen in ADS waren zu einem gewissen Grad in SCCM (System Center Configuration Manager) verfügbar, obwohl es keine hundertprozentige Featureparität gab.﻿
Bei Windows XP Embedded war der uneingeschränkte PXE-Startvorgang über den eigenen TFTPD in einer RAMDisk möglich, konnte aber nicht im Remoteverfahren bereitgestellt werden. Die Technologie sollte das gleichzeitige Starten zahlreicher Systeme vom gleichen Datenträgerabbild über PXE unterstützen.

Zusammenfassung
Dies ist also die Entwicklung in Kurzform. Weitere Informationen finden Sie in der Randleiste „Weitere Informationen zu PXE-Technologien“. Im nächsten Monat werden die WDS-Grundlagen behandelt, später dann die erweiterten WDS-Funktionen (Multicast und mehr) und schließlich die Verwendung von WDS ohne WDS, also über die vorhandenen WDS-/Setup-Erfahrungen hinaus unter Verwendung eigener Bereitstellungsverfahren.

Wes Miller ist Senior Technical Product Manager bei CoreTrace (www.CoreTrace.com) in Austin, Texas. Zuvor war er bei Winternals Software und als Programmmanager bei Microsoft tätig. Sie können Wes Miller unter technet@getwired.com erreichen.


Sicherheit auf dem Prüfstand Kennwörter und Kreditkarten, Teil 1
Jesper M. Johansson

Inhalt
Undurchführbare Sicherheitsempfehlungen
Undurchführbar und Unrichtig
Unverständliche Empfehlungen
Die Fallen einer auf Bildern basierenden Websiteauthentifizierung
Vor Kurzem kontaktierte mich die Universität von Minnesota wegen eines Interviews für ihr Magazin. Offenbar wollten sie einen Artikel über einen erfolgreichen ehemaligen Studenten schreiben, und weil sie niemanden finden konnten, entschieden sie sich für mich. Der Interviewer fragte, in welchem Bereich ich arbeite, und ich versuchte einige Minuten lang, das Thema
Sicherheitsinfrastruktursoftware zu beschreiben. Die Reaktion meines Gesprächspartners war: „Das hört sich aber kompliziert an! Bei der Sicherheit geht es doch eher um Kennwörter und Kreditkarten.“
Ich dachte einige Minuten über diese Aussage nach und erkannte, dass da etwas dran war. Bei der Sicherheit geht es wirklich um Kennwörter und Kreditkarten. So stellt es sich zumindest dem Endbenutzer dar. Diejenigen unter uns, die sich beruflich damit beschäftigen, denken, dass es beim Thema Sicherheit um kryptografische Algorithmen geht, ob Kerberos besser ist als TLS oder NTLMv2, um die Vorteile von WS*, ob Kennwort-Hashwerte frisiert werden sollten und um all die anderen esoterischen Themen, über die so gerne diskutiert wird. Unsere Sichtweise ist natürlich anders und geht tiefer als die des Endbenutzers, aber wir haben im Großen und Ganzen einen fundamentalen Punkt aus den Augen verloren: Für die Benutzer, denen wir eigentlich dienen sollten, geht es bei der Sicherheit um Kennwörter und Kreditkarten.
Zugegeben, die esoterischen Themen, über den wir uns so gerne streiten, und die vielen neuen Technologien, die wir uns mit wachsender Begeisterung ausdenken, sind dazu gedacht, die Daten des Endbenutzers zu schützen. Dennoch scheinen wir uns verirrt zu haben. Wir, die Sicherheitssubkultur der IT-Welt, existieren, weil wir einen bestimmten Bedarf unserer Auftraggeber erfüllen: die Notwendigkeit, Daten zu schützen. Das schließt selbstverständlich die Garantie mit ein, dass IT-Ressourcen sicher verwendet werden können. Das ist alles.
In früheren Artikeln wurde bereits darauf hingewiesen, dass niemand einen Computer nur deshalb kauft, damit Antivirussoftware darauf ausgeführt werden kann. Der Benutzer erwirbt einen Computer für Onlinebanking, um Computerspiele zu spielen, E-Mails zu schreiben, Hausaufgaben zu machen oder für andere wichtige Aufgaben. Auch wurde keine IT-Sicherheitsgruppe nur deshalb von Unternehmen ins Leben gerufen, damit NTLMv2 implementiert werden kann. Unternehmen stellen finanzielle Unterstützung für IT-Sicherheitsgruppen bereit, um die Organisationsressourcen zu schützen, damit IT-Ressourcen im gesamten Unternehmen sicher verwendet und die Geschäftsziele erreicht werden können.
Wir geben dabei lediglich Hilfestellung.
Deshalb ist die Frage erlaubt, ob wir heutzutage dabei wirklich noch gute Arbeit leisten. Legen wir, die Sicherheitssubkultur, dem Unternehmen eigentlich eher Steine in den Weg? Werden wir dabei womöglich von Gesetzgebern und Behörden noch unterstützt? Ich bin nicht davon überzeugt, dass dem Endbenutzer viele der neu geschaffenen Technologien wirklich weiterhelfen. Daher werden an dieser Stelle einige Bereiche genauer betrachtet, bei denen wir, die IT-Anbieter der Welt, tatsächlich mehr Schaden als Nutzen anrichten.
Manchmal scheint es, als ob die meisten der Sicherheitsempfehlungen und viele der Sicherheitstechnologien, mit denen wir unsere Benutzer belasten, undurchführbar, unrichtig und unverständlich sind oder (in vielen Fällen) aus einer Kombination dieser drei Faktoren bestehen. In dieser dreiteiligen Serie wird genauer beleuchtet, auf welche Weise der Benutzer durch Empfehlungen neuer Technologien, die einen oder mehrere der genannten Faktoren aufweisen, eher verwirrt wird.

Undurchführbare Sicherheitsempfehlungen
Eine der besten Möglichkeiten, Benutzer zu verwirren, besteht darin, ihnen undurchführbare Sicherheitsempfehlungen bereitzustellen. Manchmal sind diese Empfehlungen zudem noch unrichtig. Abbildung 1 zeigt eine beliebte erprobte, theoretisch vernünftige aber vollkommen nutzlose Empfehlung.
Abbildung 1 Undurchführbare Sicherheitsempfehlung (Zum Vergrößern auf das Bild klicken)
Sehen Sie die Stelle, an der gesagt wird, Sie sollen für jedes Ihrer Onlinekonten ein anderes Kennwort verwenden? Vor dreißig Jahren war diese Empfehlung vernünftig. Die Zahl der damaligen Internetbenutzer belief sich auf einige hundert, und alles waren intelligente Köpfe, die keine besonders guten Kennwörter auswählten. Leider hält sich diese Empfehlung hartnäckig, und es gibt keine erkennbaren Bemühungen, sie auf die heutige Computerverwendung abzustimmen.
Wie viele Onlinekonten haben Sie? Ich persönlich habe 115, plus minus ein paar, die ich nicht verwende. Die Empfehlung in Abbildung 1 schlägt nicht nur vor, dass 115 verschiedene Kennwörter verwendet werden sollen, sondern auch, dass diese 115 Kennwörter alle 30 bis 60 Tage geändert werden sollen. Mit anderen Worten, es sollen täglich 2 bis 4 Kennwörter geändert werden. (Rein rechnerisch bedeutet das auch, dass Sie pro Jahr zwischen 690 und 1380 Kennwörter haben.)
Auch wenn das technische Personal einiger Websites, die diese Empfehlung geben, pro Tag 4 gute Kennwörter finden und 115 aktuelle Kennwörter im Kurzzeitgedächtnis speichern kann, ist mit Sicherheit anzunehmen, dass 99,99 Prozent der normalen websurfenden Öffentlichkeit das nicht kann.
In Wirklichkeit ist die Empfehlung, jedes Mal ein anderes Kennwort zu verwenden, genau wie die Empfehlung, jedes der Kennwörter alle 30 bis 60 Tage zu ändern, theoretisch korrekt und vernünftig. Aber diese Empfehlungen sind ganz einfach undurchführbar. Bei der Anzahl an Kennwörtern, über die der Benutzer heutzutage verfügt, kann dieser Ratschlag nicht ohne konkrete Hilfe, z. B. mit Papier oder Software, befolgt werden. Werfen Sie einen Blick auf das nächste Beispiel.

Undurchführbar und Unrichtig
Der in Abbildung 2 gezeigte Auszug aus einer Empfehlung stammt von der Website einer der größten Banken der Welt und ist sowohl undurchführbar als auch unrichtig. Die Informationen, die unter der Überschrift „Unsere Empfehlung zum Kennwort“ genannt werden, folgen der „unterschiedliche Kennwörter überall“-Tradition. Außerdem wird empfohlen, die Kennwörter „niemals aufzuschreiben“.
Abbildung 2 Undurchführbare und unrichtige Sicherheitsempfehlung (Zum Vergrößern auf das Bild klicken)
Jetzt haben Sie also 115 verschiedene Kennwörter, müssen sich täglich 4 neue Kennwörter ausdenken, und Sie dürfen sie nicht aufschreiben. Eine Zeitlang werden Sie sich vielleicht dumm vorkommen, weil Sie sich nicht alle Kennwörter merken können. Dann aber werden Sie entdecken, dass es allen anderen genauso geht. Der Mensch kann sich einfach keine 115 Kennwörter merken. Wir können uns ungefähr sieben Informationsbrocken merken und verarbeiten. So wurden wir nun einmal programmiert. Wenn Sie den meisten der Kennwortempfehlungen aus dem Internet folgen, reicht das in Wirklichkeit nicht einmal für ein Kennwort (Siehe „The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information“ von George A. Miller, verfügbar unter musanim.com/miller1956).
Leider werden Benutzer durch Kennwortempfehlungen von Seiten der Sicherheitsbranche regelmäßig in die Irre geführt. Wenn die Sicherheitssubkultur den Benutzern mitteilt, überall verschiedene Kennwörter zu verwenden, dann sollte sie ihnen auch das „Wie“ verraten: die Kennwörter aufschreiben und irgendwo sicher verwahren. Schreiben Sie sie auf ein Blatt Papier, verwenden Sie ein geschütztes Dokument, oder verwenden Sie ein spezielles Tool wie PasswordSafe (sourceforge.net/projects/passwordsafe). Ganz ehrlich, wir alle schreiben unsere Kennwörter entweder auf, oder wir verwenden das gleiche Kennwort für alle Konten. In einer Umfrage wurde vor Kurzem sogar festgestellt, dass 88 Prozent der Benutzer das gleiche Kennwort für jedes System verwenden, an dem sie sich authentifizieren müssen (siehe msnbc.msn.com/id/24162478).
Einen großen Anteil an diesem Trend hat ganz sicher die Empfehlung, Kennwörter niemals aufzuschreiben. Benutzer müssen darüber informiert werden, wie sich Kennwörter (und andere vertrauliche Daten) effektiv organisieren lassen, anstatt ihnen die Verwaltung dieser Informationen völlig zu untersagen. Als Folge werden wahrscheinlich sehr viel weniger Anmeldeinformationen Gefährdungen ausgesetzt.

Unverständliche Empfehlungen
Die ersten beiden Abbildungen zeigen uralte Empfehlungen, die in den 60er, 70er und 80er Jahren gut funktioniert haben, in einer Zeit, in der ein normaler Benutzer noch nicht online ging und webbasierte Dienste nutzte. Bisher hat sich noch niemand über diese Art von Empfehlungen beschwert, weil sie in der Regel ganz einfach akzeptiert werden.
Solche Empfehlungen verwirren den Benutzer und erwecken möglicherweise Schuldgefühle, da Kennwörter gespeichert werden. Durch Empfehlungen dieser Art anstelle von praktischen Ratschlägen verursachen Sicherheitsfachleute vielfach Schaden. Schließlich liegt es nicht am Benutzer, selbst herauszufinden, wie die Sicherheit persönlicher Daten verwaltet werden kann. Das ist die Aufgabe der Sicherheitsfachleute. Es müssen akzeptable Möglichkeiten für Benutzer gefunden werden, ihre gesamten Onlinekonten zu verwalten. Da in den meisten Leitfäden immer nur die gleichen, veralteten Empfehlungen wiederholt werden, greifen die Benutzer weiterhin zu Haftnotizen und Tabellen, um ihre vielen Kennwörter nachzuverfolgen.
Kennwörter sind ein guter Authentifizierungsmechanismus. Das Hauptproblem bei Kennwörtern ist jedoch, dass der Benutzer sie nicht im Kopf behalten kann. Anstatt dieses biologische Problem zu lösen, denkt sich die IT-Welt weiterhin eine Menge neuer Methoden aus, wie Kennwörter ersetzt werden können, oder schlimmer noch, wie sie verstärkt werden können. Dies verwirrt den Benutzer sogar noch mehr.
Stellen Sie sich meine Überraschung vor, als ich vor Kurzem eine Finanzdienstleistungswebsite besuchte und mir ein Anmeldebildschirm mit nur einem Textfeld für den Benutzernamen angezeigt wurde (siehe Abbildung 3).
Abbildung 3 Wo gebe ich mein Kennwort ein?
Zuerst dachte ich, dass ich auf einer böswilligen Website gelandet bin. Dann habe ich die Website schnell überprüft (dieser Schritt war einfach, da ein Zertifikat angezeigt wurde) und erkannt, dass es sich um die echte Site handelte. Das Problem ist, dass Benutzer bei der Websiteanmeldung daran gewöhnt sind, die beiden Textfelder „Benutzername“ und „Kennwort“ zusammen auf dem Bildschirm zu sehen. Seit Jahren begegnet ihnen also der gleiche, gewohnte Workflow. Wenn eine Website plötzlich nur nach dem Benutzernamen fragt, gerät der Benutzer aus dem Gleichgewicht. In diesem Fall stellte sich heraus, dass der Anbieter eine Technologie implementiert hat, die Bilder verwendet, um die Website gegenüber dem Benutzer zu identifizieren, und so Phishing-Angriffe verhindern will. Nach Eingabe des Benutzernamens wird im weiteren Verlauf ein Bildschirm mit einem identifizierbaren Bild gezeigt, siehe Abbildung 4.
Abbildung 4 Einige Websites verwenden jetzt Bilder zur Authentifizierung gegenüber dem Benutzer (Zum Vergrößern auf das Bild klicken)
Die Theorie besagt, dass Sie wissen, welches Bild zu welcher Site gehört. Wird nicht das richtige Bild angezeigt, ist die Website eine Fälschung. Das ist an und für sich ein vernünftiges Konzept. Unter der Voraussetzung, dass der Benutzer weiß, welches Bild zu welcher Website gehört, ist diese Strategie relativ sinnvoll.
Selbstverständlich hat der scharfsinnige Leser die grüne Adressleiste in Abbildung 4 bemerkt. Die Adressleiste ist deshalb grün, weil diese Website SSL und Zertifikate für die erweiterte Überprüfung (Extended Validation, EV) verwendet. Das bedeutet aber auch, dass der gesamte Ansatz, ein Bild zur Identifizierung der Site zu verwenden, keinen zusätzlichen Schutz bietet. Für manche Endbenutzer stiftet das Bild stattdessen etwas mehr Verwirrung. Die Website hat sich gegenüber dem Benutzer bereits identifiziert. Sie zeigt ein Zertifikat an, das den Unternehmensnamen, die Adresse der Website und den Namen des vertrauenswürdigen Ausstellers enthält. Die grüne Adressleiste zeigt dem Benutzer, dass das Unternehmen sogar zusätzlich dreimal so viel Geld für ein EV-Zertifikat ausgegeben hat.
Die Bilder könnten selbstverständlich auch gefälscht werden. Wenn der Benutzer sein eigenes Bild einreichen kann, kann ein Angreifer u. U. über verschiedene Möglichkeiten herausfinden, welches Bild verwendet wird. Auch ist sehr gut möglich, dass der Benutzer immer das gleiche Bild für jede Website verwendet. Ein Angreifer muss lediglich eine Website mit für den Benutzer nützlichem Inhalt erstellen (das Ausdenken geeigneter Beispiele sei Ihnen überlassen), und den Benutzer nach einem Bild zur Websiteverifikation fragen. Verwendet der Benutzer das gleiche Bild für alle Websites, hat diese neue Website jetzt Zugriff auf das Bild, das der Benutzer zum Beispiel auf seiner Bankwebsite verwendet.
Bei einigen Websites können Sie Ihr eigenes Bild auswählen, bei anderen wird eine Bibliothek mit Archivfotos verwendet. Auf der Website in Abbildung 4 können Sie zum Beispiel aus 318 Archivfotos auswählen. Der oben beschriebene Trick funktioniert nicht für Websites, bei denen der Benutzer kein eigenes Foto verwenden kann. Darf der Benutzer jedoch kein eigenes Bild verwenden, dann wird er sich sehr wahrscheinlich kaum mehr an die Bilder der Websites erinnern, die er nur gelegentlich besucht. Ich habe ehrlich gesagt keine Ahnung, welches Bild ich auf der Website in Abbildung 4 verwende, aber ich bin mir sicher, dass es nicht das Bild auf dem Screenshot ist.
Das Problem mit dem auf einem Bild basierenden Ansatz ist, dass ein Angreifer so ziemlich jedes der 318 Bilder oder nur einen zufälligen Schnappschuss von Flickr zu zeigen braucht, und viele Benutzer annehmen, dass es sich um das richtige Bild handelt. Wenn sich die Mehrheit der Benutzer an Dinge wie bestimmte Bilder für bestimmte Websites erinnern könnte, gäbe es heute nicht all diese Phishing- und Sicherheitsprobleme.
Warum also soll ein Bild verwendet werden, um die Website gegenüber dem Benutzer zu authentifizieren, wenn sich die Website bereits mithilfe eines Zertifikats authentifiziert hat? Warum nicht einfach nur dieses Zertifikat verwenden und dem Benutzer beibringen, wie er es überprüfen kann? Zertifikate beweisen bereits die Identität der Website gegenüber dem Benutzer.
Der Prozess für das Abrufen eines Zertifikats ist erheblich sicherer als der Prozess, an das Authentifizierungsbild eines Benutzers für eine Site zu gelangen. Wenn es sich um ein EV-Zertifikat handelt und Sie Internet Explorer® 7 oder Firefox 3 verwenden, hebt der Browser die relevanten Zertifikatinformationen sogar in der Adressleiste hervor. Leider funktioniert das Hervorheben nur bei den sehr teuren EV-Zertifikaten.

Die Fallen einer auf Bildern basierenden Websiteauthentifizierung
Die Bildauthentifizierungstechnologie wirft einige Probleme auf. Als Erstes wird dadurch das Sammeln von Benutzernamen einer Website sehr vereinfacht. Die in Abbildung 4 gezeigte Website zeigt den in Abbildung 5 aufgeführten Dialog an, wenn der falsche Benutzername eingegeben wird. Bei Eingabe eines korrekten Benutzernamen für einen Benutzer, der sich für ein geheimes Bild entschieden hat, wird das geheime Bild dieses Benutzers preisgegeben. Dieses Wissen ist natürlich sehr wertvoll für einen Angreifer, der Informationen über einen Benutzer sammeln will.
Abbildung 5 Mit Bildern authentifizierte Websites ermöglichen das einfache Sammeln von Benutzernamen
Die hier gezeigte Art der Implementierung hat praktisch keinen Sicherheitswert. Der Angreifer kann den Anmeldeworkflow einfach auf einer gefälschten Website imitieren. Die gefälschte Website bittet um einen Benutzernamen und reicht ihn an die wirkliche Website weiter. Sie können auf dem Client sogar AJAX verwenden, um das Formular in Echtzeit zu aktualisieren und somit glaubwürdiger zu machen. Wenn die legitime Website außerdem siteübergreifende Anforderungsfälschungsangriffe auf das Anmeldeformular nicht einschränkt, kann der AJAX-Code der wirklichen Website die Anforderung sogar direkt senden, es sei denn, der Browser schränkt siteübergreifende XML-HTTP-Anforderungen ein.
Anhand des zurückgegebenen Ergebnisses kann der Angreifer die Daten analysieren, das Bild extrahieren und es dem Endbenutzer anzeigen. Ein Angreifer, der dem Benutzer eine gefälschte Anmeldewebsite anzeigen kann, kann also auch das geheime Bild des Benutzers anzeigen. Unter dem Strich bietet eine auf Bildern basierende Websiteauthentifizierung absolut keinen zusätzlichen Nutzen. Das Bild wird angezeigt, bevor sich der Benutzer bei der Website authentifiziert, und ist daher für einen Angreifer verfügbar, der den Benutzernamen des Benutzers bereits kennt oder sich verschaffen kann.
Angenommen, dem Benutzer wurde nie beigebracht, vor dem Senden eines Formulars nach einem Zertifikat zu suchen, und das ist eine berechtigte Annahme angesichts der Tatsache, dass die Verwendung einer auf Bildern basierenden Websiteauthentifizierung selbst auf der gleichen Annahme basiert, dann ist es einfach, den Benutzernamen dieses Benutzers herauszufinden. Da außerdem viele auf Bildern basierende Websiteauthentifizierungsmodelle auf einen gültigen Benutzernamen anders als auf einen ungültigen Benutzernamen reagieren, ist das Sammeln von Benutzernamen eine Bagatelle. Noch bevor ein Angriff gestartet wird, kann ein Angreifer dies Out-of-Band erledigen.
Als Ergebnis glaubt der Benutzer entweder, dass er besser geschützt ist, oder er ist noch verwirrter. Es wurden bedeutende Eigenkapitalbeträge ausgegeben, um eine auf Bildern basierende Websiteauthentifizierung zu implementieren, dabei wurde es Angreifern aber nicht erschwert, den Endbenutzer davon zu überzeugen, seine Anmeldeinformationen an gefälschte Websites zu senden.
Das wäre alles für diese Folge von „Sicherheit auf dem Prüfstand“. Im nächsten Monat folgt Teil 2 dieser Serie. Dann werden weitere Beispiele für unsinnige Sicherheitsmaßnahmen und schlechte Authentifizierungsimplementierungen vorgestellt.

Jesper M. Johansson ist Softwarearchitekt mit dem Schwerpunkt Sicherheitssoftware und schreibt redaktionelle Beiträge für das TechNet Magazin. Er hat seine Doktorarbeit zum Thema Management Information Systems geschrieben, verfügt über mehr als 20 Jahre Erfahrung auf dem Gebiet der Sicherheit und ist Microsoft MVP im Bereich Unternehmenssicherheit. Sein aktuelles Buch heißt Windows Server 2008 Security Resource Kit.


Berichte aus der Praxis Sicherstellen von Wahlgenauigkeit
Josh Benaloh

In diesem Jahr der amerikanischen Präsidentschaftswahl konzentriert sich das Interesse der Öffentlichkeit auf die Abstimmungstechnologien. Beim Streit um die Optionen geht es um die Entscheidung zwischen von Hand gezählten Wahlzetteln, was mühselig ist und missbraucht werden kann, Hebelmaschinen, die von kenntnisreichen Insidern manipuliert werden können, Lochkarten mit dem mittlerweile berühmten, nicht ganz ausgestanzten Loch, optisch gescannten Stimmzetteln, die von schlecht kalibrierten Scannern leicht falsch gelesen werden können, Sensorbildschirmsystemen, die durch nicht sorgfältig erstellte Software oder Malware beeinträchtigt werden können, sowie verschiedenen Mischformen, die oft mehr Probleme verursachen als lösen.
Tatsächlich ist dies nur eine kleine Auswahl der Sicherheitsrisiken dieser Systeme. Zudem sind die allgemein weltweit verwendeten Verfahren abhängig von ehrlichen und erfahrenen Wahlhelfern, die für die Integrität einer Wahl sorgen.
Doch es gibt eine bessere Möglichkeit, bei der die Integrität der Wahl nicht von Wahlhelfern oder von der Ausrüstung abhängt. Wahlen können so durchgeführt werden, dass ihre Genauigkeit durchgängig von Beamten, einzelnen Wählern und sogar interessierten Beobachtern überprüft werden kann.
Stellen Sie sich vor, dass die Wahlberechtigten Codes erhalten, mit denen sie ihre Stimme direkt neben ihrem Namen auf einer öffentlich lesbaren Website abgeben können. Die Wähler können die Website prüfen, um zu sehen, ob ihre eigene Stimme genau aufgezeichnet wurde, und alle können eine unabhängige Prüfung durchführen, um festzustellen, ob alle Stimmabgaben legitim sind und die Zählung den bekannt gegebenen Ergebnissen entspricht.
Das Ganze hat jedoch einen Nachteil: Ein Element, das bei dieser „offenen“ Wahl fehlt, ist der Datenschutz. Doch mithilfe der Kryptografie kann diese Lücke geschlossen werden, sodass vollständig überprüfbare, geheime Stimmabgaben ermöglicht werden. Statt die Stimme im Rohformat abzugeben, wird sie mit öffentlichen Schlüsseln verschlüsselt, wobei diese Verschlüsselungsschlüssel von Wahlbeamten gemeinsam verwendet werden, sodass zum Entschlüsseln die Zusammenarbeit der Betreffenden erforderlich ist. Nach Abschluss der Stimmabgabe produzieren die Wahlbeamten in einem kooperativen Prozess sowohl eine elektronische Zählung als auch einen kryptografischen Nachweis, dass die Zählung genau dem abgegebenen Satz verschlüsselter Stimmzettel entspricht.
Der einzelne Wähler kann prüfen, ob sein verschlüsselter Stimmzettel seiner Wahlabsicht entspricht, und jede beliebige Person kann den kryptografischen Nachweis überprüfen, um zu sehen, ob die verschlüsselten Stimmzettel richtig gezählt wurden. Auf diese Weise kann die elektronische Zählung durchgängig überprüft werden.
Ist es wirklich so einfach? Nein. Dies ist eine sinngemäße Darstellung, doch es gibt zahlreiche Details, die sorgfältig behandelt werden müssen, damit alles seinen richtigen Gang geht. So sind wir beispielsweise immer noch abhängig von traditionellen Methoden, um sicherzustellen, dass die zur Stimmabgabe verwendeten Geräte ausreichenden Datenschutz für den Wähler bieten. Und wie sollen die Wähler ihre Absicht in verschlüsselte Stimmzettel übersetzen? Die Wähler müssen darauf vertrauen können, dass die undurchschaubaren verschlüsselten Werte, die neben ihren Namen erscheinen, wirklich ihrer Absicht entsprechen, ohne Dritten die Korrespondenz zeigen zu müssen (damit es nicht zu Nötigung oder Stimmenkauf kommt). Und es muss alles getan werden, damit die Wähler nichts Komplexeres als in den traditionellen Wahlsystemen heute tun müssen.
Durchgängig überprüfbare Wahlprozesse werden in der kryptografischen Literatur seit mehr als einem Vierteljahrhundert analysiert, und mittlerweile gibt es verlässliche und praktische Möglichkeiten, um den kryptografischen Beweis für die Genauigkeit einer Zählung zu liefern. In der jüngsten Zeit hat sich die Forschungscommunity auf das Front-End konzentriert, das dem Wähler präsentiert wird, und auch hier gibt es viele Fortschritte.
Die kommerzielle Nachfrage nach Wahltechnologie ist groß, aber nicht enorm. Große Konglomerate mit breit gefächerten Interessen könnten auf diesem Markt mit Argwohn betrachtet werden, da bestimmte Wahlergebnisse zu ihrem Vorteil sein könnten. Folglich sollte dieser Markt am besten von kleineren Beteiligten mit Nischenprodukten gefüllt werden, deren gesamtes Geschäft davon abhängt, dass bei Wahlen alles richtig abläuft. Weitere Informationen und Links zu überprüfbaren End-to-End-Wahlmethoden finden Sie unter research.microsoft.com/crypto/voting.

Josh Benaloh ist leitender Kryptographieexperte bei Microsoft Research. Er wirkte acht Jahre im Vorstand der International Association for Cryptologic Research mit, und zu seinen zahlreichen Veröffentlichungen gehört u. a. seine Doktorarbeit von 1987, „Verifiable Secret-Ballot Elections“ (Überprüfbare geheime Wahlen).

© 2008 Microsoft Corporation und CMP Media, LLC. Alle Rechte vorbehalten. Die nicht genehmigte teilweise oder vollständige Vervielfältigung ist nicht zulässig.


Windows Confidential Geschichte, die viel Raum einnimmt
Raymond Chen

Erinnern Sie sich an Microsoft Bob? Es sollte eine benutzerfreundliche Benutzeroberfläche für Windows® 3.1 sein, doch stattdessen war es ein großer Flop (und genoss den zweifelhaften Ruf, von PC World als eines der schlechtesten Technologieprodukte aller Zeiten bezeichnet zu werden). In den Jahren seit Bobs Niedergang wurde das Produkt zu einem Dauerscherz, dessen Erwähnung bereits großes Gelächter auslöst.
Zufällig war der interne Codename von Microsoft® Bob „Utopia“ – sicherlich ein ehrgeiziger Name, aber zumindest hatte er einen gewissen Klang und Flair. Als wir erfuhren, dass die Mitarbeiter im Marketing beschlossen hatten, das Produkt „Bob“ zu nennen, schüttelten wir alle ungläubig den Kopf.
Doch das Vermächtnis von Bob ist größer, als Sie vielleicht denken. Wie sich herausstellt, ist Bob tot nützlicher als lebendig.
Wenn Sie vorhaben, Ihre Software auf einer CD zu verteilen, müssen Sie dafür sorgen, dass Ihr Produkt tatsächlich auf eine einzelne CD passt. Glücklicherweise waren nach Berücksichtigung des Speicherplatzes, der für Übersetzungen, Supporttools und die anderen Dinge, die auf der Windows XP-CD erforderlich waren, immer noch ungefähr 30 Megabyte Speicherplatz übrig. Diejenigen, die sich über solche Dinge den Kopf zerbrechen, dachten sich: „Da wir für diesen Speicherplatz auf der CD bereits bezahlt haben, können wir ihn auch nutzen“.
Der interne Codename von Microsoft Bob war „Utopia“ – sicherlich ein ehrgeiziger Name, aber zumindest hatte er einen gewissen Klang und Flair. (Klicken Sie auf das Bild, um es zu vergrößern)
Das Ergebnis war ein ziemlich schwacher Versuch, diejenigen zu behindern, die illegale Kopien von Windows herstellten. Es wurde beschlossen, die zusätzliche Kapazität auf der CD mit unechten Daten zu füllen und vom Windows-Setupprogramm überprüfen zu lassen, ob diese unechten Daten noch vorhanden waren. Dieser Logik zufolge waren diejenigen, die eine Kopie des CD-Abbilds herunterluden, gezwungen, etwa dreißig zusätzliche Megabyte an Daten herunterzuladen. Bedenken Sie, dass „Breitband“ in der damaligen Zeit noch kein Begriff war, und die breite Masse der Benutzer DFÜ-Verbindungen verwendete. Das Übertragen von zusätzlichen dreißig Megabyte an Daten über ein 56-KB-Modem war ein gewisses Hindernis, das zum Verlangsamen der Benutzer beitragen würde, was natürlich angesichts der heutigen Standards nicht mehr gilt.
Die Person, die gebeten wurde, diese Überprüfung zu implementieren, brauchte eine Quelle für die unechten Daten. Nun hätten wir einfach die CryptGenRandom-Funktion aufrufen können, um 30 Megabyte an kryptografisch zufälligen Bytes zu generieren, doch dabei wäre der Spaß zu kurz gekommen. Stattdessen durchsuchte der Betreffende die Archive und fand eine Kopie von Microsoft Bob. Er kombinierte alle Diskettenabbilder zu einer großen Datei. Der Inhalt der Microsoft Bob-Diskettenabbilder ist nicht besonders zufällig, und so beschloss er, die Daten zu verschlüsseln. Als es an der Zeit war, den Verschlüsselungsschlüssel einzugeben, schlug er einfach zufällig mit der Hand auf die Tastatur, und das Ergebnis war eine verschlüsselte Kopie von Microsoft Bob. Diese nahm als Datenballast den unbenutzten Speicherplatz auf der Windows XP-CD ein.
Letztendlich wurde Windows XP zum wirksamsten Bereitstellungstool für Microsoft Bob, das je entwickelt wurde. Wenn Sie nun in Ihrem Schrank nachsehen, Ihre Kopie von Windows XP heraussuchen und irgendwie die richtigen Geister herbeirufen, mit deren Hilfe Ihre Hände genau in der richtigen Weise über die Tastatur gleiten, erhalten Sie über Ihr Verschlüsselungsprogramm eine Kopie von Microsoft Bob.

Raymond Chen befasst sich auf seiner Website „The Old New Thing“ und in seinem gleichnamigen Buch mit der Geschichte von Windows und mit der Win32-Programmierung. Er fragt sich, ob er es noch miterleben wird, dass die Kernfusion genutzt wird.