Dienste und Aufgabenplanung

Der meiste Code auf einem Server läuft, ohne dass jemand davorsitzt — als Dienst oder als geplante Aufgabe. Beide werfen dieselben drei Fragen auf: wann startet das, unter welcher Identität, und was passiert bei einem Fehler. Dieses Modul beantwortet sie an den Stellen, an denen die Voreinstellungen etwas anderes zusagen, als man liest: eine eingerichtete Wiederherstellung, die beim geordneten Fehlschlag nicht greift, eine Aufgabe ohne gespeichertes Kennwort, die deshalb kein Netzlaufwerk erreicht, und ein Erfolgscode, der nur den Start eines Vorgangs bestätigt.

Lehrtext · 12 Abschnitte · zuletzt geprüft: 2026-09-03

Zwei Mechanismen, dieselben drei Fragen

Auf einem Server läuft der meiste Code, ohne dass jemand davorsitzt. Windows hat dafür zwei Mechanismen: Dienste und geplante Aufgaben. Sie sehen verschieden aus, werfen aber dieselben drei Fragen auf — wann startet das, unter welcher Identität, und was passiert, wenn es scheitert. Wer beide zusammen betrachtet, spart sich, dieselben Antworten zweimal zu lernen.

Dienst — Ein Prozess, den der Dienststeuerungs-Manager (SCM) startet, überwacht und beendet. Er meldet dem SCM seinen Zustand zurück und läuft in der Regel dauerhaft.

Geplante Aufgabe — Ein Programmaufruf, den die Aufgabenplanung bei einem Auslöser startet — zu einer Zeit, beim Start, bei einer Anmeldung oder bei einem Ereignis. Sie läuft, tut etwas und endet.

Die Faustregel: Was dauerhaft auf etwas warten soll, ist ein Dienst. Was in Abständen etwas erledigt und danach fertig ist, ist eine Aufgabe. Ein Skript in einer Endlosschleife als Dienst zu verkleiden, ist eine Konstruktion, die auf beiden Seiten Nachteile einsammelt.

Ein Dienst ist ein Registry-Schlüssel

Jeder Dienst hat einen Schlüssel unter HKLM\SYSTEM\CurrentControlSet\Services\<Name>. Dort steht alles, was ihn ausmacht: ImagePath für die Programmdatei mit Argumenten, ObjectName für das Konto, Start für den Starttyp, DependOnService für Abhängigkeiten. Die Werkzeuge sind Oberflächen über diesen Werten, keine eigene Datenbank.

Get-Service: Name, Anzeigename, Status. Sagt nichts über Konto und Pfad.
Get-CimInstance Win32_Service: Zusätzlich StartName (das Konto) und PathName (die Befehlszeile).
sc.exe qc <Name>: Starttyp, Pfad, Konto und Abhängigkeiten in einer Ausgabe.
sc.exe config <Name> …: Ändert dieselben Werte, ohne die Registry direkt anzufassen.

Warum das die erste Diagnose istBei einem Dienst, der „läuft, aber nicht funktioniert“, klärt eine einzige Ausgabe die Hälfte der möglichen Ursachen: Steht der Pfad noch auf dem alten Verzeichnis? Läuft er unter dem Konto, das ihr letztes Jahr umgestellt habt? Hängt er an einem Dienst, den jemand deaktiviert hat? Get-Service beantwortet keine dieser Fragen — es zeigt nur den Zustand.

sc.exe qc <Name> — Starttyp, Programmpfad, Konto und Abhängigkeiten in einem Blick.→sc.exe qfailure <Name> — die eingerichteten Wiederherstellungsaktionen samt Rücksetzfenster.→Get-CimInstance Win32_Service -Filter "Name='<Name>'" — dieselben Angaben als Objekte, für den Vergleich über viele Server hinweg.→Erst danach Get-Service für den aktuellen Zustand.

Der Zustand ist der letzte Schritt, nicht der erste: Er sagt, was gerade ist, aber nicht, was zugesagt wurde.

Starttypen: was sie zusagen und was nicht

auto: Startet bei jedem Systemstart, auch ohne Anmeldung.
delayed-auto: Startet automatisch, aber kurz nachdem die übrigen auto-Dienste gestartet sind.
demand: Startet nur auf Anforderung. Das ist der Standard, wenn nichts angegeben wird.
disabled: Kann nicht gestartet werden, solange der Typ nicht geändert wird.
boot / system: Treiber, die vom Startladeprogramm bzw. während der Kernelinitialisierung geladen werden.

