Beachten Sie die Funktionslücken im PowerShell Open Source-Projekt

Obwohl der aktuellen Version des PowerShell-Open-Source-Projekts ein Großteil der Funktionen von Windows PowerShell fehlt, können Administratoren diese Lücken mit einigen Anpassungen schließen.

Microsoft hat im Januar 2018 die erste Version seiner plattformübergreifenden Open Source-Version von PowerShell veröffentlicht. Diese Version heißt offiziell PowerShell Core 6.0ist kein direkter Austausch für Windows PowerShell 5.1, obwohl es aus der 5.1-Codebasis stammt und für die Verwendung unter Windows, vielen Linux-Distributionen und MacOS angepasst ist.

Der Hauptunterschied besteht darin, dass Windows PowerShell 5.1 und frühere Versionen unter dem vollständigen .NET Framework für Windows ausgeführt werden, während das Open Source-Projekt PowerShell auf .NET Core basiert, das keinen Zugriff auf dieselben .NET-Klassen hat.

Unterschiede zwischen Windows PowerShell und PowerShell Core

Viele PowerShell 5.1-Funktionen sind in PowerShell Core 6 nicht verfügbar, einschließlich der integrierten Skriptumgebung (ISE), PowerShell-Workflows, WMI-Cmdlets (Windows Management Instrumentation), Cmdlets für Ereignisprotokolle, Cmdlets für Leistungsindikatoren, Cmdlets für Leistungsindikatoren und des Pester-Moduls.
Der Grosse Sammlung von PowerShell-Modulen Diese Funktionen, die mit Windows PowerShell funktionieren, sind in PowerShell Core 6 nicht verfügbar. Jedes binäre PowerShell-Modul, das mit dem vollständigen .NET Framework kompiliert wurde, funktioniert im PowerShell-Open Source-Projekt nicht, einschließlich des Active Directory-Moduls und des Exchange-Moduls.

Die große Sammlung von PowerShell-Modulen, die mit Windows PowerShell funktionieren, ist in PowerShell Core 6 nicht verfügbar.

PowerShell Core 6 bietet einige nützliche Funktionen. Die erste ist die Möglichkeit, Linux- und MacOS-Systeme mit PowerShell zu verwalten. Die Tiefe von Cmdlets für Windows-Systeme ist auf Nicht-Windows-Plattformen nicht verfügbar, aber die PowerShell-Community füllt diese Lücken möglicherweise in der PowerShell-Galerie.
Zweitens führte PowerShell 6 das Remoting über Secure Socket Shell (SSH) ein, im Gegensatz zum Remoting mit dem Web Services-Management-Protokoll. Dies ermöglicht das Remoting von und zu Linux-Systemen und bietet eine einfache Möglichkeit zum Remote-Zugriff auf und von Windows-Computern außerhalb der Domäne.
Das Installieren und Konfigurieren von SSH unter Windows wird immer einfacher, und die Aufnahme von SSH als optionale Funktion in die neuesten Windows 10- und Windows Server-Vorschauen wird hoffentlich zu einem einfacheren Remoting-Installations- und Konfigurationsprozess führen.

Überwindung von Funktionshindernissen

Sie können einige der fehlenden Funktionen in PowerShell Core 6 beheben, beginnend mit der ISE. Verwenden Sie zum Entwickeln von Skripten Visual Studio (VS) -Code anstelle von ISE. VS Code ist ein Open Source-Editor, der unter Windows, Linux und macOS ausgeführt wird. VS Code verwendet Windows PowerShell oder PowerShell Core im integrierten Terminal, wenn beide installiert sind.
PowerShell-Workflows, mit denen Funktionen gleichzeitig auf mehreren Computern ausgeführt werden können, werden niemals Teil von PowerShell Core sein, da diese Funktion schwer zu implementieren ist. Stattdessen können Sie PowerShell-Runspaces verwenden, um eine parallele Verarbeitung bereitzustellen. Obwohl sie nicht einfach zu codieren sind, gibt es einen Vorschlag zum Erstellen von Cmdlets zum Verwalten von Runspaces.
Ein Beispiel für einen einfachen PowerShell-Workflow ist:
Workflow-Test1 {
parallel {
Get-CimInstance -ClassName Win32_OperatingSystem
Get-CimInstance -ClassName Win32_ComputerSystem
}}
}}
test1
Abbildung 1 zeigt die Ergebnisse dieses Skripts.

