Das starke Duo für alle Fälle
Von der Planung bis zur Ausführung: PowerShell-Skripte mit dem Windows Task Scheduler
Von: Philip Lorenz
In der IT-Administration stellen sich Herausforderungen wie die Bewältigung zeitaufwendiger Routineaufgaben tagtäglich. Eine elegante Lösung bietet die Kombination aus PowerShell und Windows Task Scheduler. Dieser Artikel beleuchtet, wie man durch effektive Skriptplanung mit diesen Tools die Automatisierung von System- und Netzwerkaufgaben optimieren kann.
Grundlagen der Automatisierung mit PowerShell und Task Scheduler
Als leistungsstarkes Automatisierungswerkzeug und Skriptsprache ermöglicht PowerShell die schnelle und effiziente Ausführung von Aufgaben. Es handelt sich dabei nicht nur um eine einfache Befehlszeilenschnittstelle, sondern um ein umfassendes Framework, das für komplexe Automatisierungsszenarien in Windows-Umgebungen entwickelt wurde. Mit seiner objektorientierten Natur erlaubt PowerShell die Manipulation und Verwaltung von Systemkomponenten auf eine Weise, die weit über traditionelle Skriptsprachen hinausgeht.
Auf der anderen Seite steht der Windows Task Scheduler, ein integraler Bestandteil von Windows-Betriebssystemen, der die automatische Ausführung von Aufgaben zu vordefinierten Zeiten oder unter bestimmten Bedingungen ermöglicht. Er bietet eine Benutzeroberfläche für die einfache Planung und Verwaltung von Automatisierungsaufgaben, die von einfachen Skripten bis hin zu komplexen Programmen reichen können. Die Kombination aus PowerShell und dem Windows Task Scheduler schafft eine leistungsfähige Plattform, um wiederkehrende Aufgaben zu automatisieren, Systemwartungen zu planen und auf Systemereignisse zu reagieren.
Im Vergleich zu Linux-Automatisierungstools, wie cron oder systemd, bietet der Windows Task Scheduler eine engere Integration in das Windows-Ökosystem. Während cron in Linux-Umgebungen für die Zeitplanung von Skripten verwendet wird, integriert der Windows Task Scheduler zusätzliche Funktionen wie detaillierte Konfigurationsoptionen, interaktive Benutzeroberflächen und die Fähigkeit, Aufgaben basierend auf einer Vielzahl von Ereignissen auszuführen. Diese Integration ermöglicht eine tiefere Verknüpfung mit Windows-spezifischen Diensten und Anwendungen, was den Task Scheduler zu einem unverzichtbaren Werkzeug für die Windows-basierte IT-Automatisierung macht.
Praktische Umsetzung: Skripte mit dem Task Scheduler planen
Die folgenden Abschnitte zeigen, wie man PowerShell-Skripte im Task-Scheduler planen kann. Die Anlage solcher Scheduled Tasks wird dabei sowohl über die grafische Oberfläche sowie über die PowerShell selbst demonstriert.
Vorbereitung und Test eines Beispiel-Skripts
Zur Demonstration erstellen wir ein einfaches Skript, das Datum und Uhrzeit in eine Log-Datei schreibt. Anhand der Log-Datei kann dabei unabhängig von den Ausgaben des Task Scheduler ermittelt werden, ob das Skript tatsächlich ausgeführt wurde. Speichere das folgende Skript unter dem Pfad C : \ps \scheduledtask\logger . ps1
# logger.ps1
$date = Get-Date
$logPath = "C:\ps\test\log.txt"
$date | Out-File $logPath -AppendGeplante Tasks über die grafische Benutzeroberfläche einrichten
Der einfachste Weg für das Erstellen von Scheduled Tasks führt über die grafische Oberfläche:
- Task Scheduler öffnen: Gib ‚Task Scheduler‘ in die Windows-Suche ein und öffne die Anwendung.
- Neuen Task erstellen: Wähle im rechten Fensterbereich die Option ‚Create Task‘.
- Allgemeine Einstellungen vornehmen: Gib dem Task einen Namen und beschreibe kurz seine Funktion. Wähle ‚Run whether user is logged on or not‘ für eine Ausführung im Hintergrund.

