Archiv für den Monat: Mai 2015

Tipp: Verzeichnis eines Dienstes abfragen

Basiert ein Dienst auf einer Exe-Datei, gibt es ein Verzeichnis, in dem sich die Exe-Datei befindet. Per Get-Service erfährt man nicht, auf welchem Prozess ein Dienst basiert, aber per Get-CimInstance. Die Abfrage liefert die ID des Prozesses, mit der man per Get-Process den Pfad der Exe-Date erhält.

Der folgende Befehl gibt den Pfad aus, in dem sich die MySql-Dienstdatei Mysqld.exe befindet:

Zugegeben könnte man die Path-Eigenschaft auch etwas einfacher erhalten, aber mich hat der Umstand „geärgert“, dass Get-Process so unflexibel ist und erwartet, dass das Objekt in der Pipeline eine Id-Eigenschaft besitzen muss und keine ProcessId-Eigenschaft akzeptiert.

Etwas naheliegender ist natürlich die folgende Variante:

Tipp: Zufallskennwörter mit ForEach

Der folgende Tipp setzt PowerShell 4.0 voraus. Es geht wieder einmal um die praktische ForEach-Erweiterung.

Der folgende Befehl erzeugt eine Zeichenfolge von 6 zufälligen Buchstaben:

Netterweise sorgt Get-Random dafür, dass keine doppelten Buchstaben zurückgegeben werden.

Ja, und was mache ich, wenn das Kennwort auch Ziffern enthalten soll? Ganz einfach, Du übergibst Get-Random zwei Arrays mit Zahlen:

Einige Powershell-kundige Leser mögen den Zwang auf ForEach-Object zu verzichten als etwas übertrieben ansehen, ich finde diese Kurzschreibweise sehr praktisch, da man „gedanklich“ in einem Befehl bleibt.

Ein eigenes Modul-Repository mit PowerShell 5 und ProGet im Intranet einrichten

Mit der PowerShell 5.0 (lange wird es nicht mehr dauern;) wird der Umgang mit Modulen nicht nur vereinfacht, sondern endlich auch eine einheitliche Grundlage gestellt. Soll ein Modul lokal zur Verfügung stehen, wird es über ein Install-Module von einem Repository hinzugefügt. Microsoft betreibt mit der Powershell Gallery ein eigenes Repository, über das in erste Linie DSC Ressourcen der Allgemein zur Verfügung gestellt werden. Auch wenn mehr als 95% der dort angebotenen Module (vermutlich sogar alle) absolut seriös sind, dürfte es vielen Admins gewisse Bauchschmerzen bereiten wenn jeder ihrer Kollegen jedes x-beliebige Modul aus einem öffentlichen Portal herunterladen kann – liegt das Modul als Psm1-Skriptmodul vor, werden mit dem Laden des Moduls theoretisch beliebige Befehle ausgeführt. In der Regel mit vollen Administratorberechtigungen.

In der Praxis wird man sich daher im lokalen Intranet ein eigenes Repository einrichten. Wie das mit wenigen Schritten möglich ist, zeigt PowerShell MVP Richard Siddaway in einem Blogbeitrag sehr schön:

https://richardspowershellblog.wordpress.com/2015/01/04/creating-a-powershellget-repository/

Er verwendet dazu einen kommerziellen Dienst mit dem Namen ProGet, der auch eine kostenlose Express-Version im Angebot hat. Ich habe die Schritte umgesetzt und konnte nach kurzer Zeit Module in das Repository veröffentlichen und auf anderen Rechnern im Netzwerk importieren. Lediglich das Anlegen der Firewall-Regel (in dem Beispiel wird Port 81 verwendet) darf man nicht vergessen, z.B. per PowerShell

Ich werde die Schrittfolge in einigen Wochen ausführlicher beschreiben, wenngleich die Beschreibung in dem Blog-Eintrag von Mr. Siddaday eigentlich keine Fragen offenlassen und man damit sehr gut zum Ziel kommt. Für mich ist das die Zukunft wie im Unternehmen den Admins PowerShell-Funktionalität zur Verfügung gestellt werden kann. Der einzige Schritt, der lokal ausgeführt werden muss, ist das Registrieren des Repository, doch auch diese Einstellung lässt sich per DSC bequem verteilen.

PowerShell Usergroup Treffen in Ulm am 18.6.2015

Ich werde beim nächsten Treffen der PowerShell Usergroup Süddeutschland in der Nähe von Ulm einen Überblick zum Thema DSC geben, mit dem ich mich bereits seit einiger Zeit beschäftige, und in dem ich, wie andere natürlich auch, sehr viel Potential sehe.

Termin: 18/06/2015, ab 18 Uhr 30
Ort: Firma Horaios GmbH in Blaustein bei Ulm

Weitere Infos gibt es unter http://powershell-ug.com/

Ich freue mich, dass der Termin zustande gekommen ist und hoffe, dass möglichst viele PowerShell-User und -Interessierte im Süden die Gelegenheit zu einem Treffen nach Feierabend nutzen werden.

