bella21
Goto Top

VBS Skript und Powershell

Hallo Zusammen,

ich habe folgendes Problem mit einem VBScript. Wenn ich das Skript manuell auf dem Rechner kopiere und ausführe, funktioniert es einwandfrei. Sobald ich es jedoch über PowerShell ausführe, wird das Skript zwar gestartet, aber es zeigt keine Änderungen. Das Skript sollte beispielsweise die Computerbeschreibung in Active Directory anpassen und den Computer in mehrere Gruppen verschieben. Wir verwenden Windows Server 2019, und die Berechtigungen sind korrekt; das Skript wird von einem Administrator ausgeführt.

Es funktioniert mit keinem der Skripte. Die Datei wird zuerst mit PowerShell kopiert und anschließend ausgeführt.


Beispiel:
Start-Process "wscript.exe" -ArgumentList "C:\temp\Gruppehinzufügen_Einkauf.vbs"

Vielen Dank für Eure Unterstützung.

LG Bella

Content-ID: 31557469065

Url: https://administrator.de/forum/vbs-skript-und-powershell-31557469065.html

Ausgedruckt am: 22.12.2024 um 16:12 Uhr

13910172396
13910172396 29.07.2024 aktualisiert um 16:42:39 Uhr
Goto Top
Moin.
  • Das Skript als UTF-8 mit BOM gespeichert?
Ich frage deshalb weil da ein Umlaut im Dateinamen ist ...
  • Fehlermeldung lautet wie ??
Es funktioniert mit keinem der Skripte. Die Datei wird zuerst mit PowerShell kopiert und anschließend ausgeführt.
  • Von wo kopierst du?
Hat das VBS File nach dem Kopieren zufällig ein "Mark of The Web" (Kontextmenü > Eigenschaften)? Wenn ja dann vor dem Ausführen noch ein Unblock-File ausführen.
  • Stimmt die PATH Variable? Ansonsten den kompletten Pfad zu wscript.exe angeben.

Gruß Strods.
emeriks
emeriks 29.07.2024 um 19:13:26 Uhr
Goto Top
Warum nicht einfach über
C:\Windows\System32\wscript.exe C:\temp\Gruppehinzufügen_Einkauf.vbs
aus PowerShell starten?

E.
Kraemer
Kraemer 30.07.2024 um 08:54:16 Uhr
Goto Top
Start-Process "wscript.exe" -ArgumentList "C:\temp\Gruppehinzufügen_Einkauf.vbs"

Morgen,

es ist IMMER eine schlechte Idee ohne absolute Pfade zu arbeiten!

Gruß
13910172396
13910172396 30.07.2024 aktualisiert um 09:36:13 Uhr
Goto Top
Und noch zur Information falls nicht bekannt: Der Scripthost ist deprecated und wird zukünftig per Default deaktiviert, und muss dann erst wieder aktiviert werden wenn man ihn weiterhin nutzen will.
VBScript deprecation: Timelines and next steps
So just be prepared 😉.
GrueneSosseMitSpeck
GrueneSosseMitSpeck 30.07.2024 um 13:01:51 Uhr
Goto Top
das liegt noch in sehr sehr weiter Ferne.

PS hat zwar VBScript als Adminsprache den Rang abgelaufen und das VB6 Runtime wurde seit 2006 von MS nicht mehr weiterentwickelt, erhält aber als Windows Bestandteil noch Security-Hotfixes.

In Applikationen ist das aber auch nicht einfach so wegzudisktuieren, und der Anlauf, VBScript aus Windows zu entfernen gabs in der Vergangenheit auch schon mal. Wir entwicklen z.B. eine Software seit ca. 30 Jahren weiter, die stark eventbasiert ist und über VBSCript läuft und die C# Migration hat schon 7 Jahre Arbeit verschlungen und weitere 2 stehen noch aus. Unsere Kunden werden über den Wegfall von VBS in der Applikation nicht sehr begeistert sein.

VBA in Office sollte auch schon vor Jahren sterben, aber eher wird Microsoft Office auf Terminalservern beerdigen (hier ist z.B. noch nichts für den Server nach 2022 auf der Roadmap).
ThePinky777
ThePinky777 05.08.2024 um 12:16:59 Uhr
Goto Top
also ich würde scripts nie per wscript.exe starten sondern per cscript.exe
verhindert popups und hängenbleiben von scripts.

dann problem könnte der UMLAUT im Dateinamen sein.
sprich keine öäü verwenden.

wenn das nicht hilft eine vbs erstellen mit inhalt

wscript.echo "Test ob das Teil startet"   

dann im powershell verlinken das es startet.

und dann ein DOS Fenster aufmachen, folgenden Befehl:
"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -executionpolicy Unrestricted -File "C:\PowerShellScript.ps1"  

dann wirst du nämlich im DOS fenster sehen ob er das Powershell ausführt und ob das das VBS ausführt indem er die ausgabe bringt "Test ob das Teil startet"

wenn ja dann funktioniert das ja, nächster schritt in dein vbs script auch ein echo rein und nochmal testen.
wenn dann das vbs startet und echo bringt kannst den powershell teil abhacken.

weil dann liegts irgendwo am vbs selbst dann das innen drin was nicht geht.