Tools

Sequenzielle Verarbeitung großer Datenmengen kann lange dauern — gerade bei Cloud-APIs. Die Lösung ist Parallelisierung, und dafür müssen die Daten zuerst in Portionen (Chunks) zerlegt werden.

Damit dieses Rad nicht in jedem Skript neu erfunden wird, übernimmt Split-Array genau diesen Schritt: Es teilt ein Array in ein Array von Arrays — wahlweise nach maximaler Chunk-Größe oder in eine feste Anzahl von Chunks.

Klein, aber fein: Edge Cases sind berücksichtigt, die Eingabe funktioniert als Argument ebenso wie über die Pipeline.

Install-Module SplitArray          # PowerShellGet
Install-PSResource SplitArray      # PSResourceGet

# Greedy-Verteilung (Standard): Füllt Chunks maximal auf
Split-Array -InputObject 1..10 -ChunkSize 3
# Ergebnis: (1,2,3), (4,5,6), (7,8,9), (10)

# Even-Verteilung: Verteilt den Rest gleichmäßig
Split-Array -InputObject 1..10 -ChunkSize 3 -Distribution Even
# Ergebnis: (1,2,3), (4,5,6), (7,8), (9,10)

# Even-Verteilung (Standard): Erzeugt exakt 4 ausgeglichene Chunks
Split-Array -InputObject 1..10 -MaxChunk 4
# Ergebnis: (1,2,3), (4,5,6), (7,8), (9,10)

# Mit $null auf die volle Chunk-Größe auffüllen
Split-Array -InputObject 1..10 -ChunkSize 3 -Pad $null
# Ergebnis: (1,2,3), (4,5,6), (7,8,9), (10,$null,$null)

Innerhalb eines Cmdlets ist die PowerShell-Pipeline elegant. Sobald aber die Ausgaben mehrerer Cmdlets zusammengeführt werden müssen, beginnt die Handarbeit: Schleifen, Zwischenspeicher und von Hand gepflegte Hashtable-Lookups.

Join-Object verbindet die Ausgaben zweier Cmdlets anhand einer gemeinsamen Identität — etwa einer SMTP-Adresse oder GUID — zu einem einzigen Objekt, direkt in der Pipeline.

Jedes Cmdlet wird dabei genau einmal aufgerufen, ganz ohne explizite Schleifen. Das Ergebnis bleibt ein kompakter, lesbarer One-Liner.

Install-Module JoinObject          # PowerShellGet
Install-PSResource JoinObject      # PSResourceGet

Get-Service | Join Get-Process -IdentityProperty Name |
    Select-Object Name, Status, CPU, WorkingSet

Get-Mailbox -RecipientTypeDetails SharedMailbox |
    Join-Object Get-MailboxStatistics |
    Select-Object PrimarySmtpAddress, TotalItemSize, ItemCount

$Users | Join-Object Get-ADUser -With @{ Properties = 'Department', 'Office' } -Force

Was DOS-Batchdateien mit ECHO ON immer konnten, fehlt PowerShell bis heute: ein Protokoll, das vor jedem Befehl festhält, was gleich ausgeführt wird. In langen Logs lässt sich Ausgabe deshalb oft nicht mehr dem Befehl zuordnen, der sie erzeugt hat.

Invoke-WithEcho führt einen Scriptblock aus und protokolliert vorab den Befehlstext — zusammen mit Typ und aktuellem Wert jeder Variablen, die der Block liest. In Kombination mit Start-Transcript wird so jede Zeile im Log ihrem Auslöser zuordenbar.

Die Auflösung liest die Variablen nur aus dem Scope des Aufrufers — nichts wird doppelt ausgeführt, keine Nebeneffekte. SecureStrings und Credentials erscheinen maskiert, die Rückgabe des Blocks läuft unverändert durch die Pipeline.

Install-Module InvokeWithEcho          # PowerShellGet
Install-PSResource InvokeWithEcho      # PSResourceGet

$sourcePath = 'C:\data\import'
$files = Invoke-WithEcho { Get-ChildItem $sourcePath -Filter *.csv }

# Echo-Ausgabe (landet auch im Transkript):
# >> Get-ChildItem $sourcePath -Filter *.csv
#    $sourcePath  String  1  C:\data\import

Start-Transcript deploy.log
Invoke-WithEcho { Copy-Item $source $target -Recurse }
Invoke-WithEcho { Restart-Service $serviceName }
Stop-Transcript
# deploy.log enthält jeden Befehl samt Werten — vor seiner Ausgabe

# Nur den Befehlstext protokollieren, ohne Variablenwerte
Invoke-WithEcho { Get-Content $configPath } -NoExpand

# Echo-Zeilen in eine Datei umlenken statt in die Konsole
$result = Invoke-WithEcho { Get-Process } 6> echo.log