Der Fall des hängenden Update zum MS10-070/KB2416472
Dienstag, 1. März 2011, 22:53
Abgelegt unter: Der gelöste Fall | Tags: , , , , ,

Vor zwei Wochen erreichten uns – während ich in den Ferien weilte -  mehrere Meldungen von Benutzern, die allesamt dasselbe Problem feststellten, was dann auch von Administratoren-Kollegen verifiziert werden konnte:

Download hängt stundenlang bei 66%

Auf allen betroffenen Geräten blieb der Download des  „Sicherheitsupdate für Microsoft .NET Framework 4“ (MS10-070/KB2416472) bei 66% stehen, worauf sich in dem abgebildeten Dialog stundenlang nichts mehr bewegte, bis die Benutzer entnervt auf „Cancel“ klickten. Leider dauerte es dann jeweils nicht allzulange, bis die Installation des Updates erneut gestartet wurde, da dieses unseren Client zur Installation zugewiesen ist und die entsprechende Zeitpunkt für das Assignment bereits deutlich in der Vergangenheit liegt.

Dieser Effekt trat im laufenden Betrieb der Clients auf und hat nichts mit den Problemen beim Schritt „Install Updates“ in Tasksequenzen zu tun, den wir in unserer Umgebung leider auch beobachten.

Auf den betroffenen Geräten konnte – wie meine Admin-Kollegen rasch herausfanden – das fragliche Update als Workaround problemlos über Microsoft-Update installiert werden, worauf dann die nervenden Installationsversuche durch den Configuration Manager Client aufhörten.

Zurück aus den Ferien habe ich dann versucht, die Ursache dieser Downloadprobleme zu ergründen und wurde auch recht rasch fündig. Die Geschichte des betroffenen Updates ist relativ lang; so ist auch im entsprechenden Security-Bulletin MS10-070 zu lesen, dass dieses inzwischen viermal überarbeitet wurde.

Beim Update KB2416472 handelt es sich um ein gebündeltes Update, d.h. unter dem Eintrag dieses Updates werden in der Konsole mehrere Updates aufgelistet. Und genau hier lag das Problem:

Unvollständiges Update zum KB2416472

Wie man im obigen Screenshot erkennen kann, wurden in der Konsole drei Updates zum KB2416472 aufgelistet, dabei handelt es sich um die Varianten für x86-, x64- und Itanium-Systeme. Alle drei Updates werden als „Downloaded: yes“ ausgewiesen, wie das der grüne Rahmen zeigt. Betrachtet man nun jedoch die „Content Information“ zu einem der drei Updates, kann man sehen, dass hier mehrere Updates gebündelt sind. Und wie das im roten Rahmen zu sehen sind, sind zwei dieser drei Updates heruntergeladen, das dritte jedoch nicht. „Zwei von drei Updates?“ Genau: „66%!“

Wie zudem im blauen Rahmen zu sehen ist, hat das fehlende Update zudem eine deutlich höhere Content-ID als die anderen beiden, was den Schluss nahelegt, dieses erst später nachgeliefert wurde. Und das passt auch zu unseren Beobachtungen: Schliesslich wurde MS10-070 bereits am 28. September 2010 publiziert und unzählige unserer Clients konnten dieses Update in den vergangenen Monaten problemlos installieren. Erst in jüngster Zeit wurden hier Probleme gemeldet.

Die jüngsten Installationsversuche dieses Updates schlugen also fehl, da die Clients versuchten, auch den dritten, nicht verfügbaren Teil beim Distribution Point abzuholen. Dies sieht man bestens im UpdatesHandler.log eines betroffenen Gerätes:

Bundle update (8b86deae-c862-4405-8fca-3a2dcfae1de0) is requesting download from child updates for action (INSTALL)        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Starting download on action (INSTALL) for Update (57529fa0-4c49-458f-bd14-08c1c87679d7)        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Contents already available for the update (bfa8bdd3-cf5c-44e9-b937-98aad87e0451).        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
Contents already available for the update (ee89b5c2-ac3b-4216-9bb2-e0654ef63626).        UpdatesHandler        09.02.2011 09:33:12        2876 (0x0B3C)
CancelJob received from SDM.        UpdatesHandler        09.02.2011 15:35:52        4908 (0x132C)

