Geek School Erfahren Sie, wie Sie Jobs in PowerShell verwenden

PowerShell verfügt über vier Arten von Jobs: Hintergrundjobs, Remotejobs, WMI-Jobs und geplante Jobs. Begleiten Sie uns, um herauszufinden, was sie sind und wie wir sie einsetzen können.

Lesen Sie unbedingt die vorherigen Artikel der Serie:

• Erfahren Sie, wie Sie Windows mit PowerShell automatisieren
• Verwenden von Cmdlets in PowerShell
• Informationen zum Verwenden von Objekten in PowerShell
• Lernen Sie das Formatieren, Filtern und Vergleichen in PowerShell
• Informationen zum Verwenden von Remoting in PowerShell
• Verwenden von PowerShell zum Abrufen von Computerinformationen
• Arbeiten mit Sammlungen in PowerShell

Und bleiben Sie die ganze Woche für den Rest der Serie dran.

Hintergrund-Jobs

Bisher war alles, was ich Ihnen in PowerShell gezeigt habe, synchron, was bedeutet, dass wir etwas in die Shell eingeben und erst dann wirklich viel tun können, wenn der Befehl ausgeführt wurde. Hier kommen Hintergrundjobs ins Spiel. Um einen Hintergrund zu starten, übergeben Sie einfach einen Skriptblock an das Cmdlet Start-Job.

Start-Job -Name GetFileList -Scriptblock Get-ChildItem C: \ -Recurse

Jetzt können wir innerhalb der Shell alles tun, was wir wollen, während der Skriptblock im Hintergrund ausgeführt wird.

Wenn Sie einen neuen Job starten, erstellt PowerShell ein neues Jobobjekt, das diesen Job darstellt. Sie können jederzeit eine Liste aller Jobs abrufen, indem Sie das Cmdlet Get-Job ausführen.

Die Jobobjekte informieren Sie über den Status der Jobs. Im obigen Screenshot können wir beispielsweise sehen, dass wir einen Hintergrundjob namens GetFileList haben, der noch ausgeführt wird, aber bereits Daten zurückgibt. Wenn Sie zu irgendeinem Zeitpunkt feststellen, dass der Job zu lange ausgeführt wurde, können Sie ihn leicht stoppen, indem Sie ihn an Stop-Job weiterleiten.

Get-Job -Name GetFileList | Stop-Job

Sobald Sie einen Job jedoch gestoppt haben, sind alle erhaltenen Daten bis zu dem Punkt, an dem Sie ihn angehalten haben, weiterhin verfügbar. Es gibt jedoch ein Problem. Wenn Sie in PowerShell die Ergebnisse für einen Job erhalten, werden diese gelöscht. Damit sie erhalten bleiben, müssen Sie den Keep-Switch-Parameter von Receive-Job angeben.

Get-Job -Name GetFileList | Receive-Job -Keep

Wenn Sie mit einem Job fertig sind, empfiehlt es sich, ihn zu entfernen. Um den Job zu entfernen, leiten Sie ihn einfach an das Cmdlet Remove-Job weiter.

Get-Job -Name GetFileList | Remove-Job

Dadurch wird es aus der Liste der von Get-Job zurückgegebenen Jobs entfernt.

Remote-Jobs

Vor ein paar Lektionen haben wir uns angesehen, wie wir Remoting verwenden können, um PowerShell-Befehle mit Invoke-Command auf einem Remote-Computer auszuführen. Fügen Sie dazu einfach den Parameter -AsJob am Ende Ihres Befehls hinzu:

Invoke-Command -ComputerName Flash, Viper -Verwalter des Administrator -ScriptBlock gci -AsJob

Dies war ein einfacher Befehl und sollte inzwischen abgeschlossen sein, also werfen wir einen Blick auf unseren Jobstatus.

Hmm, sieht aus wie es versagt hat Das bringt mich zu meinem ersten Job mit Jobs. Wenn Sie in PowerShell einen neuen Job eines beliebigen Typs erstellen, wird für jeden Computer, für den Sie den Job ausführen, zusätzlich zu einem untergeordneten Job ein übergeordneter Job erstellt. Wenn Sie das Cmdlet "Get-Job" verwenden, werden nur die übergeordneten Jobs angezeigt. Die State-Eigenschaft ist das ungünstigste Szenario. Dies bedeutet, dass der Befehl nur dann angezeigt wird, wenn der Befehl nur auf einem von hundert Computern ausgeführt wurde gescheitert. Um eine Liste untergeordneter Jobs anzuzeigen, müssen Sie den Parameter IncludeChildJob verwenden.