Tipp: Auflisten der installierten .NET Framework-Versionen

Der folgende Befehl gibt die Namen und Versionsnummern aller lokal installierten .NET Framework-Installationen aus:

Ich habe den Tipp auf der Webseite von Dr. Windows gefunden und gedacht, dass dies ein nützlicher Tipp ist, wenngleich der Befehl für jemanden, der von der PowerShell keine Ahnung hat und ihn eintippen soll, insgesamt etwas lang ist. Der Befehl selber ist nichts Besonderes, es hat lediglich eine Weile gedauert bis ich herausgefunden hatte, für was das „p{L}“ in dem Regex steht. Damit werden bestimmte Buchstabengruppen ausgeschlossen, in diesem Beispiel Ziffern, so dass alle Schlüsselnamen, die nur aus Ziffern bestehen, nicht ausgegeben werden. Cool.

Mehr Infos zur Wirkung von p für das Ausschließen von Zeichengruppen gibt es hier:
http://www.regular-expressions.info/unicode.html

PowerShell und DevOps – eine umfangreiche Artikelsammlung

Devops ist das neue „Buzzword“ in der IT, sozusagen der Nachfolger von TCO&Co. Dabei steckt ausnahmsweise kein Marketingslang dahinter. DevOps bedeutet, dass in der Software-Entwicklung in den letzten Jahren entstandene agile Methoden auch auf das Bereitstellen von (Web-) Anwendungen übertragen werden. Berücksichtigt man, dass die großen Webanwendungen (Twitter, Flickr usw.) täglich mehrere Male aktualisiert und damit eine aktuelle Version in einem Rechenzentrum bereitgestellt werden muss wird schnell klar, dass hier die klasssische Rollenaufteilung „Hier die Entwickler und dort die IT-Leute, die die Anwendung bereitstellen müssen“ nicht mehr funktioniert.

Ich will in diesem Blogeintrag aber nicht den Begriff „DevOps“ erklären, sondern auf eine beeindruckende Artikelsammlung hinweisen, in der die Autoren die Rolle der PowerShell als DevOps-Tools in allen Facetten beleuchten:

http://www.systemcentercentral.com/100DaysOfDevOps/

Wirklich beeindruckend.

PowerShell 4.0 unter Windows Server 2018 R2 installieren

Um PowerShell 4.0 unter Windows Server 2008 R2 installieren zu können müssen zwei Voraussetzungen erfüllt sein:

1) SP1
2) .NET Framework 4.5 (oder einer höhere Version, wie 4.52)

Ich bin großer Fan von Chocolatey, mit dem sich Anwendungen und Systemerweiterungen per Befehlszeile hinzufügen lassen. Die Installation von Chocolatey ist sehr einfach. Man ruft die Webseite www.chocolatey.org auf, kopiert den PowerShell-Befehl (iex…) in die Befehlszeile und führt ihn aus. Danach sollte ein

das Windows Management Framework 4.0 installieren. Sollte, weil wenn SP1 fehlt nur ein Schwall von Fehlermeldungen die Folge ist. Dafür wird das .NET Framework 4.5 automatisch nachinstalliert.

PowerShell und OData (4) – die Management OData-Dll per PowerShell-Skript erstellen

Wer kein Visual Studio installieren möchte oder kann, kann die erforderliche Assemblydatei auch mit einem kleinen PowerShell-Skript erstellen, das dazu den C#-Compiler Csc.exe aufruft, der im Verzeichnis der .Net-Laufzeit enthalten ist (Alternativ könnte man auch die Projektdatei per MsBuild.exe aufrufen).

Das folgende Skript erledigt dies. Bitte noch die Pfade anpassen, damit es funktioniert. Das Ergebnis ist eine Datei BasicPlugin.dll, die dann nur noch in das bin-Verzeichnis des Modata-Webverzeichnisses kopiert werden muss.

Tipp: Wie der C#-Compiler per Befehlszeile aufgerufen wird, wird z.B. unter der folgenden Adresse gut beschriebem:

https://msdn.microsoft.com/en-us/library/78f4aasd.aspx#vcconcommand_linebuildinganchor1

Tipp: Dateien flexibel kopieren mit ForEach

Das folgende Beispiel funktioniert nur mit der Version 4.0 (oder 5.0). Ausgangspunkt ist der Wunsch, eine Reihe von Dateien aus einem Verzeichnis in ein anderes Verzeichnis zu kopieren (etwa als Vorbereitung auf das Einrichten eines DSC Pull Servers, wenn dies „zu Fuß“ geschehen soll). Die Namen der Dateien liegen vor, das Zielverzeichnis aus:

Ein

funktioniert leider nicht. Ganz so flexibel ist der PowerShell-Parser dann doch nicht. Mit Hilfe der mit der Version 4.0 eingeführten ForEach-Erweiterung ist das Kopieren trotzdem mit nur einem Befehl machbar:

Möglich wird dies, da ForEach seinen Scriptblock für jede Datei in $Dateien einmal ausführt und das Ergebnis in die Pipeline legt, und der Path-Parameter von Copy-Item ein Array erwartet.

