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]
Please also mark the comments that contributed to the solution of the article
Content-ID: 554097
Url: https://administrator.de/contentid/554097
Printed on: October 11, 2024 at 15:10 o'clock
44 Comments
Latest comment
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
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
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,
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 ...
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
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 ...
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]
GO
Msg 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]
GO
Vielleicht hast du ja irgendwann mal Zeit dir das anzuschauen.
Jedenfalls danke nochmal für deine super Arbeit!
LG,
Christoph.
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
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
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 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.