Archiv der Kategorie: PowerShell-Praxis

Tipp des Tages: Dienste entfernen auch ohne PowerShell

Triviale Aufgaben können ihre Tücken haben. Beispiel: Wie ich entferne ich einen Systemdienst, der sich auch per WMI nicht mehr entfernen lässt, da z.B. im onStop-Event eine Exception auftritt? Ganz einfach durch Beenden der Exe-Datei. Doch welche Exe-Datei ist es genau? Eine Kombination aus Sc.exe und Taskkill.exe löst das kleine Problem.

Warum Sc.exe und nicht Get-Service? Weil Ersteres mit dem queryex-Parameter auch die Prozess-ID mit ausgibt.

sc.exe queryex VISEFService

Anschließend genügt der Aufruf von

Taskkill /pid 1234 /F

wenn 1234 die Prozess-ID ist.

Natürlich geht das alles auch per PowerShell, aber inzwischen bin ich an dem Punkt angekommen wo es in erster Linie darum geht, dass ich nicht zu viel tippen muss (man wird älter und bequemer;). Und geht es nur darum, eine bestimmte Aufgabe zu erledigen, sind die alten Kommandozeilentools immer noch eine sehr gute Wahl.

Per PowerShell sähe der Aufruf in etwa so aus:

stop-process (Get-CimInstance Win32_Service -Filter "Name='VISEFService'").ProcessId

Es ist nicht unbedingt der Umfang der Zeile, sondern eher der andere Denkansatz, an den man sich erst gewöhnen muss. Im Moment habe ich eher das Gefühl, dass wir uns wieder zur klassischen „Kommandozeilen-Denkweise“ zurückbewegen.

Tipp des Tages: Verzeichnisse aus der path-Umgebungsvariablen entfernen

Hin und wieder kann es erforderlich sein, einzelne Verzeichnisse aus der path-Umgebungsvariablen zu entfernen. Was sich zunächst schwierig anhören könnte, ist in der Praxis dann doch ein relativ einfacher Befehl.

Der folgende Befehl entfernt alle Verzeichnisse, die ein Python36 enthalten, aus der Path-Umgebungsvariablen.

$env:path = $env:path.split(";").where{$_ -notmatch "Python36"} -join ";"

Die Änderung gilt natürlich nur für die aktuelle PowerShell-Sitzung. Soll sie dauerhaft sein, muss der neue Wert der Umgebungsvariablen über die SetEnvironmentVariable()-Methode der Environment-Klasse für den aktuellen Benutzer oder systemweit gespeichert werden.

Praxistipp: Das Anmeldekonto für einen Systemdienst aktualisieren

Zu den wenigen Einstellungen, die für einen Systemdienst nicht per Set-Service vorgenommen werden können gehört das Ändern des System- oder Benutzerkontos, unter dem der Dienst ausgeführt werden soll. Diese Einstellung muss per WMI, der Klasse Win32_Service und ihrer Change()-Methode vorgenommen werden. Benutzername und Kennwort werden dabei im Klartext übergeben. Eine kleine Herausforderung besteht darin, dass für alle nicht verwendeten Parameter ein $null übergeben werden muss.

Bill Stewart hat ein schönes Skript erstellt ( Set-ServiceCredential.ps1), mit dem das Systemkonto für einen Systemdienst aktualisiert werden kann:

https://gist.github.com/Bill-Stewart/ab3a228903c5d6fb3c12dc1d92d3d1e8

Mir ist das Skript aber etwas zu umfangreich und formal. Die folgende Function erledigt die Einstellung etwas kürzer:

function Set-ServiceAccount
{
  [CmdletBinding()]
  param([String]$Servicename, [String]$Username, [String]$Password)
  Stop-Service -Name $ServiceName
  $service = Get-WmiObject Win32_Service -Filter "Name='$ServiceName'"
  $ret = $service.change($null,$null,$null,$null,$null,$null,$Username,$Password,$null,$null,$null)
  if ($ret.ReturnValue -eq 0)
  {
      Write-Verbose "Kontoinformation wurde erfolgreich aktualisiert."
      Start-Service -Name $ServiceName
  }
  else
  {
      Write-Warning "Die Kontoinformation konnte nicht aktualisiert werden - ReturnValue=$($ret.ReturnValue)"
  }
}

