20.07.2011, aktualisiert am 21.07.2011

8884

Batch wird nicht über Scheduler gestartet

Hallo,

ich weiß, diese Frage wurde hier schon mehrfach gestellt, aber nie richtig gelöst bzw. beantwortet.

Ich habe ein Batch geschrieben, das wenn ich es in der cmd starte einwandfrei läuft. Wenn ich das über die Aufgabenplanung starte dann steht zwar am Ende das es erfolgreich ausgeführt wurde, aber mit einem Returncode 255. Das Batch wurde auch definitiv nicht abgearbeitet. Das kann ich an Variablen sehen, die gesetzt werden müssten (vom Batch) aber nicht sind.

Hier mal das Batch:

@ echo off
set groesse=%check3:~0,30%
for %%F in (%groesse%) do set size=%%~zF
echo %size%
if %size% leq 79999999 goto kleiner 
if %size% geq 80000000 goto groesser 

:kleiner
set serrcd=2
set sergebnis=ACHTUNG Die Datei ist kleiner als 80 MB 
goto senden

:groesser
set serrcd=0
set sergebnis=Die Datei ist groesser als 80 MB
goto senden

:senden
set host=xxx.xxx.xxx
set sservice=Backup_Groesse
set stest=%host%	%sservice%	%serrcd%	%sergebnis%
echo %stest% >C:\sergebnis.txt
cd c:\send_nsca_win32_src\send_nsca\bin\
send_nsca.exe -H XXX -p 5667 -c C:\send_nsca_win32_src\send_nsca\bin\send_nsca.cfg <C:\sergebnis.txt

Hier kann man sehen, das die Variablen leer sind nach Ablauf des Batch:

C:\>echo %groesse%   %serrcd%    %size%
%groesse%   %serrcd%    %size%

Hier die Ausgabe aus der Aufgabenplanung:

Die Aufgabenplanung hat die Aufgabe "\Filolos_Backup_Groesse", Instanz "{174cdff3-cddf-4f8c-b654-36da1b6e3459}", Aktion "C:\Windows\SYSTEM32\cmd.exe" mit Rückgabecode 255 erfolgreich abgeschlossen.  

Das Batch wird mit meinem Account ausgeführt (Admin) auch die Rechte für die Stapelverarbeitung hat mein Account. Ein zweites Batch läuft völlig fehlerfrei durch. Auch dieses habe ich selber geschrieben. Das macht in der Aufgabenplanung keine Schwierigkeiten.

Das Batch liegt direkt im C:\ und ausführen Rechte hat jeder.

Ich weiß leider nicht mehr wo ich noch suchen soll. Vielleicht findet ja jemand von Euch sofort einen Fehler den ich vor lauter suchen überhaupt nicht mehr sehe.

Es handelt sich um einen Win 2008 R2 Server.

Ich danke für jede Hilfestellung schon mal im voraus.

Gruß Oli

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

Content-ID: 170097

Url: https://administrator.de/forum/batch-wird-nicht-ueber-scheduler-gestartet-170097.html

Ausgedruckt am: 22.12.2024 um 15:12 Uhr

20 Kommentare

Neuester Kommentar

Hallo Oli,

Du kannst nicht erwarten, dass das Batchfile Variablen setzt und Du die dann außerhalb des Batchfiles zur Verfügung hast. Die Variablen existieren nur solange das Batchfile läuft. Wenn Du die Werte nachher brauchst, musst Du sie innerhalb des Batchfiles in eine Datei schreiben, die Du später ausließt.

Gruß
Friemler

Hallo,

doch das funktioniert. Die Variablen sind fest im System gesetzt. Die variablen, die mein anderes Batchfile schreibt sind auch immer noch im System.

Nur als Beispiel, eine die dieses Batch ganz am Anfang nutzt:

C:\>echo %check3:~0,30%
N:\DEF.zip

Gruß

Hallo Oli,

bei mir funktioniert sowas nicht, habe gerade einen Test durchgeführt. Ich wüsste auch nicht, wie das gehen sollte (außer mit Zusatztools). Die Batch wird von einem CMD-Prozess ausgeführt, der die Umgebungsvariablen seines Elternprozesses erbt. Dieses geerbte Environment wird von der Batch verändert. Wenn der ausführende CMD-Prozess beendet wird, ist auch das veränderte Environment Geschichte.

Gruß
Friemler

Moin,

ich weiß, diese Frage wurde hier schon mehrfach gestellt, aber nie richtig gelöst bzw. beantwortet.