PowerShell und OData (Teil 3)

Im ersten Teil der Serie habe ich OData allgemein vorgestellt, im zweiten Teil ging es darum, wie sich OData-Webservices sowowhl im Browser als auch per Invoke-RestMethod-Cmdlet aufrufen lassen. Alles einfache Themen, die sehr deutlich machen, wie sich die PowerShell als Tool für die Abfrage von Webdaten und das Kombinieren mit Daten anderer Datenquellen eignet. Im dritten und letzten Teil der Serie geht es um Management OData (aka PowerShell Webservices). Ein Feature, das bereits seit der PowerShell 3.0 zur Verfügung steht, und einen Windows Server 2008R2/Windows Server 2012/R2 voraussetzt, auf dem das Feature ManagementOData (IIS-Erweiterung für OData Services for Managemen) hinzugefügt wurde.

Management OData kombiniert einen OData-Webservice mit PowerShell-Modulen. Damit wird es möglich, beliebige Cmdlets und Functions über OData-Webservice-Aufrufe auszuführen. Management OData ist Teil des Windows Management Frameworks ab Version 3.0, steht also bei jeder PowerShell zur Verfügung.

Die zentrale Frage ist natürlich die nach dem Nutzen dieser Technik. Für ein Windows-Netzwerk spielt sie keine Rolle, da es mit PowerShell-Remoting eine deutlich komfortablere Alternative gibt. Es dürfte keine Windows-Clients mehr geben, auf denen nicht wenigstens die PowerShell 2.0 installiert ist oder (Windows XP) installiert werden kann.

Die Zielgruppe für Management OData ist damit sehr klein.

Einsatzgebiete gibt es daher nur außerhalb der Windows-Plattform:

>PowerShell-Anwender, die (aus irgendeinem Grund) die in einem PowerShell-Modul enthaltene Funktionalität über Webservices zur Verfügung stellen wollen.

>Administratoren, die Daten, die über PowerShell-Cmdlets abrufbar und aktualisierbar sind, für mobile Endgeräte zur Verfügung stellen wollen. Ein Entwickler muss für dieses Gerät eine App schreibe, die den Webservice einbindet.

>PowerShell-Anwender, die Daten eines „Datensilos“ in einem Unternehmen oder einer Organisation (z.B. Behörde), über eine PowerShell-Schnittstelle (Cmdlets, Functions) zur Verfügung stellen wollen

Vorteil: Die Cmdlets lassen sich von einem beliebigen mobilen Gerät (z.B. Tablet oder SmartPhone eines x-beliebigen Herstellers) im Rahmen einer App ausführen

Der Vorteil gegenüber einer Eigenentwicklung mit Visual Studio und einer Programmiersprache wie C# ist, dass für Management OData grundsätzlich keine (!) Programmierung erforderlich ist. Theoretisch kann die komplette Bereitstellung mit Hilfe des OData Management Schemadesigners ohne die Eingabe eines einzigen Befehls erledigt werden.

Theoretisch deswegen, weil man in der Praxis doch ein paar Anpassungen vornehmen möchte, die das Editieren von Textdateien oder sogar etwas Programmierung erforderlich machen.

Management OData steht nicht „out of the box“ zur Verfügung, sondern muss als Feature hinzugefügt werden. Offiziell ist Windows Server 2012 Voraussetzung, doch es funktioniert auch unter Windows Server 2008 R2 (theoretisch auch unter Windows 7, wenngleich es mir noch nicht gelungen ist, einen Webservice auch aufzurufen – eventuell hatte ich ein IIS-Feature übersehen).

Schritt: Hinzufügen des Features


Install-WindowsFeature -Name ManagementOData

Damit versteht der IIS Management OData-Aufrufe. Um ein konkretes PowerShell-Modul aufrufen können, ist noch etwas Arbeit zu erledigen. Wenn man alles richtig macht und sich an die von Microsoft veröffentlichte Anleitung hält, dauert es knapp 30 Minuten (im Grunde kann man dabei nicht viel falsch machen;).

Im einfachsten Fall wird lediglich eines von drei Beispielprojekten benötigt, die von Microsoft im Rahmen der MSDN Code Samples zur Verfügung gestellt werden:


https://code.msdn.microsoft.com/windowsdesktop/PswsRoleBasedPlugins-1c7a7ef1

Wird eines dieser Beispielprojekte in Visual Studio erstellt resultiert eine Assemblydatei, die in das Webverzeichnis kopiert wird. Der Rest sind Textdateien und natürlich das Modul, das über den Webservice aufrufbar sein soll. Die Beispielprojekte führen also nicht zu ausführbaren Programmen, sondern lediglich zu einer Dll-Datei, die sich im Webverzeichnis befinden muss.

Auf dem MSDN Code Samples-Portal gibt es drei Beispielprojekte für Management OData

Abb. 1: Auf dem MSDN Code Samples-Portal gibt es drei Beispielprojekte für Management OData

