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

Viprex schrieb am 23.08.07 um 13:13:33:

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.

Installiere den echten WSUS als Downstreamserver, synchronisiere vom jetzigen und konfiguriere ihn dann wieder via Optionen um. Fertig.


Viprex schrieb am 23.08.07 um 13:13:33:

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.

Ich hab die Erfahrung gemacht, sie einzubinden ist nicht das schlechteste. Bei mir gibts immer ein Mail bei neuen Updates, ok, es sind nur insgesamt 150, aber im Haus hier sind es 60. Und da hat es sich bewährt. Wir lassen die Updates täglich um 12.00 Uhr installieren. Nach der ersten Orgie hat sich das mittlerweile auf 1 x pro Monat eingependelt. Bei XP-Clients hast Du ja auch die Möglichkeit die Updates beim Herunterfahren installieren zu lassen. Aber auch das müssen die User nutzen.


Viprex schrieb am 23.08.07 um 13:13:33:

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.

Dann schalte die Clients nachts via Wake-On-LAN ein, installiere die Updates und fahre die Clients wieder runter.


Viprex schrieb am 23.08.07 um 13:13:33:

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.

Download fehlgeschlagen ist ja recht eindeutig. Während der BITS die Updates vom WSUS downloaden wollte, wurde der Client heruntergefahren oder sonst der Download unterbrochen.

Die restlichen Meldungen kannst Du in der WindowsUpdate.log auf dem Client sehen. Oder mit den kryptischen Meldungen hier im Forum in auf der Hauptseite in den Fehlercodes suchen. ;)



Viprex schrieb am 23.08.07 um 13:13:33:

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).

Der WSUS stellt nur die Updates zur Verfügung, der WU-Agent auf dem Client holt sich die Updates. Einzig mit der Stichtag Installation kannst Du das forcieren.


Viprex schrieb am 23.08.07 um 13:13:33:

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?

Der Befehl wird mit /Option geschrieben.
  (Du musst Dich Einloggen oder Registrieren


Viprex schrieb am 23.08.07 um 13:13:33:

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.

In den jeweiligen Eigenschaften des Updates ist das zu sehen. Keine Angst, der WSUS löscht nur Updates die Du entweder abgelehnt hast, oder die durch andere komplett ersetzt wurden. Schau dir dazu auch mal den Serverbereinigungsassistenten an. Auch sind die Automatischen Genehmigungen es wert angesehen zu werden.


Viprex schrieb am 23.08.07 um 13:13:33:

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?

Die Schnellinstallationsdateien sind größer und brauchen mehr Platz auf der HDD. Aber: Wenn Du Office Updates verteilen möchtest, und die lokalen Installation mittels gepatchtem administrativen Installationspunkt installiert hast, kommst Du um die Schnellinstallationsdateien nicht rum.

Ich hab mich ansonsten damit noch nicht beschäftigt, wir haben noch Office 2000 im Einsatz, das unterstützt der WSUS nicht.

Die Unterscheidung zu den Schnellinstallationsdateien liegt AFAIK darin, daß Du die normalen zur Installation freigibst, dann erst werden die Updates gedownloadet. Bei den Schnellinstallationsdateien erfolgt der Download mit der Synchronisierung. Sicher bin ich mir aber auch da nicht.


Viprex schrieb am 23.08.07 um 13:13:33:

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?

Gar nicht. Am besten in den Foren und/oder den MS-Newsgroups mitlesen, und auch auf dieser Seite lesen:   (Du musst Dich Einloggen oder Registrieren
Wie du selbst weißt, ist jede Installation anders, als die nächste nebenan.

Das von dir gen. Vorgehen ist soweit in Ordnung und schützt dich insoweit, als das Du ins offene Messer läufst. Wenn ein Patch/Update richtig Mist baut, dann kommt meistens nach ein paar Tagen eine entsprechende Revision raus oder der Patch zum Patch. Wir hatten in jetzt 4 Jahren SUS + WSUS grad mal 2 oder 3 Fälle. Einer war das ELSTER-Modul, einer mit .Net Framework 1.1 und einer ganz am Anfang. Beim Rest war alles in Butter. Das muß aber nix bedeuten, Du hast vielleicht viel kritischere Anwendungen am Start als wir.



Viprex schrieb am 23.08.07 um 13:13:33:

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

Puh, das war jetzt richtig viel. Wärst Du hier würde ich sagen, daß kostet dich heute abend ein Bier. ;)

Sunny schrieb am 23.08.07 um 15:43:07:

Viprex schrieb am 23.08.07 um 13:13:33: 1. Wenn ich den Echtserver in Betrieb nehmen will: Kann ich dann den lokal gespeicherten Content des WUSS Test Servers übernehmen... Installiere den echten WSUS als Downstreamserver, synchronisiere vom jetzigen und konfiguriere ihn dann wieder via Optionen um. Fertig.

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 am 23.08.07 um 15:43:07:

Viprex schrieb am 23.08.07 um 13:13:33: 2. Es gibt keine Möglichkeit... Ich hab die Erfahrung gemacht, sie einzubinden ist nicht das schlechteste. Bei mir gibts immer ein Mail bei neuen Updates, ok, es sind nur insgesamt 150, aber im Haus hier sind es 60. Und da hat es sich bewährt. Wir lassen die Updates täglich um 12.00 Uhr installieren. Nach der ersten Orgie hat sich das mittlerweile auf 1 x pro Monat eingependelt. Bei XP-Clients hast Du ja auch die Möglichkeit die Updates beim Herunterfahren installieren zu lassen. Aber auch das müssen die User nutzen.

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 am 23.08.07 um 15:43:07:

Viprex schrieb am 23.08.07 um 13:13:33: Klar ist, dass der Rechner niemals automatisch neu startet. Ebenso bekannt ist die Möglichkeit... Dann schalte die Clients nachts via Wake-On-LAN ein, installiere die Updates und fahre die Clients wieder runter.

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



Sunny schrieb am 23.08.07 um 15:43:07:

Viprex schrieb am 23.08.07 um 13:13:33: 3. Ich habe hier in der Testumgebung einige Clients... Download fehlgeschlagen ist ja recht eindeutig. Während der BITS die Updates vom WSUS downloaden wollte, wurde der Client heruntergefahren oder sonst der Download unterbrochen. Die restlichen Meldungen kannst Du in der WindowsUpdate.log auf dem Client sehen. Oder mit den kryptischen Meldungen hier im Forum in auf der Hauptseite in den Fehlercodes suchen. ;)