Ging alles gut, ist der ReturnValue = 0. Ansonsten eine Zahl, die einen Fehlercode darstellt. 22 bedeutet z.B., das das Konto nicht stimmt (in dem Skript von Bill Stewart werden alle Fehlercodes abgefragt und durch Fehlermeldungen ersetzt).

Tipp des Tages: Befehlsverlauf (History) durchsuchen mit PsReadline

Der Befehlsverlauf (History) der PowerShell-Konsole besitzt den (kleinen) Nachteil, das er nicht automatisch gespeichert wird und damit beim nächsten Start der Konsole nicht mehr vorhanden ist. Was nicht jeder PowerShell-Anwender wissen dürfte, sobald PSReadline verwendet wird, gibt es einen eigenen Verlauf, der über die Pfeiltasten abgerufen wird (nicht per Get-History). Praktisch ist, dass sich dieser Verlauf auch durchsuchen lässt.

Ex-Scripting Guy Ed Wilson hatte ja bereits schon 2014 (also vor mehr als 5 Jahren) darüber geschrieben:

Lange her, aber immer noch aktuell – der Umgang mit dem Befehlsverlauf der PowerShell-Konsole

Im Grunde läuft es auf den Tastaturshortcut [Strg]+[r] hinaus. Über ihn wird der Befehlsverlauf von PsReadline nach allen Zeilen rückwärts durchsucht, die mit der danach eingegebenen Zeichenfolge beginnen. Für jeden weiteren Treffer drückt man erneut [Strg]+[r]. Für was die Vorwärtssuche per [Strg]+[s] gut sein soll, ist mir dagegen nicht klar. Vielleicht hat jemand eine Erklärung.

Im „neuen“ PSReadline zeigt Get-PSReadlineKeyHandler die Tastaturshortcuts auch sehr übersichtlich an.

Kleine Tipps für Zwischendurch – Zeitspannen formatiert ausgeben

Genau wie für DateTime-Objekt, die bekanntlich eine Datum und eine Uhrzeit repräsentieren, gibt es auch für TimeSpan-Objekte, die eine Zeitspanne repräsentieren, eine formatierte Ausgabe. Allerdings nicht ganz so intuitiv wie es sein könnte.

Gleich vorweg: Alles ist bei docs.microsoft.com natürlich vorbildlich dokumentiert:

https://docs.microsoft.com/de-de/dotnet/standard/base-types/custom-timespan-format-strings

Aber zum einen bezieht sich die Dokumentation auf die Programmiersprache C# und zum anderen, wer liest wirklich eine solche Beschreibung?

Ein TimeSpan-Objekt entsteht z.B. immer dann, wenn zwei DateTime-Objekte voneinander subtrahiert werden. Es gibt Eigenschaften wie days, hours, minutes, totaldays, totalhours usw. Während z.B. hours für den Stundenanteil steht, steht totalhours für die Zeitspanne in Stunden. Beträgt die Zeitspanne z.B. 90 min, wären hours=1 und totalhours=1.5.

Möchte man ein TimeSpan-Objekt als Teil einer Zeichenkette ausgeben, muss man die Formatbezeichner kennen. Sie lauten h, m, s und fff (für Millisekunden). Das ist irgendwie naheliegend, etwas verzwickter wird es durch den Umstand, dass auf den ersten Formatbezeichner ein Apostroph folgen und die folgenden Formatbezeichner in Apostrophe gesetzt werden müssen (wer sich das ausgedacht hat).

Hier ein paar Beispiele in loser Reihenfolge.

$d =(Get-Date)
$da =(Get-Date) - $d
$da.ToString("m'm 's's'")
17m 10s
"{0:m'min 's'sec'}" -f $da
17min 10sec
 "{0:s':'fff''}" -f $da
10:831
"{0:m'min 's'sec 'fff'ms'}" -f $da
17min 10sec 831ms

PS; Dies ist mein letzter Blogeintrag auf absehbare Zeit. Bei Fragen rund um die PowerShell bitte einfach eine Mail, z.B. an pm ät activetraining de.

