Blog-Kategorie
Data Center

Hier bloggen sepago Experten über: Data Center

| |

PowerShell: Die Param Anweisung, Erweiterte Parameterdefinition (Advanced Parameters) – Part 15.2

4.1.4  Die Param  Anweisung

Die Definition von Parametern für Skripte muss etwas anders funktionieren, als für die Funktionen, da bei einem Skript die Möglichkeit fehlt, die Parameter in Klammern irgendwo einzugeben. Geschähe das einfach am Anfang des Skriptes, wäre das nicht eindeutig und könnte nicht interpretiert werden, da die Definition von Parametern optional ist. In Skripten wird deshalb für die Parameterdefinition die Param Anweisung verwendet. Es muss der erste Befehl in einem Skript sein (davor sind lediglich Kommentare erlaubt).

| |

PowerShell: Response is slow after each command on command line: get-childitem, start a script, dir, etc.

From one day to another I got some „affects” using PowerShell. I got a delay of 6 seconds after each command I executed. Also for starting a script. For example:

Get-ChildItem

(delay of 6 seconds)

<directory>

I used Microsofts Process Monitor (https://technet.microsoft.com/de-de/sysinternals/processmonitor.aspx) to find the reason. Here is my result:

Accessing the history file in „%AppData%\Microsoft\Windows\PowerShell\PSReadline“ causes this delay (for whatever reason).

| |

PowerShell: Typisierung von Parametern, Initialisierung von Parametern, Switchparameter – Part 15.1

4.1.1 Typisierung von Parametern

Die Definition von Parametern innerhalb einer Funktion kann im einfachsten Fall ohne Angabe eines Datentyps erfolgen. In vielen Fällen ist das auch völlig ausreichend. Hin und wieder ist es jedoch sinnvoll, einen bestimmten Datentyp eines Parameters zu erzwingen. Besonders dann, wenn an diesem Parameter innerhalb der Funktion Operationen durchgeführt werden, welche nur mit einem bestimmten Datentyp funktionieren oder sinnvolle Ergebnisse ergeben und der Typ des übergebenen Arguments nicht in den erwarteten Datentyp konvertiert werden kann (was die PowerShell selbständig versuchen würde).

| |

PowerShell: Skripte, Funktionen und Skriptblöcke (Parameter und Argumente) – Part 15

4.1 Parameter und Argumente

Ohne die Möglichkeit, Argumente an Funktionen und Skripte zu übergeben, wäre der Nutzen solcher sehr gering. Die Übergabe von Argumenten funktioniert bei Funktionen und Skripten gleich, daher werden die Zusammenhänge vorerst anhand von Funktionen erklärt.
Im ersten Schritt soll die informelle Argumentenübergabe (positional parameters) behandelt werden. Alle Argumente, die an eine Funktion übergeben werden, werden in einem Array Namens $Args gespeichert. Über den Ausdruck $Args.Count innerhalb der Funktion kann die Anzahl der übergebenen Argumente ermittelt werden.

| |

Last Logon Time / Authentication of a AD or Service User Account – #Powershell

Sometimes it is helpful to know when an AD user or an AD function account has been authenticated the last time. After some failed attempts with „LastLogonDate“ I found the correct value in the „LastLogon“ property. This value is not replicated between the domain controllers. In addition, it is a not a readable date (it’s in ticks).

The following script determines the latest authentication of an account on all domain controller in a domain (one-liner):

1

([DateTime][long]($(ForEach ($dc in ((get-addomaincontroller -filter *).name)){(Get-ADUser -Identity „<userlogonname>“ -Properties „LastLogon“ -server $dc).LastLogon}) | Measure -Maximum).Maximum).AddYears(1600)

Or somewhat clearer:

1
2
3
4
5
6

([DateTime][long](
    $(ForEach ($dc in ((get-addomaincontroller -filter *).name))
    {
        (Get-ADUser -Identity „<userlogonname>“ -Properties „LastLogon“ -server $dc).LastLogon
    }
) | Measure -Maximum).Maximum).AddYears(1600)

Sample:

See also:

Christopher Ream – Understanding the AD Account attributes – LastLogon,

| |

Letztes Anmeldedatum/Authentifizierung eines AD- oder Service Benutzers #Powershell

Manchmal ist es hilfreich zu wissen, wann ein AD-Benutzer oder Funktionsaccount das letzte Mal authentifiziert wurde. Nach einigen Fehlversuchen mit  „LastLogonDate“ habe ich mit „LastLogon“ den richtigen Wert gefunden. Dieser Wert wird allerdings nicht zwischen den Domain Controllern repliziert. Zusätzlich liegt er nummerisch vor (Ticks).

Das folgende Skript ermittelt die aktuellste Authentifizierung über alle Domänen Controller einer Domäne hinweg (als Einzeiler):

1

([DateTime][long]($(ForEach ($dc in ((get-addomaincontroller -filter *).name)){(Get-ADUser -Identity „<userlogonname>“ -Properties „LastLogon“ -server $dc).LastLogon}) | Measure -Maximum).Maximum).AddYears(1600)

Oder etwas übersichtlicher:

1
2
3
4
5
6

([DateTime][long](
    $(ForEach ($dc in ((get-addomaincontroller -filter *).name))
    {
        (Get-ADUser -Identity „<userlogonname>“ -Properties „LastLogon“ -server $dc).LastLogon
    }
) | Measure -Maximum).Maximum).AddYears(1600)

Beispiel:

Siehe auch:

Christopher Ream –

| |

PowerShell: Skripte, Funktionen und Skriptblöcke (Einführung) – Part 14

4 Skripte, Funktionen und Skriptblöcke (Einführung)

Skripte sind die „Programme“, die in der PowerShell „Sprache“ geschrieben werden. Sie können beliebig komplex und fast beliebig lang sein. Skripte können beliebige Folgen von PowerShell Befehlen beinhalten, Variablen, Funktionen, Drives, etc. definieren. Sie können auch externe Parameter aufnehmen und verarbeiten, wodurch sie wesentlich an Flexibilität gewinnen. Im Normalfall laufen Skripte in einem eigenen Scope. Das bedeutet, dass alle Elemente wie Variablen, Funktionen, Drives, etc., welche innerhalb eines Skriptes,

| |

PowerShell: Preference und Error Variable, Fehlerbehandlung – Part 13

3.12 Die Preference Variablen

Die sogenannten Preference Variablen (sozusagen, die Einstellungen für die Shell) beeinflussen das Verhalten der Shell. Sie können vom Benutzer in der laufenden Shell verändert oder fest über ein Profil eingestellt werden. Auch aus einem Skript heraus können diese Variablen verändert werden (Scope beachten). Einige von den Preference Variablen definieren auch das Verhalten von sogenannten „Common Parameters“ (siehe about_Common Parameters), welche mit fast jedem Cmdlet verwendet werden können. Detailliert werden diese Variablen und auch die möglichen Werte in dem Hilfethema About_Preference_Variables beschrieben.

| |

Powershell: PSCustomObject / PSObject Arrays

Für ein IoT Projekt lese ich Schalterzustände einer Web-Relay-Box aus (8 Relais mit eigener Bezeichnung, die per http an- und ausgeschaltet werden können): Kanal, Beschriftung und Zustand. Die Zustände lese ich in einem Azure Web Job mit C# aus und speichere diese in einem Array einer erstellten Klasse.

Mit PowerShell lese ich die Zustände zusätzlich aus (für ein Administrationstool). Das Speichern der Zustände in einem Array ging mir nicht so leicht von der Hand.

| |

PowerShell: Die Shell – Part 12

3.11 Die Shell

Wie ist die Shell sonst so?

Die optische Ähnlichkeit mit der CMD Shell ist wohl eine der wenigen Gemeinsamkeiten. Die PowerShell kennt das sogenannte Tab-Completition (Vervollständigung) nicht nur auf dem Drive Filesystem und nicht nur in Bezug auf die unmittelbaren Inhalte der aktuellen Location, sondern auch in Bezug auf alle Cmd-lets und alle PSDrives simultan. Drücken der Taste TAB nach der Eingabe des ersten Buchstabens eines existierenden Objekts oder Cmdlets verändert die Eingabezeile ab der ersten Cursorposition in das zuerst gefundene Element einer Trefferliste,