Zum 23.08.2023 ist die NWC Services GmbH zur CANCOM GmbH geworden. Besuchen Sie uns gerne auf www.cancom.de
Toggle Bar

BLOG

BLOGGING CONSULTANTS

NWC Services Blog

Blogs von Consultants der NWC Services GmbH

PSX oder selbst entwickeltes Programm

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?       

Erstellung eines Programms:

Zur Entwicklung eines solchen Programmes benötigt man Kenntnisse in C# oder VB .NET. Neben einer guten Entwicklungsumgebung wird noch das FrontRange SOAP SDK benötigt.

Mit Visual Studio Express erhält man eine gute Entwicklungsumgebung kostenlos, für das SOAP SDK muß man bei FrontRange einen SOAP Workshop besuchen. Dieser Workshop ist notwendig, um den Aufbau der Schnittstelle mit dem Aufbau der Objekte und den Methoden zu verstehen. Insgesamt handelt es sich um einen generischen Aufbau der Objekte. So gibt es keine "CreateComputer" Methode, sondern nur eine "CreateObjekt" Methode. Über Objekteigenschaften wird definiert um was für ein Objekt es sich handelt.

Idealerweise erstellt man sich für die generischen LowLevel Funktionen eine Bibliothek, die dann z.B. "CreateComputer" Methode bereitstellt. Möchte der Kunde diese selbst erstellen, muss der Administrator auch Entwickler sein und Dinge wie z.B. Klassendesign verstehen. Oft werden dazu Entwickler abgestellt, die über keine DSM Kenntnisse verfügen aber eben programmieren können. Dieses führt dann zu anderen Problemen.

Bei Änderungen an der Schnittstelle durch Hotfixes / Patche oder Updates müssen die Methodenaufrufe überprüft und ggf. angepasst werden.

Arbeiten mit den PSX:

Mit der PowerShell hat Microsoft ein mächtiges Werkzeug zum Skripten und zur Automatisierung geschaffen. Microsoft hatte erkannt, dass gerade im Enterpriseumfeld ein GUI zur Bewältigung von immer wiederkehrenden Aufgaben oder Massenaufgaben nur bedingt geeignet ist. Von den Administratoren wurde die PowerShell sofort akzeptiert und über die Zeit hat sich eine rege Community gebildet. Große Unternehmen wie VMware, Citrix, SAP und andere bieten die Verwaltung ihrer Produkte mittels PowerShell an. Folgen die Hersteller der PowerShell Module den Microsoft Richtlinien, ist es für die Anwender der Module leicht diese zu nutzen, da einmal erlernte Konzepte sich sehr schnell auf diese PowerShell Module anwenden lassen.

Die PSX werden als PowerShell Modul in einer PowerShell Sitzung geladen. Im Anschluß daran stehen ca. 80 Cmdlets zur Verwaltung einer DSM Umgebung zur Verfügung. Sie stellen Verwaltungsaufgaben für die Bereiche

  • Organisationsverzeichnis
  • Global Software Library
  • Policies und Policyinstanzen sowie
  • virtuelle Umgebungen und 
  • Mobile Devices

zur Verfügung.

Ungefähr 190 spezielle PowerShell Objekte, die DSM Objekten entsprechen, stehen für die weitergehende Bearbeitung zur Verfügung. Anstatt C# oder VB .NET Programmcode zu erzeugen, nutzt der Administrator diese Cmdlets, die im Übrigen den Richtlinien von Microsoft so weit wie möglich folgen.

Beispielhaft sei hier der PowerShell-Code für das Erzeugen eines Computerobjektes und danach diesen Computer auf eine Neuinstallation zu setzen:

New-EmdbComputer "PC001" (mit diesem Cmdlet wird ein Computerobjekt mit dem Namen "PC001" im aktuellen Kontext angelegt) und mit  

Reinstall-EmdbComputer "PC001" -StartImmediately -RecalculateInstallationOrder (Computer neu installieren mit der Neuberechnung der Installationsreihenfolge)

Nahezu alle Aufgaben die mit der DSMC ausgeführt werden können, lassen sich auch mit den PSX durchführen. Ausnahmen sind Funktionen, die die DSMC direkt ausführt ohne die SOAP Schnittstelle zu nutzen. Beispielsweise handelt es sich hierbei um das Erzeugen neuer Revisionen eines Software-Pakets oder um die Distribution eines Software-Pakets vorzubereiten.

Fazit:

In meinen Projekten hat sich gezeigt, wie schnell sich Anforderungen zur Automatisierung und Integration einer DSM Umgebung mit den PSX umsetzen lassen. Aufgaben, für die ich früher Tage benötigt hatte weil erst die passende Bibliothek in C# und dann die Anwendung dazu erstellt werden musste, habe ich schon mit Hilfe der PSX in ca. zwei bis drei Stunden umgesetzt. Hinzu kommt, dass das erstellte PowerShell Script beim Kunden verbleibt und von diesem selbstständig weiter gepflegt werden kann, ohne dass der Administrator Entwickler sein muss. Bei erstellten Programmen mittels C# oder VB .NET bleibt meist der Sourcecode im Unternehmen des Consultants und Änderungswünsche seitens des Kunden sind dann in der Regel kostenpflichtig.  

Ein weiterer Vorteil der PSX ist die Kapselung von Änderungen an der SOAP Schnittstelle, da FrontRange durch den Einbau neuer Funktionalitäten diese manchmal ändern muss. Sehr oft ist es gelungen, diese Änderungen intern zu bearbeiten, so dass die erstellten PowerShell Skripte unverändert funktionierten. Bei einem erstellten Programm muss dazu das Programm und / oder die zugrundeliegende Bibliothek geändert und neu erstellt werden.

Für mich und viele Kunden sind die PSX ein unverzichtbares Werkzeug bei der Automatsierung und Integration von DSM Umgebungen und durch oben aufgeführten Vorteile konkurrenzlos zu selbst erstellten Programmen.

×
Stay Informed

When you subscribe to the blog, we will send you an e-mail when there are new updates on the site so you wouldn't miss them.

Citrix License Server Adminpasswort wiederherstell...
Enterprise Deployment von Internet Explorer 11

Ähnliche Beiträge

 

Kommentare

Derzeit gibt es keine Kommentare. Schreibe den ersten Kommentar!
Bereits registriert? Hier einloggen
Donnerstag, 03. Oktober 2024

Sicherheitscode (Captcha)