Software Update Services, Teil 2 (Engl. Originaltitel: Software Update Services, Part 2) Inhaltsverzeichnis SUS in Ihrer Produktionsumgebung einführen Bandbreitenkapazität Mehrere SUS-Server verwenden Aktivitäten überwachen Intervention des Benutzers einschränken Per Email benachrichtigen lassen SUS testen, verteilen und überwachen Von Randy Franklin Smith Dieser Artikel stammt aus Dezemberausgabe 2002 des Security Administrator. Im Dokument Software Update Services (Teil 1) habe ich Ihnen eine Einführung in die grundlegenden Komponenten des Microsoft Software Update Services (SUS) gegeben und Ihnen gezeigt, wie Sie SUS installieren und wichtige Updates auf die Computer im Netzwerk verteilen. In diesem Artikel gehe ich auf die Bereiche Skalierbarkeit und Stabilität ein. Dabei werden folgende Themen behandelt: Updates vor deren Verteilung in der Produktionsumgebung testen eine große Anzahl von Automatic Update-Clients (AU-Clients) verwalten und Bandbreiten beschränken unterschiedliche AU-Listen auf mehrere Computer verteilen und Updateinstallationen nachverfolgen SUS in Ihrer Produktionsumgebung einführen Die meisten Menschen werden mir zustimmen, dass es sinnvoll ist Updates vor der Verteilung auf alle Computer der Produktionsumgebung erst zu testen. Normalerweise sollten Sie neue Hotfixes erst über eine Einführung auf einigen nicht entscheidenden Computer testen. Diese sollten Sie für ca. eine Woche im Auge behalten. Während dieser Zeit sollten Sie den Windows & .NET Magazine UPDATE Newsletter lesen (http://email.winnetmag.com/winnetmag/winnetmag_prefctr.asp - englischsprachig), um herauszufinden welche Probleme bei Anwendern aufgetreten sind, welche die entsprechenden Hotfixes schon implementiert haben. Danach können Sie die Updates in der gesamten Produktionsumgebung verteilen. Sie können den Verteilungsprozess mit SUS über zwei Methoden implementieren. Die einfachere Methode besteht aus einem Herunterladen per Hand, und Installieren der Updates auf Ihren Testsystemen. Wenn Sie das Update in Ihrer Produktionsumgebung verteilen möchten, geben Sie es einfach wie in Teil 1 beschrieben auf Ihrem SUS-Server frei. Diese Methode ist für kleine Netzwerke hervorragend geeignet. SUS stellt allerdings auch eine Methode mit größerer Kontrolle und Automatisierung für das koordinierte Testen und Verteilen von wichtigen Updates zur Verfügung. Um diese verfeinerte Methode zu verwenden, benötigen Sie zwei SUS-Server (in diesem Beispiel werden diese mit SUSTest und SUSProd bezeichnet). Konfigurieren Sie über das entsprechende Gruppenrichtlinienobjekt (GPO) Ihre Produktionscomputer zum Bezug von Updates von SUSProd. Hierzu wechseln Sie im GPO zu Computerkonfiguration / Administrative Vorlagen / Windows Komponenten / Windows Update, und geben unter Set intranet update service for detecting updates den Server SUSProd ein. Erstellen Sie als nächstes ein zweites GPO und weisen Sie es auf die Testcomputer zu. Geben Sie hier SUSTest unter der Option ein. Um ein Update zu testen, geben Sie es einfach auf SUSTest frei. Alle Testcomputer werden es installieren. Wenn sie mit dem Update zufrieden sind, geben Sie dies auch auf SUSProd frei. Um die Fehlerwahrscheinlichkeit zu verringern (z. B. könnten Sie versehendlich ein Update in SUSProd und nicht in SUSTest freigeben), können Sie zwei separate Benutzerkonten wie z. B. SUSTestAdmin und SUSProdAdmin erstellen. Platzieren Sie die beiden Konten in den Administratorgruppen der entsprechenden SUS-Server. Lassen Sie uns hoffen, dass Microsoft SUS so erweitern wird, dass es möglich ist die Test- und die Produktionsumgebung über einen SUS-Server zu verwalten, und das es irgendwann erforderlich sein wird ein Update in der Testumgebung freizugeben, bevor dies in der Produktionsumgebung möglich ist. Im Moment ist die beste Lösung jedoch zwei SUS-Server zu verwenden. Wenn Sie in Ihrer Produktionsumgebung verschiedene Updates für verschiedene Typen von Computern freigeben müssen (z. B. Server, Arbeitsstationen, Domänencontroller), bleibt Ihnen nur für jeden Computertyp einen SUS-Server zu installieren und die entsprechenden Computer für den entsprechenden SUS-Server zu konfigurieren. Bandbreitenkapazität Das Installieren von Updates über das Netzwerk kann eine menge Bandbreite kosten. Glücklicherweise hat Microsoft dieses Problem beim Design von SUS berücksichtigt. Wenn Sie SUS implementieren, müssen Sie zwei Aspekte der Bandbreitenkapazität berücksichtigen. Erstens: Wenn SUS-Server ihre Datenbank der verfügbaren Updates mit den Windows Update Servern synchronisieren, kann dies die Bandbreite Ihrer Internetverbindung beeinflussen. Zweitens: Wenn sich die AU-Clients die Updates herunterladen – entweder vom SUS-Server oder direkt vom Windows Update Server – ist die Bandbreite ihres internen Netzwerkes und Ihrer Internetverbindung betroffen. Sie können beide Situationen unter Kontrolle behalten. SUS lädt den Katalog (eine Liste der verfügbaren Updates und ihre Beschreibung) immer herunter. Sie können aber auswählen, ob die Update-Packete auf den SUS-Server heruntergeladen werden. Um diese Option zu konfigurieren, öffnen Sie den Microsoft Internet Explorer (IE), rufen Sie die SUS-Webseite z. B. unter http://sustest/susadmin auf und klicken Sie auf den Link Set Options. Über die Einstellung Select where you want to store updates können Sie die Option Maintain the updates on a Microsoft Windows Update server auswählen und einen Ordnernamen unter Save the updates to a local folder eingeben. Wenn Sie die Einstellung Maintain the updates on a Microsoft Windows Update server wählen, vermeiden Sie den ersten Download von ca. 500 MB. Auf lange Sicht werden Sie allerdings mehr Internet-Bandbreite sparen, wenn Sie die Einstellung Save the updates to a local folder verwenden. Nach der ersten Synchronisation müssen Sie zukünftige Updates nur noch einmal aus dem Internet herunterladen. Egal wie viele Computer Sie aktualisieren müssen, oder wie viele SUS-Server Sie haben. Die Einstellung Maintain the updates on a Microsoft Windows Update server ist nur empfehlenswert, wenn Sie ein Platzproblem haben, weil Sie viele Standorte mit jeweils nur ein paar Computern unterstützen müssen. Nach den Angaben von Microsoft benötigt der SUS ca. 500 MB Plattenplatz pro Standort. Was passiert aber, wenn Sie unterschiedliche Systeme oder mehrere SUS-Server für Test- und Produktionsumgebungen haben? Wenn jeder SUS-Server die gleichen Updates von den Microsoft Servern herunterlädt, kostet das eine Menge Internetbandbreite. Stattdessen verwenden Sie die Einstellung Select which server to synchronize content from um die SUSServer so zu konfigurieren, dass sie die Kataloge und Updates von einem anderen internen SUS-Server synchronisieren. Sie können SUSProd z. B. mit der Option Synchronize directly from the Microsoft Windows Update servers konfigurieren. Dann konfigurieren Sie SUSTest mit der Option Synchronize from a local Software Update Services server, und geben SUSProd als Server an. Sie sollten Ihren Test-SUS-Server zum Bezug von Updates von Ihrem Produktions-SUS-Server konfigurieren, und nicht anders herum. Damit ist Ihre Produktionsumgebung nicht von Ihrer Testumgebung abhängig, was eine potentielle Fehlerquelle wäre. Auch wenn auf dem Test-SUS-Server Probleme auftauchen, können Sie noch weiterhin Updates für die Produktionsumgebung freigeben und verteilen. Wenn Ihre AU-Clients neue Updates erkennen, fangen sie an diese herunterzuladen. Entweder vom lokalen SUS-Server, oder von einem Windows Update Server. AU-Clients verwenden den Dienst Background Intelligent Transfer Service (BITS) um Downloads so zu drosseln, dass sie die Netzwerkaktivitäten des Computers nicht stören. Weitere Informationen über BITS finden Sie unter http://msdn.microsoft.com/library/en-us/bits/bits/bits_start_page.asp (englischsprachig). Windows XP unterstützt BITS 1.0 und das Windows XP Service Pack 1 (SP1) und Windows 2000 SP3 stellen BITS 1.2 zur Verfügung. Wenn Sie auf Windows 2000 Computern nur den AU-Client installieren (wie in Teil 1 beschrieben), wird BITS ebenfalls installiert. Mehrere SUS-Server verwenden Mit mehreren SUS-Servern können Sie eine große Zahl von Clients unterstützen und Bandbreite zwischen Standorten sparen. Laut Microsoft kann ein SUS-Server, der auf einem Pentium III 700MHz Prozessor mit 512MB RAM ausgeführt wird, bis zu 15.000 Clients unterstützen. Bei mehr als 15.000 Clients benötigen Sie mehrere SUS-Server. Sie müssen unterschiedliche GPOs verwenden, um die Clients zu den richtigen SUS-Servern weiterzuleiten. Nehmen wird z. B. einmal an, Ihre Organisation hat ein Hauptquartier in New York und große Niederlassungen in San Francisco und London. Wenn Sie nicht möchten, dass jeder Client aus San Francisco und London seine Updates über das WAN von dem SUS-Server in New York erhält, können Sie einen SUS-Server an jedem der Standorte aufsetzen. Sie können jedem Standort dann eine unterschiedliche GPO zuweisen, welche die Clients anweist die Updates vom SUS-Server des eigenen Standortes zu beziehen. Konfigurieren Sie die SUS-Server in San Francisco und London so, dass sie sich mit dem SUS-Server in New York synchronisieren. Jedes Update wird dann nur einmal über das WAN übertragen, und danach lokal verteilt. Wenn Sie möchten, dass die lokalen Administratoren selber entscheiden welche Updates lokal verteilt werden, können diese die entsprechenden Updates lokal auf ihren SUSServern freigeben. Wenn Sie jedoch die zentrale Kontrolle über die freigegebenen Updates behalten möchten, können Sie die Einstellung Synchronize from a local Software Update Services server mit dem Servernamen des SUS-Servers aus New York konfigurieren. Danach aktivieren Sie — wie in Abbildung 1 gezeigt - die Option Synchronize list of approved items updated from this location (replace mode) auf den SUS-Servern in San Francisco und London. Wenn Sie dann ein Update auf dem Server in New York freigeben, wird dieses auf den anderen SUS-Servern automatisch als freigegeben markiert. Wenn die Internetverbindungen in San Francisco und London nicht so ausgelastet sind wie die WANVerbindung nach New York, können sich die lokalen SUS-Server die Liste der freigegebenen Updates aus New York, und die tatsächlichen Updates aus dem Internet herunterladen. Wenn Sie die Option Synchronize from a local Software Update Services server aktivieren, müssen Sie allerdings auch die Option Save the updates to a local folder verwenden. Diese Einschränkung ist jedoch kein Problem, denn nachdem Sie die erste Synchronisation angestoßen haben, werden Updates jeweils nur einzeln bei ihrer Veröffentlichung heruntergeladen. Abbildung 1 – Im Fenster „Set Options“ den Server wählen von dem syncronisiert werden soll. Aktivitäten überwachen Nachdem Sie die SUS-Infrastruktur eingerichtet haben, müssen Sie deren Aktivität überwachen. So können Sie sichergehen, dass neue Updates von den Microsoft Servern heruntergeladen werden, und können nachverfolgen auf welchen Computer neue Updates erfolgreich installiert wurden. Sie können über die Option View synchronization log unter Other Options die Synchronisationsaktivitäten überwachen. Wie Sie in Abbildung 2 sehen, wird im Synchronisationsprotokoll jedes Synchronisationsereignis angezeigt. Egal welche Updates der SUS, automatisch oder manuell, heruntergeladen hat. Das Synchronisationsprotokoll warnt Sie auch bei Problemen, die beim Herunterladen von Updates von einem Windows Update Server oder einem internen Server entstehen. Als nächstes können Sie über die Option View approval log prüfen, welche Updates Sie bereits freigegeben haben. Wie Sie in Abbildung sehen, wird jede Änderung der Freigabeliste im Protokoll festgehalten. Sie können sehen, wer und wann ein Update freigegeben hat. Im Windows 2000 Systemprotokoll erhalten Sie weitere Informationen über die Aktivitäten des SUS und zu dessen Fehlerbehebung. Abbildung 2 – Das Synchronisationsprotokoll. Abbildung 3 – Das Freigabeprotokoll. Abbildung 4 zeigt ein Beispiel für ein SUS-Ereignisprotokoll. Eine komplette Liste von Ereignissen erhalten Sie in Anhang B: "Software Update Services Event Log Messages" des Whitepapers "Software Update Services Deployment" unter (http://www.microsoft.com/windows2000/windowsupdate/sus/susdeployment.asp englischsprachig). SUS-Ereignisse enthalten detaillierte Ereignisbeschreibungen, unter anderem auch Ratschläge zu deren Behebung. Alle Ereignisse, die der SUS möglicherweise protokollieren könnte, finden Sie im Anhang B des oben genannten Whitepapers. Abbildung 4 – Das SUS-Ereignissprotokoll. Um die Installation von Updates auf AU-Client zu verfolgen, konfigurieren Sie die Clients so, dass sie ihre Aktivitäten über das Microsoft IIS-Protokoll auf einem von Ihnen definierten IIS-Server mitteilen (IIS-Protokolle befinden sich normalerweise im Ordner \winnt\system32\logfiles\w3svc1.). Um die AU-Clients entsprechend zu konfigurieren, tragen Sie in der GPO-Einstellung Set the intranet statistics server den entsprechenden Server wie in Teil 1 beschrieben unter Computerkonfiguration / Administrative Vorlagen, Windows Komponenten / Windows Update ein. Normalerweise sollten Sie den SUS-Server auch für den Empfang der Protokollinformationen verwenden. Wenn Sie einen anderen IIS-Server angeben, müssen Sie die Datei wutrack.bin aus dem Stammordern der SUS-Webseite auf den anderen IIS-Server kopieren. Nachdem Sie die AU-Clients konfiguriert haben, schicken diese Informationen über ihre Updateaktivitäten über Anfragen auf die Datei wutrack.bin an den entsprechenden Webserver. Unglücklicherweise ist das Datenformat sehr schlecht zu lesen, da es für die Analyse über ein Programm und nicht durch einen Menschen erstellt wurde. Dies ist ein ernsthaftes Problem, denn die Protokolle sind zur Verwaltung der Verteilung von Updates entscheidend. Sie können auch HFNetChk verwenden. Dieses Tool produziert natürlich eine Menge zusätzlichen Netzwerkverkehr und benötigt Zeit für seinen Scan. Das Ausgabebeispiel zeigt die Initialisierung (&A=n), Selbstaktualisierung (&A=s) und Erkennung (&A=d), die der Client 10.0.0.41 dem SUS-Server 10.0.0.68 mitgeteilt hat. Die Informationen im Protokoll wutrack.bin sind ziemlich kryptisch. Sie werden im Anhang C: „Client Status Logging." des Whitepapers "Software Update Services Deployment" unter http://www.microsoft.com/windows2000/windowsupdate/sus/susdeployment.asp englischsprachig) genauer erklärt. Im Protokoll gibt es, zusätzlich zu den Nachrichten von wutrack.bin, noch weiter Einträge. In Anhang C wird ebenfalls gezeigt wie Sie den IIS so konfigurieren, dass er nur die wutrack.bin-Nachrichten protokolliert. Dies geschieht über die Deaktivierung der Protokollierung auf Webseiten-Ebene, und der Aktivierung der Protokollierung für die wutrack.bin-Datei. 2002-08-14 22:03:36 10.0.0.41 - 10.0.0.68 80 GET /wutrack.bin U=fb59103f77bf3a46811a0bf04159d88f&C=au&A=s& I=&D=&P=5.0.893.2.110.3.0&L=en-US& S=s&E=00000000&M=ver%3D5.4.3630.11& X=020814131437426 200 Industry+Update+Control 2002-08-14 22:09:41 10.0.0.41 - 10.0.0.68 80 GET /wutrack.bin U=fb59103f77bf3a46811a0bf04159d88f&C=iu&A=n& I=&D=&P=5.0.893.2.110.3.0&L=en-US& S=s&E=00000000&M=&X=020814132042801 200 Industry+Update+Control 2002-08-14 22:09:53 10.0.0.41 - 10.0.0.68 80 POST /autoupdate/getmanifest.asp - 200 Mozilla/4.0+ (compatible;+Win32;+WinHttp.WinHttpRequest.5) 2002-08-14 22:09:54 10.0.0.41 - 10.0.0.68 80 POST /autoupdate/getmanifest.asp - 200 Mozilla/4.0+ (compatible;+Win32;+WinHttp.WinHttpRequest.5) 2002-08-14 22:09:56 10.0.0.41 - 10.0.0.68 80 POST /autoupdate/getmanifest.asp - 200 Mozilla/4.0+ (compatible;+Win32;+WinHttp.WinHttpRequest.5) 2002-08-14 22:09:56 10.0.0.41 - 10.0.0.68 80 GET /wutrack.bin U=fb59103f77bf3a46811a0bf04159d88f&C=au& A=d&I=&D=&P=5.0.893.2.110.3.0& L=en-US&S=s&E=00000000&M=items%3D0&X=020814132108618 200 Industry+Update+Control Beispiel 1 – Ein Beispiel für die Informationen im wutrack.bin-Protokoll. Sie können die Updateaktivitäten unter Verwendung der update.log-Datei im Verzeichnis \%windir%\windows jedes Clients überwachen. Die Updateinformationen, die in dieser Datei enthalten sind, sind einfach zu lesen. Wie Beispiel 2 zeigt, fragt der Computer einen Windows Update Server nach neuen Updates ab, lädt diese herunter, installiert sie, und startet neu. Wenn der Systemadministrator den Client so konfiguriert hat, dass er Updates von einem internen SUS-Server herunterlädt, wird dies im Protokoll angezeigt. 2001-11-22 10:37:48 Success IUENGINE Querying software update catalog from http://v4.windowsupdate.microsoft.com/getmanifest.asp 2001-11-22 10:37:56 Success IUENGINE Asynchronous Download started 2001-11-22 10:37:56 Success IUENGINE Download destination root folder is: C:\WUTemp 2001-11-22 10:37:58 Success IUENGINE Downloaded file http://www.download.windowsupdate.com/msdownload/update/v319990518/cabpool/q312461_4C2D6B3A9CF56346C3C38EA71A7CE115E566DCE7.exe 2001-11-22 10:37:58 Success IUENGINE Local path C:\WUTemp\com_microsoft.q312461_ie60_5086\q312461.exe 2001-11-22 10:37:59 Success IUENGINE Downloaded file http://www.download.windowsupdate.com/msdownload/update/v319990518/cabpool/Q311889_B70136AB5CAE78941FA87A4BC0363ACCD22DE882.exe 2001-11-22 10:37:59 Success IUENGINE Local path C:\WUTemp\com_microsoft.Q311889_XP_5081\Q311889.exe 2001-11-22 10:38:10 Success IUENGINE Downloaded file http://www.download.windowsupdate.com/msdownload/update/v319990518/cabpool/Q309521_x86_3C970D04DED697E0DC2DADED5D10A9974534DB79.exe 2001-11-22 10:38:10 Success IUENGINE Local path C:\WUTemp\com_microsoft.Q309521_XP_4973\Q309521_x86.exe 2001-11-22 10:38:10 Success IUENGINE See iuhist.xml for details: Download finished 2001-11-22 10:38:10 Success IUENGINE Asynchronous Install started 2001-11-22 10:38:10 Success IUENGINE Asynchronous Install completed startup 2001-11-22 10:38:14 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft 2001-11-22 10:38:14 Success IUENGINE Installer Command Type: EXE 2001-11-22 10:38:36 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft 2001-11-22 10:38:36 Success IUENGINE Installer Command Type: EXE 2001-11-22 10:39:22 Success IUENGINE Installing SOFTWARE item from publisher com_microsoft 2001-11-22 10:39:22 Success IUENGINE Installer Command Type: EXE 2001-11-22 10:40:14 Success IUENGINE See iuhist.xml for details: Install finished 2001-11-22 10:42:45 Success IUENGINE Shutting down 2001-11-22 10:42:46 Success IUCTL Shutting down 2001-11-23 17:37:37 Success CDM Starting Beispiel 2 – Ein Beispiel für das Updateprotokolldatei. Zu sehen sind Abfrage des Windows Update, Download, Installation und Neustart. Intervention des Benutzers einschränken Sie möchten möglicherweise dafür sorgen, dass die Benutzer die Installation von SUSUpdates nicht stören können, nicht freigegebene Updates nicht von einem Windows Update Server herunterladen können. Sie können dies über Gruppenrichtlinieneinstellungen erreichen. Aktivieren Sie die Einstellung Remove access to use all Windows Update features unter Benutzerkonfiguration / Administrative Vorlagen / Windows Komponenten / Windows Update. Bei allen Windows XP Computern, die von dieser Gruppenrichtlinie betroffen sind, ist der AU-Ordner in der Systemsteuerung dann deaktiviert. Die Möglichkeit der Benutzer auf die Option Halten Sie Ihren Computer mit Windows Update auf dem neusten Stand im Hilfeund Supportcenter zuzugreifen, wird durch diese Einstellung nicht beeinflusst. Sie hat auf Windows 2000 Computer ebenfalls keinen Einfluss. Um diese Möglichkeiten zu sperren, aktivieren Sie die Richtlinie Verknüpfungen und Zugriff auf Windows Update entfernen unter Benutzerkonfiguration / Administrative Vorlagen / Windows Komponenten / Startmenü / Taskleiste. Per Email benachrichtigen lassen Wenn Sie eine Email-Benachrichtigung erhalten möchten, wenn Microsoft ein wichtiges Update für die von Ihnen verwendeten Produkte veröffentlicht, können Sie Sich unter http://go.microsoft.com/fwlink/?linkid=6931 registrieren. Wenn Sie diesen Dienst abonnieren, brauchen Sie nicht mehr jeden Tag über den SUS-Server nach neuen Updates zu schauen und diese freizugeben. Der Email-Dienst benachrichtigt Sie, wenn eine Freigabe notwendig ist. Der Unterschied zwischen diesem Dienst und dem Security Bulletin Service besteht darin, dass der Security Bulletin Service Sie über alles informiert, was mit der Sicherheit von Microsoft Produkten zu tun hat. Die Email-Benachrichtigung des SUS deckt nur die Informationen ab, die sich auf Produkte beziehen, die von SUS unterstützt werden (Windows XP, Windows 200 und IE 5.0 und höher) oder andere Updates die Sie über den SUS installieren können. Wenn Sie beide Dienste abonnieren, bleiben Sie über die Updates die der SUS bearbeitet, und über alle Updates die Sie über andere Wege verteilen müssen, auf dem laufenden. Der SUS ist nicht die einzige Lösung um Systeme auf dem neusten Stand zu halten. Er steht für andere Office- oder Backoffice-Produkte von Microsoft nicht zur Verfügung. Die Kombination von SUS und dem Softwareinstallations-Feature der Gruppenrichtlinien sollte die meiste Arbeit beim Patchen von Computern für Sie erledigen. Das Betriebssystem wird auf dem aktuellsten Stand gehalten und Servicepacks und Hotfixes werden installiert. Bedenken Sie jedoch, dass SUS nach der Freigabe und Installation von Updates keinen Weg zu deren Deinstallation zur Verfügung stellt. Sie müssen hierzu in der entsprechenden Gruppenrichtlinie ein Script unter Computerkonfiguration / Windows Einstellungen / Scripts (Starten/Herunterfahren) erstellen, das bei Start des Computers ausgeführt wird und das Update entfernt. © 2002 Security Administrator. Alle Rechte vorbehalten. Eine Testausgabe des monatliche gedruckten Newsletters Security Administrator erhalten Sie unter: http://www.secadministrator.com/. Bleiben Sie mit Security UPDATE, einem kostenlosen Newsletter für den Sicherheitsbereich auf dem neusten Stand. Sie können diesen Newsletter hier abonnieren: http://email.winnetmag.com/winnetmag/winnetmag_prefctr.asp. Wie bei Microsoft hoffen das die Informationen in diesem Dokument für Sie wertvoll sind. Sie nutzen die Informationen in diesem Dokument allerdings auf eigenes Risiko. Alle Informationen in diesem Dokument werden ohne jegliche Garantie, weder ausdrücklich noch implizit, zu Korrektheit, Vollständigkeit, Funktionstüchtigkeit im Bezug auf bestimmte Zwecke, Urheberrechte oder Urheberrechtsverletzungen, Drittanbieterprodukten oder Informationen der in diesem Dokument durch die Microsoft Corporation genannten Vorschlägen, Garantien, Unterstützungen und Urheberrechten zur Verfügung gestellt. Die Microsoft Corporation haftet weder direkt, indirekt, speziell, als Nebeneffekt oder als Konsequenz für eventuelle Schäden die Sie durch die Verwendung dieser Informationen erleiden. Auch nicht, wenn auf die Möglichkeit solcher Schäden hingewiesen wurde. Alle in diesem Dokument genannten Produktpreise können sich ohne weitere Hinweise ändern.