- Trigger einstellen: Wechsle zum Tab ‚Triggers‘ und klicke auf ‚New‘. Hier kannst du festlegen, wann das Skript ausgeführt werden soll, beispielsweise täglich um eine bestimmte Uhrzeit.
- Aktion definieren: Unter dem Tab ‚Actions‘ klickst du auf ‚New‘. Wähle ‚Start a program‘ und gib powershell im powershell -File „C:\ps\scheduledtask\logger.ps1“ Feld ‚Program/script‘ ein. Im Feld ‚Add arguments‘ trägst du File „C:\ps\scheduledtask\logger.ps1“ ein.

- Bedingungen und Einstellungen: Passe bei Bedarf die Bedingungen und Einstellungen im Task Scheduler an, um die Task deinen Anforderungen entsprechend zu optimieren.
- Task speichern: Speichere den Task und führe ihn zur Überprüfung manuell aus. Überprüfe die log.txt, um sicherzustellen, dass das Skript korrekt ausgeführt wurde.
PowerShell-basierte Task-Erstellung
Die Erstellung von Scheduled Tasks lässt sich auch direkt über PowerShell realisieren. Das hat den Vorteil, dass du die Task- Erstellung automatisieren und in Skriptform dokumentieren kannst.
$taskName = "TestLoggerTask"
$scriptPath = "C:\ps\scheduledtask\logger.ps1"
$triggerParams = @{ Daily = $true At = '9am'
}
$trigger = New-ScheduledTaskTrigger @triggerParams
$actionParams = @{
Execute = "Powershell.exe" Argument = "-File $scriptPath"
}
$action = New-ScheduledTaskAction @actionParams
$taskParams = @{ TaskName = $taskName Trigger = $trigger Action = $action
}
Register-ScheduledTask @taskParams
In diesem Skript wird die Splatting-Technik verwendet, um die Parameter für die Trigger- und Action-Erstellung in übersichtlichen und pflegbaren Hashtabellen zu organisieren. Dadurch wird der Code lesbarer und einfacher zu warten.
Scheduled Jobs vs. Scheduled Tasks
In der PowerShell-Automatisierung stehen zwei Hauptkonzepte zur Verfügung: Scheduled Jobs und Scheduled Tasks. Obwohl beide Ansätze ähnliche Ziele verfolgen, unterscheiden sie sich in ihrer Funktionsweise und in ihren Einsatzmöglichkeiten.
Scheduled Tasks sind Teil des Windows Task Schedulers und bieten eine tiefe Integration in das Betriebssystem. Sie können nicht nur PowerShell-Skripte, sondern auch andere Programme oder Skripte ausführen. Scheduled Tasks eignen sich besonders gut für komplexe Szenarien, die eine enge Verknüpfung mit Windows-Diensten und -Anwendungen erfordern. Sie bieten erweiterte Planungsoptionen, wie die Ausführung basierend auf spezifischen Ereignissen oder Zuständen des Systems.
Scheduled Jobs hingegen sind eine PowerShell-spezifische Funktion. Sie ermöglichen es, PowerShell-Befehle und -Skripte zu planen und als Hintergrundjobs auszuführen. Diese Jobs sind eng in die PowerShell-Umgebung integriert, was das Ausführen von PowerShell-Cmdlets und das Verarbeiten von PowerShell-Objekten erleichtert. Scheduled Jobs sind ideal für Aufgaben, die regelmäßig und ohne direkte Benutzerinteraktion durchgeführt werden sollen.
Ein Scheduled Job kann wie folgt angelegt werden:
# Register eines PowerShell Scheduled-Jobs
$trigger = New-JobTrigger -At 10pm -Daily
$jobOption = New-ScheduledJobOption -StartIfOnBatteries
Register-ScheduledJob -Name "MeinPowerShellJob" -ScriptBlock { # DeinIhr PowerShell-Code hier, z.B. ein Skript ausführen
. C:\ps\scheduledtask\logger.ps1
} -Trigger $trigger -ScheduledJobOption $jobOption
Bei der Verwendung von Scheduled Jobs ist jedoch Folgendes zu beachten:
- Geringere Kompatibilität mit externen Tools: Beispielsweise können Scheduled Tasks auch mittels Ansible angelegt werden, welches wiederum keine Unterstützung für Scheduled Jobs bietet.
- Einschränkungen bei der Auswahl möglicher Trigger: Scheduled Tasks können unter anderem durch Windows Events (EventLog) angestoßen werden. Scheduled Jobs beschränken sich auf die zeitliche Dimension.
Effektive Strategien zur Fehlervermeidung und Optimierung
Die Automatisierung mit PowerShell und Windows Task Scheduler birgt immense Vorteile, jedoch auch potentielle Fallstricke. Im folgenden werden diese Fallstricke, sowie weitere Optimierungspotentiale beschrieben.
Ausführungskontext und Verzeichnisstruktur
Ein häufiges Missverständnis ist die Annahme, dass PowerShell-Skripte automatisch im Speicherort des Skripts ausgeführt werden. Es ist wichtig zu wissen, dass Skripte standardmäßig im Kontext des Systemverzeichnisses, wie z.B. C:\Windows\system32, gestartet werden. Um Probleme mit relativen Pfadangaben zu vermeiden, sollte der Skriptkontext zu Beginn der Ausführung zum Speicherort des Skripts gewechselt werden. Dies lässt sich mit der PowerShell-Umgebungsvariable $PSScriptRoot realisieren:
Set-Location $PSScriptRoot
Nutzung von Scheduled Tasks im Clusterbetrieb
Für eine erhöhte Verfügbarkeit und Ausfallsicherheit können Scheduled Tasks clustergesteuert eingesetzt werden. Dies bietet Vorteile wie Hochverfügbarkeit durch Failover-Fähigkeiten, zentralisiertes Management und verbesserte Skalierbarkeit. Der Einsatz im Cluster-Modus erfordert ein bestehendes Windows-Cluster-Setup.
$taskName = "ClusteredTask"
$taskType = "ClusterWide"
$clusterName = "MeinCluster"
# ... Konfiguration von Trigger, Principal und Action ...
Register-ClusteredScheduledTask -TaskName $taskName -TaskType $taskType -Cluster $clusterName -Trigger $trigger -Principal $principal -Action
Sicherheitsaspekte und Benutzerberechtigungen
Sicherheit ist ein kritischer Aspekt bei der Automatisierung. PowerShell-Skripte werden im Kontext des angegebenen Benutzers ausgeführt, was bedeutet, dass die Sicherheitsberechtigungen dieses Benutzers berücksichtigt werden müssen. Es ist ratsam, spezielle Benutzerkonten mit minimal notwendigen Berechtigungen zu verwenden, um das Risiko einer übermäßigen Rechtevergabe zu vermeiden.
Monitoring und Protokollierung
Standardmäßiges Logging des Task Schedulers reicht oft nicht aus, um eine detaillierte Übersicht über die Ausführung von Automatisierungsaufgaben zu erhalten. Erweitere das Logging durch PowerShell-spezifische Funktionen wie das Transcript- Feature oder nutze fortgeschrittene Tools wie das PSFramework-Modul für ein umfassendes Monitoring.
Parametermanagement
Die Verwaltung von Übergabeparametern ist ein wesentlicher Bestandteil der Skriptautomatisierung. Anstatt feste Werte direkt im Skript zu definieren, sollten externe Parameterquellen wie Konfigurationsdateien genutzt werden. Dies erhöht die Flexibilität und Wartbarkeit der Skripte. Standardmäßig unterstützt die PowerShell JSON und XML als Datenformate.
Fazit
Gerade im Windows-Umfeld stellt die Kombination von PowerShell und Task Scheduler eine sehr starke und kostenfreie Option dar. Der Feature-Umfang ist natürlich bei weitem nicht so umfassend wie bei kommerziellen Tools zur Job-Steuerung. Für Anwendungsszenarien wie einfachem Reporting oder Aufräumarbeiten (Log-Dateien, etc.) erfüllt der Task Scheduler seinen Zweck. Wichtig ist hierbei lediglich, dass die genannten Best Practices angewendet werden und fehlende Features wie die Verwendung eines Credential- und Key-Stores ergänzt werden.