Jepp, alle Fehlercodes entschlüsselt. Folgende Seite kann ich sehr empfehlen:
  (Du musst Dich Einloggen oder Registrieren
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 am 23.08.07 um 15:43:07:

Viprex schrieb am 23.08.07 um 13:13:33: 4. Gibt es wirklich keine Möglichkeit, bestimmte Updates auf bestimmte Rechner pushen... Der WSUS stellt nur die Updates zur Verfügung, der WU-Agent auf dem Client holt sich die Updates. Einzig mit der Stichtag Installation kannst Du das forcieren. Viprex schrieb am 23.08.07 um 13:13:33: 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? Der Befehl wird mit /Option geschrieben.   (Du musst Dich Einloggen oder Registrieren 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 am 23.08.07 um 15:43:07: Viprex schrieb am 23.08.07 um 13:13:33: 6. Welche Möglichkeit gibt es, eine Versionhistory gut einzusehen... In den jeweiligen Eigenschaften des Updates ist das zu sehen. Keine Angst, der WSUS löscht nur Updates die Du entweder abgelehnt hast, oder die durch andere komplett ersetzt wurden. Schau dir dazu auch mal den Serverbereinigungsassistenten an. Auch sind die Automatischen Genehmigungen es wert angesehen zu werden. 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 am 23.08.07 um 15:43:07: Viprex schrieb am 23.08.07 um 13:13:33: 7. In den Optionen gibt es die Möglichkeit unter Dateien und Sprachen einen Haken... Die Schnellinstallationsdateien sind größer und brauchen mehr Platz auf der HDD. Aber: Wenn Du Office Updates verteilen möchtest, und die lokalen Installation mittels gepatchtem administrativen Installationspunkt installiert hast, kommst Du um die Schnellinstallationsdateien nicht rum. 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 am 23.08.07 um 15:43:07: Ich hab mich ansonsten damit noch nicht beschäftigt, wir haben noch Office 2000 im Einsatz, das unterstützt der WSUS nicht. Die Unterscheidung zu den Schnellinstallationsdateien liegt AFAIK darin, daß Du die normalen zur Installation freigibst, dann erst werden die Updates gedownloadet. Bei den Schnellinstallationsdateien erfolgt der Download mit der Synchronisierung. Sicher bin ich mir aber auch da nicht. 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 am 23.08.07 um 15:43:07: Viprex schrieb am 23.08.07 um 13:13:33: 8. Ich plane, kommende Updates nicht automatisch frei zuschalten... Gar nicht. Am besten in den Foren und/oder den MS-Newsgroups mitlesen, und auch auf dieser Seite lesen:   (Du musst Dich Einloggen oder Registrieren Wie du selbst weißt, ist jede Installation anders, als die nächste nebenan. 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 am 23.08.07 um 15:43:07: Das von dir gen. Vorgehen ist soweit in Ordnung und schützt dich insoweit, als das Du ins offene Messer läufst. Wenn ein Patch/Update richtig Mist baut, dann kommt meistens nach ein paar Tagen eine entsprechende Revision raus oder der Patch zum Patch. Wir hatten in jetzt 4 Jahren SUS + WSUS grad mal 2 oder 3 Fälle. Einer war das ELSTER-Modul, einer mit .Net Framework 1.1 und einer ganz am Anfang. Beim Rest war alles in Butter. Das muß aber nix bedeuten, Du hast vielleicht viel kritischere Anwendungen am Start als wir. 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 am 23.08.07 um 15:43:07: [quote author=Viprex link=1187867615/0#0 date=1187867613] Ich danke euch für das Lesen diese etwas längeren Fragekataloges und vor allem auch für die Antworten darauf! Puh, das war jetzt richtig viel. Wärst Du hier würde ich sagen, daß kostet dich heute abend ein Bier. ;)

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 ;-)

Viprex schrieb am 24.08.07 um 13:46:00:

Jepp, alle Fehlercodes entschlüsselt. Folgende Seite kann ich sehr empfehlen:   (Du musst Dich Einloggen oder Registrieren 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.

Berichte bitte was dabei rausgekommen ist. Über kurz oder lang werden wir bestimmt auch mal auf Office 2003 umsteigen, dann ist so eine Information bestimmt hilfreich. ;)



Viprex schrieb am 24.08.07 um 13:46:00:

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.

Kontrolliere den BITS. Per Default nimmt er sich 10% der zur Verfügung stehenden Bandbreite. Mit der Synczeit der GPO hat das nix zu tun. Du meinst jetzt hoffentlich nicht die Installationszeit, oder?



Viprex schrieb am 24.08.07 um 13:46:00:

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.

Ja, aller Anfang ist schwer. ;) Lass den WSUS ermitteln und gib nur die Updates frei, die auch vom Client angefordert werden. Das was Du siehst in der GUI sind nur die META-Daten in der DB. Auch die wird mit dem Serverbereinigungsassistenten verkleinert.


Viprex schrieb am 24.08.07 um 13:46:00:

Die auto. Genehmigungen greifen hier auch noch nicht, da diese sich noch nicht sinnvoll einsetzen lassen, habe ich das Gefühl ;-(

Noch nicht!

Viprex schrieb am 24.08.07 um 13:46:00:

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?

Prüf das mal, evtl. fehlen Rechte oder der Pfad zum Installationsmedium stimmt nicht.



Viprex schrieb am 24.08.07 um 13:46:00:

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 ;-)

Das kommt schon hin wieder mal vor. Ich nehm dich beim Wort. :)


Viprex schrieb am 24.08.07 um 13:46:00:

Ich bin ab heute im Urlaub, werde auf evetuelle Antworten also erst in ein paar Wochen antworten.

Yepp, ist OK. Ich bin auch erst wieder Ende nächster Woche ONLINE. Schönen Urlaub dir und schönes WE an die restlichen Leser. ;)

