In PowerShell gibt es vier Arten von Jobs: Hintergrundjobs, Remote-Jobs, WMI-Jobs und Geplante Jobs. Machen Sie mit, wenn wir herausfinden, was sie sind und wie wir sie verwenden können.
Lesen Sie unbedingt die vorherigen Artikel in der Reihe:
- Erfahren Sie, wie Sie Windows mit PowerShell automatisieren
- Lernen, Cmdlets in PowerShell zu verwenden
- Erlernen der Verwendung von Objekten in PowerShell
- Lernen des Formatierens, Filterns und Vergleichens in PowerShell
- Erfahren Sie, wie Sie Remoting in PowerShell verwenden
- Verwenden von PowerShell zum Abrufen von Computerinformationen
- Arbeiten mit Sammlungen in PowerShell
Und bleiben Sie für den Rest der Serie die ganze Woche dran.
Hintergrund-Jobs
Bis jetzt alles, was ich dir gezeigt habePowerShell war synchron, was bedeutet, dass wir etwas in die Shell eingeben und nicht viel tun können, bis dieser Befehl ausgeführt wurde. Hier kommen Hintergrundjobs ins Spiel. Um einen Hintergrundjob 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 in der Shell tun, was wir wollen, während dieser 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 derArbeitsplätze. Im obigen Screenshot sehen wir beispielsweise, dass wir einen BackgroundJob namens GetFileList haben, der noch ausgeführt wird, aber bereits Daten zurückgibt. Wenn Sie zu einem bestimmten Zeitpunkt feststellen, dass der Job zu lange ausgeführt wurde, können Sie ihn einfach stoppen, indem Sie ihn an Stop-Job weiterleiten.
Get-Job –Name GetFileList | Stop-Job
Sobald Sie jedoch einen Job beendet haben, was auch immerDaten, die es empfangen hat, bis Sie es gestoppt haben, sind noch verfügbar. Es gibt jedoch eine GOTCHA. Sobald Sie in PowerShell die Ergebnisse für einen Auftrag erhalten, werden diese gelöscht. Damit sie erhalten bleiben, müssen Sie den Parameter keep switch von Receive-Job angeben.
Get-Job –Name GetFileList | Receive-Job - Keep
Wenn Sie mit einem Job fertig sind, sollten Sie ihn am besten entfernen. Um den Job zu entfernen, leiten Sie ihn einfach an das Cmdlet Remove-Job weiter.
Get-Job –Name GetFileList | Job entfernen
Dadurch wird es aus der Liste der Jobs entfernt, die von Get-Job zurückgegeben werden.
Remote-Jobs
Vor ein paar Stunden haben wir uns angesehen, wie wir es nutzen könnenRemote-Ausführung von PowerShell-Befehlen auf einem Remote-Computer mit Invoke-Command. Wussten Sie jedoch, dass Sie Invoke-Command auch zum Starten eines Remote-Auftrags im Hintergrund verwenden können? Fügen Sie dazu einfach den Parameter –AsJob am Ende Ihres Befehls hinzu:
Rufen Sie den Befehl -ComputerName Flash, Viper -Credential Administrator -ScriptBlock {gci} –AsJob auf
Das war ein einfacher Befehl und sollte nun abgeschlossen sein. Werfen wir einen Blick auf unseren Auftragsstatus.
Hmm, sieht aus wie es fehlgeschlagen ist. Dies bringt mich zu meinem ersten Fall mit Jobs. Wenn Sie in PowerShell einen neuen Auftrag eines beliebigen Typs erstellen, wird für jeden Computer, auf dem Sie den Auftrag ausführen, zusätzlich zu einem untergeordneten Auftrag ein übergeordneter Auftrag erstellt. Wenn Sie das Cmdlet Get-Job verwenden, werden nur die übergeordneten Jobs angezeigt, und die Eigenschaft state ist das Worst-Case-Szenario. Selbst wenn der Befehl auf einem von hundert Computern nicht ausgeführt werden konnte, wird im Status der übergeordneten Jobs der Status angegeben gescheitert. Um eine Liste der untergeordneten Jobs anzuzeigen, müssen Sie den Parameter IncludeChildJob verwenden.
Wenn Sie genauer hinschauen, werden Sie feststellen, dass der Job ausgeführt wurdein der Tat scheitern nur auf einem Computer, was uns auf den nächsten Gotcha bringt. Wenn Sie versuchen, die Ergebnisse für den Job abzurufen, und Sie den Jobnamen oder die ID des übergeordneten Jobs angeben, gibt PowerShell die Daten aller untergeordneten Jobs zurück. Das Problem ist, dass bei einem Fehler in einem der untergeordneten Jobs ein roter Text verbleibt.
Es gibt zwei Möglichkeiten, dies zu umgehen. Wenn Sie zunächst wissen, für welche Computer die Ergebnisse angezeigt werden sollen, 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 weitgehend mit Remote-Jobs identisch, sodass nur der Parameter –AsJob zum Cmdlet Get-WmiObject hinzugefügt werden muss.
Leider bedeutet dies auch, dass sie denselben Fallstricken unterliegen, die ich im Abschnitt Remote-Jobs erwähnt habe.
Geplante Jobs
Die letzten drei Arten von Jobs, die wir uns angesehen haben, warennicht persistent, was bedeutet, dass sie nur in Ihrer aktuellen Sitzung verfügbar sind. Grundsätzlich bedeutet dies, dass Sie keine Jobs sehen, wenn Sie einen Job starten und dann eine andere PowerShell-Konsole öffnen und Get-Job ausführen. Wenn Sie jedoch zu der Konsole zurückkehren, von der aus Sie den Auftrag gestartet haben, können Sie den Status anzeigen. Dies steht im Gegensatz zu geplanten Jobs, die sind hartnäckig. Grundsätzlich ist ein geplanter Job ein Skriptblockdas läuft nach einem zeitplan. In der Vergangenheit konnte derselbe Effekt mit dem Windows-Taskplaner erzielt werden, was tatsächlich unter der Haube passiert. Um einen neuen geplanten Job zu erstellen, gehen Sie wie folgt vor:
Register-ScheduledJob -Name GetEventLogs -ScriptBlock {Get-EventLog -LogName Security -Newest 100} -Trigger (New-JobTrigger -Daily -At 5pm) -ScheduledJobOption (New-ScheduledJobOption -RunElevated)
In diesem Befehl ist ziemlich viel los.
- Zunächst geben wir unserem geplanten Job den Namen GetEventLogs.
- Wir teilen ihm dann mit, dass er beim Auslösen den Inhalt des angegebenen Skriptblocks ausführen soll, der im Grunde die neuesten 100 Einträge des Sicherheitsereignisprotokolls erhält.
- Als nächstes geben wir einen Trigger an. Da der Trigger-Parameter ein Trigger-Objekt als Eingabe verwendet, haben wir einen Befehl in Klammern verwendet, um einen Trigger zu generieren, 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, den wir angeben können, indem Sie ein neues ScheduledJobOption-Objekt erstellen und an den ScheduledJobOption-Parameter übergeben.
Da dies ein etwas anderer Auftragstyp ist, müssen Sie auch einen anderen Befehl verwenden, um eine Liste aller geplanten Aufträge auf einem Computer abzurufen.
Get-ScheduledJob
Das ist alles dazu.