dann hast du doch bestimmt 1- 10 Beispiele/gestellte Fragen, die wir "richtig" lösen oder beantworten könnten?

mein anderes Batchfile schreibt sind auch immer noch im System.

Mach mir kein X für ein U vor...

Apropos X, SETx kann das

PS: Ich würde ja grob anhand der Datei C:\sergebnis.txt erkennen, ob die Batch gelaufen ist oder nicht....
edit

send_nsca.exe -H 192.168.20.100 -p 5667 -c C:\send_nsca_win32_src\send_nsca\bin\send_nsca.cfg <C:\sergebnis.txt
was soll uns diese zeile sagen?

/edit

Gruß

Hallo Oli,

Wie wäre es mit folgender Theorie:

Die Variable check3 ist nicht vorhanden. Deshalb wird in Zeile 3 Deines Scripts die Variable size nicht gesetzt. Daraufhin schlägt die Ausführung von Zeile 5 fehl (dort steht dann nämlich if leq 79999999 goto kleiner). -> Das Batchfile bricht mit einem Syntaxfehler ab.

Übrigens: SETX setzt Werte in der Registry, die meines Wissens nach einen Reboot nicht überleben.

Gruß
Friemler

Zitat von @60730:

Moin,

> ich weiß, diese Frage wurde hier schon mehrfach gestellt, aber nie richtig gelöst bzw. beantwortet.

dann hast du doch bestimmt 1- 10 Beispiele/gestellte Fragen, die wir "richtig" lösen oder beantworten

könnten?

Gerade von Dir habe ich schon sehr viele hilfreiche Hinweise gelesen. Wollte damit auch nichts negatives ausdrücken.

> mein anderes Batchfile schreibt sind auch immer noch im System.

Mach mir kein X für ein U vor...

Apropos X, SETx kann das

Verdammt, wenn man das cmd schließt sind die Daten weg. Ich Depp, habe das immer im selben Fenster versucht. So Blöd muss man erst mal sein. *schäm*

PS: Ich würde ja grob anhand der Datei C:\sergebnis.txt erkennen, ob die Batch gelaufen ist oder nicht....

Auch daran kann ich sehen, das es nicht gelaufen ist. Die Datei ist nicht da. Erklärt sich aber auch durch meine Feststellung eben.

edit
> send_nsca.exe -H XXX -p 5667 -c C:\send_nsca_win32_src\send_nsca\bin\send_nsca.cfg <C:\sergebnis.txt
> was soll uns diese zeile sagen?
/edit

Hier wird nur ein passiver Check an einen Server übergeben, auf dem Icinga läuft.

Aber nun nochmal zu SETx, kannst Du mir das vielleicht nochmal erläutern? Das die Variablen nach einen Reboot verschwinden, wäre nicht so dramatisch. Erstmal ist das ein Server und startet dadurch eh nicht so oft neu, zweitens soll das Batch jede Nacht laufen um die Daten zu testen. Von daher werden die eh immer wieder neu generiert.

Ich hatte auch schon versucht, die Zeilen mit in das erste Batch zu schreiben. Trotzdem beendet er das in der CMD korrekt und im scheduler mit Returncode 255.

Macht es Sinn, das erste Batch hier auch zu posten?

Ich danke schon mal für die Kopfnuss. Komm immer noch nicht über meinen eigenen Blödsinn hinweg. Sorry.

Auch bei Dir möchte ich mich nochmal entschuldigen, das ich Deiner Aussage nicht geglaubt habe. Wie Du oben lesen kannst hab ich das ein wenig dämlich getestet. Wird mir garantiert nicht wieder passieren.

Du hast mit Deiner Theorie vollkommen Recht. Da die Variable nicht vorhanden ist, kann es nur zu einem Fehler führen.

Auch an Dich die bitte, mir das mit dem SETx noch mal zu erklären.

Danke.

Und um die Frage vorweg zu nehmen, Nein ich habe nicht bis jetzt gebraucht um meinen Fehler festzustellen. War nur nochmal in der Firma weil ich Updates installieren musste und einen Neustart nur Nachts machen kann.

)

Hi Oli,

klassischer Fehler, nimm's locker, war halt nicht Dein Tag

.

SETX ist ein Konsolentool von Microsoft, das in Server 2008 enthalten sein müsste. Eine Beschreibung gibt es hier. Damit kannst Du das von Dir gewünschte erreichen. Allerdings wäre es eine Überlegung wert, ob Du Dein Problem nicht anders lösen könntest. Dafür wäre es natürlich nützlich, das andere Batchscript zu kennen und genaueres über die Hintergründe zu wissen.

