29Aug
PowerShell heeft vier soorten taken: achtergrondtaken, externe taken, WMI-taken en geplande taken. Doe met ons mee als we uitvinden wat ze zijn en hoe we ze kunnen gebruiken.
Lees de vorige artikelen in de reeks:
- Leer hoe u Windows kunt automatiseren met PowerShell
- Leren gebruik van cmdlets in PowerShell
- Leren gebruiken van objecten in PowerShell
- Leren opmaken, filteren en vergelijken in PowerShell
- Leren gebruiken van achtergrondinformatie inPowerShell
- PowerShell gebruiken om computerinformatie te verkrijgen
- Werken met collecties in PowerShell
Blijf de rest van de serie de hele week op de hoogte.
Achtergrondtaken
Tot nu toe is alles wat ik je binnen PowerShell heb laten zien synchroon geweest, 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 die taak voorstelt. 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
Wanneer u echter een opdracht hebt stopgezet, is de gegevens die tot dan toe werden ontvangen tot het moment dat u ermee stopte 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-schakelaar van Receive-Job opgeven.
Get-Job -Name GetFileList |Ontvangst Job - Houd
aan Als je eenmaal klaar bent met een opdracht, is het het beste om het te verwijderen. Om de taak te verwijderen, pijpt u deze eenvoudig naar de cmdlet Remove Job.
Get-Job -Name GetFileList |Remove-Job
Hiermee wordt het verwijderd uit de lijst met taken die worden geretourneerd door Get-Job.
Remote Jobs
Een paar lessen geleden hebben we gekeken hoe we remoting kunnen gebruiken om PowerShell-commando's uit te voeren op een machine op afstand met Invoke-Command, maar wist je dat je Invoke-Command ook kunt gebruiken om een remoting-taak op de achtergrond te starten??Hiertoe 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 zou nu al moeten worden uitgevoerdlaten we eens kijken naar de status van onze banen.
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 niet op één van de honderd computers kan worden uitgevoerd, de status van de bovenliggende taken aangeeftmislukt. Als u een lijst met onderliggende taken wilt weergeven, moet u de parameter IncludeChildJob gebruiken.
Als u beter kijkt, ziet u dat de taak inderdaad op één computer is mislukt, 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, kunt u eenvoudig de parameter Computernaam van de cmdlet Recieve -Job gebruiken.
Get-Job -Id 3 |Receive-Job -Keep -ComputerName Viper
Als alternatief kunt u de resultaten van een specifieke onderliggende job krijgen met behulp van de job-id.
Get-Job -Id 3 -IncludeChildJob
Get-Job -Id 5 |Ontvangstopdracht - Houd
WMI-taken vast
WMI-taken zijn vrijwel hetzelfde als externe taken, waarvoor alleen de parameter -AsJob moet worden toegevoegd aan de Get-WmiObject-cmdlet.
Helaas betekent dit dat ze ook onderworpen zijn aan dezelfde valstrikken die ik heb genoemd in de sectie Remote Jobs.
Geplande opdrachten
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 persistent zijn. Kort gezegd is een geplande taak een scriptblok dat volgens een schema loopt. In het verleden kon hetzelfde effect worden bereikt met behulp van de Windows Task Scheduler, wat in werkelijkheid is wat er onder de motorkap gebeurt. Om een nieuwe Geplande Taak te maken, doen we het volgende:
Register-ScheduledJob -Name GetEventLogs-ScriptBlock{ Get-EventLog-Lognaam Security -Newest 100} -Trigger( Nieuw-JobTrigger -Dagelijks -Tijd 17:00) -ScheduledJobOption( Nieuw geplande JobOption-RunElevated)
Er is nogal wat gaande in die opdracht, dus laten we het opsplitsen.
- 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 gespecificeerde 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 door te geven aan de parameter ScheduledJobOption.
Aangezien dit een iets ander type taak is, moet u ook een andere opdracht gebruiken om een lijst met alle geplande taken op een computer op te halen.
Get-ScheduledJob
Dat is alles wat er is.