Archiv für den Monat: Dezember 2016

Frohe Weihnachten…

Ich wünsche allen Lesern dieses Blogs frohe, sorgenfreie und gesegnete Weihachten und einen guten Start in das neue Jahr 2017.

Speziell was das Thema PowerShell angeht wird es wie fast in jedem Jahr auch 2017 abwechslungsreich bleiben. Mit SSH und einer „PowerShell 6.0“ auf allen Plattformen kommt ein neues Thema dazu, andere Themen wie Testen von Skripten, DSC-Ressourcen und allgemein Einstellungen mit dem Pester-Modul oder generell die Bedeutung einer „Release-Pipeline“ für Skripte und DSC-Ressourcen werden an Bedeutung zunehmen. Interessant wird es sein zu beobachten inwieweit Cloud-Angeboote wie Microsoft OMS (Operations Management Suite), mit der sich Windows Server überwachen lassen, auch in Deutschland angenommen werden.

Mein neues zur Buch zur PowerShell 5.0 wird auch hoffentlich im ersten Quartal erscheinen, so dass mir schon alleine aus diesem Grund die Arbeit nicht ausgehen wird.

Vielleicht sehen wir uns 2017 auf einer PowerShell-Schulung oder auf einem Treffen der PowerShell User Group, z.B. am 12.1.2017 in Stuttgart.

Ihr
Peter Monadjemi

Das Ende meiner Loseblatt-Sammlung, das Ende einer Ära und das fehlende Schlusswort der letzten Aktualisierung

Vor einigen Tagen kam die letzte Aktualisierung der Loseblattsammlung mit dem Titel „Automatisierte Administration mit Scriptsprachen unter Windows NT 4.0/2000, 2003 und 2008“, für die ich über 10 Jahre als Herausgeber beim WEKA Verlag (vormals Interest Verlag) in Augsburg zuständig war.

Loseblatt. Das weckt natürlich Erinnerungen an die späten 80er und frühen 90er Jahre und sicher nicht nur positive. Damals wurden die Loseblatt-Werke zu allen möglichen Themen rund um das Thema Computer in allen Magazinen mit großem Aufwand beworben. Die Angebote klangen auch verlockend – über 1.000 Seiten Praxis-Know how, zusammmengestellt von namhaften Experten, in zwei voluminösen A5-Ringbüchern für nur 59 DM (Preis fiktiv), jederzeit kündbar, Geldzurückgarantie usw. Der Preis war natürlich nur ein Lockangebot für ein Abonnement, das, sobald es zustande kam, nicht mehr ganz so einfach kündbar war. Die meisten Abonnenenten liessen ihr Abo vermutlich mehr aus Bequemlichkeit weiterlaufen und erhielten alle paar Wochen einen Schwung von Blättern im DIN A5-Format, die sie theoretisch selber in den großen Ringordner im A5-Format einsortieren sollten, den sie als Teil des Begrüßungspakets erhalten hatten. Damals, als Internet noch etwas war, das jemand im fernen Kalifornien erfunden hatte, war ein Loseblatt-Abo eine Gewähr dafür an jene Informationen zu kommen, die ansonsten nur mit sehr viel Aufwand erhältlich gewesen wären.

Spätestens vor 5 Jahren hätte das Loseblatt-Werk eigentlich „tot“ sein müssen, da es inzwischen auch jede Menge Angebote im Internet gab, die Informationen so aufbereiteten, dass sie aktuell, informativ und leicht konsumierbar waren. Mein Scripting-Handbuch hielt sich tapfer trotz stetig sinkender Abo-Zahlen – am Ende im unteren zweistelligen Bereich. Jetzt ist Schluss und ich denke, dass es insgesamt gut so ist, da ich es niemanden mehr zumuten möchte Informationen zur PowerShell oder Windows Server alleine aus dem Lesen von A5-Seiten zu beziehen.

