ShellExecute: Fehler beim Öffnen einer PDF

  • Gibt es eine andere Möglichkeit abzufragen ob der angemeldete Benutzer über Administratorrechte verfügt (und wenn ja Excel mit Adminrechten zu starten, und wenn nicht das Script zu stoppen) ohne dass das AutoIt-Script selber Adminrechte benötigt? Je sicherer das Script umso besser. Nur auf Administratorkonten soll das Tool zu öffnen sein.

    • Offizieller Beitrag

    Edit: Geht ja noch viel einfacher:

    Upps! Das funktioniert ja wirklich!
    Wobei: Auf einem x64-System braucht man noch: #AutoIt3Wrapper_UseX64=y am Anfang, sonst stimmt der Pfad zu hosts nicht.
    Aber woher hast Du das "runas"?
    Das steht gar nicht in der Hilfe und unter MSDN findet man das auch nicht.


  • Edit: Geht ja noch viel einfacher:

    Gilt das auch für Excel und dem Aufruf der Exceldatei, inklusive Übergabe der Kennwörter? Oder ist das nur für die PDF-Datei gedacht?

    Die Quick&Dirty-Lösung interessiert mich auch, irgendwann muss ich ja mal anfangen zu lernen. ;)

  • Aber woher hast Du das "runas"?
    Das steht gar nicht in der Hilfe und unter MSDN findet man das auch nicht.

    Die Verben richten sich nach dem was in der Registry hinterlegt ist.
    Hier wird eine .exe aufgerufen. Unter HKCR\.exe finden wir den Verweis wo die Eintragungen zu finden sind was ShellExecute mit .exe-Dateien alles anfangen kann.
    In dem Fall also unter HKCR\exefile. Dort finden sich unter HKCR\exefile\Shell alle Verben die bei exe-Dateien verwendet werden können. Unter anderem auch das ominöse runas. Das Aufrufkommando unterscheidet sich hierbei nicht von "open" aber interessant ist der gesetzte Wert HasLUAShield. Wenn der gesetzt ist kommt für das Kommando vorher die UAC-Abfrage.

    Zum ersten mal bin ich vor einigen Jahren auf das HasLUAShield gestoßen als ich eine Lösung gesucht habe um Admin-Rechte in einer Batch-Datei zu erzwingen.

    Gilt das auch für Excel und dem Aufruf der Exceldatei, inklusive Übergabe der Kennwörter?

    Wenn Excel die Übergabe des Passwortes als Kommandozeilenparameter zulassen würde ja. Soweit ich gelesen habe gibts den aber nicht.
    Du arbeitest ja daher eh anscheinend mit dem Excel-Objekt.
    Von daher hast du nun schon hinreichende Gründe dem Skript Adminrechte zu geben.

    Die Quick&Dirty-Lösung interessiert mich auch, irgendwann muss ich ja mal anfangen zu lernen.

    War im Grunde die selbe Lösung - nur viel umständlicher (über ein externes VBS-File).

    • Offizieller Beitrag

    Die Verben richten sich nach dem was in der Registry hinterlegt ist.
    Hier wird eine .exe aufgerufen. Unter HKCR\.exe finden wir den Verweis wo die Eintragungen zu finden sind was ShellExecute mit .exe-Dateien alles anfangen kann.
    In dem Fall also unter HKCR\exefile. Dort finden sich unter HKCR\exefile\Shell alle Verben die bei exe-Dateien verwendet werden können. Unter anderem auch das ominöse runas. Das Aufrufkommando unterscheidet sich hierbei nicht von "open" aber interessant ist der gesetzte Wert HasLUAShield. Wenn der gesetzt ist kommt für das Kommando vorher die UAC-Abfrage.

    Zum ersten mal bin ich vor einigen Jahren auf das HasLUAShield gestoßen als ich eine Lösung gesucht habe um Admin-Rechte in einer Batch-Datei zu erzwingen.

    Ok! Vielen Dank für die Erklärung!
    Diesen Trick werde ich mir auf jeden Fall archivieren. Das kann ich bestimmt mal gebrauchen. :thumbup:

  • Bei den Office-Dateien hätte man mit "RunAs" ohenhin ein Problem. Denn für "RunAs" ist in der Registrierungsdatenbank standardmäßig kein Kommando hinterlegt. Den RunAs-Schlüssel muss ich immer manuell eintragen und mit dem zugehörigen Officeprogramm (den Pfad dorthin) versehen. Bei mehreren Dateitypen ganz schon viel Zeit erforderlich, und auf einem Rechner der mir nicht gehört kann ich das nicht einfach ungefragt per Script setzen. Man kann also nur das Officeprogramm per RunAs scriptgesteuert starten, eine Office-Datei dagegen nicht wenn auf dem Zielrechner kein RunAs-Kommando in der Registrierungsdatenbank gesetzt ist.

  • Der Trick wäre ja nicht die xlsx-Datei per Shellexecute aufzurufen sondern direkt die excel.exe und die zu öffnende xlsx-Datei als Parameter mitzugeben. Es gilt also was in der Registry für .exe hinterlegt ist und nicht für .xlsx.