Mahlzeit.

Auch wir (mittelständisches Unternehmen mit circa 400 WinXP Clients und 30 Servern - Active Directory) wollen nun mit WSUS durchstarten und Patches verteilen. Momentan habe ich Teststellungen in virtuellen Maschinen eingerichtet, um mich mit WSUS und dem Verhalten und Gefahren vertraut zu machen.
Doch jetzt habe ich ein paar Fragen, deren Antworten ich z. T. wohl zu kennen glaube
PS: Fragen sind alle an WSUS 3 gerichtet (siehe Board).

1. Wenn ich den Echtserver in Betrieb nehmen will: Kann ich dann den lokal gespeicherten Content des WUSS Test Servers übernehmen? Ebenso alle Einstellungen etc.? Muss ich dafür einfach den ganzen WSUS Kram auf dem Echtserver installieren und die DB etc einfach rüber kopieren (liegt das alles in dem Verzeichnis, welches ich bei der Installation des WSUS angegeben habe?)? Zumindest habe ich das so rausgelesen.

2. Es gibt keine Möglichkeit, jegliche Updatemeldung auf den Client PC's (haben weder lokale noch Domänenadminrechte - sind also alles Hauptbenutzer) zu unterbinden? Also auch nicht, dass ein Update einen Neustart erfordert? Ich würde unsere User gerne komplett aus diesem Vorgang raushalten.
Klar ist, dass der Rechner niemals automatisch neu startet. Ebenso bekannt ist die Möglichkeit, dass die 2. Aufforderung zum Neustart verzögert werden kann (kann man dann ja soweit verzögern, dass die Zeit definitiv außerhalb der Arbeitszeiten liegt). Ich möchte aber gar keine Meldung von diesem Update Gedöns haben. Neu gestartet wird der PC sowieso jeden Tag.

3. Ich habe hier in der Testumgebung einige Clients, bei denen Updates fehlgeschlagen sind. Wie finde ich heraus, warum? Ein klick auf den Status fehlgeschlagen gibt mir manchmal Meldungen wir: Download fehlgeschlagen oder auch andere kryptische Meldungen.

4. Gibt es wirklich keine Möglichkeit, bestimmte Updates auf bestimmte Rechner pushen zu können? Auf meinen Testclients gibt es z. B. das Problem, dass das Outlook 2003 Junk Filter Update nicht installiert werden konnte (Status: fehlgeschlagen - Fehlermeldung: "Fehler: Download fehlgeschlagen"). Dieses Update konnte aber auf den Rechner der IT wunderbar installiert werden (dies stellt eine weitere Testgruppe dar).

5. was bewirken wuauclt /ResetAuthorization /DetectNow /ReportNow ? Wird der Befehl mit - oder / geschrieben, wenn ich ihn in Start - Ausführen eingebe und ausführen will?

6. Welche Möglichkeit gibt es, eine Versionhistory gut einzusehen? Mir stellt sich gerade das Problem, dass es einige Updates gibt, die andere ersetzen. Damit gibt es auch Updates, die von anderen ersetzt werden. Solche Updates sind dann teilweise nicht mehr notwendig auf dem WSUS vorzuhalten, man kann sie sogar gleich ablehnen. Leider gilt das wohl nicht immer, da teilweise Updates, die von anderen ersetzt werden, zwingend installiert sein müssen, damit sie von den anderen Updates ersetzt werden können. Ich kann mir vorstellen, dass dies der Grund dafür ist, dass einige Updates auf den Clients fehlgeschlagen sind.

7. In den Optionen gibt es die Möglichkeit unter Dateien und Sprachen einen Haken bei "Schnellinstallationsdateien herunterladen" zu setzen. Ich bin mir nicht ganz sicher, was dies bewirkt: Sind die Updates, die WSUS dann von MS runterlädt, in der Dateigröße größer als die normalen Updates? Was beinhalten diese Updates dann zusätzlich? Welchen Vorteil bieten diese Updates? Müssen bei den anderen Updates noch Dateien nachgeladen werden? Wozu dann diese Unterscheidung?

8. Ich plane, kommende Updates nicht automatisch frei zuschalten, sondern erstmal abzuwarten, dann in der Testumgebung zu genehmigen, dann in der IT und dann erst für alle Computer im Netz. Auf was sollte man da besonders achten? Wie kann man am Besten sicherstellen, dass die Updates die Funiktion der Clients nicht richtig beeinträchtigen, keine Probleme auftreten?