Leider wurde in der letzten Aktualisierung vom Dezember diesen Jahres mein Schlusswort im Editorial nicht abgedruckt. Für den unwahrscheinlichen Fall, dass ein ehemaliger Abonnent diesen Blog-Eintrag lesen sollte, hier sind die Sätze, die ich gerne noch an die verbliebenen Leser gerichtet hätte:


Mit dieser Aktualisierung wird das Loseblattwerk Scripting eingestellt. Die erste Aktualisierung erschien im Jahr 2000. Damals waren Themen wie Hyper-V, System Center, Azure und auch PowerShell noch visionäre Themen. Heute, 16 Jahre später, sind sie Alltag für alle, die sich in ihrem beruflichen Umfeld mit Microsoft-Produkten im Server-Umfeld beschäftigen müssen. Konstant geblieben ist über die Jahre die Notwendigkeit sich weiterbilden zu müssen und dabei Spaß am Beschäftigen mit neuen Themen zu haben. Wer sich diese Fähigkeiten erhält, ist für alles was in Zukunft noch kommen mag gut vorbereitet. Und natürlich: Vielen Dank, dass Sie dem Werk so lange die Treue gehalten haben.

Turn PowerShell scripts into an exe with Posh2Exe (update 12/14/2016)

I recently relased a small Windows console application that turns any ps1 script file into an exe file by embedding the ps1 as a resource into the exe.

Get the source code and compile the exe in Visual Studio

The project is on github:

https://github.com/pemo11/Posh2Exe

Right now you have to use Visual Studio (any of the current releases will do – I recommend Visual Studio 2015 Community Edition as the latest release) to create the exe file Posh2Exe.exe. I will provide a download link for the exe in the near future and also a small extension for the ISE so that making an exe out of the currently loaded ps1 will be very simple because you only have to click on a button.

Calling Posh2Exe in the Console Window (not in the ISE) is really simple:

This will embed test.ps1 into an exe test.exe (the name is not very original of course;). The exe can be run everywhere where WMF 4.0 or above and .NET 4.0 (which is a prerequisite for WMF 4.0) is installed.

If the ps1 file uses parameters the parameters has to be written like parametername:value separated by at least one blank.

I tested the current version of posh2exe with several scripts and it worked well for me.

Since its a kind of bare bone PowerShell host implementation some things do not work at the moment like Read-Host with the AsSecureString-Parameter or the different prompt-methods of the InternalHostUserInterface.

Another thing to consider is the fact that the PSScriptRoot variable has no value because there is no script file that will be executed just text. The workaround is to use [System.AppDomain]::CurrentDomain.BaseDirectory to get the path the exe is started from and [Environment]::CurrentDirectory to get the current path for the executing exe instead of $PSScriptRoot. For my own scripts that runs either as a ps1 file or inside an exe I using a simple query to decide how to get the path either the ps1 file or the exe is running in.

Big plans for the future…

One more thing I would like to add is a debug mode with the help of the „Debugger API“. So it will be possible to debug the script that is executed as part of the exe file with the PowerShell Debugger.

Runspaces debuggen

Seit der PowerShell 5.0 ist es möglich, Skripts zu debuggen, die in einem zusätzlich angelegten Runspace ausführen. Doch warum sollte man das tun? Zum Beispiel, weil ein Skript in einem asynchron, also per BeginInvoke ausgeführten Runspace parallel zu anderen Runspaces ausführen kann und sich damit eine effektive Form des „Multitaskings“ bei der Ausführung eines Skripts ergibt.

Runspaces gab es bei der PowerShell von Anfang an, denn ein Runspace spielt eine zentrale Rolle für die Ausführung von Befehlen. Jeder Befehl wird in einem Runspace ausgeführt. In der Regel ist es jener Default-Namespace, der automatisch mit dem Start der Host-Anwwendung angelegt wird. Über ein [RunspaceFactory]::CreateRunspace() werden weitere Runspaces angelegt. Anschließend wird eine Pipeline [PowerShell]::Create() angelegt, mit Befehlen oder einem Skript gefüllt und mit einem Runspace verbunden.

