14.3 Windows Server Update Services (WSUS) 
Es hat sich gezeigt, dass das Installieren von Patches, Service Packs oder sonstigen Updates einer der wichtigsten Beiträge sowohl zur »inneren Sicherheit« als auch für die Stabilität der Systeme ist.
So komplexe Produkte wie ein Windows-Betriebssystem, ein Exchange Server oder ein Office-Paket können notwendigerweise niemals fehlerfrei sein, trotz aller Qualitätssicherung in den Entwicklungsprozessen. Hierbei bezieht sich »fehlerfrei« sowohl auf die Resistenz gegen unautorisierte Zugriffsversuche (»Hacking«) als auch auf die stabile Funktion an sich.
Es ist extrem positiv zu bewerten, dass Microsoft mit Fehlern in den Produkten erstens sehr offen umgeht und zweitens recht zügig Patches zur Behebung derselben bereitstellt. Das ist in der IT-Branche vorbildlich. Obwohl es eigentlich selbstverständlich sein sollte, ist mir kein Hersteller bekannt, bei dem dieser Prozess so nachhaltig funktioniert.
Nun verhält es sich aber leider so, dass in den meisten Installationen zwar bei der Erstinstallation darauf geachtet wird, dass aktuelle Service Packs und Patches eingespielt sind, aber danach ist die Maschine sich selbst überlassen. Das war vor 10 Jahren so, vor 5 Jahren, letztes Jahr, ist auch heute so und wird vermutlich auch in der Zukunft noch immer so sein. Da es allerdings dringend notwendig ist, diesen Zustand bzw. Missstand zu beheben, scheint mir ein Abschnitt über WSUS in diesem Buch sehr angebracht zu sein.
Falls Sie glauben, dass Patch-Management mittlerweile eine Selbstverständlichkeit ist und es folglich doch eigentlich nicht notwendig ist, so die Trommel dafür zu rühren: Ich sehe häufig Umgebungen, in denen die Verantwortlichen mich zwar ganz zerknirscht anschauen, aber trotzdem Windows 2000 Server und Clients ohne Service Pack und Patches einsetzen.
Ich kann gut verstehen, dass man nicht monatlich 30 Server und 500 Clients besuchen kann, um dort Updates aufzuspielen. Da der Windows Server Update Service (WSUS) aber sowohl kostenlos als auch recht einfach einzuführen ist, gibt es ab jetzt keine Entschuldigungen mehr …
14.3.1 Die Funktionsweise 
Die Funktionsweise von WSUS ist in Abbildung 14.58 gezeigt:
- Der WSUS-Server im Unternehmen bzw. in der Organisation lädt Update-Definitionen und Updates von der Microsoft Update-Website herunter.
- Die Clients, auf denen der Microsoft Update-Client standardmäßig vorhanden ist, werden über Gruppenrichtlinien konfiguriert. So erhalten sie auf diesem Weg die Information, welcher WSUS-Server verwendet werden soll, ob automatisch die Software-Updates installiert werden sollen und dergleichen mehr.
- Die Clients fragen nun regelmäßig den WSUS-Server ab und erhalten dabei gegebenenfalls die benötigten Updates.
Abbildung 14.58 Stark vereinfacht: Die Funktionsweise von WSUS
Zwei Aspekte wären anzumerken:
- Welche Patches, Updates oder Service Packs letztendlich auf den WSUS-Clients installiert werden sollen, entscheidet weder Microsoft noch der WSUS-Server, sondern der Administrator. Sie können entweder jedes einzelne Update individuell genehmigen, oder Sie erstellen eine oder mehrere Regeln, die dieses für Sie erledigen.
- Im Gegensatz zu vielen »großen« Softwareverteilungslösungen wird bei WSUS der Verteilungsvorgang nicht vom Server angestoßen. Vielmehr ist es die Aufgabe des Clients, sich in regelmäßigen Abständen beim Server zu melden und zu prüfen, ob es Updates für ihn gibt. WSUS basiert also auf einem Pull- und nicht auf einem Push-Verfahren.
Es gibt noch eine weitere gute Nachricht in Zusammenhang mit WSUS – jedenfalls für den Finanzvorstand des Unternehmens: Microsoft bietet WSUS kostenlos an:
- In Windows Server 2008 R2 ist WSUS bereits enthalten. Es ist dort als Rolle vorhanden, die Sie hinzufügen können.
- In Windows Server 2008 (ohne R2) ist WSUS nicht enthalten, kann aber problemlos im Microsoft Download Center heruntergeladen werden. Abbildung 14.59 dient als kleine Suchhilfe. Es ist übrigens notwendig, dass Sie auf das »SP1« achten, ansonsten ist die Version nicht für Windows Server 2008 geeignet; aber vielleicht gibt es, wenn Sie diese Zeilen lesen, ja auch bereits WSUS 4.0.
Abbildung 14.59 Kleine Suchhilfe: Das ist der momentan aktuelle WSUS-Download. Zur Auswahl stehen ein 32- und ein 64-Bit-Download.
14.3.2 Installation
Die Installation ist, wie bei den meisten Microsoft-Produkten, unkompliziert, allerdings sind manuell einige Voraussetzungen zu installieren.
Voraussetzungen installieren
Die erste Voraussetzung ist, dass der Webserver (IIS) installiert ist. Das liegt übrigens nicht etwa daran, dass WSUS zur Verwaltung eine Weboberfläche hätte (hat es auch nicht), sondern dass die Clients über das HTTP-Protokoll zugreifen.
Das Hinzufügen der Rolle Webserver (IIS) wird wie üblich mit dem Server-Manager erledigt. Die Fragestellung dabei ist, welche Rollendienste installiert werden sollen. Hier die Antwort:
- Statischer Inhalt
- ASP.NET
- Windows-Authentifizierung
- IIS 6-Verwaltungskompatibilität
- IIS 6-Metabasiskompatibilität
Die zweite Komponente, die installiert sein muss, ist zwar optional, Sie sollten aber keinesfalls darauf verzichten. Die Rede ist vom Report Viewer Redistributable-Paket. Ist dieses nicht installiert, können Sie keine Reports anzeigen lassen, was für ein professionelles Management der WSUS-Installation natürlich eine Katastrophe ist. Abbildung 14.60 zeigt als Suchhilfe das aktuelle Paket im Download-Center.
Abbildung 14.60 Suchhilfe für den Report Viewer
WSUS installieren
Die Installation erfolgt mithilfe eines Assistenten. Ich werde Sie auf ein paar Kleinigkeiten aufmerksam machen, aber viel Spannendes oder Problematisches gibt es nicht zu vermelden.
Zunächst ist interessant festzustellen, dass die WSUS-Verwaltungskonsole auch einzeln installiert werden kann (Abbildung 14.61, links). Das ist nicht uninteressant, denn so lässt sich vermeiden, dass der Administrator sich auf dem Server anmelden muss. Gut, das ist dank RDP kein Problem, ich bin aber immer dafür, unnötige Anmeldevorgänge auf dem Server zu vermeiden.
Abbildung 14.61 Wie man Sie sehen, kann man auch auf dem Adminarbeitsplatz die Verwaltungskonsole installieren.
In den Dialogen aus Abbildung 14.62 müssen Sie zwei wichtige Entscheidungen treffen:
- Zunächst geht es darum, ob die Updates lokal auf Ihrem Server gespeichert werden sollen. Diese Checkbox werden Sie mit Sicherheit aktivieren, denn ansonsten würde jeder Client seine Updates über das Internet von Microsoft Update holen. Bei der Auswahl des Pfades müssen Sie aber beachten, dass die Datenmenge durchaus ganz ansehnlich ist. Auch wenn Sie »nur« deutschsprachige Versionen beziehen, kommen leicht einige Dutzend Gigabytes (!) zusammen.
- WSUS benötigt eine SQL Server-Datenbank. Falls Sie nicht über einen zentralen Datenbankserver verfügen, der noch ein wenig Last vertragen kann, können Sie den Assistenten die Windows Internal Database installieren lassen. Diese SQL Server-Version ist ein Feature von Windows Server 2008; Sie brauchen es aber nicht per Hand hinzuzufügen.
Abbildung 14.62 Die Frage nach den Ablageorten ist durchaus mit Vorsicht zu beantworten: Es kommen leicht einige Dutzend Gigabytes zusammen.
Die nächste (und letzte) Dialogseite des Assistenten bezieht sich auf die Website, in die die WSUS-Webkomponenten installiert werden sollen (Abbildung 14.63). Sofern keine andere Webanwendung auf dem Server installiert ist (oder werden soll), können Sie der Empfehlung des Assistenten folgen und die IIS-Standardwebsite verwenden. Alternativ kann der WSUS-Installationsassistent auch eine neue Website erstellen. Um diese Website eindeutig »identifizieren« zu können, gibt es drei Möglichkeiten:
- IP-Adresse
- Portnummer (also etwas anderes als 80; diese Möglichkeit würde ich nicht empfehlen)
- Host-Header
Abbildung 14.63 Ist auf der Standardwebsite nichts anderes installiert, können Sie WSUS dorthin installieren.
14.3.3 Erstkonfiguration mit dem Assistenten
Bei der Erstkonfiguration hilft ein freundlicher Assistent, der ein weitgehend betriebsbereites System hinterlässt.
Die erste Entscheidung ist, von welchem Server die Updates abgerufen werden sollen. In den meisten Umgebungen werden das die Microsoft-Systeme (Microsoft Update) sein. Für große verteilte Umgebungen, in denen mehrere WSUS-Server arbeiten, können Sie allerdings auch eine andere Quelle angeben, so dass die Dateien nicht zweimal aus dem Internet geholt werden müssen (Abbildung 14.64).
WSUS kann für die Verbindung natürlich einen Proxy-Server verwenden; auch eine Authentifizierung an diesem ist möglich (Abbildung 14.65). Sind die Verbindungseinstellungen konfiguriert, können Sie mit einem Klick auf die Schaltfläche Verbindung starten die erste »Aktion« auslösen. Dies ist aber nicht nur ein simpler Verbindungstest, sondern es werden die Listen der auf der Updatequelle zur Verfügung stehenden Sprachversionen, Produkte und Klassifizierungen geladen.
Auf den nächsten Dialogseiten geht es nun darum, festzulegen, welche Updates auf dem WSUS-Server zur Verfügung stehen sollen. Auch wenn es vielleicht sehr verlockend ist, »vorsichtshalber« alle Sprachversionen und Updates für alle Produkte zu beziehen, sollten Sie zumindest grob selektieren, was Sie benötigen. Wenn Sie zu großzügig auswählen, haben Sie schnell etliche 100 Gigabytes auf dem Server (Abbildung 14.66).
Abbildung 14.64 Vermutlich werden Sie die Updates vom Microsoft-Server beziehen. Für große Umgebungen mit mehreren WSUS-Servern gibt es auch die Möglichkeit, eine andere Quelle anzugeben.
Abbildung 14.65 Nach der Konfiguration des Proxy-Servers (falls nötig), kann eine Verbindung aufgebaut werden. Dabei werden grundlegende Informationen über Sprachen, Produkte und Klassifizierungen abgerufen.
Abbildung 14.66 Geben Sie die in Ihrer Umgebung vorhandenen Sprachen und Produkte an.
| Globalität |
|
Übrigens: Auch wenn Sie Niederlassungen auf der ganzen Welt haben, müssen Sie entscheiden, ob Sie wirklich die Clients aus Fernost über den deutschen WSUS-Server versorgen möchten. Das kann man machen, aber wenn es sich um größere Niederlassungen handelt, dürften lokale WSUS-Server die deutlich bessere Idee sein. In diesem Fall brauchen Sie diese Sprachversionen gegebenenfalls auch nicht auf dem deutschen Server zu halten. |
Bei der Auswahl der Klassifizierungen sollten Sie ebenfalls mit Augenmaß vorgehen. Wichtige Updates und Sicherheitsupdates sind natürlich »Pflichtprogramm«, allerdings sind Feature Packs und Tools im Allgemeinen Komponenten, die man meist eher nicht über WSUS installiert. Ich möchte nun zwar nicht um ein paar Gigabytes mehr oder weniger feilschen – wenn Sie viele Sprachversionen benötigen, summiert sich das. Ich mache mir übrigens weniger Sorgen um die Plattenkapazität, sondern um Ihre Internetanbindung. Wenn die ohnehin stark belastet ist, spielen »ein paar Gigabytes« eben doch eine Rolle (Abbildung 14.67).
Abbildung 14.67 Wählen Sie, welche Arten von Updates wann heruntergeladen werden sollen.
Auf der nächsten Dialogseite geht es nun noch darum, die Synchronisierungshäufigkeit und die »Grundzeit« festzulegen.
Tja, und dann haben Sie den Assistenten bereits durchgearbeitet. Auf der letzten Dialogseite bietet er Ihnen an, direkt die Erstsynchronisation zu beginnen. Das macht Sinn, denn ohne Synchronisierung ist der Nutzwert der WSUS sehr begrenzt (Abbildung 14.68).
Ob die Synchronisierung läuft, können Sie übrigens in der Verwaltungskonsole erkennen: Wenn Sie den Knoten Synchronisierungen wählen, sollten Sie einen laufenden Vorgang sehen (Abbildung 14.69).
Abbildung 14.68 Auf Wunsch kann der Assistent direkt die Erstsynchronisation starten.
Abbildung 14.69 Hier ist in der Verwaltungskonsole von WSUS die laufende Erstsynchronisation zu sehen.
14.3.4 Konfiguration und Betrieb
Auch wenn der soeben besprochene Assistent schon ein weitgehend lauffähiges System hinterlässt, gibt es in der WSUS-Verwaltungskonsole noch hinreichend viele weitere Optionen, die konfiguriert werden können. Abbildung 14.70 zeigt einen ersten Blick in die Optionen der Verwaltungskonsole, wobei viele Bereiche bereits vom Assistenten abgearbeitet worden sind – aber vielleicht muss daran ja auch irgendwann etwas verändert werden.
Wir werden nicht jeden Konfigurationsbereich ansehen, da diese Dialoge überwiegend selbsterklärend sind. Ich möchte Sie aber gern durch ein paar »wirklich wichtige Aspekte« führen.
| Hinweis |
|
Ein wesentlicher Konfigurationsaspekt sind die Automatischen Genehmigungen. Diese bespreche ich in Abschnitt 14.3.5. Die WSUS-Verwaltungskonsole finden Sie übrigens in der Gruppe Verwaltung des Startmenüs. |
Abbildung 14.70 In der WSUS-Verwaltungskonsole gibt es immerhin ein Dutzend Optionen zu konfigurieren.
Gruppen anlegen, Computer zuordnen
Vermutlich werden Sie nicht alle Computer gleich behandeln wollen. Es gibt durchaus absolut unternehmenskritische Server, auf denen Sie vermutlich nicht automatisiert Updates einspielen möchten. Um dies zu steuern, gibt es zwei Ansatzpunkte:
- Mithilfe von Gruppenrichtlinien können Sie beispielsweise festlegen, ob die Computer Updates automatisch beziehen sollen und falls notwendig direkt einen Neustart durchführen.
- Über WSUS-Computergruppen steuern Sie vereinfacht gesagt, welche Computer welche Updates erhalten. Wenn Sie beispielsweise möchten, dass einige Clients das Service Pack 5 für Vista bekommen, andere aber nicht, kann das über die besagten WSUS-Computergruppen realisiert werden.
Ein Client, der sich zum ersten Mal beim WSUS-Server meldet, wird in die Gruppe Nicht zugewiesene Computer einsortiert. Wenn alle Systeme in Ihrem Netz dieselben Updates bekommen, könnten Sie sogar alle Computer dort belassen. Die meisten Administratoren möchten aber doch differenzieren können.
| WSUS nicht zur Trennung |
|
Sie benötigen diese Gruppen übrigens nicht, um Computer mit verschiedenen Betriebssystemen, Office-Versionen und dergleichen voneinander zu trennen. WSUS und der WSUS-Client sind so schlau, dass ein Windows XP-System keine Vista-Patches lädt und diese installiert (bzw. es versucht). |
In einer kleinen und gleichzeitig einigermaßen simplen Umgebung könnte man beispielsweise drei Computergruppen einrichten:
- Standardclients, in die alle Client-Systeme einsortiert werden.
- Server, Class A: Das sind die wirklich kritischen und komplexen Systeme. Diese sollten natürlich auch aktuell gehalten werden, aber gegebenenfalls möchten Sie die Updates für diese Systeme zuvor in einer Testumgebung ausprobieren.
- Server, Class B: Diese Server sind zwar ebenfalls wichtig, allerdings können zumindest kritische Patches für diese automatisch genehmigt werden.
Da ein WSUS-Client Mitglied in verschiedenen Gruppen sein kann, sind beliebig komplexe Gruppenkonzepte denkbar. Wenn mir die »WSUS-Beauftragten« von größeren Unternehmen ihre WSUS-Computergruppen-Strategie vorstellen, habe ich teilweise den Eindruck, dass es um die Realisierung der weichen Mondlandung und nicht »nur« um die Verteilung von Patches geht. Mit mehr oder weniger viel Mühe kann man das wirklich zur Perfektion treiben – Respekt!
Kommen wir zu den praktischen Dingen des Lebens (Abbildung 14.71):
- Das Anlegen von neuen WSUS-Computergruppen geschieht im Kontextmenü des Knotens Alle Computer. Benötigt wird hier nur ein gut klingender Name für die neue Gruppe.
- Um einen Computer einer oder mehrere Gruppen zuzuordnen, wählen Sie den Menüpunkt Mitgliedschaft ändern des Kontextmenüs.
| Alternative |
|
Die Gruppe oder Gruppen, in die ein Computer »einsortiert« werden soll, kann bzw. können alternativ auch in den Gruppenrichtlinien konfiguriert werden. |
Abbildung 14.71 Ein neuer Computer wird standardmäßig in die Gruppe »Nicht zugewiesene Computer« einsortiert.
Computer überwachen
Wie ich weiter vorn erwähnt habe, basiert WSUS darauf, dass sich der Client regelmäßig beim Server »meldet«, um Updates zu beziehen. Falls der Client das längere Zeit nicht tut, kann es dafür zwei Gründe geben:
- Der Computer ist länger nicht eingeschaltet worden, beispielsweise weil der Besitzer im Urlaub oder dergleichen ist. Das kann natürlich für Server nicht zutreffen (schlecht wäre, wenn ein Server nicht mehr läuft, wenn der Admin im Urlaub ist, was aber oft genug vorkommt).
- Der WSUS-Client hat ein irgendwie geartetes Problem und kann nicht (mehr) mit dem Server kommunizieren.
In der Liste der Computer können Sie unter anderem erkennen, wann ein WSUS-Client sich das letzte Mal beim Server gemeldet hat (Abbildung 14.72). Die Liste kann beispielsweise nach dem Datum sortiert sein, so dass Sie sich relativ einfach einen Überblick verschaffen können.
Synchronisierungen überwachen
Ein weiterer Aspekt, den Sie regelmäßig überprüfen sollten, ist die Durchführung bzw. der Erfolg der Synchronisierungen mit der Update-Quelle. Die in Abbildung 14.73 gezeigte Liste gibt einen Überblick über den Erfolg, den Zeitpunkt und die Anzahl der gefundenen Updates.
Im Kontextmenü jedes Eintrags findet sich der Menüpunkt Statusbericht. Dort erhalten Sie Details zum Vorgang, beispielsweise welche neuen Updates gekommen sind und welche vorhandenen Updates dadurch ersetzt wurden.
Abbildung 14.72 Hier bekommen Sie eine Übersicht über alle Computer. Wenn sich ein System lange nicht gemeldet oder Updates mit Fehlern hat, besteht Handlungsbedarf.
Abbildung 14.73 Es kann nicht schaden, gelegentlich die Synchronisierungsvorgänge zu überwachen.
14.3.5 Updates genehmigen
Auch wenn Sie bis hierhin alles perfekt konfiguriert haben, wird kein einziger Patch auf einen WSUS-Client gelangen. Der Grund ist, dass der WSUS-Server kein Update an einen WSUS-Client sendet, wenn es nicht genehmigt (d. h. freigegeben) ist. Genauer gesagt muss ein Update für jede einzelne Computergruppe genehmigt werden.
Da realistisch betrachtet kaum ein Administrator Zeit dafür haben wird, jedes einzelne Update zu kontrollieren und für die diversen angelegten Computergruppen zu genehmigen, können Sie sich von der Automatischen Genehmigung helfen lassen.
Automatische Genehmigung konfigurieren
In der Praxis arbeiten die meisten Administratoren mit automatischen Genehmigungen. Den Konfigurationsdialog rufen Sie in der Verwaltungskonsole über Optionen • Automatische Genehmigungen auf.
Standardmäßig vorhanden ist die Automatische Standardgenehmigungsregel, die besagt, dass Updates, die als Sicherheitsupdate oder Wichtiges Update klassifiziert sind, für Alle Computer genehmigt werden (Abbildung 14.74).
Abbildung 14.74 Sie können beliebig viele Regeln anlegen. Die »Automatische Standardgenehmigungsregel« ist bereits vorhanden, allerdings deaktiviert.
Sie können diese Regel bei Bedarf modifizieren. Bevor aber irgendetwas passiert, muss sie zunächst aktiviert werden.
Wenn Sie eine Regel erstellt und aktiviert haben, wirkt sie für neu eingehende Updates. Sie können die Regel sofort auf alle vorhandenen Updates anwenden, wenn Sie die Schaltfläche Regel ausführen anklicken (Abbildung 14.75).
Abbildung 14.75 Eine Genehmigungsregel kann sofort ausgeführt werden.
Auf der Registerkarte Erweitert finden Sie einige zusätzliche Optionen:
- Es kann konfiguriert werden, dass Updates, die den WSUS-Server betreffen, automatisch genehmigt werden.
- Weiterhin gibt es zwei Einstellungen, die den Umgang mit Updateversionen betreffen.
Beim Umgang mit automatischen Genehmigungen gehen die meisten Unternehmen übrigens wie folgt vor:
- Updates, die als Sicherheitsupdate oder Wichtiges Update klassifiziert sind, werden automatisch genehmigt – zumindest für Clients.
- Service Packs werden im Allgemeinen nicht automatisch genehmigt, sondern nach diversen Tests manuell genehmigt.
- Bei kritischen Servern empfiehlt es sich, gegebenenfalls zuvor in der Testumgebung die »Verträglichkeit« von Updates zu untersuchen. Also ist manuelles Genehmigen angesagt.
Updates manuell genehmigen
Unterhalb des Knoten Updates befinden sich vier verschiedene Kategorien. In der Kopfzeile der angezeigten Liste sind Filter vorhanden. Es kann nach dem Genehmigungsstatus (z. B. Nicht genehmigt) und/oder dem Status (z. B. Fehlgeschlagen oder Erforderlich) gefiltert werden (Abbildung 14.76). In dem Statusbereich (am unteren Rand des Fensters) wird ein Kurzüberblick zu dem selektierten Update gezeigt. Wenn Sie mehr Details sehen möchten, beispielsweise die Server, für die das Update benötigt wird oder würde, wählen Sie den Menüpunkt Statusbericht aus dem Kontextmenü des Eintrags (Abbildung 14.77).
Abbildung 14.76 Die angezeigten Updates können gefiltert werden. Im Kontextmenü können Sie beispielsweise »Genehmigen« oder »Ablehnen« wählen.
Abbildung 14.77 Im Statusbericht können Sie beispielsweise abfragen, welche Computer das Update benötigen.
Wenn Sie den Menüpunkt Genehmigen aufrufen, erscheint der Dialog aus Abbildung 14.78, in dem Sie die Genehmigung für die einzelnen Gruppen steuern können. Wenn die WSUS-Clients einer solchen Gruppe das nächste Mal die Liste der einzuspielenden Updates abfragen, erhalten Sie dieses Update.
Abbildung 14.78 Das Update kann für »Alle Computer« oder ausgewählte Gruppen genehmigt werden.
14.3.6 Gruppenrichtlinie konfigurieren
Da die WSUS-Clients über Gruppenrichtlinien konfiguriert werden, ist es höchste Zeit, diesen Aspekt genauer zu betrachten.
Die Einstellungen finden Sie im Gruppenrichtlinienverwaltungs-Editor unter Computerkonfiguration • Richtlinien • Administrative Vorlagen • Windows-Komponenten • Windows Update. Dort gibt es immerhin 15 Einstellungen, mit denen Sie das Verhalten recht granular steuern können. Abbildung 14.79 zeigt die Einstellung Internen Pfad für den Microsoft Updatedienst angeben, also den Verweis auf Ihren WSUS-Server. Wenn Sie mehrere WSUS-Server an verschiedenen Standorten haben, ist das übrigens eine Einstellung, die sehr gut in einer Standortrichtlinie aufgehoben ist.
Abbildung 14.79 Für WSUS gibt es diverse Gruppenrichtlinien-Einstellungen. Hier wird der zu verwendende WSUS-Server angegeben.
Sehr wichtig ist übrigens auch die in Abbildung 14.80 gezeigte Einstellung, die das automatische Einspielen von Updates regelt.
Die Einstellungen sind im Gruppenrichtlinienverwaltungs-Editor recht ausführlich beschrieben, so dass eine weitere Erläuterung an dieser Stelle nicht notwendig ist. Sie werden vermutlich ein wenig experimentieren müssen, bis Sie Ihre individuellen »Optimaleinstellungen« gefunden haben.
Abbildung 14.80 »Automatische Updates« konfigurieren ist eine besonders wichtige Einstellung: Hier wird festgelegt, ob und wann Updates automatisch eingespielt werden sollen.
14.3.7 Kurzer Blick auf den WSUS-Client
Die Betriebssysteme ab Windows 2000 SP3 verfügen standardmäßig über einen WSUS-Client. Abgesehen von dem kleinen Eintrag in der Menüleiste ist von ihm aber im Normalfall wenig zu sehen. Im Windows Server 2008-Server-Manager findet sich ein Überblick über den aktuellen Status, was auf Abbildung 14.81 gezeigt ist; es handelt sich hier übrigens um ein »ganz frisches« System, weshalb auch noch keine Updates installiert wurden.
Abbildung 14.81 Im Server-Manager von Windows Server 2008 wird der Status von WSUS angezeigt.
In der Systemsteuerung kann das Applet Windows Update aufgerufen werden, das einen Überblick über die für diesen Computer bereitliegenden Updates gibt (Abbildung 14.82). Auch der Updateverlauf ist häufig nicht uninteressant.
Abbildung 14.82 Im »Windows Update«-Applet der Systemsteuerung können Sie nachschauen, welche Updates für den Computer bereitliegen.
Abbildung 14.83 Im Netzwerkmonitor können Sie sich überzeugen, dass die Kommunikation zwischen WSUS-Server und -Client über HTTP abläuft.
| »wuauclt« |
|
Außerdem besteht die Möglichkeit, einige Befehle mittels des Kommandozeilenprogramms wuauclt abzusetzen. Mit wuauclt /detectnow können Sie beispielsweise einen Überprüfungsvorgang einleiten, und wuauclt /reportnow sendet den aktuellen Status an den WSUS-Server. |
Ich habe zuvor immer behauptet, dass die Kommunikation zwischen WSUS-Client und -Server über das HTTP-Protokoll abläuft. Den »Beweis« sehen Sie in einem Netzwerkmonitor-Mitschnitt (Abbildung 14.83). In der Abbildung sehen Sie übrigens den Beginn des »Nach Updates suchen«-Vorgangs.
14.3.8 Mit Berichten arbeiten
Wenn Sie das Report Viewer Distributable-Paket installiert haben (siehe Installationsvoraussetzungen in Abschnitt 14.3.2), können Sie diverse Berichte aufrufen. Unterhalb des Knotens Berichte finden Sie diverse allgemeine Reports. Die Beschreibung lässt bereits vermuten, worum es dort jeweils geht (Abbildung 14.84).
Abbildung 14.84 Mithilfe der Berichte lassen sich diverse Aspekte ermitteln.
An verschiedenen Stellen der Verwaltungskonsole können »spezielle« Berichte aufgerufen werden, beispielsweise im Kontextmenü eines Updates (siehe auch Abbildung 14.77) oder eines Computers. Der Statusbericht des Computers ist in Abbildung 14.85 zu sehen. Neben einigen grundlegenden technischen Daten ist die Statuszusammenfassung von besonderem Interesse. In diesem Fall ist zwar alles grün, allerdings wurden 7 Updates nicht installiert.
Abbildung 14.85 Diesen Detailbericht können Sie in der Verwaltungskonsole aus dem Kontextmenü des WSUS-Clients aufrufen.
Abbildung 14.86 Nicht uninteressant ist auch der Updatestatusbericht. Sie können dort auch herausfinden, warum ein Update noch nicht installiert worden ist (»Nicht genehmigt«).
Wenn Sie mehr Details brauchen und wissen möchten, welche Updates nicht installiert werden können, wechseln Sie auf die zweite Seite des Berichts. Dort werden die Updates nebst Genehmigungs- und Installationsstatus gezeigt. In diesem Fall wurden die Updates also nicht installiert, weil sie schlicht und ergreifend nicht genehmigt sind – auch einleuchtend.