Über den Autor: Philip Lorenz
Philip Lorenz ist erfahrener DevOps- und Cloud-Engineer mit Schwerpunkt auf Prozessautomatisierung. Mit Begeisterung teilt er sein Wissen in Form von Dienstleistungen und Schulungen und erstellt praxisnahe Lerninhalte rund um die Themen Automatisierung, Cloud-Computing und die Umsetzung moderner KI-Lösungen. Seine Trainings, inspiriert von realen IT-Szenarien, vermitteln anwendbares Wissen, das Teilnehmende direkt in ihre tägliche Arbeit integrieren können.
Diese Beiträge könnten dich auch interessieren:
Der Beitrag Etwas weniger magisch, aber leichter zu lernen erschien zuerst auf heise academy Blog.
]]>Der Beitrag Frameworks – braucht’s die eigentlich noch? erschien zuerst auf heise academy Blog.
]]>Frameworks – braucht’s die eigentlich noch?
Von Brennpunkten in der IT-Landschaft und neuen Interpretationen alter Probleme
Von: Katja Potensky
Ich bin zwar nicht bekannt dafür, aus der Bibel zu zitieren, aber hin und wieder passt eine Passage einfach:
Es gibt nichts neues unter der Sonne. – Prediger 1,9
Daran fühlte ich mich letzte Woche erinnert bei einer Diskussion zur Frage, ob es Frameworks noch brauche. Du kannst dir sicher vorstellen, wie lebhaft solch ein Diskurs geführt wird. In den folgenden Absätzen möchte ich die verschiedenen Blickwinkel sowie meine Two Cents zum Thema Frameworks mit euch teilen.
Was ist überhaupt ein Framework?
Ein Framework ist eine Sammlung von Software mit einer zugehörigen Sammlung an Kompromissen. – Peter Kröner
Diese Definition kam zu Beginn der angesprochenen Diskussion auf und ich halte sie für die erste sinnvolle überhaupt. Denn sie deutet bereits darauf hin, dass wir es hier nicht mit einer rein technischen Fragestellung zu tun haben. Dennoch möchte ich den technischen Blickwinkel als Ausgangspunkt wählen.
Worin liegt der technische Bedarf?
Gibt es einen technischen Bedarf für C oder Java? Warum programmieren wir nicht alle einfach Assembler? Der Bedarf richtet sich nicht nur nach den Zielen, sondern auch nach den Aufwänden. Man wollte irgendwann nicht mehr in Assembler programmieren, also haben schlaue Menschen begonnen, die typischen Aufgaben zu abstrahieren und irgendwann kam unter anderem C dabei raus. Später hat sich herausgestellt, dass man auch in C viele wiederkehrende Aufgaben lösen musste, also hat sich über ein paar Umwege Java ergeben. Du siehst also, das Ganze ist ein iterativer Prozess.
Auf solchem Wege wurde auch die Aufgabe, ein buntes Kästchen im Browser zu bauen, in das man etwas reintippen kann, immer mehr abstrahiert. Diese Abstraktionen wurden zu den Frameworks, die wir heute kennen. Mittlerweile sind wiederum viele bis alle typischen Aufgaben zum Erstellen einer BLOBA (Boring Line-of-Business Application), bei denen ein Framework in den letzten zehn Jahren geholfen hat, durch Erweiterungen der Webstandards ohne größere oder sogar mit weniger Problemen umsetzbar.
Ich rate hier dringend dazu, auf MDN die Liste der HTML-Elemente alle paar Jahre durchzugehen, genauso wie die Liste der Web-APIs. Dialoge, Dropdowns oder auch die meisten Validierungen sollte man im Jahr 2024 wirklich nicht mehr mit einer teuren Component Library umsetzen.
Auch wenn es um das Thema Bundling und CI/CD geht, lohnt sich ein Blick über den Tellerrand. Gerade hier führt der Einsatz schwergewichtiger Lösungen gerne zu unvorhergesehenen Problemen.
Tipp: „Code is a liability, not an asset“ gilt auch für jenen Code, den wir nicht selbst schreiben. Wenn sich Abhängigkeiten ungünstig verhalten, ist meistens das einzige, was wir heutzutage tun können, einen Bug Report zu erstellen und die Ohren steif zu halten. Oder hast du schon mal probiert, eine geforkte Version von Angular auszurollen? ;)
Aber gut, dieses Argument schaut auf die bisherigen Umstände. Was ist, wenn wir in die Zukunft blicken?
Der Blick nach vorne
Gehen wir rein theoretisch davon aus, dass Angular, React, Vue etc. ihre Repositories und Packages löschen und wir alle unsere BLOBAs mit HTML und gezielt eingesetztem Javascript bauen.
Einer der Trends unserer Zeit ist ganz klar KI, man kann heutzutage im Browser mittels WebGPU Zugriff auf die GPU erlangen. Jetzt wäre es nicht allzu weit hergeholt, dass für diverse Use-Cases auf vielen Websites Chatbots implementiert werden sollen. Und zwar auf so vielen, dass es sich zur Vereinfachung des Anwendungsfalls auszahlt, Libraries darum herum zu schreiben. Vielleicht kommen auch Bezahlmöglichkeiten mittels Payment Request API dazu und ein paar andere Dinge, die so typisch werden, dass wir wiederum eine Reihe von Libraries unter der Annahme von gewissen Kompromissen auf eine spezifische Art und Weise verbinden, die wir gut finden… und prompt haben wir unser nächstes Framework geschaffen.
Wir können also davon ausgehen, dass es immer (neue) Frameworks geben wird. Denn so wunderbar die Webstandards sind, sie können und sollen eben nicht meinungsgetrieben sein. Selbst die Gamepad API existiert, weil es ausreichend Bedarf dafür gab und nicht umgekehrt. Neue Bedürfnisse sollten nicht durch Webstandards verprobt werden, sondern durch Libraries und Frameworks. Aber wer würde solche neuen Frameworks wohl verwenden?
„Apes together strong“
Wie viele Frameworks, die uns geholfen haben Formulare und Seitennavigationen zu bauen, gibt es wohl?
2011 habe ich einige JS-Files geschrieben, die mittels beliebiger Attribute an HTML-Elementen diese Elemente um eine beliebige Funktionalität erweitern können. Das weiß kaum jemand, da ich diese Idee zum einen nicht verbreitet habe. Zum anderen wurde ich ein paar Wochen später mit AngularJS konfrontiert und dachte mir: „Hey, die Idee hatte schon jemand.“ Also habe ich meinen eigenen Code verworfen und stattdessen AngularJS eingesetzt, weil es zum damaligen Zeitpunkt genau das tat, was ich zum damaligen Zeitpunkt brauchte. Es gibt Ideen, um die Menschen sich versammeln, und das hat gleich mehrere Auswirkungen.
Brennpunkte
Egal ob man diesen Ansatz gut findet oder nicht, egal ob man React oder Angular mag – durch die Existenz von Frameworks bilden sich gewissermaßen Brennpunkte in der IT-Landschaft. Orte, an denen Menschen zusammen kommen, ihre Ideen einbringen und Richtlinien rund um die vermeintlich korrekte (idiomatische) Verwendung der jeweiligen Lösung erarbeiten.
Diese Richtlinien mögen uns gefallen oder nicht, sie ermöglichen einen effizienteren Austausch in Projekten und ein schnelleres Onboarding von neuen Personen. Durch die kontinuierliche Anwendung dieser Richtlinien werden sie innerhalb gewisser Grenzen laufend verbessert. Aber was, wenn man an diese Grenzen stößt und sich nicht damit abfinden will?
Dissonanz
Zu Deutsch: Unstimmigkeit, Missklang. Stell dir vor, du kannst nicht damit leben, dass AngularJS die Änderungen an Objekten periodisch und recht teuer auf den Bildschirm bringt. Ganz egal, wie viel optimiert wird, hier ist das grundlegende Konzept das Problem und irgendwann stößt man an die Grenzen des technisch Möglichen.
Wenn das ein Knockout-Kriterium ist, muss man besagten Brennpunkt verlassen, zurück ans Zeichenbrett und von Null auf neue Wege gehen. Das mag erst mal unglaublich schwer klingen, aber man hat einige gewaltige Vorteile dabei: Man weiß, was das Problem ist, wie man es nicht löst und was die Erwartungshaltungen sind.
Und nach ein paar Monaten Hin und Her, Recherche und Trial-and-Error hat man dann wahrscheinlich einen Weg, um den Anwendungsfall, an dem die vorige Idee gebrochen ist, besser umzusetzen. Um es mit den Worten von Soichiro Honda zu sagen:
„Racing improves the breed.“
Die Frage ist dann eher, ob das, was wir jetzt besser machen können, die Verbesserung überhaupt verdient hat.
Ein alter Hut?
Sind Frameworks also bloß immer neue Interpretationen von ewig alten Problemen? Nun, irgendwie schon, aber irgendwie auch nicht. Mir fällt hierzu eine Anekdote ein. Ich fand Liebeslieder immer kitschig und sinnlos, bis ich mal einen Musiker bei einer Show sagen hörte: „Natürlich wurden die Worte ‚I love you‘ schon tausende Male vertextet, natürlich ist jedes Liebeslied irgendwie gleich. Aber vielleicht, nur vielleicht, wurde es ja noch nicht mit den selben Gefühlen gesungen, die du dabei spürst. Und selbst wenn, warum sollte dich das davon abhalten, ‚I love you‘ zu sagen?“
Vielleicht können wir darüber hinweg sehen, welches Framework technisch besonders ausgefeilt ist, und einfach das verwenden, das am besten zur aktuellen Situation passt. Und wenn die aktuelle Situation bloß erfordert, eine Reihe von Formularen zu erstellen, könnte man ‚I love you‘ mal ganz ohne jegliche Schnörkel sagen. Denn der größte Brennpunkt in der IT-Landschaft sind immer noch die Webstandards.

Über die Autorin: Katja Potensky
Katja ist Software Engineer bei adesso und seit 2012 in einem professionellen Setting tätig. Sie lässt sich nicht auf einzelne Aspekte eines Systems limitieren, und hat von daher schon eine Vielzahl an Projekten in unterschiedlichsten Rollen und Teamgrößen umgesetzt. Aus der Arbeit mit unterschiedlichsten Webtechnologien hat sich ein fundierter Anspruch an Codequalität und korrektes Programmverhalten entwickelt den sie auch weitergeben möchte. Sie brennt für Code der leicht zu lesen ist und nicht bedingt die halbe Codebase im Kopf zu behalten um zu verstehen was “da gerade passiert”.

