Inhaltsverzeichnis:
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}
Get-Job –Name GetFileList | Stop-Job
Get-Job –Name GetFileList | Receive-Job –Keep
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 mithilfe von Invoke-Command mithilfe von Remoting PowerShell-Befehle auf einer Remote-Maschine ausführen können. Wussten Sie jedoch, dass Sie mit Invoke-Command auch einen Remoting-Job im Hintergrund starten können? Fügen Sie dazu einfach den Parameter –AsJob am Ende Ihres Befehls hinzu:
Invoke-Command -ComputerName Flash,Viper -Credential administrator -ScriptBlock {gci} –AsJob
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
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.
Geplante Jobs
Die letzten drei Arten von Jobs, die wir uns angesehen haben, waren nicht dauerhaft, dh sie sind nur in Ihrer aktuellen Sitzung verfügbar. 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 Security -Newest 100} -Trigger (New-JobTrigger -Daily -At 5pm) -ScheduledJobOption (New-ScheduledJobOption -RunElevated)
In diesem Befehl ist ziemlich viel los, also brechen wir ihn auf.
- Zuerst geben wir unserem Scheduled Job den Namen GetEventLogs.
- Wir sagen dann, dass wir bei einer Auslösung den Inhalt des angegebenen Skriptblocks ausführen sollen, 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.
Get-ScheduledJob