Sunny schrieb am 24.08.07 um 14:07:25:

Viprex schrieb am 24.08.07 um 13:46:00: Ich bin ab heute im Urlaub, werde auf evetuelle Antworten also erst in ein paar Wochen antworten. Yepp, ist OK. Ich bin auch erst wieder Ende nächster Woche ONLINE. Schönen Urlaub dir und schönes WE an die restlichen Leser. ;)

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


Sunny schrieb am 24.08.07 um 14:07:25:

Viprex schrieb am 24.08.07 um 13:46:00: Jepp, alle Fehlercodes entschlüsselt. Folgende Seite kann ich sehr empfehlen:   (Du musst Dich Einloggen oder Registrieren 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. Berichte bitte was dabei rausgekommen ist. Über kurz oder lang werden wir bestimmt auch mal auf Office 2003 umsteigen, dann ist so eine Information bestimmt hilfreich. ;)

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


Sunny schrieb am 24.08.07 um 14:07:25:

Viprex schrieb am 24.08.07 um 13:46:00: 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. Kontrolliere den BITS. Per Default nimmt er sich 10% der zur Verfügung stehenden Bandbreite. Mit der Synczeit der GPO hat das nix zu tun. Du meinst jetzt hoffentlich nicht die Installationszeit, oder?

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 am 24.08.07 um 14:07:25:

Viprex schrieb am 24.08.07 um 13:46:00: 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. Ja, aller Anfang ist schwer. ;) Lass den WSUS ermitteln und gib nur die Updates frei, die auch vom Client angefordert werden. Das was Du siehst in der GUI sind nur die META-Daten in der DB. Auch die wird mit dem Serverbereinigungsassistenten verkleinert.

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 am 24.08.07 um 14:07:25:

Viprex schrieb am 24.08.07 um 13:46:00: 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? Prüf das mal, evtl. fehlen Rechte oder der Pfad zum Installationsmedium stimmt nicht.

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


Sunny schrieb am 24.08.07 um 14:07:25:

Viprex schrieb am 24.08.07 um 13:46:00: 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 ;-) Das kommt schon hin wieder mal vor. Ich nehm dich beim Wort. :)

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 :P

Viprex schrieb am 19.09.07 um 11:21:45:

Urlaub war übrigens traumhaft ;-)

Meiner war auch nicht schlecht. ;-)


Viprex schrieb am 19.09.07 um 11:21:45:

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

Ich hab in news etwas zum Thema gepostet:   (Du musst Dich Einloggen oder Registrieren


Viprex schrieb am 19.09.07 um 11:21:45:

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

Für den Bits gibts eine GUI:   (Du musst Dich Einloggen oder Registrieren  Damit siehst Du ob noch Jobs in Queue sind. Habt ihr den BITS via GPOs eingeschränkt?


Viprex schrieb am 19.09.07 um 11:21:45:

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

Doch, gibts schon. Siehe angehängtes Bild, gleich in der Übersicht. Oder auch in der Detail Ansicht für die Clients. Besser machst Du das aber in den Update Ansichten.




Viprex schrieb am 19.09.07 um 11:21:45:

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 :P

Hamburg ist gut, da bin ich wenn dann eher zu finden. Ich glaub ich muß mal ne Tour in den Norden machen, die Biere sollten für eine Woche reichen. ;-)

---

Sunny schrieb am 19.09.07 um 11:51:04:

Viprex schrieb am 19.09.07 um 11:21:45: Urlaub war übrigens traumhaft ;-) Meiner war auch nicht schlecht. ;-)

Das freut mich ;-)


Sunny schrieb am 19.09.07 um 11:51:04:

Viprex schrieb am 19.09.07 um 11:21:45: Hmm, weiß gar nicht, ob da mittlerweile schon was gelaufen ist. Werde demnächst berichten. Ich hab in news etwas zum Thema gepostet:   (Du musst Dich Einloggen oder Registrieren 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 am 19.09.07 um 11:51:04: Viprex schrieb am 19.09.07 um 11:21:45: Was heißt: "Kontrolliere den Bits"? Auf den Clients? Was soll ich da wo gucken? Sorry, bin mittlerweile etwas aus dem Thema raus... *omg* Für den Bits gibts eine GUI:   (Du musst Dich Einloggen oder Registrieren  Damit siehst Du ob noch Jobs in Queue sind. Habt ihr den BITS via GPOs eingeschränkt? 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 am 19.09.07 um 11:51:04: Viprex schrieb am 19.09.07 um 11:21:45: Wie sehe ich denn, was vom Client angefordert wird? Muss ich mich da auf allen Clients einzeln durchklicken? Gibts da keine schöne Übersicht? Doch, gibts schon. Siehe angehängtes Bild, gleich in der Übersicht. Oder auch in der Detail Ansicht für die Clients. Besser machst Du das aber in den Update Ansichten. 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 am 19.09.07 um 11:51:04: [quote author=Viprex link=1187867615/0#4 date=1190193705] 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 :P Hamburg ist gut, da bin ich wenn dann eher zu finden. Ich glaub ich muß mal ne Tour in den Norden machen, die Biere sollten für eine Woche reichen. ;-)

Dann mal los!

Viprex schrieb am 20.09.07 um 11:56:10:

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 ;-(

Eine weitere Variante wäre, den administrativen Installationspunkt, sofern ihr einen habt, mit SP3 zu aktualisieren und erneut an die Clients ausrollen.


Viprex schrieb am 20.09.07 um 11:56:10:

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.

Prinzipiell solltest die beiden Dienste WUAUSERV + BITS auf den Clients via GPO einstellen, Du mußt nur den Hinweis von hier beachten:   (Du musst Dich Einloggen oder Registrieren
Steht ein bisschen weiter unten.


Viprex schrieb am 20.09.07 um 11:56:10:

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...)

Wenn Du den Kollegen auch zur bestimmten Uhrzeit das Update verpassen willst, geht das auch. Dann erscheint kein Symbol mehr im Systray, sondern es wird einfach zur vorgegebenen Zeit installiert. Folgende GPO-Einstellung aktivieren: Zugriff auf alle Windows Update Funktionen entfernen. Ist im Benutzerbezogenen Teil zu finden. ;)

Sunny schrieb am 20.09.07 um 12:22:18:

Viprex schrieb am 20.09.07 um 11:56:10: 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. Prinzipiell solltest die beiden Dienste WUAUSERV + BITS auf den Clients via GPO einstellen, Du mußt nur den Hinweis von hier beachten:   (Du musst Dich Einloggen oder Registrieren Steht ein bisschen weiter unten.

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 am 20.09.07 um 12:22:18:

Viprex schrieb am 20.09.07 um 11:56:10: 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...) Wenn Du den Kollegen auch zur bestimmten Uhrzeit das Update verpassen willst, geht das auch. Dann erscheint kein Symbol mehr im Systray, sondern es wird einfach zur vorgegebenen Zeit installiert. Folgende GPO-Einstellung aktivieren: Zugriff auf alle Windows Update Funktionen entfernen. Ist im Benutzerbezogenen Teil zu finden. ;)

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

Viprex schrieb am 21.09.07 um 15:42:59:

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!

Ich meinte, Du kannst die beiden Dienste per GPO auf eine bestimmte Startart einstellen:   (Du musst Dich Einloggen oder Registrieren
Weiters ist darauf zu achten, wenn man das so macht, daß sondern das Konto „DIENST“ mit in die Liste der Berechtigten aufgenommen wird:

******************************
!!! ACHTUNG !!!

Wer die Berechtigungen am Dienst Automatische Updates konfiguriert hat, der kann ein Problem mit Windows XP SP2 bekommen.

Bis zum SP2 werden die Berechtigungen per Default auf „Adminstratoren – Voll“ und „System – Vollzugriff“ eingestellt. (Wenn man diese aktiviert) Ab SP2 ist es aber nicht mehr der „SYSTEM-Account“ unter dem der Dienst gestartet wird, sondern das Konto „DIENST“. Also bitte darauf achten diesen Account in den Berechtigungen einzutragen.
******************************

Laß die 10% einfach so, wenn das Netz sehr schnell ist, hat der Client nach der Benutzeranmeldung eh schon die Updates gedownloadet. Natürlich nur, wenn es kein nagelneuer Client ist, der noch keine Updates hat.

Sunny schrieb am 21.09.07 um 18:01:12:

Viprex schrieb am 21.09.07 um 15:42:59: 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! Ich meinte, Du kannst die beiden Dienste per GPO auf eine bestimmte Startart einstellen:   (Du musst Dich Einloggen oder Registrieren Weiters ist darauf zu achten, wenn man das so macht, daß sondern das Konto „DIENST“ mit in die Liste der Berechtigten aufgenommen wird: ****************************** !!! ACHTUNG !!! Wer die Berechtigungen am Dienst Automatische Updates konfiguriert hat, der kann ein Problem mit Windows XP SP2 bekommen. Bis zum SP2 werden die Berechtigungen per Default auf „Adminstratoren – Voll“ und „System – Vollzugriff“ eingestellt. (Wenn man diese aktiviert) Ab SP2 ist es aber nicht mehr der „SYSTEM-Account“ unter dem der Dienst gestartet wird, sondern das Konto „DIENST“. Also bitte darauf achten diesen Account in den Berechtigungen einzutragen. ****************************** Laß die 10% einfach so, wenn das Netz sehr schnell ist, hat der Client nach der Benutzeranmeldung eh schon die Updates gedownloadet. Natürlich nur, wenn es kein nagelneuer Client ist, der noch keine Updates hat.

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...

Viprex schrieb am 25.09.07 um 11:54:56:

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.

Die sind doch auch noch nicht gedwonloadet worden, oder? Dann stehen sie nur auf einer Liste.


Viprex schrieb am 25.09.07 um 11:54:56:

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 ;-(

Mach ein rsop.msc auf einem Client, der KEINE Updates bekommen sollte. Dort siehst Du welche Richtlinien der Client zieht. Ich tippe auf die Default Domain Policy.



Viprex schrieb am 25.09.07 um 11:54:56:

Darüber hinaus wurde die OU nicht auf die Test Clients übernommen (nach dem Wechsel des interenen Pfads zur Updatequelle).

Hä? Du hast die Clients in die OU verschoben und dann entweder neugestartet oder mittels gpupdate /force die Richtlinie aktualisiert?


Viprex schrieb am 25.09.07 um 11:54:56:

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.

GPEDIT.MSC ist auch nur eine GUI und zeigt nur die Werte an, die Du auch lokal auf dem Client mittels GPEDIT.MSC gesetzt hast. Mit der GPO hat das rein gar nichts zu tun.



Viprex schrieb am 25.09.07 um 11:54:56:

Nur merkwürdig, warum sich da nun einige andere Clients außerdem der Windows Update OU im AD auch am WSUS Server gemeldet haben...

Nochmal, mittels RSOP.MSC auf einem XP Client siehst Du sofort, welche Einstellungen von welcher Richtlinien gezogen werden.

Sunny schrieb am 25.09.07 um 12:49:50:

Viprex schrieb am 25.09.07 um 11:54:56: 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. Die sind doch auch noch nicht gedwonloadet worden, oder? Dann stehen sie nur auf einer Liste.

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 am 25.09.07 um 12:49:50:

Viprex schrieb am 25.09.07 um 11:54:56: 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 ;-( Mach ein rsop.msc auf einem Client, der KEINE Updates bekommen sollte. Dort siehst Du welche Richtlinien der Client zieht. Ich tippe auf die Default Domain Policy.

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 am 25.09.07 um 12:49:50:

Viprex schrieb am 25.09.07 um 11:54:56: Darüber hinaus wurde die OU nicht auf die Test Clients übernommen (nach dem Wechsel des interenen Pfads zur Updatequelle). Hä? Du hast die Clients in die OU verschoben und dann entweder neugestartet oder mittels gpupdate /force die Richtlinie aktualisiert?

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 am 25.09.07 um 12:49:50:

Viprex schrieb am 25.09.07 um 11:54:56: 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. GPEDIT.MSC ist auch nur eine GUI und zeigt nur die Werte an, die Du auch lokal auf dem Client mittels GPEDIT.MSC gesetzt hast. Mit der GPO hat das rein gar nichts zu tun. Viprex schrieb am 25.09.07 um 11:54:56: Nur merkwürdig, warum sich da nun einige andere Clients außerdem der Windows Update OU im AD auch am WSUS Server gemeldet haben... Nochmal, mittels RSOP.MSC auf einem XP Client siehst Du sofort, welche Einstellungen von welcher Richtlinien gezogen werden.

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 ;-(

Viprex schrieb am 25.09.07 um 17:02:20:

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.

Wenn sie abgelehnt sind, kannst Du den Assistenten gleich aufrufen. Dann sollten sie AFAIK weg sein.

Viprex schrieb am 25.09.07 um 17:02:20:

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.

Bitte, gern geschehen. ;)



Viprex schrieb am 25.09.07 um 17:02:20:

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.

Dann kontrolliere doch mal die Einstellungen in der Registry:
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
und natürlich auch in GPEDIT.MSC. Nich daß dir jemand einen Streich gespielt hat. ;)


Viprex schrieb am 25.09.07 um 17:02:20:

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 ;-(

Dann viel Erfolg weiterhin. Bei Fragen zum WSUS weißt Du ja, wohin damit. ;)

Sunny schrieb am 26.09.07 um 00:04:25:

Viprex schrieb am 25.09.07 um 17:02:20: 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. Dann kontrolliere doch mal die Einstellungen in der Registry: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate und natürlich auch in GPEDIT.MSC. Nich daß dir jemand einen Streich gespielt hat. ;)

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?

Viprex schrieb am 26.09.07 um 11:33:25:

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.

Was ist das für ein VB Script? Was steht in der Registry?
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate


Viprex schrieb am 26.09.07 um 11:33:25:

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?

GPEDIT.MSC zeigt dir nur das an, was auch durch gpedit.msc verändert/erstellt wurde.

Nochmal: Welches VB-Script mit welchem Inhalt?
Schau mal ob hier was steht: %Windir%\system32\GroupPolicy



Viprex schrieb am 26.09.07 um 11:33:25:

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.

Aber die neuen Werte können aus der GPO übernommen worden sein.


Viprex schrieb am 26.09.07 um 11:33:25:

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.

Das muss nichts bedeuten. Es gibt viele Möglichkeiten die Konfiguration zu machen. ;)


Viprex schrieb am 26.09.07 um 11:33:25:

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.

Nur an dieser Stelle, und wirklich ausschließlich an dieser Stelle werden normalerweise GPOs angelegt.


Viprex schrieb am 26.09.07 um 11:33:25:

Vielmehr interessiert mich in diesem Zusammenhang aber, warum GPEDIT und RSOP das nciht anzeigen. Worauf greifen GPEDIT und RSOP also zu?

Jetzt hast Du mich kalt erwischt. Ich weiß es ehrlich gesagt nicht.  :( Du kannst in der MS-NG microsoft.public.de.german.windows.gruppenrichtlinien
nachfragen. Dort sitzt der GPO-Gott. ;) Und/oder auch mal auf gruppenrichtlinien.de ein bisschen stöbern.



Viprex schrieb am 26.09.07 um 11:33:25:

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?

Wenn es ein Client innerhalb der Domain ist, solltest Du auf rsop.msc zurückgreifen, bzw. den Richtlinienergibnissatz aufrufen. Alternativ via REGEDIT auf die Registry des Clients zugreifen.

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 am 26.09.07 um 13:44:37:

Was ist das für ein VB Script? Was steht in der Registry? HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

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 am 26.09.07 um 13:44:37:

GPEDIT.MSC zeigt dir nur das an, was auch durch gpedit.msc verändert/erstellt wurde. Nochmal: Welches VB-Script mit welchem Inhalt? Schau mal ob hier was steht: %Windir%\system32\GroupPolicy

Sunny schrieb am 26.09.07 um 13:44:37:

Aber die neuen Werte können aus der GPO übernommen worden sein.

Sunny schrieb am 26.09.07 um 13:44:37:

Nur an dieser Stelle, und wirklich ausschließlich an dieser Stelle werden normalerweise GPOs angelegt.

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 am 05.10.07 um 10:49:51:

So, bin wieder da, habe heute aber den letzten Tag. Dann gehts erstmal zurück ins Studium.

Na dann viel Erfolg beim weiterem Studuim! :)


Viprex schrieb am 05.10.07 um 10:49:51:

Projekt ist mittlerweile im Echtbetrieb, SP2 werden bereits ausgerollt für eine einheitliche Basis.

Das SP2 für W2K3? AFAIK wird das nicht automatisch installiert. Auch wenn es evtl. in der GPO so eingestellt ist.


Viprex schrieb am 05.10.07 um 10:49:51:

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.

Das ist ein kluge Herangehensweise. ;-)



Viprex schrieb am 05.10.07 um 10:49:51:

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

Bitte, gern geschehen. ;)


Viprex schrieb am 05.10.07 um 10:49:51:

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.

OK.



Viprex schrieb am 05.10.07 um 10:49:51:

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.

Ich hab nochmal einen Spezialisten gefragt. Entweder der Wert in der GPT.ini (liegt in C:\WINDOWS\system32\GroupPolicy) erhöht sich und/oder in der passenden Registry.pol in C:\WINDOWS\system32\GroupPolicy\Machine oder C:\WINDOWS\system32\GroupPolicy\User verändert sich ein Wert. Wenn nicht, und das ist bei GPEDIT.MSC der Fall, dann werden die Änderungen nicht in GPEDIT.MSC angezeigt. Ohne Gewähr! ;)

Viprex schrieb am 05.10.07 um 10:49:51:

Tja, interessant ist dann ja aber immer noch, warum GPEDIT und RSOP die Registry nicht mit einbeziehen.

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.