Hallo zusammen,

nur mal aus Neugierde, ob noch jemand etwas Vergleichbares beobachtet hat.

Wir haben angefangen einige Windows-Rechner auf 1903 zu upgraden. Und hatten kurz darauf massive Performance-Einbrüche am WSUS, sodass wir mittlerweile die WSUS-Rolle komplett neu installiert und wieder bei Null angefangen haben. Aber schon 2 Tage später fangen die Probleme erneut an.

Es hat sich nun gezeigt, dass die tbEventInstance-Tabelle in der SUSDB extrem schnell wächst. Und weiter hat sich gezeigt, dass es die 1903er Clients sind, die hier endlos Einträge generieren. Ein Client hat es alleine innerhalb von den zwei Tagen auf 561.798 Einträge gebracht. Alle beziehen sich auf EventID 182 (= "Installation Failure: Windows failed to install the following update with error %1: %2.") und es betrifft immer das Update 52DD0FB8-2165-4E8F-B7CD-7B8D46157BE9. Allerdings kann ich zu diesem Update keinen Namen finden.

Hat jemand etwas Ähnliches beobachtet? Ich kann mir nicht denken, was die 1903er Rechner so aus dem Tritt bringt.

Würde mich über Rückmeldungen freuen.

Danke und viele Grüße
   


PS: Nicht schön, aber läuft ... mit dieser SQL-Abfrage habe ich das bei mir rausbekommen.

use susdb;
SELECT ei.ComputerID, count(*) as anzahl, ct.FullDomainName, ctd.OSMajorVersion, ctd.OSMinorVersion, ctd.OSBuildNumber, ei.EventID
FROM tbEventInstance as ei
join dbo.tbComputerTarget as ct
  on ct.ComputerID = ei.ComputerID
join dbo.tbComputerTargetDetail as ctd
  on ctd.TargetID = ct.TargetID
group by ei.ComputerID, ct.FullDomainName, ctd.OSMajorVersion, ctd.OSMinorVersion, ctd.OSBuildNumber, ei.EventID
order by anzahl desc 

In der aktuellen tbUpdate finde ich das Update am WSUS nicht. Ist aber wie gesagt erst vor ein paar Tagen frisch aufgesetzt. In der Datensicherung der vorherigen SUSDB findet sich die GUID in der tbUpdate. Aber seltsamerweise steht unter LegacyName "NULL". Deshalb ist es mir bisher nicht gelungen aufzulösen, um welches Update es gehen könnte

Ähm ... an dem Thema Client arbeiten wir gerade. Soll heißen wir versuchen ein ähnlich problematisches System hausintern aufzusetzen. Wir wollen bei den Kunden nicht unnötig schlafende Hunde wecken. Aber du hast Recht, dass uns das am ehesten weiterbringen dürfte. Wenn es sich nicht vermeiden lässt, werden wir wohl nicht drum rumkommen auf Kundenrechner zu sehen.

Und der DualScan sollte tatsächlich deaktiviert sein. Das habe zwar nicht ich gemacht und der Kollege ist gerade in Urlaub. Aber ich weiß, dass wir die Windows-Updates ausschließlich über unseren WSUS verteilen. Lediglich das P2P haben wir aktiviert, um die Leitung der Kunden nicht mehr als nötig zu belasten.

Vorgestern haben wir uns nun schließlich Zugang zu einer der Kundenanlagen verschafft
Der Rechner hatte uns innerhalb von etwa 2 Tagen ca. 130.000 Einträge in der tbEventInstances generiert. Bei weitem zwar nicht der Spitzenreiter, aber besser zugänglich als die Spitzenreiter.

Ich kann aber nicht sagen, dass sich das "Durchdrehen" des Systems in der WindowsUpdate.log widergespiegelt hätte. Es gab zwar seltsame Einträge. Aber die passen nicht zu den Events mit dem Installationsfehler EventId 182. Auszug der WindowsUpdate.log siehe unten.

Ansonsten haben wir nun regelmäßig alle Einträge der tbEventInstances gelöscht, die von Win10 1903 erzeugt wurden. So können wir wenigstens unseren WSUS am Leben halten.

Vorher haben wir uns immer angesehen welche Rechner wie häufig Events gemeldet haben. Aber da lässt sich einfach kein System erkennen.

Mittlerweile haben wir übrigens zwei Updates, die in diesen Rückmeldungen erwähnt werden. Ich habe versucht sie über eine StoredProcedure auf Declined zu setzen, weil ich sie in der Oberfläche vom WSUS nicht finden konnte. Dabei wurde dann ein ganz komischer Name für die Updates angezeigt:

Change:Successfully deployed deployment(Decline) of MpSigStub 1.1.16200.1 for Defender amd64fre Ring0 UpdateID:52DD0FB8-2165-4E8F-B7CD-7B8D46157BE9 Revision Number:200
Change:Successfully deployed deployment(Decline) of MpSigStub 1.1.16200.1 for Defender amd64fre Ring3 UpdateID:B32A63CA-BE05-4999-9A8C-FB61CC4BEB63 Revision Number:200
 

