Da die Verlinkung von AD Gruppen und Device Collections in SCCM relativ komplex ist, es jedoch über die Konsole standardmäßig keine andere Möglichkeit der Anlage gibt, möchte ich heute wie bereits in meinem letzten Post angekündigt zeigen, wie eine Device Collection mit AD Mitgliedschaftsregel auch schnell und einfach per PowerShell angelegt werden kann.

Hierfür möchte ich in diesem Beitrag lediglich die einzelnen Schritte, sowie alle benötigten Komponenten und PowerShell Cmdlets erklären. Aus diesen sehr statischen Befehlen kann man natürlich später jeden Grad von Automatisierung erreichen, bis hin zu grafischen Oberflächen bzw. einem kleinen Custom Wizard, der sich bei Bedarf sogar in das Kontextmenü der SCCM Konsole integrieren lässt.

Da ich mich in letzter Zeit wieder intensiv mit dem System Center Configuration Manager beschäftige, möchte ich in meinem heutigen Blog Post etwas genauer auf das Zusammenspiel von User/Device Collections und Security Gruppen im Active Directory eingehen und zeigen, wie diese miteinander verlinkt werden können. Die Idee hinter dieser Methode soll sein, die Applikationsverwaltung von optionaler oder individueller Software teilweise oder auch komplett über das AD steuern zu können und damit die Administration beider Systeme zu vereinfachen.

Für die DSM Administratoren unter meinen Lesern wäre diese Anforderung wohl am ehesten mit dem Import einer Externen Gruppe in DSM zu vergleichen, welche in dieser Form in SCCM nicht existiert. Weiterhin wurde dieses Szenario in DSM oft nicht direkt über Externe Gruppen abgebildet da die Berechung der Gruppenmitgliedschaften nicht wie in SCCM über den Server sondern bei jedem Sync direkt am Client stattfindet. Aufgrund der dadurch entstehenden Last am DSM BLS bzw. den langen Sync Vorgängen an den Clients haben sich einige der Kunden daher ein ähnliches Konstrukt über einen AD-DSM Konnektor geschaffen, um das AD wieder zum führenden System zu machen und Computerobjekte innerhalb DSM automatisiert in statische Gruppen aufnehmen/herausnehmen zu lassen. Da SCCM die Synchronisation mit dem AD anders abwickelt sind derartige Konstrukte hier nicht notwendig was die Komplexität erheblich reduziert und somit gerade für Umsteiger oder Interessierte neue Möglichkeiten schafft.

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.

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.

Seit geraumer Zeit besteht in DSM die Möglichkeit, eine ODS Variable vom Typ "Zeitplan" zu erstellen. Da diese Variable im eScript über die "If"-Anweisung "IsInTimeframe" geprüft werden kann, ergeben sich hieraus gerade für Installationen viele neue Möglichkeiten. Somit wäre es denkbar einen Softwarerollout in mehrere "dynamische Phasen" (führe Aktion 1 aus wenn innerhalb Wartungszeitfenster und Aktion 2 wenn nicht) zu unterteilen, ohne das der DSM Administrator weitere Änderungen am eScript oder der Policy vornehmen muss, wie es oft bei der Verteilung von Patchen oder z.B. auch einer schleichenden Windows 10 Migration gewünscht ist. Ein "Aufschieben" oder "Erweitern" des Zeitplanes greift bei Ausführung des eScripts sofort.

Möchte man nun im eScript den "Beginn" oder das "Ende" des Wartungszeitplans herausfinden, gibt es für den Builtin DSM Wartungszeitplan den eScript Befehl "GetMaintenanceTimes". Leider ist es über diesen Befehl aber zum jetzigen Zeitpunkt nicht möglich einen eigenen Wartungsplan auszulesen um die gewünschten Informationen zu erhalten. Weist man den Wartungsplan einer DSM Variablen zu und lässt sich den Inhalt ausgeben, erscheint die Interpretation dieses codierten Strings auf den ersten Blick relativ schwierig.

Hier ein Custom Wartungszeitplan und der Inhalt der ODS Variablen als String:

1;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA;AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgP///z8AAAAA

In diesem Artikel möchte ich zeigen, wie der angezeigte String per PowerShell interpretiert und die darin enthaltene Information in DSM weiterverarbeitet werden kann. Dies würde sich sowohl mit als auch ohne PSX realisieren lassen.

Wie mein Kollege Frank Scholer bereits in seinem letzten Artikel schrieb, kommen mit der nächsten DSM Version (2017) die ja voraussichtlich Ende November erscheinen wird, wieder einige sehr interessante und nützliche Features in das Produkt DSM. Auch ich möchte deshalb in unserer kleinen Rubrik "Sneak Peek" ein weiteres neues Feature etwas genauer vorstellen.

Hierbei handelt es sich um die "Erweiterte Site Definition", mit der es ab sofort möglich ist, mehrere Site-Definitionen innerhalb einer einzigen Site anzugeben und nacheinander abarbeiten zu lassen. Die einzelnen Kriterien einer Site-Definition werden mit der neuen "Def-ID" gekennzeichnet. Dabei können mehrere oder auch nur eine einzige Site-Definition zutreffen und die Sitezugehörigkeit eines Clients bewirken.

Wie dieses Feature in der Praxis umgesetzt werden kann, möchte ich im folgenden Artikel etwas näher ausführen.

Arbeitet man viel mit deaktivierten Policys / Policyinstanzen, hat man sich sicherlich schon des Öfteren gewünscht, dass diese ab und zu etwas deutlicher erkennbar wären. Generell werden Policyinstanzen von DSM in hellgrau dargestellt, was je nach Kontrast des Monitors oder mit zunehmender Feierabendmüdigkeit immer schwerer zu erkennen ist.

Da es seit DSM 2016.2 die Möglichkeit gibt deaktivierte Einträge bereits Out-Of-The-Box anzupassen, diese Funktion aber bei vielen Kunden nicht wirklich bekannt ist, möchte ich in diesem Artikel kurz zeigen, wie man die Anzeige hierfür anpassen kann.

Vor kurzem wurde ich gefragt, wie man am besten damit umgeht, einen DSM gemanagten Client zu reinstallieren, der jedoch sein Betriebssystem nicht über OSD, sondern über ein anderes System Deployment Tool wie z.B. WDS bekommt.

Problem hierbei ist, dass bei einer "Reinstallation" von Policyinstanzen der Ausführungsmodus "Reinstallation" und nicht wie gewünscht "Installation" gesetzt wird, was natürlich zu unerwünschten Effekten führen kann sofern auch innerhalb der Scripte die unterschiedlichen Ausführungsmodi geprüft und mit verschiedenen Aktionen belegt werden.

In manchen Fällen kann es durchaus von Vorteil sein, wenn man sich ohne großen Aufwand selbst einen kleinen "Installer" basteln kann. Gerade für kleinere Aufgaben im Bereich der Automatisierung und vielleicht auch wenn man nicht unbedingt auf Deployment Tools wie DSM und Co. zurück greifen kann, lassen sich somit z.B. eigene Scripte inkl. der benötigter Dateien schnell und einfach in einem Archiv zusammen fassen, welches sich bei Ausführung selbst entpackt und die beinhaltenden Aktionen automatisch ausführt.

Wie Sie sich ein solches, selbst-extrahierendes Archiv mit dem Freeware Tool 7-Zip erzeugen können, möchte ich Ihnen in diesem Artikel nun zeigen.