Wenn Sie genauer hinschauen, werden Sie feststellen, dass der Job tatsächlich nur an einem Computer fehlgeschlagen ist, was uns auf die nächste Frage bringt. Wenn Sie versuchen, die Ergebnisse für den Job abzurufen und den Jobnamen oder die ID des übergeordneten Objekts anzugeben, gibt PowerShell die Daten aller untergeordneten Jobs zurück. Das Problem ist, dass bei einem Fehler in einem der untergeordneten Jobs ein roter Text übrig bleibt.

Es gibt zwei Möglichkeiten, dies zu umgehen. Wenn Sie wissen, für welche Computer Sie die Ergebnisse wünschen, können Sie einfach den Parameter ComputerName des Cmdlets Recieve -Job verwenden.

Get-Job -Id 3 | Receive-Job -Keep -ComputerName Viper

Alternativ können Sie die Ergebnisse eines bestimmten untergeordneten Jobs anhand seiner Job-ID abrufen.

Get-Job -Id 3 -IncludeChildJob

Get-Job -Id 5 | Receive-Job -Keep

WMI-Jobs

WMI-Jobs sind im Wesentlichen mit Remote-Jobs identisch, sodass nur der Parameter -AsJob zum Cmdlet Get-WmiObject hinzugefügt werden muss.

Leider bedeutet dies, dass sie auch den gleichen gotchas unterliegen, die ich im Abschnitt Remote Jobs erwähnt habe.

Geplante Jobs

Die letzten drei Arten von Jobs, die wir uns angesehen haben, waren nicht dauerhaft. Dies bedeutet, dass sie nur in Ihrer aktuellen Sitzung verfügbar sind. Im Allgemeinen bedeutet dies, dass Sie keine Jobs sehen, wenn Sie einen Job starten, eine andere PowerShell Console öffnen und Get-Job ausführen. Wenn Sie jedoch zu der Konsole zurückkehren, von der aus Sie den Job gestartet haben, können Sie den Status sehen. Dies steht im Gegensatz zu geplanten Jobs sind hartnäckig. Grundsätzlich ist ein geplanter Job ein Skriptblock, der nach einem Zeitplan ausgeführt wird. In der Vergangenheit hätte derselbe Effekt mit dem Windows Task Scheduler erzielt werden können, was wirklich unter der Haube geschieht. Um einen neuen geplanten Job zu erstellen, führen wir folgende Schritte aus:

Register-ScheduledJob -Name GetEventLogs -ScriptBlock Get-EventLog -LogName-Sicherheit -Newest 100 -Trigger (New-JobTrigger -Daily-At 17:00 Uhr)

In diesem Befehl ist ziemlich viel los, also brechen wir es ab.

• Zuerst geben wir unserem Scheduled Job den Namen GetEventLogs.
• Dann sagen wir ihm, dass er ausgelöst werden soll, um den Inhalt des angegebenen Skriptblocks auszuführen, der im Wesentlichen die neuesten 100 Einträge des Sicherheitsereignisprotokolls abruft.
• Als Nächstes geben wir einen Auslöser an. Da für den Triggerparameter ein Triggerobjekt als Eingabe verwendet wird, wurde mit einem Befehl in Klammern ein Trigger generiert, der jeden Tag um 17.00 Uhr ausgelöst wird.
• Da es sich um das Ereignisprotokoll handelt, müssen wir als Administrator ausgeführt werden. Dies kann durch Erstellen eines neuen ScheduledJobOption-Objekts und Übergabe an den Parameter ScheduledJobOption festgelegt werden.

Da es sich hierbei um einen etwas anderen Jobtyp handelt, müssen Sie auch einen anderen Befehl verwenden, um eine Liste aller auf einem Computer geplanten Jobs abzurufen.

Get-ScheduledJob

Das ist alles dazu.