In größeren Umgebungen mit vielen Administratoren die diverse Aufgaben innerhalb der DSM delegiert bekommen sollen, empfiehlt es sich oft schon wegen der reinen Übersichtlichkeit die User nicht alle einzeln zu berechtigen, sondern mit Berechtigungsgruppen für die Tätigkeitsgebiete zu arbeiten.

Entscheidet man sich hier z.B. für die Verwendung von externen Gruppen aus dem Active Directory reicht es oft aus, das Berechtigungskonzept einmal zu implementieren und alles weitere nur noch über die Gruppenmitgliedschaften des Users im AD zu regeln. An dieser Stelle sollte man sich allerdings entweder gut merken wo man seine Gruppen berechtigt hat oder man denkt über den Kauf von PSX (Powershell Extensions) nach, denn die DSM bietet leider nach wie vor keine Möglichkeit diese Informationen anzeigen zu lassen.

Ich möchte heute kurz zeigen wie Sie mit Hilfe der PSX schnell und einfach herausfinden können wo ihre Gruppe berechtigt ist, ohne dass Sie sich mühevoll durch unzählige Objekte klicken müssen.

Ein Kunde von uns hatte die Anforderung, dass die Patches von Microsoft im späteren Workflow anders behandelt werden sollten als die Patches von Drittanbietern. Vereinfacht dargestellt sollten erstere auf eine Gruppe und die der Drittanbieter auf eine andere Computergruppe zugewiesen werden.

Der Patch Management Dienst ist so konfiguriert, dass alle Patches einer statischen Computergruppe namens "DownloadOnly" zugewiesen werden, die allerdings keine Computer enthält. Von da aus werden sie mittels Targetlistenerweiterung weiter an die Gruppen "Microsoft" bzw. "ThirdParty" verteilt.

Die Pilotgruppen sind hier ausser acht gelassen, es geht um die grundsätzliche Logik.

In den letzten Jahren habe ich sehr viele kundenspezifische Programme entwickelt, die über die SOAP Schnittstelle auf die DSM-Umgebung zugreifen. Es handelte sich dabei vielfach um Windows Dienste, die spezielle Aufgaben durchführten. Dazu zählten unter anderem:

• ein Abgleich der Computerkonten zwischen Active Directory, DSM und Discovery
• ein Patch Management Prozess, bei dem Policies nach einem Regelwerk verschoben / erweitert werden
• Policyinstanzen, die nicht compliant sind auf "Reinstallation" zu setzen und ggf. noch auf den Stand der Policy bringen 
• und viele verschiedene mehr.

Darüber hinaus habe ich auch reine Kommandozeilenprogramme entwickelt, die z.B. Computerobjekte anlegen, Gruppenmitgliedschaften und Policies verwalten sowie andere DSM Verwaltungsaufgaben durchführen. Bei allen Entwicklungen ging es entweder um die Integration der Aufgabe in bestehende / neue Prozesse oder um die Automatisierung von Standardaufgaben.

Alle Programme wurden in C# mit Visual Studio als Entwicklungsumgebung erstellt.

