44
WSUS Stabilisierung und Performanceoptimierung
WSUS – Stabilisierung und Performanceoptimierung
Moin Zusammen,
so gut wie jeder der einen WSUS betreibt, kennt das Problem. Wenn man einen WSUS ohne händische Optimierungen in Betrieb nimmt, dann läuft die Software meistens äusserst Instabil und auch sehr langsam. Im Netz gibt es bereits einen dutzend Beiträge zu diesem Thema und auch die diversesten Lösungsvorschläge, die mal mehr mal weniger gut funktionieren.
Ich würde nun folgend die wesentlichen Dinge gerne zusammenfassen und um eine Neuigkeit ergänzen, die nach meinen jüngsten WSUS Erfahrungen den grössten Erfolg beschert hat.
Kleines Schmankerl zum Vorab:
Das setzen der markierten Klassifizierungen, gibt jedem „out of the Box“ WSUS normalerweise den sicheren Todesstoss und hat schon dutzende von Admins eine mühselige Bereinigung oder gar eine Neuinstallation beschert. Der von mir jüngst optimierte WSUS läuft auch mit den oben markierten und aktivierten Optionen, nun mehr als geschmeidig.
Aber schön der Reihe nach …
Nach einer WSUS Installation sollte man sich als erste den folgenden Artikel zu Gemüte führen und die entsprechenden Empfehlungen von Microsoft auch umsetzten.
https://support.microsoft.com/de-de/help/4490414/windows-server-update-s ...
An dieser Stelle hätte ich schon die erste Frage Richtung Microsoft.
Warum baut Ihr die eigenen „Best Practices“ Optionen nicht einfach in das Setup ein? 🤨
Liebes Microsoft, ich weiss, das ist eine gute Frage, aber jetzt nicht gleich nur mit dieser einen Fragestellung zu dem Verantwortlichen losflitzen, Bleistift spitzen, es kommen noch ein paar weitere … 😁 oder eher 😢 je nach Betrachtungswinkel.
---
Der zweite wesentliche Punk beim WSUS ist seine Datenbank und hier liegt der Hund auch begraben. 😉
Die Performance einer Datenbank ist mit unter von den folgenden Faktoren abhängig
- Kluges Grunddesign der Datenbankstruktur
- Kluges schreiben von SQL Statements
(An dieser Stellen ein Gruss an alle Freunde von select *, das ist damit nicht gemeint.)
- Setzen von entsprechenden Indexen
- zyklische Erneuerung der im oberen Punkt genannten Indexe
- u.s.w.
Nun kommen wir zu dem zweiten wesentlichen Optimierungspunkt, die Zyklische Aktualisierung/Erneuerung der Indexe. Dieser durchaus wesentliche Punkt ist bei der WSUS Datenbank (SUSDB) schlichtweg nicht aktiviert und je nachdem auf welcher Datenbank der WSUS aufgesetzt wurde auch nicht so einfach möglich.
Aber auch hierzu gibt es ein dutzend Anleitungen im Internet, die sehr gut beschreiben wie man dieses Problem angehen kann, deshalb verlinke ich auch bei diesem Punkt auf eine Lösung.
Muss das Rad ja nicht neu erfinden. 🙃
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-98 ...
https://www.windowspro.de/wolfgang-sommergut/wsus-datenbank-neu-indizier ...
u.s.w einfach nach „wsus reindex db“ googeln.
Liebes Microsoft, eine weitere Frage in eure Richtung.
Warum richtet Ihr diesen absolut performancewichtigen Wartungstask nicht schon per Setup ein?
---
Alle guten Dinge sind Drei und somit kommen wir nun zu dem wesentlichsten Punk, der die Performance jedoch am meisten betrifft aber auch die Stabilität.
Wir haben in dem oberen Punkt das Thema Index ja schon angesprochen gehabt und dass die „Reindexierung“ auch extrem wichtig ist. Nun bringt das ganze aber absolut gar nichts, wenn in der DB die entsprechenden Indexe gar nicht angelegt sind.
Ich habe mir, nachdem mir der XXte WSUS zum XXXten Mal Probleme bereitet hat, mal die mühe gemacht und die WSUS DB, respektive deren „Lasterzeugung“ mal unter die Luppe genommen, das Ergebnis war grausig. Diverseste SQLs erzeugten abartige CPU Kosten weil sie aufgrund von fehlenden Indexen auf einen „FULL TABLE SCAN“ hinausliefen. 🤢🤮
Ich habe basierend auf diesen Erkenntnissen ein paar Indexe neu hinzugefügt und siehe da, seit dem schnurrt das WSUS Kätzchen gemütlich vor sich hin. 😀
Folgend ein SQL mit dem Ihr die fehlenden Indexe auch bei euch nachtragen könnt.
(Aktualisiert 17.01.2023)
Über ein Feedback würde ich mich sehr freuen.
---
(der folgende Abschnitt gilt ausschließlich Microsoft, lesen darf diesen natürlich jeder … 🤪)
Liebes Microsoft, Ich hätte bis zum gestrigen Tag, niemals im Leben vorstellen können, das ich diese Leviten mal dem grössten Datenbanksoftwarehersteller der Welt lesen müsste.
Dies zu tun erfühlt mich keineswegs mit Freude, sondern mit tiefster Trauer.
Nun zum Punkt, Euch müsste das Feature Abfragespeicher ja bestens bekannt sein. Das Ding ist echt gut und liefert auch sehr interessante Informationen, nur der Name ist leicht Grüzze.
Was ich auch sehr gut finde ist, dass der „Abfragespeicher“ mittlerweile sogar von sich aus bei suboptimalen SQL-Abfragen vorschlägt mit welchem neuen Index die Abfrage um wieviel Prozent schneller laufen könnte.
Die Hälfte der oberen Indexe kam aus solchen Vorschlägen. 😠
Nur damit ich das jetzt richtig verstehe, Ihr stellt die Datenbanksoftware selbst her, der WSUS kommt auch von Euch, auch der „Abfragespeicher“ ist euer Kind.
Wie kann so etwas geschehen?
Warum seid Ihr nicht in der Lage, die eigenen Komponenten klug miteinander zu verwenden um ein Problem effektiv und vor allem zentral zu beseitigen?
Grüsse aus BaWü
Alex
Nachtrag 17.02.2021:
Laut Microsoft sollten auch noch die folgenden beiden Indexe zusätzlich erstellt werden.
https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/wsus-mainten ...
Moin Zusammen,
so gut wie jeder der einen WSUS betreibt, kennt das Problem. Wenn man einen WSUS ohne händische Optimierungen in Betrieb nimmt, dann läuft die Software meistens äusserst Instabil und auch sehr langsam. Im Netz gibt es bereits einen dutzend Beiträge zu diesem Thema und auch die diversesten Lösungsvorschläge, die mal mehr mal weniger gut funktionieren.
Ich würde nun folgend die wesentlichen Dinge gerne zusammenfassen und um eine Neuigkeit ergänzen, die nach meinen jüngsten WSUS Erfahrungen den grössten Erfolg beschert hat.
Kleines Schmankerl zum Vorab:
Das setzen der markierten Klassifizierungen, gibt jedem „out of the Box“ WSUS normalerweise den sicheren Todesstoss und hat schon dutzende von Admins eine mühselige Bereinigung oder gar eine Neuinstallation beschert. Der von mir jüngst optimierte WSUS läuft auch mit den oben markierten und aktivierten Optionen, nun mehr als geschmeidig.
Aber schön der Reihe nach …
Nach einer WSUS Installation sollte man sich als erste den folgenden Artikel zu Gemüte führen und die entsprechenden Empfehlungen von Microsoft auch umsetzten.
https://support.microsoft.com/de-de/help/4490414/windows-server-update-s ...
An dieser Stelle hätte ich schon die erste Frage Richtung Microsoft.
Warum baut Ihr die eigenen „Best Practices“ Optionen nicht einfach in das Setup ein? 🤨
Liebes Microsoft, ich weiss, das ist eine gute Frage, aber jetzt nicht gleich nur mit dieser einen Fragestellung zu dem Verantwortlichen losflitzen, Bleistift spitzen, es kommen noch ein paar weitere … 😁 oder eher 😢 je nach Betrachtungswinkel.
---
Der zweite wesentliche Punk beim WSUS ist seine Datenbank und hier liegt der Hund auch begraben. 😉
Die Performance einer Datenbank ist mit unter von den folgenden Faktoren abhängig
- Kluges Grunddesign der Datenbankstruktur
- Kluges schreiben von SQL Statements
(An dieser Stellen ein Gruss an alle Freunde von select *, das ist damit nicht gemeint.)
- Setzen von entsprechenden Indexen
- zyklische Erneuerung der im oberen Punkt genannten Indexe
- u.s.w.
Nun kommen wir zu dem zweiten wesentlichen Optimierungspunkt, die Zyklische Aktualisierung/Erneuerung der Indexe. Dieser durchaus wesentliche Punkt ist bei der WSUS Datenbank (SUSDB) schlichtweg nicht aktiviert und je nachdem auf welcher Datenbank der WSUS aufgesetzt wurde auch nicht so einfach möglich.
Aber auch hierzu gibt es ein dutzend Anleitungen im Internet, die sehr gut beschreiben wie man dieses Problem angehen kann, deshalb verlinke ich auch bei diesem Punkt auf eine Lösung.
Muss das Rad ja nicht neu erfinden. 🙃
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/window ...
https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-98 ...
https://www.windowspro.de/wolfgang-sommergut/wsus-datenbank-neu-indizier ...
u.s.w einfach nach „wsus reindex db“ googeln.
Liebes Microsoft, eine weitere Frage in eure Richtung.
Warum richtet Ihr diesen absolut performancewichtigen Wartungstask nicht schon per Setup ein?
---
Alle guten Dinge sind Drei und somit kommen wir nun zu dem wesentlichsten Punk, der die Performance jedoch am meisten betrifft aber auch die Stabilität.
Wir haben in dem oberen Punkt das Thema Index ja schon angesprochen gehabt und dass die „Reindexierung“ auch extrem wichtig ist. Nun bringt das ganze aber absolut gar nichts, wenn in der DB die entsprechenden Indexe gar nicht angelegt sind.
Ich habe mir, nachdem mir der XXte WSUS zum XXXten Mal Probleme bereitet hat, mal die mühe gemacht und die WSUS DB, respektive deren „Lasterzeugung“ mal unter die Luppe genommen, das Ergebnis war grausig. Diverseste SQLs erzeugten abartige CPU Kosten weil sie aufgrund von fehlenden Indexen auf einen „FULL TABLE SCAN“ hinausliefen. 🤢🤮
Ich habe basierend auf diesen Erkenntnissen ein paar Indexe neu hinzugefügt und siehe da, seit dem schnurrt das WSUS Kätzchen gemütlich vor sich hin. 😀
Folgend ein SQL mit dem Ihr die fehlenden Indexe auch bei euch nachtragen könnt.
USE [SUSDB]
GO
CREATE NONCLUSTERED INDEX [ivwApiUpdateRevision_NGIS_01] ON [dbo].[ivwApiUpdateRevision]
(
[IsLatestRevision] ASC
)
INCLUDE([IsHidden],[IsLocallyPublished],[IsMandatory]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [ivwApiUpdateRevision_NGIS_02] ON [dbo].[ivwApiUpdateRevision]
(
[UpdateID] ASC,
[IsLatestRevision] ASC,
[IsHidden] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbCategory_NGIS_01] ON [dbo].[tbCategory]
(
[CategoryIndex] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
DROP INDEX [c0ChangeTracking] ON [dbo].[tbChangeTracking] WITH ( ONLINE = OFF )
GO
CREATE NONCLUSTERED INDEX [c0ChangeTracking] ON [dbo].[tbChangeTracking]
(
[ChangeNumber] DESC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbDeployment_NGIS_01] ON [dbo].[tbDeployment]
(
[ActionID] ASC,
[TargetGroupTypeID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbDeployment_NGIS_02] ON [dbo].[tbDeployment]
(
[TargetGroupTypeID] ASC
)
INCLUDE([ActionID],[RevisionID]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbEventInstance_NGIS_01] ON [dbo].[tbEventInstance]
(
[EventNamespaceID] ASC,
[TimeAtServer] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbFile_NGIS_01] ON [dbo].[tbFile]
(
[IsEula] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbFileOnServer_NGIS_01] ON [dbo].[tbFileOnServer]
(
[ActualState] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbFileOnServer_NGIS_02] ON [dbo].[tbFileOnServer]
(
[ActualState] ASC
)
INCLUDE([FileDigest],[TimeAddedToQueue]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbFrontEndServersHealth_NGIS_02] ON [dbo].[tbFrontEndServersHealth]
(
[ComponentName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbLocalizedPropertyForRevision_NGIS_01] ON [dbo].[tbLocalizedPropertyForRevision]
(
[LocalizedPropertyID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbNotificationEvent_NGIS_01] ON [dbo].[tbNotificationEvent]
(
[State] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbPreComputedLocalizedProperty_NGIS_01] ON [dbo].[tbPreComputedLocalizedProperty]
(
[ShortLanguage] ASC
)
INCLUDE([Title],[Description],[ReleaseNotes],[RevisionID]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbProperty_NGIS_01] ON [dbo].[tbProperty]
(
[CreationDate] ASC,
[ReceivedFromCreatorService] ASC
)
INCLUDE([PublicationState]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbProperty_NGIS_02] ON [dbo].[tbProperty]
(
[PublicationState] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbProperty_NGIS_03] ON [dbo].[tbProperty]
(
[DefaultPropertiesLanguageID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbRevision_NGIS_01] ON [dbo].[tbRevision]
(
[State] ASC
)
INCLUDE([LocalUpdateID]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbSchedule_NGIS_01] ON [dbo].[tbSchedule]
(
[ScheduleTarget] ASC,
[ScheduleID] ASC,
[ScheduledRunTime] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbUpdate_NGIS_01] ON [dbo].[tbUpdate]
(
[IsHidden] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbXml_NGIS_01] ON [dbo].[tbXml]
(
[RootElementType] ASC,
[LanguageID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GOÜber ein Feedback würde ich mich sehr freuen.
---
(der folgende Abschnitt gilt ausschließlich Microsoft, lesen darf diesen natürlich jeder … 🤪)
Liebes Microsoft, Ich hätte bis zum gestrigen Tag, niemals im Leben vorstellen können, das ich diese Leviten mal dem grössten Datenbanksoftwarehersteller der Welt lesen müsste.
Dies zu tun erfühlt mich keineswegs mit Freude, sondern mit tiefster Trauer.
Nun zum Punkt, Euch müsste das Feature Abfragespeicher ja bestens bekannt sein. Das Ding ist echt gut und liefert auch sehr interessante Informationen, nur der Name ist leicht Grüzze.
Was ich auch sehr gut finde ist, dass der „Abfragespeicher“ mittlerweile sogar von sich aus bei suboptimalen SQL-Abfragen vorschlägt mit welchem neuen Index die Abfrage um wieviel Prozent schneller laufen könnte.
Die Hälfte der oberen Indexe kam aus solchen Vorschlägen. 😠
Nur damit ich das jetzt richtig verstehe, Ihr stellt die Datenbanksoftware selbst her, der WSUS kommt auch von Euch, auch der „Abfragespeicher“ ist euer Kind.
Wie kann so etwas geschehen?
Warum seid Ihr nicht in der Lage, die eigenen Komponenten klug miteinander zu verwenden um ein Problem effektiv und vor allem zentral zu beseitigen?
Grüsse aus BaWü
Alex
Nachtrag 17.02.2021:
Laut Microsoft sollten auch noch die folgenden beiden Indexe zusätzlich erstellt werden.
https://docs.microsoft.com/en-us/troubleshoot/mem/configmgr/wsus-mainten ...
USE [SUSDB]
CREATE NONCLUSTERED INDEX [nclLocalizedPropertyID] ON [dbo].[tbLocalizedPropertyForRevision]
(
[LocalizedPropertyID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
-- Create custom index in tbRevisionSupersedesUpdate
CREATE NONCLUSTERED INDEX [nclSupercededUpdateID] ON [dbo].[tbRevisionSupersedesUpdate]
(
[SupersededUpdateID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
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-Key: 554097
Url: https://administrator.de/contentid/554097
Ausgedruckt am: 19.04.2024 um 01:04 Uhr
44 Kommentare
Neuester Kommentar
Moin,
bitte mal anpassen:
Duzen vs Dutzend
Es sei denn Dein WSUS ist per Du mit Dir
bitte mal anpassen:
Duzen vs Dutzend
Es sei denn Dein WSUS ist per Du mit Dir
Moin Sabines,
hab's korrigiert, danke für den Hinweis.
Dem deutsche Sprache ist halt dem schwere Sprache ... 🙃
Grüsse aus BaWü
Alex
hab's korrigiert, danke für den Hinweis.
Dem deutsche Sprache ist halt dem schwere Sprache ... 🙃
Grüsse aus BaWü
Alex
Was wäre, wenn Du die klassifizierungen einfach weg lassen würdest? Deswegen erhält trotzdem jeder Client seine Treiber.
Moin Mike,
Wie sollen die Clients den die Treiber ausgerollt bekommen, wenn ich die entsprechende Klassifizierung weg lasse?
Gruss Alex
Was wäre, wenn Du die klassifizierungen einfach weg lassen würdest? Deswegen erhält trotzdem jeder Client seine Treiber.
Wie sollen die Clients den die Treiber ausgerollt bekommen, wenn ich die entsprechende Klassifizierung weg lasse?
Gruss Alex
Hallo Alex
Die Clients melden dem WSUS trotzdem, was sie alles benötigen, das erscheint dann in der Liste der zu genehmigenden Updates. Wenn Du nun die geforderten genehmigst, bekommt der Client trotzdem alles.
Die Clients melden dem WSUS trotzdem, was sie alles benötigen, das erscheint dann in der Liste der zu genehmigenden Updates. Wenn Du nun die geforderten genehmigst, bekommt der Client trotzdem alles.
Zitat von @MysticFoxDE:
An dieser Stelle hätte ich schon die erste Frage Richtung Microsoft.
Warum baut Ihr die eigenen „Best Practices“ Optionen nicht einfach in das Setup ein? 🤨
Liebes Microsoft, eine weitere Frage in eure Richtung.
Warum richtet Ihr diesen absolut performancewichtigen Wartungstask nicht schon per Setup ein?
An dieser Stelle hätte ich schon die erste Frage Richtung Microsoft.
Warum baut Ihr die eigenen „Best Practices“ Optionen nicht einfach in das Setup ein? 🤨
Liebes Microsoft, eine weitere Frage in eure Richtung.
Warum richtet Ihr diesen absolut performancewichtigen Wartungstask nicht schon per Setup ein?
Hi Alex,
weil es ja sonst jeder könnte!
Vermutlich möchte MS den Expertenkreis überschaubar halten.
mfg
kowa
Hi Mike,
wir reden glaube ich an einander vorbei oder meinen etwas Unterschiedliches.
Das Auswählen der Klassifizierungen (und Produkte) die ich meine (siehe Screenshot ganz oben), gehört zur der Initialkonfiguration eines jeden WSUS. Der WSUS Synchronisiert basierend auf dieser Auswahl (Klassifizierungen & Produkte) dann die entsprechenden Updatedefinitionen (nicht die Updates selbst) von MS in seine eigene Datenbank (SUSDB) und zwar nur die, die ausgewählt wurden. Aus dieser eingeschränkten Auswahl kann sich im Anschluss dann der Client bedienen. Wenn du bei der Klassifizierungswahl keine Treiber und Treibersätze auswählst, dann bekommst du über den WSUS auch keine bereitgestellt. Das rächt sich aber spätestens dann, wenn das Unternehmen Surface Pro & Co im Einsatz hat.
Ich finde es generell wichtig, dass man neben aktuellen Softwareupdates auch auf aktuelle Treiber achtet. Weniger, aber auch aus Sicherheitsgründen, viel mehr jedoch aus Performancegründen.
Hatte da dem letzt erst so eine Erfahrung ...
Bei einem Kunden ist an einem Rechner das Netzteil futsch gegangen. Am selben Rechner hatten wir am Vortag den Virenscanner getauscht.
Nach dem Tausch des Netzteils funktionierte zwar der Rechner wieder aber die CAD Software war absolut unbedienbar (ruckel, ruckel, ruckel ...).
Mein Telefon klingelt und ich habe einen leicht verärgerten Admin dran, der absolut davon überzeugt ist, dass das Problem am neuen AV liegt.
Mir kam es gleich spanisch vor, ich kenne in Verbindung mit CAD Software zwar Probleme die beim Laden der Software und oder der Zeichnung entstehen können, aber Darstellungsprobleme in Verbindung mit einem AV Sanner bei geladener Zeichnung wären mir absolut neu.
Ich habe dem Admin dann angemerkt, dass ich das Problem eher bei dem Grafikkartentreiber sehe und kassierte daraufhin erst mal eine schroffe Antwort "Vorgestern ging noch alles, dann haben sie den AV Scanner getauscht und wir gestern das Netzteil und nun sagen sie, dass problem liegt am Grafikkartentreiber?"
OK, da eine Produktionsmaschine stand, wollte ich nicht lange Diskutieren und deinstallierte kurzerhand die AV Software von dem betreffenden Rechner. Nach dem anschliessenden Neustart war der Admin jedoch nicht glücklicher, die CAD Software war auch ohne AV nicht zu gebrauchen.
Nun durfte ich auch einen Blick auf den Grafikkartentreiber des Rechners werfen und sah eine Version von Anno 2015. Der neue Treiber war schnell geladen und installiert und nach einem Neustart des Rechner lieft die CAD Software wieder wie gewohnt, auch nachdem die AV Software wieder installiert wurde.
Auf die Frage des Admins, ob ich dafür nun eine logische Erklärung hätte, konnte ich nur mit "That's IT live" antworten.
Grüsse aus BaWü
Alex
wir reden glaube ich an einander vorbei oder meinen etwas Unterschiedliches.
Das Auswählen der Klassifizierungen (und Produkte) die ich meine (siehe Screenshot ganz oben), gehört zur der Initialkonfiguration eines jeden WSUS. Der WSUS Synchronisiert basierend auf dieser Auswahl (Klassifizierungen & Produkte) dann die entsprechenden Updatedefinitionen (nicht die Updates selbst) von MS in seine eigene Datenbank (SUSDB) und zwar nur die, die ausgewählt wurden. Aus dieser eingeschränkten Auswahl kann sich im Anschluss dann der Client bedienen. Wenn du bei der Klassifizierungswahl keine Treiber und Treibersätze auswählst, dann bekommst du über den WSUS auch keine bereitgestellt. Das rächt sich aber spätestens dann, wenn das Unternehmen Surface Pro & Co im Einsatz hat.
Ich finde es generell wichtig, dass man neben aktuellen Softwareupdates auch auf aktuelle Treiber achtet. Weniger, aber auch aus Sicherheitsgründen, viel mehr jedoch aus Performancegründen.
Hatte da dem letzt erst so eine Erfahrung ...
Bei einem Kunden ist an einem Rechner das Netzteil futsch gegangen. Am selben Rechner hatten wir am Vortag den Virenscanner getauscht.
Nach dem Tausch des Netzteils funktionierte zwar der Rechner wieder aber die CAD Software war absolut unbedienbar (ruckel, ruckel, ruckel ...).
Mein Telefon klingelt und ich habe einen leicht verärgerten Admin dran, der absolut davon überzeugt ist, dass das Problem am neuen AV liegt.
Mir kam es gleich spanisch vor, ich kenne in Verbindung mit CAD Software zwar Probleme die beim Laden der Software und oder der Zeichnung entstehen können, aber Darstellungsprobleme in Verbindung mit einem AV Sanner bei geladener Zeichnung wären mir absolut neu.
Ich habe dem Admin dann angemerkt, dass ich das Problem eher bei dem Grafikkartentreiber sehe und kassierte daraufhin erst mal eine schroffe Antwort "Vorgestern ging noch alles, dann haben sie den AV Scanner getauscht und wir gestern das Netzteil und nun sagen sie, dass problem liegt am Grafikkartentreiber?"
OK, da eine Produktionsmaschine stand, wollte ich nicht lange Diskutieren und deinstallierte kurzerhand die AV Software von dem betreffenden Rechner. Nach dem anschliessenden Neustart war der Admin jedoch nicht glücklicher, die CAD Software war auch ohne AV nicht zu gebrauchen.
Nun durfte ich auch einen Blick auf den Grafikkartentreiber des Rechners werfen und sah eine Version von Anno 2015. Der neue Treiber war schnell geladen und installiert und nach einem Neustart des Rechner lieft die CAD Software wieder wie gewohnt, auch nachdem die AV Software wieder installiert wurde.
Auf die Frage des Admins, ob ich dafür nun eine logische Erklärung hätte, konnte ich nur mit "That's IT live" antworten.
Grüsse aus BaWü
Alex
Hi Kowa,
vielen Dank für die Blumen, aber ich kann diese irgendwie nicht annehmen.
Liegt aber nicht an dir, sondern am Anlass. 😔
Würde ich jetzt irgend einer 0815 Bude diese Leviten lesen müssen, OK, kein Problem, schon duzende Mal gemacht.
Aber dass es nun Microsoft selbst trift, erfüllt mich mit tiefster Trauer. Wenn nicht Mal der Hersteller selbst in der Lage ist,
seine eigene Technologie qualitativ und konsequent zu leben, was soll man dann von dem Rest verlangen. 😔😔😔
Hmm, vielleicht ist bei MS das Wissen ja einfach untergegangen?
Ne, ich sehe schon, es ist in die CLOUD ausgelagert worden ...
SQL Server performance: faster querying with SQL Server
Ich habe in der Vergangenheit viel von MS gehalten und tue das auch jetzt noch. Jedoch darf man unsere aktuelle Beziehung durchaus als angespannt betrachten.
---
Ja, MS hat auch schon früher versucht hier und da die eigenen Vorstellungen dem Kunden aufs Auge zu drücken, aber dennoch hat MS in der Vergangenheit auch viel Rücksicht auf den Wunsch des Kunden gelegt. Vor allem nicht nur auf die Wünsche der wenigen ganz Grossen, sondern auch auf die Wünsche der sehr vielen Mittleren bis Kleinen. Jüngst beobachte ich jedoch eine ganz andere Mentalität, ich würde diese verkürzt gerne als "Friss die Cloud oder stirb" bezeichnen.
Cloud hin, cloud her, ich sehe die Sache so.
Würde irgend einer von euch, sein eigenes Kind ausser Haus geben, bloss weil einer vor der Tür erscheint und meint er könnte besser darauf aufpassen als sie selbst. ???
Wer jetzt den Bogen nicht ganz hin bekommt.
Für die meisten Menschen sind Ihre Kinder eines der wesentlichsten Bestandteile des Lebens.
Für die meisten Unternehmen sind es heutzutage die Daten dieser. 😉
Bei der Frage mit dem Kind würde wahrscheinlich so gut wie jeder dem Typen an der Haustür einen kräftigen Tritt in den Hintern geben.
Aber bei den Daten die man meistens nicht direkt sieht und auch nicht fühlt, zumindest solange diese noch da (zugreifbar) sind, ... 😔
Grüsse aus BaWü
Alex
Vermutlich möchte MS den Expertenkreis überschaubar halten.
vielen Dank für die Blumen, aber ich kann diese irgendwie nicht annehmen.
Liegt aber nicht an dir, sondern am Anlass. 😔
Würde ich jetzt irgend einer 0815 Bude diese Leviten lesen müssen, OK, kein Problem, schon duzende Mal gemacht.
Aber dass es nun Microsoft selbst trift, erfüllt mich mit tiefster Trauer. Wenn nicht Mal der Hersteller selbst in der Lage ist,
seine eigene Technologie qualitativ und konsequent zu leben, was soll man dann von dem Rest verlangen. 😔😔😔
Hmm, vielleicht ist bei MS das Wissen ja einfach untergegangen?
Ne, ich sehe schon, es ist in die CLOUD ausgelagert worden ...
SQL Server performance: faster querying with SQL Server
Ich habe in der Vergangenheit viel von MS gehalten und tue das auch jetzt noch. Jedoch darf man unsere aktuelle Beziehung durchaus als angespannt betrachten.
---
Ja, MS hat auch schon früher versucht hier und da die eigenen Vorstellungen dem Kunden aufs Auge zu drücken, aber dennoch hat MS in der Vergangenheit auch viel Rücksicht auf den Wunsch des Kunden gelegt. Vor allem nicht nur auf die Wünsche der wenigen ganz Grossen, sondern auch auf die Wünsche der sehr vielen Mittleren bis Kleinen. Jüngst beobachte ich jedoch eine ganz andere Mentalität, ich würde diese verkürzt gerne als "Friss die Cloud oder stirb" bezeichnen.
Cloud hin, cloud her, ich sehe die Sache so.
Würde irgend einer von euch, sein eigenes Kind ausser Haus geben, bloss weil einer vor der Tür erscheint und meint er könnte besser darauf aufpassen als sie selbst. ???
Wer jetzt den Bogen nicht ganz hin bekommt.
Für die meisten Menschen sind Ihre Kinder eines der wesentlichsten Bestandteile des Lebens.
Für die meisten Unternehmen sind es heutzutage die Daten dieser. 😉
Bei der Frage mit dem Kind würde wahrscheinlich so gut wie jeder dem Typen an der Haustür einen kräftigen Tritt in den Hintern geben.
Aber bei den Daten die man meistens nicht direkt sieht und auch nicht fühlt, zumindest solange diese noch da (zugreifbar) sind, ... 😔
Grüsse aus BaWü
Alex
Hallo Alex,
vielen Dank von einem Leid geplagtem WSUS Admin! ich hatte irgendwann mal die DB ge-"reindext". Aber kein wöchentlichen Task erstellt.
Ich wollte auch gerne dein Tipp mit den fehlenden Indexen folgen, jedoch weiß ich leider nicht wie man ganz simple die SQL-Kommandos ausführt
Ich habe dein Code als DB_Tuning.sql abgespeichert und mit sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -i DB_Tuning.sql versucht auszuführen.
Ich erhalte jedoch nur folgende Meldung:
Kannst du mir helfen? Vielen Dank!
vielen Dank von einem Leid geplagtem WSUS Admin! ich hatte irgendwann mal die DB ge-"reindext". Aber kein wöchentlichen Task erstellt.
Ich wollte auch gerne dein Tipp mit den fehlenden Indexen folgen, jedoch weiß ich leider nicht wie man ganz simple die SQL-Kommandos ausführt
Ich habe dein Code als DB_Tuning.sql abgespeichert und mit sqlcmd -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query -i DB_Tuning.sql versucht auszuführen.
Ich erhalte jedoch nur folgende Meldung:
Changed database context to 'SUSDB'.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 5
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 5
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 5
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 7
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 5
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option.
Msg 155, Level 15, State 1, Server NWZWSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' is not a recognized CREATE INDEX option. Kannst du mir helfen? Vielen Dank!
Zitat von @MysticFoxDE:
Ich habe in der Vergangenheit viel von MS gehalten und tue das auch jetzt noch. Jedoch darf man unsere aktuelle Beziehung durchaus als angespannt betrachten.
Ja, MS hat auch schon früher versucht hier und da die eigenen Vorstellungen dem Kunden aufs Auge zu drücken, aber dennoch hat MS in der Vergangenheit auch viel Rücksicht auf den Wunsch des Kunden gelegt. Vor allem nicht nur auf die Wünsche der wenigen ganz Grossen, sondern auch auf die Wünsche der sehr vielen Mittleren bis Kleinen. Jüngst beobachte ich jedoch eine ganz andere Mentalität, ich würde diese verkürzt gerne als "Friss die Cloud oder stirb" bezeichnen.
Ich habe in der Vergangenheit viel von MS gehalten und tue das auch jetzt noch. Jedoch darf man unsere aktuelle Beziehung durchaus als angespannt betrachten.
Ja, MS hat auch schon früher versucht hier und da die eigenen Vorstellungen dem Kunden aufs Auge zu drücken, aber dennoch hat MS in der Vergangenheit auch viel Rücksicht auf den Wunsch des Kunden gelegt. Vor allem nicht nur auf die Wünsche der wenigen ganz Grossen, sondern auch auf die Wünsche der sehr vielen Mittleren bis Kleinen. Jüngst beobachte ich jedoch eine ganz andere Mentalität, ich würde diese verkürzt gerne als "Friss die Cloud oder stirb" bezeichnen.
Hi Alex,
in Deiner Schilderung erkenne ich mein eigenes Verhältnis zu MS wieder.
Bei mir war die Abkündigung des SBS der Auslöser für den Ansehensverlust.
mfg
kowa
1
Hallo Alex,
danke für den Beitrag. Eine Frage benutzt du SQL Express oder richtigen SQL Server. Hab momentan Problem das wir mit SQL Express die 10GB Grenze errecht haben, trotzdem Updates mit Powershell automatisch aufräumen und SQL Datenbank per Scrip aufgeräumt haben.
Will jetzt umstellen auf SQL Server, allerdings da wir 12 Wsus Server haben, wollte ich es zentrall auf einen SQL Server umstellen hofffe das es so klappt.
Grüß Aleksandar
danke für den Beitrag. Eine Frage benutzt du SQL Express oder richtigen SQL Server. Hab momentan Problem das wir mit SQL Express die 10GB Grenze errecht haben, trotzdem Updates mit Powershell automatisch aufräumen und SQL Datenbank per Scrip aufgeräumt haben.
Will jetzt umstellen auf SQL Server, allerdings da wir 12 Wsus Server haben, wollte ich es zentrall auf einen SQL Server umstellen hofffe das es so klappt.
Grüß Aleksandar
Moin Andre,
habe die gleiche Dresche gerade von meinem Kollegen bekommen. 🙃
Kein Problem, habe das Script soeben überarbeitet.
Nun kann man dieses, sowohl auf einer MS-SQL basierten SUSDB anwenden als auch auf einer WID basierten.
Als Entschädigung sind noch 3 weitere Indexe dazugekommen. 😀
- tbLocalizedPropertyForRevision_NGIS_01
- ivwApiUpdateRevision_NGIS_02
- tbUpdate_NGIS_01
Grüsse aus BaWü
Alex
habe die gleiche Dresche gerade von meinem Kollegen bekommen. 🙃
Kein Problem, habe das Script soeben überarbeitet.
Nun kann man dieses, sowohl auf einer MS-SQL basierten SUSDB anwenden als auch auf einer WID basierten.
Als Entschädigung sind noch 3 weitere Indexe dazugekommen. 😀
- tbLocalizedPropertyForRevision_NGIS_01
- ivwApiUpdateRevision_NGIS_02
- tbUpdate_NGIS_01
Grüsse aus BaWü
Alex
1
Moin Aleksandar,
Ich habe den angesprochene WSUS Server zu debug zwecken auf einem SQL 2019 Standard aufgesetzt damit ich den Abfragespeicher zur Analyse nutzen kann. Die jetzige SUSDB hat bei mir aktuell 14,5 GB.
Hast du schon versucht die Datenbank mal zu verkleinern?
Die meisten Aufräumscripte die ich bisher gesehen habe, löschen zwar die nicht mehr benötigten Daten aus der Datenbank, machen aber die Datenbank selbst nicht kleiner.
???
Das sollte eigentlich absolut kein Problem sein.
DB von A nach B migrieren (am besten die DB/Log Files rüberkopieren und am Ziel neu einbinden).
Berechtigungen in der DB prüfen/nachziehen.
Konfigfile des jeweiligen WSUS anpassen, fertig.
Nur der Neugierde halber, warum habt Ihr 12 WSUS Server?
Grüsse aus BaWü
Alex
Eine Frage benutzt du SQL Express oder richtigen SQL Server.
Ich habe den angesprochene WSUS Server zu debug zwecken auf einem SQL 2019 Standard aufgesetzt damit ich den Abfragespeicher zur Analyse nutzen kann. Die jetzige SUSDB hat bei mir aktuell 14,5 GB.
Hab momentan Problem das wir mit SQL Express die 10GB Grenze errecht haben, trotzdem Updates mit Powershell automatisch aufräumen und SQL Datenbank per Scrip aufgeräumt haben.
Hast du schon versucht die Datenbank mal zu verkleinern?
Die meisten Aufräumscripte die ich bisher gesehen habe, löschen zwar die nicht mehr benötigten Daten aus der Datenbank, machen aber die Datenbank selbst nicht kleiner.
???
Will jetzt umstellen auf SQL Server, allerdings da wir 12 Wsus Server haben, wollte ich es zentrall auf einen SQL Server umstellen hofffe das es so klappt.
Das sollte eigentlich absolut kein Problem sein.
DB von A nach B migrieren (am besten die DB/Log Files rüberkopieren und am Ziel neu einbinden).
Berechtigungen in der DB prüfen/nachziehen.
Konfigfile des jeweiligen WSUS anpassen, fertig.
Nur der Neugierde halber, warum habt Ihr 12 WSUS Server?
Grüsse aus BaWü
Alex
Moin,
danke dir für die Anpassung.
Ich bekomme noch zwei Fehler:
Zur Info: Ich benutze den SQL Express und habe die Treiber Updates deaktiviert.
Gefühlt läuft der Server aber schon deutlich besser!
Danke!
danke dir für die Anpassung.
Ich bekomme noch zwei Fehler:
Msg 1934, Level 16, State 1, Server NWZWSUS\MICROSOFT##WID, Line 2
CREATE INDEX failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations.
Msg 1934, Level 16, State 1, Server NWZWSUS\MICROSOFT##WID, Line 2
CREATE INDEX failed because the following SET options have incorrect settings: 'QUOTED_IDENTIFIER'. Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations. Zur Info: Ich benutze den SQL Express und habe die Treiber Updates deaktiviert.
Gefühlt läuft der Server aber schon deutlich besser!
Danke!
Ja hab die schon Datenbank verkleinen gemacht, leider kann man nichts mehr rausholen. Mache auch Monatlich den reindex der Datenbank so wie hier beschrieben:
https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-98 ...
Wir haben 12 Standorte und für jeden Standort einen Wsus Server vor Ort mit eigenen SQL Express Datenbank. Damit halt die Clients nicht die Standleitung blockieren und Updates von Server vor Ort runterladen. Sind bei grösseren Standorten ca. 30-40 Clients vor Ort.
Und wie du schon oben geschrieben hast, haben wir Surface Notebooks im Einsatz, deswegen benötigen wir die Treiber auf den Wsus aktiviert.
Wenn ich es aus den Link von oben mit den Best Practice richtig verstehe, schreibt Microsoft man kann mehrere WSUS Server betrieben mit eine gemeinsame Datenbank?
Für Datenbank umzug hab ich folgendes Link gefunden, wollte es so ausprobieren:
https://www.ugg.li/wsus-datenbank-verschieben-z-b-von-sql-2005-nach-sql2 ...
https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-98 ...
Wir haben 12 Standorte und für jeden Standort einen Wsus Server vor Ort mit eigenen SQL Express Datenbank. Damit halt die Clients nicht die Standleitung blockieren und Updates von Server vor Ort runterladen. Sind bei grösseren Standorten ca. 30-40 Clients vor Ort.
Und wie du schon oben geschrieben hast, haben wir Surface Notebooks im Einsatz, deswegen benötigen wir die Treiber auf den Wsus aktiviert.
Wenn ich es aus den Link von oben mit den Best Practice richtig verstehe, schreibt Microsoft man kann mehrere WSUS Server betrieben mit eine gemeinsame Datenbank?
Für Datenbank umzug hab ich folgendes Link gefunden, wollte es so ausprobieren:
https://www.ugg.li/wsus-datenbank-verschieben-z-b-von-sql-2005-nach-sql2 ...
Moin Andre,
ich denke nicht, dass es an der SQL Version liegt ... 🤔
Kann es sein, dass dein WSUS < 2019 ist?
Ich habe die oberen Optimierungen basierend aus einem aktuellen WSUS 2019 gemacht.
Es kann gut sein, dass das Script bei älteren nicht vollständig funktioniert, weil die entsprechende Tabellen und oder Felder gar nicht vorhanden sind.
Aus deiner Fehlermeldung kann ich leider absolut nicht erkennen, bei welchen Indexen die Probleme aufgetreten sind, aber ich habe da eine Vermutung, wahrscheinlich gleich bei den ersten beiden.
- ivwApiUpdateRevision_NGIS_01
- ivwApiUpdateRevision_NGIS_02
Kannst du bitte mal den folgenden Abschnitt erneut ausführen und schauen ob du dabei denselben Fehler bekommst.
???
Grüsse aus BaWü
Alex
Zur Info: Ich benutze den SQL Express und habe die Treiber Updates deaktiviert.
ich denke nicht, dass es an der SQL Version liegt ... 🤔
Kann es sein, dass dein WSUS < 2019 ist?
Ich habe die oberen Optimierungen basierend aus einem aktuellen WSUS 2019 gemacht.
Es kann gut sein, dass das Script bei älteren nicht vollständig funktioniert, weil die entsprechende Tabellen und oder Felder gar nicht vorhanden sind.
Aus deiner Fehlermeldung kann ich leider absolut nicht erkennen, bei welchen Indexen die Probleme aufgetreten sind, aber ich habe da eine Vermutung, wahrscheinlich gleich bei den ersten beiden.
- ivwApiUpdateRevision_NGIS_01
- ivwApiUpdateRevision_NGIS_02
Kannst du bitte mal den folgenden Abschnitt erneut ausführen und schauen ob du dabei denselben Fehler bekommst.
USE [SUSDB]
GO
CREATE NONCLUSTERED INDEX [ivwApiUpdateRevision_NGIS_01] ON [dbo].[ivwApiUpdateRevision]
(
[IsLatestRevision] ASC
)
INCLUDE([IsHidden],[IsLocallyPublished],[IsMandatory]) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [ivwApiUpdateRevision_NGIS_02] ON [dbo].[ivwApiUpdateRevision]
(
[UpdateID] ASC,
[IsLatestRevision] ASC,
[IsHidden] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO???
Grüsse aus BaWü
Alex
Moin Aleksandar,
das mit den 12 Standorten habe ich mir schon halber gedacht.
Wenn ich deinen Plan richtig verstanden habe, so möchtest du alle 12 SUSDBs auf einen zentralen SQL Standard Edition mit CORE Lizenzierung packen.
Wenn ja, dann würde ich dir gerne von dieser Idee abraten. Die WSUS "Applikation" plappert schon ganz schön viel und oft mit der SUSDB.
Die Reaktionszeit der SUSDB ist für einen stabilen WSUS Betrieb mehr als kriegsentscheidend. Bei WAN Verbindungen ist die SQL Performance meistens um Faktoren bescheidender als bei einer LAN Verbindung, da WAN's meistens eine höhere Latenz mit sich bringen als LAN's.
Ich sehe für dein Problem vielleicht eine entspanntere Lösung. 🙃
Lass mich noch eine Sache prüfen ...
Grüsse aus BaWü
Alex
das mit den 12 Standorten habe ich mir schon halber gedacht.
Wenn ich deinen Plan richtig verstanden habe, so möchtest du alle 12 SUSDBs auf einen zentralen SQL Standard Edition mit CORE Lizenzierung packen.
Wenn ja, dann würde ich dir gerne von dieser Idee abraten. Die WSUS "Applikation" plappert schon ganz schön viel und oft mit der SUSDB.
Die Reaktionszeit der SUSDB ist für einen stabilen WSUS Betrieb mehr als kriegsentscheidend. Bei WAN Verbindungen ist die SQL Performance meistens um Faktoren bescheidender als bei einer LAN Verbindung, da WAN's meistens eine höhere Latenz mit sich bringen als LAN's.
Ich sehe für dein Problem vielleicht eine entspanntere Lösung. 🙃
Lass mich noch eine Sache prüfen ...
Grüsse aus BaWü
Alex
Moin Aleksandar,
nochmals zu deinen 12 WSUS Server.
Ich denke du bist besser dran, wenn du die 12 WSUS Server auf WID anstelle vom MS-SQL aufsetzt/migrierst.
Es heisst zwar hier und da im Netz, dass die WID DBs ebenfalls der 10 GByte Grenze unterliegen, aber das stimmt so nicht.
Mein Kollege hat gestern einen 2019er WSUS der auf einer WID aufgesetzt ist, optimiert und die Treiber aktiviert.
Nach dem Sync der Nachts gelaufen ist, ist die SUSDB nun auf knapp 13 GByte angewachsen (~ 160.000 Definitionen).
Der WSUS läuft bisher ohne Probleme. 😀
Der Vollständigkeit halber, der angesprochene WSUS hat 4 Kerne und 16GB RAM, darunter würde ich nicht empfehlen.
Ferner ist der 2019er WSUS (VM) noch mit dem Folgenden optimiert ...
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
&
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
😎
Grüsse aus BaWü
Alex
nochmals zu deinen 12 WSUS Server.
Ich denke du bist besser dran, wenn du die 12 WSUS Server auf WID anstelle vom MS-SQL aufsetzt/migrierst.
Es heisst zwar hier und da im Netz, dass die WID DBs ebenfalls der 10 GByte Grenze unterliegen, aber das stimmt so nicht.
Mein Kollege hat gestern einen 2019er WSUS der auf einer WID aufgesetzt ist, optimiert und die Treiber aktiviert.
Nach dem Sync der Nachts gelaufen ist, ist die SUSDB nun auf knapp 13 GByte angewachsen (~ 160.000 Definitionen).
Der WSUS läuft bisher ohne Probleme. 😀
Der Vollständigkeit halber, der angesprochene WSUS hat 4 Kerne und 16GB RAM, darunter würde ich nicht empfehlen.
Ferner ist der 2019er WSUS (VM) noch mit dem Folgenden optimiert ...
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
&
https://community.spiceworks.com/topic/2225989-server-2019-network-perfo ...
😎
Grüsse aus BaWü
Alex
Hallo,
mich würde in dem Zusammenhang interessieren, inwieweit das hier noch aktuell ist: WSUS auf einem SBS2011 reparieren (Timeout)
Liebe Grüße aus Bremen,
Jörg
mich würde in dem Zusammenhang interessieren, inwieweit das hier noch aktuell ist: WSUS auf einem SBS2011 reparieren (Timeout)
Liebe Grüße aus Bremen,
Jörg
Moin Jörg,
ich verstehe die Frage zwar nicht ganz versuche die aber dennoch zu beantworten. 🙃
In dem Link den du geschickt hast werden viele Bereinigungsschritte einzeln erwähnt die auch auf einen heutigen WSUS anwendbar wären.
Das Thema mit der Reindizierung (Schritt 3) haben wir hier ja z.B. auch schon angesprochen gehabt, ist somit noch nach wie vor mehr als aktuell.
Es gibt schon seit Langem ein Script welches die WSUS Wartung relativ gut im Griff hält, folgend der Link dazu.
https://gallery.technet.microsoft.com/WSUS-cleanup-script-7e019537
In Summe kann ich stand heute aber schon mal folgendes sagen, mit den oben erwähnten Indexen schnurrt jeder WSUS den wir bisher optimiert haben wie ein zahmes Kätzchen. Mann muss dafür lediglich beim Installieren auf die richtige DB Art achten.
Wenn mann alles über den WSUS ziehen möchte (Updates, Upgrade und vor allem Treiber) dann darf mann auf keinen Fall eine SQL Express basierte DB verwenden. Diese ist auf eine maximale Grösse von 10GB limitiert und das recht weder vorne noch hinten für alles aus.
Wenn mann alles über den WSUS bereitstellen möchte, dann hat die DB nach der Erstsynchronisation bereits mehr als 12 GB!
In so einem Fall kann man entweder auf die interne WID zurückgreifen, die im Grunde auch nichts anderes als eine SQL Express ist, jedoch gilt hier das 10GB Limit nicht, aber du kannst auch nicht jeden Index anlegen, da die maximale Indexgrösse doch sehr mager ausgelegt ist.
Am besten eignet sich eine Standard SQL Installation. Bei dieser kann man sowohl die Reindizierung über die Wartungspläne automatisiert durchlaufen lassen, als auch bessere Indexe anlegen, die die Performance nochmals verbessern und auch die Auslastung minimieren.
Aber wir kennen glaube ich beide den Nachteil meines letzten Vorschlages. Günstig ist es nicht, da die SQL Server Lizenz & evtl. SQL-CALs noch zusätzlich erworben werden müssen.
Grüsse aus BaWü
Alex
mich würde in dem Zusammenhang interessieren, inwieweit das hier noch aktuell ist: WSUS auf einem SBS2011 reparieren (Timeout)
ich verstehe die Frage zwar nicht ganz versuche die aber dennoch zu beantworten. 🙃
In dem Link den du geschickt hast werden viele Bereinigungsschritte einzeln erwähnt die auch auf einen heutigen WSUS anwendbar wären.
Das Thema mit der Reindizierung (Schritt 3) haben wir hier ja z.B. auch schon angesprochen gehabt, ist somit noch nach wie vor mehr als aktuell.
Es gibt schon seit Langem ein Script welches die WSUS Wartung relativ gut im Griff hält, folgend der Link dazu.
https://gallery.technet.microsoft.com/WSUS-cleanup-script-7e019537
In Summe kann ich stand heute aber schon mal folgendes sagen, mit den oben erwähnten Indexen schnurrt jeder WSUS den wir bisher optimiert haben wie ein zahmes Kätzchen. Mann muss dafür lediglich beim Installieren auf die richtige DB Art achten.
Wenn mann alles über den WSUS ziehen möchte (Updates, Upgrade und vor allem Treiber) dann darf mann auf keinen Fall eine SQL Express basierte DB verwenden. Diese ist auf eine maximale Grösse von 10GB limitiert und das recht weder vorne noch hinten für alles aus.
Wenn mann alles über den WSUS bereitstellen möchte, dann hat die DB nach der Erstsynchronisation bereits mehr als 12 GB!
In so einem Fall kann man entweder auf die interne WID zurückgreifen, die im Grunde auch nichts anderes als eine SQL Express ist, jedoch gilt hier das 10GB Limit nicht, aber du kannst auch nicht jeden Index anlegen, da die maximale Indexgrösse doch sehr mager ausgelegt ist.
Am besten eignet sich eine Standard SQL Installation. Bei dieser kann man sowohl die Reindizierung über die Wartungspläne automatisiert durchlaufen lassen, als auch bessere Indexe anlegen, die die Performance nochmals verbessern und auch die Auslastung minimieren.
Aber wir kennen glaube ich beide den Nachteil meines letzten Vorschlages. Günstig ist es nicht, da die SQL Server Lizenz & evtl. SQL-CALs noch zusätzlich erworben werden müssen.
Grüsse aus BaWü
Alex
Danke für Deine Mühe und dass Du diese Infos mit uns teilst.
Es hat mir geholfen, dass der WSUS nun schnurrt und "Alle Updates Alles Anzeigen" auch zügig auwirft.
Wenn ich Dir nen Kaffee per PayPal ausgeben kann, lass es mich wissen.
Es hat mir geholfen, dass der WSUS nun schnurrt und "Alle Updates Alles Anzeigen" auch zügig auwirft.
Wenn ich Dir nen Kaffee per PayPal ausgeben kann, lass es mich wissen.
Moin Pcpanik,
Gern geschehen, ist für mich selbstverständlich, gibt eh viel zu Wenige von uns und ich sehe täglich welchen Qualen diese durch den Murks der grossen ausgesetzt werden.
Ich muss den Beitrag demnächst aktualisieren, da ich mittlerweile noch ein paar weitere (fehlende) Indexe ergänzt habe.
Vielleicht läuft man sich ja auch im realen Leben mal über den Weg, dann können wir auch gerne ein Bierchen trinken.
Gruss Alex
Danke für Deine Mühe und dass Du diese Infos mit uns teilst.
Gern geschehen, ist für mich selbstverständlich, gibt eh viel zu Wenige von uns und ich sehe täglich welchen Qualen diese durch den Murks der grossen ausgesetzt werden.
Es hat mir geholfen, dass der WSUS nun schnurrt und "Alle Updates Alles Anzeigen" auch zügig auwirft.
Ich muss den Beitrag demnächst aktualisieren, da ich mittlerweile noch ein paar weitere (fehlende) Indexe ergänzt habe.
Wenn ich Dir nen Kaffee per PayPal ausgeben kann, lass es mich wissen.
Vielleicht läuft man sich ja auch im realen Leben mal über den Weg, dann können wir auch gerne ein Bierchen trinken.
Gruss Alex
Vielen Dank in jedem Fall, und ich werde Deinen Beitrag beobachten und dann die entsprechenden Indexe nachziehen lassen und natürlich weiter empfehlen, denn diese WSUS Fehler begleiten ja leider viele Admins, seit seinem Erscheinen.
Ggf. wären ein par Tags wie ID 7053, ID 7032, Serverknoten zurücksetzen noch Hilfreich um bei der Internetrecherche schneller darauf zu stoßen.
Ggf. wären ein par Tags wie ID 7053, ID 7032, Serverknoten zurücksetzen noch Hilfreich um bei der Internetrecherche schneller darauf zu stoßen.
Hallo Alex,
ich wollte mal nachfragen, ob Du die weiteren Indexe in deinem Beitrag ergänzen könntest, bitte? Ich stoße inzwischen wieder auf das Problemchen mit dem "Serverknoten zurücksetzen", wenn ich größere Abfragen mache.
Natürlich Indexieren wir die SUSDB nun regelmäßig.
Würde mich freuen von Dir zu lesen.
Gruß,
Patrick
ich wollte mal nachfragen, ob Du die weiteren Indexe in deinem Beitrag ergänzen könntest, bitte? Ich stoße inzwischen wieder auf das Problemchen mit dem "Serverknoten zurücksetzen", wenn ich größere Abfragen mache.
Natürlich Indexieren wir die SUSDB nun regelmäßig.
Würde mich freuen von Dir zu lesen.
Gruß,
Patrick
ID 7053 kommt mir bekannt vor, versuch mal diesen hier:
https://www.dacomsys.de/wsus-verbindungsfehler-serverknoten-zuruecksetze ...
https://www.dacomsys.de/wsus-verbindungsfehler-serverknoten-zuruecksetze ...
Moin Patrick,
sorry, ich finde jetzt auf die schnelle nicht die Aufschriebe die ich damals gemacht habe und muss nun die Indexe aus einem der bereits optimierten WSUS-Server ziehen. Das schaffe ich aber frühestens nächste Woche.
Grüsse aus BaWü
Alex
sorry, ich finde jetzt auf die schnelle nicht die Aufschriebe die ich damals gemacht habe und muss nun die Indexe aus einem der bereits optimierten WSUS-Server ziehen. Das schaffe ich aber frühestens nächste Woche.
Grüsse aus BaWü
Alex
Das mit dem Speicherlimit habe ich schon ausgeführt gehabt. Aber Danke sehr.
Danke Dir, kein Stress deswegen. Wenn Du mal Zeit findest, wäre es einfach super nett.
Moin Patrik,
sorry, hat jetzt doch ne Weile gedauert.
Ich habe soeben im Hauptpost das SQL für die Indexe aktualisiert.
Die folgenden Indexe sind dazugekommen:
Grüsse aus BaWü
Alex
sorry, hat jetzt doch ne Weile gedauert.
Ich habe soeben im Hauptpost das SQL für die Indexe aktualisiert.
Die folgenden Indexe sind dazugekommen:
USE [SUSDB]
GO
CREATE NONCLUSTERED INDEX [tbXml_NGIS_01] ON [dbo].[tbXml]
(
[RootElementType] ASC,
[LanguageID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbProperty_NGIS_03] ON [dbo].[tbProperty]
(
[DefaultPropertiesLanguageID] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
DROP INDEX [c0ChangeTracking] ON [dbo].[tbChangeTracking] WITH ( ONLINE = OFF )
GO
CREATE CLUSTERED INDEX [c0ChangeTracking] ON [dbo].[tbChangeTracking]
(
[ChangeNumber] DESC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/****** nur auf MS-SQL nicht auf WID ******/
CREATE NONCLUSTERED INDEX [tbFrontEndServersHealth_NGIS_01] ON [dbo].[tbFrontEndServersHealth]
(
[ServerName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbFrontEndServersHealth_NGIS_02] ON [dbo].[tbFrontEndServersHealth]
(
[ComponentName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/****** nur auf MS-SQL nicht auf WID ******/
CREATE NONCLUSTERED INDEX [tbReference_NGIS_01] ON [dbo].[tbReference]
(
[NLBMasterFrontEndServer] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbSchedule_NGIS_01] ON [dbo].[tbSchedule]
(
[ScheduleTarget] ASC,
[ScheduleID] ASC,
[ScheduledRunTime] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/****** nur auf MS-SQL nicht auf WID ******/
CREATE NONCLUSTERED INDEX [tbConfiguration_NGIS_01] ON [dbo].[tbConfiguration]
(
[Name] ASC,
[Value] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbFile_NGIS_01] ON [dbo].[tbFile]
(
[IsEula] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
CREATE NONCLUSTERED INDEX [tbEventInstance_NGIS_01] ON [dbo].[tbEventInstance]
(
[EventNamespaceID] ASC,
[TimeAtServer] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]Grüsse aus BaWü
Alex
Hallo Alex,
ich sage ganz ganz ganz herzlchen Dank für Deine Mühe. Ich sehe es heute erst. Die Benachrichtigung ist mir da durch gegangen.
HG,
Patrick
ich sage ganz ganz ganz herzlchen Dank für Deine Mühe. Ich sehe es heute erst. Die Benachrichtigung ist mir da durch gegangen.
HG,
Patrick
Hallo Alex!
Vielen Dank für deine Arbeit, der Beitrag sollte jedem WSUS Admin empfohlen werden!
Ich möchte mich beim Beitrag von Andre1988 vom 10.03.2020 um 11:04 Uhr anschließen.
Ich bekomme ebenfalls die beiden Fehler, zusätzlich noch 2 weitere.
Ich habe dann deinen Vorschlag vom 10.03.2020 um 19:27 Uhr, die beiden Indexe ivwApiUpdateRevision_NGIS_01 und ivwApiUpdateRevision_NGIS_02 nochmal neu zu erstellen ausgeführt und bekomme exakt diese Meldungen.
Ich habe alles der Reihe nach in die SQLCMD eingegeben.
Andre hat sich damals nicht mehr gemeldet, deshalb mache ich das jetzt.
Vielleicht fällt dir dazu ja etwas ein, was der Fehler sein könnte.
Mein System ist SRV2019 und WID.
Zu Fehler 3, wurde dadurch verursacht:
Fehler 4 hat sich beim schrittweisen abarbeiten nicht reproduzieren lassen.
Mir ist auch noch aufgefallen, dass der manuelle Durchlauf diesen Index angelegt hat, dürfte beim Skript nicht funktioniert haben:
Vielleicht hast du ja irgendwann mal Zeit dir das anzuschauen.
Jedenfalls danke nochmal für deine super Arbeit!
LG,
Christoph.
Vielen Dank für deine Arbeit, der Beitrag sollte jedem WSUS Admin empfohlen werden!
Ich möchte mich beim Beitrag von Andre1988 vom 10.03.2020 um 11:04 Uhr anschließen.
Ich bekomme ebenfalls die beiden Fehler, zusätzlich noch 2 weitere.
Msg 1934, Level 16, State 1, Server WSUS\MICROSOFT##WID, Line 2
Fehler bei CREATE INDEX, da die folgenden SET-Optionen falsche Einstellungen aufweisen: 'QUOTED_IDENTIFIER'. Überprüfen Sie, ob die SET-Optionen für die Verwendung mit indizierte Sichten und/oder Indizes für berechnete Spalten und/oder gefilterte Indizes und/oder Abfragebenachrichtigungen und/oder XML-Datentypmethoden und/oder Vorgänge für räumliche Indizes richtig sind. Msg 1934, Level 16, State 1, Server WSUS\MICROSOFT##WID, Line 2
Fehler bei CREATE INDEX, da die folgenden SET-Optionen falsche Einstellungen aufweisen: 'QUOTED_IDENTIFIER'. Überprüfen Sie, ob die SET-Optionen für die Verwendung mit indizierte Sichten und/oder Indizes für berechnete Spalten und/oder gefilterte Indizes und/oder Abfragebenachrichtigungen und/oder XML-Datentypmethoden und/oder Vorgänge für räumliche Indizes richtig sind. Msg 155, Level 15, State 1, Server WSUS\MICROSOFT##WID, Line 6
'OPTIMIZE_FOR_SEQUENTIAL_KEY' wird nicht als Option für CREATE INDEX erkannt. Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbFrontEndServersHealth_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.Ich habe dann deinen Vorschlag vom 10.03.2020 um 19:27 Uhr, die beiden Indexe ivwApiUpdateRevision_NGIS_01 und ivwApiUpdateRevision_NGIS_02 nochmal neu zu erstellen ausgeführt und bekomme exakt diese Meldungen.
Ich habe alles der Reihe nach in die SQLCMD eingegeben.
Andre hat sich damals nicht mehr gemeldet, deshalb mache ich das jetzt.
Vielleicht fällt dir dazu ja etwas ein, was der Fehler sein könnte.
Mein System ist SRV2019 und WID.
Zu Fehler 3, wurde dadurch verursacht:
CREATE NONCLUSTERED INDEX [tbEventInstance_NGIS_01] ON [dbo].[tbEventInstance]
(
[EventNamespaceID] ASC,
[TimeAtServer] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, OPTIMIZE_FOR_SEQUENTIAL_KEY = OFF) ON [PRIMARY]
GOMsg 155, Level 15, State 1, Server WSUS\MICROSOFT##WID, Line 5
'OPTIMIZE_FOR_SEQUENTIAL_KEY' wird nicht als Option für CREATE INDEX erkannt. Fehler 4 hat sich beim schrittweisen abarbeiten nicht reproduzieren lassen.
Mir ist auch noch aufgefallen, dass der manuelle Durchlauf diesen Index angelegt hat, dürfte beim Skript nicht funktioniert haben:
CREATE CLUSTERED INDEX [c0ChangeTracking] ON [dbo].[tbChangeTracking]
(
[ChangeNumber] DESC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GOVielleicht hast du ja irgendwann mal Zeit dir das anzuschauen.
Jedenfalls danke nochmal für deine super Arbeit!
LG,
Christoph.
Moin Christoph,
Vielen Dank.
Ich möchte an dieser Stelle jedoch gerne eine alternative Lösung empfehlen.
https://www.ajtek.ca/
Ich habe bei Spiceworks einen englischsprachigen Schwesterbeitrag gepostet gehabt.
Darüber ist einer der AJTEK Entwickler gestolpert und dieser fand meinen Ansatz auch sehr interessant und hat
so wie es aussieht, die Optimierung der Indexe auch ins WAM integriert.
Die Jungs und Mädels von AJTEK haben viel mehr Erfahrung mit dem WSUS wie ich.
Ich gehe daher davon aus, dass die nicht nur die Indexe 1:1 von meinem Spiceworks Beitrag übernommen, sondern den einen oder anderen auch noch zusätzlich hinzugefügt haben. Ausserdem optimiert WAM den WSUS noch an diversen weiteren Stellen, korrigiert den einen oder anderen Fehler und kostet gerade mal 60$/Jahr.
😬 ups, diese Indexe kannst du bei dir nicht benutzen, sorry mein Fehler.
Der Grund ist der folgende, ich habe die letzten Optimierungen auf einem WSUS gemacht, dessen Datenbank nicht als WID läuft sondern
auf einem "erwachsenen" Standard SQL Server. Auf den normalen SQL Servern (Standard/Enterprise) kannst du viel grössere Indexe anlegen als dies bei der WID oder auch beim Express SQL Server möglich ist. Ich kommentiere gleich in den oberen Scripten mit dazu, dass diese, bei einer WID nicht ausgeführt werden sollten.
Beste Grüsse aus BaWü
Alex
Zitat von @Stoffi77:
Vielen Dank für deine Arbeit, der Beitrag sollte jedem WSUS Admin empfohlen werden!
Vielen Dank für deine Arbeit, der Beitrag sollte jedem WSUS Admin empfohlen werden!
Vielen Dank.
Ich möchte an dieser Stelle jedoch gerne eine alternative Lösung empfehlen.
https://www.ajtek.ca/
Ich habe bei Spiceworks einen englischsprachigen Schwesterbeitrag gepostet gehabt.
Darüber ist einer der AJTEK Entwickler gestolpert und dieser fand meinen Ansatz auch sehr interessant und hat
so wie es aussieht, die Optimierung der Indexe auch ins WAM integriert.
Die Jungs und Mädels von AJTEK haben viel mehr Erfahrung mit dem WSUS wie ich.
Ich gehe daher davon aus, dass die nicht nur die Indexe 1:1 von meinem Spiceworks Beitrag übernommen, sondern den einen oder anderen auch noch zusätzlich hinzugefügt haben. Ausserdem optimiert WAM den WSUS noch an diversen weiteren Stellen, korrigiert den einen oder anderen Fehler und kostet gerade mal 60$/Jahr.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbFrontEndServersHealth_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
😬 ups, diese Indexe kannst du bei dir nicht benutzen, sorry mein Fehler.
Der Grund ist der folgende, ich habe die letzten Optimierungen auf einem WSUS gemacht, dessen Datenbank nicht als WID läuft sondern
auf einem "erwachsenen" Standard SQL Server. Auf den normalen SQL Servern (Standard/Enterprise) kannst du viel grössere Indexe anlegen als dies bei der WID oder auch beim Express SQL Server möglich ist. Ich kommentiere gleich in den oberen Scripten mit dazu, dass diese, bei einer WID nicht ausgeführt werden sollten.
Beste Grüsse aus BaWü
Alex
Moin Christoph,
kleiner Nachtrag, habe die oberen Scripte korrigiert, der folgende Fehler sollte nicht mehr auftauchen.
Gruss Alex
kleiner Nachtrag, habe die oberen Scripte korrigiert, der folgende Fehler sollte nicht mehr auftauchen.
> Msg 155, Level 15, State 1, Server WSUS\MICROSOFT##WID, Line 6
> 'OPTIMIZE_FOR_SEQUENTIAL_KEY' wird nicht als Option für CREATE INDEX erkannt.
> Gruss Alex
Hi Alex,
coole Sache die du angefangen hast. Wir haben auch zwei Kleinigkeiten die angemeckert werden vom Skript:
Das der Index vorhanden ist, kann man wohl ignorieren.
Viele Grüße
coole Sache die du angefangen hast. Wir haben auch zwei Kleinigkeiten die angemeckert werden vom Skript:
Der Datenbankkontext wurde in 'SUSDB' geändert.
Msg 1934, Level 16, State 1, Server HOST\MICROSOFT##WID, Line 2
Fehler bei CREATE INDEX, da die folgenden SET-Optionen falsche Einstellungen aufweisen: 'QUOTED_IDENTIFIER'. Überprüfen Sie, ob die SET-Optionen für die Verwendung mit indizierte Sichten und/oder Indizes für berechnete Spalten und/oder gefilterte Indizes und/oder Abfragebenachrichtigungen und/oder XML-Datentypmethoden und/oder Vorgänge für räumliche Indizes richtig sind.
Msg 1934, Level 16, State 1, Server HOST\MICROSOFT##WID, Line 2
Fehler bei CREATE INDEX, da die folgenden SET-Optionen falsche Einstellungen aufweisen: 'QUOTED_IDENTIFIER'. Überprüfen Sie, ob die SET-Optionen für die Verwendung mit indizierte Sichten und/oder Indizes für berechnete Spalten und/oder gefilterte Indizes und/oder Abfragebenachrichtigungen und/oder XML-Datentypmethoden und/oder Vorgänge für räumliche Indizes richtig sind.
Msg 1913, Level 16, State 1, Server HOST\MICROSOFT##WID, Line 2
Fehler bei dem Vorgang, weil ein Index oder eine Statistik mit dem Namen 'tbCategory_NGIS_01' für 'dbo.tbCategory' (Tabelle) bereits vorhanden ist. Viele Grüße
Hallo CH3COOH!
Wenn Meldungen mit 'QUOTED_IDENTIFIER' kommen, dann setze "SET QUOTED_IDENTIFIER ON;" rein, bevor die Index Erstellung los geht.
Bei mir kommt die Meldung ansonsten öfter als nur 2 Mal.
Bei mir hat das geholfen.
LG
Wenn Meldungen mit 'QUOTED_IDENTIFIER' kommen, dann setze "SET QUOTED_IDENTIFIER ON;" rein, bevor die Index Erstellung los geht.
Bei mir kommt die Meldung ansonsten öfter als nur 2 Mal.
USE [SUSDB]
GO
SET QUOTED_IDENTIFIER ON;Bei mir hat das geholfen.
LG
1
Hi CH3COOH,
sorry für die späte Antwort, hatte die Tage echt viel um die Ohren.
danke, war aber nicht ganz freiwillig.
Irgendwann hatte ich die Anrufe der Kunden bez. der hängenden WSUS-Server einfach nur satt.
So wie es aussieht, werden alle Fehler durch "Line 2" des Skriptes verursacht.
Sprich, in allen drei Fällen ist das Problem dasselbe. --> bereits vorhandener Index
Wie ich schon in einem Post weiter oben geschrieben habe, habe ich lediglich den Anfang gemacht.
Die Jungs von ajtek/WAM haben diese Optimierungsmöglichkeit dann übernommen und so wie ich die einschätze,
bereits schon kräftig ausgebaut. 😉
Beste Grüsse aus BaWü
Alex
sorry für die späte Antwort, hatte die Tage echt viel um die Ohren.
coole Sache die du angefangen hast.
danke, war aber nicht ganz freiwillig.
Irgendwann hatte ich die Anrufe der Kunden bez. der hängenden WSUS-Server einfach nur satt.
Wir haben auch zwei Kleinigkeiten die angemeckert werden ...
So wie es aussieht, werden alle Fehler durch "Line 2" des Skriptes verursacht.
Sprich, in allen drei Fällen ist das Problem dasselbe. --> bereits vorhandener Index
Wie ich schon in einem Post weiter oben geschrieben habe, habe ich lediglich den Anfang gemacht.
Die Jungs von ajtek/WAM haben diese Optimierungsmöglichkeit dann übernommen und so wie ich die einschätze,
bereits schon kräftig ausgebaut. 😉
Beste Grüsse aus BaWü
Alex
1
Moin moin,
der Beitrag ist schon länger hier, aber offensichtlich immer noch tagesaktuell
Ich hätte da eine Frage in Bezug auf den Code für die Datenbank:
Ich nutze die WID und sehe da zweimal den Eintrag, dass das nur für MSSQL gilt. Gilt das nur bis zum nächsten GO oder ist alles ab da nur noch für MSSQL gedacht? Ich habe jetzt sicherheitshalber erstmal nur bis zum ersten Kommentar das Skript ausgeführt - den Rest kann ich ja ggf. nachziehen
Viele Grüße und vielen Dank für diesen tollen Beitrag
der Beitrag ist schon länger hier, aber offensichtlich immer noch tagesaktuell
Ich hätte da eine Frage in Bezug auf den Code für die Datenbank:
Ich nutze die WID und sehe da zweimal den Eintrag, dass das nur für MSSQL gilt. Gilt das nur bis zum nächsten GO oder ist alles ab da nur noch für MSSQL gedacht? Ich habe jetzt sicherheitshalber erstmal nur bis zum ersten Kommentar das Skript ausgeführt - den Rest kann ich ja ggf. nachziehen
Viele Grüße und vielen Dank für diesen tollen Beitrag
Moin Samoangtagey,
ja, sieht leider so aus, als ob Microsoft seine QS immer noch nicht wiedergefunden hat. 🙃
Diese "Beschränkung" gilt nur für den jeweiligen Index, sprich nur bis zu nächstem GO.
Danke und Gerne.
Beste Grüsse aus BaWü
Alex
der Beitrag ist schon länger hier, aber offensichtlich immer noch tagesaktuell
ja, sieht leider so aus, als ob Microsoft seine QS immer noch nicht wiedergefunden hat. 🙃
Gilt das nur bis zum nächsten GO oder ist alles ab da nur noch für MSSQL gedacht?
Diese "Beschränkung" gilt nur für den jeweiligen Index, sprich nur bis zu nächstem GO.
Viele Grüße und vielen Dank für diesen tollen Beitrag
Danke und Gerne.
Beste Grüsse aus BaWü
Alex
Hallo,
Leider habe ich den Teil weiter unten erst später gelesen und habe die beiden Indexe auch erzeugt:
/ nur auf MS-SQL nicht auf WID /
CREATE NONCLUSTERED INDEX [tbFrontEndServersHealth_NGIS_01] ON [dbo].[tbFrontEndServersHealth]
(
[ServerName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/ nur auf MS-SQL nicht auf WID /
CREATE NONCLUSTERED INDEX [tbReference_NGIS_01] ON [dbo].[tbReference]
(
[NLBMasterFrontEndServer] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
Wie kann ich die wieder löschen @MysticFoxDE?
Oder kann man die da lassen?
Danke und Gruß
Leider habe ich den Teil weiter unten erst später gelesen und habe die beiden Indexe auch erzeugt:
/ nur auf MS-SQL nicht auf WID /
CREATE NONCLUSTERED INDEX [tbFrontEndServersHealth_NGIS_01] ON [dbo].[tbFrontEndServersHealth]
(
[ServerName] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
/ nur auf MS-SQL nicht auf WID /
CREATE NONCLUSTERED INDEX [tbReference_NGIS_01] ON [dbo].[tbReference]
(
[NLBMasterFrontEndServer] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO
Wie kann ich die wieder löschen @MysticFoxDE?
Oder kann man die da lassen?
Danke und Gruß
Moin @deathman,
das ist eigentlich nicht schlimm, normalerweise hätten diese Indexe auf einer WID gar nicht angelegt werden können.
Am einfachsten über den SSMS.
(Der Screenshot ist von einer anderen Datenbank, das Vorgehen ist jedoch dasselbe)
1. SUSDB Aufklappen
2. Tabellen Aufklappen
3. Entsprechende Tabelle finden und aufklappen (in deinem Fall ist das "tbFrontEndServersHealth" & "tbReference" )
4. Indizes Aufklappen
5. Entsprechenden Index finden ("tbFrontEndServersHealth_NGIS_01" oder "tbReference_NGIS_01") und mit der rechten Maustaste draufklicken.
6. Löschen auswählen, bestätigen und weg ist der Index.
Wenn die wirklich erstellt wurden, dann kannst du die normalerweise auch lassen.
Was für eine WSUS Version verwendest du eigentlich?
Beste Grüsse aus BaWü
Alex
Leider habe ich den Teil weiter unten erst später gelesen und habe die beiden Indexe auch erzeugt.
das ist eigentlich nicht schlimm, normalerweise hätten diese Indexe auf einer WID gar nicht angelegt werden können.
Wie kann ich die wieder löschen @MysticFoxDE?
Am einfachsten über den SSMS.
1. SUSDB Aufklappen
2. Tabellen Aufklappen
3. Entsprechende Tabelle finden und aufklappen (in deinem Fall ist das "tbFrontEndServersHealth" & "tbReference" )
4. Indizes Aufklappen
5. Entsprechenden Index finden ("tbFrontEndServersHealth_NGIS_01" oder "tbReference_NGIS_01") und mit der rechten Maustaste draufklicken.
6. Löschen auswählen, bestätigen und weg ist der Index.
Oder kann man die da lassen?
Wenn die wirklich erstellt wurden, dann kannst du die normalerweise auch lassen.
Was für eine WSUS Version verwendest du eigentlich?
Beste Grüsse aus BaWü
Alex
Moin moin,
ich arbeite im Moment noch mit einem Windows Server 2019 und habe grad festgestellt, dass ich mit der Lizenz auch auf 2022 umsteigen könnte. Macht das Sinn? Ich benutze den Server ohnehin ausschließlich für WSUS, ansonsten macht der nichts. Wenn sich also für WSUS ohnehin nichts ändern sollte, wäre ein Umzug im Moment reine Arbeitsbeschaffungsmaßnahme.
Gibt es dazu Erfahrungswerte?
Viele Grüße aus SH
Thomas
ich arbeite im Moment noch mit einem Windows Server 2019 und habe grad festgestellt, dass ich mit der Lizenz auch auf 2022 umsteigen könnte. Macht das Sinn? Ich benutze den Server ohnehin ausschließlich für WSUS, ansonsten macht der nichts. Wenn sich also für WSUS ohnehin nichts ändern sollte, wäre ein Umzug im Moment reine Arbeitsbeschaffungsmaßnahme.
Gibt es dazu Erfahrungswerte?
Viele Grüße aus SH
Thomas
Danke für die Anleitung
Ich habe das Script aus deinem ersten Post genommen.
Dabei gab es die Meldung:
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbFrontEndServersHealth_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Der Wsus ist ein Server 2019, der vor ein paar Tagen installiert wurde.
Ich habe das Script aus deinem ersten Post genommen.
Dabei gab es die Meldung:
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbFrontEndServersHealth_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Der Wsus ist ein Server 2019, der vor ein paar Tagen installiert wurde.
Moin @deathman,
😬, dann wird der Index doch unvollständig angelegt ... das ist nicht gut ... bitte den entsprechenden Index wieder löschen.
Gruss Alex
Dabei gab es die Meldung:
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbFrontEndServersHealth_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbFrontEndServersHealth_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
Warnung: Die maximale Schlüssellänge beträgt 900 Bytes. Der tbReference_NGIS_01-Index hat eine maximale Länge von 2048 Bytes. Bei einigen Kombinationen hoher Werte schlägt der INSERT-/UPDATE-Vorgang fehl.
😬, dann wird der Index doch unvollständig angelegt ... das ist nicht gut ... bitte den entsprechenden Index wieder löschen.
Gruss Alex
Hab ich gemacht 😉, nachdem ich gemerkt habe das der Server damit nicht mehr wirklich rennt 😁. Da hilft dann leider nur Neuinstallation.
Vll. den Teil mit der Wid im ersten Post in einen 2ten Code Block packen. Dann passiert das nicht noch einen 😉.
Vll. den Teil mit der Wid im ersten Post in einen 2ten Code Block packen. Dann passiert das nicht noch einen 😉.
