none
Neue WSUS-Clients werden am WSUS-Server geblockt (Code: 80072EE2) RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Liebe IT-Profis,

    aus bislang unbekannten Gründen werden neue Windows-7 Clients (64 Bit) am WSUS-Server (Windows Server 2003 R2 SP2) geblockt. Es handelt sich um XP-Clients, die aus der Domäne entfernt, neu installiert und wieder in die Domäne genommen werden (bei den bestehenden Clients funktioniert WSUS einwandfrei). Die Update-Suche beim neuen Client bricht ab mit der Fehlermeldung: Fehler bei der Suche nach neuen Updates, Code: 80072EE2. Die Clients werden zwar in der WSUS-Konsole wieder gelistet, erstellen aber keinen Bericht. Ich vermute, daß das Problem auf dem Server liegt (WSUS-Version: 3.2.7600.226), denn dort steht im IIS- httperr1.log für die IP-Adresse des Clients folgender Eintrag (mit einer Zeitdifferenz von 2 Stunden, obwohl die Uhrzeit am Server über die Domäne synchronisiert wird):

    HTTP/1.1 POST /ClientWebService/client.asmx - 1 Connection_Dropped WsusPool

    Bei der Internet-Recherche bin ich auf folgenden Post gestoßen:

    https://social.technet.microsoft.com/Forums/windowsserver/en-US/a58139b9-092b-46a8-845f-f568f08cfdcf/wsus-clients-unable-to-connect?forum=winserverwsus

    Hier war das Problem wohl zu viele Clients und Gruppen im WSUS, wir haben 'nur' 52 Clients und die Standardgruppe.

    Dem lokalen Benutzer "Netzwerk" Vollzugriff auf den Ordner "C:\WINDOWS\Microsoft.NET\Framework" des WSUS-Servers, hat auch nicht geholfen, wie hier beschrieben:

    http://www.wsus.info/index.php?showtopic=5735

    Wäre für einen guten Tipp dankbar. Ansonsten werde ich das WSUS SP2 nochmal drüberbügeln oder einen neuen WSUS-Server aufsetzen.

    Besten Dank

    Peter Huber

    Donnerstag, 23. Juni 2016 09:41
    |