Seit gut einem Monat bin ich Senior Consultant im Team der NWC Services GmbH und habe die PowerShell Extensions für DSM 7 (PSX) (https://www.nwc-services.de/produkte/psx) kennen gelernt, die viele unserer Kunden einsetzen. Mittlerweile sind die PSX zum Standard geworden, wenn Anforderungen, wie sie oben genannt sind, umgesetzt werden sollen. Aber was sind die Gründe dafür?       

In jüngerer Vergangenheit sind wir von einigen Anwendern unserer PowerShell Extensions für FrontRange DSM (PSX) darauf aufmerksam gemacht worden, dass es beim Absetzen von PSX-Kommandos die fehlschlagen, zu einer kryptischen Fehlermeldung kommt, die nur besagt dass das es sich bei der Antwort um nicht-wohlgeformtes XML handeln würde.

Dies ist natürlich wenig aussagekräftig und hilft bei der Ergründung der Fehlerursache nicht weiter.

Im oben dargestellten Fall kann man vielleicht noch selbst darauf kommen, dass es schlicht nicht möglich ist, eine Software-Kategorie unterhalb von "Managed Users & Computers" zu erstellen – in aller Regel wird man jedoch auf die konkrete Fehlermeldung angewiesen sein, um die Ursache des Problems erkennen und beheben zu können.

Das beobachtete Verhalten tritt im Übrigen nur auf, wenn die Umgebung schon auf DSM 2013.2 (oder neuer) aktualisiert wurde.

Seit vergangenem Dezember ist die neue Version FrontRange HEAT DSM 2013.2 verfügbar und spätestens mit dem Release des ersten Hotfix-Bundles vor wenigen Tagen, stehen mehr und mehr Kunden vor der Umstellung auf die neue Version.

Wie mit jedem neuen Release, gab es auch diesmal etliche Änderungen am User-Interface, neue Möglichkeiten und neuen Infrastruktur-Optionen. Hinter den Kulissen wurde aber natürlich auch wieder viel geändert, unter anderem auch am Administration Webservice - der Schnittstelle, über die unsere PowerShell Extensions mit der DSM Infrastruktur kommunizieren. Das bedeutet, dass die Version 2.1 der PSX nicht vollständig kompatibel zum neuesten DSM-Release ist.

Wir freuen uns daher, Ihnen mitteilen zu können, dass seit heute der Kompatiblitäts-Release PSX 2.1.1 zur Verfügung steht, mit dem die vollständige Kompatibilität zur aktuellen Version wiederhergestellt wird.

Das Windows Preinstallation Environment in der Version 4.0, welches mit Einführung von Windows 8 bzw. Windows Server 2012 veröffentlicht wurde, bietet einige spannende Neuerungen in Bezug auf seinen Vorgänger. So ist es nun unter anderem möglich PowerShell 3 als optionale Komponente zu integrieren. Durch diesen Schritt ist es natürlich auch möglich per PSX Ihre DSM Umgebung bereits in der PreOS Phase anzusprechen, auszulesen und natürlich zu konfigurieren. In diesem Blog möchte ich Ihnen kurz zeigen wie Sie ihr Boot Environment zum einen PowerShell und zum anderen PSX Ready machen können.

Nachdem ich in letzter Zeit immer häufiger nach einer Möglichkeit gefragt wurde, ob man Software Policys einer bestehenden statischen oder dynamischen Gruppe auf einfachem Wege duplizieren, oder auch die Targetlist der bestehenden Policys erweitern kann, möchte ich kurz einen Weg aufzeigen mit welchem sich die gewünschte Aktion per PSX realisieren lässt.

Nach Zuweisung von Software und dem damit verbundenen Erzeugen neuer Policies, müssen Ihre Clients in der Regel bis zum nächsten Polling warten, damit die Änderungen angewendet werden.

Über die DSM 7 Konsole hat man jedoch – ähnlich der „Sofort-Installation“ unter NetInstall v5.x – die Möglichkeit, die Aktion „Änderungen ausführen“ durchzuführen und diese Wartezeit damit zu verkürzen. In diesem Blog-Artikel möchte ich Ihnen kurz zeigen, wie Sie diese Möglichkeit auch per PowerShell abbilden können.

Nach der kleinen Einführung und dem richtigen Connect zur DSM via PSX wollen wir uns als nächstes einige sehr oft genutzte Features der DSM ansehen und uns hierfür weitere kleine Codeschnipsel erstellen. So kommen wir zunächst zu einem der wohl am meisten genutzten Features. Dem "Computer neu installieren"-Dialog.

Wie schon angekündigt starten wir unsere "Schnipseljagd" relativ einfach damit, dass wir uns mit der EMDB verbinden und anschließend hierfür ein eigenes kleines PowerShell Profil erstellen, welches beim Starten der PowerShell sofort geladen wird. Dieser Schritt wird eine grundlegende Voraussetzung für alle weiteren Codeschnipsel werden, weshalb ich diesen nun etwas genauer beschreiben möchte.