none
WSUS SQL Timeout auf Replica Servern RRS feed

  • Frage

  • Hallo allerseits!

    Ich habe eine laufende WSUS Struktur mit einem Haupt-Server und 23 Replicas. Einige davon wollen seit kurzem (genauer: seit 30.07.) nicht mehr richtig synchronisieren. 

    Am Hauptserver ist angeblich bei den Downstreamservern alles okay. Die Downstreamserver melden:

    SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
    at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
       at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader()
       at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

    Das Problem ist genauso hier beschrieben, leider ohne Lösung: http://www.wsus.info/index.php?showtopic=14393

    Es wurde testweise ein neuer Server als WSUS Replica aufgesetzt. Dort funktioniert die Erstsynchronisation, aber dann taucht sofort das selbe Problem auf. Alle Server nutzen die interne Windows Datenbank. Es werden keine Treiber freigegeben und auch nur die Updates, die tatsächlich von Clients benötigt werden.

    Irgendwelche Ideen?

    Dienstag, 14. August 2012 08:17

Alle Antworten

  • Am 14.08.2012 schrieb Windingo:

    Am Hauptserver ist angeblich bei den Downstreamservern alles okay. Die Downstreamserver melden:SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
    at Microsoft.UpdateServices.DatabaseAccess.DBConnection.DrainObsoleteConnections(SqlException e)
       at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ExecuteReader()
       at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

    Du könntest die Indexe aktualisieren, wird in diesem HowTo
    angesprochen:
    http://www.wsus.de/ausfuehren_eines_scripts_auf_der_windows_internal_database

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Dienstag, 14. August 2012 19:19
  • Habe ich probiert, aber leider keine Verbesserung. Einige Replicas synchen sauber, andere laufen auf den Timeout. Ein Muster ist nicht zu erkennen.

    Es wurden schon:

    - alte Updates abgelehnt
    - WSUS Cleanup durchgeführt
    - Defrag der Datenbank im Filesystem durchgeführt

    Dummerweise zieht ja auch SCEP seine Updates darüber, was die Sache jetzt etwas unschöner macht...

    Mittwoch, 15. August 2012 07:38
  • Ich kann die Sache noch etwas weiter ausführen. Die Problematik hat scheinbar auch mit der CPU Leistung der Replica Server zu tun.

    Die Maschinen mit Xeon E3 1220 CPU (4x 3,1 GHz) haben überhaupt keine Probleme mit der Synchronisation
    Die Maschinen mit langsameren Xeon CPUs (zw. 1,6 und 2 GHz) haben arge Probleme, die Mehrzahl der Synchronisierungen schlägt mit der Timeout Meldung fehl. 
    Die Maschinen mit AMD Neo N40L CPU (HP MicroServer, 2x 1,5 GHz) bekommen überhaupt keinen Sync mehr hin und laufen immer in den Timeout. 

    Auffällig ist auch, dass auf den Maschinen, auf denen es problemlos läuft, der SQL meist unter 1 GB Ram nutzt, während auf den Maschinen, auf denen die Probleme auftauchen, teilweise locker 3 GB Ram nur vom SQL genutzt werden. 

    Mittwoch, 15. August 2012 12:01
  • Am 15.08.2012 schrieb Windingo:

    Die Maschinen mit Xeon E3 1220 CPU (4x 3,1 GHz) haben überhaupt keine Probleme mit der Synchronisation
    Die Maschinen mit langsameren Xeon CPUs (zw. 1,6 und 2 GHz) haben arge Probleme, die Mehrzahl der Synchronisierungen schlägt mit der Timeout Meldung fehl. 
    Die Maschinen mit AMD Neo N40L CPU (HP MicroServer, 2x 1,5 GHz) bekommen überhaupt keinen Sync mehr hin und laufen immer in den Timeout. 

    Auffällig ist auch, dass auf den Maschinen, auf denen es problemlos läuft, der SQL meist unter 1 GB Ram nutzt, während auf den Maschinen, auf denen die Probleme auftauchen, teilweise locker 3 GB Ram nur vom SQL genutzt werden.

    Läuft auf den Problemmaschinen denn nur die Windows Internal Database
    oder gibt es noch weitere SQL Server? Läuft auch ein Sharepoint?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 15. August 2012 14:47
  • Auf allen Maschinen läuft der WSUS mit der Windows Internal Database. 

    Es gibt zwar einen SQL Server, der wird aber nicht für WSUS genutzt. Sharepoint ist auch vorhanden, nutzt den SQL. 

    Donnerstag, 16. August 2012 05:58
  • Am 16.08.2012 schrieb Windingo:

    Auf allen Maschinen läuft der WSUS mit der Windows Internal Database. 

    OK.

    Es gibt zwar einen SQL Server, der wird aber nicht für WSUS genutzt. Sharepoint ist auch vorhanden, nutzt den SQL.

    OK. Um ein Problem mit der Windows Internal Database auszuschliessen,
    könnte ihr auf einem Replica den WSUS auf den richtigen SQL
    schwenken? Hier wird beschrieben wie das funktioniert:
    http://technet.microsoft.com/en-us/library/dd939918%28v=ws.10%29.aspx

    Habt ihr per GPO den BITS zwischen Main- und Downstream WSUS
    eingeschränkt? Gibt es Kapazitätsprobleme bei den Leitungen?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Donnerstag, 16. August 2012 18:07
  • Auf den Replica Systemen habe ich eigentlich keine Chance, einen SQL Server einzusetzen. Auf dem Haupt-Server ist das eher ein Thema. Wäre das eine Alternative?

    BITS wird bisher nicht eingeschränkt. Es gibt diesbezüglich keine GPO. Das Problem tritt auch auf einem neu installierten Testsystem auf, welches hier lokal im LAN steht, d.h. im selben Netz wie der Upstream-WSUS.

    Kapazitätsprobleme mit den Leitungen gibts immer. Man glaubt gar nicht, wie lahm Verbindungen nach Frankreich oder Spanien sein können...

    Donnerstag, 6. September 2012 14:08
  • Am 06.09.2012 schrieb Windingo:

    Auf den Replica Systemen habe ich eigentlich keine Chance, einen SQL Server einzusetzen. Auf dem Haupt-Server ist das eher ein Thema. Wäre das eine Alternative?

    Du kannst keinen SQL Express auf einem Downstream installieren? Auf
    dem Mainstream kannst Du das gerne probieren.

    BITS wird bisher nicht eingeschränkt. Es gibt diesbezüglich keine GPO. Das Problem tritt auch auf einem neu installierten Testsystem auf, welches hier lokal im LAN steht, d.h. im selben Netz wie der Upstream-WSUS.

    Der SQL ist up2date in Sachen Windows Updates?

    Kapazitätsprobleme mit den Leitungen gibts immer. Man glaubt gar nicht, wie lahm Verbindungen nach Frankreich oder Spanien sein können...

    Dann schränke den BITS ein.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Sonntag, 9. September 2012 21:11
  • Mal ein kleines Update, die ganze Geschichte hat sich etwas gezogen...

    Der Upstream Server wurde jetzt von der WID auf eine Datenbank auf SQL 2008 Standard umgestellt. Die Datenbank liegt dabei nicht lokal, sondern auf einem eigenständigen Server. Ich bilde mir zwar ein, dass die Konsole deutlich schneller wurde, aber am Problem änderte es nichts.

    Dann habe ich einen weiteren Testserver als Replica aufgesetzt, diesmal aber die Datenbank lokal auf diesem nicht in die WID gepackt, sondern einen SQL 2008 R2 Express installiert. Die initiale Synchronisierung läuft noch, ich werde mal beobachten, inwiefern das die Sache verbessert.

    Aber warum ich auf einer eh schon langsamen Leitung BITS noch weiter begrenzen soll, das ist mir jetzt noch nicht ganz klar geworden...

    Mittwoch, 19. September 2012 08:27
  • So, nun ist auch der Test-Downstreamserver mit der Synchronisierung durch und Status ist wieder "Failed".

    SqlException: Timeout expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
       at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
       at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
       at System.Data.SqlClient.SqlDataReader.ReadInternal(Boolean setTimeout)
       at Microsoft.UpdateServices.DatabaseAccess.DBConnection.ReadOneRow()
       at Microsoft.UpdateServices.Internal.DataAccess.HideUpdatesForReplicaSync(String xmlUpdateIds)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ProcessHiddenUpdates(Guid[] hiddenUpdates)
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ReplicaSync()
       at Microsoft.UpdateServices.ServerSync.CatalogSyncAgentCore.ExecuteSyncProtocol(Boolean allowRedirect)

    Mittwoch, 19. September 2012 10:47
  • Am 19.09.2012 schrieb Windingo:

    Der Upstream Server wurde jetzt von der WID auf eine Datenbank auf SQL 2008 Standard umgestellt. Die Datenbank liegt dabei nicht lokal, sondern auf einem eigenständigen Server. Ich bilde mir zwar ein, dass die Konsole deutlich schneller wurde, aber am Problem änderte es nichts.

    Hmm.

    Dann habe ich einen weiteren Testserver als Replica aufgesetzt, diesmal aber die Datenbank lokal auf diesem nicht in die WID gepackt, sondern einen SQL 2008 R2 Express installiert. Die initiale Synchronisierung läuft noch, ich werde mal beobachten, inwiefern das die Sache verbessert.

    OK.

    Aber warum ich auf einer eh schon langsamen Leitung BITS noch weiter begrenzen soll, das ist mir jetzt noch nicht ganz klar geworden...

    Weil sich der BITS nicht an der Leitungskapazität hält, sondern an der
    Linkgeschwindigkeit der NIC. Hängt die NIC an 100 Mbit will sich der
    BITS 10% davon nehmen, egal ob die Leitung dahinter nur 1 oder 5 MBit
    hat. Ich hatte dafür auch einen KB Artikel, finde den aber nicht mehr
    auf die Schnelle.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 19. September 2012 19:44
  • Okay, das mit BITS lasse ich mir mal durch den Kopf gehen. Andererseits läuft das nachts ab und da ist es mir reichlich egal, ob nun die Leitung dicht ist oder nicht.

    Hast du noch weitere Ideen bezüglich des SQL Timeout Problems? Wie ich ja schrieb klappte es auch mit dem neuen Test-Replica-Server nicht, obwohl dieser nicht WID verwendet.

    Freitag, 21. September 2012 07:25
  • Am 21.09.2012 schrieb Windingo:

    Okay, das mit BITS lasse ich mir mal durch den Kopf gehen. Andererseits läuft das nachts ab und da ist es mir reichlich egal, ob nun die Leitung dicht ist oder nicht.

    OK.

    Hast du noch weitere Ideen bezüglich des SQL Timeout Problems? Wie ich ja schrieb klappte es auch mit dem neuen Test-Replica-Server nicht, obwohl dieser nicht WID verwendet.

    Nein, keinerlei Ideen mehr. Du könntest in einem SQL Server Forum
    nachfragen, evtl. kennt einer der SQL Spezialisten den Fehler.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 21. September 2012 13:52
  • Hallo,

    gibt es inzwischen eine Lösung zu dem Thema? Denn ich habe das gleiche Problem und wäre für eine Lösung dankbar.

    Donnerstag, 27. September 2012 12:17
  • Am 27.09.2012 schrieb BigL1:

    gibt es inzwischen eine Lösung zu dem Thema? Denn ich habe das gleiche Problem und wäre für eine Lösung dankbar.

    Was hast Du denn schon alles probiert? Wie groß ist die SUSDB?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 27. September 2012 20:41
  • Ich habe schon alles getestet, was hier vorgeschlagen wurde. Vorher schon alle Replicas bereinigt und dann den Upstreamserver bereinigt. Habe die DB neu indizieren lassen, das hat alles nichts gebracht.

    Ich hatte das ganze Problem vor ca. 2 Monaten schon Mal, da war es mit der Bereinigung aller Server getan.

    Die SUSDB ist 4,2 GB groß.

    Freitag, 28. September 2012 07:20
  • Am 28.09.2012 schrieb BigL1:

    Ich habe schon alles getestet, was hier vorgeschlagen wurde. Vorher schon alle Replicas bereinigt und dann den Upstreamserver bereinigt. Habe die DB neu indizieren lassen, das hat alles nichts gebracht.

    OK.

    Ich hatte das ganze Problem vor ca. 2 Monaten schon Mal, da war es mit der Bereinigung aller Server getan.

    Die SUSDB ist 4,2 GB groß.

    Wow, das ist groß. Probier die DB zu verkleinern. Melde dich dazu an
    der Windows Internal Database, sofern Du die auch nutzt, wie in diesem
    Artikel beschrieben:
    http://www.wsus.de/ausfuehren_eines_scripts_auf_der_windows_internal_database
    Darin dann auch die DB verkleinern. Einfach auf neue Abfrage klicken und das eingeben und Ausführen anklicken.

    dbcc shrinkdatabase ('SUSdb', truncateonly)

    Kontrolliere anschließend die Größe der SUSDB. Ist sie kleiner
    geworden?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 28. September 2012 14:46
  • Hallo

    auch ich habe genau das gleiche Problem. hab schon alles möglich versucht. Meine Datenbak ist auch relativ groß. Glaube aber nicht das es an der Datenbankgröße liegt. Auf einem SqlExpress 2008 R2 liegt die Begrenzung (bin nicht ganz sicher) auf 10 GB - aber zumindest über 4 GB.

    Über eine Lösung wäre ich ganz dankbar....

    Mfg

    Thomas

    Montag, 1. Oktober 2012 08:01
  • Montag, 1. Oktober 2012 10:20
  • Am 01.10.2012 schrieb Thomas Wallner:

    das hat bei mir geholfen

    http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/4c493b02-9c20-4383-8235-1db7a95c4b3a/

    Freut mich für Dich und Danke für die Rückmeldung. ;)

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 1. Oktober 2012 19:22
  • Am 01.10.2012 schrieb Thomas Wallner:

    auch ich habe genau das gleiche Problem. hab schon alles möglich versucht. Meine Datenbak ist auch relativ groß. Glaube aber nicht das es an der Datenbankgröße liegt. Auf einem SqlExpress 2008 R2 liegt die Begrenzung (bin nicht ganz sicher) auf 10 GB - aber zumindest über 4 GB.

    Richtig, ab 2008R2 Express kann eine DB 10 GB groß werden.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 1. Oktober 2012 19:22
  • Wow, das ist groß. Probier die DB zu verkleinern. Melde dich dazu an
    der Windows Internal Database, sofern Du die auch nutzt, wie in diesem
    Artikel beschrieben:
    http://www.wsus.de/ausfuehren_eines_scripts_auf_der_windows_internal_database
    Darin dann auch die DB verkleinern. Einfach auf neue Abfrage klicken und das eingeben und Ausführen anklicken.

    dbcc shrinkdatabase ('SUSdb', truncateonly)

    Kontrolliere anschließend die Größe der SUSDB. Ist sie kleiner
    geworden?

    Nein, Sie hat sich leider kein Stück verändert.

    Ich habe auch, wie im Link unten beschrieben, alle abgelösten Updates abgelehnt. Jetzt bin ich bei 2,7 GB, an meinem Problem hat das aber bisher nichts geändert.

    Dienstag, 2. Oktober 2012 13:33
  • Am 02.10.2012 schrieb BigL1:

    Ich habe auch, wie im Link unten beschrieben, alle abgelösten Updates abgelehnt. Jetzt bin ich bei 2,7 GB, an meinem Problem hat das aber bisher nichts geändert.

    Hmm, keine Idee mehr. Neustart hast du schon durch? Synchronisation
    auf dem Replica angeschoben?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Dienstag, 2. Oktober 2012 17:23
  • Ja, nach Neustart immer noch keine Synchronisation.

    Der Sync läuft zwar wesentlich schneller, als letzte Woche vor den ganzen Bereinigungen und dem Verkleinern der SUSDB's, bleibt aber bei 99% ne Weile stehen und bringt dann den Fehler wieder. 

    Donnerstag, 4. Oktober 2012 11:08
  • Am 04.10.2012 schrieb BigL1:

    Der Sync läuft zwar wesentlich schneller, als letzte Woche vor den ganzen Bereinigungen und dem Verkleinern der SUSDB's, bleibt aber bei 99% ne Weile stehen und bringt dann den Fehler wieder.

    Auf Replica kannst Du den Haken entfernen, dann ist er kein Replica
    mehr. Jetzt manuell Updates ablehnen und den Bereinigungsassistenten
    laufen lassen.

    Zusätzlich auf allen WSUS Maschinen dieses Script täglich laufen
    lassen: http://www.wsus.de/serverbereinigung2

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 5. Oktober 2012 17:33
  • Sind Treiber bei euch zur Synchronisation und Bereistellung aktiviert? Ggf. liegt es dann daran - s.a.:

    A large number of driver updates showing up in WSUS
    http://blogs.technet.com/b/sus/archive/2008/08/20/a-large-number-of-driver-updates-showing-up-in-wsus.aspx

    --
    Tobias Redelberger
    StarNET Services (HomeOffice)
    Frankfurter Allee 193
    D-10365 Berlin
    Tel: +49 (30) 86 87 02 678
    Mobil: +49 (163) 84 74 421
    Email: T.Redelberger@starnet-services.net
    Web: http://www.starnet-services.net

    Sonntag, 7. Oktober 2012 12:18
  • Ich habe jetzt ein wenig mit dem Holzhammer draufgehauen...

    Auf dem Upstream WSUS eigene Updates exportiert, dann WSUS deinstalliert, alle heruntergeladenen Updates gelöscht, Datenbank gelöscht. 

    WSUS neu installiert, KB2734608 drauf, keine Treiber mit bereitgestellt. Nur die Updates freigegeben, die benötigt werden und bereits ersetzte Updates abgelehnt. Der Upstream Server läuft damit wieder. 

    Nun testweise mehrere Downstream Server ebenfalls deinstalliert und neu eingerichtet und auf anderen Downstream Servern einfach so die Sync angeworfen: quasi selbiges Problem wie vorher. Einzelne Downstream Server synchronisieren sauber, der Rest läuft in den SQL Timeout. 

    Das kann doch alles nicht wahr sein!

    Freitag, 12. Oktober 2012 07:26
  • Am 12.10.2012 schrieb Windingo:

    Auf dem Upstream WSUS eigene Updates exportiert, dann WSUS deinstalliert, alle heruntergeladenen Updates gelöscht, Datenbank gelöscht. 

    WSUS neu installiert, KB2734608 drauf, keine Treiber mit bereitgestellt. Nur die Updates freigegeben, die benötigt werden und bereits ersetzte Updates abgelehnt. Der Upstream Server läuft damit wieder. 

    OK.

    Nun testweise mehrere Downstream Server ebenfalls deinstalliert und neu eingerichtet und auf anderen Downstream Servern einfach so die Sync angeworfen: quasi selbiges Problem wie vorher. Einzelne Downstream Server synchronisieren sauber, der Rest läuft in den SQL Timeout. 

    Was ist der Unterschied zwischen den Funktionierenden und den Nicht
    Funktionierenden Servern?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 12. Oktober 2012 15:05
  • Am 12.10.2012 schrieb Windingo:

    Nun testweise mehrere Downstream Server ebenfalls deinstalliert und neu eingerichtet und auf anderen Downstream Servern einfach so die Sync angeworfen: quasi selbiges Problem wie vorher. Einzelne Downstream Server synchronisieren sauber, der Rest läuft in den SQL Timeout. 

    Lass auf den Servern, die Probleme machen, dieses Script täglich
    laufen, das räumt immer schön auf: http://wsus.de/serverbereinigung2

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/
    Reg2xml:  http://www.reg2xml.com - Registry Export File Converter

    Samstag, 13. Oktober 2012 17:15
  • Meine Aussage war da etwas optimistisch. Im Prinzip habe ich keine Maschinen mehr, wo es ständig funktioniert. Es gibt einzelne Maschinen, wo es an einem Tag mal vorkommen kann, dass der Sync durchläuft. In den letzten Wochen war das pro Server vielleicht mal ein oder zwei Mal erfolgreich.

    Noch ein wenig Statistik:

    Unapproved updates: 1857
    Approved updates: 594
    Declined updates: 5079
    Computers: 658
    Computer groups: 4

    Ich gehe nicht davon aus, dass das zu viele Updates sind. Die SUSDB hat etwa 2,3 GB.

    Das Script wird seit Freitag auf allen Replicas und auf dem Upstream Server jede Nacht einmal ausgeführt. Hat leider auch noch nicht weitergeholfen.

    Was ich nicht verstehe: die Replicas zeigen mir eine deutlich höhere Anzahl an "Unapproved updates" an als der Upstream Server. Da sind das Anzahlen zwischen 5000 und 23000 unapproved updates. Und zwar auch die, die jetzt nach der Neuinstallation des Upstream Servers ebenfalls neu installiert wurden.

    Montag, 15. Oktober 2012 11:48
  • Am 15.10.2012 schrieb Windingo:

    Meine Aussage war da etwas optimistisch. Im Prinzip habe ich keine Maschinen mehr, wo es ständig funktioniert. Es gibt einzelne Maschinen, wo es an einem Tag mal vorkommen kann, dass der Sync durchläuft. In den letzten Wochen war das pro Server vielleicht mal ein oder zwei Mal erfolgreich.

    Die Firewalls/Router dazwischen kannst Du zu 100% ausschließen?

    Unapproved updates: 1857
    Approved updates: 594
    Declined updates: 5079
    Computers: 658
    Computer groups: 4

    Ich gehe nicht davon aus, dass das zu viele Updates sind. Die SUSDB hat etwa 2,3 GB.

    Nein, sieht schon OK sein.

    Das Script wird seit Freitag auf allen Replicas und auf dem Upstream Server jede Nacht einmal ausgeführt. Hat leider auch noch nicht weitergeholfen.

    Wird denn Plattenplatz freigegeben und werden auch alte Updates
    abgelehnt?

    Was ich nicht verstehe: die Replicas zeigen mir eine deutlich höhere Anzahl an "Unapproved updates" an als der Upstream Server. Da sind das Anzahlen zwischen 5000 und 23000 unapproved updates. Und zwar auch die, die jetzt nach der Neuinstallation des Upstream Servers ebenfalls neu installiert wurden.

    Da hat wohl die Synchronisation zwischendurch länger nicht sauber
    funktioniert. Du kannst mit WSUSUTIL /Export /Import versuchen die
    Server wieder synchron zu bekommen.
    http://technet.microsoft.com/de-de/library/cc720466%28v=ws.10%29.aspx
    Alternativ rückstandsfrei deinstallieren, incl. DB und Content und
    wieder neu vom Master synchronisieren lassen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Montag, 15. Oktober 2012 18:47
  • Ja, Firewalls und Router kann ich ausschließen, da das Problem genauso auftaucht, wenn die Replica Maschine im selben Netz wie der Upstream steht - ganz ohne Routing dazwischen.

    Plattenplatz wird meines Erachtens freigegeben. Aber ich kann nicht ganz nachvollziehen, dass ich eine neue Replica Maschine installiere und diese dann knappe 6000 unapproved Updates anzeigt, obwohl der Upstream selber nur die 1857 zeigt. Irgendwie müsste doch nach meinem Verständnis eine Replik genau die gleichen Anzahlen von Updates haben wie das Original. 

    Ich bin momentan dabei, und habe die Replikas auch Schritt für Schritt deinstalliert und dann wieder neu installiert. Bringt nur leider nichts für das eigentliche Problem. Auch diese frisch installierten Replikas laufen beim Sync wieder in den SQL Timeout. 

    Dienstag, 16. Oktober 2012 08:29
  • Am 16.10.2012 schrieb Windingo:

    Ja, Firewalls und Router kann ich ausschließen, da das Problem genauso auftaucht, wenn die Replica Maschine im selben Netz wie der Upstream steht - ganz ohne Routing dazwischen.

    OK. Switche kannst Du auch ausschliessen?

    Plattenplatz wird meines Erachtens freigegeben. Aber ich kann nicht ganz nachvollziehen, dass ich eine neue Replica Maschine installiere und diese dann knappe 6000 unapproved Updates anzeigt, obwohl der Upstream selber nur die 1857 zeigt. Irgendwie müsste doch nach meinem Verständnis eine Replik genau die gleichen Anzahlen von Updates haben wie das Original. 

    Die ersten Replikationen sollte man abwarten, aber spätestens nach 2
    Tagen sollte alles wieder passen.

    Ich bin momentan dabei, und habe die Replikas auch Schritt für Schritt deinstalliert und dann wieder neu installiert. Bringt nur leider nichts für das eigentliche Problem. Auch diese frisch installierten Replikas laufen beim Sync wieder in den SQL Timeout.

    Installierst Du die mit der Windows Internal Database oder mit einer
    Express Version?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Dienstag, 16. Oktober 2012 19:26
  • Ich wüsste jetzt nicht, was man auf einem Switch konfigurieren muss, damit WSUS einen SQL Timeout beim Zugriff auf den lokalen SQL meldet. Wir haben zumindest sonst keine Netzwerkprobleme - weder in Sachen Performance, noch sonst irgendwie geartet.

    Die Server haben auch nach drei Tagen noch unterschiedliche Anzahlen von Updates. Die Replicas haben weiterhin allesamt deutlich mehr Updates als der Upstream.

    Die Replicas sind alle mit WID installiert. SQL Express hatte ich getestet, aber da keine Änderungen festzustellen waren wieder gelassen.

    Freitag, 19. Oktober 2012 11:54