none
Batch Dateien in der Aufgabenplanung als ausführbares Programm RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Guten morgen Zusammen,

    ich habe 4 Batchdateien auf unserem 2008R2 x64 Server in einem lokalen Ordner und diese in der Aufgabenplanung eingebunden. Es werden täglich Dateien auf ein externes Laufwerk kopiert. Das ging seit Mitte Dezember super. Jetzt musste ich aber das Kennwort des Benutzerkontos ändern (nicht zurücksetzen, sondern normal ändern), mit dem díe Aufgabe gestartet wird. Das Kennwort habe ich natürlich in der Aufgabenplanung auch geändert. Aber trotzdem laufen die Batchfiles nicht mehr über den Taskplaner. Wenn ich sie normal über den Explorer anklicke, klappt es natürlich bestens. An den eigentlichen Berechtigungen des Users liegt es nicht. Eigenartigerweise meldet der Taskplaner 0x1 und 0x4 zurück, vorher war es 0x0.

    Dieses Verhalten kenne ich vom 2003er Server nicht. Aber bei Win7 und 2008R2 hab ich es schon öfters gehabt. Ich hab soviele BAT Dateien im Einsatz und würde sie gerne weiterverwenden.

    Donnerstag, 17. Februar 2011 10:07
    |

Antworten

  • Question
    Anmelden
    1
    Anmelden

    Ein Neustart des Servers kann in Hinsicht auf Sicherheitsrechte durchaus Sinn machen!

    Ich hatte mal einen neu angelegten Benutzer der partout nicht auf ein Verzeichnis zugreifen konnte. Nach dem Neustart des Servers lief alles einwandfrei!

    Donnerstag, 24. Februar 2011 14:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Bernd

    wurde das Problem durch den Neustart behoben?

    Gruß
    Andrei

    Dienstag, 1. März 2011 10:56
    |
    Moderator