Praxistipp: SQL-Kommandos aus einer SQL Server-Trace-Datei herausziehen

Der folgende Tipp ist sehr speziell, aber enorm praktisch und ganz allgemein ein weiteres Beispiel für die Flexibilität beim Auswerten von Xml-Dateien per PowerShell.

Ausgangspunkt ist der Microsoft SQL Server und da wiederum der SQL Server Profiler, der alle SQL-Kommandos anzeigt, die von einer Anwendung an die Datenbank geschickt werden. Das Trace-Protokoll kann im XML-Format gespeichert werden.

Der folgende Befehl zieht nur die SQL-Kommandos aus der XML-Datei heraus, so dass sie in einer separaten Textdatei gespeichert werden könnten:

 

$Xml = [Xml](Get-Content $XmlPfad)

$Xml.TraceData.Events.Event | Where-Object Name -eq "SQL:BatchStarting" | 
 Where-Object { $_.Column.Name -eq "TextData" }  | 
  Select-Object -ExpandProperty Column | 
 Where-Object Name -eq "TextData" | 
 Select-Object -Expand "#text" > SqlText.txt

Auch wenn auch der SQL Server-Profiler eine ähnliche Option bietet, den reinen SQL-Text erhält man damit nicht.

PowerShell unter Linux installieren

Der folgende Beitrag ist eher eine „Note to my self“, damit ich beim nächsten Mal danach nicht suchen muss – auf der PowerShell Projektportalseite ist alles sehr schön und vollkommen ausreichend beschrieben:

https://docs.microsoft.com/de-de/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-6#ubuntu-1604

Aber vielleicht doch etwas zu ausführlich.

Also, mit der Linux-VM per SSH verbinden. Danach geht es wie folgt weiter:

Schritt 1: Herunterladen der Schlüssel (keys), damit das Microsoft-Repo vom Paketmanager als vertrauenswürdig behandelt wird.

wget -q https://packages.microsoft.com/config/ubuntu/16.04/packages-microsoft-prod.deb

Schritt 2: Registrieren der Microsoft-Schlüssel

sudo dpkg -i packages-microsoft-prod.deb

Schritt 3: Aktualisieren aller Pakete

sudo apt-get update

Schritt 4: Jetzt wird das PowerShell-Paket installiert

sudo apt-get install -y PowerShell

Es wird automatisch die aktuellste stabile Version installiert.

Schritt 5: Ging alles gut, PowerShell starten

pwsh

Ein $PSVersionTable gibt aus, um welche Version es sich tatsächlich handelt. 6.2, 6.3 womöglich sogar 6.4:)

Wurde die Microsoft-Paketquelle registriert, lässt führt ein allgemeines Upgrade aller Pakete auch dazu, dass PowerShell aktualisiert wird.

sudo apt-get upgrade powershell

Möchte man lediglich PowerShell auf den aktuellesten Stand bringen, muss install erneut ausgeführt werden.

sudo apt install powershell

Update 18/02/19:

Bei aktuellen Ubuntu-Versionen kann man sich dank dem von canonical entwickelten Package-Format snap alle der hier aufgezählten Schritte sparen. Einfach „pwsh“ eingeben und den Anweisungen folgen. Kurz danach kann PowerShell Core per „pwsh“ gestartet werden. Einfach und genial. Aber vermutlich bleibt der Komfort auf Ubuntu beschränkt.

Erstellen eines Zertifikats per Inf-Datei und ein kleiner Unterschied zwischen der ISE und Visual Studio Code

Visual Studio Code ist ein genialer Universaleditor mit unzähligen Erweiterungen. Eine davon macht Code zu einem mehr als vollwertigen Editor für PowerShell-Skripte inklusive Eingabehilfen und einer deutlich besseren Debugger-Unterstützung. Die einzige kleine Einschränkung gegenüber der ISE ist, dass bei „Code“ eine Befehlsfolge in einer Datei gespeichert werden muss, damit sie als PowerShell-Skript ausgeführt werden kann.

