WSUS: Clients geben keinen Statusbericht beim Server ab

Im Rahmen des Rollouts eines wichtigen Sicherheitsupdates habe ich über die letzten Tage festgestellt, dass einige Windows XP Clients keinen Statusbericht beim WSUS Server (3.0) mehr abgeben. In der Update-Logdatei des Clients C:\windows\WindowsUpdate.log werden dabei folgende Warnungen protokolliert:

WARNING: SyncUpdates failure, error = 0x8024400E, soap client error = 7,
         soap error code = 400, HTTP status code = 200
WARNING: SOAP Fault: 0x000190
WARNING:     faultstring:Fault occurred
WARNING:     ErrorCode:InternalServerError(5)
WARNING:     Message:(null)
WARNING:     Method:"http://www.microsoft.com/SoftwareDistribution/
             Server/ClientWebService/SyncUpdates"
WARNING:     ID:207ae298-8fe6-46d2-946b-8daebdb4c075
WARNING: PTError: 0x8024400e
WARNING: SyncUpdates_WithRecovery failed.: 0x8024400e
WARNING: Sync of Updates: 0x8024400e
WARNING: SyncServerUpdatesInternal failed: 0x8024400e

Weiterhin wird auf betroffenen Clients folgender Fehler im Eventlog vermerkt:

Event Type:	Error
Event Source:	Windows Update Agent
Event Category:	Softwaresynchronisation 
Event ID:	16
Date:		27.03.2009
Time:		11:52:21
User:		N/A
Computer:	client01
Description:
Unable to Connect: Windows is unable to connect to the automatic updates
service and therefore cannot download and install updates according to
the set schedule. Windows will continue to try to establish a connection.

Wie beim WSUS Product Team Blog im Artikel Client/Server Synchronization issues und in Knowledgebase-Eintrag KB954960: Some computers do not receive updates from the WSUS server beschrieben, wird das Problem aufgrund eines Fehlers bei den Update-Approvals ausgelöst, der wiederum durch eine überarbeitete Revision des Office 2003 Service Pack 1 Updates verursacht wird. Das Problem tritt sowohl mit WSUS 3.0 als auch mit WSUS 3.0 SP1 auf.

Für WSUS 3.0 SP1 stellt Microsoft im o.g. Artikel einen Patch bereit, der das Problem beheben soll. Benutzer von WSUS 3.0 ohne Service Pack 1 müssen sich stattdessen mit folgendem Workaround behelfen:

1. Auf dem WSUS-Server in der Liste der Updates das Office 2003 Service Pack 1-Update mit der Update ID D359F493-0AAD-43FA-AF5C-6763326CD98F suchen.
2. Sicherstellen, dass das Update bereits abgelehnt (declined) ist. Ist es das nicht, muss es mit der rechten Maustaste angeklickt und im Kontextmenü die Option „Ablehnen“ bzw. „Decline“ gewählt werden.
3. Den Status des Updates von „Abgelehnt“ auf „Nicht genehmigt“ (not approved) setzen, indem mit der rechten Maustaste auf das Update geklickt und „Genehmigen“ (approve) gewählt wird. An den daraufhin erscheinenden Genehmigungseinstellungen müssen keine Änderungen vorgenommen werden, so dass das Fenster unmittelbar nach Erscheinen mit „OK“ wieder geschlossen werden kann.
4. Das Update mittels rechter Maustaste und Auswahl von „Ablehnen“ bzw. „Decline“ wieder ablehnen.

Bei der nächsten Suche nach Updates sollten die Clients ihren Statusbericht wieder ordnungsgemäß abliefern und mit Updates versorgt werden.

Auf einigen Arbeitsstationen erhielt ich nach Korrektur des Fehlers und manuellem Triggern der Suche nach Updates mittels wuauclt /detectnow übrigens noch eine weitere Fehlermeldung in der c:\windows\WindowsUpdate.log:

* WARNING: Failed to synchronize, error = 0x8024400E
* WARNING: Exit code = 0x8024400E
*********
**  END  **  Agent: Finding updates [CallerId = AutomaticUpdates]
*************
2009-WARNING: WU client failed Searching for update with error 0x8024400e
>>##  RESUMED  ## AU: Search for updates 
               [CallId = {C4C563E2-CE8C-4C65-85AA-77B8A5B7927E}]
# WARNING: Search callback failed, result = 0x8024400E
# WARNING: Failed to find updates with error code 8024400E
#########
##  END  ##  AU: Search for updates 
         [CallId = {C4C563E2-CE8C-4C65-85AA-77B8A5B7927E}]