Antworten

  • Question
    Anmelden
    2
    Anmelden

    Hallo zusammen,

    DIE Gelegenheit habe ich denn auch genutzt und eine Migration durchgeführt. Jetzt klappt's auch wieder mit den Updates. Allerdings war der Weg etwas steinig:

    - SUSDB via SQL Studio Manager auf Quellserver (Domain Member) gesichert
    - neuen Windows Server 2012 R2 als Domain-Member installiert (Zielserver)
    - WSUS-Rolle auf Zielserver aktiviert, Angabe des neuen Speicherortes für die Binärdateien (WsusContent)
    - Domänen-Admins auf Zielserver zur lokalen Gruppe der WSUS-Administratoren hinzugefügt (wie beim Quellserver)
    - Microsoft SQL Server 2012 Express auf dem Zielserver installiert (für den SUSDB-Import)

    Fehlermeldung bei Installation der SQL-Verwaltungstools: Fehler beim Aktivieren der Windows-Funktion: NetFx3. Fehlercode : -2146498298 | Lösung: NetFramework 3.5 via Feature-Installation im Servermanager unter Angabe des Quellpfades (Windows Installations-Image) nachinstalliert, anschließend SQL Verwaltungstool-Installation wiederholt.

    - SQL-Server Management Studio auf Zielserver gestartet (als Administrator, sonst keine Verbindung zur WID (Windows Internal Database); Hinweis: Nach Abschluss der Installation lässt sich das Studio auch 'normal' starten.)
    - Serverdaten eingegeben: \\.\pipe\MICROSOFT##WID\tsql\query (=WID)
    - SUSDB-Backup vom Quellserver im SQL-Server Management Studio auf dem Zielserver in die WID importiert

    1. Fehlermeldung beim Import: Property BackupDirectory is not available for Settings ‘Microsoft.SqlServer.Management.Smo.Settings’. This property may not exist for this object, or may not be retrievable due to insufficient access rights.  (Microsoft.SqlServer.Smo) | Lösung: Neuer Registry-Eintrag für Backup-Verzeichnis am Server: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\ Neue Zeichenfolge: BackupDirectory,  Wert: Pfad zur Backup-Datei

    2. Fehlermeldung beim Import: The backup set holds a backup of a database other than the existing ... database | Lösung:Wiederherstellungs-Optionen: Ziel-Datenbank überschreiben

    3. Fehlermeldung beim Import: Fehler bei der Wiederherstellung von Datenbank 'SUSDB'. (Microsoft.SqlServer.Management.RelationalEngineTasks) System.Data.SqlClient.SqlError: Der exklusive Zugriff auf die Datenbank ist nicht möglich, da die Datenbank gerade verwendet wird. (Microsoft.SqlServer.SmoExtended) | Lösung: Wiederherstellungs-Optionen: Bestehende Verbindungen mit der Ziel-Datenbank schließen (Single User Modus)

    4. Fehlermeldung beim Import: System.Data.SqlClient.SqlError: Fehler bei Schemaüberprüfung für Datenbank 'SUSDB'. (Microsoft.SqlServer.SmoExtended) | Lösung: ignorieren und in Admin-Eingabeaufforderung folgenden Befehl ausführen: "%ProgramFiles%\Update Services\Tools\wsusutil.exe" postinstall

    - Binärdaten vom Quellserver auf den Zielserver kopiert (WsusContent)
    - WSUS Management Konsole geöffnet und die Einstellungen überprüft
    - In den Domänen-Gruppenrichtlinien den neuen WSUS-Server eingetragen (Port: 8530)
    - an einem "Problem-Client" (ehemals XP pro, jetzt Windows 7 pro 64 bit) das Windows-Update über die Systemsteuerung gestartet: Dabei kam es zunächst zum Fehler 0x80244010 (Client hätte zu viele Verb. zum Server); nach dem erneuten Abrufen der Updates war der Fehler verschwunden und Updates wurden installiert. Und endlich stand der Bericht des Clients in der WSUS-Konsole.

    Inzwischen melden sich auch die anderen Clients peu à peu beim WSUS :-)

    Grüße und besten Dank für die Unterstützung

    Peter



    Freitag, 1. Juli 2016 14:01
    |
  • Question
    Anmelden
    1
    Anmelden

    Hallo Peter,

    hin und wieder muss man beim WSUS einfach etwas Geduld mitbringen:

    http://windows.microsoft.com/de-de/windows/windows-update-error-80072ee2#1TC=windows-7

    Wenn du die Möglichkeit hast, würde ich die Clients einfach mal über Nacht laufen lassen.

    Gruß TechnikSC885


    EDIT: gerade bei neu aufgesetzten Clients, kann es einige Stunden dauern bis der Bericht am WSUS vorliegt.
    Donnerstag, 23. Juni 2016 09:52
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 23.06.2016 schrieb Peter M. Huber:

    aus bislang unbekannten Gründen werden neue Windows-7 Clients (64 Bit) am WSUS-Server (Windows Server 2003 R2 SP2) geblockt.

    Der WSUS ist dumm wie Brot und blockt gar nichts. Die Intelligenz ist
    einzig und allein am Client zu finden.

    Es handelt sich um XP-Clients, die aus der Domäne entfernt, neu installiert und wieder in die Domäne genommen werden (bei den bestehenden Clients funktioniert WSUS einwandfrei).

    Was denn jetzt? XP oder Windows 7 Clients?

    Bericht. Ich vermute, daß das Problem auf dem Server liegt (WSUS-Version: 3.2.7600.226), denn dort steht im IIS- httperr1.log für die IP-Adresse des

    Die exakte Position der Build wäre wichtig. Bitte schau hier:
    http://www.wsus.de/images/wsus-version.png Benutze dabei unbedingt die
    Konsole auf dem WSUS direkt. Falls Du noch nicht auf der Build .274
    bist, dann updaten. Die WSUS-FAQ No. 44 zeigt dir welche Updates noch
    fehlen. http://wsus.de/de/FAQ

    Wäre für einen guten Tipp dankbar. Ansonsten werde ich das WSUS SP2 nochmal drüberbügeln oder einen neuen WSUS-Server aufsetzen.

    Zum Neuaufsetzen ist es zu früh, und das SP2 einfach nochmal drüber
    bügeln ist so ziemlich die schlechteste Aktion, die du machen
    könntest.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Sonntag, 26. Juni 2016 16:44
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Peter,

    hin und wieder muss man beim WSUS einfach etwas Geduld mitbringen:

    http://windows.microsoft.com/de-de/windows/windows-update-error-80072ee2#1TC=windows-7

    Wenn du die Möglichkeit hast, würde ich die Clients einfach mal über Nacht laufen lassen.

    Gruß TechnikSC885


    EDIT: gerade bei neu aufgesetzten Clients, kann es einige Stunden dauern bis der Bericht am WSUS vorliegt.
    Donnerstag, 23. Juni 2016 09:52
    |
  • Question
    Anmelden
    1
    Anmelden

    Möglicherweise hilft es, die Computerkonten der betroffenen Clients aus der WSUS-Datenbank zu löschen. Sie sollten dann nach einmaligem Kontakt mit dem WSUS-Server wieder erscheinen.

    Hilfreich ist es auch immer, bei solchen Aktionen die WindowsUpdate.log life zu verfolgen. Ich verwende dazu http://www.baremetalsoft.com/baretail/index.php.

    Wenn dir meine Antwort nützt, kannst du "Als Antwort vorschlagen" anklicken. Warum? Das steht hier.

    Donnerstag, 23. Juni 2016 10:01
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 23.06.2016 schrieb Peter M. Huber:

    aus bislang unbekannten Gründen werden neue Windows-7 Clients (64 Bit) am WSUS-Server (Windows Server 2003 R2 SP2) geblockt.

    Der WSUS ist dumm wie Brot und blockt gar nichts. Die Intelligenz ist
    einzig und allein am Client zu finden.

    Es handelt sich um XP-Clients, die aus der Domäne entfernt, neu installiert und wieder in die Domäne genommen werden (bei den bestehenden Clients funktioniert WSUS einwandfrei).

    Was denn jetzt? XP oder Windows 7 Clients?

    Bericht. Ich vermute, daß das Problem auf dem Server liegt (WSUS-Version: 3.2.7600.226), denn dort steht im IIS- httperr1.log für die IP-Adresse des

    Die exakte Position der Build wäre wichtig. Bitte schau hier:
    http://www.wsus.de/images/wsus-version.png Benutze dabei unbedingt die
    Konsole auf dem WSUS direkt. Falls Du noch nicht auf der Build .274
    bist, dann updaten. Die WSUS-FAQ No. 44 zeigt dir welche Updates noch
    fehlen. http://wsus.de/de/FAQ

    Wäre für einen guten Tipp dankbar. Ansonsten werde ich das WSUS SP2 nochmal drüberbügeln oder einen neuen WSUS-Server aufsetzen.

    Zum Neuaufsetzen ist es zu früh, und das SP2 einfach nochmal drüber
    bügeln ist so ziemlich die schlechteste Aktion, die du machen
    könntest.

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Sonntag, 26. Juni 2016 16:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Winfried,

    die Installation des WSUS-Updates KB2938066 schlug leider fehl: "Es liegt ein dieses Windows Installer-Paket betreffenden Problem vor. Ein Programm, das im Rahmen der Installation ausgeführt wurde, wurde nicht erfolgreich abgeschlossen. Wenden Sie sich an das Supportpersonal oder den Hersteller des Pakets."

    Der Tipp mit dem Entpacken, Umbenennen  und Ersetzen der DbCert, DbCertDll, and DbCertSql wie hier zu lesen:

     https://social.technet.microsoft.com/Forums/de-DE/97e42e3e-c453-452a-bb7b-0d246a4cdee6/kb2720211-installation-failed-with-error-code-1603?forum=winserverwsus

    führte nicht zum Erfolg. Im Ergebnis kam ich mit der WSUS-Konsole nicht mehr auf die Datenbank, auch nicht nach dem Umschalten der SUSDB in den multi_user Mode per SQL Studio Express.

    Nach einem ähnlichen Problem mit dem WSUS-Update KB2720211  konnte ich kürzlich nach der erneuten Installation des WSUS 3.0 SP2 wieder auf die WSUS-Konsole zugreifen.

    Leider hat das diesmal nicht geklappt. Die Installation von WSUS 3.0 SP2 unter Verwendung der vorhandenen Datenbank endet ebenfalls mit obiger Fehlermeldung: "Es liegt ein dieses Windows Installer-Paket betreffenden Problem vor...", obwohl ich die vor dem KB2938066-Update gesicherten Daten WSUSSignDb.dll und WSUSSignDb.cer zuvor in den ursprünglichen Ordner: C:\WINDOWS\SYSMSI\SSEE\MSSQL.2005\MSSQL\SchemaSig\ kopiert habe, ebenso die Datei C:\Programme\Update Services\Database\WSUSSignDb.sql

    In der WSUSCA...log steht:

    Changed database context to 'SUSDB'.
    Msg 15151, Level 16, State 1, Server \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query, Procedure sp_revokedbaccess, Line 51
    Cannot drop the user 'DCFILE03\WSUS-Administratoren', because it does not exist or you do not have permission.
    Changed database context to 'SUSDB'.
    Msg 15151, Level 16, State 1, Server \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query, Procedure sp_revokedbaccess, Line 51
    Cannot drop the user 'NT-AUTORITÄT\NETZWERKDIENST', because it does not exist or you do not have permission.
    Changed database context to 'SUSDB'.
    Msg 33002, Level 16, State 1, Server \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query, Procedure spSetupLogin, Line 0
    Access to module dbo.spSetupLogin is blocked because the signature is not valid.
    Changed database context to 'SUSDB'.
    Msg 15151, Level 16, State 1, Server \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query, Procedure sp_revokedbaccess, Line 51
    Cannot drop the user 'DCFILE03\WSUS-Administratoren', because it does not exist or you do not have permission.
    Changed database context to 'SUSDB'.
    Msg 15151, Level 16, State 1, Server \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query, Procedure sp_revokedbaccess, Line 51
    Cannot drop the user 'NT-AUTORITÄT\NETZWERKDIENST', because it does not exist or you do not have permission.

    Habe die Benutzerrechte überprüft bzw. angepasst, daß der installierende Benutzer Mitglied der WSUS-Administratoren ist, Windows Internal Database und Windows Update Service neu gestartet; ich bekomme WSUS einfach nicht mehr installiert.

    Grüße, Peter


    Montag, 27. Juni 2016 16:45
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 27.06.2016 schrieb Peter M. Huber:

    Nach einem ähnlichen Problem mit dem WSUS-Update KB2720211  konnte ich kürzlich nach der erneuten Installation des WSUS 3.0 SP2 wieder auf die WSUS-Konsole zugreifen.

    Wenn es schon früher Probleme gegeben hat, wäre es wohl besser den
    Server komplett neu zu machen. Nicht das noch irgendwelche Altlasten
    rumgeistern. Geht schneller und ist zielführender.

    In der WSUSCA...log steht:

    Changed database context to 'SUSDB'.
    Msg 15151, Level 16, State 1, Server \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query, Procedure sp_revokedbaccess, Line 51
    Cannot drop the user 'DCFILE03\WSUS-Administratoren', because it does not exist or you do not have permission.

    Gibt es die Gruppe WSUS-Administratoren auf dem System? Ist das ein
    Domain-Member? DC und Fileserver? Wie genau war denn die Reihenfolge
    der Installation? Windows dann DC und dann WSUS? Riecht für mich nach
    der falschen Reihenfolge. Wenn der WSUS zum DC gemacht wird, muss
    vorher alles vom WSUS komplett deinstalliert werden, IIS und die
    komplette WSUS-Rolle.

    Habe die Benutzerrechte überprüft bzw. angepasst, daß der installierende Benutzer Mitglied der WSUS-Administratoren ist, Windows Internal Database und Windows Update Service neu gestartet; ich bekomme WSUS einfach nicht mehr installiert.

    Mit welchem genauen Benutzer installierst Du? Lokaler Admin oder
    Domain Admin?

    Servus
    Winfried

    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Montag, 27. Juni 2016 21:09
    |
  • Question
    Anmelden
    0
    Anmelden
    Wenn es schon früher Probleme gegeben hat, wäre es wohl besser denServer komplett neu zu machen.

    und noch Ergänzend: wäre es DIE Gelegenheit, den WSUS auf eine aktuelle Platform zu migrieren.

    Wenn ich den ersten Post richtig lese ist das noch ein 2003R2 Dinosaurier ;)

    Gruß TechnikSC885

    Dienstag, 28. Juni 2016 06:44
    |
  • Question
    Anmelden
    2
    Anmelden

    Hallo zusammen,

    DIE Gelegenheit habe ich denn auch genutzt und eine Migration durchgeführt. Jetzt klappt's auch wieder mit den Updates. Allerdings war der Weg etwas steinig:

    - SUSDB via SQL Studio Manager auf Quellserver (Domain Member) gesichert
    - neuen Windows Server 2012 R2 als Domain-Member installiert (Zielserver)
    - WSUS-Rolle auf Zielserver aktiviert, Angabe des neuen Speicherortes für die Binärdateien (WsusContent)
    - Domänen-Admins auf Zielserver zur lokalen Gruppe der WSUS-Administratoren hinzugefügt (wie beim Quellserver)
    - Microsoft SQL Server 2012 Express auf dem Zielserver installiert (für den SUSDB-Import)

    Fehlermeldung bei Installation der SQL-Verwaltungstools: Fehler beim Aktivieren der Windows-Funktion: NetFx3. Fehlercode : -2146498298 | Lösung: NetFramework 3.5 via Feature-Installation im Servermanager unter Angabe des Quellpfades (Windows Installations-Image) nachinstalliert, anschließend SQL Verwaltungstool-Installation wiederholt.

    - SQL-Server Management Studio auf Zielserver gestartet (als Administrator, sonst keine Verbindung zur WID (Windows Internal Database); Hinweis: Nach Abschluss der Installation lässt sich das Studio auch 'normal' starten.)
    - Serverdaten eingegeben: \\.\pipe\MICROSOFT##WID\tsql\query (=WID)
    - SUSDB-Backup vom Quellserver im SQL-Server Management Studio auf dem Zielserver in die WID importiert

    1. Fehlermeldung beim Import: Property BackupDirectory is not available for Settings ‘Microsoft.SqlServer.Management.Smo.Settings’. This property may not exist for this object, or may not be retrievable due to insufficient access rights.  (Microsoft.SqlServer.Smo) | Lösung: Neuer Registry-Eintrag für Backup-Verzeichnis am Server: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL11E.LOCALDB\MSSQLServer\ Neue Zeichenfolge: BackupDirectory,  Wert: Pfad zur Backup-Datei

    2. Fehlermeldung beim Import: The backup set holds a backup of a database other than the existing ... database | Lösung:Wiederherstellungs-Optionen: Ziel-Datenbank überschreiben

    3. Fehlermeldung beim Import: Fehler bei der Wiederherstellung von Datenbank 'SUSDB'. (Microsoft.SqlServer.Management.RelationalEngineTasks) System.Data.SqlClient.SqlError: Der exklusive Zugriff auf die Datenbank ist nicht möglich, da die Datenbank gerade verwendet wird. (Microsoft.SqlServer.SmoExtended) | Lösung: Wiederherstellungs-Optionen: Bestehende Verbindungen mit der Ziel-Datenbank schließen (Single User Modus)

    4. Fehlermeldung beim Import: System.Data.SqlClient.SqlError: Fehler bei Schemaüberprüfung für Datenbank 'SUSDB'. (Microsoft.SqlServer.SmoExtended) | Lösung: ignorieren und in Admin-Eingabeaufforderung folgenden Befehl ausführen: "%ProgramFiles%\Update Services\Tools\wsusutil.exe" postinstall

    - Binärdaten vom Quellserver auf den Zielserver kopiert (WsusContent)
    - WSUS Management Konsole geöffnet und die Einstellungen überprüft
    - In den Domänen-Gruppenrichtlinien den neuen WSUS-Server eingetragen (Port: 8530)
    - an einem "Problem-Client" (ehemals XP pro, jetzt Windows 7 pro 64 bit) das Windows-Update über die Systemsteuerung gestartet: Dabei kam es zunächst zum Fehler 0x80244010 (Client hätte zu viele Verb. zum Server); nach dem erneuten Abrufen der Updates war der Fehler verschwunden und Updates wurden installiert. Und endlich stand der Bericht des Clients in der WSUS-Konsole.

    Inzwischen melden sich auch die anderen Clients peu à peu beim WSUS :-)

    Grüße und besten Dank für die Unterstützung

    Peter



    Freitag, 1. Juli 2016 14:01
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Peter,

    schön zu hören/lesen, dass es wieder läuft :)

    Und danke für das ausführliche Feedback. Vielleicht hilft das dem ein oder anderen Migrationswilligen noch.


    Gruß TechnikSC885

    Freitag, 1. Juli 2016 14:09
    |