14
WSUS SUSDB File verkleinern
Moin,
Die SQL Profis wissen sicher sofort bescheid. Da gehöre ich allerdings nicht zu.
Konkret wird mir die Datenbank eines Wsus zu groß oder ich interpretiere die Anzeigen im Manager schlicht falsch. (Siehe Screenshot)
Ist es nun so das dieses DB File 36gb groß ist und nicht mal 1% davon tatsächlich genutzt wird?
Wenn ich den Shrink wie in dem Screenshot angegeben ausführe, dann schließt sich das Fenster und es ändert sich rein gar nichts.
Möchte ich allerdings die dritte Option (Migration der Dateien) nutzen, so bekomme ich die Fehlermeldung die "Primary" Dateigruppe hätte nicht genug Platz.
(Ich denke ich brauch nicht zu sagen, dass es in der Konsole identisch ausschaut)
Gibt es noch weitere Optionen wie ich die Datenbank wieder kleiner bekomme falls diese wirklich so "leer" sein sollte?
Gruß
Spirit
Die SQL Profis wissen sicher sofort bescheid. Da gehöre ich allerdings nicht zu.
Konkret wird mir die Datenbank eines Wsus zu groß oder ich interpretiere die Anzeigen im Manager schlicht falsch. (Siehe Screenshot)
Ist es nun so das dieses DB File 36gb groß ist und nicht mal 1% davon tatsächlich genutzt wird?
Wenn ich den Shrink wie in dem Screenshot angegeben ausführe, dann schließt sich das Fenster und es ändert sich rein gar nichts.
Möchte ich allerdings die dritte Option (Migration der Dateien) nutzen, so bekomme ich die Fehlermeldung die "Primary" Dateigruppe hätte nicht genug Platz.
(Ich denke ich brauch nicht zu sagen, dass es in der Konsole identisch ausschaut)
Gibt es noch weitere Optionen wie ich die Datenbank wieder kleiner bekomme falls diese wirklich so "leer" sein sollte?
Gruß
Spirit
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2730652169
Url: https://administrator.de/contentid/2730652169
Ausgedruckt am: 23.11.2024 um 07:11 Uhr
14 Kommentare
Neuester Kommentar
Moin,
habe den letzten Beitrag gelöscht, weil ich es nicht richtig verstanden habe. Daher jetzt nochmal richtig:
Frei nach diesem Link
Schritt 3 ausgeführt? Das verkleinern der Datenbank funktioniert nur, wenn der WUSS Dienst via ISS gestoppt wurde.
Gruß
Doskias
habe den letzten Beitrag gelöscht, weil ich es nicht richtig verstanden habe. Daher jetzt nochmal richtig:
Frei nach diesem Link
Schritt 3 ausgeführt? Das verkleinern der Datenbank funktioniert nur, wenn der WUSS Dienst via ISS gestoppt wurde.
Gruß
Doskias
Zitat von @Doskias:
Moin,
habe den letzten Beitrag gelöscht, weil ich es nicht richtig verstanden habe. Daher jetzt nochmal richtig:
Frei nach diesem Link
Schritt 3 ausgeführt? Das verkleinern der Datenbank funktioniert nur, wenn der WUSS Dienst via ISS gestoppt wurde.
Gruß
Doskias
Moin,
habe den letzten Beitrag gelöscht, weil ich es nicht richtig verstanden habe. Daher jetzt nochmal richtig:
Frei nach diesem Link
Schritt 3 ausgeführt? Das verkleinern der Datenbank funktioniert nur, wenn der WUSS Dienst via ISS gestoppt wurde.
Gruß
Doskias
Ich habe es gerade explizit nochmal getestet. Das macht hier keinen Unterschied. Vorher hatte allerdings schon den Wsus-Dienst gestoppt.
Die Frage ist halt wie ich die DB reorganisieren kann. Dieser Prozess scheint nicht zu funktionieren.
Moin Spirit,
du interpretierst die Anzeige schon richtig, ich befürchte nur, dass diese dich bezüglich des freien Speicherplatzes, gewaltig anschwindelt. 36GB sind für eine WSUS DB nichts besonderes. Ich war dem Letzt erst auf einem WSUS, dessen DB schon die 60G durchbrochen hatte. 🙃
Ist deine SUSDB eine WID, eine Express oder eine erwachsene SQL Datenbank?
Das hört sich gewaltig nach einem SQL-Express an.
Die hat eine Grössenbeschränkung auf 10G und genau da scheinst du dagegen zu knallen. ☹
Und ja, leider kann eine SQL-Express-SUSDB, warum auch immer, vom WSUS auf über 10G aufgebläht werden,
danach kannst du diese mit den normalen SQL-Werkzeugen, jedoch so gut wie nicht verwalten.
Das ist wahrscheinlich auch der Grund, warum du die DB nicht verkleinern kannst.
Wenn das wirklich eine SQL-Express-DB ist, dann kannst du entweder den SQL von Express auf Standard Upgraden,
was jedoch mit Unkosten im 4 stelligen Bereich verbunden ist.
Oder du migrierst die DB auf einen eventuell bestehenden Standard SQL Server, dabei muss dessen bestehende Lizenzierung auch genau geprüft werden, ob für den WSUS Betrieb überhaupt ausreichend.
Oder du setzt den WSUS komplett neu auf, dieses mal aber mit einer WID und nicht mit einer SQL-Express.
Im Gegensatz zu einer SQL-Express, hat eine WID keine Grössenbeschränkung. 😉
Beste Grüsse aus BaWü
Alex
Konkret wird mir die Datenbank eines Wsus zu groß oder ich interpretiere die Anzeigen im Manager schlicht falsch. (Siehe Screenshot)
Ist es nun so das dieses DB File 36gb groß ist und nicht mal 1% davon tatsächlich genutzt wird?
du interpretierst die Anzeige schon richtig, ich befürchte nur, dass diese dich bezüglich des freien Speicherplatzes, gewaltig anschwindelt. 36GB sind für eine WSUS DB nichts besonderes. Ich war dem Letzt erst auf einem WSUS, dessen DB schon die 60G durchbrochen hatte. 🙃
Wenn ich den Shrink wie in dem Screenshot angegeben ausführe, dann schließt sich das Fenster und es ändert sich rein gar nichts.
Ist deine SUSDB eine WID, eine Express oder eine erwachsene SQL Datenbank?
Möchte ich allerdings die dritte Option (Migration der Dateien) nutzen, so bekomme ich die Fehlermeldung die "Primary" Dateigruppe hätte nicht genug Platz.
(Ich denke ich brauch nicht zu sagen, dass es in der Konsole identisch ausschaut)
(Ich denke ich brauch nicht zu sagen, dass es in der Konsole identisch ausschaut)
Das hört sich gewaltig nach einem SQL-Express an.
Die hat eine Grössenbeschränkung auf 10G und genau da scheinst du dagegen zu knallen. ☹
Und ja, leider kann eine SQL-Express-SUSDB, warum auch immer, vom WSUS auf über 10G aufgebläht werden,
danach kannst du diese mit den normalen SQL-Werkzeugen, jedoch so gut wie nicht verwalten.
Das ist wahrscheinlich auch der Grund, warum du die DB nicht verkleinern kannst.
Gibt es noch weitere Optionen wie ich die Datenbank wieder kleiner bekomme falls diese wirklich so "leer" sein sollte?
Wenn das wirklich eine SQL-Express-DB ist, dann kannst du entweder den SQL von Express auf Standard Upgraden,
was jedoch mit Unkosten im 4 stelligen Bereich verbunden ist.
Oder du migrierst die DB auf einen eventuell bestehenden Standard SQL Server, dabei muss dessen bestehende Lizenzierung auch genau geprüft werden, ob für den WSUS Betrieb überhaupt ausreichend.
Oder du setzt den WSUS komplett neu auf, dieses mal aber mit einer WID und nicht mit einer SQL-Express.
Im Gegensatz zu einer SQL-Express, hat eine WID keine Grössenbeschränkung. 😉
Beste Grüsse aus BaWü
Alex
Moin
was jedoch mit Unkosten im 4 stelligen Bereich verbunden ist.
Oder du migrierst die DB auf einen eventuell bestehenden Standard SQL Server, dabei muss dessen bestehende Lizenzierung auch genau geprüft werden, ob für den WSUS Betrieb überhaupt ausreichend.
Oder du setzt den WSUS komplett neu auf, dieses mal aber mit einer WID und nicht mit einer SQL-Express.
Im Gegensatz zu einer SQL-Express, hat eine WID keine Grössenbeschränkung. 😉
Wenn es "wirklich" daran liegt, dass der WSUS die SQl-Express Grenze gesprengt hat, dann kannst du auch noch folgendes versuchen:
DBCC Shrinkdatabase via OSQL direkt aus der CMD. Das hat mir früher oft geholfen wenn die SQL-Express-Größe erreicht war und die Management-Konsole die Datenbank nicht mehr verkleinern konnte.
Gruß
Doskias
Zitat von @MysticFoxDE:
Moin Spirit,
du interpretierst die Anzeige schon richtig, ich befürchte nur, dass diese dich bezüglich des freien Speicherplatzes, gewaltig anschwindelt. 36GB sind für eine WSUS DB nichts besonderes. Ich war dem Letzt erst auf einem WSUS, dessen DB schon die 60G durchbrochen hatte. 🙃
Da befürchte ich aber, dass bei deinem WSUS was nicht richtig läuft. Ich hab gestern mit dem Link die WSUS-DB von 5 GB auf 4 GB verkleinert und das bei 367 GB an WSUS-Updates, die tatsächlich gebraucht werden. Bereinigung erfolgt und keine ersetzten Updates mehr vorhanden. Wenn deine DB 60 GB Groß ist, solltest du vielleicht mal deine Updates bereinigen?Moin Spirit,
du interpretierst die Anzeige schon richtig, ich befürchte nur, dass diese dich bezüglich des freien Speicherplatzes, gewaltig anschwindelt. 36GB sind für eine WSUS DB nichts besonderes. Ich war dem Letzt erst auf einem WSUS, dessen DB schon die 60G durchbrochen hatte. 🙃
Gibt es noch weitere Optionen wie ich die Datenbank wieder kleiner bekomme falls diese wirklich so "leer" sein sollte?
Wenn das wirklich eine SQL-Express-DB ist, dann kannst du entweder den SQL von Express auf Standard Upgraden,was jedoch mit Unkosten im 4 stelligen Bereich verbunden ist.
Oder du migrierst die DB auf einen eventuell bestehenden Standard SQL Server, dabei muss dessen bestehende Lizenzierung auch genau geprüft werden, ob für den WSUS Betrieb überhaupt ausreichend.
Oder du setzt den WSUS komplett neu auf, dieses mal aber mit einer WID und nicht mit einer SQL-Express.
Im Gegensatz zu einer SQL-Express, hat eine WID keine Grössenbeschränkung. 😉
Wenn es "wirklich" daran liegt, dass der WSUS die SQl-Express Grenze gesprengt hat, dann kannst du auch noch folgendes versuchen:
DBCC Shrinkdatabase via OSQL direkt aus der CMD. Das hat mir früher oft geholfen wenn die SQL-Express-Größe erreicht war und die Management-Konsole die Datenbank nicht mehr verkleinern konnte.
Gruß
Doskias
Moin Doskias,
Die Grösse der SUSDB hat schon Ihre Gründe.
Die WSUSe unserer Kunden verteilen nicht nur Updates sondern unter anderem auch Treiber und
das Letztere bläht die Datenbank halt besonders gerne auf.
Das Bereinigen des WSUS Servers verkleinert übrigens nicht automatisch die SUS-DB.
Beste Grüsse aus BaWü
Alex
Da befürchte ich aber, dass bei deinem WSUS was nicht richtig läuft. Ich hab gestern mit dem Link die WSUS-DB von 5 GB auf 4 GB verkleinert und das bei 367 GB an WSUS-Updates, die tatsächlich gebraucht werden. Bereinigung erfolgt und keine ersetzten Updates mehr vorhanden. Wenn deine DB 60 GB Groß ist, solltest du vielleicht mal deine Updates bereinigen?
Die Grösse der SUSDB hat schon Ihre Gründe.
Die WSUSe unserer Kunden verteilen nicht nur Updates sondern unter anderem auch Treiber und
das Letztere bläht die Datenbank halt besonders gerne auf.
Das Bereinigen des WSUS Servers verkleinert übrigens nicht automatisch die SUS-DB.
Beste Grüsse aus BaWü
Alex
Moin
Ich persönlich würde die Datenbank auch nicht regelmäßig verkleinern. Wenn der Speicher passt, dann ist es egal ob die zu 80,90 oder 100% gefüllt sind. Da ist immer etwas Bewegung drin.
Gruß
Doskias
Zitat von @MysticFoxDE:
Das Bereinigen des WSUS Servers verkleinert übrigens nicht automatisch die SUS-DB.
Das ist korrekt, aber veraltete und ersetze Updates, die nicht abgelehnt werden belegen weiterhin Festplattenspeicher, was wiederum zu einer überfüllten Datenbank führt. Hab ich neulich selbst erst gelernt, dass die automatisch Ablehnung nur bei automatischer Genehmigung funktioniert und manuell freigegebene Updates auch manuell abgelehnt werden müssen. Das hat bei uns den WSUS ziemlich aufgebläht.Das Bereinigen des WSUS Servers verkleinert übrigens nicht automatisch die SUS-DB.
Ich persönlich würde die Datenbank auch nicht regelmäßig verkleinern. Wenn der Speicher passt, dann ist es egal ob die zu 80,90 oder 100% gefüllt sind. Da ist immer etwas Bewegung drin.
Gruß
Doskias
Moin Doskias,
ach, so viele genehmigte oder abgelehnte Updates sind da gar nicht drauf.
Das ist eher den Client (W7-W11) und Server(2003-2022), plus diverse SQL's, und diverse .NET Studio Versionen & Co Zoo geschuldet und natürlich den Treiberupdates.
Gruss Alex
Das ist korrekt, aber veraltete und ersetze Updates, die nicht abgelehnt werden belegen weiterhin Festplattenspeicher, was wiederum zu einer überfüllten Datenbank führt.
ach, so viele genehmigte oder abgelehnte Updates sind da gar nicht drauf.
Das ist eher den Client (W7-W11) und Server(2003-2022), plus diverse SQL's, und diverse .NET Studio Versionen & Co Zoo geschuldet und natürlich den Treiberupdates.
Gruss Alex
Also ich würde ja die 798504 Updates mal überprüfen. Gibt kaum einen Grund für die Menge. Das macht das ganze doch nur unübersichtlich. Entweder du brauchst sie nicht, oder du willst sie nicht. Bei mir sieht es so aus:
Ähnliche Client-Konstellation wie bei dir: Win 7 bis Win 10. Server 2003 bis 2019. Allerdings ohne Treiberupdates 
Gruß
Doskias
Gruß
Doskias
Zitat von @MysticFoxDE:
Moin Spirit,
du interpretierst die Anzeige schon richtig, ich befürchte nur, dass diese dich bezüglich des freien Speicherplatzes, gewaltig anschwindelt. 36GB sind für eine WSUS DB nichts besonderes. Ich war dem Letzt erst auf einem WSUS, dessen DB schon die 60G durchbrochen hatte. 🙃
Ist deine SUSDB eine WID, eine Express oder eine erwachsene SQL Datenbank?
Moin Spirit,
Konkret wird mir die Datenbank eines Wsus zu groß oder ich interpretiere die Anzeigen im Manager schlicht falsch. (Siehe Screenshot)
Ist es nun so das dieses DB File 36gb groß ist und nicht mal 1% davon tatsächlich genutzt wird?
du interpretierst die Anzeige schon richtig, ich befürchte nur, dass diese dich bezüglich des freien Speicherplatzes, gewaltig anschwindelt. 36GB sind für eine WSUS DB nichts besonderes. Ich war dem Letzt erst auf einem WSUS, dessen DB schon die 60G durchbrochen hatte. 🙃
Wenn ich den Shrink wie in dem Screenshot angegeben ausführe, dann schließt sich das Fenster und es ändert sich rein gar nichts.
Ist deine SUSDB eine WID, eine Express oder eine erwachsene SQL Datenbank?
Es handelt sich hier tatsächlich um einen normalen SQL Server. Ich habe die DB irgend wann von einer WID Installation wegmigriert. Vor zwei Jahren hat der Wsus schonmal Probleme gemacht und es ist in einer Neuinstallation geendet. Das kann aus meiner Sicht nicht die Lösung sein.
Diese Instanz läuft quasi standalone. Eine andere wir durchweg per SCCM verwaltet. Da benötigt der Wsus sogar weniger Ressourcen damit die Console selbst nicht abschmiert. Hier frisst die Wsus VM gern 25gb RAM. Unglaublich.
Bei geringer RAM Zuweisung baut die Console gar keine Verbindung mehr auf und Clients können nicht syncen.
Möchte ich allerdings die dritte Option (Migration der Dateien) nutzen, so bekomme ich die Fehlermeldung die "Primary" Dateigruppe hätte nicht genug Platz.
(Ich denke ich brauch nicht zu sagen, dass es in der Konsole identisch ausschaut)
(Ich denke ich brauch nicht zu sagen, dass es in der Konsole identisch ausschaut)
Das hört sich gewaltig nach einem SQL-Express an.
Die hat eine Grössenbeschränkung auf 10G und genau da scheinst du dagegen zu knallen. ☹
Und ja, leider kann eine SQL-Express-SUSDB, warum auch immer, vom WSUS auf über 10G aufgebläht werden,
danach kannst du diese mit den normalen SQL-Werkzeugen, jedoch so gut wie nicht verwalten.
Das ist wahrscheinlich auch der Grund, warum du die DB nicht verkleinern kannst.
Gibt es noch weitere Optionen wie ich die Datenbank wieder kleiner bekomme falls diese wirklich so "leer" sein sollte?
Wenn das wirklich eine SQL-Express-DB ist, dann kannst du entweder den SQL von Express auf Standard Upgraden,
was jedoch mit Unkosten im 4 stelligen Bereich verbunden ist.
Oder du migrierst die DB auf einen eventuell bestehenden Standard SQL Server, dabei muss dessen bestehende Lizenzierung auch genau geprüft werden, ob für den WSUS Betrieb überhaupt ausreichend.
Oder du setzt den WSUS komplett neu auf, dieses mal aber mit einer WID und nicht mit einer SQL-Express.
Im Gegensatz zu einer SQL-Express, hat eine WID keine Grössenbeschränkung. 😉
Ich bin absichtlich auf eine SQL Instanz ausgewichen um die Performance zu testen da es andauern mit dem Stück Software Probleme gab. Wahrscheinlich sollte ich doch wieder eine WID nutzen.
Aber irgendwie muss man doch die Console vernünftig flott bekommen.
Ich habe so ziemlich alles an Optimierungen durchgeführt. Z.b. war dabei dein Tutorial sehr hilfreich.
Ich habe nachher sogar für alles Tasks erstellt welche an unterschiedlichen Tagen der Woche den Server aufräumen und Bspw. unneeded Updates rauswirft und die Datenbank reindexiert.
Mit dem Verkleinern der DB wollte ich testen ob dies dann Einfluss auf die Performance hat.
Es kann ja nicht sein, dass man so viel Zeit in die Betreuung eines Wsus Servers stecken muss.
Beste Grüsse aus BaWü
Alex
Mein Serverstatistik ist in diesem Fall recht human da hier nicht viele Produkte verwaltet werden.
Moin Doskias,
Doch den Gibt es und das sind die Treiber-Updates, deshalb wirst du auch duzende Seiten im Internet finden,
wo dir absolut davon abgeraten wird, diese beim WSUS für die Synchronisierung zu aktivieren,
weil dadurch die SUS-DB um Faktoren aufgebläht wird, was wiederum den meisten Usern ohne zutuen, unweigerlich zum Stillstand des WSUS Servers führt, weil dessen Datenbank an manchen Stellen einfach nur grottig indiziert ist. 🤮
Aber dagegen gibt es zum Glück ein kleines Heilmittelchen.
WSUS Stabilisierung und Performanceoptimierung
😉
Doch, ich brauche sie und ich will sie und du übrigens auch, oder willst du mir ernsthaft erzählen,
dass du die ganzen Treiber-Updates von Hand auf den Clients nachziehst.
Wenn dein WSUS auf einer WID läuft, dann hau die Indexe rein und aktiviere in deinem WSUS mal die Treiber. 😎
Beste Grüsse aus BaWü
Alex
Also ich würde ja die 798504 Updates mal überprüfen. Gibt kaum einen Grund für die Menge.
Doch den Gibt es und das sind die Treiber-Updates, deshalb wirst du auch duzende Seiten im Internet finden,
wo dir absolut davon abgeraten wird, diese beim WSUS für die Synchronisierung zu aktivieren,
weil dadurch die SUS-DB um Faktoren aufgebläht wird, was wiederum den meisten Usern ohne zutuen, unweigerlich zum Stillstand des WSUS Servers führt, weil dessen Datenbank an manchen Stellen einfach nur grottig indiziert ist. 🤮
Aber dagegen gibt es zum Glück ein kleines Heilmittelchen.
WSUS Stabilisierung und Performanceoptimierung
😉
Das macht das ganze doch nur unübersichtlich. Entweder du brauchst sie nicht, oder du willst sie nicht.
Doch, ich brauche sie und ich will sie und du übrigens auch, oder willst du mir ernsthaft erzählen,
dass du die ganzen Treiber-Updates von Hand auf den Clients nachziehst.
Allerdings ohne Treiberupdates
Wenn dein WSUS auf einer WID läuft, dann hau die Indexe rein und aktiviere in deinem WSUS mal die Treiber. 😎
Beste Grüsse aus BaWü
Alex
Moin Spirit-of-eli,
OK, sind der SQL und die SSMS auf dem neusten Stand?
Nur 25GB, süss, wir fahren die WSUS Server bei den Kunden mittlerweile mit 32-64GB RAM. 🙃
Ja, ist ne Menge, aber ohne einen WSUS dem ganzen Update-Theater einzeln hinterherzurennen, ist auch nicht besser.
😮, was dem WSUS RAM wegnehmen, das hast du jetzt aber nicht wirklich gemacht.
Da wird dieser schnell ganz zickig, aber das hast du ja selber schon gemerkt.
Der erwachsene SQL ist der WID auf jeden Fall performancetechnisch überlegen.
Wenn du wieder auf die WID gehst, dann musst du auf jeden Fall mit Einbußen rechnen.
Das hört sich danach an, als ob du den IIS noch nicht optimiert hast.
In der Materie ist mein Kollege jedoch fitter wie ich.
Ich frage ihn mal morgen, was er diesbezüglich bei den aktuellen WSUS-Installationen alles optimieren muss.
Zeit und WSUS, ja das ist schon eine sehr schräge Geschichte, der ich nicht nur eine IT-Narbe zu verdanken habe.
Beste Grüsse aus BaWü
Alex
Es handelt sich hier tatsächlich um einen normalen SQL Server.
OK, sind der SQL und die SSMS auf dem neusten Stand?
Diese Instanz läuft quasi standalone. Eine andere wir durchweg per SCCM verwaltet. Da benötigt der Wsus sogar weniger Ressourcen damit die Console selbst nicht abschmiert. Hier frisst die Wsus VM gern 25gb RAM. Unglaublich.
Nur 25GB, süss, wir fahren die WSUS Server bei den Kunden mittlerweile mit 32-64GB RAM. 🙃
Ja, ist ne Menge, aber ohne einen WSUS dem ganzen Update-Theater einzeln hinterherzurennen, ist auch nicht besser.
Bei geringer RAM Zuweisung baut die Console gar keine Verbindung mehr auf und Clients können nicht syncen.
😮, was dem WSUS RAM wegnehmen, das hast du jetzt aber nicht wirklich gemacht.
Da wird dieser schnell ganz zickig, aber das hast du ja selber schon gemerkt.
Ich bin absichtlich auf eine SQL Instanz ausgewichen um die Performance zu testen da es andauern mit dem Stück Software Probleme gab. Wahrscheinlich sollte ich doch wieder eine WID nutzen.
Der erwachsene SQL ist der WID auf jeden Fall performancetechnisch überlegen.
Wenn du wieder auf die WID gehst, dann musst du auf jeden Fall mit Einbußen rechnen.
Aber irgendwie muss man doch die Console vernünftig flott bekommen.
Das hört sich danach an, als ob du den IIS noch nicht optimiert hast.
In der Materie ist mein Kollege jedoch fitter wie ich.
Ich frage ihn mal morgen, was er diesbezüglich bei den aktuellen WSUS-Installationen alles optimieren muss.
Es kann ja nicht sein, dass man so viel Zeit in die Betreuung eines Wsus Servers stecken muss.
Zeit und WSUS, ja das ist schon eine sehr schräge Geschichte, der ich nicht nur eine IT-Narbe zu verdanken habe.
Beste Grüsse aus BaWü
Alex
Zitat von @MysticFoxDE:
Das hört sich danach an, als ob du den IIS noch nicht optimiert hast.
In der Materie ist mein Kollege jedoch fitter wie ich.
Ich frage ihn mal morgen, was er diesbezüglich bei den aktuellen WSUS-Installationen alles optimieren muss.
Zeit und WSUS, ja das ist schon eine sehr schräge Geschichte, der ich nicht nur eine IT-Narbe zu verdanken habe.
Beste Grüsse aus BaWü
Alex
Das hört sich danach an, als ob du den IIS noch nicht optimiert hast.
In der Materie ist mein Kollege jedoch fitter wie ich.
Ich frage ihn mal morgen, was er diesbezüglich bei den aktuellen WSUS-Installationen alles optimieren muss.
Es kann ja nicht sein, dass man so viel Zeit in die Betreuung eines Wsus Servers stecken muss.
Zeit und WSUS, ja das ist schon eine sehr schräge Geschichte, der ich nicht nur eine IT-Narbe zu verdanken habe.
Beste Grüsse aus BaWü
Alex
Auf jeden Fall Danke für deine Rückmeldung.
Wenn du bezüglich der IIS Optimierung ggf noch etwas in Erfahrung bringen kannst, wäre ich dir Dankbar und dies könnte auch seinen Platz in deinem HowTo finden.
Derzeit ist es so, wenn der "PrivatMemory" Wert nicht auf 0 steht, ist kein Sync möglich. Selbst wenn der Wert fest auf z.B. 20gb gestellt wird.
Moin
Wenn du sie brauchst und willst, dann müssten sie aber genehmigt sein. Im nicht genehmigten Zustand ist das doch nicht zielführend. Wenn du die Updates brauchst, dann genehmigen. Wenn du die Updates nicht brauchst, dann ablehnen. Völlig egal was das ist. Ob Treiber, Sicherheitsupdate oder welche Klassifizierung es auch immer ist. Es sollte möglichst bei jedem Eintrag entscheiden werden ob man es braucht (genehmigt) oder nicht braucht (abgelehnt). Mich stört nicht die Anzahl, mich stört nur, dass die Anzahl auf nicht genehmigt steht und nicht auf abgelehnt/genehmigt.
Wir haben derzeit 128 Updates in unserem WSUS mit dem Status nicht genehmigt und die sind alle vom 10.05.2022. Alle Älteren Updates sind entweder genehmigt oder abgelehnt. Das hilft dann bei der Übersicht ganz gut. Bei mehr als 700.000 Objekten, wäre mit persönlich das ganze zu unübersichtlich.
. Wir haben einige Clients wo CAD-Programme laufen, die nur mit ganz speziellen Treibern funktionieren. Die Treiber müssen eine bestimmte Version haben und ein Update der Treiber führt dazu, dass die CAD-Programme das Ergebnis nicht mehr richtig darstellen können. Deswegen werden bei dieser Kategorie an Rechnern die Treiber eigentlich gar nicht aktualisiert.
Ansonsten werden auf den Rechnern ohne CAD-Programme, die Treiber automatisch installiert, aber halt nicht über den WSUS. Je nach Hersteller gibt es da Tools (HP hat den HP Support Assistenten, Fujitsu das Fujitsu DeskUpdate, etc.) die auf den Clients installiert sind. Die kümmern sich um die Treiber mit dem Vorteil, dass sie (a) nur die Treiber installieren, wo der Hersteller sagt, dass sie passen und nicht MS der Meinung ist, dass sie passen müssten und (b) auch die BIOS-Updates dort mit dazu gehören. Die entsprechenden Tools laufen regelmäßig, so dass dies bewusst nicht über den WSUS läuft.
Wie gesagt: Unser WSUS macht aus gutem Grund keine Treiber
Gruß
Doskias
Zitat von @MysticFoxDE:
Doch den Gibt es und das sind die Treiber-Updates, deshalb wirst du auch duzende Seiten im Internet finden,
wo dir absolut davon abgeraten wird, diese beim WSUS für die Synchronisierung zu aktivieren,
weil dadurch die SUS-DB um Faktoren aufgebläht wird, was wiederum den meisten Usern ohne zutuen, unweigerlich zum Stillstand des WSUS Servers führt, weil dessen Datenbank an manchen Stellen einfach nur grottig indiziert ist. 🤮
Da hast du mich missverstanden glaube ich. Natürlich können das die Treiber sein, aber es sind nicht genehmigte Updates.Also ich würde ja die 798504 Updates mal überprüfen. Gibt kaum einen Grund für die Menge.
Doch den Gibt es und das sind die Treiber-Updates, deshalb wirst du auch duzende Seiten im Internet finden,
wo dir absolut davon abgeraten wird, diese beim WSUS für die Synchronisierung zu aktivieren,
weil dadurch die SUS-DB um Faktoren aufgebläht wird, was wiederum den meisten Usern ohne zutuen, unweigerlich zum Stillstand des WSUS Servers führt, weil dessen Datenbank an manchen Stellen einfach nur grottig indiziert ist. 🤮
Das macht das ganze doch nur unübersichtlich. Entweder du brauchst sie nicht, oder du willst sie nicht.
Doch, ich brauche sie und ich will sie [...]Wir haben derzeit 128 Updates in unserem WSUS mit dem Status nicht genehmigt und die sind alle vom 10.05.2022. Alle Älteren Updates sind entweder genehmigt oder abgelehnt. Das hilft dann bei der Übersicht ganz gut. Bei mehr als 700.000 Objekten, wäre mit persönlich das ganze zu unübersichtlich.
und du übrigens auch, oder willst du mir ernsthaft erzählen, dass du die ganzen Treiber-Updates von Hand auf den Clients nachziehst.
Ja mach ich . Wir haben einige Clients wo CAD-Programme laufen, die nur mit ganz speziellen Treibern funktionieren. Die Treiber müssen eine bestimmte Version haben und ein Update der Treiber führt dazu, dass die CAD-Programme das Ergebnis nicht mehr richtig darstellen können. Deswegen werden bei dieser Kategorie an Rechnern die Treiber eigentlich gar nicht aktualisiert.Ansonsten werden auf den Rechnern ohne CAD-Programme, die Treiber automatisch installiert, aber halt nicht über den WSUS. Je nach Hersteller gibt es da Tools (HP hat den HP Support Assistenten, Fujitsu das Fujitsu DeskUpdate, etc.) die auf den Clients installiert sind. Die kümmern sich um die Treiber mit dem Vorteil, dass sie (a) nur die Treiber installieren, wo der Hersteller sagt, dass sie passen und nicht MS der Meinung ist, dass sie passen müssten und (b) auch die BIOS-Updates dort mit dazu gehören. Die entsprechenden Tools laufen regelmäßig, so dass dies bewusst nicht über den WSUS läuft.
Allerdings ohne Treiberupdates
Wenn dein WSUS auf einer WID läuft, dann hau die Indexe rein und aktiviere in deinem WSUS mal die Treiber. 😎Gruß
Doskias