delayed-auto ist der Typ, der am häufigsten falsch verstanden wird. Er ist kein Zeitplan und keine Verzögerung um eine bestimmte Zahl von Sekunden, sondern eine Aussage über die Reihenfolge: Der Dienst kommt an die Reihe, wenn die anderen automatischen Dienste durch sind. Wer damit ein Abhängigkeitsproblem umgeht, hat es nicht gelöst, sondern nur unwahrscheinlicher gemacht — auf einem langsameren oder stärker belasteten Server kommt es zurück.

Der Unterschied zwischen laufend und zugesagtRunning und der Starttyp sind zwei getrennte Aussagen. Ein von Hand gestarteter Dienst mit dem Typ demand läuft — und ist nach dem nächsten Neustart weg. Umgekehrt bedeutet auto nicht, dass der Dienst gerade läuft. Bei jeder Übergabe gehören deshalb beide Werte in den Nachweis, nicht nur der Status.

Unter welcher Identität ein Dienst läuft

LocalSystem: Höchste lokale Rechte. Im Netz tritt der Dienst als Computerkonto auf.
NETWORK SERVICE: Eingeschränkt lokal, im Netz ebenfalls als Computerkonto.
LOCAL SERVICE: Eingeschränkt lokal, im Netz anonym — für Netzzugriffe unbrauchbar.
Domänenkonto / gMSA: Eigene Identität im Netz, eigene Berechtigungen, eigene Nachvollziehbarkeit.

Die Zeile, die im Betrieb am meisten Zeit kostet, ist die dritte. Ein Dienst unter LOCAL SERVICE, der auf eine Freigabe zugreifen soll, scheitert — und die Fehlermeldung spricht von fehlenden Berechtigungen, was zu der falschen Reaktion einlädt, auf der Freigabe Rechte zu vergeben. Es gibt aber niemanden, dem man sie geben könnte.

Das Recht, ohne das nichts startetEin Konto, unter dem ein Dienst laufen soll, braucht das Benutzerrecht Anmelden als Dienst (SeServiceLogonRight). Fehlt es, startet der Dienst nicht — mit einer Meldung über einen fehlgeschlagenen Anmeldevorgang, die nach einem falschen Kennwort aussieht. Wer das Kennwort über die Dienste-Konsole setzt, bekommt das Recht automatisch mitgesetzt; wer das Konto per Skript oder Gruppenrichtlinie einträgt, in der Regel nicht. Das erklärt, warum derselbe Dienst von Hand eingerichtet läuft und automatisiert eingerichtet nicht.

Bleibt die Frage nach dem Kennwort. Ein Domänenkonto als Dienstkonto bedeutet, dass irgendwo ein Kennwort steht, das jemand drehen muss — und dass beim Drehen jeder Dienst mitgezogen werden will, der es benutzt. Genau deshalb gibt es gruppenverwaltete Dienstkonten (gMSA), bei denen das Verzeichnis das Kennwort selbst rotiert und die berechtigten Hosts es abholen. Für dieses Modul reicht die Merkregel: Wenn ein Dienstkonto auf mehr als einem Server gebraucht wird, ist ein statisches Kennwort die teuerste der möglichen Antworten. Die Einzelheiten dazu stehen im Modul über Dienstidentitäten.

Wiederherstellungsaktionen greifen seltener, als man denkt

In den Eigenschaften eines Dienstes lässt sich unter Wiederherstellung festlegen, was beim ersten, zweiten und jedem weiteren Fehler passieren soll: Dienst neu starten, Programm ausführen, Computer neu starten. Das ist der Teil, den jeder kennt. Der Teil, den fast niemand kennt, steht daneben.

Dienst neu starten: Der SCM startet den Prozess erneut. Ohne Beseitigung der Ursache entsteht daraus ein Muster, das im Status nicht auffällt.
Programm ausführen: Ein Befehl, den der SCM startet. Er läuft laut Dokumentation unter demselben Konto wie der Dienst.
Computer neu starten: Der drastischste Fall. Bei einem Dienst mit mehreren Verbrauchern selten die richtige Antwort.
Keine Aktion: Der Standard. Er ist eine Entscheidung, auch wenn er wie eine fehlende aussieht.