PowerShell-Workflow
Abbildung 1. Ausführen eines Workflows unter Windows PowerShell 5.1 in der PowerShell Integrated Scripting-Umgebung

Das Emulieren eines PowerShell-Workflows mit Runspaces führt zu folgendem Code:
## Runspace-Pool mit min = 1 und max = 5 Runspaces erstellen
$ rp = [runspacefactory]:: CreateRunspacePool (1,5)
## Powershell erstellen und mit dem Runspace-Pool verknüpfen
$ ps = [powershell]::Erstellen()
$ ps.RunspacePool = $ rp
$ rp.Open ()
$ cmds = New-Object -TypeName System.Collections.ArrayList
1..2 | ForEach-Object {
$ dog = [powershell]::Erstellen()
$ psa.RunspacePool = $ rp
if ($ _ -eq 1) {
[void]$ dog.AddScript ({
Get-CimInstance -ClassName Win32_OperatingSystem
})
} else {
[void]$ dog.AddScript ({
Get-CimInstance -ClassName Win32_ComputerSystem
})
}}
$ handle = $ psa.BeginInvoke ()
$ temp = ” | Select-Object PowerShell, Handle
$ temp.PowerShell = $ psa
$ temp.Handle = $ handle
[void]$ cmds.Add ($ temp)
}}

## Fortschritt anzeigen
$ cmds | Select-Object -ExpandProperty-Handle
## Daten abrufen
$ cmds | ForEach-Object {$ _. PowerShell.EndInvoke ($ _. Handle)}
## Aufräumen
$ cmds | ForEach-Object {$ _. PowerShell.Dispose ()}
$ rp.Close ()
$ rp.Dispose ()
Abbildung 2 zeigt diesen Code, der unter PowerShell Core 6 im VS-Code-Editor ausgeführt wird.

PowerShell-Runspaces in VS-Code
Abbildung 2. Ausführen von Code mit Runspaces in PowerShell Core 6 im VS-Code-Editor.

Runspaces-Code funktioniert in Windows PowerShell 5.1 und PowerShell Core 6. Administratoren können Runspaces auch mit dem PoshRSjob-Modul aus der PowerShell-Galerie vereinfachen. Die neueste Version funktioniert in PowerShell Core 6 unter Linux und Windows.
Die Entwickler des Open Source-Projektprojekts PowerShell planen, fehlende WMI-, Ereignisprotokoll- und Leistungs-Cmdlets zum Windows Compatibility Pack für .NET Core hinzuzufügen. WMI-Cmdlets werden zugunsten der Cmdlets effektiv abgelehnt Common Information Model (CIM) Cmdlets, die in PowerShell Core 6 und Windows PowerShell 3 und höher verfügbar sind.

Anzeigen der plattformübergreifenden Leistung von PowerShell Core
Fähigkeiten