Von wegen der Aussage "Die gesetzten Variablen überleben einen Reboot nicht" - vergiss es.

Aber Achtung!
Die Variablen, die Du mit SETX im globalen Environment setzt, sind in dem Batchfile, in dem Du den Befehl ausführst, nicht direkt vorhanden, erst in danach gestarteten Instanzen von CMD! Um das zu umgehen (falls Du die Variablen auch im weiteren Verlauf des aktuellen Batchfiles benötigst), musst Du die Variablen nochmal mit dem normalen SET-Befehl setzen.

Gruß
Friemler

Hallo,

hier ist das erste Batch:

@ echo off
set dat=%Date%
set day=%date:~0,2%
set month=%date:~3,2%
set year=%date:~6,4%
REM @ echo %year%%month%%day%

set /a day-=1
if %day% LEQ 0 set /a month-=1
if %month% LEQ 0 set /a year-=1 & set month=12

if %day% GEQ 01 goto done
rem day one moth ago, proper day
if %month% EQU 1 set day=31
if %month% EQU 3 set day=31
if %month% EQU 4 set day=30
if %month% EQU 5 set day=31
if %month% EQU 6 set day=30
if %month% EQU 7 set day=31
if %month% EQU 8 set day=31
if %month% EQU 9 set day=30
if %month% EQU 10 set day=31
if %month% EQU 11 set day=30
if %month% EQU 12 set day=31

if %month% NEQ 2 goto done
rem *** day in February, assay leap year
set /a mod4=year % 4
set /a mod100=year % 100
set /a mod400=year % 400
set day=28
if %mod4% NEQ 0 goto done
set day=29
if %mod100% NEQ 0 goto done
set day=28
if %mod400% NEQ 0 goto done
set day=29
:done
set /a day=%day%+100
set day=%day:~1,2%
set /a month=%month%+100
set month=%month:~1,2%

set gestern=%year%%month%%day%
set check1="N:\XYZ%gestern%.zip,  
set check2=N:\ABC%gestern%.zip,
set check3=N:\DEF%gestern%.zip,
set check4=N:\GHI%gestern%.zip"  
set check=%check1%%check2%%check3%%check4%
set host=xxx
set service=Backup_Pruefung
REM Prüfung
cd c:\
check_file.exe --target %check% --filter "age le 24h" --critical 0 >C:\test.txt  

REM Prüfung ob als Ausgabe ein "Files OK" zurückkommt.  
for /f "delims=" %%i in (C:\test.txt) do set ergebnis=%%i  
set pruefung=%ergebnis:~5,2%
if not "%pruefung%" == "OK" set errcd=2  
if "%pruefung%" == "OK" set errcd=0  
set test=%host%	%service%	%errcd%	%ergebnis%
echo %test% >C:\ergebnis.txt
cd c:\send_nsca_win32_src\send_nsca\bin\
send_nsca.exe -H xxx -p 5667 -c C:\send_nsca_win32_src\send_nsca\bin\send_nsca.cfg <C:\ergebnis.txt

Dieses prüft ob gewisse Dateien vorhanden sind und schickt das Ergebnis auch wieder an Icinga.

Bei einer dieser Dateien will ich auch noch wissen ob es eine gewisse Größe hat. Dies soll das zweite Batch prüfen. Ich hatte das anfänglich alles in einem Batch stehen, dann kam aber auch am Ende der Returncode 255, deswegen habe ich das zum testen auseinander gezogen. Wobei mir dann der Fehler mit den Variablen passiert ist.
Allerdings weiß ich immer noch nicht warum das nicht läuft.

Hast Du da noch einen Tipp?

Gruß Oli

Hallo Oli,

ich habe Dein Script Nr. 1 mal überarbeitet:

@echo off & setlocal


set "VBScript=%Temp%\GetDateOfYesterday.vbs"  

> "%VBScript%" echo strYesterday = DateAdd("d", -1, Now)  
>>"%VBScript%" echo WScript.Echo Right("0" ^& Day(strYesterday), 2) ^& "." ^& _  
>>"%VBScript%" echo              Right("0" ^& Month(strYesterday), 2) ^& "." ^& _  
>>"%VBScript%" echo              Year(strYesterday)  

for /f "tokens=1-3 delims=." %%a in ('cscript /nologo "%VBScript%"') do (  
  set "Day=%%a"  
  set "Month=%%b"  
  set "Year=%%c"  
)

