NWC Services Blog
Blogs von Consultants der NWC Services GmbH
Seit der Version 2107 bietet der Microsoft Endpoint Configuration Manager die Möglichkeit, Cloud Management Gateways die über den "Classic" Cloud Service erstellt wurden, in eine VM Skalierungsgruppe zu migrieren. Mit der Version 2203 wurde dann der offizielle Support für die Bereitstellung via classic service entfernt. Da viele Kunden nach wie vor jedoch mit älteren CMGs arbeiten und die Migration nur unter bestimmten Voraussetzungen möglich ist, möchte ich heute auf die Frage eingehen wie man ein bestehendes CMG am besten migrieren kann und was die Migration für bestehende Clients bedeutet, die aktuell nur über das Internet mit der MEMCM Umgebung kommunizieren.
Seit Version 2.0 erlaubt die Packaging PowerBench, Pakete direkt aus dem PPB-GUI heraus in SCCM zu registrieren. Damit entfällt die Notwendigkeit, nach der Erstellung eines Pakets, dies manuell in SCCM als Application anzulegen und sämtliche Eigenschaften manuell zu konfigurieren. Wenn Sie Ihre SCCM-Installation aber auf Version 2103 aktualisieren, erhalten Sie beim Verbindungstest auf die SCCM-Infrastruktur einen Fehler.
Dieser Blog-Artikel beschreibt die Ursache und den verfügbaren Workaround.
Durch die immer stärker werdende Bereitschaft von Unternehmen, die Home-Office Möglichkeiten für ihre Mitarbeiter auszubauen, wird gerade auch im Bereich der Softwareverteilung die Anbindung bzw. die Erweiterung der lokalen Umgebung mit Cloud-basierten Diensten immer wichtiger. Um im Bereich Microsoft Endpoint Manager die Configuration Manager Clients über das Internet zu verwalten, bietet Microsoft mit dem Cloud Management Gateway eine entsprechend einfache aber sehr leistungsstarke Lösung.
Da ich bereits in mehreren Kundenprojekten gefragt wurde wie man nun über die MEMCM Konsole am besten herausfinden kann welcher Client gerade über das CMG mit der Umgebung kommuniziert und da diese Information etwas versteckt zu finden ist, möchte ich in diesem Artikel kurz zwei Möglichkeiten aufzeigen wie diese Anforderung realisiert werden kann.
Eines der mit Sicherheit spannendsten Features in SCCM 1906 ist das "Install Application" Feature mit dem der Administrator in der Lage ist, Software adhoc auf einem Gerät zu installieren. In diesem Beitrag möchte ich das neue Feature kurz etwas genauer beleuchten und starte zunächst mit den Voraussetzungen.
Die erste Voraussetzung ist sicherlich eine aktualisierte SCCM Umgebung mit Version 1906. Allerdings gibt es noch weitere Bedingungen die erfüllt sein müssen, bevor eine Applikation auf ein Gerät gepusht werden kann.
Um den Grad der Dynamisierung einer Installation zu erhöhen bieten sich in SCCM bekanntlich mehrere Stellen an, an denen Variablen gesetzt werden können. Hierbei gilt jedoch die Reihenfolge der Abarbeitung zu beachten, sofern dieselbe Variable an unterschiedlichen Stellen verwendet wird. Grundsätzlich werden zuerst Sammlungsvariablen ausgewertet, danach Gerätespezifische Variablen die die Sammlungsvariablen im Ernstfall überschreiben und danach Task Sequenz Variablen die den Wert der Gerätespezifischen Variablen wiederrum überschreiben würden. Hinzu kommt die Tatsache, dass diese Variablen immer nur zur Laufzeit einer Task Sequenz verwendet werden können und danach nicht mehr zur Verfügung stehen.
In manchen Fällen, wie z.B. bei einer Neuinstallation eines Computers, kann es jedoch durchaus hilfreich sein sich alle während der OS Installationsphase verfügbaren Task Sequenz Variablen anzeigen oder im Bedarfsfall sogar weg schreiben zu lassen um diese auch nach der Ausführung der Task Sequenz, wenn auch nur mit den zur Laufzeit aktuellen Werten, zur Verfügung zu haben.
In diesem Artikel möchte ich kurz darauf eingehen wie man sich während einer Neuinstallation im PE alle Task Sequenz Variablen anzeigen lassen und diese z.B. in Form einer Log Datei oder in der Registry speichern kann.
Einleitung
Mittlerweile unterstützen alle namhaften Hersteller für Software-Paketierungswerkzeuge das neue Microsoft Paketformat MSIX. Microsoft selbst liefert ein Gratiswerkzeug, um bestehende Win32 Applikationen in das neue Paketformat zu konvertieren, genauer zu repaketieren. Folgende technische Voraussetzungen werden für das Werkzeug genannt:
- Windows 10 (mindestens Version 1809)
- Ein gültiges Microsoft Konto, um das Tool aus dem Windows Store zu beziehen
- Administrator-Berechtigungen auf dem zu installierenden System
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.
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.