Jump to content

SBS2011: WSUS Serverbereinigung läuft nicht durch


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Jepp, das ist ja Bestandteil der "Komplettlösung" von Bent. Habe das Script aber eben auch immer nur in der Gesamtlösung ausgeführt.
Bringt mich bisher noch nicht recht weiter; die Timeout-Fehler bleiben. Wie bei BumBum auch: WSUS an sich läuft, nur die Bereinigung nicht.

 

Bisher probiert / überprüft:
- Aufräum-Script von Bents Blog

- Löschen der Sync-Historie per SQL-Manager (manuell)

- Ablehnen aller ersetzen Updates (handisch im WSUS)
- Defragmentieren der HDD drunter (geschieht wöchentlich per Task)
- Einzelnes Ausführen der Aufgaben des Bereinigungs-Assis
  (alles ausser Punkt 1 lässt sich in beliebiger Reihe und Kombination ausführen).

 

Ich bleib dran, wenn noch jemand Ideen hat, gerne hier melden.

bearbeitet von Andre.Heisig
Link zu diesem Kommentar

So, Lösung offenbar in Sicht, und sogar recht simpel: Aufräumen!

 

Ich hab gemäß dem dritten Link oben alle

  • abgelaufenen bzw. ersetzten Updates im WSUS gesucht und abgelehnt,
  • definitiv nicht benötigten Updates per manueller Suche (Itanium, ia64, Internet Explorer < Version 8, etc.) im WSUS gesucht und abgelehnt,
  • per Script alle Updates der Kategorie "Treiber" gesucht (gabs bei mir nicht, könnte aber ggf. vorliegen) und ggf. aus der WSUS-DB gelöscht,
  • per Script alle abgelehnten Updates aus der WSUS-DB gelöscht.

Das Löschen der Updates per Script lief 5 Tage permanent durch,
auch mit regelmäßigen TimeOut-Fehlern.

Wiederholung des Laufs nach der ersten "Wäsche" steht noch aus.

 

Update-Pool von knapp 30.000 auf jetzt knapp 9000 Updates reduziert,
und die Server-Bereinigung ist jetzt zumindest einmalig wieder durchgelaufen.
Beim Ablehnen wäre bei genauerer Analyse der noch vorhandenen
Updates sicherlich auch noch Luft, bspw. alte Office-Versionen, etc.

 

Da ich (auch beim "SBS-WSUS" möglich) die Updates nicht im Repository
speichere, sondern direkt bei MS ziehe (mein privates Setup; in Standard-Umgebungen
handhabe ich das selbstredend anders), ist der Festplatten-Platzgewinn zwar
(wie erwartet) überschaubar, aber die WSUS-Datenbank selber läuft nun aber um
einiges flüssiger.

 

Lästig ist das Prozedere aber allemal, und der WSUS-Assi bzw. das automatische
Bereinigungs-Script von Bent's Blog erledigen das Entscheidende, das Ablehnen
nicht (länger) erforderlicher Updates offenbar nicht.

 

@Sunny: Offenbar ist dein Script etwas anders als das von Bent's Blog. Ich sichte
beide nochmal auf Unterschiede; eine Mail bekomme ich von meinem aber nicht.
Beim Öffnen alter Logfiles hab ich aber inzwischen gesehen, dass das Script zwar
durchläuft, aber dort auch schon TimeOut-Fehler geloggt wurden -  das hatte ich
eingangs nicht bemerkt.

bearbeitet von Andre.Heisig
Link zu diesem Kommentar

So, Lösung offenbar in Sicht, und sogar recht simpel: Aufräumen!

Freut mich für Dich und Danke für die Rückmeldung. ;)

 

 

@Sunny: Offenbar ist dein Script etwas anders als das von Bent's Blog. Ich sichte

beide nochmal auf Unterschiede; eine Mail bekomme ich von meinem aber nicht.

 

Dann probier es mit meinem einfach mal aus, das tägliche Mail ist recht nett. ;)

Link zu diesem Kommentar

Tja ... ich würde sagen: Ausgleich in der zweiten Halbzeit durch den WSUS:
Aus den mühselig bereinigten knapp 7.500 Updates in der WSUS-DB sind
ohne aktives Zutun schon wieder gute 11.500 geworden.

 

Denkfehler? Wenn man nach obigen Vorschlägen nicht benötigte Updates
ablehnt, und dann per SQL-Bereinigung diese Updates aus der DB löscht ...
dann müsste der WSUS bei der nächsten Synchronisation doch genau diese
Updates alle als noch nicht geladen wiederfinden ... und wieder ziehen?

 

Ich lass das Ganze jetzt mal noch 2, 3 Tage einfach laufen, mir schwant
aber dass ich wieder auf den alten Pool der 30.000 Updates kommen werde.

 

