JTL-Worker als Windows-Dienst: Fehler 1069 und die zwei Ursachen dahinter

Der JTL-Worker ist die Komponente, die im Hintergrund abarbeitet, was nicht am Bildschirm passiert: Shop-Abgleich, Marktplatzanbindungen, Zahlungsabholung, geplante Aufgaben. Läuft er nicht, fällt das oft erst auf, wenn Bestellungen fehlen.

Genau deshalb gehört er als Windows-Dienst eingerichtet und nicht als Programm, das jemand nach dem Anmelden startet. Nur scheitert die Einrichtung bei jeder zweiten Installation an derselben Meldung:

Fehler 1069: Der Dienst konnte wegen eines Anmeldefehlers nicht gestartet werden.

Ursache 1: Dem Konto fehlt das Recht „Anmelden als Dienst”

Windows lässt Sie einen Dienst mit einem beliebigen Konto konfigurieren — aber starten darf sich dieses Konto nur, wenn es das Recht Anmelden als Dienst besitzt. Fehlt es, ist das Ergebnis exakt dieselbe Meldung wie bei einem falschen Passwort. Deshalb sucht man zuerst an der falschen Stelle.

Setzen lässt sich das Recht über die lokale Sicherheitsrichtlinie unter Lokale Richtlinien → Zuweisen von Benutzerrechten → Anmelden als Dienst. Dort das Dienstkonto hinzufügen, danach den Dienst erneut starten.

Wenn Sie die Einrichtung skripten, geht es auch ohne grafische Oberfläche — über den Export und Reimport der Sicherheitsrichtlinie:

$konto = "SERVER\jtlworker"
secedit /export /cfg C:\temp\rechte.cfg /areas USER_RIGHTS

$sid  = (New-Object System.Security.Principal.NTAccount($konto)).
         Translate([System.Security.Principal.SecurityIdentifier]).Value
$cfg  = Get-Content C:\temp\rechte.cfg
$zeile = $cfg | Where-Object { $_ -like "SeServiceLogonRight*" }
$neu   = if ($zeile) { "$zeile,*$sid" } else { "SeServiceLogonRight = *$sid" }
($cfg -replace [regex]::Escape($zeile), $neu) | Set-Content C:\temp\rechte.cfg

secedit /configure /db secedit.sdb /cfg C:\temp\rechte.cfg /areas USER_RIGHTS

Der Umweg über die SID statt über den Kontonamen ist kein Selbstzweck: Auf deutschsprachigen Systemen heißen die integrierten Konten anders als auf englischen. Mit der SID funktioniert dasselbe Skript auf beiden.

Ursache 2: Das Benutzerprofil existiert noch gar nicht

Die zweite Ursache ist unauffälliger und kostet erfahrungsgemäß mehr Zeit. Der Worker legt Dateien in einem benutzerbezogenen Verzeichnis unterhalb von AppData\Local ab. Dieses Verzeichnis entsteht aber erst, wenn sich das Konto mindestens einmal interaktiv angemeldet hat.

Ein frisch angelegtes Dienstkonto hat das nie getan. Der Dienst startet, findet sein Arbeitsverzeichnis nicht und beendet sich wieder — teils mit 1069, teils mit einer generischen Meldung.

Die Lösung ist unspektakulär: Melden Sie sich einmal per Remote-Desktop mit dem Dienstkonto an, warten Sie bis der Desktop steht, melden Sie sich wieder ab. Danach existiert das Profil samt Verzeichnisstruktur, und der Dienst startet.

Falls das Konto sich nicht interaktiv anmelden darf, hilft es, das Verzeichnis von Hand anzulegen und dem Konto Vollzugriff darauf zu geben. Der saubere Weg bleibt die einmalige Anmeldung.

Die Reihenfolge, die funktioniert

1. Dienstkonto anlegen — ein eigenes Konto, kein Administratorkonto, Kennwort ohne Ablaufdatum.
2. Einmal interaktiv anmelden, damit das Profil entsteht. Wieder abmelden.
3. Recht „Anmelden als Dienst” vergeben.
4. Worker als Dienst registrieren und auf Automatisch (verzögerter Start) setzen. Der verzögerte Start ist kein Detail: Startet der Worker vor dem SQL Server, findet er keine Datenbank und gibt auf.
5. Wiederherstellungsoptionen setzen — in den Diensteigenschaften unter Wiederherstellung alle drei Fehlerfälle auf „Dienst neu starten”. Damit übersteht der Worker einen kurzzeitig nicht erreichbaren SQL Server ohne Handarbeit.
6. Kontrollieren, ob er wirklich arbeitet. Dass der Dienst „Wird ausgeführt” anzeigt, heißt nur, dass der Prozess lebt. Ob er Aufträge abholt, sehen Sie erst in den Worker-Protokollen oder daran, dass geplante Aufgaben tatsächlich durchlaufen.

Was ich zusätzlich einrichte

Eine Überwachung, die anschlägt, wenn nichts passiert. Ein Dienst, der läuft aber nichts tut, ist der unangenehmste Fall — es gibt keine Fehlermeldung, nur ausbleibende Ergebnisse. Ein einfacher Zeitstempel-Check reicht: Wenn seit mehr als einer Stunde kein Abgleich stattgefunden hat, eine Nachricht auf das Handy. Das kostet einmal zwanzig Minuten Einrichtung und hat bei mir schon mehrfach einen halben Tag Bestellrückstand verhindert.

Kennwortablauf abschalten. Läuft das Kennwort des Dienstkontos ab, kommt Fehler 1069 zurück — Monate später, wenn niemand mehr an die Worker-Installation denkt.

Dokumentieren, unter welchem Konto der Dienst läuft. Klingt banal. Beim nächsten Serverwechsel oder wenn ein Kollege danach sucht, spart diese eine Zeile in der Dokumentation eine halbe Stunde Rätselraten.