Die drei Beispielprojekte unterscheiden sich lediglich durch die Art der Authentifizierung und den Aspekt von Management OData, den sie veranschaulichen sollen:

>Windows Powershell basic OData Web Service sample

>Windows Powershell role-based OData Web Service sample

>Association sample

Tipp: Die Beispiele sind etwas schwer zu finden. Für die ersten beiden Beispiele sucht man nach „Modata“, für das dritte Beispiel dagegen nach „Management OData“.

Die ersten beiden Beispiele verwenden als Ressourcen Dienste und Prozesse, die dadurch über URLs abrufbar sind. Die beiden Beispiele unterscheiden sich lediglich durch die Art der Authentifizierung. Während das erste Beispiel die einfachste Form der Authentifizierung verwendet, verwendet das zweite Beispiel eine Benutzerverwaltung auf der Grundlage einer XML-Datei, in der Benutzerkonten (lokale oder Domänkonten) auf Gruppen verteilt werden und jeder Gruppe ein Satz an Cmdlets/Modulen zugeordnet wird, die allen Mitgliedern dieser Gruppe zur Verfügung stehen, sowie Kontingente (wie oft darf ein Benutzer eine Ressource aufrufen). Das dritte Beispiel veranschaulicht das Prinzip der Beziehungen (Associations) und verwendet dazu fiktive Ressourcen (virtuelle Maschinen und Server), zwischen denen Beziehungen bestehen.

Für das Kennenlernen von Management OData empfehle ich das erste Beispielprojekt, das für die Authentifizierung ein beliebiges lokales Benutzerkonto verwendet.

Wozu ist das Beispielprojekt gut?

Das Beispielprojekt erfüllt zwei Aufgaben:

1) Es erklärt anhand des Quellcodes, wie die für die Authentifizierung und Einrichten einer PowerShell-Sessionkonfiguration erforderliche Assembly umsetzt wird. Dieser Aspekt ist für Entwickler interessant.
2) Es stellt ein fertiges Visual Studio-Projekt dar, das nur erstellt werden muss, um jene Assembly zu erhalten, die von einem Management OData-Webservice für die Authentizifierung und das Einrichten der Sessionkonfiguration benötigt wird. Das Erstellen des Projekts ist einfach und setzt keine (!) Programmierkenntnisse voraus (man muss lediglich die folgende Anleitung lesen und umsetzen;).

Warum stellt Microsoft die Assembly nicht direkt zum Download zur Verfügung oder macht sie zum Bestandteil des WMF?

Weil dies unflexibel ist, da sie immer an eine bestimmte Version des .NET Framework gebunden wäre, und weil das Erstellen wirklich sehr einfach ist. Es setzt lediglich ein Visual Studio voraus, z.B. Visual Studio 2013 Community Edition. Das Visual Studio muss man noch nicht einmal selber installieren. Man benötigt nur auf einem Computer mit Visual Studio, auf dem die Assembly erstellt wird. Das Ergebnis ist eine Datei mit der Erweiterung .Dll, die in das Webverzeichnis kopiert wird. Theoretisch könnte man auch ein kleines PowerShell-Skript schreiben, das die Quelltextdateien CustomAuthorization.cs und SessionConfiguration.cs per Aufruf des C#-Compilers Csc.exe kompiliert. Mehr dazu hier.

Das Visual Studio-Beispielprojekt wird in 5 Schritten umgesetzt, um die Assemblydatei zu erhalten:

Schritt 1: Download und Auspacken des Zip-Archivs in ein leeres Verzeichnis. Der Inhalt ist ein Visual Studio-Projekt mit seinen Dateien und drei davon unabhängige PowerShell-Skriptdateien.

Schritt 2: Laden der Projektmappendatei (BasicPlugins.sln) in Visual Studio. Ich empfehle Visual Studio 2013 Community Edition, da diese kostenlos ist.

Ein Blick in den Quellcode des Basic-Plugins

Abb. 2: Ein Blick in den Quellcode des Basic-Plugins


Schritt 3: Erstellen des Projekts.

Das Projekt wird über [Strg]+[Umschalt]+[B] oder den Menübefehl Erstellen|Projektmappe erstellen erstellt. Ging alles gut, erscheint ein entsprechender Hinweis im Ausgabefenster. Die Assemblydatei befindet sich im Projektverzeichnis bindebug (um es im Projektmappen Explorer sehen zu können, müssen dort alle Dateien sichtbar gemacht werden).

Das Projekt muss erstellt werden

Abb. 3: Das Projekt muss erstellt werden



Das Ausgabefenster zeigt an, dass das Projekt ohne Fehler erstellt wurde

Abb. 4: Das Ausgabefenster zeigt an, dass das Projekt ohne Fehler erstellt wurde

Sollte die Assemblydatei Microsoft.Management.OData.dll fehlen, muss diese nachträglich hinzugefügt werden. Sie befindet sich im GAC (C:WindowsMicrosoft.NetassemblyGAC_MSILMicrosoft.Management.ODatav4.0_3.0.0.0__31bf3856ad364e35Microsoft.Management.OData.dll).

