Geek School Leer hoe je banen in PowerShell gebruikt

PowerShell heeft vier soorten taken: achtergrondtaken, externe taken, WMI-taken en geplande taken. Doe met ons mee als we ontdekken wat ze zijn en hoe we ze kunnen gebruiken.

Zorg ervoor dat u de vorige artikelen in de serie leest:

• Leer hoe u Windows kunt automatiseren met PowerShell
• Leren gebruik te maken van cmdlets in PowerShell
• Leren hoe objecten in PowerShell te gebruiken
• Leren opmaken, filteren en vergelijken in PowerShell
• Leer hoe u Remoting kunt gebruiken in PowerShell
• PowerShell gebruiken om computerinformatie te verkrijgen
• Werken met collecties in PowerShell

En blijf op de hoogte voor de rest van de serie de hele week.

Achtergrond banen

Tot nu toe is alles wat ik je binnen PowerShell heb laten zien synchroon, wat betekent dat we iets in de shell typen en niet echt veel kunnen doen totdat die opdracht is voltooid. Dit is waar achtergrondopdrachten binnenkomen. Om een ​​achtergrond te starten, geeft een taak simpelweg een scriptblok door aan de cmdlet Start Job.

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

Nu zijn we vrij om te doen wat we willen in de shell, terwijl dat scriptblok op de achtergrond wordt uitgevoerd.

Wanneer u een nieuwe taak start, maakt PowerShell een nieuw taakobject dat voor die taak staat. U kunt op elk gewenst moment een lijst met alle taken krijgen door de cmdlet Get-Job uit te voeren.

De taakobjecten vertellen u over de status van de taken. In de bovenstaande schermafbeelding kunnen we bijvoorbeeld zien dat we een BackgroundJob hebben genaamd GetFileList die nog steeds actief is, maar al is begonnen met het retourneren van gegevens. Als u op enig moment besluit dat de taak te lang heeft geduurd, kunt u deze eenvoudig stoppen door deze naar Stop-Job te leiden.

Get-Job -Name GetFileList | Stop-Job

Zodra u echter een taak hebt stopgezet, is de gegevens die u hebt ontvangen tot het moment dat u bent gestopt nog steeds beschikbaar. Er is echter een gotcha. In PowerShell worden ze verwijderd zodra u de resultaten voor een taak ontvangt. Om ervoor te zorgen dat ze blijven, moet u de parameter voor de keep-switch van Receive-Job opgeven.

Get-Job -Name GetFileList | Ontvangst-opdracht-hou

Als je klaar bent met een baan, is het het beste om het te verwijderen. Om de taak te verwijderen, hoeft u deze alleen maar naar de cmdlet Remove Job te pipen.

Get-Job -Name GetFileList | Verwijder-Job

Hiermee wordt het verwijderd uit de lijst met taken die worden geretourneerd door Get-Job.

Externe opdrachten

Een paar lessen geleden hebben we gekeken hoe we remoting kunnen gebruiken om PowerShell-opdrachten uit te voeren op een externe machine met behulp van Invoke-Command, maar wist je dat je Invoke-Command ook kunt gebruiken om een ​​remoting-taak op de achtergrond te starten? Om dit te doen, voegt u eenvoudig de parameter -AsJob toe aan het einde van uw opdracht:

Invoke-Command -ComputerName Flash, Viper -Credential administrator -ScriptBlock gci -AsJob

Dat was een eenvoudige opdracht en het zou nu al moeten zijn uitgevoerd, dus laten we eens kijken naar onze taakstatus.

Hmm, ziet eruit alsof het niet gelukt is. Dit brengt me op mijn eerste gotcha met banen. Wanneer u in PowerShell een nieuwe taak van elk type maakt, maakt deze een bovenliggende taak naast een onderliggende taak voor elke computer waarop u de taak uitvoert. Wanneer u de Get-Job-cmdlet gebruikt, worden alleen de bovenliggende taken weergegeven en de eigenschap state in het slechtste geval, wat betekent dat zelfs als de opdracht slechts op één van de honderd computers kan worden uitgevoerd, de status van de bovenliggende taken mislukt. Als u een lijst met onderliggende taken wilt weergeven, moet u de parameter IncludeChildJob gebruiken.

Als je dichterbij kijkt, zul je zien dat de taak inderdaad op slechts één computer faalde, wat ons op de volgende gotcha brengt. Wanneer u probeert de resultaten voor de taak op te halen en de taaknaam of ID van de bovenliggende naam opgeeft, retourneert PowerShell de gegevens van alle onderliggende taken. Het probleem is dat als er een fout is in een van de onderliggende taken, er rode tekst achterblijft.

Er zijn twee manieren om dit te omzeilen. Ten eerste, als u weet op welke computers u de resultaten wilt hebben, gebruikt u eenvoudig de parameter Computernaam van de cmdlet Recieve -Job.

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

U kunt ook de resultaten van een specifieke onderliggende taak ophalen met behulp van de taak-id.

Get-Job -Id 3 -IncludeChildJob

Get-Job -Id 5 | Ontvangst-opdracht-hou

WMI-taken

WMI-taken zijn vrijwel hetzelfde als externe taken, waarvoor alleen de parameter -AsJob moet worden toegevoegd aan de cmdlet Get-WmiObject.

Helaas betekent dit dat ze ook onderhevig zijn aan dezelfde valstrikken die ik heb genoemd in de sectie Remote Jobs.

Geplande banen

De laatste drie soorten taken die we hebben bekeken, waren niet persistent, wat betekent dat ze alleen beschikbaar zijn in uw huidige sessie. Kort gezegd betekent dit dat als u een taak start en vervolgens een andere PowerShell-console opent en Get-Job uitvoert, u geen taken zult zien. Kom echter terug naar de console waar je je werk vandaan hebt geschopt, je zult de status ervan kunnen zien. Dit is in tegenstelling tot geplande taken die zijn persistent. Kort gezegd is een geplande taak een scriptblok dat volgens een schema loopt. In het verleden kon hetzelfde effect worden bereikt met de Windows Task Scheduler, wat echt is wat er gebeurt onder de motorkap. Om een ​​nieuwe geplande taak te maken, doen we het volgende:

Register-ScheduledJob -Name GetEventLogs -ScriptBlock Get-EventLog -LogName Security -Newest 100 -Trigger (Nieuw-JobTrigger -Dagelijks -Tijd om 17:00) -ScheduledJobOption (Nieuw geplande JobOption -RunElevated)

Er is nogal wat gaande in die opdracht, dus laten we het afbreken.

• Eerst geven we onze geplande taak een naam van GetEventLogs.
• We vertellen het vervolgens dat wanneer het wordt geactiveerd, we willen dat het de inhoud van het opgegeven scriptblok uitvoert, dat in feite de nieuwste 100 items van het beveiligingslogboek krijgt.
• Vervolgens specificeren we een trigger. Omdat de triggerparameter een triggerobject als invoer gebruikt, hebben we een haakjescommando gebruikt om een ​​trigger te genereren die elke dag om 17:00 uur afgaat.
• Omdat we te maken hebben met het gebeurtenislogboek, moeten we het uitvoeren als een beheerder, die we kunnen specificeren door een nieuw object ScheduledJobOption te maken en dit door te geven aan de parameter ScheduledJobOption.

Omdat dit een iets ander type taak is, moet u ook een andere opdracht gebruiken om een ​​lijst met alle geplande taken op een machine op te halen.

Get-ScheduledJob

Dat is alles wat er is.