Leider hat aber das Ablehnen nicht wirklich geholfen. Es melden weiterhin 1903er-Clients Installationsprobleme bezüglich dieser Updates.

Und hier noch ein Auszug aus der untersuchten WindowsUpdate.log (Server-Name wurde ausge-beep-t  ):

2019.08.28 14:34:07.0754607 2788  4728  ProtocolTalker  OK to reuse existing configuration
2019.08.28 14:34:07.0754643 2788  4728  ProtocolTalker  Existing cookie is valid, just use it
2019.08.28 14:34:07.0754657 2788  4728  ProtocolTalker  PTInfo: Server requested registration
2019.08.28 14:34:07.0868536 2788  4728  Misc            Got WSUS Reporting URL: http://[beeeeeep]:80/ReportingWebService/ReportingWebService.asmx""
2019.08.28 14:34:07.0878978 2788  4728  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents) started; operation # 686; does use network; is at background priority
2019.08.28 14:34:07.0881404 2788  4728  WebServices     Auto proxy settings for this web service call.
2019.08.28 14:34:07.3423061 2788  4728  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents, operation # 686) stopped; does use network; is at background priority
2019.08.28 14:34:07.3683316 2788  4728  Misc            Got WSUS Client/Server URL: http://[beeeeeep]/ClientWebService/client.asmx""
2019.08.28 14:34:07.3696265 2788  4728  ProtocolTalker  OK to reuse existing configuration
2019.08.28 14:34:07.3696301 2788  4728  ProtocolTalker  Existing cookie is valid, just use it
2019.08.28 14:34:07.3696315 2788  4728  ProtocolTalker  PTInfo: Server requested registration
2019.08.28 14:34:07.3806446 2788  4728  Misc            Got WSUS Reporting URL: http://[beeeeeep]/ReportingWebService/ReportingWebService.asmx""
2019.08.28 14:34:07.3816813 2788  4728  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents) started; operation # 687; does use network; is at background priority
2019.08.28 14:34:07.3819212 2788  4728  WebServices     Auto proxy settings for this web service call.
2019.08.28 14:34:07.5873160 2788  4728  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents, operation # 687) stopped; does use network; is at background priority
2019.08.28 14:34:07.6107392 2788  4728  Misc            Got WSUS Client/Server URL: http://[beeeeeep]:80/ClientWebService/client.asmx""
2019.08.28 14:34:07.6120110 2788  4728  ProtocolTalker  OK to reuse existing configuration
2019.08.28 14:34:07.6120148 2788  4728  ProtocolTalker  Existing cookie is valid, just use it
2019.08.28 14:34:07.6120161 2788  4728  ProtocolTalker  PTInfo: Server requested registration
2019.08.28 14:34:07.6233047 2788  4728  Misc            Got WSUS Reporting URL: http://[beeeeeep]:80/ReportingWebService/ReportingWebService.asmx""
2019.08.28 14:34:07.6244091 2788  4728  IdleTimer       WU operation (CLegacyEventUploader::HandleEvents) started; operation # 688; does use network; is at background priority
2019.08.28 14:34:07.6246677 2788  4728  WebServices     Auto proxy settings for this web service call.
2019.08.28 14:34:08.0575703 2788  4728  WebServices     WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2019.08.28 14:34:08.0575758 2788  4728  WebServices     WS error: Fault occurred
2019.08.28 14:34:08.0575779 2788  4728  WebServices     WS Error code: Client
2019.08.28 14:34:08.0575993 2788  4728  WebServices     WS error: <detail><ErrorCode>ServerBusy</ErrorCode><Message>The server has refused the connection because it is temporarily experiencing heavy load. Please try again later.</Message><ID>4234d97f-0f6e-49b7-ad85-9233c4c4bea8</ID><Method>http://www.microsoft.com/SoftwareDistribution/Server/IMonitorable/Ping"</Method></detail>"
 

Edit: Ach, und das DualScan scheint nach allem was ich finden konnte wirklich deaktiviert. Wir verteilen ausschließlich über unseren WSUS. Habe verschiedene Anleitungen aus dem Internet versucht, um das zu überprüfen

Danke erstmal für die Aufklärung, was sich hinter diesem ominösen MpSigStub verbirgt

Wir nutzen tatsächlich nur den Defender und haben am WSUS eine Regel bei den "Automatic Approvals" eingerichtet, damit alles aus der Klassifikation "Definition Updates" und dem Produkt "Windows Defender" sofort durchgereicht wird.

Bezüglich dem DualScan habe ich z.B. das Vorgehen von dieser Seite hier nochmal eben gemacht:
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).

Und das Ergebnis war dann ein "True" ausschließlich bei "Windows Server Update Service" (siehe auch Bild im Anhang).

