NWC Services Blog
Blogs von Consultants der NWC Services GmbH
For an english version please scroll down... ;-)
Durch den Anruf eines alten Bekannten und weil dieses Thema offensichtlich genau den Nerv der heutigen Zeit trifft, möchte ich meine kleine Exkursion in die Welt der CSPs fortsetzen und noch ein bisschen tiefer gehen. Bei dem besagten Anruf bin ich gefragt worden, ob es nicht eine Möglichkeit gibt, CSPs auch ohne Intune und Configuration Profiles nutzen bzw. setzen zu können. Schließlich sind diese ja Bestandteil von Windows 10/11 und bieten durchaus auch Abseits von Intune ein gewisses Potential.
Also gilt zunächst zu klären ob diese wirklich nur auf Intune beschränkt sind, was mit einem eindeutigen "Nein" beantwortet werden kann. Wie bereits in meinem ersten CSP Artikel beschrieben, handelt es sich hierbei lediglich um eine Schnittstelle die auch von anderen MDM Plattformen wie z.B. MobileIron (welches seit Dezember 2020 zur Ivanti Familie gehört) genutzt werden kann.
In meinem heutigen Artikel möchte ich zeigen, wie das Ansprechen und Verwenden von CSPs via WMI und PowerShell lokal am Client betrieben werden kann.
Mit der Veröffentlichung von DSM 2022.1 wurde auch der neue Microsoft Intune Konnektor veröffentlicht. Dieser Konnektor, welcher mittels Azure App Registration über die Graph API mit Intune kommuniziert, ermöglicht unter anderem einen direkten Upload des DSM Agents zur Verteilung via Intune.
Prinzipiell bietet dieser Konnektor natürlich vor allem für hybride Client Management Ansätze ein sehr großes Potenzial. Da sich der Funktionsumfang der Seitens Ivanti zum aktuellen Zeitpunkt mitgeliefert wird jedoch noch in Grenzen hält, möchte ich heute zeigen wie Sie sich mit wenig Aufwand und DSM Bordmitteln auch jetzt bereits interessante Infos aus der Cloud in Ihre DSM Umgebung syncen können.
Aber was wäre denn interessant zu wissen? Ob es sich bei einem Client um ein AAD-Only oder ein Hybrid-Joined Gerät handelt? Oder vielleicht die Geräte-ID aus Intune? Kurz gesagt, eine Art "DSM Basis Inventarisierung" für Intune wäre doch toll.
In einem früheren Blog-Artikel habe ich beschrieben, dass die kommende Packaging PowerBench 2.0 ein Feature beinhalten wird, um Pakete in das von Microsoft Intune verwendete Format zu konvertieren beziehungsweise zu exportieren. In diesem Artikel möchte ich nun beschreiben, wie Sie ein exportiertes Paket in Ihrem Intune-Mandanten registrieren und damit zur Verteilung an Ihre über Intune verwalteten Geräte bereitstellen können.
Das Interesse an unserem im Sommer in Version 1.0 releasten Produkt „Packaging PowerBench" ist erfreulich hoch – die vielen Demo-Sessions, Eval-Anfragen und auch mehrere Neukunden in der letzten Zeit sind ein deutliches Zeichen dafür. Wir freuen uns sehr, dass unser Tool offensichtlich so gut ankommt und einen „Nerv" getroffen zu haben scheint, aber natürlich ruhen wir uns nicht auf unseren Lorbeeren aus und entwickeln sehr aktiv an einer neuen Version, die für das erste Quartal kommenden Jahres geplant ist.
Eines der neuen Features der Version 2.0 möchte ich in diesem Blog-Artikel kurz vorstellen.
Die meisten Leser dieses Blogs werden wahrscheinlich technisch orientierte User sein, die als Consultants, Administratoren, System Engineers oder Entwickler häufig „auf der Kommandozeile“ unterwegs sind. Die Verwendung der Eingabeaufforderung (cmd.exe) oder von Windows PowerShell gehört zu unserem Alltag und jeder kennt die Schwächen der Tools, die seit Jahrzehnten quasi identisch funktionieren und Verbesserungen und Weiterentwicklungen in maximal homöopathischen Dosen erfahren haben.
Mit der Neuentwicklung „Windows Terminal“, die auf GitHub als Open Source Software entwickelt wird, hat Microsoft einen neuen Anlauf gewagt, für die Windows-Welt ein zeitgemäßes Kommandozeilen-Interface zur Verfügung zu stellen.
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.
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.
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.
Auch in der kommenden Version 2017 wird es wieder etliche sinnvolle Neuerungen geben, die DSM noch flexibler und damit universeller einsetzbar machen. Dabei mausert sich das System mehr und mehr vom reinen Softwareverteilsystem zur zentralen Konsole, mit der typische administrative Aufgabenstellungen des täglichen Geschäfts erledigt werden können.
Eines dieser neuen Features möchte ich in diesem Artikel vorstellen, nämlich die Möglichkeit, benutzerdefinierte Aktionen lokal auf DSM-gemanageten Clients ausführen zu lassen. Der Phantasie sind bei den Anwendungsfällen kaum Grenzen gesetzt, beispielsweise lassen sich damit dezentral die Logfiles einsammeln oder es findet es eine Bereinigung des Festplattenspeichers statt oder ein Client wird bei Verdacht auf Virenbefall nach Schadsoftware gescannt oder oder oder...
Die Umsetzung des Anti-Malware Scans mit Windows Defender möchte ich in diesem Artikel beispielhaft beschreiben.
Mit DSM 2016.2 wurde das Konzept des "User Centric Managements" in DSM vorgestellt. Dabei geht es unter anderem darum, dass Benutzer sogenannte "assoziierte Computer" haben können (und umgekehrt haben Computer natürlich auch assoziierte Benutzer). Bei der Zuweisung von Software-Paketen auf Benutzer oder Benutzergruppen kann dann festgelegt werden, dass die Pakete nicht mehr auf allen Maschinen, auf denen sich diese Benutzer anmelden, installiert werden, sondern nur noch auf den assoziierten Geräten. Damit wird der Wildwuchs und die unkontrollierte Installation von eventuell lizenzpflichtiger Software auf einer unbekannten Anzahl von Systemen unterbunden.
Die Frage ist aber nun, wie Computer- und Benutzer-Objekte in DSM assoziiert werden können und wie diese Assoziationen bei Bedarf automatisiert und über PSX-basierte PowerShell-Scripts gepflegt werden können.