Archiv der Kategorie: English

Blog entries in english

Die ersten Schritte mit den AWS-Cmdlets (inkl. Problemlösung)

Amazon stellt für die Nutzung ihrer inzwischen sehr umfangreichen Amazon Webservices (AWS) ein sehr umfangreiches Modul (über 2.500 Cmdlets!) zur Verfügung. Die AWS Tools for Windows PowerShell stehen u.a. über die PowerShell Gallery zur Verfügung.

Eine ausführliche Übersicht gibt es unter der folgenden Adresse: https://aws.amazon.com/de/powershell/. Dort gibt es auch einen Button für den direkten Download einer Msi-Datei, über die das .NET SDK und die Cmdlets installiert werden.

Die Dokumentation ist, typisch für AWS, vorbildlich mit ein paar kleineren Abstrichen.

Das Modul muss direkt per Import-Module geladen werden.

Ein kleiner „Trick“ zählt die Anzahl der Cmdlets, in dem die Verbose-Ausgabe auf den Standardausgabekanal umgeleitet und damit in die Pipeline gelegt wird.

Die Authentifizierung erfolgt über einen Access Key und einen Secret Key, die man zuvor in der AWS-Konsole im Browser anlegen muss. Der Secret Key wird nur einmalig beim Anlegen eines neuen Key angezeigt und kann als Csv-Datei heruntergeladen werden.

Mit den beiden Zutaten wird per Set-AWSCredentials ein Profil angelegt.

Hier kam es bei mir zu einer Fehlermeldung, die besagte, dass der Pfad %userprofile%\.asws\credentials nicht gefunden werden konnte. Dieser Fehler muss wohl mit der Version der AWS-Tools (3.3.45.0) und anderen Faktoren zu tun haben. Der Fehler trat nicht mehr auf, nachdem ich im Benutzerprofil ein Verzeichnis mit dem Namen .aws angelegt hatte.

Interessant ist, dass die Keys aber nicht in diesem Verzeichnis, sondern als Json-Datei RegisteredAccounts.json unter %userprofile%\AppData\Local\AWSToolkit abgelegt werden.

Anschließend wurde das Profil per Get-AWSCredentials -ListStoredCredentials aufgelistet. Per Clear-AWSCredentials kann ein Profil wieder gelöscht werden.

Die weitere Vorgehensweise ist dann sehr einfach. Bei allen Cmdlets wie z.B. Get-S3Bucket erfolgt die Authentizierung über das Profil, das per ProfileName-Parameter angegeben wird.

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.

Feststellen, wer die Remote-Session benutzt

Möchte man in einer mit RunAsCredential-Parameter angelegten Remoting-Sitzung den Namen des Benutzerkontos abfragen, mit dem die Verbindung hergestellt wurde, liefert z.B. whoami nur den Benutzer des Administratorkontos dessen Credentials bei RunAsCredential angegeben wurden. Den Namen des Benutzerkontos, mit dem die Verbindung hergestellt wurde, erhält man über die Variable $PSSenderInfo und dessen ConnectedUser- (oder UserInfo-) Eigenschaft.