doskias
Goto Top

Excel mit Parametern aus Powershell heraus öffnen

Hallo zusammen,

wir haben auf Grund von Migrationsprojekten derzeit verschiedene Excel-Versionen im Einsatz. Alls Version sind derzeit Office 2013, Office 2016 und Office 365 im Einsatz. Wir haben 74 Excel-Dateien auf dem Fileserver. Diese Excel-Dateien müssen von alle 3 Office Versionen sowohl schreiben, aber auch in gewissen Fällen auch nur Schreibgeschützt geöffnet werden. Dabei kann es sei, dass die selbe Person am Montag die Datei beschreiben muss, am Dienstag aber nur schreibgeschützt öffnet. Eine Eingruppierung mit Dateiberechtigungen fällt daher aus. Wir haben dazu für die Excel-Dateien einfach eine Verknüpfung erstellt und den Parameter /r mitgegeben. Die sieht zum Beispiel nun so aus:
"C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" /r "[Server]\[Datei].xlsx"  
oder aber auch so:
"C:\Program Files\Microsoft Office 15\root\office15\excel.exe" /r "[Server]\[Datei].xlsx"  
um nur zwei Beispiele zu nennen. Ich möchte nun nicht zu jeder der Excel-Datei noch eine zusätzliche Verknüpfung erstellen.

Mein Gedanke war, ein PS-Skript anstatt der Verknüpfung abzulegen, welches prüft, welche Excel-Version installiert ist und dann den entsprechenden Pfad aufzurufen. Die Prüfung nach dem Pfad ist kein Problem. Das Funktioniert. Es scheitert am Start von Excel.

Folgendes habe ich bereits versucht:
1. Start-Process "C:\Program Files\Microsoft Office 15\root\office15\excel.exe" /r "[Server]\[Datei].xlsx"  
Dies führt dazu, dass Powershell meckert, dass der Parameter /r nicht als Argument von Start-Prozess erkannt wurde (ist ja auch richtig)

2. Start-Process C:\Program Files\Microsoft Office 15\root\office15\excel.exe /r [Server]\[Datei].xlsx
Dies führt dazu, dass C:\Program nicht als ausführer Prozess identifiziert wurde, da es den Pfad nicht gibt.

3. Start-Process "C:\Program Files\Microsoft Office 15\root\office15\excel.exe /r [Server]\[Datei].xlsx"  
Führt dazu, dass absolut nichts passiert

4. Start-Process "C:\Program Files\Microsoft Office 15\root\office15\excel.exe"  
Startet Excel.

Die Frage ist also, wie muss ich den Start-Process-Befehl schreiben, damit ich eine Datei mitgeben kann, die dann nur schreibgeschützt geöffnet wird. Oder geht das an dieser Stelle nicht?

Ich möchte es sauber lösen (falls möglich). Ich habe natürlich auch schon darüber nachgedacht die Excel-Datei einfach nach C:\Temp zu kopieren und dann mit
Start-Process C:\Temp\[Datei].xlsx
zu starten, aber die Lösung finde ich Powershell gegenüber ungerecht face-smile

Gruß
Doskias

Content-ID: 603621

Url: https://administrator.de/contentid/603621

Ausgedruckt am: 21.11.2024 um 13:11 Uhr

godlie
godlie 10.09.2020 um 12:35:14 Uhr
Goto Top
Hallo,

also wenn ichs recht im Kopf habe solltest du mit -FilePath und -ArgumentList zum Ziel kommen:

Start-Process -FilePath "excel.exe" -ArgumentList "/r file.xlx"  
Doskias
Doskias 10.09.2020 um 12:44:16 Uhr
Goto Top
Sorry Fehler von mir. man kann versuchen es ausführlich zu schreiben wie man möchte, man vergisst doch noch was. Die Option hatte ich auch schon versucht, genau wie:
Start-Process -FilePath "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" -ArgumentList "/r", "C:\temp\Test - Datei.xlsx"  

Problem und oben vergessen zu sagen. Die Datei enthält immer die Kombination Leezeichen Minus Leerzeichen. Bei deiner (und bei meiner) Verwendung der ArgumentList, wird es als 2 Dateien interpretiert.
TK1987
Lösung TK1987 10.09.2020 aktualisiert um 14:35:58 Uhr
Goto Top
Moin,

Powershell kann Excel. Du brauchst auch gar nicht überprüfen, welche Version von Excel installiert ist.

# Excel öffnen
$Excel = New-Object -ComObject Excel.Application

