Wie bereits in meinem Blog Artikel zur SCCM Content Library beschrieben, hat sich das Content Management seit SCCM 2012 grundlegend geändert. Da es aufgrund dieser Änderungen relativ schwierig ist die einzelnen Ordner der Content Library zu durchsuchen und die darin befindlichen Dateien herauszufinden wurde als Teil des ConfigMgr Toolkits (https://www.microsoft.com/en-us/download/details.aspx?id=50012) ein kleines aber extrem hilfreiches Tool von Microsoft veröffentlicht um die Content Library einfach durchsuchen zu können.

In diesem aufbauenden Artikel möchte ich nun auf den Content Library Explorer und einige seiner Funktionen etwas näher eingehen.

Vor kurzem wurde ich wieder einmal von einem Kunden darauf angesprochen, dass bereits distribuierte Pakete nicht automatisch von Depots gelöscht werden, wenn man die Distributionziele am Paket bereinigt. Somit stellt sich vielen Kunden aber auch die Frage, wie man seine Depots demnach am besten aufräumen kann, da sich über die Jahre natürlich viele Daten ansammeln, die eigentlich nicht mehr gebraucht werden bzw. schon gar nicht mehr am ein oder anderen Depot liegen sollten.

Da diese Aussage jedoch seit DSM 2014.1 nur noch teilweise korrekt ist und man mithilfe einer neuen Infrastruktur Einstellung dieses Verhalten ändern kann, möchte ich in diesem Artikel kurz zeigen, wie man seine Pakete anhand der Job Definition automatisch bereinigen lassen kann.

Auf Grundlage des Blogs Das Konzept der Fileablage in SCCM (SCCMContentLib) meines Kollegen wollen wir uns einmal mit dem Aufbau der Verzeichnisstrukturen der beiden Softwareverteillösungen Ivanti DSM und Microsoft SCCM befassen.

Der erste Schritt ist, dass wir die beiden Strukturen gegenüberstellen:

Innerhalb von Ivanti DSM gibt es zwei Verzeichnisse unterhalb der eigentlichen Freigabe auf dem Master-Depot-Server.

Für SCCM Neulinge mag die Art und Weise der Dateiablage in SCCM zunächst etwas unübersichtlich/undurchsichtig erscheinen, was wohl an dem mit System Center 2012 Configuration Manager eingeführtem Konzept der "Content Library" liegt.

Der Grundgedanke ist die effektive Speicherung von Daten auf dem Fileshare nach dem Prinzip des "Single Instance Storage". Hierbei werden Dateien die von mehreren Software Paketen benötigt werden, wie z.B. eine bestimmte DLL oder EXE, jeweils nur einmal gespeichert und lediglich eine Mapping-Referenz zwischen einer bereits existierenden Datei und dem neuen Software Paket hinzugefügt. Somit wird nicht nur der Traffic zwischen den Distribution Points reduziert um ein neues Paket bereit zu stellen, sondern auch die Zeit für die Bereitstellung reduziert.

Da es, wie in meinem Einleitungssatz bereits erwähnt, jedoch nicht immer ganz einfach ist hier die Übersicht zu behalten, möchte ich mit diesem Artikel etwas Licht ins Dunkel bringen.

Grundsätzlich ist die Aussage von FrontRange, dass sowohl die Distribution als auch die Softwareverteilung zum Client über http implementiert ist.

Diese Aussage stimmt zwar grundsätzlich, allerdings gibt es einige Stolpersteine, die einem die Einrichtung eines Depots in diesem Szenario zum persönlichen Jakobs-Weg machen. Daher nun folgend eine kleine Schritt-für-Schritt Anleitung als Abkürzung.

Hinweis: dieser Artikel setzt tiefgehende Kenntnisse über die DSM Infrastruktur, die Distribution, IP und DNS voraus. Sollten Sie unsicher in einem dieser Bereiche sein, nutzen Sie bitte die Unterstützung eines Consultants. 

Zielsetzung

Grundsätzliches Ziel dieses Artikels ist der Aufbau eines Depots in einer Außenstelle, das per Pull-Distribution über einen http-Port mit einem zentralen Depot abgeglichen wird. SMB ist dabei zwischen den beiden Lokationen nicht verfügbar.

Möchte man eine Testumgebung „für den persönlichen“ Gebrauch aufsetzen, in der keine „Vorab-Tests“ von Patchen durchgeführt werden und keine Pilotuser/Computer versorgt werden, kann der folgende Trick genutzt werden, um sowohl Speicherplatz zu sparen, als auch die Distribution deutlich zu optimieren.