26
Mit Visual Basic Batch Datei öffnen
Hi,
ich habe ein kleines Problem. Ich habe mir eine Batch datei geschrieben die ich gern mit einer VB Form starten möchte, dazwischen ist noch ein vb script um das batch fenster zu verstecken. Ich habe das ganze auf einem Test PC getestet und dort hat alles wunderbar funktioniert, das VB-Programm hat das vb-Script gestartet und dieses wiederrum hat versteckt die Batch geöffnet.
Nun habe ich alles vom Test PC auf den Haupt PC umgezogen, dort funktioniert es nicht mehr so wie es soll.
Das VB-Programm öffnet zwar noch das vb-Script und dieses öffnet auch noch die Batch, aber nicht mehr so wie es soll.
In der Batch stehen psexec Befehle, wen ich die Batch jetzt auf dem neun PC per VB-Programm starte, gibt die Batch aus das sie den Befehl "psexec" nicht kenne. Psexec ist aber auch auf dem neuen PC installiert und wen ich die Batch manuell auf dem neuen PC starte, kennt sie den Befehl auch und führt in tadellos aus.
Könnte es daran liegen das VB die Batch villeicht nicht mit admin rechten startet?
Komisch ist nur das es auf dem alten test PC alles funktioniert hat...
Grüße
Florian
Edit: Mir ist aufgefallen das die cmd auf dem alten test PC standardmäßig als Admin gestartet wird, auf dem neuen nicht, obwohl dieser benutzer auch admin ist..
ich habe ein kleines Problem. Ich habe mir eine Batch datei geschrieben die ich gern mit einer VB Form starten möchte, dazwischen ist noch ein vb script um das batch fenster zu verstecken. Ich habe das ganze auf einem Test PC getestet und dort hat alles wunderbar funktioniert, das VB-Programm hat das vb-Script gestartet und dieses wiederrum hat versteckt die Batch geöffnet.
Nun habe ich alles vom Test PC auf den Haupt PC umgezogen, dort funktioniert es nicht mehr so wie es soll.
Das VB-Programm öffnet zwar noch das vb-Script und dieses öffnet auch noch die Batch, aber nicht mehr so wie es soll.
In der Batch stehen psexec Befehle, wen ich die Batch jetzt auf dem neun PC per VB-Programm starte, gibt die Batch aus das sie den Befehl "psexec" nicht kenne. Psexec ist aber auch auf dem neuen PC installiert und wen ich die Batch manuell auf dem neuen PC starte, kennt sie den Befehl auch und führt in tadellos aus.
Könnte es daran liegen das VB die Batch villeicht nicht mit admin rechten startet?
Komisch ist nur das es auf dem alten test PC alles funktioniert hat...
Grüße
Florian
Edit: Mir ist aufgefallen das die cmd auf dem alten test PC standardmäßig als Admin gestartet wird, auf dem neuen nicht, obwohl dieser benutzer auch admin ist..
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: 316046
Url: https://administrator.de/forum/mit-visual-basic-batch-datei-oeffnen-316046.html
Ausgedruckt am: 08.01.2025 um 08:01 Uhr
26 Kommentare
Neuester Kommentar
Hallo,
Involvierte OSe sind was?
Bit Systeme sind was?
Inhalt der VBS ist was?
Welcher Benutzer hat welche genauen Rechte?
Wie wird das ganze gestartet?
Pfade sind was?
Gruß,
Peter
Zitat von @Flodsche:
Könnte es daran liegen das VB die Batch villeicht nicht mit admin rechten startet?
Könnte oder könnte nicht. Was würdest du denn mit diesen mickrigen Infos antworten?Könnte es daran liegen das VB die Batch villeicht nicht mit admin rechten startet?
Komisch ist nur das es auf dem alten test PC alles funktioniert hat...
Nur gut das wir gar nicht wissen waqs du alles hast. Es fehlen eigentlich alle Informationen um auch nur Ansatzweise eine Antwort geben zu können. Bei mein nachbarn geht das Auto nicht, meins geht schon. Was könnte der Fehler sein?Involvierte OSe sind was?
Bit Systeme sind was?
Inhalt der VBS ist was?
Welcher Benutzer hat welche genauen Rechte?
Wie wird das ganze gestartet?
Pfade sind was?
Gruß,
Peter
Hi,
danke für deine Antwort.
Sorry, hier die infos:
OS = bei beiden win7
Bit = beim test pc 32 bit beim neuen 64bit
Inhalt = VB-Programm:
Inhalt = vbs-script:
Rechte = Beide Admin Rechte, d.h. admin$ und IPC$
Starten = Das ganze wird per Visual Basic Programm gestartet mit einem Button, Syntax siehe oben.
gruß
Florian
danke für deine Antwort.
Sorry, hier die infos:
OS = bei beiden win7
Bit = beim test pc 32 bit beim neuen 64bit
Inhalt = VB-Programm:
Process.Start("C:\Users\Benutzername\Documents\Programm_start.vbs") Inhalt = vbs-script:
Set WshShell = WScript.CreateObject("WScript.Shell")
Return = WshShell.Run("""C:\Users\Benutzer\Documents\Programm_script.bat""", 0, True)
Set WshShell = NothingRechte = Beide Admin Rechte, d.h. admin$ und IPC$
Starten = Das ganze wird per Visual Basic Programm gestartet mit einem Button, Syntax siehe oben.
gruß
Florian
Hi,
starte mal testhalber das VB-Programm mit "Als Administrator ausführen".
Gruß
Xolger
starte mal testhalber das VB-Programm mit "Als Administrator ausführen".
Gruß
Xolger
Hi,
das hab ich schon versucht, funktioniert leider auch nicht.
Hab zum testen auch einmal diesen Befehl in Visual Basic eingegeben:
dann hat er die cmd auch als admin gestartet...
Gruß
Florian
das hab ich schon versucht, funktioniert leider auch nicht.
Hab zum testen auch einmal diesen Befehl in Visual Basic eingegeben:
Process.Start("C:\Windows\System32\cmd.exe") dann hat er die cmd auch als admin gestartet...
Gruß
Florian
Hallo,
Und? Ging es dann oder auch nicht?
Gruß,
Peter
Und? Ging es dann oder auch nicht?
Gruß,
Peter
Hi,
naja dann hat er ja nur die cmd.exe geöffnet, wen ich jedoch wieder den pfad von meiner batch datei angebe öffnet er die batch (vermutlich) ohne admin rechte, sprich es funktioniert nicht und es kommt immer noch die Meldung das er den befehl psexec nicht kennt.
Es muss ja aber auch nicht dringend an den Rechten liegen das er diesen Befehl nicht kennt oder?
Wobei es ja schon auf der Hand liegt, da die Batch datei ja manuell gestartet einwandfrei funktioniert, nur halt nicht wen sie über das Visual Basic Programm gestartet wird..
Übrigens funktioniert es auch nicht wen man das vbs-script zwischen drin weg lässt, also das Visual Basic Programm direkt die Batch öffnet, also würde ich einfach mal ausschließen das es was mit dem vbs-script zu tun hat.
Gibt es in Visual Basic keine Parameter die man angeben kann das er den Prozess mit admin rechten startet?
Edit: Es wird wohl ziemlich sicher ein Berechtigungsproblem sein, als ich eben in Visual Basic einen Befehl zum Kopieren von meinem PC auf einem PC im netzwerk eingegeben habe , hat Visual Basic mein Programm garnicht mehr ausgeführt, mit dem Fehler das Berechtigungen fehlen um dateien auf diesen PC im Netzwerk zu kopieren...
Händisch kann ich wieder auf diesen Ordner auf dem PC aus dem Netzwerk zugreifen (Der ordner ist natürlich freigegben).
Wie kann ich Visual Basic nun die benötigten berechtigungen geben?
Gruß
Florian
naja dann hat er ja nur die cmd.exe geöffnet, wen ich jedoch wieder den pfad von meiner batch datei angebe öffnet er die batch (vermutlich) ohne admin rechte, sprich es funktioniert nicht und es kommt immer noch die Meldung das er den befehl psexec nicht kennt.
Es muss ja aber auch nicht dringend an den Rechten liegen das er diesen Befehl nicht kennt oder?
Wobei es ja schon auf der Hand liegt, da die Batch datei ja manuell gestartet einwandfrei funktioniert, nur halt nicht wen sie über das Visual Basic Programm gestartet wird..
Übrigens funktioniert es auch nicht wen man das vbs-script zwischen drin weg lässt, also das Visual Basic Programm direkt die Batch öffnet, also würde ich einfach mal ausschließen das es was mit dem vbs-script zu tun hat.
Gibt es in Visual Basic keine Parameter die man angeben kann das er den Prozess mit admin rechten startet?
Edit: Es wird wohl ziemlich sicher ein Berechtigungsproblem sein, als ich eben in Visual Basic einen Befehl zum Kopieren von meinem PC auf einem PC im netzwerk eingegeben habe , hat Visual Basic mein Programm garnicht mehr ausgeführt, mit dem Fehler das Berechtigungen fehlen um dateien auf diesen PC im Netzwerk zu kopieren...
Händisch kann ich wieder auf diesen Ordner auf dem PC aus dem Netzwerk zugreifen (Der ordner ist natürlich freigegben).
Wie kann ich Visual Basic nun die benötigten berechtigungen geben?
Gruß
Florian
Ich sehe hier auf die schnelle nirgends das hier psexec aufgerufen wird.
Kompletten Pfad mit angegeben. Bei leerzeichen "" nicht vergessen.
Kompletten Pfad mit angegeben. Bei leerzeichen "" nicht vergessen.
Hi,
wie meinst du?
Dieser Befehl
ruft eine Batchdatei auf in der der psexec Befehl hinterlegt ist?
Gruß
Florian
wie meinst du?
Dieser Befehl
Process.Start("C:\Users\Benutzername\Documents\Programm_script.bat") ruft eine Batchdatei auf in der der psexec Befehl hinterlegt ist?
Gruß
Florian
Hallo,
Und die Batch ist vorhanden?
PSExec ist wo vorhanden? Der Pfad dorthin passt auch in der Batchdatei? Rechte dazu eignen sich? Bedenke ein RunAs oder "Als Administrator ausführen" nimmt dann immer die Umgebung des passenden benutzers. Dort muss nicht alles so sein wie in deiner Umgebung.
Und dein
Ist die erste halbwegs passable Fehlermelung welches mehr aussagt als deine ewiges "Es geht nicht". Und wieso glaubst du nicht das der rechner sagt er kennt kein PSExec? Es gibt so viele wege einen PC bzw. Benutzern Programme bekannt zu machen. Nur das Kopieren in irgendwelcheVerzeichnisse reicht nicht wenn die Umgebung nicht passt. Denn ein richtiges Installieren von PSExec gibt es nicht, Aszug von hier.Wie sind also die Path Variablen (Verschiede PC, verschiedene benutzer) gesetzt? Oder halt immer direkt addressieren.
Gruß,
Peter
Und die Batch ist vorhanden?
PSExec ist wo vorhanden? Der Pfad dorthin passt auch in der Batchdatei? Rechte dazu eignen sich? Bedenke ein RunAs oder "Als Administrator ausführen" nimmt dann immer die Umgebung des passenden benutzers. Dort muss nicht alles so sein wie in deiner Umgebung.
Und dein
es kommt immer noch die Meldung das er den befehl psexec nicht kennt
Installation
Kopieren Sie PsExec in den Pfad für ausführbare Dateien. Wenn Sie „psexec“ eingeben, wird die zugehörige Syntax angezeigt.Gruß,
Peter
Zitat von @Pjordorf:
Hallo,
Involvierte OSe sind was?
Bit Systeme sind was?
Inhalt der VBS ist was?
Welcher Benutzer hat welche genauen Rechte?
Wie wird das ganze gestartet?
Pfade sind was?
Gruß,
Peter
Hallo,Hallo,
Zitat von @Flodsche:
Könnte es daran liegen das VB die Batch villeicht nicht mit admin rechten startet?
Könnte oder könnte nicht. Was würdest du denn mit diesen mickrigen Infos antworten?Könnte es daran liegen das VB die Batch villeicht nicht mit admin rechten startet?
Komisch ist nur das es auf dem alten test PC alles funktioniert hat...
Nur gut das wir gar nicht wissen waqs du alles hast. Es fehlen eigentlich alle Informationen um auch nur Ansatzweise eine Antwort geben zu können. Bei mein nachbarn geht das Auto nicht, meins geht schon. Was könnte der Fehler sein?Involvierte OSe sind was?
Bit Systeme sind was?
Inhalt der VBS ist was?
Welcher Benutzer hat welche genauen Rechte?
Wie wird das ganze gestartet?
Pfade sind was?
Gruß,
Peter
warum vergessen die Fragesteller IMMER WIEDER diese elementare Informationen zu liefern?
Da ist so die typische Fragestellung: "Das geht nicht", ohne weitere Informationen.
Man, man, man. Und dann wundern sich die Fragesteller, daß man die Fragen nicht beantwortet.
Gruss Penny
Zitat von @Pjordorf:
Und die Batch ist vorhanden?
PSExec ist wo vorhanden? Der Pfad dorthin passt auch in der Batchdatei? Rechte dazu eignen sich?
Und die Batch ist vorhanden?
PSExec ist wo vorhanden? Der Pfad dorthin passt auch in der Batchdatei? Rechte dazu eignen sich?
Batch ist vorhanden und Pfad stimmt. Er "öffnet" die Btach datei ja auch nur gibt die Batch dann halt aus das sie den Befehl psexec nicht kennt. Das gibt die Batch dann aus! (die von vb geöffnet wurde) Sorry falls das nicht rüber kahm.Ich bin mir auch sicher das mit der Batch datei und psexec alles stimmt, denn wen ich sie manuell (also einfach doppelklick auf die batch datei) öffne funktioniert alles, nur eben nicht wen ich sie über vb öffnen lasse.
Naja wen man die psexec dateien dann in den sys32 ordner verschoben hat gibt man im cmd psexec ein und es öffnet sich ein fenster zur "Installation" von psexec.
Gruß Florian
Naja wen man die psexec dateien dann in den sys32 ordner verschoben hat gibt man im cmd psexec ein und es öffnet sich ein Fenster zur "Installation" von psexec. Wenn du dann den Pfad in der batch zu dem sys32 komplett angibst?
Die Batch mit Doppelklick auszuführen ist was anderes als sie mit rechter mausstaste als Admin zu starten. Wie schon beschrieben ändern sich Pfad variable.
Was ist so geheimnisvoll an deinen Pfaden und der Inhalt der bat?
Gib mal wirklich ALLES an dann können wir das hier auch nachvollziehen.
DIe bat kann ja auch gekürzt werden und auf das minimale (was ja dann auch nicht funktioniert durch den Fehler das er psexec nicht findet) zurecht gestutzt werden.
Zitat von @Flodsche:
Naja wen man die psexec dateien dann in den sys32 ordner verschoben hat gibt man im cmd psexec ein und es öffnet sich ein fenster zur "Installation" von psexec.
Naja wen man die psexec dateien dann in den sys32 ordner verschoben hat gibt man im cmd psexec ein und es öffnet sich ein fenster zur "Installation" von psexec.
Und man verschiebt nicht einfach so alle möglichen Programme und Tools in den System32 Ordner. Besser ist es, dafür ein separates Verzeichnis zu nutzen (z.B.: C:\Tools) und dieses Verzeichnis in die systemweite "Path"-Variable mitaufzunehmen.
Und wie Xerebus schon mitgeteilt hat, muss psexec nicht installiert werden.
Beim ersten Aufruf muss man nur die Lizenzbedingungen (EULA) aktzeptieren.
Gruss Penny
Hallo Florian,
wenn ich das schon wieder lese stellen sich mir echt die Nackenhaare
...
Erstens ist der Zwischenschritt über ein VBS um die Konsole zu verstecken absolut überflüssig wenn man ein Process-Object erstellt und die entsprechende Option des Prozesses zum unsichtbaren Ausführen aktiviert. Zweitens muss man dem Process-Object sagen das es ein Programm elevated im Admin-Kontext starten soll (-Verb runas) wenn man es denn überhaupt benötigt. Dort gilt dann ebenso ein eigenes Environment mit eigenen Umgebungsvariablen.
Ebenso muss für ein erfolgreiches PSExec auf dem Remote-System wenn es nicht in einer Domäne hängt ein Registry-Eintrag gesetzt werden (LocalAccountTokenFilterPolicy) damit der Zugriff mit psexec funktioniert. Den Pfad zu psexec bei Zweifel "absolut" angeben, oder gleich im Argument vom Process-Object ausführen lassen.
Na dann vermute bei dir eher folgendes:
Auf einem 64bit System auf dem ein 32Bit-Prozess (deine EXE) ausgeführt wird greift nicht auf das SYSTEM32 Verzeichnis zu sondern per FS-Redirection auf C:\windows\syswow64 ! Wenn du psexec also ins system32 Verzeichnis kopiert hast ist klar warum die Konsole es nicht finden kann.
Das sind alles Dinge man beachten muss
Grüße Uwe
wenn ich das schon wieder lese stellen sich mir echt die Nackenhaare
...Edit: Mir ist aufgefallen das die cmd auf dem alten test PC standardmäßig als Admin gestartet wird, auf dem neuen nicht, obwohl dieser benutzer auch admin ist..
Dann ist auf dem einen definitiv UAC deaktiviert. Wenn die UAC deaktiviert ist wird das meiste standardmäßig elevated gestartet.Erstens ist der Zwischenschritt über ein VBS um die Konsole zu verstecken absolut überflüssig wenn man ein Process-Object erstellt und die entsprechende Option des Prozesses zum unsichtbaren Ausführen aktiviert. Zweitens muss man dem Process-Object sagen das es ein Programm elevated im Admin-Kontext starten soll (-Verb runas) wenn man es denn überhaupt benötigt. Dort gilt dann ebenso ein eigenes Environment mit eigenen Umgebungsvariablen.
Dim p As New Process()
With p.StartInfo
.FileName = "cmd.exe"
.Arguments = "/c ""C:\Pfad\batch.cmd"""
.UseShellExecute = False
.CreateNoWindow = True
.RedirectStandardError = True
.RedirectStandardOutput = True
End With
p.Start()
p.WaitForExit()
MsgBox(p.StandardOutput.ReadToEnd() & p.StandardError.ReadToEnd())Ebenso muss für ein erfolgreiches PSExec auf dem Remote-System wenn es nicht in einer Domäne hängt ein Registry-Eintrag gesetzt werden (LocalAccountTokenFilterPolicy) damit der Zugriff mit psexec funktioniert. Den Pfad zu psexec bei Zweifel "absolut" angeben, oder gleich im Argument vom Process-Object ausführen lassen.
Bit = beim test pc 32 bit beim neuen 64bit
Na dann vermute bei dir eher folgendes:
Auf einem 64bit System auf dem ein 32Bit-Prozess (deine EXE) ausgeführt wird greift nicht auf das SYSTEM32 Verzeichnis zu sondern per FS-Redirection auf C:\windows\syswow64 ! Wenn du psexec also ins system32 Verzeichnis kopiert hast ist klar warum die Konsole es nicht finden kann.
- http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.we ...
- https://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx
Das sind alles Dinge man beachten muss
Grüße Uwe
1
Hi,
ok wir sind uns einig psexec muss man nicht installieren. :P
Pfad:
Inhalt:
Danke für den Tipp Penny!
ok wir sind uns einig psexec muss man nicht installieren. :P
Zitat von @Xerebus:
Nein. Das muss nicht installiert werden.
Wenn du dann den Pfad in der batch zu dem sys32 komplett angibst?
Die Batch mit Doppelklick auszuführen ist was anderes als sie mit rechter mausstaste als Admin zu starten. Wie schon beschrieben ändern sich Pfad variable.
Was ist so geheimnisvoll an deinen Pfaden und der Inhalt der bat?
Gib mal wirklich ALLES an dann können wir das hier auch nachvollziehen.
DIe bat kann ja auch gekürzt werden und auf das minimale (was ja dann auch nicht funktioniert durch den Fehler das er psexec nicht findet) zurecht gestutzt werden.
Naja wen man die psexec dateien dann in den sys32 ordner verschoben hat gibt man im cmd psexec ein und es öffnet sich ein Fenster zur "Installation" von psexec. Wenn du dann den Pfad in der batch zu dem sys32 komplett angibst?
Die Batch mit Doppelklick auszuführen ist was anderes als sie mit rechter mausstaste als Admin zu starten. Wie schon beschrieben ändern sich Pfad variable.
Was ist so geheimnisvoll an deinen Pfaden und der Inhalt der bat?
Gib mal wirklich ALLES an dann können wir das hier auch nachvollziehen.
DIe bat kann ja auch gekürzt werden und auf das minimale (was ja dann auch nicht funktioniert durch den Fehler das er psexec nicht findet) zurecht gestutzt werden.
Pfad:
C:\Users\schulung\Documents\Schulungsraumsteuerung_Scripts\FunctionScripts\InternetAus_script.batInhalt:
psexec \\PC Name /u Domäne\schulung /p Passwort route delete 0.0.0.0Danke für den Tipp Penny!
Zitat von @colinardo:
Hallo Florian,
wenn ich das schon wieder lese stellen sich mir echt die Nackenhaare...
Erstens ist der Zwischenschritt über ein VBS um die Konsole zu verstecken absolut überflüssig wenn man ein Process-Object erstellt und die entsprechende Option des Prozesses zum unsichtbaren Ausführen aktiviert. Zweitens muss man dem Process-Object sagen das es ein Programm elevated im Admin-Kontext starten soll (-Verb runas) wenn man es denn überhaupt benötigt. Dort gilt dann ebenso ein eigenes Environment mit eigenen Umgebungsvariablen.
Ebenso muss für ein erfolgreiches PSExec auf dem Remote-System wenn es nicht in einer Domäne hängt ein Registry-Eintrag gesetzt werden (LocalAccountTokenFilterPolicy) damit der Zugriff mit psexec funktioniert. Den Pfad zu psexec bei Zweifel "absolut" angeben, oder gleich im Argument vom Process-Object ausführen lassen.
Na dann vermute bei dir eher folgendes:
Auf einem 64bit System auf dem ein 32Bit-Prozess (deine EXE) ausgeführt wird greift nicht auf das SYSTEM32 Verzeichnis zu sondern per FS-Redirection auf C:\windows\syswow64 ! Wenn du psexec also ins system32 Verzeichnis kopiert hast ist klar warum die Konsole es nicht finden kann.
Das sind alles Dinge man beachten muss
Grüße Uwe
Hallo Florian,
wenn ich das schon wieder lese stellen sich mir echt die Nackenhaare
...Edit: Mir ist aufgefallen das die cmd auf dem alten test PC standardmäßig als Admin gestartet wird, auf dem neuen nicht, obwohl dieser benutzer auch admin ist..
Dann ist auf dem einen definitiv UAC deaktiviert. Wenn die UAC deaktiviert ist wird das meiste standardmäßig elevated gestartet.Erstens ist der Zwischenschritt über ein VBS um die Konsole zu verstecken absolut überflüssig wenn man ein Process-Object erstellt und die entsprechende Option des Prozesses zum unsichtbaren Ausführen aktiviert. Zweitens muss man dem Process-Object sagen das es ein Programm elevated im Admin-Kontext starten soll (-Verb runas) wenn man es denn überhaupt benötigt. Dort gilt dann ebenso ein eigenes Environment mit eigenen Umgebungsvariablen.
> Dim p As New Process()
> With p.StartInfo
> .FileName = "cmd.exe"
> .Arguments = "/c ""C:\Pfad\batch.cmd"""
> .UseShellExecute = False
> .CreateNoWindow = True
> .RedirectStandardError = True
> .RedirectStandardOutput = True
> End With
> p.Start()
> p.WaitForExit()
> MsgBox(p.StandardOutput.ReadToEnd() & p.StandardError.ReadToEnd())
> Ebenso muss für ein erfolgreiches PSExec auf dem Remote-System wenn es nicht in einer Domäne hängt ein Registry-Eintrag gesetzt werden (LocalAccountTokenFilterPolicy) damit der Zugriff mit psexec funktioniert. Den Pfad zu psexec bei Zweifel "absolut" angeben, oder gleich im Argument vom Process-Object ausführen lassen.
Bit = beim test pc 32 bit beim neuen 64bit
Na dann vermute bei dir eher folgendes:
Auf einem 64bit System auf dem ein 32Bit-Prozess (deine EXE) ausgeführt wird greift nicht auf das SYSTEM32 Verzeichnis zu sondern per FS-Redirection auf C:\windows\syswow64 ! Wenn du psexec also ins system32 Verzeichnis kopiert hast ist klar warum die Konsole es nicht finden kann.
- http://techsupt.winbatch.com/webcgi/webbatch.exe?techsupt/nftechsupt.we ...
- https://msdn.microsoft.com/en-us/library/aa384187(VS.85).aspx
Das sind alles Dinge man beachten muss
Grüße Uwe
Stimmt wahrscheinlich dass, das sehr umständlich war, aber ich kenne mich wirklich garnicht aus mit VB, nutze es nur wegen der schöneren Nutzeroberfläche im Gegensatz zu Dos, deswegen verweist das Programm auch nur auf meine batch dateien. Auf jeden fall vielen dank für deine "vereinfachenderen Zeilen", ist natürlich viel geschickter jetzt.
Das mit dem syswow64, hört sich ziemlich logisch an.
Aber wie bringe ich die exe dazu auf den system32 Ordner zuzugreifen? Sorry ich bin der englischen Sprache nicht sehr mächtig.
PS: Der registry Eintrag is gemacht, wie gesagt an der Batch dürfte es nicht liegen, die funktioniert manuell ausgeführt (egal ob mit Doppelklick oder Rechtsklick Ausführen als Administrator).
Gruß
Florian
Hallo,
mach dort mal CD gibt dir den aktuellen Pafd, SET Path ziegt dir wo du bist, Dir zeigt dir ob PSExec ausserhalb von Path und im aktuellen Pfad und darunter gefunden werden kann, dann dein bisheriges Skript und am Ende alles in Ruhe Lesen. Dazu darf die Batchdatei natürlich nicht Versteckt ausgeführt werden. Was ein Programm tut, muss noch lange nicht das entsprechen was ein Benutzer tut.
Gruß,
Peter
mach dort mal
@Echo OFF
Echo Wo bin ich?
CD
Echo Pfad fuer Ausfuehrbare Dateien
SET Path
Echo PSExec ist zu finden
Dir PSExec.exe /S
Echo noch ne Taste um ungehindert weiter zu machen
pause
psexec \\PC Name /u Domäne\schulung /p Passwort route delete 0.0.0.0
Echo Und alles in ruhe Lesen
pauseGruß,
Peter
1Zitat von @Pjordorf:
Hallo,
mach dort mal CD gibt dir den aktuellen Pafd, SET Path ziegt dir wo du bist, Dir zeigt dir ob PSExec ausserhalb von Path und im aktuellen Pfad und darunter gefunden werden kann, dann dein bisheriges Skript und am Ende alles in Ruhe Lesen. Dazu darf die Batchdatei natürlich nicht Versteckt ausgeführt werden. Was ein Programm tut, muss noch lange nicht das entsprechen was ein Benutzer tut.
Gruß,
Peter
Hallo,
mach dort mal
@Echo OFF
> Echo Wo bin ich?
> CD
> Echo Pfad fuer Ausfuehrbare Dateien
> SET Path
> Echo PSExec ist zu finden
> Dir PSExec.exe /S
> Echo noch ne Taste um ungehindert weiter zu machen
> pause
> psexec \\PC Name /u Domäne\schulung /p Passwort route delete 0.0.0.0
> Echo Und alles in ruhe Lesen
> pauseGruß,
Peter
Hi,
psexec wird nicht gefunden...
Das ist doch wirklich komisch, wie gesagt wen ich die Batch direkt starte findet er psexec und führt alles problemlos aus nur nicht über VB...
Wird wohl was mit der syswow64 geschichte zu tun haben.
Gruß
Florian
Dann gib den kompletten pfad zur psexec an.....
Wie meinst du?
c:\windows\system32\psexec.exe \\PC Name /u Domäne\schulung /p Passwort route delete 0.0.0.0
Mensch, ich sag doch nehm psexec aus dem System32 raus und schiebe es nach syswow64. Oder besser gleich in einen Tools Ordner !!
Die Erläuterung dazu steht oben in Deutsch von mir.
Die Erläuterung dazu steht oben in Deutsch von mir.
Hallo,
Vielleicht mal die Ausgabe deines Batches (das was im CMD Fenster steht) als Text hier rein stellen? CMD Fenster Menüzeile, rechte Taste, Bearbeiten, Markieren - Eingabetaste und den Text in ein code block "code type=plain" hier rein stellen. Dann sehen wir das was du siehst...
Gruß,
Peter
Vielleicht mal die Ausgabe deines Batches (das was im CMD Fenster steht) als Text hier rein stellen? CMD Fenster Menüzeile, rechte Taste, Bearbeiten, Markieren - Eingabetaste und den Text in ein code block "code type=plain" hier rein stellen. Dann sehen wir das was du siehst...
wen ich die Batch direkt starte findet er psexec und führt alles problemlos aus nur nicht über VB...
Das was ein Programm tut muss noch lange nicht das sein was ein Benutzer tut.Gruß,
Peter
Hallo,
habe es nun mehr oder weniger hinbekommen.
Ich habe einfach meine .vbproj Datei geöffnet per editor und die Zeile
zu
geändert.
Dann hab ich die Debug Version als Admin ausgeführt und siehe da aufeinmal kennt er alle Befehle.
Wahrscheinlich greift er jetzte auf den system32 Ordner zu (was mein Ziel war, ich wollte nicht das auf den syswow64 Ordner zugegriffen wird).
Vielen Dank für eure Hilfe!
Nur noch eine Frage, gibt es villeicht eine Möglichkeit das das Programm immer als admin bzw standardmäßig als Admin mein Programm ausführt? Das ich nicht immer in den Debug ordner muss und das Programm mit rechtsklick ausführen als starten muss sondern direkt in Visual basic mit F5.
Gruß
Florian
habe es nun mehr oder weniger hinbekommen.
Ich habe einfach meine .vbproj Datei geöffnet per editor und die Zeile
<PlatformTarget>x86</PlatformTarget><PlatformTarget>x64</PlatformTarget>Dann hab ich die Debug Version als Admin ausgeführt und siehe da aufeinmal kennt er alle Befehle.
Wahrscheinlich greift er jetzte auf den system32 Ordner zu (was mein Ziel war, ich wollte nicht das auf den syswow64 Ordner zugegriffen wird).
Vielen Dank für eure Hilfe!
Nur noch eine Frage, gibt es villeicht eine Möglichkeit das das Programm immer als admin bzw standardmäßig als Admin mein Programm ausführt? Das ich nicht immer in den Debug ordner muss und das Programm mit rechtsklick ausführen als starten muss sondern direkt in Visual basic mit F5.
Gruß
Florian
Zitat von @Flodsche:
Ich habe einfach meine .vbproj Datei geöffnet per editor und die Zeile
zu
geändert.
Die Datei brauchst du garnicht anpacken, das kannst du auch über die GUI in den COMPILE-Options festlegen "Compile > Advanced Compile Options".Ich habe einfach meine .vbproj Datei geöffnet per editor und die Zeile
<PlatformTarget>x86</PlatformTarget><PlatformTarget>x64</PlatformTarget>Dann hab ich die Debug Version als Admin ausgeführt und siehe da aufeinmal kennt er alle Befehle.
Wahrscheinlich greift er jetzte auf den system32 Ordner zu (was mein Ziel war, ich wollte nicht das auf den syswow64 Ordner zugegriffen wird).
Schreib ich doch die ganze Zeit Wahrscheinlich greift er jetzte auf den system32 Ordner zu (was mein Ziel war, ich wollte nicht das auf den syswow64 Ordner zugegriffen wird).
, die Erläuterung steht ja oben dazu.Das ist aber nicht Sinn und Zweck einer universellen Applikation. Welche auch selbst überprüfen kann ob sie in einer x64 Umgebung arbeitet oder nicht. In den System32-Ordner gehören auf einem 64-Bit System nur 64-Bit Dateien!
Aus einem 32-Bit Programm heraus nutzt man den virtuellen "C:\windows\sysnative" Ordner um auf den system32 Ordner zuzugreifen. Steht alles hier:
http://www.samlogic.net/articles/sysnative-folder-64-bit-windows.htm
(Das kann sich auch jeder per Google übersetzen lassen wenn er des Englischen nicht mächtig ist.)
Nur noch eine Frage, gibt es villeicht eine Möglichkeit das das Programm immer als admin bzw standardmäßig als Admin mein Programm ausführt? Das ich nicht immer in den Debug ordner muss und das Programm mit rechtsklick ausführen als starten muss sondern direkt in Visual basic mit F5.
Self-Elevation ist dein Stichwort:How to self-elevate an application to a high privilege level under UAC
Habe ich hier auch schon via Powershell gezeigt.
Grüße Uwe
1
Hi,
vielen Dank, ich werds mal versuchen. Falls es niocht klappt hört ihr von mir. :D
Gruß
Florian
vielen Dank, ich werds mal versuchen. Falls es niocht klappt hört ihr von mir. :D
Gruß
Florian