Reines Ablehnen (und in der DB belassen) verkleinert die WSUS-DB nicht,
ein Ausfiltern der zu (re)syncronisierenden Produkte im Anschluss ans Löschen
bringt die SBS-Konsole ja bekanntlich aus dem Tritt.

 

Und nu?

Link zu diesem Kommentar

Alles richtig, aber das Ausgangsproblem (Timeout-Abbruch beim Bereinigungsassi, und insgesamt spürbar trägere WSUS-MMC) bestand ja eben nicht im Platzbedarf der Updates im Dateisystem, sondern in der DB-Größe!

 

Wie gesagt, in der betrachteten Umgebung verwalte ich die Updates nur per WSUS, die Clients laden aber direkt bei MS (Optionen => Dateien und Sprache => Updatedateien; Randnotiz: diese Abweichung vom Standard-Setting schluckt der SBS 2011 sogar ohne zu Maulen). Die Timeout-Probleme einer ca. 15GB großen WSUS-Datenbank sind gegen Null gegangen, seit die DB nach Bereinigung nur noch <4GB hat. Mein Repository hat sich durch die ganzen Klimmzüge nicht verändert: <15 MB.

 

Wenn ich aber trotz nicht-vorhandenem Update-Repository irgendwann aufgrund der WSUS-Datenbankgröße Performance-Probleme bekomme, muss ich an der Datenbank ansetzen (können). Jetzt stecke ich nicht tief genug in den WSUS-DB-Interna, um beurteilen zu können, ob ein abgelehntes Update dort weniger Datensätze erzeugt/benötigt wird als ein genehmigtes; denn nur dann würde Ablehnen von Updates zu einer Verkleinerung der DB führen. Oder hab ich hier einen grundsätzlichen Denkfehler?

 

Hast Du zum Vergleich mal Eckdaten von einem SBS 2011 WSUS, der ohne explizite Datenbank-Bereinigungen schon eine Weile läuft, und wo der Bereinigungs-Assi noch sauber durchgeht? Anzahl Comuter, Anzahl Updates, Größe Datenbank? Rechner-Eckdaten?

 

Mein SBS: Aufgesetzt Mitte 2012 | 8 verwaltete Computer; 8.000 genehmigte, 3.500 abgelehnte Updates | DB-Größe 3,5 GB. (Vor der Bereinigung ca. 29.000 Updates)
Hardware: HP ML-310 v2; XEON@3,1GHz, 32 GB RAM.

bearbeitet von Andre.Heisig
Link zu diesem Kommentar

Ich selbst betreue keinen SBS2011, kann also keine Referenz heranziehen.

Hast Du denn auf dem WSUS schon http://support.microsoft.com/kb/2938066 installiert? Wenn nein, hol das bitte nach. Anschließend hat der WSUS (2008R2 und kleiner) die Build .274. Den Server danach komplett neu starten.

 

Weshalb brauchst Du bei 8 Clients 8000 genehmigte Updates? Gibt es irgendwelche alten OS-Updates und/oder Office-Updates die abgelehnt werden können? Auch wenn es vorher 29.000 Updates waren sind IMHO die 8.000 immer noch zu viel. Das Reindexierungsscript läuft bei mir einmal in der Woche.

Link zu diesem Kommentar

Das .274er Update fehlt noch. Ich hols nach, von der Beschreibung her fixt das aber andere Löcher.

 

>> Weshalb brauchst Du bei 8 Clients 8000 genehmigte Updates?

