schtasks - Aufruf bringt Fehler: Falscher Parameter

[AndiMzD 1]

Hallo,

Ich habe eine einfache Task in taskschd.msc erstellt, nur ein

shutdown /r /f

Diese Task kann ich nun mit schtasks bedienen, z.B. so:

schtasks /change /TN Taskname /SD 27/06/2020

Es handelt sich hier also nicht mal um einen remote-Aufruf. Auf den meisten Servern funktioniert das einwandfrei. Aber auf einigen Windows Server 2016 funktioniert das Ändern des Datums mit schtasks nicht. Stattdessen kommt:

Fehler: Falscher Parameter

Prinzipiell spricht der Task auf diesem Server schon an, denn wenn ich absichtlich ein falsches Datum eingebe:

schtasks /change /TN Taskname /SD 32/06/2020

quittiert er das mit
Fehler: Ungültiges Startdatum

Warum bekomme ich die Meldung Fehler: Falscher Parameter und wie stelle ich das ab?

An der Version von Windows 2016 liegt es nicht.
Danke für Hinweise zur Behebung dieses Fehlers.

[BOfH_666 577]

vor 37 Minuten schrieb AndiMzD:

 

An der Version von Windows 2016 liegt es nicht.

... sind das alles "Deutsche" Server?  ... hast Du mal 

schtasks /change /TN Taskname /SD 06/27/2020

probiert?

 

BTW: Du hast in Deinem schtasks Aufruf oben ein "Sonderzeichen" drin ... wenn Du Dir die Zeile hier raus kopierst und in eine CMD einfügst, kannst Du das sehen ..  ich hoffe, das ist nur ein Tippfehler beim erstellen der Frage hier im Forum.   

bearbeitet 8. April 2020 von BOfH_666

[AndiMzD 1]

Danke für die Antwort.

Ich habe beide Befehle in eine Kommandozeile kopiert und kann kein Sonderzeichen entdecken.

Wenn ich als Datum 06/27/2020 übergebe quittiert er das mit 

Fehler: Ungültiges Startdatum

Damit hatte ich vorher schon rumgespielt. Er merkt sofort, wenn ich ein ungültiges Datum übergebe. 

Übergebe ich ein korrektes Datum bekomme ich 

Fehler: Falscher Parameter

Ich hatte den schtasks-Befehl händisch in die Kommandozeile getippt. Ist also nicht aus einem Skript, wo man Ansi-Verdrehung oder so vermuten könnte. 

Auf den meisten Servern funktioniert der identisch eingetippte Befehl.

Es ist eine komische Angelegenheit. Und ärgerlich, dass so eine einfache, langjährig zum BS gehörende kleine Anwendung plötzlich nicht funktioniert. 

Im Übrigen mag ich zwar hier als Newbie stehen, administriere aber schon seit über 20 Jahren, bin MCSE, Programmierer etc. 

 

VG

 

bearbeitet 8. April 2020 von AndiMzD
typo

[BOfH_666 577]

Hmmm ... dann muss ich leider passen. Wenn ich das hier auf einem 2019-er Server teste, funktioniert es wie erwartet. 

 

Du sagst, dass es auf einigen Servern nicht funktioniert. Was ist auf diesen Servern anders? Wurde kürzlich etwas geändert? Kannst Du die geplanten Aufgaben über die grafische Oberfläche ändern?  Hast Du's mal mit Powershell probiert?

[AndiMzD 1]

Hi,

habe die Lösung gefunden und lasse sie nun hier.

In die Eigenschaften der Task reingehen.
Reiter [Trigger], Bearbeiten

Im nun erscheinenden Dialogfenster, oben rechts, neben Datum und Zeit ist eine Checkbox namens
Zeitzonenübergreifende Synch.

Diese Checkbox darf nicht angehakt sein. 
Das war sie aber auf meinen Servern, auf denen es nicht funktionierte.

VG

[BOfH_666 577]

vor 4 Minuten schrieb AndiMzD:

Diese Checkbox darf nicht angehakt sein. 
Das war sie aber auf meinen Servern, auf denen es nicht funktionierte.

.... und wer war der Schlingel, der das Checkböxlein aktiviert hat?      

[AndiMzD 1]

Hi,

Nein, das war ich nicht. 

Diese Task wird mit der zentralen Servererstellung (= Virtuelle Maschine) immer eingerichtet. Ich muss nie einen Server hier von Scratch installieren. 

ich glaube nicht, dass es in anderen großen Umgebungen anders ist. Die werden wohl eh gecloned. 

Nur hatte es bisher immer gepasst und dieses Mal eben nicht. 

Sobald "jemand" etwas anders macht, hat das eben Auswirkungen und die Kunst ist, auch dann noch zur Lösung vorzudringen. 

bearbeitet 8. April 2020 von AndiMzD

[BOfH_666 577]

vor 11 Minuten schrieb AndiMzD:

ich glaube nicht, dass es in anderen großen Umgebungen anders ist.

... definiere "groß"!  

 

vor 12 Minuten schrieb AndiMzD:

ich glaube nicht, dass es in anderen großen Umgebungen anders ist.

... doch doch ... gibt's alles.   

 

vor 11 Minuten schrieb AndiMzD:

Die werden wohl eh gecloned. 

... nope ... und selbst wenn, sind ja trotzdem nicht alle Server in allem gleich ... oder?

[daabm 1.366]

vor 9 Stunden schrieb BOfH_666:

... nope ... und selbst wenn, sind ja trotzdem nicht alle Server in allem gleich ... oder?

Nein, sind sie nicht. Egal wie groß die Umgebung ist, egal wie stringent das Deployment - manche sind immer anders. Warum weiß niemand...

[AndiMzD 1]

Hi,

groß = mehr als 30tausend Clients.

Im Übrigen hat ein Windows Server 2012R2 dieses Problem nicht. Wenn dort das Häkchen gesetzt ist, kannst du den Befehl absetzen und hinterher ist es weg. 

Deswegen war das für lange Zeit vorher nie ein Problem. 

[BOfH_666 577]

vor 15 Minuten schrieb AndiMzD:

groß = mehr als 30tausend Clients.

OK ... da bin ich der gleichen Meinung ... das ist groß.    ...  solche Infrastrukturen sind aber schon nicht ganz alltäglich. Mein größter Kunde waren mal ca 24tsd  ... lange her.

vor 15 Minuten schrieb AndiMzD:

Im Übrigen hat ein Windows Server 2012R2 dieses Problem nicht. Wenn dort das Häkchen gesetzt ist, kannst du den Befehl absetzen und hinterher ist es weg. 

Deswegen war das für lange Zeit vorher nie ein Problem. 

Na sonst macht eine neue Betriebssystem-Version ja keinen Sinn, wenn mann nicht auch ein paar neue Fehler einbaut.     

[daabm 1.366]

vor 13 Stunden schrieb BOfH_666:

OK ... da bin ich der gleichen Meinung ... das ist groß. 

Geht so

 

Und das mit "ging bisher immer, geht jetzt nicht mehr" kenn ich zur Genüge - leider gibt es in nahezu jeder Software gelegentlich breaking changes. Man denke nur an MS15-025 und MS16-072.