Alle Antworten

  • Question
    Anmelden
    0
    Anmelden

    Am 17.02.2011 schrieb Bernd Marscheider:

    ich habe 4 Batchdateien auf unserem 2008R2 x64 Server in einem lokalen Ordner und diese in der Aufgabenplanung eingebunden. Es werden täglich Dateien auf ein externes Laufwerk kopiert. Das ging seit Mitte Dezember super. Jetzt musste ich aber das Kennwort des Benutzerkontos ändern (nicht zurücksetzen, sondern normal ändern), mit dem díe Aufgabe gestartet wird. Das Kennwort habe ich natürlich in der Aufgabenplanung auch geändert. Aber trotzdem laufen die Batchfiles nicht mehr über den Taskplaner. Wenn ich sie normal über den Explorer anklicke, klappt es natürlich bestens.

    Laufen die Batches auch, wenn Du dich als der ausführende Benutzer
    anmeldest? Gibt es Fehlermeldungen im Eventlog?

    An den eigentlichen Berechtigungen des Users liegt es nicht. Eigenartigerweise meldet der Taskplaner 0x1 und 0x4 zurück, vorher war es 0x0.

    Lt. http://support.microsoft.com/kb/308558 ist 0x1 Eine falsche oder
    unbekannte Funktion wurde aufgerufen.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 17. Februar 2011 10:32
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Wilfried,

     

    danke für die schnelle Antwort. Die Batch läuft mit dem extra angelegtem "scriptuser". Der ist Dom-Admin. Sie lief ja 9 Wochen problemlos. Es werden auch nur ein paar Dateien kopiert. Ich vermute die Ursache in gecachten Accountinformationen, die nicht oder noch nicht aktualisiert werden können. Bzw. die nach der Kennwortännderung nicht validiert werden können.

    Donnerstag, 17. Februar 2011 11:40
    |
  • Question
    Anmelden
    0
    Anmelden
     Die Batch läuft mit dem extra angelegtem "scriptuser". Der ist Dom-Admin.

    Dir ist aber klar, das dies sicherheitstechnisch nicht gerade das Optimum ist?

    Die Dateien werden lokal auf dem Server kopiet oder von wo nach wo?
    Welche Informationen stehen im SCHEDLGU.log in C:\Windows\Tasks\ ?

    Donnerstag, 17. Februar 2011 12:04
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 17.02.2011 schrieb Bernd Marscheider:

    Hallo Wilfried,

    Immer noch Winfried. ;)

    danke für die schnelle Antwort. Die Batch läuft mit dem extra angelegtem "scriptuser". Der ist Dom-Admin. Sie lief ja 9 Wochen problemlos. Es werden auch nur ein paar Dateien kopiert. Ich vermute die Ursache in gecachten Accountinformationen, die nicht oder noch nicht aktualisiert werden können. Bzw. die nach der Kennwortännderung nicht validiert werden können.

    Probier die Ausführung mit einem anderen Benutzer, bei dem das
    Kennwort nicht kürzlich geändert wurde.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 17. Februar 2011 13:50
    |
  • Question
    Anmelden
    0
    Anmelden

    Das ist eine vorgefundene Konfiguration. Vom Optimum zwar weit entfernt, aber die roten Stop-marken im Ereignisprotokoll reduzieren sich allmählich. Wir sind also auf einem guten Weg. Die Datei SCHEDLGU.log existiert nicht.

    Die Dateien werden von einem lokalen Datenträger auf einen externen, am USB Anschluß angeschlossene Platte kopiert. Nichts Komplziertes.

    copy *.* \\Zielrchner\Freigabe

     

    Donnerstag, 17. Februar 2011 14:38
    |
  • Question
    Anmelden
    0
    Anmelden

    WiNfried, ich habe mich gerade mal mit RDP draufgeschaltet und die Ordner aufgeklickt, von wo nach wo es hin geht.

    Es kommt immer die Meldung "Sie müssen Administratorberechtigungen angeben". Obwohl der User einer ist. Nach einem Klick geht es denn auch ohne Murren und Knurren weiter.

    Donnerstag, 17. Februar 2011 14:45
    |
  • Question
    Anmelden
    0
    Anmelden

    Am 17.02.2011 schrieb Bernd Marscheider:

    WiNfried, ich habe mich gerade mal mit RDP draufgeschaltet und die Ordner aufgeklickt, von wo nach wo es hin geht.

    Es kommt immer die Meldung "Sie müssen Administratorberechtigungen angeben". Obwohl der User einer ist. Nach einem Klick geht es denn auch ohne Murren und Knurren weiter.

    Hat der Benutzer keine Adminrechte? Wenn ja, dann sperrt UAC den
    Vorgang. Von wo nach wo willst Du kopieren?

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 17. Februar 2011 15:19
    |
  • Question
    Anmelden
    1
    Anmelden

    Hast du in den Eigenschaften der Aufgabe, den Haken gesetzt,
    "Mit höchsten Privilegien ausführen"?

    Kannst du dich mit dem User am Zielrechner anmelden, bzw. existiert dort ggf. noch eine alte Session dieses Users?

    Was du noch probieren kannst, den Befehl in ein Textfile leiten, also pfad\script.bat >%temp%\script.log.
    So lässt sich erkennen, ob das Script überhaupt ausgeführt wird und wenn ja, welche Fehlermeldung der Kopierbefehl ausgibt.

    Donnerstag, 17. Februar 2011 16:27
    |
  • Question
    Anmelden
    0
    Anmelden

    Mit höchsten Privilegien klappt es. Aber warum ist das auf einmal nötig?? Nundenn, es klappt und deshalb verfahren wir nach Regel 1: Do not change a running system.

    Danke Euch allen.

    Mittwoch, 23. Februar 2011 08:57
    |
  • Question
    Anmelden
    0
    Anmelden

    Für mich klingt das ebenfalls nach einem Rechteproblem beim "scriptuser". Hast du schon die auf deinem Datenträger gesetzten NTFS-Rechte überprüft?

    Ist der User vllt. in eine andere Sicherheitgruppe reingerutscht von der aus ihm die Adminrechte gesperrt werden?

    Mittwoch, 23. Februar 2011 09:18
    |
  • Question
    Anmelden
    1
    Anmelden

    Am 23.02.2011 schrieb Bernd Marscheider:

    Mit höchsten Privilegien klappt es. Aber warum ist das auf einmal nötig??

    Du hast die weiteren Tipps von Matthias noch nicht ausgeführt. Wenn Du
    eine Lösung haben willst dann probier die Tipps aus. Jetzt hast Du nur
    einen Workaround und weißt nicht woran es lag.

    Nundenn, es klappt und deshalb verfahren wir nach Regel 1: Do not change a running system.

    Schlechter Ansatz.

    Servus
    Winfried

    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Mittwoch, 23. Februar 2011 11:15
    |
  • Question
    Anmelden
    0
    Anmelden
    Der Hinweis ist gut. Ist auch eine beliebte Fehlerquelle. Ich habe aber einen User im AD kopiert und mit ihm seine Gruppenzugehörigkeiten. Haub auch schon nachgeschaut in der Policy. Unter "Anmeldung als Dienst" steht er auch drin.
    Donnerstag, 24. Februar 2011 07:38
    |
  • Question
    Anmelden
    0
    Anmelden

    Hab nun die Aufträge Taskplaner gelöscht und neu angelegt, mit einem User, der sein Kennwort noch nicht geändert hat. Nun laufen die Aufträge wieder, wie vorher. Mite einem neu angelegtem User geht es aber nicht. Es sieht so aus, das irgendetwas verhindert, das die notwendigen Berechtigungen vollständig durch die gesamte Registry durchgereicht werden.

    Donnerstag, 24. Februar 2011 08:08
    |
  • Question
    Anmelden
    0
    Anmelden

    Winfried, Du hast Recht. Der Ansatz ist schlecht, aber ich bin gerade bei einer Dynamics NAV Migration und bin eigentlich damit beauftragt den SQL Server mit Daten zu füttern. Die jetzt eingerichtete Datensicherung der Logfiles ist nur eine vorübergehende Lösung, damit nicht alles umsonst war, falls man den Server neu aufsetzen muß. Wenn die Anlage in Betrieb ist, werden wir wohl Logshipping konfigurieren.

    Ich bin aber andererseits zu neugierig, weil das Fehlerbild - (hab mal gegoogelt)  - öfters auftritt. 

    Donnerstag, 24. Februar 2011 08:16
    |
  • Question
    Anmelden
    0
    Anmelden

    Bin mir nicht ganz sicher ob es damit zusammenhängt aber gucken kann man ja mal:

    Beim Server unter lokale Sicherheitsrichtlinien gibt es unter Lokale Richtlinien->Zuweisen von Benutzerrechten eine Richtlinie "Anmelden als Stapelverarbeitungsauftrag". Prüfe doch mal ob einer der Gruppen denen der "scriptuser" angehört, in der Richtlinie eingetragen ist.

    Das hab ich jetzt nur auf die schnelle gefunden weil ich leider nich viel Zeit habe, allerdings ist das Problem sehr interessant! :)

    Donnerstag, 24. Februar 2011 10:44
    |
  • Question
    Anmelden
    0
    Anmelden

    Genau die Richtlinie meinte ich auch. Da ist er als Gruppenmitglied drin, also nicht namentlich, sondern als Mitglied der Gruppe Dom-Admins.

    Im Grunde wie der user auch, bei dem es funktioniert. Irgendwie scheint es tatsächlich so zu sein, das beim neu anlegen oder Kennwort ändern, einige Registry Schlüssel, nicht aktualisiert werden können, weil sie noch durch irgendeine Software geöffnet sind. Muss man womöglich den Server neu starten??

    Donnerstag, 24. Februar 2011 13:23
    |
  • Question
    Anmelden
    1
    Anmelden

    Ein Neustart des Servers kann in Hinsicht auf Sicherheitsrechte durchaus Sinn machen!

    Ich hatte mal einen neu angelegten Benutzer der partout nicht auf ein Verzeichnis zugreifen konnte. Nach dem Neustart des Servers lief alles einwandfrei!

    Donnerstag, 24. Februar 2011 14:39
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo Bernd

    wurde das Problem durch den Neustart behoben?

    Gruß
    Andrei

    Dienstag, 1. März 2011 10:56
    |
    Moderator
  • Question
    Anmelden
    0
    Anmelden

    Hallo Andrej,

     

    hab den Server noch nicht gestartet. Ich denke aber, das damit das Problem gelöst ist.

    Danke und Gruß

    Bernd

    Mittwoch, 2. März 2011 08:11
    |