Ereignisprotokoll-Cmdlets funktionieren nur mit den herkömmlichen Ereignisprotokollen. Wenn Sie mit den neuen Anwendungs- und Dienstprotokollen arbeiten müssen, müssen Sie das Cmdlet Get-WinEvent verwenden, das auch mit den Protokollen des alten Stils funktioniert.
Der folgende Befehl verwendet das ältere Cmdlet Get-EventLog:
Get-EventLog -LogName System -Newest 5
Es ist einfach genug, zum Cmdlet Get-WinEvent zu wechseln, um ähnliche Ergebnisse zu erzielen:
Get-WinEvent -LogName System -MaxEvents 5
Das Cmdlet Get-WinEvent kann klassische Ereignisprotokolle nicht löschen, einschränken, schreiben oder erstellen / entfernen. Sie können jedoch Ereignisprotokolle mithilfe der Eigenschaften und Methoden für die zurückgegebenen Objekte konfigurieren.
Get-WinEvent -ListLog *
In Windows PowerShell 5.1 können Sie den folgenden Befehl ausführen, um auf Leistungsindikatoren zuzugreifen:
Get-Counter -Counter ‘ Prozessor
% Prozessorzeit ‘
Dies erzeugt die folgende Ausgabe:
Timestamp CounterSamples
——— ————–
31/03/2018 15:18:34 \ w510w10 Prozessor (0) % Prozessorzeit:
1,56703775955929

\ w510w10 Prozessor (1) % Prozessorzeit:
0,00460978748879626

\ w510w10 Prozessor (2) % Prozessorzeit:
1,56703775955929

\ w510w10 Prozessor (3) % Prozessorzeit:
0,00460978748879626

\ w510w10 Prozessor (4) % Prozessorzeit:
0,00460978748879626

\ w510w10 Prozessor (5) % Prozessorzeit:
4.69189370370026

\ w510w10 Prozessor (6) % Prozessorzeit:
3.12946573162978

\ w510w10 Prozessor (7) % Prozessorzeit:
0,00460978748879626

\ w510w10 Prozessor (_Total) % Prozessorzeit:
1.37173676293523
Die alternative Möglichkeit, Leistungsindikatordaten zurückzugeben, besteht in CIM-Klassen, die in Windows PowerShell 5.1 und PowerShell Core 6 funktionieren:
Get-CimInstance -ClassName Win32_PerfFormattedData_PerfOS_Processor | Wählen Sie Name, PercentProcessorTime

Nennen Sie PercentProcessorTime
—- ——————–
_Gesamt 13
0 50
1 0
2 0
3 43
4 6
5 6
6 0
7 0
PowerShell Core 6 kann auf viele der älteren PowerShell-Module zugreifen, z. B. auf die Netzwerk- oder Speichermodule, die unter Windows 8 oder Windows Server 2012 verfügbar sind. Fügen Sie dazu den folgenden Eintrag in Ihrem Profil zum Ordner Windows PowerShell 5.1-Module hinzu:
$ env: PSModulePath = $ env: PSModulePath +; C: Windows System32 WindowsPowerShell v1.0 Modules ‘
Eine andere Möglichkeit besteht darin, das Modul direkt zu importieren.
Import-Modul C: Windows System32 WindowsPowerShell v1.0 Module NetAdapter NetAdapter.psd1
Get-NetAdapter

Name ifIndex Status MacAddress LinkSpeed
—- ——- —— ———- ———
vEthernet (nat) 16 Up 00-15-5D-82-CF-92 10 Gbit / s
vEthernet (DockerNAT) 20 Up 00-15-5D-36-C9-37 10 Gbit / s
vEthernet (Standard-Swi … 9 Up 2E-15-00-2B-41-72 10 Gbit / s
vEthernet (Wireless) 22 Up F0-7B-CB-A4-30-9C 144,5 Mbit / s
vEthernet (LAN) 12 Up 00-15-5D-36-C9-11 10 Gbit / s
Netzwerkbrücke 24 bis F0-7B-CB-A4-30-9C 144,5 Mbit / s
LAN 14 getrennt F0-DE-F1-00-3F-67 0 bps
Drahtlos 8 bis F0-7B-CB-A4-30-9C 144,5 Mbit / s Bei Binärmodulen wie Active Directory müssen Sie bei Verwendung der Open Source-Version von PowerShell auf Skripts zurückgreifen. Wenn du möchtest Linux verwalten

Auf Computern, die PowerShell Core 6 verwenden, müssen Sie viel Skripte erstellen oder darauf warten, dass die Community die Funktionen erstellt.

Similar Posts

Leave a Reply