Eine weitere Eigenheit von Code hat mich vor einiger Zeit etwas Nerven gekostet. Ein Skript führte zu einem eigentlich harmlosen „Die Zeichenfolge hat kein Abschlusszeichen“-Fehler, dessen Ursache ich einfach nicht finden konnte. In der ISE wurde dasselbe Skript problemlos ausgeführt. Am Ende stellt sich heraus, dass es genau die BOM-Bytes waren, die bei der ISE automatisch einer Textdatei vorangestellt werden. Nachdem ich das Skript auch in Code als „UTF-8 with BOM“ gespeichert hatte, funktioniert es dort genauso.

Das Skript ist eine kleine Demo des Protect-CMS-Cmdlets, das in der Windows PowerShell die Verschlüsselung von Zeichenketten mit Hilfe eines für die Dokumentesignierung geeigneten Zertifikats erledigt. Das Zertifikat wird mit Hilfe einer Inf-Datei und dem Befehlszeilentool certreg.exe angelegt. In die Inf-Datei muss lediglich ein Wert für subject eingetragen werden.

<#
 .Synopsis
 Ein Kennwort verschlüsseln per Cryptographic Message Syntax (CMS) und einem Zertifikat
 .Notes
 Geht nicht bei PowerShell Core
#>

# Schritt 1: Zertifikat anlegen, das für die Dokumentverschlüsselung geeignet ist

$InfPfad = Join-Path -Path $PSScriptRoot -ChildPath PsKursZertifikat.inf

{[Version]
    Signature = "$Windows NT$"
    
    [Strings]
    szOID_ENHANCED_KEY_USAGE = "2.5.29.37"
    szOID_DOCUMENT_ENCRYPTION = "1.3.6.1.4.1.311.80.1"
    
    [NewRequest]
    Subject = "cn=pskurs"
    MachineKeySet = false
    KeyLength = 2048
    KeySpec = AT_KEYEXCHANGE
    HashAlgorithm = Sha1
    Exportable = true
    RequestType = Cert
    KeyUsage = "CERT_KEY_ENCIPHERMENT_KEY_USAGE | CERT_DATA_ENCIPHERMENT_KEY_USAGE"
    ValidityPeriod = "Years"
    ValidityPeriodUnits = "1000"
    
    [Extensions]
    %szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_DOCUMENT_ENCRYPTION%"
}  | Out-File -FilePath $InfPfad

# Set-Content geht nicht, da {} nicht mitgespeichert werden darf

$CerPfad = Join-Path -Path $PSScriptRoot -ChildPath PsKursZertifikat.cer

# Zertifikat vorher löschen
dir Cert:\CurrentUser\my | Where-Object Subject -eq "cn=pskurs" | del

# Cer-Datei löschen
$CerPfad | Remove-Item -ErrorAction Ignore

# Zertifikat anlegen
Certreq.exe -new $InfPfad $CerPfad

$PwPfad = Join-Path -Path $PSScriptRoot -ChildPath PwCert.dat

# Wurde die Cer-Datei angelegt?
Test-Path -Path $CerPfad

# Alle Zertifikate auflisten, mit denen sich Dokumente verschlüsseln lassen
dir -Path Cert:\CurrentUser\My –DocumentEncryptionCert

# Schritt 2: Kennwort mit dem Zertifikat verschlüsseln
$PwString = "demo+1234"

$PwString | Protect-CmsMessage -To "cn=pskurs2" > $PwPfad

# Schritt 3: Kennwort wieder einlesen
$PwNeu = Get-Content -Path $PwPfad | Unprotect-CmsMessage
$PwNeu

# Details der verschlüsselten Nachrichten ausgeben
Get-Content -Path $PwPfad  | Get-CmsMessage

Visual Basic-Code in einem PowerShell-Skript ausführen

Visual Basic ist ein wenig die vergessene Programmiersprache bei Microsoft. In den 90er Jahren hatte das damals noch alte Visual Basic einen großen Anteil daran, dass sich Windows 3.0 und seine Nachfolger als Betriebssystemoberfläche so schnell verbreiten konnte. Mit der Einführung von .NET Framework im Jahr 2002 war Visual Basic als Visual Basic.NET zwar noch vertreten, das neue Visual Basic hatte aber nicht mehr viel mit dem vertrauten Visual Basic gemein. Die Folge war, dass es immer mehr auf ein Abstellgleis geriet, wenngleich die Sprache immer noch ein fester Bestandteil des .NET Framework als auch von .NET Core ist und auch weiterentwickelt wird. Auch bei .NET Core 3.0 wird VB dabei sein, auch wenn es nicht für alle Anwendungstypen eingesetzt werden kann:

https://blogs.msdn.microsoft.com/vbteam/2018/11/12/visual-basic-in-net-core-3-0/

Anders sieht es bei PowerShell Core aus. Mit der aktuellen Version 6.1 wird VB im Zusammenhang mit dem Add-Type-Cmdlet nicht mehr unterstützt. Auch wenn es nur wenige Gründe geben dürfte, in einem PowerShell-Skript Visual Basic-Code zu verwenden ist es trotzdem etwas schade, da eine Option weniger zur Auswahl steht.

Das folgende Beispiel ist daher nur für die Windows PowerShell gedacht. Es startet Word per später Bindung, lädt eine Docx-Datei und speichert sie als Pdf-Datei. Das setzt Word ab Version 2010 (?) voraus, damit diese Option überhaupt zur Verfügung steht.

<#
 .Synopsis
 Visual Basic Code ausführen
#>

$VBCode = @"

    Sub Docx2Pdf(DocxPfad as String)
        Dim WdApp As Object
        Dim PdfPfad As String = System.IO.Path.ChangeExtension(DocxPfad, ".pdf")
        WdApp = CreateObject("Word.Application")
        WdApp.Documents.Open(DocxPfad)
        WdApp.ActiveDocument.SaveAs(PdfPfad, 17)
        WdApp.Quit()
    End Sub

"@

Add-Type -MemberDefinition $VBCode -Language VisualBasic -Name PdfConvert -ReferencedAssemblies Microsoft.VisualBasic -UsingNamespace Microsoft.VisualBasic -Namespace Wd


$DocxPfad = "$env:userprofile\documents\FragenZurFormatierung_1908.docx"
[Wd.PdfConvert]::new().Docx2Pdf($DocxPfad)

17 ist der „Code“ (der Wert der Konstanten, die für das Dateiformat steht) für Pdf. Alle Pfade bitte anpassen, damit es auch funktioniert.

Tipp: Oracle Datenbanken per PowerShell ansprechen

Wer Oracle hört, denkt wahrscheinlich zunächst an hochpreisige Produkte und komplizierte Installationen. Das ist natürlich nur bedingt der Fall.

In jedem Fall ist der Zugriff auf eine Oracle DB per PowerShell sehr einfach. Voraussetzung ist, dass ODP.NET (z.B. als Teil der Developer Tools for Visual Studio) installiert wurde. Die Developer Tools installiert man auch dann, wenn kein Visual Studio vorhanden ist. In jedem Fall gibt es danach eine Assembly mit dem Namen Oracle.ManagedDataAccess.dll in dem Verzeichnis, in das die Developer Tools installiert wurden.

Das folgende kleine Beispiel geht von einer vorhandenen Datenbank aus. Benutzername und Kennwort sind natürlich frei erfunden. Wichtig ist nur, dass der Pfad der Dll-Datei stimmt.

    Add-Type -Path "C:\Assembly\Oracle.ManagedDataAccess.dll"
    $CnStr = "Data Source=minipc:1521;User Id=System;Password=pw1234"
    $Cn = [Oracle.ManagedDataAccess.Client.OracleConnection]::new()
    $Cn.ConnectionString = $CnStr
    $Cn.Open()
    "Verbindung steht!!!"
    $Cn.Close()
    "Verbindung wurde geschlossen!!!"

Für eine konkrete Datenbankabfrage muss lediglich ein OracleCommand-Objekt angelegt, der CommandText-Eigenschaft ein SQL-Kommando zugeordnet und per ExecuteReader() ein DataReader geholt werden, der dann per Read() durchlaufen wird. Sollte alles kein Problem sein.

PS: Ein Listener muss dazu nicht mehr konfiguriert werden. Die Oracle DB läuft ohnehin nicht auf dem Computer, auf dem die Abfrage ausgeführt wird.