Der dokumentierte HakenIn der Voreinstellung werden die Wiederherstellungsaktionen nur ausgelöst, wenn der Prozess endet, ohne dem SCM einen ordentlichen Stopp zu melden — also beim Absturz. Beendet sich der Dienst geordnet und meldet dabei einen Fehlercode ungleich null, passiert nichts. Erst das zusätzliche Kennzeichen — in der Oberfläche das Kästchen für Beendigungen mit Fehlern — erweitert die Auslösung auf diesen Fall. Ein Dienst, der sich bei einer unerreichbaren Datenbank sauber selbst beendet, ist damit genau der Fall, in dem die eingerichtete Wiederherstellung nicht greift.

Die Konsequenz für eine Übergabe: „Wiederherstellung ist konfiguriert“ ist keine prüfbare Aussage. Prüfbar ist, ob die Aktionen für den Fehlerfall gelten, der bei diesem Dienst tatsächlich auftritt — und den kennt man erst, wenn man einmal hingesehen hat, wie er ausfällt.

Der Fehlerzähler und sein Rücksetzfenster

Die Wiederherstellung kennt drei Stufen: erster Fehler, zweiter Fehler, alle weiteren. Welche Stufe gilt, entscheidet ein Zähler — und der wird nach einer einstellbaren Zeit ohne Fehler auf null zurückgesetzt. Diese Zeit heißt Rücksetzfenster und steht üblicherweise auf einen Tag.

Der Dienst, der nie die zweite Stufe erreicht

Szenario

Ein Dienst stürzt etwa alle 30 Stunden ab. Konfiguriert ist: erster Fehler Neustart, zweiter Fehler Neustart, weitere Fehler Programm ausführen — ein Skript, das ein Ticket öffnet. Das Ticket ist in vier Monaten nie entstanden.

Anforderungen

Der Absturz soll auffallen, nicht nur überlebt werden.

Schritte

Rücksetzfenster ablesen: ein Tag. Zwischen zwei Abstürzen liegen 30 Stunden.
Daraus folgt: Der Zähler ist bei jedem Absturz längst wieder null. Es ist immer der erste Fehler.
Das Ticket-Skript hängt an „weitere Fehler“ und wird deshalb nie erreicht.
Korrektur: entweder das Rücksetzfenster über den Abstand zwischen zwei Abstürzen hinaus verlängern, oder die Meldung an den ersten Fehler hängen statt an den dritten.

Merksatz: Die Konfiguration war nicht falsch abgetippt — sie war für ein Fehlerbild gedacht, das dieser Dienst nicht zeigt. Eine Wiederherstellungseinstellung ist nur zusammen mit der Fehlerfrequenz lesbar.

Abhängigkeit ist Reihenfolge, nicht Bereitschaft

Trägt ein Dienst in DependOnService einen anderen ein, startet der SCM den anderen zuerst und verweigert den eigenen Start, wenn das misslingt. Das ist eine Aussage über die Reihenfolge und über den vom SCM gemeldeten Zustand — mehr nicht.

„Gestartet“ heißt: Der Prozess läuft und hat sich beim SCM gemeldet. Es heißt nicht, dass er seinen Port bedient, seine Datenbank geöffnet oder seinen Zwischenspeicher aufgebaut hat. Ein Dienst, der zehn Sekunden zur Bereitschaft braucht, ist für den SCM schon nach einer Sekunde gestartet — und der abhängige Dienst läuft in genau dieses Fenster.

Umgekehrt gilt dasselbe beim Anhalten: Wer einen Dienst stoppt, von dem andere abhängen, nimmt diese mit. Die Dienste-Konsole fragt vorher; ein Skript in der Regel nicht. Bevor ein Dienst im laufenden Betrieb angehalten wird, gehört deshalb die Frage dazu, wer an ihm hängt — sichtbar in sc.exe enumdepend <Name>. Die Liste ist oft länger, als das Änderungsvorhaben annimmt, und sie ist der Unterschied zwischen einem Neustart eines Dienstes und einem Ausfall mehrerer.

Warum eine Wartezeit die falsche Antwort istDer übliche Reflex ist eine Verzögerung: delayed-auto, oder ein Skript, das erst einmal wartet. Beides verschiebt die Fehlerwahrscheinlichkeit, statt sie zu beseitigen, und beides bricht wieder, sobald der Server langsamer bootet als am Tag des Tests. Tragfähig ist, dass der abhängige Dienst die Bereitschaft prüft und es erneut versucht — eine Eigenschaft der Anwendung, keine der Dienstkonfiguration. Wo die Anwendung das nicht kann, ist die Wartezeit ein bewusst gewählter Kompromiss und gehört als solcher dokumentiert.