Der Projektmappen-Explorer zeigt die eingebundenen Assemblies an

Abb. 5: Der Projektmappen-Explorer zeigt die eingebundenen Assemblies an


Um die Assemblydatei in ihrem bindebug-Verzeichnis zu sehen, müssen alle Dateien angezeigt werden

Abb. 6: Um die Assemblydatei in ihrem bindebug-Verzeichnis zu sehen, müssen alle Dateien angezeigt werden


Die Assemblydatei befindet sich im bindebug-Verzeichnis im Projektverzeichnis

Abb. 7: Die Assemblydatei befindet sich im bindebug-Verzeichnis im Projektverzeichnis

Das Ergebnis ist eine Assembly-Datei mit dem Namen Microsoft.Samples.Management.OData.BasicPlugins.dll. Diese Datei muss in das Setup-Projektverzeichnis kopiert werden. Meine Empfehlung ist, diese Assembly in ein Verzeichnis zu kopieren, das sich leicht erreichen lässt, z.B. D:MODataFiles, da wir die Assembly im Zusammenhang mit dem Management Data Schemadesigner noch einmal benötigen werden.

Schritt 4: Laden der Skriptdatei InstallModata.ps1 in die PowerShell ISE.

Schritt 5: Ausführen der Skriptdatei in der ISE (Administratormodus).

Mit dem Skript wird die Management OData-Erweiterung für den IIS noch einmal hinzugefügt, auch wenn dies bereits geschehen ist (damit kann man leben). Außerdem wird durch das Skript ein WCF-Endpunkt angelegt, der unter der folgenden Adresse aufgerufen wird:


http://localhost:7000/MODataSvc/Microsoft.Management.Odata.svc

Die Authentifizierung erfolgt einmalig über ein lokales Benutzerkonto.

Ging alles gut, werden die von dem Dienst zur Verfügung gestellten Ressourcen angezeigt. Über eine URL in der „ODATA-Syntax“, kann z.B. eine typische PowerShell-Abfrage ausgeführt werden:


http://localhost:7000/MODataSvc/Microsoft.Management.Odata.svc?$format=JSON&$filter=(WS gt 50000000)

Sämtliche Angaben in der URL, vor allem die Port-Nummer, können beim Erstellen des Endpunkts natürlich geändert werden.

Der Management OData Schemadesigner

Möchte man ein eigenes PowerShell-Modul bereitstellen, wird ein Tool mit dem Namen Management OData Schemadesigner benötigt, das Microsoft ein wenig versteckt. Die in der MSDN-Dokumentation enthaltenen Links führen zu einem Fehler (warum auch immer wurden sie nicht aktualisiert). Das Tool ist als Teil der Visual Studio Gallery unter der folgenden URL zu finden:


https://visualstudiogallery.msdn.microsoft.com/77bb35c1-7695-4f5e-ba1a-9ffeb6fe0d14

Der Management OData Schemadesigner hat zwei Aufgaben:

>Die für das Bereitstellen erforderliche Schemadateien anzulegen (eine Mof- und eine Xml-Datei).

>Den Endpunkt zu konfigurieren, so dass die Cmdlets des Moduls danach aufgerufen werden können.

Leider ist der Designer nicht 100% fehlerfrei, er besitzt einen kleinen Bug, der verhindert, dass weitere Hauptwörter nach der Auswahl eines Moduls ausgewählt werden können – abgesehen davon funktioniert er aber sehr gut.

Tipp: Die Programmdatei ManagementODataSchemaDesigner.exe wird im Verzeichnis C:Program FilesMicrosoftManagement OData Schemadesigner abgelegt.

Tipp: Neben dem Schemadesigner selber enthält der Download auch eine knapp 60 seitige Word-Datei mit dem Namen ManagementODataIISExtension_Whitepaper.docx, in der alle wichtigen Informationen zu Management OData zu finden sind. Selbst man den Designer nicht verwenden möchte, lohnt sich der Download bereits wegen dieser Datei.

Der Management OData Schemadesigner setzt die „Visual Studio 2010 Isolated Shell“ voraus, die zuerst installiert werden muss (mit neueren Versionen der Visual Studio Shell funktioniert es offenbar nicht). Download hier.

Tipp: Unter Windows 7 ist die Installation offiziell nicht möglich. Hier müssen lediglich die Dateien von einer Installation, etwa unter Windows Server 2012, kopiert werden. Der Designer lässt sich dann starten.

Mit folgenden Schritten wird mit Hilfe des Management Schemadesigners ein PowerShell-Modul bereitgestellt, das ich für diese Übung erstellt habe. Das Modul heißt PSServer und umfasst vier Cmdlets:

>Get-PSServer
>Add-PSServer
>Set-PSServer
>Remove-PSServer

Die Cmdlets arbeiten mit Objekten vom Typ PSServer, die in einer separaten Assemblydatei, die Teil des Moduls ist, definiert sind, und die „virtuelle Server“ repräsentieren. Jedes PSServer-Objekt besitzt die Eigenschaften ServerID, ServerName und Status.

