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.