technox
Goto Top

Wsus http 1.1 Protokoll Fehler bei Windows Internal Database

Basis: Windows 2008 R2 Server (Neuinstallation)

Habe das Problem wie hier beschrieben:
WSUS 3 synchronisiert, läd jedoch keine Dateien herunter.
Folgende Fehler erscheinen im Eventlog:

Ereignistyp: Fehler
Ereignisquelle: Windows Server Update Services
Ereigniskategorie: Core
Ereigniskennung: 10032
Datum: 14.12.2008
Zeit: 07:48:20
Benutzer: Nicht zutreffend
Computer: SRV
Beschreibung:
Der Server kann einige Updates nicht herunterladen.

und:

Ereignistyp: Fehler
Ereignisquelle: Windows Server Update Services
Ereigniskategorie: Synchronization
Ereigniskennung: 364
Datum: 14.12.2008
Zeit: 02:37:19
Benutzer: Nicht zutreffend
Computer: SRV
Beschreibung:
Inhaltdateisynchronisierung ist fehlgeschlagen.
Ursache: Der Server unterstützt das erforderliche HTTP-Protokoll nicht.
Der Server muss den Bereichsprotokollheader unterstützen, damit BITS ausgeführt werden kann.


Richtig!
Der Server unterstützt das erforderliche HTTP-Protokoll nicht. Somit kann die BITS-Funktionalität
nicht genutzt werden.
Da ich nicht ermitteln konnte, wie das Protokoll erweitert werden kann, hier die gängige Methode:

Wir müssen einen Eintrag in der WSUS Datenbank ändern, der bewirkt, dass WSUS nicht BITS im
Hintergrundmodus nutzt, sondern aktiv die Leitung benutzt. Wer als Datenbank einen vorhandenen
SQL Server gewählt hat, der sei froh.

Hat man die Microsoft Internal Database in Form einer abgespeckten Express Edition gewählt, so
hat man keinen Zugriff über ein Managementtool und benötigt einen Server mit Microsoft SQL
(auch Express) mit Management-Tool oder installiert sich etwas in der Art auf dem Server.
Dann beendet man die Dienste des WSUS und der Microsoft Internal Database.
Jetzt lassen sich die Datenbankdateien xxx.mdf und xxx.ldf kopieren und als Datenbank an unseren
managebaren Server anhängen.

Folgende Tabelle muss bearbeitet werden: tbConfigurationC
Dort Folgenden Eintrag von "False" auf "True" setzen: BitsDownloadPriorityForeground

Datenbank wieder an den Ursprungsort verfrachten und die Dienste (erst SQL, dann WSUS) wieder
starten.


Kann mir nich vorstellen das ich alleine damit bin. Habe mich für die Windows Interne Database entscheiden & frage mich nun was genau ich tun
muss um dieses Problem zu beseitigen. Anleitungen wie es "mit SQL" zu beseitigen geht habe ich Haufenweise gefunden. Meine gesammten Dokus
beziehen sich auf W2003 Server.. auch etwas doof. Habe schon gesucht wie blöde. Es kann doch nicht angehen das Microsoft ein Produkt raushaut das
mit seiner eigenen Datenbank ned läuft.

Hat irgendwer die Lösung? Ich finds nämlich ned.

Content-Key: 145356

Url: https://administrator.de/contentid/145356

Printed on: April 19, 2024 at 11:04 o'clock

Member: TechnoX
TechnoX Jun 22, 2010 at 07:57:49 (UTC)
Goto Top
Ok... ich glaube (bin mir nich sicher) es gefunden zu haben. Der Grund warum es nicht ging lag an der Sonic Firewall.

Besser gesagt geht es um die Antispyware Regeln. Und die Gateway Antivirus Regeln. Zu finden unter:

Security Services > Antispyware
->Configure Antispyware Settings
->Enable Anti-Spyware Exclusion List
Trage hier beides Mal deine IP von der Wsus Kiste ein.

Security Services > Gateway Anti-Virus
->Configure Gateway AV Settings

WICHTIG:
->Enable HTTP Byte-Range requests with Gateway AV -> HÄCKCHEN SETZEN!

Nun sollte sich der Content Ordner füllen.. (tuts bei mir zumindest.)

Allerdings zeigt mir der WSUS vollkommen krasse Werte an was die Dateigrößen anbetrifft:
Updates die Daten erfordern = 10.578,56MB von 45.743,29 (-> de letzte Wert NICHT STEIGEND!)
Der hintere Wert stieg aus irgendeinem Grund permanent an, proportional zu dem was heruntergeladen worden war.
Leider um den Faktor verfälscht. Die 10 GB waren ~10MB welche er gezogen hat.
Seit der Einstellung der Sonicwall ist der hintere Wert bei 45GB stehn geblieben & der Wert dessen was geladen wurde steigt
normal an. Ich vermute hier ne Schleife oder sowas die den Zähler verrissen hat. Das war ne schwere Geburt..