`Running` beweist nur die eigene Schicht

Der Status eines Dienstes ist ein Signal über einen Prozess. Zwischen diesem Signal und der Aussage „der Dienst erfüllt seinen Zweck“ liegen mehrere Schichten, von denen jede einzeln ausfallen kann.

Jede Schicht belegt nur sich selbst. Abgenommen ist erst, was auf dem Weg des Clients ankommt.

Praktisch heißt das: Nach einem Neustart oder einer Änderung ist die Prüfung nicht Get-Service, sondern der kürzeste Weg, der dem echten Zugriff entspricht — eine Anfrage auf dem Port, ein Aufruf über den Namen, den die Clients benutzen. Der Statusabruf bleibt nützlich, aber als erster Schritt einer Kette, nicht als deren Ergebnis.

Die geplante Aufgabe: Auslöser, Aktion, Principal

Eine Aufgabe besteht aus drei Teilen, die man getrennt betrachten muss: dem Auslöser, der bestimmt wann, der Aktion, die bestimmt was, und dem Principal, der bestimmt wer. Der dritte Teil ist der, an dem die meisten Aufgaben scheitern.

Password: Anmeldung mit hinterlegtem Kennwort. Läuft unabhängig von einer Anmeldung, mit Netzzugriff.
S4U: Anmeldung ohne hinterlegtes Kennwort. Läuft unabhängig von einer Anmeldung, ohne Netzzugriff.
Interactive: Läuft nur, wenn der Benutzer bereits angemeldet ist.
ServiceAccount: Läuft unter LocalSystem, LOCAL SERVICE oder NETWORK SERVICE.

Angelegt und geprüft wird das mit Register-ScheduledTask und New-ScheduledTaskPrincipal, oder mit schtasks. Get-ScheduledTask <Name> | Select-Object -ExpandProperty Principal zeigt bei einer bestehenden Aufgabe, welcher Anmeldetyp tatsächlich gesetzt ist.

Neben Auslöser, Aktion und Principal gibt es einen vierten Bereich, der Aufgaben stillschweigend aussetzt: die Bedingungen. Dort steht etwa, dass die Aufgabe nur bei Netzbetrieb starten soll, nur wenn der Computer im Leerlauf ist, oder nur wenn eine bestimmte Netzwerkverbindung besteht. Ist eine Bedingung nicht erfüllt, startet die Aufgabe nicht — und im Verlauf steht kein Fehler, weil nichts fehlgeschlagen ist. Dazu kommen die Einstellungen mit der Höchstlaufzeit: Wird sie erreicht, beendet die Aufgabenplanung den Vorgang. Beide Bereiche gehören in die Prüfung einer Aufgabe, die „einfach nicht läuft“.

S4U: kein Kennwort, kein Netz

In der Oberfläche gibt es die Auswahl Unabhängig von der Benutzeranmeldung ausführen und darunter das Kästchen Kennwort nicht speichern. Wer das Kästchen setzt, wählt damit S4U. Die Dokumentation ist an dieser Stelle deutlich: Bei einer S4U-Anmeldung speichert das System kein Kennwort — und es gibt weder Zugriff auf das Netzwerk noch auf verschlüsselte Dateien.

Kurzcheck

Ein Skript sichert eine Datei nach \\fs01\backup. Von Hand gestartet funktioniert es. Als Aufgabe mit „Unabhängig von der Benutzeranmeldung“ und „Kennwort nicht speichern“ meldet es Zugriff verweigert. Was ist die Ursache?

Die Aufgabe läuft als S4U und hat damit keinen Netzzugriff
Dem Konto fehlen Rechte auf der Freigabe \\fs01\backup
Der Aufgabe fehlt das Recht, als Batch-Auftrag angemeldet zu werden

Treffer. Richtig. Ohne hinterlegtes Kennwort gibt es keine Anmeldeinformationen, die im Netz vorgezeigt werden könnten — unabhängig davon, welche Rechte das Konto auf der Freigabe hat.

Die Wahl, die dahinterstecktDamit ist die Entscheidung offengelegt: Entweder ein Kennwort wird auf dem Server hinterlegt, oder die Aufgabe erreicht kein Netzlaufwerk. Wer beides will, braucht eine dritte Antwort — ein verwaltetes Dienstkonto, dessen Kennwort das Verzeichnis selbst rotiert. Was von Hand funktioniert, ist deshalb kein Beweis dafür, dass es geplant funktioniert: Es sind zwei verschiedene Anmeldungen.

