Vor einiger Zeit wurde ich von einem Kollegen mit dem Problem konfrontiert, dass bei der Installation eines Softwarepaket über den System Center Configuration Manager 2007 der Download mittendrin ohne klar ersichtlichen Grund hängenbleibe. Doch wenn man im Advertisement von „Download content from distribution point and run locally“ auf „Run program from distribution point“ umstelle, könne das Paket problemlos installiert werden. Dies betreffe jedoch nur die eine Site, in einer anderen Site unserer Sitestruktur könne zudem dasselbe Paket problemlos auf beide Arten installiert werden. „Für den Installer dieser Applikation spiele es keine Rolle, ob er lokal oder über einen UNC-Pfad ausgeführt werde; beides funktioniere problemlos, wie er getestet habe. Und die verwendeten Dateien in den Paketen seien doch in allen Fällen und auf allen Distribution Points dieselben und stammten vom selben Source-Verzeichnis“, konstatierte der verzweifelte Kollege. „Ja schon, aber….“, begann meine Antwort.

Auch wenn die Dateien tatsächlich in allen Fällen dieselben sind, ist der Weg, wie die Dateien vom Server zum Client transportiert werden, grundverschieden. Im Falle des „Run program from distribution point“ greift der Client via SMB (d.h. normalen Fileserver-Zugriff) auf den Distribution Point zu. Im Falle von „Download content from distribution point and run locally“ will der Client jedoch die Dateien via BITS (d.h. den „Background Intelligent Transfer Service“) vom Server beziehen, womit auch der IIS („Internet Information Server“ des Distribution Point ins Spiel kommt. Somit liegt der Verdacht nahe, dass es sich beim vorliegenden Problem gar nicht um ein SCCM, sondern ein IIS-Problem handelt.

Denn der IIS blockt standardmässig bestimmte Dateierweiterungen, womit Dateien dieser Typen in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden können. Dies wird auch im Technet-Artikel „Konfigurieren von Windows Server 2008 für Standortsysteme“ beschrieben:

Wenn an BITS-fähige Verteilungspunkte verteilte Paketquelldateien Dateierweiterungen enthalten, die in IIS 7.0 standardmäßig blockiert sind, muss der Abschnitt „requestFiltering“ der Datei „applicationHost.config“ so geändert werden, dass die erforderlichen Dateierweiterungen zugelassen werden.

Und dies geschieht auf folgende Art und Weise: In der Datei „applicationHost.config“ im Verzeichnis „%windir%\System32\inetsrv\config\“ des Distribution Points muss der Abschnitt „<requestFiltering>“ gesucht werden. In diesem Abschnitt sind Einträge in der folgenden Art zu finden:

<add fileExtension=".mdb" allowed="false" />

Wird hier „false“ durch „true“ ersetzt, die Datei „applicationHost.config“ danach gespeichert und der IIS neu gestartet, können nun auch Dateien mit der Endung „.mdb“ über BITS übertragen werden. Und so kann diese Einstellung für jeden benötigten Dateityp vorgenommen werden. Kandidaten in unserer Umgebung waren primär Dateierweiterungen wie „.config“, „.java“, „.mdb“ und „.ldf“. Natürlich lässt sich dies auch gleich pauschal lösen, indem alle entsprechenden Zeilen auskommentiert oder gelöscht werden, denn für alle nicht aufgeführten Dateitypen ist der Transfer gemäss der Default-Einstellung erlaubt. Man muss sich einfach bewusst sein, dass man durch derartige Anpassungen die Angriffsfläche des Servers vergrößert, zumal die Änderungen für alle Websites auf dem jeweiligen Server gelten.

Ganz abgesehen davon, dass man bei der Installation eines neuen Siteservers selten im voraus weiss, welche Dateitypen dann tatsächlich benötigt werden, verschweigt der besagte Technet-Artikel jedoch einen Punkt, der uns schon mehrfach Probleme verursacht hat:

Es gibt nicht nur bestimmte Dateiendungen, die standardmässig geblockt werden, sondern auch Pakete, welche ein Unterverzeichnis „bin“ haben, können in der IIS-Standardkonfiguration nicht via BITS heruntergeladen werden. Hierzu findet man in derselben Datei „applicationHost.config“ etwas weiter unten einen Abschnitt „hiddenSegments“ mit den dazugehörenden Einträgen in der Form:

<add segment="bin" />

Wird diese Zeile (resp. die passende Zeile bei anderen blockierten Verzeichnisnamen) gelöscht, die geänderte Datei gespeichert und der IIS neu gestartet, können danach auch Pakete mit „bin“-Verzeichnissen über BITS ausgeliefert werden.

Dass in unserem Problemfall der Download von einem Distribution Point geklappt hat und vom anderen nicht, lag schlicht und einfach daran, dass die notwendigen Modifikationen der Datei „applicationHost.config“ auf dem einen Server bereits vorgenommen, auf dem anderen jedoch unterlassen wurden.

Bei der Aufarbeitung dieser Thematik als Blogbeitrag bin ich noch über weitere Blogs bzw. Diskussionen gestossen, welche ähnliche Probleme beschreiben. Diese habe ich in unserem Umfeld zwar nicht direkt angetroffen, doch ich denke, dass die abschliessende Erwähnung dieser Beiträge und Links in diesem Zusammenhang durchaus Sinn macht:

• Im Beitrag „This package was a challenge…“ des Blogs „The D-Spot – Tickle your deployment needs“ schreibt Steve De Peet, er hätte noch ein Problem mit „hidden“ (d.h. „versteckten“) Files gehabt, welche zu einem „Hash Verification Error“ führten. Nachdem das Hidden-Flag entfernt und ein Refresh des Distribution Points durchgeführt worden sei, hätte der Download dann geklappt.

• In der Diskussion „Programmdownload bleibt einfach stehen“ in den deutschsprachigen Microsoft System Center Technet Foren zeigte sich, dass weitere Zeichen im Dateinamen (im dortigen Fall handelte es sich um „+“-Zeichen) Probleme verursachten, welche mit Hilfe des Microsoft KB-Artikels 942076 (Error message when you visit a Web site that is hosted on IIS 7.0: „HTTP Error 404.11 – URL_DOUBLE_ESCAPED“) gelöst werden konnten.

• Im Beitrag „Troubleshooting SCCM and BITS Downloads“ liefert Matthew Boyd weitere Hinweise und Tipps zur Lösung von Problemen aus diesem Umfeld.