Das kleine Modul steht über diesen PSServerals Zip-Datei zur Verfügung.

Schritt 1: Starten des Management OData Schemadesigner

Anlegen einer neuen Schemadefinitionsdatei

Abb. 8: Anlegen einer neuen Schemadefinitionsdatei

Die einzige in Frage kommende Vorlage ist „Management OData Model“.

Auswahl der Vorlage Management OData Model

Abb. 9: Auswahl der Vorlage Management OData Model

Schritt 2: Laden des Moduls und Auswahl der Cmdlets über einen Assistenten

Ein Modul soll importiert werden

Abb. 10: Ein Modul soll importiert werden

Das Modul PSServer wird über seine Psd1-Datei ausgewählt

Abb. 11: Das Modul PSServer wird über seine Psd1-Datei ausgewählt


Nach der Auswahl des Moduls werden die zur Auswahl stehenden „Nouns“ angeboten. An diesem Punkt besitzt der Schemadesigner einen Bug, der die Auswahl eines Nouns verhindert. Es kann lediglich das voreingestellte Noun übernommen werden, was in diesem Fall aber kein Problem ist.

Auswahl de Cmdlets über ihr Hauptwort

Abb. 12: Auswahl de Cmdlets über ihr Hauptwort

In diesem Dialogfeld wird die Zuordnung zwischen Web-Operation und Cmdlet getroffen oder einfach die Voreinstellung übernommen

Abb. 13: In diesem Dialogfeld wird die Zuordnung zwischen Web-Operation und Cmdlet getroffen oder einfach die Voreinstellung übernommen

Im nächsten Schritt werden die Eigenschaften festgelegt, die das Objekt, das als Web-Ressource angesprochen wird, besitzen soll.

Auswahl der Eigenschaften, die das Objekt besitzen soll, das über eine URL als Web-Ressource angesprochen wird

Abb. 14: Auswahl der Eigenschaften, die das Objekt besitzen soll, das über eine URL als Web-Ressource angesprochen wird

Im nächsten Schritt wird jene Eigenschaft ausgewählt, über die eine einzelne Instanz angesprochen wird. In diesem Fall ist es die ServerId-Eigenschaft.

Auswahl der Eigenschaft, über die eine einzelne Instanz angesprochen wird

Abb. 15: Auswahl der Eigenschaft, über die eine einzelne Instanz angesprochen wird

Im letzten Schritt könnten weitere Eigenschaften des Objekts mit Parametern der einzelnen Cmdlets verknüpft werden, was in diesem Fall aber nicht erforderlich ist.

Die Verknüofung weiterer Eigenschaften mit Parametern ist nicht erforderlich

Abb. 16: Die Verknüpfung weiterer Eigenschaften mit Parametern ist nicht erforderlich

Zum Schluss zeigt der Assistent eine Zusammenfassung an.

Zum Schluss zeigt der Assistent eine Zusammenfassung an

Abb. 17: Zum Schluss zeigt der Assistent eine Zusammenfassung an

Schritt 3: Bereitstellen des Endpunkts

Der Endpunkt wird über den Eintrag „Publish OData Endpoint“ im Kontextmenü angelegt.

Über den Schemadesigner wird ein Endpunkt angelegt

Abb. 18: Über den Schemadesigner wird ein Endpunkt angelegt

Die Daten des Endpunkts weden in ein Dialogfeld eingetragen.

Computer Name – das ist der Name des Computers, auf dem der Endpunkt bereitgestellt werden soll. In diesem Fall ist es der lokale Computer.

User Name/Password – da das Bereitstellen des Endpunkts per PowerShell-Remoting durchgeführt wird, beziehen sich Benutzername und Kennwort auf ein lokales Administratorkonto auf dem Computer, auf der Endpunkt bereitgestellt wird.

Site Name – der Name der Site kann freigewählt werden, in diesem Fall heißt sie „PSServer“. Dieser Name wird später in der URL verwendet.

Port – hier wird die Portnummer eingetragen, z.B. 7020.

Das Häkchen bei Use other ‚custom authorization‘ and ’session configuration‘ implementation muss (?) gesetzt sein, da nur so per Browse–Button die Assembly ausgewählt werden kann, in der die Klassen Authorization und Configuration implementiert sind. Hier wähle ich die Assembly Microsoft.Samples.Management.OData.BasicPlugins.dll aus, die aus dem Visual Studio-Beispielprojekt hervorgegangen ist.

Das Häkchen bei Copy custom Windows PowerShell modules muss nicht gesetzt sein. Ich habe es in diesem Beispiel gesetzt. Das hat zur Folge, dass die Psd1-Datei in das Webverzeichnis kopiert wird (was wiederum die Ursache für einen Fehler beim ersten Aufruf sein wird – mehr dazu in Kürze).

Die Daten des Endpunkts werden in ein Dialogfeld eingetragen

Abb. 19: Die Daten des Endpunkts werden in ein Dialogfeld eingetragen