Die zwei Anmelderechte

Dienst und Aufgabe brauchen verschiedene Benutzerrechte, und beide sind unabhängig von den Berechtigungen auf Dateien oder Freigaben. Ein Konto kann auf ein Verzeichnis vollen Zugriff haben und trotzdem nichts starten dürfen.

Anmelden als Dienst: SeServiceLogonRight. Ohne dieses Recht startet der Dienst nicht.
Anmelden als Batch-Auftrag: SeBatchLogonRight. Die Aufgabenplanung meldet das Konto als Batch-Auftrag an, nicht interaktiv.
Standard laut Doku: Dienst: NETWORK SERVICE. Batch: Administratoren, Sicherungs-Operatoren, Benutzer der Leistungsprotokolle.

Wo das Recht wieder verschwindetBeim Anlegen einer Aufgabe über den Assistenten mit Benutzername und Kennwort wird das Batch-Recht automatisch mit vergeben. Steuert eine Gruppenrichtlinie dieselbe Richtlinieneinstellung zentral, überschreibt sie beim nächsten Anwenden die lokale Liste — und nimmt das automatisch vergebene Recht wieder mit. Die Aufgabe lief dann wochenlang und hört ohne erkennbaren Anlass auf. Der Anlass ist die Richtlinie, nicht die Aufgabe.

Prüfen lässt sich der Ist-Zustand mit secedit /export /areas USER_RIGHTS /cfg rechte.inf und einem Blick in die erzeugte Datei: Dort stehen SeServiceLogonRight und SeBatchLogonRight mit den Sicherheitskennungen der berechtigten Konten. Das ist umständlicher als ein Klick in der lokalen Sicherheitsrichtlinie, hat aber zwei Vorteile — es funktioniert auf Server Core, und das Ergebnis ist eine Datei, die sich zwischen zwei Servern vergleichen lässt.

Was die Aufgabenplanung meldet — und was nicht

In der Spalte Letztes Ausführungsergebnis steht ein Code. Er wird häufig als Erfolgsmeldung der Aufgabe gelesen und ist etwas anderes.

0x0: Der Vorgang wurde gestartet und endete ohne Fehler. Über das fachliche Ergebnis sagt das nichts.
0x00041301: Die Aufgabe läuft noch. Ein Wert, der stehen bleibt, deutet auf einen hängenden Vorgang.
0x00041303: Die Aufgabe wurde noch nie ausgeführt — der Auslöser hat nie gegriffen.
0x00041306: Der letzte Lauf wurde beendet, etwa weil die eingestellte Höchstlaufzeit erreicht war.

Die Lücke zwischen 0x0 und erledigt0x0 bedeutet: Der Prozess wurde gestartet und hat sich mit Rückgabewert null beendet. Ein Skript, das seinen Fehler abfängt und trotzdem sauber endet, meldet ebenfalls 0x0. Ein Skript, dessen Pfad nicht existiert, meldet dagegen einen Startfehler — der Unterschied ist wichtig: Die Aufgabenplanung überwacht den Start eines Vorgangs, nicht sein Ergebnis. Wer wissen will, ob die Sicherung gelaufen ist, braucht einen Nachweis aus der Sicherung, nicht aus der Aufgabenplanung.

Wo man tatsächlich nachsieht: Der Ereigniskanal Microsoft-Windows-TaskScheduler/Operational protokolliert je Aufgabe den registrierten Start, den gestarteten Vorgang und dessen Ende mit Rückgabewert. Er ist die einzige Quelle, die zwischen „der Auslöser hat nicht gegriffen“, „der Vorgang wurde gestartet und ist gescheitert“ und „der Vorgang läuft noch“ unterscheidet — die Spalte in der Übersicht kann das nicht. Prüfe bei der Übernahme eines Servers, ob dieser Kanal aktiviert ist; ohne ihn bleibt für die Diagnose nur die letzte Zeile eines Ergebnisses.

Jetzt anwenden

Diesen Stoff gibt es als Modul mit bewerteten Entscheidungs-Checks — dieselbe Einführung, danach die Übungen.

Zum Modul →

Quellen & Aktualität10 Primärquellen · zuletzt geprüft: 2026-09-03