So zeigt dieser Logauszug, dass das „Bundle Update“ den Download der „Child-Updates“ verlangt.  Zwei Inhalte sind „already available“, der dritte Inhalt soll jedoch heruntergeladen werden. Doch dann geschieht nichts mehr, bis der der betroffene Benutzer unzählige Stunden später auf „Cancel“ geklickt hat.

Dies erklärt auch, weshalb das Problem auch durch manuelle Installation via Microsoft Update gelöst werden konnte, denn dort dürften ja – im Gegensatz zu unserem Distribution Point – alle benötigten Files vorhanden gewesen sein.

Die definitive Lösung dieses Problems war nun trivial: Ich habe nun die betreffenden Updates zum KB2416472 nochmals heruntergeladen und die Distribution Points aktualisiert. Danach waren die Updates komplett, wie im grünen Rahmen zu sehen ist:

Vervollständigtes Update zum KB2416472

Auch war nun das Update mit der im Protokoll genannten GUID 57529fa0-4c49-458f-bd14-08c1c87679d7 tatsächlich auf unseren Distribution Points zu finden, die Hänger bei 66% waren beseitigt.

Beim zusätzlichen Update handelte es sich übrigens im konkreten Falle um das „Update für Microsoft .NET Framework 4 für Probleme bei ausstehenden Dateiumbenennungsvorgängen“ zum Microsoft KB-Artikel 2473228.



Der Fall des nicht funktionierenden Server-Manager
Samstag, 16. Oktober 2010, 23:13
Abgelegt unter: Der gelöste Fall | Tags: , , , ,

Als ich auf einem unserer Server (mit Windows Server 2008 R2) per Remote-Desktop einloggte, wurde wie üblich gleich der Server Manager gestartet. Doch anstatt mir irgendwelche Daten unter „Roles“ und „Features“ zu zeigen, meinte dieser lapidar: „Error.“ Bei den Fehlerdetails wird folgendes angegeben: „Unerwarteter Fehler beim Aktualisieren von Server-Manager: Der Remoteprozeduraufruf ist fehlgeschlagen. (Ausnahme von HRESULT: 0x800706BE)“. [engl.: „Unexpected error refreshing Server Manager: The remote procedure call failed (Exception from HRESULT: 0x800706BE)“]

Server Manager Error: Exeption from HRESULT: 0x800806BF

Als ich nach Hinweisen zu diesem Fehler suchte, der übrigens auf unseren Servern mit Windows Server 2008 R2 schon mehrfach zugeschlagen hat, fand einen Thread in den Windows Server Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wird dort folgendes vorgeschlagen:

Please follow the instructions from the following website to download and run System Update Readiness Tool on your computer.
http://support.microsoft.com/kb/947821

If the issue is not resolved after running the tool, please check the result of CheckSUR.log (%windir%\logs\cbs\checksur.log) and ServerManager.log (inside C:\Windows\Logs)

Obwohl ich mir auf Anhieb keinen Reim auf die Zusammenhänge zwischen einem „System Update Readiness Tool“ und einem nicht funktionierenden Server Manager machen konnte, schaute ich mir den KB-Artikel 947821 an und lud mir das dort referenzierte und knapp 100MB grosse Tool für den Server 2008 R2 herunter und startete dieses per Doppelklick, worauf der „Hotfix for Windows (KB947821)“ installiert wurde. Dies dauerte eine geraume Zeit und wurde schlussendlich mit „Installation complete“ quittiert.

Darauf startete ich erneut den Server Manager: Fehlanzeige! Immer noch dieselbe Fehlermeldung! Also konsultierte ich das beschriebene CheckSUR.log, das im Verzeichnis %windir%\logs\cbs zu finden ist.

CheckSUR.log