Die 8.000 Updates kommen, weil der SBS (konkret: die Update-Statusprüfung in der SBS-Konsole) nicht mehr rund laufen, wenn der WSUS ausserhalb der Standard-Parameter betrieben wird. Dazu gehört auch "alle, auch zukünftige Produkte", sprich ich kann hier nicht wie sonst sinnvoll tatsächlich explizit die Produktlinien wählen, die im Einsatz sind. (Wenn mich einer der SBS-Guru's hier korrigieren mag, gerne! Die Vorgehensweise ist aber meines Wissens die im SBS 2008/2011-Kontext empfohlene).

 

>> Gibt es irgendwelche alten OS-Updates und/oder Office-Updates die abgelehnt werden können?

Die 8.000 stehen ja nach (!) dem massigen Ablehnen, bisher per grober Produkt- (Itanium, Internet Explorer <8, Windows < XP, etc.: alles abgelehnt) und Update-Status- Suche (alle ersetzten Updates: abgelehnt). An der Stelle steht aber meine Kernfrage von oben: Was bewirkt Ablehnen hinsichtlich der SUSDB? Abgelehnte Updates werden ja mit dem Status "abgelehnt" weiter in der DB geführt; das dürfte die Datenbank-Größe insofern kaum beeinflussen. Der dadurch frei werdende Platz im Repository ist (hier) nicht das Problem.

Link zu diesem Kommentar

>> Weshalb brauchst Du bei 8 Clients 8000 genehmigte Updates?

Die 8.000 Updates kommen, weil der SBS (konkret: die Update-Statusprüfung in der SBS-Konsole) nicht mehr rund laufen, wenn der WSUS ausserhalb der Standard-Parameter betrieben wird. Dazu gehört auch "alle, auch zukünftige Produkte", sprich ich kann hier nicht wie sonst sinnvoll tatsächlich explizit die Produktlinien wählen, die im Einsatz sind. (Wenn mich einer der SBS-Guru's hier korrigieren mag, gerne! Die Vorgehensweise ist aber meines Wissens die im SBS 2008/2011-Kontext empfohlene).

 

Hmm, ich kann mir das nicht vorstellen dass der WSUS auf dem SBS, bzw. der SBS mit einer manuellen Korrektur Probleme haben sollte. Da ich selbst aber keinen habe und betreue kann ich das natürlich auch nicht unterschreiben.

 

 

 

 

 

>> Gibt es irgendwelche alten OS-Updates und/oder Office-Updates die abgelehnt werden können?

Die 8.000 stehen ja nach (!) dem massigen Ablehnen, bisher per grober Produkt- (Itanium, Internet Explorer <8, Windows < XP, etc.: alles abgelehnt) und Update-Status- Suche (alle ersetzten Updates: abgelehnt). An der Stelle steht aber meine Kernfrage von oben: Was bewirkt Ablehnen hinsichtlich der SUSDB? Abgelehnte Updates werden ja mit dem Status "abgelehnt" weiter in der DB geführt; das dürfte die Datenbank-Größe insofern kaum beeinflussen. Der dadurch frei werdende Platz im Repository ist (hier) nicht das Problem.

 

Wenn Du z.B. alle alten Updates von XP ablehnst und nach der vollständigen Bereinigung auch das Produkt deaktivierst, wird anschließend natürlich auch in der SUSDB vieles gelöscht. Erst dann wird die SUSDB IMHO kleiner. Ich weiß allerdings nicht was das Tool von Solarwind exakt macht, von daher kann ich auch nur spekulieren. Aber wenn das Reindexierungsscript regelmässig läuft und auch die Synchronsierungshistorie regelmässig gelöscht wird, sollte die Windows Internal Database mit großen Datenbanken eigentlich klar kommen.

Link zu diesem Kommentar

>> Hmm, ich kann mir das nicht vorstellen dass der WSUS auf dem SBS, bzw. der SBS mit einer manuellen Korrektur Probleme haben sollte.

 

Führt bzw. kann dazu führen, dass die SBS -Konsole den Update-Status nicht mehr anzeigt; meldet dann sinngemäß eine "nicht unterstützte Konfiguration".

 

Das hier ist die Anleitung zum Wiederherstellen des SBS-konformen Standards, siehe konkret "manually recover, Punkt 4d: http://technet.microsoft.com/en-us/library/gg680316.aspx

 

(Bitte nicht falsch verstehen: Soll keine Klusc***erei sein; ich kenn die Empfehlung nicht anders und habe beim SBS 2008 selber schon eine abweichende Konfiguration wieder zurückstellen müssen. Ich werd die Tage aber zum Verifizieren meinen SBS 2011 mal bewusst in der Produktliste "verbiegen" und nochmal schauen.

 

Vielleicht kann sich ja einer der SBS-Gurus hier kurz dazu melden ;) ).

Link zu diesem Kommentar

>> Hmm, ich kann mir das nicht vorstellen dass der WSUS auf dem SBS, bzw. der SBS mit einer manuellen Korrektur Probleme haben sollte.

 

Führt bzw. kann dazu führen, dass die SBS -Konsole den Update-Status nicht mehr anzeigt; meldet dann sinngemäß eine "nicht unterstützte Konfiguration".

 

Das hier ist die Anleitung zum Wiederherstellen des SBS-konformen Standards, siehe konkret "manually recover, Punkt 4d: http://technet.microsoft.com/en-us/library/gg680316.aspx

 

(Bitte nicht falsch verstehen: Soll keine Klusc***erei sein; ich kenn die Empfehlung nicht anders und habe beim SBS 2008 selber schon eine abweichende Konfiguration wieder zurückstellen müssen. Ich werd die Tage aber zum Verifizieren meinen SBS 2011 mal bewusst in der Produktliste "verbiegen" und nochmal schauen.

Ich weiß vom vielen mitlesen das der SBS zickig sein kann, deshalb schreib ich ja immer dazu das ich keinen im Einsatz habe. ;)

bearbeitet von Sunny61
Link zu diesem Kommentar
  • 1 Monat später...

Edit:

Oder halt alternativ und 1000 mal einfacher...

 

1. Rechtsklick auf
\\.\pipe\mssql$microsoft##ssee\sql\query
links im Baum (oberstes Element).
2. Wähle "Eigenschaften".
3. Wähle "Verbindungen".
4. Setze "Timeout für Remoteabfragen" auf 0 (= kein Timeout).

 

======================================================================

Letztendlich ist die einfache Lösung die erstgenannte. Das unterhalb lasse ich dennoch stehen, da es einen tieferen Einblick gibt und sich eventuell jemand damit auseinandersetzen möchte. Die investierte Zeit in die u.g. Lösung ist aber irgendwie schade...

======================================================================

 

Hi, du hast ja schon einmal auf so einen Beitrag verwiesen. Ich habe es ausprobiert und erfolgreich abgeschlossen. Deine Aussage, dass man jedes Update manuell löschen muss, ist jedoch nicht korrekt. Es sind nur gewisse Updates, die den Timeout verursachen. Den Rest macht die Serverbereinigung selbst.

Habe selbes auch auf Bents-Blog gepostet - der wurde von dir ja auch schon verlinkt.

 
---------------------------------------------------------------
Lösung für das Timeout-Problem bei WSUS3.0. 
---------------------------------------------------------------
Ich setze SBS2011 ein, ist aber mit Sicherheit auch bei anderen Systemen so.
 
Ursprung des Problems: Keine regelmäßige Wartung der WSUS-Datenbank (SUSDB)
Problem für den Timout: Leistung des Servers (v.a. bei SBS ein Problem, mit Exchange usw.)
Lösung:
1. Maintenance-Script von oben auf dem Server ausführen.
 
2. Serverbereinigung testen, dabei erstmal alle Punkte einzeln ausführen und beobachten, bei welchem Punkt der Timeout auftritt. Das ist vermutlich der oberste Punkt.
 
3. SQL-Server-Manager starten und mit der Datenbank verbinden:
---------------------------------------------------------------
\\.\pipe\mssql$microsoft##ssee\sql\query
---------------------------------------------------------------
 
4. Rechtsklick auf
\\.\pipe\mssql$microsoft##ssee\sql\query
links im Baum (oberstes Element). Wähle "Neue Abfrage".
 
5. Die nicht weiter benötigten Updates abfragen mit
---------------------------------------------------------------
USE SUSDB
GO
exec spGetObsoleteUpdatesToCleanup
---------------------------------------------------------------
 
6. In der Ergebnisliste stehen die Updates mit "LocalUpdateID". Man nehme die erste ID und "löscht" das Update mit dem Kommando
---------------------------------------------------------------
USE SUSDB
GO
exec spDeleteUpdate @localUpdateID=######
---------------------------------------------------------------
wobei ###### natürlich für die "LocalUpdateID" steht. Man kann ebenfalls mehrere Updates "löschen" indem man mehrere Spalten angibt, z.B.
---------------------------------------------------------------
USE SUSDB
GO
exec spDeleteUpdate @localUpdateID=######
exec spDeleteUpdate @localUpdateID=######
exec spDeleteUpdate @localUpdateID=######
---------------------------------------------------------------
 
7. Der Befehl wird dann erfolgreich ausgeführt und man kann die Serverbereinigung erneut testen. 
 
TIPP: Notiert euch am besten die Gesamtzahl der mit unter Punkt 5. aufgelisteten Updates. Falls die Serverbereinigung erneut fehlschlägt, wiederholt das Vorgehen mit dem manuellen Löschen des obersten Updates. Hier solltet ihr feststellen, dass sich die Gesamtzahl der Updates auch durch die Ausführung der Serverbereinigung verringert, nicht nur durch eure manuellen Löschvorgänge!
 
Wer des Englischen mächtig ist, liest einfach noch das hier, da steht das Gleiche:
 
Wenn ihr die Serverbereinigung soweit habt, dass sie überhaupt sichtbar anfängt, ihr also einen kleinen blauen Balken seht, dann dürft ihr euch zurücklehnen und das Ding laufen lassen. Auch wenn ich keine Erklärung dafür habe, sobald ich etwas blaues gesehen habe, gab es bei meinen (ingesamt 7 WSUS)  Maschinen keinen Timeout mehr. Meine Minimumzeiten für etwa 6000 "obsolete Updates" liegen bei 23 Stunden, meine Maximalzeiten bei 46 Stunden.
 
Grüße
bearbeitet von ente_0815
Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...