NWC Services Blog
Blogs von Consultants der NWC Services GmbH
Am heutigen 12.05.2022 wurde die neue Version 3.1 unserer NWC Packaging PowerBench veröffentlicht. Es handelt sich um einen Minor-Release, sodass sich die Änderungen gegenüber der Vorversion in Grenzen halten. Wir sind uns dennoch sicher, dass die Neuerungen bei Kunden und Interessenten gut ankommen und nützliche Anwendungsfälle adressieren. Dieser Blog-Artikel stellt die neuen Features vor.
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.
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.
Am gestrigen Dienstag, dem 15.12.2020, wurde die neue DSM-Version 2020.2 freigegeben. Neue Features wie Unterstützung für die Verteilung von MSIX-Paketen, PowerShell 7 Support, die Integration von Xtraction Reporting und weitere kleinere neue Optionen sowie natürlich die Behebung bekannter Probleme, lassen eine vielversprechende Version erwarten. Details finden Sie wie üblich in den offiziellen Release Notes, die Sie hier nachlesen können.
Allerdings möchte ich Sie mit diesem Blog-Artikel auf ein Problem aufmerksam machen, das sowohl in DSM 2020.1 als auch noch in der neuen Version 2020.2 besteht und das eventuell schwerwiegend genug ist, dass Sie aktuell von einem Update auf DSM 2020.x absehen sollten.
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.
Bei der Paketierung in DSM gibt es ja verschiedene Möglichkeiten, dafür zu sorgen, dass Pakete nur unter bestimmten Bedingungen und Voraussetzungen auf den gemanagten Clients installiert werden. Zu nennen wären hier (ohne Anspruch auf Vollständigkeit):
- unterstützte Plattformen
- serverseitige Voraussetzungen
- clientseitige Voraussetzungen
- Bedingungen für vorhandene Installationen
Die Bedingungen für unterstützte Plattformen sollten klar sein: es werden nur für die Policy-Ziele auch Policy-Instanzen erzeugt, die eine der von dem Paket unterstützten Plattformen verwenden. Ebenso verhält es sich mit serverseitigen Voraussetzungen, auch hier wird eine Policy-Instanz nur dann erzeugt, wenn der Business Logic Server erkennt, dass die angegebenen Voraussetzungen von einem Policy-Ziel erfüllt sind.
Anders verhält es sich jedoch bei clientseitigen Voraussetzungen: für die Policy-Ziele werden auf jeden Fall Policy-Instanzen erzeugt (sofern die Plattform-Einstellungen und serverseitigen Voraussetzungen dem nicht widersprechen). Da DSM aber nicht alle erdenklichen Zustände über die verwalteten Clients in seiner Datenbank speichern kann, werden solche clientseitigen Voraussetzungen erst zur Laufzeit auf den Endgeräten geprüft und dann entschieden, ob die Installation ausgeführt wird oder nicht.
Ein naheliegender Anwendungsfall für die Verwendung von clientseitigen Voraussetzungen ist daher beispielsweise die Prüfung, ob genug freier Speicherplatz für die Installation eines Pakets zur Verfügung steht oder ob die Installation durch die Existenz eines Flags in der Registry oder im Dateisystem erlaubt ist. Bei diesem Vorgehen lauert jedoch "eine böse Falle"...
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.
Seit DSM-Version 2015.1 ist es ja möglich, das System ohne clientseitige Konten zu betreiben – der Service-Installer kann im Kontext des LocalSystem-Accounts ausgeführt werden und auch der Zugriff auf das Depot für das Staging der Pakete kann in Active Directory Umgebungen mit dem Computerkonto erfolgen. Somit sind in der Konfigurationsdatenbank nur noch die Credentials von Management Point Konten gespeichert, die aber durch die asynchrone Verschlüsselung wirksam geschützt sind.
Trotzdem ist es immer wieder erforderlich, Setup-Programme oder andere Aktionen im Rahmen von DSM-Scripts in einem definierten Benutzerkontext auszuführen, um Zugriff auf Netzwerkressourcen wie Back-End Systeme, Datenbanken, Fileserver oder ähnliches zu haben. Hierfür wird in aller Regel innerhalb der eScripts der Befehl RunAsEx verwendet und dort der Benutzername und das zugehörige Kennwort angegeben.
Dieser Ansatz bringt jedoch unter mehreren Gesichtspunkten Nachteile mit sich...
Es besteht meiner Erfahrung nach große Unsicherheit, wie man Windows bei Verwendung von Advanced Patch Management (APM) oder PatchLink (PL) konfigurieren soll, damit es nicht auf die Idee kommt, auf den Microsoft Servern selbständig nach Updates zu suchen, diese herunterzuladen und – insbesondere unter Windows 10 – zu einem völlig willkürlichen Zeitpunkt zu installieren.
Die empfohlenen Einstellungen waren auch schon das ein oder andere mal Thema im DSM Forum, beispielsweise in diesem oder diesem Thread.
Während man bei Windows 7 und Windows 8.1 noch einfach über Gruppenrichtlinien den ungewollten Zugriff auf die Microsoft Upate Server unterbinden kann, stellt sich die Sache bei Windows 10 – auch für Clients, die für die Verwendung eines internen WSUS-Servers konfiguriert sind – etwas anders dar...