Nach dem Klick auf Publish dauert es 2-3 Minuten bis eine Erfolgsmeldung erscheint. Die kleine Messagebox enthält die URL, über die der Endpunkt im Browser aufgerufen werden kann.

Der Endpunkt wurde angelegt

Abb. 29: Der Endpunkt wurde angelegt

Jetzt wird es spannend. Was wird die Eingabe der Endpunkt-URL in den Browser bringen? Für die Übung wird zunächst den Internet Explorer verwendet, da der Firefox-Browser die XML-Rückgabe automatisch als RSS-Feed formatiert anzeigt (ich habe leider noch nicht herausgefunden, wie sich das ändern lässt):


http://localhost:7020/PSServer/mosd.svc

Nach dem Drücken der Eingabe-Taste muss ich mich mit dem Namen eines lokalen Benutzerkontos und dem dazugehörigen Kennwort authentifizieren.

Beim ersten Aufruf ist eine Authentifizierung mit einem lokalen Benutzerkonto erforderlich

Abb. 21: Beim ersten Aufruf ist eine Authentifizierung mit einem lokalen Benutzerkonto erforderlich

Danach kommt es zu einem Fehler. Schade. Leider ist die Fehlermeldung nicht besonders aussagekräftig.

Der Aufruf des Webservice führt zu einem "request error"

Abb. 22: Der Aufruf des Webservice führt zu einem „request error“

Zum Glück gibt es ein Ereignisprotokoll mit dem Namen Microsoft-Windows-ManagementOdataService/Operational, das über Get-WinEvent abgefragt wird:

Es stellt sich heraus, dass die Assembly PSRZServer.dll nicht geladen werden konnte. Kein Wunder, denn sie wurde noch nicht in das Webverzeichnis kopiert. Das hole ich nach und kopiere dabei auch die zweite Assembly aus dem Modulverzeichnis in das Webverzeichnis.

In dem Webverzeichnis müssen auch die beiden Assemblydateien enthalten sein, die von dem Modul geladen werden

Abb. 23: In dem Webverzeichnis müssen auch die beiden Assemblydateien enthalten sein, die von dem Modul geladen werden

Grundsätzlich spielt es natürlich keine Rolle, wo sich das Modulverzeichnis befindet. Es liegt in diesem Fall an der von mir verwendeten Assembly (Microsoft.Samples.Management.OData.BasicPlugins.dll), das nur die Moduldateien im Webverzeichnis berücksichtigt werden.

Bevor ich einen zweiten Versuch starte, setze ich den IIS durch Eingabe von Iisreset in der PowerShell-Konsole zurück. Damit wird der IIS-Webserver und damit auch die Webanwendung neu gestartet.

Über einen IIS-Reset wird auch die Webservice-Anwendung neu gestartet

Abb 24: Über einen IIS-Reset wird auch die Webservice-Anwendung neu gestartet

Ich gehe die URL erneut ein und erhalte dieses Mal ein Erfolgserlebnis in Gestalt von Text im XML-Format zurück. Danke, ihr wunderbaren Management OData Webservices;)

XML ist die für die Weiterverarbeitung nicht ganz optimal, besser wäre JSON. Das erhalte ich über den OData-spezifischen Anhang ?$Format=JSON (die Groß-/Kleinschreibung spielt hier keine Rolle), den ich an die URL anhänge. Ich verwende dieses Mal den Firefox-Browser, da der IE (ohne einen Eingriff in die Registry, der mit chirugischer Präzision durchgeführt werden muss) kein JSON anzeigen kann:


http://localhost:7020/PSServer/mosd.svc?$format=JSON

Dieses Mal erhalte ich die Daten im JSON-Format zurück.

Als nächstes möchte ich die Abfrage natürlich in der PowerShell durchführen. Dafür verwende ich das mit der Version 3.0 eingeführte Invoke-RestMethod-Cmdlet, das intern die vielen sicher bekannte WebClient-Klasse verwendet:


Invoke-RestMethod -URL http://localhost:7020/PSServer/mosd.svc?$format=JSON -Credential Administrator

Dieses Mal erhalte ich „echte“ Objekte zurück, die über die Pipeline beliebig weiterverarbeitet werden können.

Um es noch einmal deutlich zu machen: Das Besondere an dieser Übung ist nicht, dass ich über einen Webservice-Aufruf Objekte erhalte. Das geht, wie in Teil 1 gezeigt, grundsätzlich mit jedem Webservice, dieser muss noch nicht einmal auf OData basieren. Das Besondere ist, dass die Daten von Cmdlets geliefert werden, die auf dem Webserver ausgeführt werden.

CRUD-Operationen über Invoke-RestMethod

Bislang wurden nur Abfragen ausgeführt, für die lediglich eine URL erforderlich war. Für Updates muss ein POST ausgeführt werden – es kommt eine „Payload“ ins Spiel, die als JSON-Objekt dem Cmdlet Invoke-RestMethod übergeben wird.

Beispiel:

Das folgende Beispiel legt ein neues PSServer-Objekt an:

Aufrufen beliebiger Cmdlets

