SQL Server Lizenzierung für WSUS
Edit:
Ich habe leider soeben erst gesehen, das @NordicMike heute schon eine ähnliche Frage platziert hat:
Indirekte SQL Lizenzierung
Hi,
weiß jemand, welche Lizenzen fällig werden, wenn man einen MS SQL Server ausschließlich für einen WSUS Server verwenden will?
Hintergrund ist, dass wir seit ca. 3 Wochen Probleme mit der Synchronisation unserer Downstream Server haben.
Wir haben - seit Jahren - einen WSUS Server in der Zentrale und ca. 10 Replica Downstream Server an den Standorten, welche sich jeweils von diesem zentralen Server synchronisieren. Die Datenbanken sind alle jeweils >30 GB. Der zentrale Server nutzt einen vorhandenen MS SQL Failovercluster. Die Downstream Server nutzen jeweils ihre lokale WID.
Die tägliche Synchronisation der Downstream Server steigt jeweils bei 99% und nach ca. 20-22 Minuten aus, mit Fehler
Vorweg genommen:
Wir kennen die "Tricks" mit dem regelmäßigen Aufräumen der Datenbanken, haben nur die tatsächlich benötigten Updates freigegeben, laden nur genehmigte Inhalte herunter. Tipps in dieser Richtung bringen uns also nicht weiter.
Und bitte nicht verwechseln: Es geht um die DB, nicht um die Dateien. Der Content Download vom zentralen Server auf die Downstream Server funktioniert immer noch. Dieser läuft ja auch nachgeordert zur Synchronisation der DB.
Wir haben auch keine Probleme mit fehlendem Festplattenplatz oder CPU/RAM. Die Synchronisationen liefen bis Anfang Juni tadellos. Doch dann sind plötzlich alle Downstream Server mit dieser o.g. Fehlermeldung ausgestiegen. Ich vermute, dass wir zu diesem Zeitpunkt die 30 GB DB-Größe überschritten hatten. So genau kann ich das jetzt nicht mehr belegen.
Es schien naheliegend, dass es am zentralen Server liegen müsste, weil dieser das gemeinsame Element aller Server ist. Aber die o.g. Fehlermeldung bezieht sich auf die eigene DB des jeweiligen Downstream Servers. Diese greifen nicht direkt auf die DB des Upstream Servers zu.
Also habe ich experimentiert und an 3 Downstream Servern folgende Prozedur reproduzieren können:
Die Synchronisation vom Upstream Server läuft auch mit der WID fehlerfrei, wenn man den Downstream Server nicht als Replikat konfiguriert. Das kann man durch wechselndes Aktivieren und Deaktivieren jeweils provozieren: Replika aktiviert --> Fehler, Replika deaktiviert --> läuft.
D.h. neue Updates werden immer repliziert. Nur die Replikation der Gruppen und der Genehmigungen, welche nur bei Replikaten erfolgt, führt dann zu diesem Fehler.
SQL Server Express Edition fällt aus wegen der DB-Größe >10 GB.
SQL Server Standard würde das Problem lösen. Aber wie muss das lizensiert werden?
E.
Ich habe leider soeben erst gesehen, das @NordicMike heute schon eine ähnliche Frage platziert hat:
Indirekte SQL Lizenzierung
Hi,
weiß jemand, welche Lizenzen fällig werden, wenn man einen MS SQL Server ausschließlich für einen WSUS Server verwenden will?
Hintergrund ist, dass wir seit ca. 3 Wochen Probleme mit der Synchronisation unserer Downstream Server haben.
Wir haben - seit Jahren - einen WSUS Server in der Zentrale und ca. 10 Replica Downstream Server an den Standorten, welche sich jeweils von diesem zentralen Server synchronisieren. Die Datenbanken sind alle jeweils >30 GB. Der zentrale Server nutzt einen vorhandenen MS SQL Failovercluster. Die Downstream Server nutzen jeweils ihre lokale WID.
Die tägliche Synchronisation der Downstream Server steigt jeweils bei 99% und nach ca. 20-22 Minuten aus, mit Fehler
1
2
3
4
5
6
7
2
3
4
5
6
7
SqlException: Das Ausführungstimeout ist abgelaufen. Der Timeoutzeitraum wurde überschritten, bevor der Vorgang beendet wurde, oder der Server antwortet nicht. ---> System.ComponentModel.Win32Exception: Der Wartevorgang wurde abgebrochen
bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader()
bei Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlHiddenUpdateIds, String xmlAllUpdatesIds)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid hiddenUpdates, UpdateIdentity allUpdates)
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
Vorweg genommen:
Wir kennen die "Tricks" mit dem regelmäßigen Aufräumen der Datenbanken, haben nur die tatsächlich benötigten Updates freigegeben, laden nur genehmigte Inhalte herunter. Tipps in dieser Richtung bringen uns also nicht weiter.
Und bitte nicht verwechseln: Es geht um die DB, nicht um die Dateien. Der Content Download vom zentralen Server auf die Downstream Server funktioniert immer noch. Dieser läuft ja auch nachgeordert zur Synchronisation der DB.
Wir haben auch keine Probleme mit fehlendem Festplattenplatz oder CPU/RAM. Die Synchronisationen liefen bis Anfang Juni tadellos. Doch dann sind plötzlich alle Downstream Server mit dieser o.g. Fehlermeldung ausgestiegen. Ich vermute, dass wir zu diesem Zeitpunkt die 30 GB DB-Größe überschritten hatten. So genau kann ich das jetzt nicht mehr belegen.
Es schien naheliegend, dass es am zentralen Server liegen müsste, weil dieser das gemeinsame Element aller Server ist. Aber die o.g. Fehlermeldung bezieht sich auf die eigene DB des jeweiligen Downstream Servers. Diese greifen nicht direkt auf die DB des Upstream Servers zu.
Also habe ich experimentiert und an 3 Downstream Servern folgende Prozedur reproduzieren können:
- Installation SQL Server 2014 Standard auf dem WSUS Server
- Die SUSDB 1:1 vom WID an den SQL Server gehängt.
- WSUS in der Registry von WID auf SQL Server konfiguriert
- Die Synchronisation des Downstream Servers lief prompt fehlerfrei durch!
- Gegenprobe: Die SUSDB wieder 1:1 an den WID gehängt, WSUS Server angepasst
- Die Synchronisation des Downstream Servers lieferte prompt wieder o.g. Fehler.
- Erneute Gegenprobe: SUSDB wieder von WID nach SQL Server
- Die Synchronisation lief wieder fehlerfrei.
Die Synchronisation vom Upstream Server läuft auch mit der WID fehlerfrei, wenn man den Downstream Server nicht als Replikat konfiguriert. Das kann man durch wechselndes Aktivieren und Deaktivieren jeweils provozieren: Replika aktiviert --> Fehler, Replika deaktiviert --> läuft.
D.h. neue Updates werden immer repliziert. Nur die Replikation der Gruppen und der Genehmigungen, welche nur bei Replikaten erfolgt, führt dann zu diesem Fehler.
SQL Server Express Edition fällt aus wegen der DB-Größe >10 GB.
SQL Server Standard würde das Problem lösen. Aber wie muss das lizensiert werden?
E.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 764318086
Url: https://administrator.de/forum/sql-server-lizenzierung-fuer-wsus-764318086.html
Ausgedruckt am: 11.04.2025 um 05:04 Uhr
13 Kommentare
Neuester Kommentar
Moin,
nach meinem Verständnis greift nur der WSUS-Dienst auf die Datenbank direkt zu. Das würde bedeuten, dass ich weder User- noch Client-CALs benötige, wenn ich den SQL ausschließlich für den WSUS einsetze.
Aber was macht ihr, damit Eure DB so riesig ist....?
Gruß
Looser
P.S.: Gerade mal bei uns geschaut: die SUSDB.mdf ist 1,76GB groß (Windows 10 + Windows 2016 + ALLE Officepackete) bei knapp 40 Clients.
nach meinem Verständnis greift nur der WSUS-Dienst auf die Datenbank direkt zu. Das würde bedeuten, dass ich weder User- noch Client-CALs benötige, wenn ich den SQL ausschließlich für den WSUS einsetze.
Aber was macht ihr, damit Eure DB so riesig ist....?
Gruß
Looser
P.S.: Gerade mal bei uns geschaut: die SUSDB.mdf ist 1,76GB groß (Windows 10 + Windows 2016 + ALLE Officepackete) bei knapp 40 Clients.
weiß jemand, welche Lizenzen fällig werden, wenn man einen MS SQL Server ausschließlich für einen WSUS Server verwenden will?
[...]
SQL Server Standard würde das Problem lösen. Aber wie muss das lizensiert werden?
Jedes direkt oder indirekt zugreifende System benötigt eine CAL.
Zitat von @emeriks:
Zitat von @Looser27:
P.S.: Gerade mal bei uns geschaut: die SUSDB.mdf ist 1,76GB groß (Windows 10 + Windows 2016 + ALLE Officepackete) bei knapp 40 Clients.
Dann haben wir doch mit 30 GB noch Glück ....P.S.: Gerade mal bei uns geschaut: die SUSDB.mdf ist 1,76GB groß (Windows 10 + Windows 2016 + ALLE Officepackete) bei knapp 40 Clients.
Auf jeden Fall nicht viel falsch gemacht.
Meine WID Datenbank hier ist bei 10 Clients schon auf 24gb angewachsen. Das ganze trotz sämtliche Bereinigungsmöglichkeinte die sich per Script ausführen lassen.
Zitat von @Looser27:
Ich bereinige die Datenbank ausschließlich über die Wsus GUI, also nichtüber irgendwelche Skripte. Da habe ich mal schlechte Erfahrungen mit gemacht....
Das ganze trotz sämtliche Bereinigungsmöglichkeinte die sich per Script ausführen lassen.
Ich bereinige die Datenbank ausschließlich über die Wsus GUI, also nichtüber irgendwelche Skripte. Da habe ich mal schlechte Erfahrungen mit gemacht....
Bei der DB selbst lass ich auch nur das reindexing laufen. Ansonsten ein mal pro Tag die Wsus Bereinigung per Script.
Zitat von @emeriks:
Hi,
weiß jemand, welche Lizenzen fällig werden, wenn man einen MS SQL Server ausschließlich für einen WSUS Server verwenden will?
Hi,
weiß jemand, welche Lizenzen fällig werden, wenn man einen MS SQL Server ausschließlich für einen WSUS Server verwenden will?
Die gleichen die man braucht wenn jede andere Applikation drauf zugreift. Alle User die den Dienst nutzen müssen lizenziert sein oder du hast eine Core Lizenz.
Bevor du aber 5k Euronen ausgibst würd ich erst mal an eine Neuinstallation denken. 80% der Datenbankeinträge sind mit ziemlicher Sicherheit alter Schrott den du gar nicht brauchst. WSUS ist ja bekannt dafür NICHTS aus der Datenbank zu löschen, auch nicht die Updates die es gar nicht mehr gibt. Wenn du einfach nur alles verfügbare nochmal runterladen lässt wird die Datenbank wahrscheinlich wieder ein vertretbares Maß haben. Die Clients sollten sich ja normalerweise problemlos neu verbinden und ihre Infos senden.
Eventuell wär auch eine Trennung in WSUSalt und WSUSneu für alle aktuellen Updates machbar. Du brauchst ja nur den Pfad anhand eines WMI Filters auf die Betriebssystemversion zu verteilen. Das sollten ja hoffentlich keine tausend XP Clients mehr sein, ansonsten hast du ganz andere Probleme.
Über Sinn und Unsinn einen Update Server bereitzuhalten für Systeme die keine Updates mehr bekommen, hast du dir ja wahrscheinlich selbst schon genug Gedanken gemacht.
Moin emeriks,
das kommt auf die Anzahl der User an die der WSUS bedient.
Bis zu einer bestimmten Menge machen es durchaus Sinn den SQL nach der Anzahl der User zu lizenzieren, ab einer bestimmten Menge fährst du mit den CPU Lizenzen günstiger.
Deine WSUS Server bleiben höchstwahrscheinlich bei irgend einer Abfrage hängen, weil diese zu lange für die Ausführung benötigt.
Das Problem lässt sich in den allermeisten Fällen jedoch relativ einfach beseitigen. 😀
Das grösste Problem dabei ist das Problematische SQL zu finden, aber das ist nur eine Frage von etwas Fleiss und etwas Zeit.
Das hört sich schon mal sehr entspannt an, du kennst dich so wie es aussieht mit der Prozedur, die SUSDB einem SQL Standard unterzujubeln ja bestens aus.
Kannst du als nächstes einen der Replica Downstream Server von WID auf einen Standard SQL Server umstellen, aber bitte auf einen 2019er und nicht auf einen 2014er.
Wenn das getan ist, dann aktiviere bitte auf der SUSDB den Abfragespeicher und lasse das Ding ein paar Tage durchlaufen.
Danach kannst du über diese Auswertung sehen, welche Abfrage die höchsten Ressourcen verbraucht und auch warum.
In den meisten fällen fehlt ein Index oder ein bestehender ist nur grottig erstellt und muss einfach nur optimiert werden.
Ich kann da aus Erfahrung ein langes Lied davon Singen.
Schau dir mal den folgenden Beitrag an, vielleicht helfen dir ja bereits die darin geposteten Indexoptimierungen.
WSUS Stabilisierung und Performanceoptimierung
Wenn du nicht weiterkommst, dann schick mir ne PN und wir ziehen den Karren gemeinsam aus dem Schlamm. 😉
Für eine Empfehlung muss man erstmal wissen, wie viele Benutzer an den jeweiligen Standorten an dem jeweiligen WSUS hängen.
Beste Grüsse aus BaWü
Alex
weiß jemand, welche Lizenzen fällig werden, wenn man einen MS SQL Server ausschließlich für einen WSUS Server verwenden will?
das kommt auf die Anzahl der User an die der WSUS bedient.
Bis zu einer bestimmten Menge machen es durchaus Sinn den SQL nach der Anzahl der User zu lizenzieren, ab einer bestimmten Menge fährst du mit den CPU Lizenzen günstiger.
Hintergrund ist, dass wir seit ca. 3 Wochen Probleme mit der Synchronisation unserer Downstream Server haben.
Wir haben - seit Jahren - einen WSUS Server in der Zentrale und ca. 10 Replica Downstream Server an den Standorten, welche sich jeweils von diesem zentralen Server synchronisieren. Die Datenbanken sind alle jeweils >30 GB. Der zentrale Server nutzt einen vorhandenen MS SQL Failovercluster. Die Downstream Server nutzen jeweils ihre lokale WID.
Wir haben - seit Jahren - einen WSUS Server in der Zentrale und ca. 10 Replica Downstream Server an den Standorten, welche sich jeweils von diesem zentralen Server synchronisieren. Die Datenbanken sind alle jeweils >30 GB. Der zentrale Server nutzt einen vorhandenen MS SQL Failovercluster. Die Downstream Server nutzen jeweils ihre lokale WID.
Die tägliche Synchronisation der Downstream Server steigt jeweils bei 99% und nach ca. 20-22 Minuten aus, mit Fehler
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
> SqlException: Das Ausführungstimeout ist abgelaufen. Der Timeoutzeitraum wurde überschritten, bevor der Vorgang beendet wurde, oder der Server antwortet nicht. ---> System.ComponentModel.Win32Exception: Der Wartevorgang wurde abgebrochen
> bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
> bei Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader()
> bei Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlHiddenUpdateIds, String xmlAllUpdatesIds)
> bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid hiddenUpdates, UpdateIdentity allUpdates)
> bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
> bei Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)
>
Deine WSUS Server bleiben höchstwahrscheinlich bei irgend einer Abfrage hängen, weil diese zu lange für die Ausführung benötigt.
Das Problem lässt sich in den allermeisten Fällen jedoch relativ einfach beseitigen. 😀
Das grösste Problem dabei ist das Problematische SQL zu finden, aber das ist nur eine Frage von etwas Fleiss und etwas Zeit.
Also habe ich experimentiert und an 3 Downstream Servern folgende Prozedur reproduzieren können:
- Installation SQL Server 2014 Standard auf dem WSUS Server
- Die SUSDB 1:1 vom WID an den SQL Server gehängt.
- WSUS in der Registry von WID auf SQL Server konfiguriert
- Die Synchronisation des Downstream Servers lief prompt fehlerfrei durch!
- Gegenprobe: Die SUSDB wieder 1:1 an den WID gehängt, WSUS Server angepasst
- Die Synchronisation des Downstream Servers lieferte prompt wieder o.g. Fehler.
- Erneute Gegenprobe: SUSDB wieder von WID nach SQL Server
- Die Synchronisation lief wieder fehlerfrei.
Das hört sich schon mal sehr entspannt an, du kennst dich so wie es aussieht mit der Prozedur, die SUSDB einem SQL Standard unterzujubeln ja bestens aus.
Kannst du als nächstes einen der Replica Downstream Server von WID auf einen Standard SQL Server umstellen, aber bitte auf einen 2019er und nicht auf einen 2014er.
Wenn das getan ist, dann aktiviere bitte auf der SUSDB den Abfragespeicher und lasse das Ding ein paar Tage durchlaufen.
Danach kannst du über diese Auswertung sehen, welche Abfrage die höchsten Ressourcen verbraucht und auch warum.
In den meisten fällen fehlt ein Index oder ein bestehender ist nur grottig erstellt und muss einfach nur optimiert werden.
Ich kann da aus Erfahrung ein langes Lied davon Singen.
Schau dir mal den folgenden Beitrag an, vielleicht helfen dir ja bereits die darin geposteten Indexoptimierungen.
WSUS Stabilisierung und Performanceoptimierung
Wenn du nicht weiterkommst, dann schick mir ne PN und wir ziehen den Karren gemeinsam aus dem Schlamm. 😉
SQL Server Standard würde das Problem lösen. Aber wie muss das lizensiert werden?
Für eine Empfehlung muss man erstmal wissen, wie viele Benutzer an den jeweiligen Standorten an dem jeweiligen WSUS hängen.
Beste Grüsse aus BaWü
Alex
Moin emeriks,
Das geschieht meines Wissens nach nur dann, wenn du von Hand den Kompatibilitätsmodus der DB heraufschraubst.
Wenn du das nicht tust, dann sollte das Zurückbiegen eigentlich kein Problem sein.
Hast du WAM schon ausprobiert?
https://www.ajtek.ca/
WAM tut neben vielen anderen guten Dingen auch die SUSDB kräftig bereinigt und kostet pro WSUS absolut überschaubare 60$ pro Jahr.
Beste Grüsse aus BaWü
Alex
Wenn man vorhat, die DB nur temporär von WID nach SQL Server zu verlagern, dann darf man unter Win2016 max. den SQL Server 2014 nehmen, weil man sonst die DB nicht wieder zurück an den WID hängen kann. Der SQL Server ändert ggf. die Dateiversion.
Das geschieht meines Wissens nach nur dann, wenn du von Hand den Kompatibilitätsmodus der DB heraufschraubst.
Wenn du das nicht tust, dann sollte das Zurückbiegen eigentlich kein Problem sein.
Hast du WAM schon ausprobiert?
https://www.ajtek.ca/
WAM tut neben vielen anderen guten Dingen auch die SUSDB kräftig bereinigt und kostet pro WSUS absolut überschaubare 60$ pro Jahr.
Beste Grüsse aus BaWü
Alex