del "%VBScript%"  


set "gestern=%year%%month%%day%"  
set "check1=N:\XYZ%gestern%.zip"  
set "check2=N:\ABC%gestern%.zip"  
set "check3=N:\DEF%gestern%.zip"  
set "check4=N:\GHI%gestern%.zip"  
set "check="%check1%","%check2%","%check3%","%check4%""  

set "host=xxx"  
set "service=Backup_Pruefung"  


REM Prüfung ob als Ausgabe ein "Files OK" zurückkommt.  
for /f "tokens=2" %%i in ('call "C:\check_file.exe" --target %check% --filter "age le 24h" --critical 0') do set "ergebnis=%%i"  

if /i "%ergebnis%" equ "OK" (  
  set "errcd=0"  
) else (
  set "errcd=2"  
)

>"C:\Ergebnis.txt" echo %host% %service% %errcd% %ergebnis%  

cd /d "C:\send_nsca_win32_src\send_nsca\bin"  
<"C:\Ergebnis.txt" send_nsca.exe -H xxx -p 5667 -c "send_nsca.cfg"  

Meine Änderungen:

Zunächstmal habe ich den Batchcode zur Berechnung des gestrigen Datums entfernt und durch ein Inline-VBScript ersetzt. Das ist erstens kürzer und übersichtlicher und zweitens sicherer, da vom eingestellten Datumsformat des Systems unabhängig.
Ich habe drei goldene Regeln für Batchscripting angewandt:

Die Zuweisungen von SET-Befehlen immer in Anführungszeichen setzen - das vermeidet Probleme mit eventuell enthaltenen Sonderzeichen und verhindert, dass sich versehentlich ein Leerzeichen an den zuzuweisenden Wert anhängt.
Pfade und Variablen, die Pfade enthalten, immer in Anführungszeichen einschließen - das vermeidet Probleme mit Pfaden, die Leerzeichen enthalten.
Bei ECHO-Befehlen, die per Ausgabeumleitung in eine Datei schreiben sollen, die Umleitung immer vor den ECHO-Befehl schreiben - vermeidet auch Probleme. Zu erklären welche, wäre jetzt zu langatmig.

Ich habe die Ermittelung des Rückgabewertes von check_file.exe optimiert (Zeile 32). Ich bin aufgrund Deines Codes davon ausgegangen, dass das Programm in C:\ liegt, evtl anpassen. Der CALL-Befehl vor dem Programmpfad steht dort zur Sicherheit, falls der reale Pfad Leerzeichen enthält; in dem Fall ist CALL notwendig. Die Prüfung ob OK zurückgeliefert wurde (Zeile 34) berücksichtigt wegen if /i die Groß-/Kleinschreibung nicht. BTW: Ist File OK die einzige Ausgabe des Programms oder kommen da noch mehr Zeilen vorher/hinterher? In dem Fall funktioniert es so nicht.
Du wechselst an zwei Stellen mit cd <Verzeichnis> das Verzeichnis. Ich nehme mal an, dass Du damit beabsichtigt hast, das jeweilige Verzeichnis zum aktuellen Verzeichnis zu machen. Dazu muss aber cd /d <Verzeichnis> verwendet werden. Einer dieser Befehle im Zusammenhang mit check_file.exe ist weggefallen, den anderen habe ich angepasst (Zeile 42).

Da in diesem Batchfile der Wert von errcd davon abhängt, was check_file.exe zurückliefert und in dem Batchfile aus Deinem Eröffnungsposting von der Größe der Datei N:\DEF%gestern%.zip, konnte ich das nicht unter einen Hut bringen/nicht einbauen, dazu müsstest Du zuerst noch ein paar Worte verlieren.

Teste jetzt erstmal meinen Code, dann sehen wir weiter.

Zitat von @OlibSyl:
Allerdings weiß ich immer noch nicht warum das nicht läuft.

Was meinst Du damit genau? Meinst Du Dein Script Nr. 1 oder verstehst Du den Fehler noch nicht so ganz, den Du gemacht hast?

Gruß
Friemler

Hallo Friemler,

dazu kann ich nur ein Wort sagen:
PERFEKT!!!!

Ich muss mir das VBS mal in Ruhe ansehen um zu verstehen was es macht. Vielleicht begreif ich es ja auch irgendwann.

Zitat von @Friemler:
Da in diesem Batchfile der Wert von errcd davon abhängt, was check_file.exe zurückliefert und in dem Batchfile
aus Deinem Eröffnungsposting von der Größe der Datei N:\DEF%gestern%.zip, konnte ich das nicht unter einen Hut
bringen/nicht einbauen, dazu müsstest Du zuerst noch ein paar Worte verlieren.

