Fehler:

Ein, auf einem SCCM 2012, angelegtes Treiberpaket lässt sich nicht auf den Distribution Point kopieren!


Analyse:

Wenn das Treiberpaket ganz nochmal über „Distribute Content“ auf den Verteilpunkt kopiert wird, so ist kurze Zeit später im „Content Status“ erkennbar, dass die Verteilung erfolgreich war.

Verteilung auf Distribution Point:
clip_image001

Status nach der Verteilung:
clip_image002

Wenn man jedoch etwas genauer hinsieht ist in den Distribution-Point-Eigenschaften erkennbar, dass es sich bei dem Treiberpaket um ein 0,00MB großes Paket handelt.

Distribution-Point-Eigenschaften direkt nach der „erfolgreichen“ Verteilung:
clip_image003

Bei einer Validierung des Pakets über die Distribution-Point-Eigenschaften schlägt diese nach kurzer Zeit mit „Failed to validate content hash“ fehl!

Start der Validierung:
clip_image005

Resultat der Validierung:
clip_image006

Versucht man das Paket mithilfe eines „Redistribute“ neu zu verteilen tut sich nichts! Es ist lediglich im distmgr.log zu erkennen, dass die Queue sich aus irgendeinem Grund aufgehangen hat und die Verteilung zu einem späteren Zeitpunkt erneut durchzuführen möchte. Die genaue Meldung lautet: „Package ‚1510005D‘ is found in active queue, will try it later“. Meiner Erfahrung zu folge kommt es jedoch nie zu diesen erneuten Versuch!

Erneute Verteilung mittels „Redistribute“:
clip_image007

Logauszug:
clip_image008


Ursache:

Nachdem ich mir das Problem nicht erklären und den Logs keine weiteren Informationen mehr entnehmen konnte habe ich einen Call bei Microsoft eröffnet. Der Microsoft-Techniker hat sich die Mühe gemacht dieses Problem in einer eigenen Testumgebung nachzustellen. Einige Tage später teilte er mir mit, dass es sich um ein generelles Problem handelt, da er es genauso reproduzieren konnte.

Nach einer etwas längeren gemeinsamen Suche haben wir die Quelle des Übels gefunden: Der „Fehler“ hat sich bereits bei der Erstellung des Treiberpakets eingeschlichen!

Im Zuge des Treiberpaket-Erstellungs-Wizards gibt es einen Haken „Update distribution points when finished“, der für die Aktualisierung bereits bestehender Pakete gedacht ist. Da bei einer Neuerstellung dieser Haken keinen Effekt hat, da das Paket ja danach erst per Hand verteilt wird, macht es Sinn diesen raus zu nehmen. Das ist aber ein Trugschluss! Microsoft hat hier einen fiesen Programmierfehler eingebaut! (Da hat der Programmierer wohl ein Bier zu viel getrunken ;-)) Sobald der Haken nicht gesetzt ist, kann das Paket, wie oben beschrieben, NICHT manuell auf den Distribution Point kopiert werden! Dies wurde mir von Microsoft auch so bestätigt!

Treiberpaket-Erstellungs-Wizard:
clip_image009


Lösung:

Leider gibt es für das beschriebene Problem noch keine Lösung, da es noch bei Microsoft eskaliert wird.

Es gibt aber zum Glück folgenden einfachen Workaround.

Workaround durch Neuerstellung des Treiberpakets:
Wie bereits unter dem Punkt „Ursache“ beschrieben tritt das Problem nicht auf wenn der Haken „Update distribution points when finished „ beim Erstellen des Treiberpakets gesetzt ist. Das Treiberpaket wird dann auch mit der richtigen Größe unter den Distribution-Point-Eigenschaften angezeigt!

clip_image010

Workaround für bereits bestehende Treiberpakete:
Wenn bereits mehrere Pakete erstellt wurden ist es natürlich sehr mühsam alle neu anzulegen, daher kann man sich hier mit einem Trick helfen.

Im Ersten Schritt sollten alle betroffenen Pakete vom Distribution Point entfernt werden! Anschließend muss ein beliebiger neuer Treiber dem SCCM hinzugefügt und jedem bestehenden Paket zugerwiesen werden. Beim Hinzufügen ist wieder der Haken „Update distribution points when finished“ vorhanden. Wenn dieser gesetzt ist korrigieren sich alle ausgewählten Pakete! Diese können anschließend erfolgreich verteilt werden. Die Treiberpakete werden dann auch mit der richtigen Größe unter den Distribution-Point-Eigenschaften angezeigt! Der als Workaround importierte Treiber kann natürlich wieder entfernt werden wenn alle Pakete erfolgreich aktualisiert sind.

clip_image011

clip_image012


Richtige Lösung:

Sobald ich von Microsoft eine „richtige“ Lösung für das Problem erhalten habe, werde ich diese natürlich nochmal bloggen!