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.

Für viele meiner Kunden ist der tägliche Umgang mit den DSM Log Files eher ein lästiges Übel als eine Freude. Dies ist vor allem darauf zurück zu führen, dass es zum einen eine große Vielfalt an verschiedenen Log Files zu den diversesten Aktionen gibt, als auch auf die einzelnen Log Files die oft mit sehr vielen Informationen gespickt sind und einem die Suche nach der gewünschten Information oft nicht leicht machen.

In diesem Blog möchte ich kurz auf eine Möglichkeit eingehen, sich mithilfe einer seit DSM 2016.1 angebotenen Sprach-XML für das Freeware Tool Notepad ++, die Arbeit mit den Log Files zu erleichtern und möchte kurz zeigen, wie man diese XML für seine eigenen Bedürfnisse anpassen kann.

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

In diesem Artikel möchte ich ein etwas älteres Feature der DSM beschreiben (Bestandteil seit DSM 7.2.1), welches bei der Verwendung von Job-Scripts sehr hilfreich sein kann, jedoch relativ unbekannt ist. Das neu eingeführte Feature wurde zwar in den Release Notes erwähnt und ist auch in der Online-Hilfe dokumentiert, dennoch zeigt die Erfahrung, dass nur wenige DSM-Kunden Kenntnis über die Existenz oder Verwendung haben.

Es handelt sich um die Möglichkeit, in Job-Scripts auf die Werte von Variablen und Installationsparametern von Aufrufpaketen (Main Packages) zugreifen zu können.

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