Mache ich gerne. Das erste Script prüft ob vier verschiedene Dateien vorhanden sind. Diese werden jede Nacht neu erstellt, nach dem Prinzip [Dateiname][Datum].zip. Dafür brauche ich das Datum von gestern. Der zweite Teil, den ich nicht zum laufen bekommen habe prüft ob eine bestimmte dieser drei Dateien eine gewisse Größe hat (um festzustellen, das nicht eine leere oder kleine zip Datei geschrieben wurde). Je nach Größe der Datei soll wieder eine Meldung an Icinga verschickt werden (größer 80 MB alles O.K., kleiner 80 MB Achtung hier ist was falsch).

Ich hatte beide Scripte in einer Datei. Wenn ich es in einer cmd ausgeführt habe war alles gut. Habe ich das in den scheduler gepackt, lief es auch durch aber mit einem Returncode 255 und der zweite Teil (der mit der Prüfung der Größe) lieferte kein Ergebnis. Dann kam meine geistige Umnachtung und ich dachte "Hey packst es einfach in zwei Scripte und guckst mal". Solange es in einer cmd lief war auch alles gut. Dann über den scheduler lief das erste. Das zweite meldete erfolgreich 255 und schickt kein Ergebnis an Icinga (läuft also nicht).
Das war der Punkt wo ich Anfing im Netz zu suchen.

Den Rest kennst Du

Hallo Oli,

also soll nur eine zusätzliche Nachricht erzeugt werden. Dann sollte es ja ausreichen, folgenden Code an mein Script anzuhängen:

for %%f in ("%check3%") do set "size=%%~zf"  
if %size% leq 79999999 (
  set "errcd=2"  
  set "ergebnis=ACHTUNG Die Datei ist kleiner als 80 MB!"  
) else (
  set "errcd=0"  
  set "ergebnis=Die Datei ist groesser als 80 MB."  
)

set "service=Backup_Groesse"  
>"C:\sergebnis.txt" echo %host%  %service%  %errcd%  %ergebnis%  
<"C:\sergebnis.txt" send_nsca.exe -H XXX -p 5667 -c "send_nsca.cfg"  

Das VBScript ist eigentlich ganz simpel. Die erste Zeile mit dem DateAdd addiert -1 auf das aktuelle Datum (Now) und berechnet so das Datum vom Vortag. Die folgenden Ausdrücke (z.B. Right("0" & Month(strYesterday), 2)) extrahieren den Tag, den Monat bzw. das Jahr aus diesem Datum und sorgen dafür, dass Monat und Tag führende Nullen haben (z.B. "verkette "0" und die Monatsnummer, nimm vom resultierenden String 2 Zeichen von rechts"). Statt & steht da ja immer ^&, das ist nötig um das & zu "escapen", damit CMD beim Ausführen der Zeilen das & nicht als Steuerzeichen für sich selbst interpretiert, sondern es einfach in die Zieldatei schreibt. Durch den Operator _ am Ende der ersten beiden Zeilen werden die Zeilen 2 bis 4 miteinander verkettet und als eine Zeile interpretiert. Zwischen den Zahlenwerten werden als Trennzeichen noch Punkte ausgegeben. Die werden von der nachfolgenden FOR-Schleife, die das VBScript ausführt und seine Ausgabe auswertet, als Trennzeichen behandelt (delims=.) um so an die einzelnen Werte zu kommen.

Ist Dein Problem damit gelöst? Dann möchte ich schonmal an den "grünen Haken" erinnern

.

Gruß
Friemler

Hallo Friemler,

leider ist es noch nicht ganz gelöst.

Der erste Teil funktioniert. Sieht man an der Ausgabe:

1 data packet(s) sent to host successfully.

Der zweite Teil leider noch nicht.

Erst kam der Fehler:

Der Befehl ""set size="" ist entweder falsch geschrieben oder konnte nicht gefunden werden.

Das habe ich geändert in set "size=..."

Dann kam der Fehler:

"79999999" kann syntaktisch an dieser Stelle nicht verarbeitet werden.

Und da weiß ich leider nicht warum. Heißt das das "size" nicht gefüllt ist und er daher nicht prüfen kann?

Bei der Variablen check3 ist nun auch noch das "," am Ende. Kann das da stehen bleiben oder stört das? Deswegen hatte ich das mit %check3:~0,30% gemacht, damit das Komma am Ende abgeschnitten wird.

