Wenn ihr per PowerShell Daten exportiert (zum Beispiel in eine CSV-Datei per Export-CSV
), dann werden die originalen Eigenschaftsnamen von den PowerShell Objekten verwendet. Wenn die aber nicht ganz passend für euren Zweck sind, dann könnt ihr sie auch anpassen. Dafür können sogenannte “Calculcated Properties” und das Cmdlet Select-Object
verwendet werden.
Damit können zum Beispiel:
- Eigenschaften umbenannt werden
- Eigenschaftswerte formatiert werden
- Komplett eigene Eigenschaften erzeugt werden (z.B. durch den Aufruf zusätzlicher Cmdlets)
Ich habe zu diesem Thema auch ein Video auf meinem YouTube Kanal veröffentlicht.
Objekte normal ausgeben
Zur Erinnerung: Die Auswahl von Objekteigenschaften bei Select-Object
ist mit dem Parameter -Property
möglich. Wobei der Parameter in der Regel auch nicht explizit benannt werden muss.
|
|
Eigenschaft umbenennen
Um eine Eigenschaft umzubennen, müssen wir eine Hashtable statt eines einfachen Parameternamens angeben. Die Hashtable hat zwei Einträge:
Bezeichner | Bedeutung |
---|---|
Name (oder Label ) | Name der neuen Eigenschaft |
Expression | Scriptblock, der den Wert erzeugt |
Beispielsweise um die Eigenschaft “Dienstname” zu erzeugen, die den Namen eines Windows Dienstes enthält:
|
|
Zusätzlich können normale Parameter auch verwendet werden. In diesem Beispiel habe ich auch noch die Eigenschaft “Status” mit ausgegeben.
String Eigenschaft formatieren / mehrere Eigenschaften zusammenfassen
Aber wir können Eigenschaften nicht nur umbenennen, sondern auch beliebig formatieren. Zum Beispiel, wenn ich möchte, dass in einer Eigenschaft sowohl der Anzeigename, als auch der interne Name eines Windows Dienstes angezeigt wird.
|
|
If-Abfrage einbauen
Es ist auch möglich, Logik mit einer If-Abfrage zu integrieren. Zum Beispiel wird hier geprüft, ob ein Active Directory User Mitglied in einer Sicherheitsgruppe ist, die dem Wildcard Muster *VIP-User*
entspricht. Falls dem so ist, wird “Ja” in die neue Eigenschaft “VIP” hineingeschrieben. Falls nicht, wird stattdessen “Nein” hineingeschrieben.
|
|
Zusätzliche Cmdlets verwenden
Abgesehen von If-Abfragen können wir auch ganze Cmdlets verwenden, um zusätzliche Informationen abzufragen.
In diesem Beispiel verwende ich erstmal Get-ADUser
, um alle User in einer Organisationseinheit im Active Directory aufzulisten. Anschließend möchte ich den jeweiligen Manager (Vorgesetzten) von den Usern auflisten.
|
|
Im Standard wird uns hier der “Distinguished Name” (DN) des Managers aufgelistet. Nicht besonders ansehlich. Aber wir können in der Expression für die Calculated Property ein weiteres mal Get-ADUser
ausführen, um Infos zu dem Manager zu erhalten.
|
|
In diesem Beispiel habe ich die Expression auch auf mehrere Zeilen aufgeteilt. Das ist problemlos möglich, da sie eindeutig erkennbar mit {
geschweiften Klammern}
umschlossen ist.
Übrigens: Falls ihr in der Konsole arbeitet, könnt ihr auch [Umschalt] + [Enter]
drücken, um in einer neuen Zeile weiter zu schreiben, ohne den Befehl bereits auszuführen.
Array zu String umwandeln
Falls ihr eine Objekteigenschaft exportieren wollt, die aus einem Array besteht, funktioniert der Export normalerweise nicht so gut. In der Konsole sind die Werte in der Array-Eigenschaft mit {
geschweiften Klammern}
umschlossen. Zum Beispiel frage ich hier alle Domain Controller in meinem Active Directory ab und lasse die FSMO-Rollen auflisten.
|
|
In meiner Konsole wurde die Ausgabe sogar ein bisschen abgeschnitten, sodass ich gar nicht alle Rollen sehe. Wenn ich versuche ein derartiges Array per Export-CSV
zu exportieren, ist das Ergebnis im Standard komplett unbrauchbar:
|
|
Das Array wurde also nicht zu einem String umgewandelt, sondern stattdessen steht dort Microsoft.ActiveDirectory.Management.ADPropertyValueCollection
.
Die Lösung: Calculated Properties und der -join
Operator. Im folgenden Beispiel werden die Einträge im Array zu einem String zusammengeführt und jeweils mit einem Leerzeichen und Komma getrennt (,
).
|
|
Weitere Tipps und Hinweise
Hier noch ein paar allgemeine Tipps und Hinweise zu Calculated Properties.
Name VS. Label
Vielleicht ist euch im vorherigen Beispiel aufgefallen, dass ich auf einmal @{Label=
statt @{Name=
in der Hashtable verwendet habe. Tatsächlich sind hier Name
und Label
beliebig miteinander austauschbar. Es geht beides, macht keinen Unterschied.
|
|
Lesbarkeit erhöhen mit Hashtable Splatting
Im Abschnitt “Zusätzliche Cmdlets verwenden” hatte ich ja den Expression Scriptblock auch schon mal aufgeteilt auf mehrere Zeilen. Eine weitere Möglichkeit die Lesbarkeit zu erhöhen ist das Splatting. Dabei werden die Cmdlet Parameter in eine Hashtable geschrieben.
Im folgenden Beispiel habe ich die Hashtable-Variable für die Formatierung der Einfachheit halber auch $Formatierung
genannt. Der Name ist aber natürlich frei wählbar. In der Hashtable gibt es dann den Key Property
, der wiederum ein Array ist. In diesem Array müssen die Properties stehen, die ausgegeben werden sollen. Ich habe hier zwei weitere Hashtables verwendet (Calculated Properties) und einen String (normale Property vom Objekt).
|
|
Kurzform der Hashtable Namen erlaubt
Statt der vollständig ausgeschriebenen Hashtable-Keys Name
/Label
und Expression
können auch die Kurzschreibweisen N
,L
und E
verwendet werden.
|
|
Das Label ist eigentlich optional
Tatsächlich ist das Label beziehungsweise der Name optional. Es wäre auch möglich keine Hashtable zu verwenden, sondern einfach nur einen Scriptblock für die Calculated Property anzugeben. In dem Fall erhält die Calculated Property aber den ScriptBlock als Namen, was komisch aussieht. Ich würde das nicht empfehlen.
|
|