Über Management OData lassen sich grundsätzlich beliebige Cmdlets (mit gewissen Einschränkungen) per POST aufrufen. Ein Schema ist nicht erforderlich, der Management OData Schemadesigner spielt daher auch keine Rolle. Der Aufruf geschieht über die Ressource CommandInvocation.

Voraussetzung ist, dass in Web.config im Element das Attribut enabled auf „true“ gesetzt ist.

Hier ein Beispiel für den Aufruf des Get-Hotfix-Cmdlets:

Da die Aufrufe auf dem Server asynchron ausgeführt werden, kann es passieren, dass nur ein Teil der Daten zurückgegeben wird. In diesem Fall muss Invoke-RestMethod mit der Session-ID erneut aufgerufen werden, um weitere Daten zu holen. Wer sich für das Thema interessiert, muss ein wenig „experimentieren“.

Tipps zur Fehlersuche

Wenn etwas nicht geht, sollte man als erstes im OData-Ereignisprotokoll Microsoft-Windows-ManagementOdataService/Operational nachsehen, das über Get-WinEvent abgefragt wird. Hier schreibt die ManagementOData-Assembly ihre Meldungen.

Tipp: Für das Löschen der „modernen“ Ereignisprotokolle gibt es bei der PowerShell 4.0 kein Cmdlet. Es geht über den kleinen Umweg der EventLogSession-Klasse und ihrer statischen Methode ClearLog. Der folgende Befehl löscht das ManagementOData-Eventlog:

Tipp: Für die Fehlersuche in den beteiligten Assemblies für die Authentifizierung und das Einrichten der Sessionkonfiguration würde ich Meldungen in das Eventlog Application schreiben und dafür zuvor eine Quelle (z.B. MoData) anlegen, so dass sich die Meldungen leichter auflisten lassen.

Fehler können auch etwas mit der IIS-Konfiguration zu tun haben. Die Einstellungen zu der Webservice-Anwendungen werden in der IIS-Managementkonsole bearbeitet, denn es handelt sich (natürlich) um eine reguläre IIS-Webanwendung.

Die allgemeinen Einstellungen der Management ODat a-Webanwendung werden in der IIS-Konsole angezeigt

Abb 25: Die allgemeinen Einstellungen der Management OData-Webanwendung werden in der IIS-Konsole angezeigt

Tipp: Nach einer Änderung des OData-Webservices sollte der IIS per „iisreset“ neu gestartet werden.

Wie zu allen Aspekten rund um Management OData gibt es nur sehr wenig Know-how im Internet.

Das wirft die Frage auf, ob Management OData bei Microsoft überhaupt eine Zukunft hat?

Zumindestens OData spielt in Zukunft eine Rolle, denn ab der PowerShell Version 5.0 gibt es die Function New-WebserviceEndpointProxy. Sie legt für einen beliebigen OData-Webservice ein Modul an, das Functions umfasst, mit deren Hilfe Abfragen und Updates durchgeführt werden können. Damit lassen sich OData-Webservices sehr einfach und nahtlos in eine allgemeine Abfrage integrieren – mit Management OData hat dies aber nur indirekt etwas zu tun.

Ich vermute, dass Management OData mit seiner Einführung bei der PowerShell 3.0 nur eine Art „Versuchsballon“ war (und die ganze Software in Indien entwickelt wurde und die Entwickler längst mit anderen Dingen beschäftigt sind) und das Projekt bei Microsoft inzwischen „tot“ ist – die wenigen Blog-Einträge stammen ausnahmslos aus dem Jahr 2012. Danach kam nichts mehr. Die Umsetzung eines Management OData-Service wird immerhin in der MSDN-Dokumentation vollständig beschrieben. Auf der anderen Seite kann es durchaus sein, dass das PowerShell-Team diese Technik wieder aufgreift.

Mein Fazit

OData ist ein sehr interessantes Thema, da sich beliebige Daten über das Web bereitstellen lassen.

Das Konsumieren, aber auch das Aktualisieren dieser Daten ist per PowerShell sehr einfach.

Mit Management OData können Module mit ihren Functions und Cmdlets als OData-Webservices zur Verfügung gestellt und z.B. in eine mobile Anwendung integriert werden. Der Vorteil ist, dass dazu dank des Management OData Schemadesigners keine Programmierung und nur wenig Know-how zum Thema Webservices erforderlich ist.

Ich wollte mit dieser Artikelserie ein Thema beleuchten, das ein offizieller Bestandteil des Management Framework an Version 3.0 ist, offiziell aber nur dürftig dokumentiert ist. Sollten noch Fragen offen geblieben sein stellt sie bitte über die Kommentarfunktion.

Das PshOData-Modul

Dieses Modul habe ich bei meinen unzähligen Webrecherchen nach dem Stichwort „PowerShell Management OData“ entdeckt:

https://github.com/toenuff/PshOdata

Es automatisiert das Ableiten eines Management OData-Endpunkts für ein PowerShell-Modul. Ausprobiert habe ich es allerdings noch nicht.