Erst seit der Version 5.0 ist es möglich, ein Skript in einem separaten Runspace zu debuggen. Im Mittelpunkt stehen die Cmdlets Enter-PSHostProcess, Get-Runspace und Debug-Runspace.

Das folgende Beispiel geht von einem kleinen Skript aus mit dem Namen Skript.ps1. Sein Inhalt spielt keine Rolle. Wichtig ist nur, dass es in einem separaten Runspace (synchron) ausgeführt wird. Dies geschieht in einem Skript, das in der PowerShell ISE ausgeführt wird.

Damit das Skript bei seiner Ausführung nicht einfach durchrauscht, wird in der Zeile mit dem Invoke-Aufruf ein Haltepunkt gesetzt und das Skript gestartet. Dadurch wird ein Runspace angelegt, ein Skript in den Runspace geladen, aber noch nicht ausgeführt.

Ein Skript wird in einem weiteren Runspace ausgeführt

Im zweiten Schritt wird die PowerShell-Konsole gestartet und der ISE-Prozess per Enter-PSHostProcess betreten:

Der Prompt der Konsole ändert sich zu [Prozess: 1234], wobei 1234 für die Prozess-ID steht.

Ein Get-Runspace listet alle Runspaces im ISE-Prozess auf. Wichtig ist der „RunspaceX“-Runspace und seine Id. Seine State-Eigenschaft muss den Wert „Opened“ und seine Avaivalibilty-Eigenschaft den Wert „Available“ besitzen.

Im Konsolenhost werden die Runspaces des ISE-Prozesses aufgelistet

Dieser Runspace wird per Debug-Runspace-Cmdlet mit der Id des Runspaces debuggt:

Neben dem Standard-Runspace steht auch der Runspace „RunspaceX“ zur Auswahl

Damit wird der Runspace in den Debug-Modus versetzt. Damit auch etwas passiert, muss der Invoke-Aufruf in der ISE ausgeführt werden. Damit steht der Debugger in der PowerShell-Konsole zur Verfügung und das Skript kann bei der Ausführung in seinem Runspace debuggt werden. Die einzige Einschränkung besteht darin, dass die Ausgaben gesammelt und erst am Ende zusammen ausgegeben werden.

Der Debugger wird über [Strg]+[C], der Host-Prozess über exit verlassen.

Der Runspace „RunspaceX“ wird debuggt

Die Möglichkeit jeden Runspace debuggen zu können ist eine wichtige Neuerung bei der Version 5.0, auch wenn sie nur weniger Anwender verwenden werden.

Jetzt muss ich noch herausbekommen wie ich ein Skript debuggen kann, das in einer von mir umgesetzten Host-Anwendung in einem Remote-Runspace ausgeführt wird.

eBook zum Thema PowerShell und Azure

Unter GitHub gibt es seit kurzem ein eBook, das den Einsatz der PowerShell im Zusammenspiel mit Azure sehr schön beschreibt:

https://github.com/gitralf/ersteschritte/blob/master/Azure_PowerShell_Erste_Schritte.pdf

Der Autor ist Ralf Wiegand, der bei Microsoft Deutschland für das Thema „Deutsche Cloud“ zuständig ist. Seinen Blog findet ihr unter https://blogs.technet.microsoft.com/ralfwi/.

Tipp: Einen Scriptblock vorzeitig verlassen mit dem return-Befehl

Wie verlässt man einen Scriptblock vorzeitig? Mit dem return-Befehl, da ein Scriptblock lediglich eine anonyme Function ist.

Der eventuell naheliegendere break-Befehl funktioniert nur, wenn der Scriptblock per & aufgerufen. Beim Aufruf über Invoke bewirkt er, dass der Scriptblock offenbar nicht ausgeführt wird.