NWC Services Blog

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.

Kürzlich kam einer unserer Kunden auf mich zu mit dem Anliegen, dass er die bestehende ODS-Struktur seiner DSM-Produktionsumgebung auf eine Testumgebung übertragen möchte. Grundsätzlich ist es ja eine gute Idee, Test- und Produktionsumgebung möglichst identisch oder zumindest nahezu identisch zu halten und somit besteht die Notwendigkeit, diese Anforderung mit möglichst geringem Aufwand umzusetzen. Ein manuelle "Synchronisation" schied daher von vorneherein aus.

Die Vorstellung des Kunden war, sowohl die Domain- und OU-Struktur, sowie die statischen und dynamischen Gruppen zu übertragen. Als Kunde der PowerShell Extensions lag natürlich nahe, diese Aufgabe mittels eines PSX-basierten Scripts zu erledigen. Insbesondere bei der Übertragung der hierarchisch organisierten dynamischen Gruppen tat sich der Kunde jedoch schwer, und kam mit der Bitte um den ein oder anderen Tipp auf mich zu.

Da es sich um eine interessante und durchaus auch für andere Kunden relevante Aufgabenstellung handelt, möchte ich in diesem Artikel einen möglichen Ansatz bzw. eine einfach gehaltene Lösung zur Umsetzung dieser Anforderung vorstellen.

Heute mal ein kurzer Hinweis auf einen anderen Blog: Markus Bäker, Systemingenieur bei einem Karlsruher Systemhaus, beschäftigt sich in letzter Zeit intensiv mit Enteo v6 / DSM 7 und automatisiert in einem großen Projekt viele administrative Aufgaben mit unseren PowerShell Extensions.

Über seine Erfahrungen, Beispiele sowie Tipps & Tricks berichtet er auf seinem Blog unter http://www.mbaeker.de/tag/enteo/.

Im heutigen (recht kurzen) Blogeintrag soll es nun um das noch nicht beschriebene Cmdlet Get-NiInstParam gehen.

Mit diesem Cmdlet wird nicht – wie man anhand des Namens womöglich vermuten könnte (und wovon ich bei meinen ersten Tests auch ausgegangen bin) – der Wert eines für das entsprechende Paket definierten Installations-Parameters ermittelt...

In diesem Teil der Artikelserie über die PowerShell Scriptingmöglichkeiten in DSM 7 soll es nun um die konkrete Anwendung gehen.

Wie beim Scripting-Support für VBScript, JScript und Perl-Scripts, besteht auch für PowerShell-Scripts die Möglichkeit, lesend auf NetInstall-Variablen zuzugreifen oder die Werte von NetInstall-Variablen zu setzen. Dazu werden über das PowerShell-Modul Enteo.Powershell.ScriptCmdlet.dll, das Teil des DSM 7 Clients ist, folgende Cmdlets zur Verfügung gestellt:

• Get-NIVar
• Set-NIVar
• Write-NIReport
• Set-NIError
• Get-NiInstParam

Eine der wenig bekannten (und noch schlechter dokumentierten) Neuerungen in DSM 7, ist die Unterstützung von PowerShell innerhalb von DSM 7 Scripts.

Da sich PowerShell und die PowerShell-Scriptsprache ja mehr und mehr als die Automatisierungs-Schnittstelle im Windows-Umfeld herauskristallisieren, ist diese Unterstützung ein wichtiger Baustein im Gesamtkonzept einer LifeCycle-Management Strategie.

Dieser Artikel ist der erste einer kleinen Serie  von Posts, in der die neuen Möglichkeiten aufgezeigt werden sollen...