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...

Wir alle, die wir mit DSM arbeiten, sind sicherlich regelmäßige "Leser" der DSM Logfiles, von denen es ja jede Menge gibt. Die Schwierigkeit für Anfänger (und durchaus auch manchmal noch für Fortgeschrittene) beim Ergünden einer Problemursache besteht meistens nicht darin, das Problem im Logfile zu finden, sondern das richtige Logfile zu identifizieren, indem das (vermutete) Fehlverhalten protokolliert ist.

Obwohl ich doch jetzt schon ein paar Jahre DSM-Erfahrung auf dem Buckel habe, hat mir ein Kunde letztens ein paar Fragen zu Logfiles gestellt, die ich so aus dem Stehgreif auch nicht beantworten konnte. Der Support hat mir super-schnell und kompetent auf die Fragen geantwortet, aber da ich denke, dass diese Infos vielleicht auch bei anderen DSM-Anwendern nicht so bekannt sind, dachte ich, ich schreibe einen mehr oder weniger kurzen Blog-Artikel dazu.

Die Fragen des Kunden waren:

• Wann werden eigentlich alte Logfiles gelöscht und werden immer die ältesten gelöscht (hier hatte ich noch Infos aus NetInstall 5.x Zeiten, war mir aber nicht sicher, ob diese Mechanismen heute noch gültig sind)?
• Wieviele Logfiles werden eigentlich vorgehalten und lässt sich die Anzahl konfigurieren?
• Manche Logs werden ja in einem ZIP-Unterverzeichnis archiviert. Kann man das beeinflussen oder konfigurieren?

Wenn man in der DSM-Welt unterwegs ist – und ich nehme stark an, dass praktisch alle Leser dieses Blogs irgendwelche Berührungspunkte mit DSM haben – kommt man hin und wieder bestimmt in die Situation, dass man neue Hardware in die Umgebung einbinden muss. Das heißt, es müssen Treiber für das jeweilige Ziel-Betriebssystem paketiert werden, insbesondere für die Hardware-Komponten, für die Windows keine Treiber an Bord hat. Manchen Kunden möchten sogar, dass alle vom Hardware-Hersteller gelieferten Treiber paketiert und in DSM eingebunden werden.

Es gibt nun mehrere Möglichkeiten, wie man hier vorgehen kann. Und insbesondere seit Windows 8.1 und für die bevorstehenden Windows 10 Rollouts gibt es nun noch die Option, hier mit PowerShell aktiv zu werden, was mich im Endeffekt veranlasst hat, diesen Blog-Artikel zu schreiben...

Wie bei jedem neuen Release, wird auch die DSM 2015.1 Version wieder eine Reihe sehr nützlicher neuer oder geänderter Features beinhalten. Zum Zeitpunkt der Erstellung dieses Artikels ist die Beta-Version aktuell, trotzdem möchte ich Ihnen bereits jetzt ein neues, sehr praktischen Feature vorstellen.

In der Vergangenheit war in DSM das Thema "Wartungszeitfenster" relativ kompliziert gelöst. Es gab verschiedene Zeitpläne, die für unterschiedliche System-Typen galten – namentlich Pläne für Arbeitsstationen, für Server, für Terminal-Server und für Citrix-Server. Diese Wartungspläne wurden über Konfigurations-Policies zugewiesen. Je nachdem von welchem Typ ein System war, wurde eine entsprechende Policy-Instanz erzeugt (sodass der Wartungsplan "zog") oder auch nicht. Insbesondere bei der Installation von Citrix-Servern wurden bis zu drei verschiedene Konfigurations-Policies benötigt, um eine vollständige Installation umzusetzen.

Außerdem war es durchaus möglich, dass über verschiedene Container verschiedene Wartungspläne zugewiesen wurden, sodass der effektive Wartungsplan schwierig zu bestimmen war oder es zu Problemen bei der Ausführung von Paketen kam.

Schließlich war eine sehr häufig geäußerte Anforderung von Kunden, dass es möglich sein sollte, Patches in einem anderen Wartungsfenster auszuführen als "normale" Software-Pakete – eine Anforderung, die bis dato nicht oder nur sehr eingeschränkt umsetzbar war.

Mit DSM 2015.1 werden hier Neuerungen eingeführt, die das Handling und die Flexibilität von Wartungsplänen und Wartungszeitfenstern deutlich erhöhen...

Bei einem Import eines PnP-Paketes in eine DSM 2014.1 Umgebung kann es zu einem Import-Fehler kommen.

Sie haben ein PnP-Paket welches aus einer älteren DSM / enteo V6 Umgebung exportiert wurde. In diesem PnP-Paket sind in der PnP-ID-Liste mehr als ein Gerät aufgelistet.

Eine der – weitgehend undokumentierten – Neuerungen in DSM 2013.2, ist die Möglichkeit im Rahmen des CSV-Imports von Objekten, diese gleich zu Mitgliedern statischer Gruppen im ODS zu machen.

Sinn und Zweck dieser Möglichkeit ist naheliegenderweise, dass ohne weitere manuelle Aktionen über die Mitgliedschaft in Softwarezuweisungs-Gruppen neuen Objekten (vermutlich in aller Regel Computer-Objekten) bestimmte Software-Pakete oder sogar ganze Sets an Standard-Paketen zugewiesen werden sollen. Damit lässt sich dann eine weitgehende Automatisierung von Rollouts oder Betriebssystem-Migrationen realisieren, wenn im Rahmen von Hardware-Tausch Szenarien, die Daten vom Lieferanten vorab bereitgestellt werden können.

Die Information beziehungsweise eine Dokumentation, welche Syntax das Import-File allerdings haben muss, um Objekte zu Mitgliedern statischer Gruppen zu machen, ist allerdings schwer zu finden...

Rund um das Thema "Umzug des ORG-Master Depots" gibt es jede Menge Unsicherheit, Gerüchte und fast schon moderne Märchen. Ganz früher (zu NetInstall 5.0-Zeiten) war dafür zwingend der sogenannte RAW-Modus erforderlich, der aber weder supported noch offiziell dokumentiert war.

Um ein supportbares Szenario zu schaffen, wurde mit der Version NetInstall 5.54 der Schalter "/AllowSrvMove" geschaffen, mit dem der NetInstall-Manager gestartet werden musste. In solch einer Sitzung konnte dann der ORG-Master durch Auswahl des Kontextmenü-Befehls "Umbenennen" oder durch Drücken von F2 umbenannt werden.

Wie mein Kollege David König in einem – mittlerweile veralteten und daher von ihm offline-genommenen – Artikel beschrieben hatte, gab es auch vor einiger Zeit mal eine DSM-Version, wo die alleinige Verwendung des "/AllowSrvMove"-Parameters nicht (mehr) ausreichend war. Beim Versuch eine so modifizierte NCP-Datei abzuspeichern kam es zu einer Fehlermeldung und so musste damals eine Kombination aus RAW-Mode und Schalter verwenden werden.

Mittlerweile (zum Zeitpunkt der Erstellung dieses Artikels ist die DSM-Version 7.2.1.2123 aktuell) wurden  diesbezüglich erneut Änderungen vorgenommen...