Hallo Oli,

tja, das kommt davon, wenn man (ich) nachträglich noch am Script herumfummelt

. Kopiere Dir noch mal die aktuelle Version des Scripts, da ist das Komma bei den Variablen checkX entfernt. Dann sollte es funktionieren.

[EDIT]
Die Erweiterung enthielt auch noch einen Fehler

. Bitte auch noch mal neu kopieren.
[EDIT2]
Ah, den hast Du ja schon korrigiert (die Anführungszeichen bei set size=..).
[/EDIT2]
[/EDIT]

Gruß
Friemler

Hallo Friemler,

leider immer noch nicht. Nun kommt folgende Fehlermeldung:

"else" kann syntaktisch an dieser Stelle nicht verarbeitet werden.

Müsste das erste sein. Ich habe ein echo bei der zweiten Abfrage gemacht und bis dahin kommt er schon nicht.

Hallo Oli,

Zeile 32 enthielt nochmal den gleichen Fehler bzgl. Anführungszeichen bei set ergebnis=...

. Ist bereits korrigiert.

Gruß
Friemler

Hallo Friemler,

es wäre echt zu schön um wahr zu sein.

In der cmd läuft es nun perfekt. Leider wieder nicht über den scheduler. Wieder Returncode 255, und auf dem Icinga kommt dann folgende Meldung:

 PASSIVE SERVICE CHECK: host;Backup_Pruefung;2;UNKNOWN

Das ist auch das was in der ergebnis.txt drin steht.

Hallo Oli,

tja, da musst Du nochmal die Ausgabe von check_file.exe genauer analysieren. Starte es mal direkt mit den Parametern, die in der FOR-Schleife im Script verwendet würden. Ich hatte ja (aber auch nachträglich

) geschrieben, dass man da nochmal forschen muss, und zwar für ein positives als auch für ein negatives Ergebnis.

BTW: Die ganzen Werte %host% %service% %errcd% %ergebnis% werden ja in eine Zeile von C:\ergebnis.txt bzw. später C:\sergebnis.txt geschrieben. Im zweiten Fall ist das ja ein String (z.B. ACHTUNG Die Datei ist kleiner als 80 MB!), der Leerzeichen enthält. Wenn es möglich ist, sollte deshalb %ergebnis% in beiden Zeilen in Anführungszeichen eingeschlossen werden, damit das auch als zusammenhängender Wert erkannt wird.

Gruß
Friemler

So, habe das Problem nun gelöst.

Ich habe das im Scheduler immer laufen lassen mit "Unabhängig von der Benutzeranmeldung ausführen". Dadurch konnte das nicht funktionieren.

Hier die Erklärung von Friemler dazu (Vielen Dank dafür nochmal an dieser Stelle):

mit der Einstellung, wie Du sie vorher hattest, läuft der CMD-Prozess, der das Batchfile ausführt, in Session 0. Diese Session ist für Dienste und Systemprozesse vorgesehen und nicht interaktiv, d.h. es wird dem Prozess auch keine Konsole zugeordnet. Deshalb funktionieren die Ein-/Ausgabeumleitungen im Batchfile und somit auch der ganze Ablauf nicht.

Session 0 ist ein Sicherheitsfeature von MS seit Vista. Normale Programme (auch der Desktop) laufen in Session 1, TS-Sessions haben höhere Nummern. Eine Kommunikation zwischen Prozessen in Session 0 und Session 1 ist nicht möglich, es gibt lediglich einen API-Aufruf , mit dem ein Dienst einen einfachen Popup mit nur einem OK-Button anzeigen kann. Die Sessionnummer eines Prozesses wird im Taskmanager angezeigt, wenn die Spalte "Sitzungskennung" aktiviert ist. 

Ich habe jetzt einen Benutzer angelegt, der immer angemeldet sein muss und unter dessen credentials dieser Task läuft. Dann klappt das auch hervorragend.

Gruss Oli

gelöst Frage Microsoft Windows Server

Mehr von OlibSyl

NFS Mount einer schon per NFS gemounteten FreigabeOlibSyl - 1 Kommentar

Word 2010 - Dokumentenvorlage mit Feldern die nur unter bestimmten Bedingungen eingeblendet werdenOlibSyl - 4 Kommentare

Lagerverwaltung Open-SourceOlibSyl - 1 Kommentar

Ausdruck in Mail umleitenOlibSyl - 2 Kommentare

Heiß diskutiert