Ich danke euch für das Lesen diese etwas längeren Fragekataloges und vor allem auch für die Antworten darauf!

Gruß,
Tim

Sunny schrieb on 23.08.07 um 15:43:07:

Auch eine kluge Idee. Das werden wir so machen, da wir sowieso einen Replika Server für unseren 2. Standort (ist mit einer 34 MBit Funkverbindung zu uns angeschlossen) benötigen und das dann direkt mit dem Echtserver einmal vorab testen können


Sunny schrieb on 23.08.07 um 15:43:07:

Ja, Installationsart 4 ist gewählt und 12 Uhr als Installationszeitpunkt. Dann sind viele in der Mittagspause und können nach dem Mittagessen dann mal schnelle einen Neustart durchführen. So schlecht ist das gar nicht, und ich glaube, dass die User sich darauf auch schnell einstellen werden. Ne Mail vorab ist obligatorisch.


Sunny schrieb on 23.08.07 um 15:43:07:

Nein, dann lieber wenn die User dabei sind. Was Nachts alles passieren kann Dieser Absatz stellte auch mehr meine Möglichkeiten fest als wirklich eine Frage formulieren zu wollen


Sunny schrieb on 23.08.07 um 15:43:07:

Jepp, alle Fehlercodes entschlüsselt. Folgende Seite kann ich sehr empfehlen:
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).
Die meisten Fehlercodes waren: Zu wenig Plattenplatz... *omg* Andere beziehen sich auf das Problem, dass die Office Installationsquelle nicht verfügbar war, obwohl sie das eigentlich sein sollte (Installationsdateien liegen von unserer unattended Installation direkt auf den Clients). Da muss ich mal schauen, wie ich den Fehler umgehen kann.


Sunny schrieb on 23.08.07 um 15:43:07:

Anscheinend helfen /detect now bzw. /reportnow und /ResetAuth.. auch nicht wirklich. Die Clients melden sich dann zwar mal beim Server, holen sich aber keine weiteren Updates. Das geschieht trotzdem nur zum Sync-Zeitpunkt der GPO.
Vielen Dank für den Link zum MS Artikel.


Sunny schrieb on 23.08.07 um 15:43:07:

