Wenn der SCCM Distribution Point bockt…
Sonntag, 31. Oktober 2010, 21:30
Abgelegt unter: Erkenntnisse | Tags: , , , ,

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:



Wenn noch SCCM-Pakete auf einem gelöschten Distribution Point liegen…
Freitag, 15. Oktober 2010, 21:32
Abgelegt unter: Erkenntnisse | Tags: , , ,

Kürzlich entfernte ich einen nicht mehr gebrauchten Distribution Point. Dies ging ruckzuck: Flugs im „Site Management“ unter den „Site Systems“ der entsprechenden Site den betreffenden Server ausgewählt und die Rolle „ConfigMgr Distribution Point“ entfernt. Fertig!

Fertig? Nein, leider nicht ganz…

Der Distribution Point wurde überall aus den Listen entfernt und man konnte auf diesem auch keine Pakete mehr verwalten. Auf den ersten Blick schien alles in bester Ordnung zu sein. Auf den zweiten Blick hingegen…

Immer wieder tauchten seither Fehlermeldungen auf, dass ein bestimmtes Paket auf dem betreffenden Distribution Point nicht bereitgestellt oder entfernt werden konnte. Und wenn man dann die betreffenden Pakete in der Konsole betrachtete, war tatsächlich der betreffende Distribution Point noch im „Package Status“ aufgelistet, zumeist mit einem Status „Removal Pending“. Dabei war doch dieser Distribution Point längst gelöscht und der entsprechende Server ausrangiert und entsorgt.

Was nun?

Ein entsprechender Artikel „How to Remove a Distribution Point“ aus dem Microsoft Technet half etwas weiter, da dort folgendes dokumentiert ist:

1. Remove all distribution package folders and the SMSPKGSIG signature folder from the distribution point computer.
Important: You must manually remove these components before removing the distribution point role.

Tja, hinterher ist man immer schlauer. Bloss war es etwas schwierig für mich, diese Anweisung nachträglich umzusetzen, da der Distribution Point längst weg war.

Da ich vermutete, dass ich nicht der einzige bin, der einen Distribution Point gelöscht hat, bevor er die Packages von diesem Distribution Point entfernt hatte, suchte ich weiter und fand einen Thread in den System Center Foren von Microsoft, bei welcher dieses Problem diskutiert wurde. Als Lösung wurde dabei auf einen Beitrag im „System Center WebLog by Russ Slaten“ verwiesen, dessen Titel „Removing a retired DP from all your packages“ vielversprechend aussah.

Dieser Beitrag beschreibt, dass das Entfernen der Rolle „Distribution Point“ nicht auch automatisch die Pakete von diesen Distribution Point entferne. Man müsse vorgängig die Pakete vom Distribution Point entfernen, was ziemlich mühsam werden kann, wenn man eine grössere Menge von Paketen auf dem betreffenden Distribution Point bereitgestellt hat. Netterweise stellt Russ Slaten bei dem betreffenden Beitrag ein VB-Skript bereit, mit dem diese Aufgabe automatisiert durchgeführt werden kann. Die Angabe der Namen des Site Servers und des leerenden Distribution Points als Parameter bei Aufruf seines Skriptes „SMSDPClean.vbs“ reichen, und schon würden alle Pakete vom betreffenen Distribution Point entfernt werden.

Wie ich dann leider herausfinden musste, funktioniert dieses Skript problemlos, zumindest solange der Distribution Point noch nicht vom Netzwerk entfernt wurde. Das Skript deckt zwar mit einer kleinen vorzunehmenden Modifikation den Fall ab, dass ein Distribution Point schon gelöscht wurde, doch in meinem Falle mit dem bereits entsorgten Distribution Point half das Skript nicht wirklich weiter.

Langsam aber sicher fragte ich mich, weshalb beim Entfernen der Rolle „Distribution Point“ keine entsprechenden Warn- oder Fehlermeldungen erscheinen, die darauf hinweisen, dass man diese Rolle nicht entfernen solle bzw. könne, da diesem Distribution Point noch Packages zugewiesen seien. Wehmütig dachte ich an den Assistenten, der beim Löschversuch einer Collection erscheint, der auf detaillierteste Weise beschreibt, was alles geschehen wird, wenn man diese Collection löscht.

Jegliches Sinnieren über mögliche Unzulänglichkeiten der SCCM-Konsole half mir jedoch nicht weiter. Ich hatte ein Problem, und das sollte gelöst werden! Also las und suchte ich weiter und stiess auf den Artikel „Deletion of Orphaned Distribution Points“ von Brett Wilms in seinem „System Management Blog“. Und dieser Beitrag half tatsächlich weiter!

Doch bevor ich die Lösung des Problemes präsentieren kann, ist nun ein Warnhinweis fällig:

Die direkte Modifikation einer SCCM-Datenbank wird von Microsoft grundsätzlich nicht unterstützt, ausser sie erfolgt direkt auf Anweisung der Microsoft Support Services. Die beschriebene Lösung hat beim Autor dieses Artikels funktioniert und wird als Beispiel publiziert, wie die Problematik gelöst werden könnte. Die unsachgemässe Anwendung der beschriebenen Lösung kann negative Folgen auf eine SCCM-Umgebung haben. Testen Sie die beschriebene Lösung unbedingt in Ihrer Testumgebung, bevor sie diese auf eigene Verantwortung und eigenes Risiko in Ihrer Produktionsumgebung anwenden. Bitte wenden Sie diese Lösung in Ihrer Umgebung nur genau dann an, wenn Sie wissen was sie tun, und kontaktieren Sie die Microsoft Support Services bei jeglicher Unsicherheit.

Mit Hilfe des SQL Server Management Studio konnte ich mit Hilfe der nachfolgenden beiden Queries sehen, welche Einträge zum fraglichen Distribution Point noch in der Datenbank vorhanden waren, wobei natürlich <DistributionpointName> durch den Namen des gelöschten Distribution Points zu ersetzen ist:

SELECT * FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'

SELECT * FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'

Als ich mich davon überzeugt hatte, dass diese beiden Queries tatsächlich genau (und nur!) die Einträge zum gelöschten Distribution Point lieferten, und ich mich zudem vergewissert hatte, dass ich ein korrektes und aktuelles Backup der betreffenden Site vorliegen hatte, wagte ich es, die folgenden beiden Queries zu starten, um die Spuren des gelöschten Distribution Points in der Datenbank zu beseitigen:

DELETE FROM PkgServers WHERE NALPath like '%<DistributionpointName>%'

DELETE FROM PkgStatus WHERE PkgServer like '%<DistributionpointName>%'

Und tatsächlich: Seither sind die Fehlermeldungen verschwunden.