Zur Frage wie die Tabelle aussieht habe ich auch ein Bild angehängt. Diese Rückmeldungen sind in ziemlich genau einer Stunde reingetrudelt. Sollten noch weitere Spalten interessant sein, kann ich das gerne noch ergänzen. Meine Abfrage hat übrigens so ausgesehen:

use susdb;
SELECT ei.ComputerID, count(*) as anzahl, ct.FullDomainName, ctd.OSMajorVersion, ctd.OSMinorVersion, ctd.OSBuildNumber, ctd.ClientVersion, ei.EventID, ei.UpdateID
  FROM dbo.tbEventInstance as ei
  join dbo.tbComputerTarget as ct
    on ct.ComputerID = ei.ComputerID
  join dbo.tbComputerTargetDetail as ctd
    on ctd.TargetID = ct.TargetID
  group by ei.ComputerID, ct.FullDomainName, ctd.OSMajorVersion, ctd.OSMinorVersion, ctd.OSBuildNumber, ctd.ClientVersion, ei.EventID, ei.UpdateID
  order by anzahl desc

Sorry ... irgendwie hatte das mit dem zweiten Screenshot gestern nicht geklappt 

Bezüglich DualScan hast du Recht, im regedit ist unter WindowsUpdate hier die "1" bei DisableDualScan hinterlegt.

Testclients haben wir tatsächlich inzwischen auch ein paar aufgesetzt, z.T. ein paar Mal. Aber die haben nicht verrückt gespielt. Wir können das Problem immer noch nicht gezielt nachstellen.

Und Schock-Schwere-Not ... ohne Mist ?!?!?! ... die Defender-Updates fliegen nicht von alleine wieder raus. Ich dachte, wenn die in der Synchronisation unter "Expired Updates" auftauchen wären die auch wieder weg. Da muss ich mir nochmal einen Überblick verschaffen, was wir da aktuell dann so verteilen.

Oh und dann geht's ans Eingemachte. "ADMT-Templates" lt. Google "Active Directory Migration Tool". Sorry ich fürchte das ich mir zu hoch ... Was ich aber sagen kann, unsere Kundenrechner stecken nicht in einer Domäne. Das sind jeweils kleine lokale Netzwerke ohne Domäne.
Ähm und die "Übermittlungsoptimierung". Wir nutzen das P2P um die Bandbreite bei den Kunden nicht unnötig zu belasten. Aber war das gefragt?

Ich versuche nochmal ein Bild anzuhängen mit unseren Registry-Einstellungen im WU.

Noch ein kurzes Wort zum Stand unseres WSUS. Seit wir die EventInstances-Tabelle alle 6 Stunden bereinigen bleibt das System ansprechbar und wir können seit Ende letzter Woche wieder Updates liefern. Das machen wir in Wellen mit mehr und mehr Rechnern. Ich hoffe nicht vorzugreifen, aber die Problemfälle scheinen deutlich weniger zu werden. Vor jedem Bereinigen protokolliere ich noch meine "TopTroubleMaker" und auch hier ist das Absinken im Moment sichtbar.

Echt strange die Sache 

Clouseau schrieb on 05.09.19 um 16:29:41:


Gut.

Clouseau schrieb on 05.09.19 um 16:29:41:


Sind die exakt so erzeugt worden, wie die Clients beim Kunden? Upgrade auf Upgrade auf Upgrade.

Clouseau schrieb on 05.09.19 um 16:29:41:


Schau dir das gepostete SQL Script an. Tut was es soll.

Clouseau schrieb on 05.09.19 um 16:29:41:


Die Bandbreite kann man auch sparen, wenn man den BITS per GPO begrenzt. Aber ohne Domäne ist das alles Turnschuhadministration. Warum macht man so etws heute noch? Das ist noch aus dem vorletzten Jahrhunder.
(Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).

ADM-Templates, sorry für die falsche Bezeichnung, sind die Templates/Vorlagen für die Gruppenrichtlinien. Hier ein Artikel zum Lesen: (Du musst Dich Einloggen oder Registrieren um Multimediadateien oder Links zu sehen).


Clouseau schrieb on 05.09.19 um 16:29:41:


Sieht gut aus.


Clouseau schrieb on 05.09.19 um 16:29:41:


MSFT hat ja Ende August ein Update für 1903 geliefert das ein paar (ca. 20) Fehler korrigiert, würde mich nicht wundern wenn da etwas für euch auch dabei gewesen ist.

Danke für die Rückmeldung und hoffentlich läuft es jetzt ruhig weiter.

Evtl. hat ja MSFT in Sachen Defender Updates etwas gelernt und die alten auf abgelehnt gesetzt. Beim letzten AG musste ich das noch auf diese Art manuell setzen.

EDIT: Man kann den BITS, Intelligenter Hintergrund Übertragungsdienst, auch für eigenen Projekte nutzen. Mit der Powershell kannst Du selbst große Pakete scripten und so Daten von A nach B bringen.

Ich vermute das 'defekte' Update das mittlerweile korrigiert wurde.

Trotzdem vielen Dank für deine Rückmeldung.