In diesem Log stachen mir zwei Dinge ins Auge: Erstens wurde eine „CBS MUM Corruption 0x00000000“ in einem bestimmten File gefunden (was auch immer das heissen soll), zweitens wurde weiter unten genau zum betreffende MUM-File (und dem offenbar dazugehörenden CAT-File) angemerkt, dass das „Repair File“ fehle:

Unavailable repair files:
servicing\packages\Package_for_KB2387149_RTM~31bf3856ad364e35~amd64~~6.1.1.1.mum
servicing\packages\Package_for_KB2387149_RTM~31bf3856ad364e35~amd64~~6.1.1.1.cat

Was die zwei fehlenden Repair-Files mit meinem nicht funktionierenden Server Manager zu tun haben sollten, war mir keineswegs klar. Und was diese Meldungen nun tatsächlich bedeuten sollten, hatte ich erst recht keinen blassen Schimmer. Also suchte ich weiter und fand die Anleitung „Advanced guidelines for diagnosing and fixing servicing corruption“ bei MSDN, die mir hier etwas weiterhalf: Diese Meldungen sollten wohl heissen, dass das Systemupdate-Vorbereitungstool zwei Dateien eines Patches erkannte, die wohl nicht korrekt im Servicing-Store abgelegt waren:

If you get the Unavailable repair files message, this indicates that some of the inconsistent files found by the tool cannot be fixed as the correct versions of the replacement files are not carried by the tool.

Und zum Glück sind in dieser Anleitung auch die Schritte zur Lösung des Problemes beschrieben:

Get the files required from other sources. The options available can be found in the “Options for obtaining files” section below.

Da es sich bei den fehlenden Files offenbar um Dateien zum Update KB2387149 handelt, habe ich dieses Update – es handelte sich in meinem heutigen Fall um das Sicherheitsupdate für den Windows Server zum Security Bulletin MS10-074, welches am 11. Oktober 2010 publiziert worden ist – manuell heruntergeladen und in einen temporären Ordner entpackt, wobei die Platzhalter <…> in nachfolgendem Befehl mit den passenden Werten zu ersetzen und der Ordner, wohin die Files ausgepackt werden sollen, vorgängig anzulegen sind:

expand <...pfad zu...>\<...Update...>.msu /f:* c:\<...Auspackziel...>

Als nächstes habe ich das CAB-File entpackt, welches nun in diesem Ordner zu finden war:

expand <...pfad zu...>\<...Update...>.cab /f:* C:\<...Auspackziel...>

Und da lagen nun in diesem zweiten Ordner die beiden Dateien, die im CheckSUR.log als „unavailable“ bezeichnet wurden, vor mir. Wie die Anleitung „Advanced guidelines for diagnosing and fixing servicing corruption“ beschreibt, kopierte ich die beiden Dateien nun in das passende Verzeichnis:

All files of type *.mum and *.cat should be placed in the %windir%\Temp\CheckSUR\servicing\packages directory

Danach habe ich das Systemupdate-Vorbereitungstool erneut gestartet und die Dateien wurden sauber in den Servicing-Store übernommen, wie das neue CheckSUR.log bestätigt:

CheckSUR.log bestätigt erfolgreiche Reparatur

Auch der Server-Manager konnte sofort danach wieder ohne Probleme ausgeführt werden:

Der Server Manager funktioniert wieder!

Weshalb der Server-Manager nicht mehr funktionieren wollte, habe ich immer noch keinen blassen Schimmer… Und weshalb dieses Problem überhaupt aufgetreten ist, weiss ich noch weniger. Tatsache ist einfach, dass ich dieses Problem bisher noch jedesmal auf genau diese Weise lösen konnte:

  • Als ich das erste Mal mit diesem Problem konfrontiert wurde, habe ich Stunden damit verbracht, den Server Manager des betroffenen Servers wieder funktionstüchtig zu machen.
  • Als dieses Problem zum zweiten Mal zuschlug, konnte ich mit Hilfe einiger Notizen vom ersten Fall das Problem rascher lösen, wobei ich mir dabei detailliertere Aufzeichnungen machte.
  • Ich hoffe, das es nun mit Hilfe dieses Beitrages, den ich heute anlässlich des dritten Vorkommnisses nebenher erstellt habe, auch weiteren Lesern gelingt, das offenbar häufiger auftretende Problem zügig lösen zu können.

