9
Excel mit VBS füllen aus Aufgabenplanung
Hallo,
ich hab ein ganz einfaches vb-Script, dass die Exceldatei Work.xlsx öffnet, in Zelle A1 Test schreibt und die Datei wieder schließt.
Auf einem Windows Server 2016 tut das Script, was es soll, wenn ich es auf eine dieser beiden Arten starte:
Es funktioniert nicht mit dieser Aufrufart:
Zum Testen habe ich das Script direkt nach Öffnen der Exceldatei beendet, also so:
Jetzt bleibt bei den 2 funktionierenden Aufrufarten Excel geöffnet.
Bei der nicht funktionierenden Aufrufart (als Benutzer B) ist für 2 Sekunden der Prozess excel.exe im Task-Manager zu sehen, dann ist er weg.
Also irgendwas bringt Excel zum Absturz, aber was? In der Ereignisanzeige finde ich nichts.
Auf meinem Windows 10 22H2 funktionieren alle 3 Aufrufarten. Bei vorzeitiger Scriptbeendigung (wscript.quit) läuft bei Aufruf als Benutzer B der Prozess excel.exe im Task-Manager weiter, bis ich ihn manuell beende.
Was läuft hier falsch?
Danke
Gruß
Martin
ich hab ein ganz einfaches vb-Script, dass die Exceldatei Work.xlsx öffnet, in Zelle A1 Test schreibt und die Datei wieder schließt.
Dim objExcel
Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = true
Set xls = objExcel.Workbooks.Open("C:\temp\Work.xlsx")
objExcel.Range("A1").Select
objExcel.ActiveCell.FormulaR1C1 = "Test"
xls.save
xls.close
objExcel.quitAuf einem Windows Server 2016 tut das Script, was es soll, wenn ich es auf eine dieser beiden Arten starte:
- bei Direktausführung (Doppelklick)
- aus der Aufgabenplanung (ausführen als der angemeldete Benutzer und "Nur ausführen, wenn der Benutzer angemeldet ist")
Es funktioniert nicht mit dieser Aufrufart:
- aus der Aufgabenplanung (ausführen als Benutzer B und "Unabhängig von der Benutzeranmeldung ausführen")
Zum Testen habe ich das Script direkt nach Öffnen der Exceldatei beendet, also so:
Dim objExcel
Set objExcel = CreateObject("Excel.Application")
objExcel.Visible = true
Set xls = objExcel.Workbooks.Open("C:\temp\Work.xlsx")
wscript.quitJetzt bleibt bei den 2 funktionierenden Aufrufarten Excel geöffnet.
Bei der nicht funktionierenden Aufrufart (als Benutzer B) ist für 2 Sekunden der Prozess excel.exe im Task-Manager zu sehen, dann ist er weg.
Also irgendwas bringt Excel zum Absturz, aber was? In der Ereignisanzeige finde ich nichts.
Auf meinem Windows 10 22H2 funktionieren alle 3 Aufrufarten. Bei vorzeitiger Scriptbeendigung (wscript.quit) läuft bei Aufruf als Benutzer B der Prozess excel.exe im Task-Manager weiter, bis ich ihn manuell beende.
Was läuft hier falsch?
Danke
Gruß
Martin
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: 8165312007
Url: https://administrator.de/forum/excel-mit-vbs-fuellen-aus-aufgabenplanung-8165312007.html
Ausgedruckt am: 22.12.2024 um 18:12 Uhr
9 Kommentare
Neuester Kommentar
Liegt an fehlendem Desktop Ordner des System Profiles
Per Batch in Aufgabeplanung XLS in CSV umwandeln
Bitte auch daran denken das man evt. Dialoge mittels Application.DisplayAlerts = False unterdrücken sollte, weil Excel sonst auch hängen bleiben kann. Und nicht vergessen das ganze wieder am Ende des Skripts rückgängig zu machen da das eine permanente Einstellung ist Application.DisplayAlerts = True
Gruß
Per Batch in Aufgabeplanung XLS in CSV umwandeln
Bitte auch daran denken das man evt. Dialoge mittels Application.DisplayAlerts = False unterdrücken sollte, weil Excel sonst auch hängen bleiben kann. Und nicht vergessen das ganze wieder am Ende des Skripts rückgängig zu machen da das eine permanente Einstellung ist Application.DisplayAlerts = True
Gruß
Hallo,
danke für den Tipp. Aber Microsoft Excel Application gibt es bei mir nicht.
Dise beiden Ordner habe ich erstellt:
Auch nicht nach Ergänzung des Scripts um die Zeile
Mithilfe der Ereignisanzeige
kam ich auf den Komponentendienst "Immersive Shell Broker"
Und nachdem ich in der Registry den Besitz des Schlüssels
HKCR\AppID\{2FD08A73-D1F1-43EB-B888-24C2496F95FD}\ übernommen hatte, konnte ich in den Komponentendiensten auch die Rechte (Identität) setzen:
Das hat dazu geführt, dass in der Ereignisanzeige kein Fehler mehr erscheint, sowie der Prozess excel.exe jetzt wieder nach 2 Sekunden verschwindet, aber das Script macht nicht, was es soll, sprich, die Work.xlsx wird nicht geändert.
Was jetzt?
VG
Martin
danke für den Tipp. Aber Microsoft Excel Application gibt es bei mir nicht.
- C:\Windows\SysWOW64\config\systemprofile\Desktop
- C:\Windows\System32\config\systemprofile\Desktop
Auch nicht nach Ergänzung des Scripts um die Zeile
objExcel.application.displayalerts = falseMithilfe der Ereignisanzeige
kam ich auf den Komponentendienst "Immersive Shell Broker"
Und nachdem ich in der Registry den Besitz des Schlüssels
HKCR\AppID\{2FD08A73-D1F1-43EB-B888-24C2496F95FD}\ übernommen hatte, konnte ich in den Komponentendiensten auch die Rechte (Identität) setzen:
Das hat dazu geführt, dass in der Ereignisanzeige kein Fehler mehr erscheint, sowie der Prozess excel.exe jetzt wieder nach 2 Sekunden verschwindet, aber das Script macht nicht, was es soll, sprich, die Work.xlsx wird nicht geändert.
Was jetzt?
VG
Martin
objExcel.application.displayalerts = false
Die Zeile ist falsch!Sie muss so lauten
objExcel.displayalerts = falseSo haut das hin ...
With CreateObject("Excel.Application")
.DisplayAlerts = False
Set xls = .Workbooks.Open("C:\temp\Work.xlsx")
xls.Sheets.Item(1).Range("A1").Value = "Test"
xls.Save
xls.Close true
.DisplayAlerts = True
.quit
End withRTFM
https://learn.microsoft.com/de-de/office/vba/api/excel.application.displ ...
Die Zeile mit displayalerts hab ich angepasst, keine Änderung.
Das Script an sich muss ja passen, bei manueller Ausführung macht es ja, was es soll. Ich hab es trotzdem so umgestellt, wie von dir geschrieben, keine Änderung. Manuell funktioniert es, nicht über die Aufgabenplanung bei Ausführung als anderer Benutzer.
Das mit dem Prozess excel.exe ist auch nicht immer gleich. Mal bleibt er im Task-Manager, mal verschwindet er gleich wieder. Aber in keinem Fall wird in die Work.xlsx geschrieben.
Das Script an sich muss ja passen, bei manueller Ausführung macht es ja, was es soll. Ich hab es trotzdem so umgestellt, wie von dir geschrieben, keine Änderung. Manuell funktioniert es, nicht über die Aufgabenplanung bei Ausführung als anderer Benutzer.
Das mit dem Prozess excel.exe ist auch nicht immer gleich. Mal bleibt er im Task-Manager, mal verschwindet er gleich wieder. Aber in keinem Fall wird in die Work.xlsx geschrieben.
Klappt hier im Test tiptop mit meiner Anpassung. Und nein, ein Skript das manuell funktioniert muss nicht auch in der Aufgabenplanung funktionieren, schon gar nicht wenn es unabhängig von der Anmeldung mit einem anderen User ausgeführt wird dem bspw. Rechte am Ziel fehlen oder Netzlaufwerke fehlen die userabhängig gemappt werden usw. hier muss einiges mehr beachtet werden, u.a. auch Security Settings.
Im Link oben wurde ein Testskript mit Logging-Funktion genannt lass dir einfach die Fehler mal in eine Datei loggen und du siehst was Sache bei dir ist und musst nicht in der Gegend rum raten!
Im Link oben wurde ein Testskript mit Logging-Funktion genannt lass dir einfach die Fehler mal in eine Datei loggen und du siehst was Sache bei dir ist und musst nicht in der Gegend rum raten!
Mein Script ist vbs, das Testskript ist Powershell. Aber immerhin ruft es auch Excel auf und verhält sich bei mir genauso bescheuert. Manuell funktioniert es, nicht bei Aufruf per Aufgabenplanung als anderer Benutzer. Von daher ganz gut vergleichbar. Nur hilft mir das Logging nicht weiter:
Funktionierender Aufruf:
Nicht funktionierender Aufruf:
Funktionierender Aufruf:
Nicht funktionierender Aufruf:
Jetzt kam doch noch mehr:
PowerShell und Office müssen in der selben Bitness laufen, wenn also ein 32Bit Office installiert ist muss das Skript auch in einer 32Bit Shell laufen und bei 64bit in einer 64bit Shell. Also die jeweilige PS EXE aus Wow6432 oder System32 zum Starten nehmen.
Geht bei mir trotzdem nicht. Ich hab's jetzt aufgegeben und schreib das Script um auf Ausgabe in Textdatei. Wenn das so ein Gewürg ist, hab ich beim nächsten Serverumzug wieder das gleiche Problem.
Aber trotzdem Danke für die Mühen
VG
Martin
Aber trotzdem Danke für die Mühen
VG
Martin