#############
AU setting next detection timeout to 2009-03-27 14:16:24
Setting AU scheduled install time to 2009-03-28 02:00:00

Laut Beschreibung im Artikel WSUS clients fail with WARNING: SyncServerUpdatesInternal failed: 0x80244010 des WSUS Support Team Blogs können diese Warnungen jedoch ignoriert werden. So war es auch bei mir: Nach einiger Zeit war der Fehler verschwunden und die Automatischen Updates funktionierten wieder wie gewünscht.

Cisco IOS: Kaskadieren von Switches & PortFast BPDU guard

In verschiedenen Situationen kann es dazu kommen, dass Ports auf Cisco-Switchen automatisch deaktiviert werden und den Status „err-disabled“ erhalten. Eine der möglichen Ursachen ist beispielsweise der Anschluss eines Switches an einen Port, bei dem die optionalen Spanning Tree Features „PortFast“ und „BPDU Guard“ aktiviert sind.

STP PortFast bewirkt, dass ein Port unmittelbar nach Herstellen des Links in den Forwarding-Modus schaltet und damit die sonst üblichen Listening und Learning-States des Spanning Tree Protokolls überspringt. Die Option ist ausschließlich für den Anschluss von Endgeräten wie Computer oder Netzwerkdrucker gedacht und soll mögliche Timeouts z.B. während des Bezugs einer IP-Adresse von einem DHCP-Server verhindern. Keinesfalls an einen solchen Port angeschlossen werden sollten dagegen Geräte wie z.B. Switches oder Hubs, deren Betrieb ggf. zu Schleifen führen kann.

Mit der Option BPDU Guard lässt sich sicherstellen, dass derartige Geräte an einem im PortFast-Modus befindlichen Port nicht verwendet werden können. Empfängt der Switch eine BPDU (Bridge Protocol Data Unit) auf einem für Endgeräte konfigurierten Port und die Funktion BPDU Guard ist aktiviert, wird er vom Switch automatisch deaktiviert und in den Status „err-disabled“ versetzt:

sw-2960-1#show interfaces fastEthernet 0/10 status
Port     Name    Status         Vlan    Duplex    Speed Type
Fa0/10           err-disabled   1       auto      auto 10/100BaseTX

Allerdings gibt es auch Fälle, in denen die Bildung von Schleifen von vornherein ausgeschlossen werden kann und das Kaskadieren von Switches ausdrücklich gewünscht ist; beispielsweise wenn ein bestehendes Netzwerk kurzfristig um einen kleinen SOHO-Switch erweitert werden muss. In diesem Fall kann der BPDU Guard, insbesondere wenn seine Funktion nicht bekannt ist, zum Hindernis werden: Man schließt einen Switch an, doch eine Verbindung kommt nicht zustande und aus Unwissenheit schiebt man die Probleme möglicherweise auf einen defekten Switch oder andere falsche Ursachen.

Soll ein Switch oder ähnliches Gerät angeschlossen werden, muss die Option PortFast für den entsprechenden Port deaktiviert werden:

sw-2960-1#conf term
Enter configuration commands, one per line.  End with CNTL/Z.
sw-2960-1(config)#interface FastEthernet 0/10
sw-2960-1(config-if)#spanning-tree portfast disable

Gegebenenfalls muss zusätzlich noch sein „err-disabled“ Status zurückgesetzt werden:

sw-2960-1#conf term
Enter configuration commands, one per line.  End with CNTL/Z.
sw-2960-1(config)#interface fastEthernet 0/10
sw-2960-1(config-if)#shutdown
sw-2960-1(config-if)#no shutdown

Unmittelbar danach sollte der Fehlerstatus verschwunden sein:

sw-2960-1#show interfaces fastEthernet 0/10 status
Port     Name    Status         Vlan    Duplex    Speed Type
Fa0/10           notconnect      1       auto      auto 10/100BaseTX

Anschließend sollte sich ein weiterer Switch problemlos anschließen und nutzen lassen. Weiterführende Informationen zu dem Thema gibt es bei Cisco in den Artikeln Spanning Tree PortFast BPDU Guard Enhancement und Errdisable Port State Recovery on the Cisco IOS Platforms. Grundsätzlich empfehlenswert zum Thema Spanning Tree Protkoll ist außerdem der Artikel Understanding and Configuring Spanning Tree Protocol (STP) on Catalyst Switches.