Nachtrag vom 9.11.2010:

Heute hat Microsoft den KB-Artikel 2461206 „You are unable to view Roles and Features and receive error code 0x800706BE in Server Manager“ zu dieser Problematik publiziert.



Der Fall des Acer-Notebooks, das den Apple Airport Express nicht mochte
Montag, 30. August 2010, 12:51
Abgelegt unter: Der gelöste Fall | Tags: , , , , , ,

Kürzlich wurde ich mit einem weiteren skurrilen Problem konfrontiert. Dabei handelte sich sich um ein Acer Aspire 5100 Notebook, das die Internetverbindung per Wireless LAN über einen Apple Airport Express herstellen sollte.

Am Anfang klappte alles wunschgemäss: Das gewünschte WLAN wurde in der Suche nach Drahtlosnetzwerken angezeigt und nach dem Klick auf „Verbinden“ wurde nach dem notwendigen WPA2-Preshared-Key gefragt. Der Key wurde problemlos akzeptiert und kurz darauf wurde auch bestätigt, dass die Verbindung erfolgreich hergestellt werden konnte.

Doch was sollte denn das? Das auf diesem Notebook installierte Vista behauptete stur, es hätte nur lokalen Netzwerkzugriff! Internetzugriff? Weit gefehlt…

Die Netzwerkdiagnose von Windows hatte einzig zu vermelden, dass ein „Problem mit dem Netzwerkrouter oder Breitbandmodem“ die Internetverbindung möglicherweise verhindere. Doch dass der Apple Airport Express einwandfrei konfiguriert war und problemlos funktionierte, bewies ein weiterer Zugriffsversuch mit einem anderen Notebook und einem iPhone.

Als ich dann das übliche „ipconfig /all“ in einem CMD-Fenster ausführte, schien alles in Ordnung zu sein: Das Adresse bezog eine passende IP-Adresse per DHCP, DNS-Server und Standardgateway waren ebenfalls i.O. Der Ping auf die eigene IP-Adresse wurde einwandfrei beantwortet und der Ping auf den Airport… ähhh „Destination host unreachable“?

Da kommunizierte also das Gerät „einwandfrei“ mit der Airport-Basisstation und bezog per DHCP eine passende IP-Adresse mitsamt den korrekten übrigen Settings und wollte daraufhin trotzdem nicht mehr kommunizieren?

Nun ja: „Skurrile Probleme“ rund um die Hardware schreien üblicherweise danach, dass man mal den entsprechenden Treiber unter die Lupe nimmt. So besuchte ich die Acer Webseite und lud von dort den für das Acer Aspire 5100 angebotenen „Atheros Wireless LAN Treiber“ 7.1.0.90 (vom 05.12.2008) herunter und installierte diesen. Leider Fehlanzeige… Auch der neue Treiber brachte keinerlei Verbesserung.

Da das betreffende WLAN-Modul von Atheros stammte, suchte ich im Internet nach diesem Hersteller. Und siehe da: Auf dessen Webseite http://www.atheros.cz/ fand ich einen weiteren, neuen Treiber (Version 7.7.0.331 vom 12.06.2009) für das von Acer verbaute Modul Atheros AR5007EG.

Ich lud diesen Treiber herunter und startete dessen Installation. Ergebnis: Da ich auf dem Notebook das vom Apple Airport Express bereitgestellte WLAN bereits als bevorzugtes Netzwerk konfiguriert hatte, war das Gerät schneller online als die Treiberinstallation Erfolg vermelden konnte.

Fazit: Neue Treiber können etliche Probleme beseitigen. Doch nicht immer findet man diese auf der Webseite des Herstellers des PC/Notebook. Es kann sich lohnen, auch direkt beim Hersteller der jeweigen Gerätekomponenten nach Treibern zu suchen…



