12
Batch funktioniert auf einem von 30 Rechnern nicht
Windows XP Service Pack 1
Hallo,
zur Verwaltung von ca. 50 Rechnern mit unterschiedlichen Betriebssystemen habe ich einen kleinen Batchablauf geschrieben, der mir die Anmeldedaten der User in eine Datei schreibt.
@echo off
set PFAD="q:\datenaustausch\ip\ip.txt"
for /F "tokens=3,1" %%i in ('ver^|find "Windows"') do set WINVER=%%j
if %WINVER%==XP for /F "tokens=1,*" %%i in ('date/t') do set DATD=%%i
if not %WINVER%==XP for /F "tokens=1,*" %%i in ('date/t') do set DATD=%%j
for /F "tokens=1,*" %%i in ('time/t') do set TIM=%%i
for /F "tokens=1,*" %%i in ('ipconfig^|find "IP-Ad"') do set IP=%%j
for /F "tokens=1,*" %%i in ('ipconfig/all^|find "Host"') do set HOST=%%j
for /F "tokens=1,*" %%i in ('ipconfig/all^|find "Physi"') do set MACADR=%%j
echo %DATD%>>%pfad% : %TIM%>>%pfad% : %username%>>%pfad% : %IP%>>%pfad% : %HOST%>>%pfad% : %MACADR%>>%pfad%
Einer der 30 XP Rechner meldet: "for" ist an dieser Stelle syntaktisch nicht verarbeitbar
Wenn ich die WINVER Variable einzeln setze und den Batch nochmal starte, passiert im cmd-Fenster nichts mehr. Alle anderen Rechner schreiben brav ihre Daten in die Datei.
Hat jemand eine Idee, woran das liegen kann?
Hallo,
zur Verwaltung von ca. 50 Rechnern mit unterschiedlichen Betriebssystemen habe ich einen kleinen Batchablauf geschrieben, der mir die Anmeldedaten der User in eine Datei schreibt.
@echo off
set PFAD="q:\datenaustausch\ip\ip.txt"
for /F "tokens=3,1" %%i in ('ver^|find "Windows"') do set WINVER=%%j
if %WINVER%==XP for /F "tokens=1,*" %%i in ('date/t') do set DATD=%%i
if not %WINVER%==XP for /F "tokens=1,*" %%i in ('date/t') do set DATD=%%j
for /F "tokens=1,*" %%i in ('time/t') do set TIM=%%i
for /F "tokens=1,*" %%i in ('ipconfig^|find "IP-Ad"') do set IP=%%j
for /F "tokens=1,*" %%i in ('ipconfig/all^|find "Host"') do set HOST=%%j
for /F "tokens=1,*" %%i in ('ipconfig/all^|find "Physi"') do set MACADR=%%j
echo %DATD%>>%pfad% : %TIM%>>%pfad% : %username%>>%pfad% : %IP%>>%pfad% : %HOST%>>%pfad% : %MACADR%>>%pfad%
Einer der 30 XP Rechner meldet: "for" ist an dieser Stelle syntaktisch nicht verarbeitbar
Wenn ich die WINVER Variable einzeln setze und den Batch nochmal starte, passiert im cmd-Fenster nichts mehr. Alle anderen Rechner schreiben brav ihre Daten in die Datei.
Hat jemand eine Idee, woran das liegen kann?
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 23374
Url: https://administrator.de/contentid/23374
Ausgedruckt am: 01.11.2024 um 01:11 Uhr
12 Kommentare
Neuester Kommentar
du schreibst was von windows xp sp1, anschliessend von 50 rechnern
mit unterschiedlichen OS, anschliessend beziehst du dich auf 30 XP
rechner, is bissal schwer zu folgen, was da jetz für ein betriebssystem
am problemkind drauf is, bzw. bei den rechnern wo es funktioniert.
mit unterschiedlichen OS, anschliessend beziehst du dich auf 30 XP
rechner, is bissal schwer zu folgen, was da jetz für ein betriebssystem
am problemkind drauf is, bzw. bei den rechnern wo es funktioniert.
Moin Peanut,
möglicherweise ist bei diesem einen Rechner die (standardmäßig eingeschaltete) "Befehlserweiterung" NICHT aktiv.
Setz mal bitte probeweise die Zeile
Setlocal EnableExtensions
als zweite Zeile ein.
Wenn das das Problem löst, ändere bei diesem Rechner den Wert in der Registry.
~~~
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"EnableExtensions"=dword:00000001
...
HTH Biber
möglicherweise ist bei diesem einen Rechner die (standardmäßig eingeschaltete) "Befehlserweiterung" NICHT aktiv.
Setz mal bitte probeweise die Zeile
Setlocal EnableExtensions
als zweite Zeile ein.
Wenn das das Problem löst, ändere bei diesem Rechner den Wert in der Registry.
~~~
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Command Processor]
"EnableExtensions"=dword:00000001
...
HTH Biber
Hallo Biber,
vielen Dank für die schnelle Antwort. Ergänzung von "Setlocal EnableExtensions" bringt leider keine Änderung.
In der Registry habe ich alle "EnableExtensions" Einträge geprüft. Alle sind auf "=dword:00000001" gesetzt.
Hallo Angeldust,
Falls die Problembeschreibung unübersichtlich war:
Der Batch wird über ein Anmeldeskript im Netz auf 50 Rechnern ausgeführt. Davon laufen 5 unter NT4 SP6, 15 unter 2000 SP 4 und 30 unter XP SP1. Nur einer der 30 XP Rechner schreibt die Daten nicht in die Datei ip.txt. Egal ob der Batch übers Netz oder lokal gestartet wird: die For-Zeilen scheinen nicht ausgewertet zu werden
Folgende Dateien habe ich bereits ohne Erfolg mit denen eines "funktionierenden" Rechners überschrieben:
c:\windows\system32\config.nt
c:\windows\system32\autoexec.nt
c:\windows\system32\command.com
c:\windows\system32\dosx.exe
c:\windows\system32\mscdexnt.exe
c:\windows\system32\Ntio.sys
c:\windows\system32\Ntdos.sys
c:\windows\system32\Ntvdm.exe
c:\windows\system32\Redir.exe
Gibt es noch mehr DOS-relevante Dateien unter XP?
vielen Dank für die schnelle Antwort. Ergänzung von "Setlocal EnableExtensions" bringt leider keine Änderung.
In der Registry habe ich alle "EnableExtensions" Einträge geprüft. Alle sind auf "=dword:00000001" gesetzt.
Hallo Angeldust,
Falls die Problembeschreibung unübersichtlich war:
Der Batch wird über ein Anmeldeskript im Netz auf 50 Rechnern ausgeführt. Davon laufen 5 unter NT4 SP6, 15 unter 2000 SP 4 und 30 unter XP SP1. Nur einer der 30 XP Rechner schreibt die Daten nicht in die Datei ip.txt. Egal ob der Batch übers Netz oder lokal gestartet wird: die For-Zeilen scheinen nicht ausgewertet zu werden
Folgende Dateien habe ich bereits ohne Erfolg mit denen eines "funktionierenden" Rechners überschrieben:
c:\windows\system32\config.nt
c:\windows\system32\autoexec.nt
c:\windows\system32\command.com
c:\windows\system32\dosx.exe
c:\windows\system32\mscdexnt.exe
c:\windows\system32\Ntio.sys
c:\windows\system32\Ntdos.sys
c:\windows\system32\Ntvdm.exe
c:\windows\system32\Redir.exe
Gibt es noch mehr DOS-relevante Dateien unter XP?
bzw. ersetze mal die cmd.exe, die sollte meiner auffassung nach,
den befehl "for" mitbringen.
den befehl "for" mitbringen.
Hm, dann wären die nächsten 4 Überprüfungen:
- was kommt denn bei "ver" zurück an diesem Rechner? (bleibt %WINVER% leer?)
- zeigt %comspec% auf "....\CMD.exe" oder (falsch) auf "...Command.com"?
- ist der PATH kaputt - wird "find.exe" nicht gefunden?
- ist das Netzlaufwerk q:\ sicher vorhanden?
Nur sicherheitshalber.. muss irgendwas albernes sein. Sonst poste nochmal ein "Set" von diesem Rechner.
Nächste Eskalationsebene: diesen Batch Zeile für Zeile an dem Rechner per CMD-Line durchkaspern... irgendwo muss ja ein anderer Fehler auftreten als nur "FOR syntaktisch nicht...." , denn das ist IMHO ein Folgefehler.
Gruß Biber
- was kommt denn bei "ver" zurück an diesem Rechner? (bleibt %WINVER% leer?)
- zeigt %comspec% auf "....\CMD.exe" oder (falsch) auf "...Command.com"?
- ist der PATH kaputt - wird "find.exe" nicht gefunden?
- ist das Netzlaufwerk q:\ sicher vorhanden?
Nur sicherheitshalber.. muss irgendwas albernes sein. Sonst poste nochmal ein "Set" von diesem Rechner.
Nächste Eskalationsebene: diesen Batch Zeile für Zeile an dem Rechner per CMD-Line durchkaspern... irgendwo muss ja ein anderer Fehler auftreten als nur "FOR syntaktisch nicht...." , denn das ist IMHO ein Folgefehler.
Gruß Biber
Hallo Biber,
vielen Dank für Deine Hilfe.
Die comspec-Variable verwies tatsächlich auf command.com (warum auch immer?).
vielen Dank für Deine Hilfe.
Die comspec-Variable verwies tatsächlich auf command.com (warum auch immer?).
Hallo Biber,
hallo Angeldust,
mein Dank geht natürlich an Euch beide...
aber vielleicht habe ich den Beitrag von Ageldust falsch verstanden. Denn als ich den Batch lokal im cmd.exe-Fenster ausführte, kam ebenfalls oben genannte Fehlermeldung und die WINVER-Variable blieb leer. Erst die Änderung der Umgebungsvariable in den Systemeigenschaften half.
Jedenfalls bin ich sehr froh, dass die Kiste mit Eurer Hilfe jetzt wieder macht, was ich will.
hallo Angeldust,
mein Dank geht natürlich an Euch beide...
aber vielleicht habe ich den Beitrag von Ageldust falsch verstanden. Denn als ich den Batch lokal im cmd.exe-Fenster ausführte, kam ebenfalls oben genannte Fehlermeldung und die WINVER-Variable blieb leer. Erst die Änderung der Umgebungsvariable in den Systemeigenschaften half.
Jedenfalls bin ich sehr froh, dass die Kiste mit Eurer Hilfe jetzt wieder macht, was ich will.
jetz will ich aber schon wissen was comspac genau macht 
@engelsstaub
In der Variable COMSPEC ist festgelegt, welches Programm als Command-Interpreter genutzt wird.
Aufbau: COMSPEC=[Lw:\][Pfad]NameDesCommandInterpreters.ext [Parameter]-->z.B.: "...=c:\Windows\CMD.Exe"
Historische Gründe:
1) In den DOS-Zeiten gab es "nur" die command.com, aber war insofern wichtig, weil beim Booten von Diskette auch eine Kopie des Command-Interpreters auf der Bootdisk nötig war. Aus Performance-Gründen konnte "im laufenden Betrieb", zwischen 2 Dos-Kommandos auf die "schnellere" Command.com auf Festplatte gewechselt werden konnte.
Beim Booten galt: "COMSPEC=A:\Command.com"; schneller war dann "COMSPEC=C:\Dos\Command.com" o.ä.
2) die Laufzeitumgebung der Command.com konnte durch Neu-Setzen von COMSPEC angepasst werden, z.B. wenn (zur Laufzeit) bei komplexeren Batchen mehr Platz für Umgebungsvariablen erforderlich war.
3) die command.com konnte auch durch Freeware-Replacements/"Batch-Enhancer" ersetzt werden, die ein paar Befehle mehr hatten. Auch das "im laufenden Betrieb".
4)
-- Heute:bei den heutigen Windows-Versionen werden 2 Command-Interpreter mitgeliefert
a) die command.com: mehr oder weniger der "DOS 7.0"-Befehlssatz; siehe oben - keine FOR /F..Verarbeitung etc.
Nur aus Kompat-Gründen dabei.
b) die "erweiterte" CMD.exe, die die so genannten "Befehlserweiterungen" mitbringt. Aus nicht klar erkennbaren Gründen lassen sich diese "Befehlserweiterungen" auch abschalten - aber wer das aus welchen Gründen jemals tun sollte, hat M$ (noch) geheimgehalten. (Abschalten=DisableExtensions; Einschalten=EnableExtensions=Standard; Status prüfen=vergessen von M$)
HTH Biber
In der Variable COMSPEC ist festgelegt, welches Programm als Command-Interpreter genutzt wird.
Aufbau: COMSPEC=[Lw:\][Pfad]NameDesCommandInterpreters.ext [Parameter]-->z.B.: "...=c:\Windows\CMD.Exe"
Historische Gründe:
1) In den DOS-Zeiten gab es "nur" die command.com, aber war insofern wichtig, weil beim Booten von Diskette auch eine Kopie des Command-Interpreters auf der Bootdisk nötig war. Aus Performance-Gründen konnte "im laufenden Betrieb", zwischen 2 Dos-Kommandos auf die "schnellere" Command.com auf Festplatte gewechselt werden konnte.
Beim Booten galt: "COMSPEC=A:\Command.com"; schneller war dann "COMSPEC=C:\Dos\Command.com" o.ä.
2) die Laufzeitumgebung der Command.com konnte durch Neu-Setzen von COMSPEC angepasst werden, z.B. wenn (zur Laufzeit) bei komplexeren Batchen mehr Platz für Umgebungsvariablen erforderlich war.
3) die command.com konnte auch durch Freeware-Replacements/"Batch-Enhancer" ersetzt werden, die ein paar Befehle mehr hatten. Auch das "im laufenden Betrieb".
4)
-- Heute:bei den heutigen Windows-Versionen werden 2 Command-Interpreter mitgeliefert
a) die command.com: mehr oder weniger der "DOS 7.0"-Befehlssatz; siehe oben - keine FOR /F..Verarbeitung etc.
Nur aus Kompat-Gründen dabei.
b) die "erweiterte" CMD.exe, die die so genannten "Befehlserweiterungen" mitbringt. Aus nicht klar erkennbaren Gründen lassen sich diese "Befehlserweiterungen" auch abschalten - aber wer das aus welchen Gründen jemals tun sollte, hat M$ (noch) geheimgehalten. (Abschalten=DisableExtensions; Einschalten=EnableExtensions=Standard; Status prüfen=vergessen von M$)
HTH Biber
1-3) soll dat heissen, wenn ich eine console programmiere (weil mir gerade
sooooo... fad is), dass windows sie dann mittels comspec für alle cmdline-
g'schicht'rln verwenden würde. dat wäre ja grundsätzlich geil, wenn ich
aber daran denke was man damit gegebenenfalls für nen ### machen
kann, wird mir übel. ich mag windows, ich mag einstellungsmöglichkeiten,
aber die modularität und möglichkeiten von windows bringt mich auch immer
wieder zum heulen.
4) kenn jetz nich genau den umfang, was hier genau abgeschaltet wird.
könnte aber je nach anwendungsart vielleicht durchaus sinn bringen,
damit man per remoteconsle keine schweinereinen macht. den ein exploit
is immer nur so gut, wie die funktionen die ein os zur verfügung stellt.
sooooo... fad is), dass windows sie dann mittels comspec für alle cmdline-
g'schicht'rln verwenden würde. dat wäre ja grundsätzlich geil, wenn ich
aber daran denke was man damit gegebenenfalls für nen ### machen
kann, wird mir übel. ich mag windows, ich mag einstellungsmöglichkeiten,
aber die modularität und möglichkeiten von windows bringt mich auch immer
wieder zum heulen.
4) kenn jetz nich genau den umfang, was hier genau abgeschaltet wird.
könnte aber je nach anwendungsart vielleicht durchaus sinn bringen,
damit man per remoteconsle keine schweinereinen macht. den ein exploit
is immer nur so gut, wie die funktionen die ein os zur verfügung stellt.
@7203
...ja, ist es auch. Den Weg sind VIELE gegangen, für so banale Sachen wie Bereitstellung von @today oder simple Rechenfunktionen oder Programmierkonstrukte wie IF..THEN..ELSE oder SELECT..CASE.
Oder eben auch FOR-Schleifen, die es unterm COMMAND.COM nur in einfachster Form gab.
Na, ja... wer von den Youngstern benutzt den überhaupt noch ein Konsolenutility??
Die nehmen eine Klicki-Bunti-Dateisuche mit schwanzwedelndem Hund, weil sie gar nichts anderes kennen.
Die halten Programme im Handy-Logo-Design für "normal"
Perversling!
...Du meinst dieses Zusammengestoppelt-Wirkende?
mitfühlend Taschentuch reicht
Bei ziemlich jedem CMD-Befehl kommt als 5.Hilfezeile:
"Wenn die Befehlserweiterungen aktiviert sind, geht noch..." und dann drei Bildschirmseiten...
Siehe FOR /?; SET /?; MORE /?; CALL /? IF /?....
Nein. Bzw. "könnte" ja... ich hab noch keinen entdeckt.
Nein, das Problem ist umgekehrt. Wenn plötzlich und unerwartet die "erweiterten Funktionalitäten" fehlen oder abgeschaltet sind, laufen deine Login-Skripte nicht mehr.
So waren wir ja in diesem Thread gelandet.
Nochmal zur Missbrauchsmöglichkeit.
Es wäre natürlich möglich, unter dem Namen bzw. dem Etikett "COMSPEC=c:\windows\OTHERCMD.exe" irgendeine Malware zu betreiben.
Aber ebenso und mit weniger Aufwand kannst Du einen Virus oder einen Dialer unter dem Namen Explorer.exe oder FreeCell.exe irgendwo hinstellen.
Oder auch einen Schädling. der Windows.exe oder Win.com heißt..
Da entsteht kein zusätzliches Scheunentor.
Was in der Tat allerdings einige Skript-Kiddies machen:
Diverse Trojaner stellen eine Datei namens "CMD.com" in das %windir%\system32-Verzeichnis.
Diese ruft zuerst ihren Malware-Prozess auf und startet dann die CMD.exe.
*.com-Dateien werden zuerst gesucht, dann gleichnamige *.exe-Dateien.
Wenn also ein User aufruft: "Start" -"Ausführen" "cmd", dann wird dieser Schädling für Extrem-DAUs aktiv.
Erschöpfend behandelt, Angel?
Grüße Biber
1-3) soll dat heissen, wenn ich eine console programmiere (weil mir gerade
sooooo... fad is), dass windows sie dann mittels comspec für alle cmdline-
g'schicht'rln verwenden würde. dat wäre ja grundsätzlich geil,
sooooo... fad is), dass windows sie dann mittels comspec für alle cmdline-
g'schicht'rln verwenden würde. dat wäre ja grundsätzlich geil,
Oder eben auch FOR-Schleifen, die es unterm COMMAND.COM nur in einfachster Form gab.
wenn ich aber daran denke was man damit ...
für nen ### machen kann, wird mir übel.
für nen ### machen kann, wird mir übel.
Die nehmen eine Klicki-Bunti-Dateisuche mit schwanzwedelndem Hund, weil sie gar nichts anderes kennen.
Die halten Programme im Handy-Logo-Design für "normal"
ich mag windows,
ich mag einstellungsmöglichkeiten,
aber die modularität
aber die modularität
und möglichkeiten von windows bringt mich auch immer
wieder zum heulen.
wieder zum heulen.
4) kenn jetz nich genau den umfang, was hier genau abgeschaltet wird.
"Wenn die Befehlserweiterungen aktiviert sind, geht noch..." und dann drei Bildschirmseiten...
Siehe FOR /?; SET /?; MORE /?; CALL /? IF /?....
könnte aber je nach anwendungsart vielleicht durchaus sinn bringen,
damit man per remoteconsle keine schweinereinen macht. den ein exploit
is immer nur so gut, wie die funktionen die ein os zur verfügung stellt.
is immer nur so gut, wie die funktionen die ein os zur verfügung stellt.
So waren wir ja in diesem Thread gelandet.
Nochmal zur Missbrauchsmöglichkeit.
Es wäre natürlich möglich, unter dem Namen bzw. dem Etikett "COMSPEC=c:\windows\OTHERCMD.exe" irgendeine Malware zu betreiben.
Aber ebenso und mit weniger Aufwand kannst Du einen Virus oder einen Dialer unter dem Namen Explorer.exe oder FreeCell.exe irgendwo hinstellen.
Oder auch einen Schädling. der Windows.exe oder Win.com heißt..
Da entsteht kein zusätzliches Scheunentor.
Was in der Tat allerdings einige Skript-Kiddies machen:
Diverse Trojaner stellen eine Datei namens "CMD.com" in das %windir%\system32-Verzeichnis.
Diese ruft zuerst ihren Malware-Prozess auf und startet dann die CMD.exe.
*.com-Dateien werden zuerst gesucht, dann gleichnamige *.exe-Dateien.
Wenn also ein User aufruft: "Start" -"Ausführen" "cmd", dann wird dieser Schädling für Extrem-DAUs aktiv.
Erschöpfend behandelt, Angel?
Grüße Biber
