Sheduled Task verliert dauernd den ausführenden Account

Hallo zusammen,

in unserem Fileserver Cluster läuft ein Task der alle 5 Minuten per Robocopy Daten von einer Freigabe in eine andere schreibt (Batch). Dies tut er mit einem eigenen AD Account mit entsprechenden Rechten. Der Task funktioniert einwandfrei. Allerdings schmeißt er unregelmäßig den Account raus und setzt den SYSTEM Account ein. Der Task bekommt natürlich dann den Fehler 0x10. Wenn ich den Service Account wieder eintrage ist erstmal wieder Ruhe für ein paar Tage. Wir haben zwei Fileserver die im Failover Clusterverbund laufen.

Vielleicht hängt es mir der wechselnden Rolle zusammen?!
Kann mir jemand sagen, warum der ständig den Account auf SYSTEM zurücksetzt?

Bitte keine Debatte über Sinn oder Unsinn. ;)

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 399655

Url: https://administrator.de/forum/sheduled-task-verliert-dauernd-den-ausfuehrenden-account-399655.html

Ausgedruckt am: 26.04.2025 um 13:04 Uhr

14 Kommentare

Neuester Kommentar

Hi,
hast Du den Task über den Namen eines Knotens oder den einer Fileserver-Rolle erstellt?

E.

Zitat von @emeriks:

Hi,
hast Du den Task über den Namen eines Knotens oder den einer Fileserver-Rolle erstellt?

E.

Den Task habe ich per PowerShell auf einem der beiden Fileserver erstellt. Ich hoffe das reicht als Antwort. ;)

# Filesync zwischen FS1 und Fileserver-Cluster

$Action = New-ScheduledTaskAction -Execute "M:\Scripts\filesyncfs1.bat"  
$Repeat = (New-TimeSpan -Minutes 5)
$Duration = ([timeSpan]::maxvalue)
$Trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).Date -RepetitionInterval $Repeat -RepetitionDuration $Duration

Register-ClusteredScheduledTask -Cluster "DE01FSC" -TaskName “Filesync zwischen FS1 und Fileserver-Cluster” -TaskType ResourceSpecific -Resource "DE01FS01-Shares" -Action $Action -Trigger $Trigger  

Am Rande, pragmatischer Ansatz:
Warum nicht als LocalSystem? LocalSystem läuft immer voll eleviert. Und mit Schalter "/B" oder "/ZB" bei Robocopy kann LocalSystem alle lokalen Daten kopieren, auch wenn LocalSystem nicht explizit NTFS-Berechtigungen dafür hat.

Ich hoffe das reicht als Antwort.

Ja. "Register-ClusteredScheduledTask" und "-TaskType ResourceSpecific -Resource "DE01FS01-Shares"" wollte ich wissen.

Edit: Aber wo sind die Credential?

Die Sache interessiert mich auch. Habe mal nachgelesen. Bin hierauf gestoßen:
https://social.technet.microsoft.com/Forums/ie/en-US/f3b2b5d2-b6ae-4091- ...

When you create a scheduled task, the password that is supplied for the task is stored in the Protected Storage database; the password is not stored in the actual task. When you create the scheduled task, the task is given a security descriptor.

Beim Verschieben der Rolle auf einen anderen Knoten hat der andere Knoten also nicht die betreffenden Anmeldedaten in seiner lokalen DB.

Möglicherweise könnte es helfen, die Job-Dateien zwischen den Knoten zu synchronisieren.Die Dateien findest Du unter

%systemroot%\Tasks

Die Credentials habe ich nachträglich eingetragen.

/B oder /ZB hilft nicht.

Die Batch macht das:

robocopy "\\FS1\SYS\BENUTZER\EE" "\\XXX.local\fs\shares\DE01\EEF\Daten Pruefergebnisse" /e /xo  

Dateifreigabe war hier missverständlich ausgedrückt. Es werden lediglich neue oder geänderten Dateien von FS1 zu Shares kopiert. Hier würde m. E. n. der LocalSystem wenig bringen.

Vielleicht hilfreich: FS1 ist ein alter Windows Server 2003 und unser Cluster 2012 R2.

Task müsste "mit höchsten Privilegien" laufen.
Du könntest die Computerkonten der Knoten in die Gruppe der "Backup Operatoren" oder der "Administratoren" des Win2003 aufnehmen.

Am Rande:
Warum nicht DFS-R? Sowas funktioniert auch mit FailoverCluster. Oder ist das noch ein 2003 ohne R2 ?

Zitat von @emeriks:

Task müsste "mit höchsten Privilegien" laufen.
Du könntest die Computerkonten der Knoten in die Gruppe der "Backup Operatoren" oder der "Administratoren" des Win2003 aufnehmen.

Am Rande:
Warum nicht DFS-R? Sowas funktioniert auch mit FailoverCluster. Oder ist das noch ein 2003 ohne R2 ?

leider kein R2, DFSR fällt aus.

Halt.
Ist doch ein R2, aber ich werde es jetzt noch einfacher machen. Ich lasse die Batch einfach auf FS1 in den Sheduled Tasks laufen. Wenn der Server irgendwann wegfällt brauchen wir auch den Task nicht mehr. Eigentlich dämlich, dass auf dem FS Cluster zu betreiben...

Zitat von @132501:
Ist doch ein R2, aber ich werde es jetzt noch einfacher machen. Ich lasse die Batch einfach auf FS1 in den Sheduled Tasks laufen. Wenn der Server irgendwann wegfällt brauchen wir auch den Task nicht mehr. Eigentlich dämlich, dass auf dem FS Cluster zu betreiben...

Warum einfach, wenn es auch kompliziert geht ...

Zitat von @emeriks:

Warum einfach, wenn es auch kompliziert geht ...

Bekommst trotzdem ne grünen Button für deine Mühe!

Zitat von @132501:
Bekommst trotzdem ne grünen Button für deine Mühe!

Och, wenn's bloß das wär, dann müssten es doch 5 oder 10 sein, oder?

Man lernt selbst - hoffentlich - nie aus.

Mh habe da noch was:
Server 2003 R2 kennt leider kein Robocopy. Windows Ressource Kit würde ich ja installieren, der Server darf aber nicht neustarten. Kann ich mit XCopy das Gleiche realisieren?