# Arbeitsmappe öffnen
$Mappe = $Excel.Workbooks.Open('C:\Pfad\zur\Arbeitsmappe.xlsx')  

# Oder alternativ Arbeitsmappe Schreibgeschützt öffnen
$Mappe = $Excel.Workbooks.Open('C:\Pfad\zur\Arbeitsmappe.xlsx',0,$true)  

# Excel sichtbar machen
$Excel.Visible = $true

# Excel freigeben (wichtig, sonst bleibt der Prozess erhalten, auch wenn Excel vom Benutzer geschlossen wird)
[System.Runtime.InteropServices.Marshal]::ReleaseComObject($Excel)

Allerdings stellt sich die Frage, ob es nicht sinnvoller wäre, Kontextmenüeinträge für Excel-Dateien zu erstellen - sodass der Nutzer nur mit Rechtsklick auf eine Arbeitsmappe klicken braucht und dann die Auswahl hat, ob er normal oder schreibgeschützt öffnen will.

Gruß Thomas
godlie
Lösung godlie 10.09.2020 um 12:54:13 Uhr
Goto Top
Hallo,

das sollte sich mit ein bisschen Quoting schon ausgehen face-smile

Start-Process -FilePath "C:\Program Files\Microsoft Office\root\Office16\EXCEL.EXE" -ArgumentList "/r `"C:\temp\Test - Datei.xlsx`""  
Doskias
Doskias 15.09.2020 um 08:30:29 Uhr
Goto Top
Die Lösung funktioniert, allerdings bleibt Excel nicht im Vordergrund. Das Stört mich etwas. Allerdings war der Hinweis, dass Powershell Excel kann Goldwert.
Doskias
Doskias 15.09.2020 um 08:31:13 Uhr
Goto Top
Dank dem Hinweis von TK1987, dass Powershell Excel kann, sieht es jetzt einfach so aus:

Start-Process EXCEL.EXE -ArgumentList "/r `"C:\temp\Test 2.xlsx`""  
TK1987
TK1987 15.09.2020 aktualisiert um 09:12:44 Uhr
Goto Top
Zitat von @Doskias:
Dank dem Hinweis von TK1987, dass Powershell Excel kann, sieht es jetzt einfach so aus:
Start-Process EXCEL.EXE -ArgumentList "/r `"C:\temp\Test 2.xlsx`""  
Das Ganze geht gänzlich ohne Start-Process:
$Excel = New-Object -ComObject Excel.Application
[void]$Excel.Workbooks.Open("C:\temp\Test 2.xlsx",0,$true)  
$Excel.Visible = $true
[void][System.Runtime.InteropServices.Marshal]::ReleaseComObject($Excel)
Kontextmenüeinträge zu erstellen kommt für dich nicht in Frage?!

Gruß Thomas
Doskias
Doskias 15.09.2020 um 09:24:39 Uhr
Goto Top
Zitat von @TK1987:
Kontextmenüeinträge zu erstellen kommt für dich nicht in Frage?!


Darüber habe ich schon nachgedacht. Aber die Anwender sind es gewohnt die Daten mit einem Doppelklick zu öffnen.
TK1987
TK1987 15.09.2020 um 09:51:22 Uhr
Goto Top
Zitat von @Doskias:
Aber die Anwender sind es gewohnt die Daten mit einem Doppelklick zu öffnen.
Dann verstehe ich wiederum nicht, was du da eigentlich zu tun versuchst. Wenn die Anwender das Ganze per Doppelklick öfnnen sollen, bringt dich ein Start-Process auch nicht weiter. Dann bleiben dir nur 2 Möglichkeiten:

  • Für jede Excel-Datei eine Verknüpfung anlegen, um diese schreibgeschützt öffnen zu können (die Verknüpfungen könnte man ja per Powershell anlegen lassen)
  • Eine kleine grafische Oberfläche vorschalten, die beim Doppelklick auf eine Exceldatei abfragt, ob Normal oder Schreibgeschützt geöffnet werden soll.
Doskias
Doskias 15.09.2020 um 10:52:09 Uhr
Goto Top
Zitat von @TK1987:

Für jede Excel-Datei eine Verknüpfung anlegen, um diese schreibgeschützt öffnen zu können (die Verknüpfungen könnte man ja per Powershell anlegen lassen)

Genau das haben wir jetzt jetzt. Eine Verknüpfung für jede Excel-Datei. Jetzt haben wir allerdings verschiede Excel-Versionen durch ein Migrationsprojekt. Daher will ich die Excel-Verknüpfung durch ein PS-Skript ersetzen, damit es nicht zwei Verknüpfungen gibt. Bisher macht der Anwender ein Doppelklick auf eine Verknüpfung, die jedoch Wahlweise officve15 oder Office16 im Pfad haben muss. Künftig macht er nun einen Doppelklick auf ein eine Batch-Datei, die dann das PS-Skript ausführt welches mit Start-Process Excel (egal welche Version) öffnet.

Technisch keine schöne Lösung aber für die Migrationszeit akzeptabel und für den Anwender ändert sich nichts.
TK1987
TK1987 15.09.2020 um 14:22:01 Uhr
Goto Top
Zitat von @Doskias:
Jetzt haben wir allerdings verschiede Excel-Versionen durch ein Migrationsprojekt. Daher will ich die Excel-Verknüpfung durch ein PS-Skript ersetzen, damit es nicht zwei Verknüpfungen gibt.
Ok, dann noch ein anderer Vorschlag: Füge doch auf den Clients den Office-Ordner zur Path-Variable hinzu. Dann brauchst du in der Verknüpfung auch nur noch
Excel /r "C:\temp\Test 2.xlsx"  
ausführen und das Ganze funktioniert komplett ohne Powershellskript.
Doskias
Doskias 16.09.2020 um 10:07:50 Uhr
Goto Top
Auf die Idee bin ich gar nicht gekommen. Habe es jetzt erstmal an 3 Rechnern erfolgreich getestet. GPO ist geschrieben und wird verteilt. Ab morgen kann ich dann die Verknüpfungen umstellen. Danke für den Denkanstoß mit den Umgebungsvariablen.
Doskias
Doskias 21.09.2020 um 15:45:26 Uhr
Goto Top
So, ich musste die Bewertung nun noch einmal zurücknehmen. Die Aktuelle Situation ist nun wie folgt:

Ich verteile via GPO die Variable Office. Basierend auf der Zielgruppenadressierung (OS ist nicht Windows 10) gibt es den Pfad
 C:\Program Files\Microsoft Office 15\root\office15\ 
bzw. (OS ist Windows 10)
 C:\Program Files\Microsoft Office\root\Office16\

Das Funktioniert. Ich gelange mit %Office% in den entsprechenden Ordner. Ich habe die Verknüpfungen nun wie folgt angelegt:
%office%\excel.exe /r "Dateipfad"

Soweit so gut. Es funktioniert nun wie gewünscht. Klicke ich die Datei an, geht sie bei mir direkt auf. Jetzt wird es kurios. Öffne ich auf einem Windows 8 Arbeitsplatz nun diese Verknüpfung, sagt mir Windows, dass er den Pfad nicht öffnen kann. Als Pfad wird hier allerdings C:\Program Files\Microsoft Office\root\Office16\ angezeigt, also der Pfad von Windows 10, dem Rechner an dem ich die Verknüpfung bearbeitet habe. Zielort der Verknüpfung ist allerdings %office% und Ziel ist wie geplant %office%\Excel.exe. Die Systemvariable Office zeigt wie geplant allerdings auf C:\Program Files\Microsoft Office 15\root\office15. Daher nun die Frage: Wo ist mein Denkfehler bzw. der Fehler in meinen Einstellungen?

Meinem Verständnis nach hätte auf dem Windows 8 Rechner durch %office%\Excel.exe die Excel-Datei aus dem Office15 geöffnet werden müssen, auch wenn es bei mir Office16 ist.

Das ganze Spiel kann ich übrigens auch Rückwärts aufbauen. Wenn ich eine dieser angepassten Verknüpfungen nun auf einem Windows 8 Rechner öffne und neu speichere, können die Windows 10 Rechner die Datei nicht mehr öffnen.
TK1987
TK1987 22.09.2020 um 07:56:44 Uhr
Goto Top
Moin,

Zitat von @Doskias:
Meinem Verständnis nach hätte auf dem Windows 8 Rechner durch %office%\Excel.exe die Excel-Datei aus dem Office15 geöffnet werden müssen, auch wenn es bei mir Office16 ist.
Eben genau das hätte ich auch so erwartet...

... habe es gerade mal hier getestet. Leider scheint Windows beim Anlegen einer Verknüpfung alle Variablen aufzulösen - selbst wenn diese mit Powershell erstellt und der Pfad mit den Variablen in Single Quotes geschrieben wird.

Scheint auch keine Möglichkeit zu geben, dieses Verhalten zu umgehen. Damit sind Umgebungsvariablen in Verknüpfungen defacto leider nutzlos.

Bleibt dann wohl doch nur der Umweg über ein Skript, sorry.

Gruß Thomas