Der Fall des lahmgelegten Notebooks
Freitag, 27. August 2010, 17:35
Abgelegt unter: Der gelöste Fall | Tags: , , , ,

Kürzlich wurde ich mit einem Notebook konfrontiert, dessen Besitzer am Verzweifeln war: „Das Notebook sei schlicht und einfach nicht mehr benutzbar“, lautete der lapidare Hilferuf. Obwohl ich derart schwammige Problemmeldungen keineswegs schätze, habe ich mir das betroffene Gerät angeschaut:

Nach dem Einschalten des Notebooks startete das installierte Vista Home Premium im gewohnten Tempo und der Benutzer meldete sich an, sobald der Anmeldedialog erschien. Soweit war noch alles in Ordnung. Doch unmittelbar nach dem Erscheinen des Desktops wurde das System unerträglich langsam und fror nahezu ein. Es gelang mir noch, den Taskmanager zu starten; dieser zeigte 100% CPU-Auslastung an. Kurz darauf wurde das System dermassen langsam, dass im Taskmanager nicht einmal mehr die Prozesslisten, geschweige denn die Grafiken zum Verlauf der CPU-Auslastung aktualisiert wurden. Zudem lief der Lüfter des Gerätes auf vollen Touren.

Nach etlichen Minuten Wartezeit wurde der Taskmanager zwar wieder etwas lebendig und begann seine Ansicht wieder zu aktualisieren, aber unter einer „benutzbaren Applikation“ stelle ich mir etwas anderes vor. Die CPU-Last blieb unverändert bei 100%.

In der Benutzer-Ansicht des Taskmanager waren nur Prozesse zu sehen, die kaum CPU-Last produzierten. Die Ursache für die hohe CPU-Last musste deshalb anderswo liegen, weshalb ich auf den Knopf „Prozesse aller Benutzer anzeigen“ klickte. Es dauerte weitere vier bis fünf Minuten, bis sich die Anzeige dunkel verfärbte und nochmals geraume Zeit, bis ich den Dialog der Benutzerkontensteuerung (UAC) abnicken konnte. Doch trotz weiterer unzähliger Minuten Wartezeit erschien der Taskmanager mit der Ansicht aller Prozesse nicht.

Es gelang mir aber, von einem USB-Stick den „Process Explorer“ der Sysinternals-Suite zu starten. Hier konnte ich sogleich in der Anzeige erkennen, dass ein Prozess namens „AAWService.exe“ für die immense CPU-Last verantwortlich war. Der Rechtsklick auf den entsprechenden Eintrag mit anschliessendem „Kill Process“ wurde jedoch sogleich mit „Zugriff verweigert“ quittiert.

Eine kurze Recherche bei Google förderte zu Tage, dass es sich bei AAWService.exe um den Dienst der Software „Ad-Aware“ von Lavasoft handelt. Ich öffnete deshalb die Konsole der Dienste-Verwaltung und suchte dort nach dem Dienst „Lavasoft Ad-Aware Service“. Und siehe da: Dessen Status war auch noch nach weit über 30 Minuten nach dem Systemstart immer noch auf „wird gestartet“. Mit viel Geduld gelang es mir, den Starttyp des Dienstes auf  „manuell“ zu setzen, worauf ich das Gerät neu startete.

Nach dem Neustart reagierte das System wieder in normaler Geschwindigkeit, weshalb ich anschliessend – in Rücksprache mit dem Benutzer – die Ad-Aware-Software komplett deinstallierte. Auch der Task-Manager liess sich dann wieder wie gewohnt in die Ansicht „Prozesse aller Benutzer anzeigen“ umschalten…

Weshalb die Ad-Aware-Software Amok lief, ist mir nicht bekannt; für eine Suche nach der tieferen Ursache dieses Problems fehlt mir sowohl die Zeit als auch die Lust.

Fazit: Sündenbock dank „Process Explorer“ gefunden. Herzlichen Dank an Mark Russinovich für die Sysinternals-Tools!