Serverbereinigungsassistent hilft da nicht wirklich weiter. Es ist ja so, dass wir zum Start vor einem großen Berg an Updates stehen und davon lange nicht alle benötigt werden. Solche Updates, die auf keinen Fall Voraussetzung für andere Updates sind, die nicht mehr benötigt werden weil sie eventuell auch in neuer Version vorliegen oder einfach nur alt sind und im SP enthalten sind, diese will ich auf dem WSUS dann auch gar nicht genehmigen, runterladen oder sonst was. Die stören nur und werden nicht benötigt.
Dafür suche ich eine geeignete Möglichkeit, Ordnung zu schaffen.
Die auto. Genehmigungen greifen hier auch noch nicht, da diese sich noch nicht sinnvoll einsetzen lassen, habe ich das Gefühl ;-(


Sunny schrieb on 23.08.07 um 15:43:07:

Komisch. Wir nutzen also ausschließlich die Schnellinstallationsdateien und haben trotzdem den Fehlercode für "Installationsmedium nicht verfügbar" bekommen. Hängt das also gar nicht zusammen?


Sunny schrieb on 23.08.07 um 15:43:07:

Das kann nicht sein, denn ich habe immer mal wieder ein paar einzelne Dateien genehmigt und dann bemerkt, dass diese noch nicht heruntergeladen waren (wurde mir durch das Symbol in der Spalte angezeigt). Ist ja auch nicht so wichtig, Plattenplatz haben wir genug, auch auf den Echt-Clients. Es gibt fast keine alten Clients mehr, wir haben im letzen Jahr alle Clients von NT auf XP Maschinen migriert und dabei auch gleich alte Hardware über Board geworfen. Das hat zum einen den Vorteil, dass die Clients auf demselben Softwarestand sind, da sie alle die gleiche Installationsquelle nutzen, zum anderen, dass wir genug Rechenpower und Plattenplatz zur Verfügung haben.


Sunny schrieb on 23.08.07 um 15:43:07:

zum Glück sind unsere Installationen nicht so wganz verschieden, unterscheiden sich lediglich in der Verwendung spezieller Software. Diese speziellen Rechner bekommen dann auch eine eigene Gruppe.


Sunny schrieb on 23.08.07 um 15:43:07:

Richtig Mist will ich aber auf keinen meiner Clients hier haben. Das kann dann ja sogar bedeuten, dass die Installationen gar nicht mehr laufen, im schlimmsten Fall. Für diesen Ausfall will ich nicht verantwortlich sein, weil ich kein Prozessmanagement und Testmanagement habe ;-(
Darüber hinaus sind wir eine pharmazeutische Fabrik. Hier gelten ganz besondere Regelungen in einigen Bereichen. Da darf man nicht einfach so rumwurschteln. Da muss jede Änderung validiert werden, Office Programme wurden einzeln validiert (deswegen war es ein riesen Aufwand, auf Office 2003 in allen Bereichen umzustellen. Makros müssen angepasst und validiert werden etc. - naja, ganz abgeschlossen ist die Umstellung auch noch nicht, es gibt noch 2 Hände voll alter NT4SP6-Clients hier im Haus, die aber keineswegs weiter supported werden).


Sunny schrieb on 23.08.07 um 15:43:07:


Yeah, ich danke dir dafür auch ganz ganz dolle! Hast uns sehr geholfen. Wenn du mal im Norden vorbeischaust, dann ist dir dein Bier sicher

Ich bin ab heute im Urlaub, werde auf evetuelle Antworten also erst in ein paar Wochen antworten. So lange werden die Uhren des WSUS Servers auch still stehen

Sunny schrieb on 24.08.07 um 14:07:25:

Bin also zurück und werde mich ab nächster Woche wieder mit WSUS beschäftigen können. Urlaub war übrigens traumhaft

Sunny schrieb on 24.08.07 um 14:07:25:

Hmm, weiß gar nicht, ob da mittlerweile schon was gelaufen ist. Werde demnächst berichten.

Sunny schrieb on 24.08.07 um 14:07:25:

Was heißt: "Kontrolliere den Bits"? Auf den Clients? Was soll ich da wo gucken? Sorry, bin mittlerweile etwas aus dem Thema raus... *omg*

Sunny schrieb on 24.08.07 um 14:07:25:

Wie sehe ich denn, was vom Client angefordert wird? Muss ich mich da auf allen Clients einzeln durchklicken? Gibts da keine schöne Übersicht?

Sunny schrieb on 24.08.07 um 14:07:25:

Nein, weder fehlende Rechte noch der installationspfad sind hier schuld.

Sunny schrieb on 24.08.07 um 14:07:25:

Wir sind in der Gegend 255xx, schau rein, wenn du in der Nähe bist. Stell dann aber sicher, dass ich auch da bin und arbeite und nicht gerade in Hamburg am Studieren bin

Sunny schrieb on 19.09.07 um 11:51:04:

Das freut mich

Sunny schrieb on 19.09.07 um 11:51:04:

Ahh, interessant. Ich habe heute unseren WSUS Testserver wieder angeworfen und mal geschaut, was sich so getan hat. Und in der Tat haben wir keine Probleme mehr mit den Office Updates (ausgenommen das SP3, da es ziemlich viel Platz in Anspruch nimmt und wir da bei einigen Rechnern Probleme hatten - egal, sind ja nur die Test Clients. Müssen usn nur überlegen, wie wir das in Echt Netzwerk hinkriegen ;-(

Sunny schrieb on 19.09.07 um 11:51:04:

Danke für den Tipp. Bits ist in den GPO nicht eingeschränkt, steht auf Nicht konfiguriert. Es steht momentan auch nichts weiter in der queue, der DL ist so schnell, da kommen wir gar nicht mit. Vorhin erst Office03 SP3 genehmigt, schon ist es auf allen Laptops in der IT installiert (zumindest war es zur Installation bereit - einige haben aber ihre Platten so zugemüllt...)
Die Gui ist gut zum testen, klasse Tool.

Sunny schrieb on 19.09.07 um 11:51:04:

Ups, natürlich, Wie doof von mir. Die Clients melden das ja direkt, wenn sie Updates benötigen, selbst wenn die Updates noch nicht genehmigt sind. Klasse, das erleichtert einiges


Sunny schrieb on 19.09.07 um 11:51:04:

Dann mal los!

Sunny schrieb on 20.09.07 um 12:22:18:

Was meinst du denn genau? ich habe den Artikel jetzt überflogen und kann dort nichts relevantes bzgl. BITS finden? Ich finde, die 10% Einstellung ehrlich gesagt überflüssig. Die Clients sollen sich die Updates saugen und gut ist, unser Netz ist schnell genug und der Server gibt dann halt sein Maximum. Die Clients merken jedenfalls in den seltensten Situationen etwas von der ausgelasteten Netzwerkverbindung!

Sunny schrieb on 20.09.07 um 12:22:18:

Ja, das habe ich gelesen. Man kann da sogar die Installation erzwingen. Das ist super interessant, falls sich ein Client mal total weigert.

Sunny schrieb on 21.09.07 um 18:01:12:

Ich lass es einfach so, kann man ja immer noch ändern, wenn man Probleme erwartet

Ich kotze hier gerade an einem ganz anderen fetten Problem ab... Habe gestern den Echtserver aufgesetzt, WSUS als Replika installiert und sich mit meinem Testserver synchronisieren lassen. Blöde, dass das nicht geklappt hat. Nicht nur, dass er nicht alle Einstellungen übernommen hat, nein, vielmehr hat der mir in den Produkten und Klassifizierungen Haken gesetzt, die wir nicht haben wollen. Jetzt haben wir unendlich viele andere Updates in der Liste, die wir gar niemals benötigen werden.
Außerdem scheinen wir ein Problem mit der OU Windows Update zu haben. Am WSUS Server melden sich Rechner, die nie in der entsprechenden OU waren. Hier geht momentan echt alles durcheinandern und wir wissen noch nicht, warum ;-( Darüber hinaus wurde die OU nicht auf die Test Clients übernommen (nach dem Wechsel des interenen Pfads zur Updatequelle). gpedit-msc gibt auf den Clients völlig falsche Einstellungen aus, obwohl das  Check_WSUS_1.05.04.1.vbs die richtigen Einstellungen meldet und sich die entsprechenden Clients auch am neuen WSUS Server gemeldet haben. Nur merkwürdig, warum sich da nun einige andere Clients außerdem der Windows Update OU im AD auch am WSUS Server gemeldet haben...

Sunny schrieb on 25.09.07 um 12:49:50:


Nein, sie stehen nur mit in der Liste und machen das ganze extrem unübersichtlich! Das nervt ;-( Ich vermute aber, dass sie nach 3 Monaten "Nicht genehmigt" vom Serverbereinigungsassistenten sowieso entfernt werden.

Sunny schrieb on 25.09.07 um 12:49:50:

Die Default Domain Policy ist korrekt und wird auf alle Clients im gesamten Unternehmen angewendet. Dann hätten sich alle gemeldet.
nach dem Replika (also dem Aufsetzen des Echtservers und dem syncen mit dem Testserver) trat dieses Problem auf einmal auf.


Sunny schrieb on 25.09.07 um 12:49:50:

Die Clients waren ja schon in der OU, ich habe nur die Richtlinie angepasst und dann gewartet, neu angemeldet, neu gestartet und zuletzt sogar ein gupdate /force /wait:0 gemacht. Aber bevor du dir den Kopf zerbrichst: Es ist alles ok, erklärung folgt zuletzt

Sunny schrieb on 25.09.07 um 12:49:50:

Genau hier lag der Fehler. Das VB Skript hat natürlich die korrekte bzw. die greifende Richtlinie angezeigt, nämlich die aus der Domäne. Die lokale Richtlinie war natürlich auf ganz andere Werte gesetzt, was ja auch ok ist. Die Domänen Richtlinien setzen sich ja darüber hinweg. Gut so. Ich kannte bis eben gerade den Aufruf rsop.msc nicht Das hätte mir mein Kollege auch mal sagen können, der kennt sich mit AD aus, war aber nicht im Haus ;-(
Vielen Dank also für den entscheidenden Tipp.

Bleibt also nur der Fehler mit den beiden PC's, die sich mir nichts dir nichts am WSUS Server gemeldet haben und sich dann noch nichtmal in "nicht verwendete Computer" eingereiht haben, sondern direkt in die Testgruppe aus der IT gerutscht sind.
ich vermute hier ein Fehler im DNS unseres Netzwerkes, da wir in letzter Zeit immer mal wieder falsche RDNS Einträge entdeckt haben... Das ist aber ein anderes Problem, dem wir mal auf den Grund gehen müssen. Das machen aber die Kollegen, da habe ich nichts mit am Hut ;-(

Sunny schrieb on 26.09.07 um 00:04:25:


Oh man, ich verzweifle gerade. Folgendes:

Gestern habe ich die beiden PC's vom WSUS gelöscht. Die tauchten dann auch nicht mehr auf. Heute morgen stehen die wieder im WSUS drin. Auch nicht verwunderlich, wenn die dann irgendwo die Einstellungen her hätten.
Ich habe daraufhin lokal auf dem einen PC geschaut, was Sache ist:
GPEDIT.MSC: Keine Einstellung zu Windows Update
RSOP.MSC: Keine Policies von WSUS auf den Client gedrückt
Das VB Skript ausgeführt: Einstellungen zu WSUS Windows Update verfügbar, allerdings sind die Einstellungen sehr alt, haben aber merkwürdigerweise schon den neuen Echtserver drin.

Die Frage ist jetzt, woher das VB Skript sich die Einstellungen zieht, die GPEDIT und RSOP nicht sehen! Was liest denn die GPEDIT aus, wenn nicht die Registry Einstellungen?
Und mal angenommen, ich hätte früher mal beim Aufsetzen des einen PC's, ein Registry Skript zum lokalen einfügen von WSUS Update Einstellungen ausgeführt: Dann kann in der Registry nur der alte Testserver als Quelle stehen, nicht aber der neue Echtserver, denn dazu existiert gar kein Reg. Skript.
Laut Aussage des User hat es in der Zeit, in welcher sich der PC am WSUS Server gemeldet hat, keine Updates gegeben, die auf sich aufmerksam gemacht hätten. Also keinen Neustart Hinweis, keine Update Ballons, keine Updates beim Runterfahren oder Hochfahren.

Welche Möglichkeiten, außer GPedit und Richtlinienergebnissatz (kann man ja auch aus der AD heraus remote anzeigen lassen - gleiches Ergebnis), gibt es denn noch, sich Einstellungen anzeigen zu lassen bzw. zu ändern?

PS: Bei dem betreffenden PC gibt es keine DNS Probleme, das würde ich hier also ausschließen wollen.

Edit: Der Client hat tatsächlich in der Registry in den von dir genannten Pfad die Einstellungen vermerkt. Fraglich, woher er die hat. Kann ich aber rückgängig machen.

Vielmehr interessiert mich in diesem Zusammenhang aber, warum GPEDIT und RSOP das nciht anzeigen. Worauf greifen GPEDIT und RSOP also zu? Womit kann ich mir wirklich alle Einstellungen anzeigen lassen, ohne mir immer Remote die Registry der Clients auslesen zu müssen und diese Einstellungen auch noch zu überprüfen?

So, bin wieder da, habe heute aber den letzten Tag. Dann gehts erstmal zurück ins Studium. Projekt ist mittlerweile im Echtbetrieb, SP2 werden bereits ausgerollt für eine einheitliche Basis. Demnächst wird dann Abteilung für Abteilung in die Updategruppe mit hinzugenommen, damit wir dann langsam auf einen für uns wichtigen Patchstand von 100% kommen.

Ich danke dir jedenfalls für deine Hilfe. Du hast uns immer wieder nen kleinen Schritt nach vorne gebracht! Danke!

Sunny schrieb on 26.09.07 um 13:44:37:

Das Skript nennt sich "Check_WSUS_1.05.04.1.vbs" und liest, soweit ich das herauslesen kann, die Windows Update Werte aus der lokalen Registry aus - eben an dem Ort, wo du sagtest das ich mal gucken soll.

Sunny schrieb on 26.09.07 um 13:44:37:

Sunny schrieb on 26.09.07 um 13:44:37:

Sunny schrieb on 26.09.07 um 13:44:37:

Tja, interessant ist dann ja aber immer noch, warum GPEDIT und RSOP die Registry nicht mit einbeziehen. In dem speziellen Fall war tatsächlich nichts über GPEDIT gesetzt und der PC hat auch nichts aus der Domain GPO empfangen. Die Werte habe ich damals dann bestimmt per Hand hinzugefügt. Der PC kann sich nichts aus den GPO gezogen haben, die war ihm niemals bekannt, zumal er ja auch die alten Werte (nicht die aktuellen Werte der GPO), aber neuen Server stehen hatte.

Viprex schrieb on 05.10.07 um 10:49:51:


So, nun hab ichs amtlich. Damit Änderungen in der Registry unter HKLM\Software\Policies auch in GPEDIT.MSC angezeigt werden können, müssen die Änderungen in der REGISTRY.POL drin stehen. Und das tun sie NUR bei einer lokalen GPO.