Mit DSM 2016.2 wurde das Konzept des "User Centric Managements" in DSM vorgestellt. Dabei geht es unter anderem darum, dass Benutzer sogenannte "assoziierte Computer" haben können (und umgekehrt haben Computer natürlich auch assoziierte Benutzer). Bei der Zuweisung von Software-Paketen auf Benutzer oder Benutzergruppen kann dann festgelegt werden, dass die Pakete nicht mehr auf allen Maschinen, auf denen sich diese Benutzer anmelden, installiert werden, sondern nur noch auf den assoziierten Geräten. Damit wird der Wildwuchs und die unkontrollierte Installation von eventuell lizenzpflichtiger Software auf einer unbekannten Anzahl von Systemen unterbunden.

Die Frage ist aber nun, wie Computer- und Benutzer-Objekte in DSM assoziiert werden können und wie diese Assoziationen bei Bedarf automatisiert und über PSX-basierte PowerShell-Scripts gepflegt werden können.

Bereits seit Ende Januar 2017 ist die neue Version 4.0 unserer PowerShell Extensions for HEAT Client Management verfügbar - leider komme ich erst jetzt dazu, einen Blog-Artikel darüber zu schreiben, der die Neuerungen und Verbesserungen gegenüber der Vorgängerversion verdeutlicht. Neben 40 komplett neuen Cmdlets wurden sowohl zusätzliche Parameter für bereits bestehende Cmdlets, zusätzliche Methoden für Objekte und Performance-Verbesserungen implementiert. Außerdem wurden einige (wenige) interne Fehler behoben.

Dieser Blog-Artikel listet die Veränderungen im Detail.

Vor knapp einer Woche, am 16.12.2015, wurde die neue Version 5.0 des Windows Management Frameworks offiziell freigegeben, das ja als zentrale Komponente die Windows PowerShell 5.0 enthält. Dadurch sind jetzt auch die aktuellen in Windows 10 vorhandenen Funktionen wie das PackageManagement, PowerShellGet, PowerShell Klassen und anderes mehr für ältere Betriebssystem-Versionen verfügbar und unterstützt. Die Ankündigung ist im Windows PowerShell Blog unter http://blogs.msdn.com/b/powershell/archive/2015/12/16/windows-management-framework-wmf-5-0-rtm-is-now-available.aspx nachzulesen, die Downloads sind unter https://www.microsoft.com/en-us/download/details.aspx?id=50395 erreichbar.

Allerdings führt ein Bug im Installer dazu, dass nach der Installation das Laden des Moduls unserer PowerShell Extensions for HEAT Client Management (PSX) fehlschlägt. Aber nicht nur die PSX sind betroffen, sondern alle Module, die nicht in den Standard-Modulverzeichnissen installiert sind.

Der Versuch das PSX Modul oder jedes andere PowerShell Modul, das nicht in den Standardpfaden gefunden wird, zu laden führt zu der folgenden Fehlermeldung:

Wir freuen uns sehr mit diesem Blog-Artikel mitteilen zu können, dass ab sofort die aktuelle Version 3.1 unserer PowerShell Extensions (PSX) verfügbar ist.

Da sich ja sowohl der Firmenname des DSM-Herstellers (von "FrontRange Solutions" zu "HEAT Software") als auch der Produktname selbst (von "DSM" zu "HEAT Client Management") geändert haben, heißt unser Produkt nun offiziell "PowerShell Extensions for HEAT Client Management".

Die zentralen neuen Features sind:

• Herstellung der vollständigen Kompatibilität zu HEAT Client Management 2015.1
• Unterstützung neuer Features von HEAT Client Management 2015.1 (beispielsweise Ausführung einzelner Policy-Instanzen)
• Technische Verbesserungen und Weiterentwicklungen auf Basis von Anregungen durch Partner und Kunden

Die PowerShell Extension 3.1 unterstützen die DSM-Versionen 2013.2 bis einschließlich 2015.1, sind also zu den vergangenen zwei Major-Releases abwärtskompatibel.

Im Folgenden die Neuerungen im Detail...

Wer viel mit ODS Variablen arbeitet wird sicherlich schon einmal an dem Punkt angekommen sein an dem man sich die Frage stellt wo eine bestimmte Variable überhaupt überall gesetzt wurde. Leider ist dieser Verwendungsort über die DSMC nicht wirklich ersichtlich.

In folgendem Beitrag möchte ich einen Codeschnippsel erläutern, mit dem Sie die Zuweisungen der ODS Variable auslesen können.

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.

Vor kurzem haben wir die neue Version 3.0 der PowerShell Extensions für FrontRange DSM (PSX) freigegeben. Neben vielen internen Verbesserungen, wurden auch wieder eine ganze Reihe neuer Cmdlets aufgenommen, um die Verwaltung von DSM noch besser über die PSX steuern zu können.

Neben Cmdlets zur Erstellung, zum Abrufen und zum Löschen von Citrix-Objekten im DSM Organisationsverzeichnis, wurden insbesondere die mit DSM 2014.1 eingeführten neuen Möglichkeiten des Advanced Patch Managements (APM) adressiert und entsprechende Cmdlets implementiert.

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?