Naja viel zu aufwendig und riskant. Kannst natürlich in der Registry rumpfuschen und die Dateityp Zuordnung für alle relevanten Formate unbrauchbar machen und die Startmenüeinträge, Desktopverknüpfungen und angepinnte Programmverknüpfungen ebenfalls entfernen. Wäre mir aber viel zu riskant... was passiert wenn dein Script aufgrund schlampiger Programmierung abstürzt und die Änderungen nicht mehr rückgängig machen kann? Danach heißts dann wohl Office Reparatur oder Neuinstallation starten für den Anwender / IT Admin.
Die Frage ist doch viel mehr warum es dich überhaupt juckt wenn der Anwender nebenher eigene Instanzen von Excel startet. Soweit ich mich erinnere nutzt die Excel UDF COM Objekte um mit der gestarteten Excel Instanz zu kommunizieren. Dabei sollte es eigentlich keine Komplikationen mit anderen Instanzen geben.
Selbst wenn... die viel einfachere Lösung für das Problem ist ein aufdringlicher visueller Hinweis an den Benutzer, dass er gefälligst die Finger von manuellen Excelstarts zu lassen hat. Wenn er meint er ist gescheiter ist es sein Problem und er muss dann eben mit den Konsequenzen leben. Alternativ kannst du auch einfach Maus und Tastatur mit blockinput sperren und den Benutzer darauf Hinweisen, dass er sich jetzt mal 2min zurücklehnen darf bis dein Script fertig ist.
Wie dem auch sei und was du auch immer tun wirst... alle notwendigen Informationen bzgl. Registry, Startmenü und anpinnen von Verknüpfungen findest du recht schnell per google. Für pin/unpin gibt es funktionierende Autoit Scripte. Dateiverknüpfungen und die entsprechenden Registryänderungen sind von Microsoft dokumentiert. 
Fremde Registrierungsdatenbanken gehen mich nichts an, da pfusche ich nicht drin rum. Ich würde nie auf die Idee kommen fremde Registrierungsdatenbanken ungefragt anzufassen.
(...) sollte es eigentlich keine Komplikationen mit anderen Instanzen geben (...)
Da bin ich mir nicht so sicher. Es soll ja möglich sein, Daten zwischen zwei Instanzen auszutauschen. Und genau das möchte ich verhindern. Und verhindern kann man das nur wenn nur eine einzige Instanz zulässig ist. Ich kann zwar in der durch AutoIt erzeugten Instanz verhindern dass andere Dateien geöffnet werden können. Hierzu lenke ich die Menübefehle und Tastenkombinationen auf eine Fehlermeldung um, und die Einträge im Dateimenü und Menüband werden über die RibbonX-Definition umgelenkt bzw. deaktiviert (da die Datei mit Kennwort geschützt ist kann die Datei bzw. die RibbonX-Definition auch nicht manipuliert werden). Die Tastenkombinationen lenke ich über VBA um (Application.OnKey). Der Schutz ist also schon sehr hoch (94%). Da fehlen noch ein paar Prozenzpunkte, auch wenn 100% unmöglich ist.
Ich starte per AutoIT-Script Excel. Nun soll, wenn Excel durch das AutoIt-Script gestartet wurde, keine weitere Excelinstanz gestartet werden dürfen. Egal wie die zusätzliche Excelinstanz gestartet werden soll (Doppelklick auf Exceldatei, Doppelklick auf Programmverknüpfung etc.). Erst wenn die durch AutoIt gestartete Excelinstanz beendet wurde soll wieder die Standardeinstellung gelten. Wie erreicht man das? Danke!
Präventiv wirst du da nicht viel machen können aber du kannst einfach die PID deines Excel-Prozesses speichern und alle beenden die ein Excel-Prozess sind aber nicht die PID haben.
Dazu solltest du aber noch eine MsgBox aufblenden lassen, damit der User bescheid weiß was los ist.
(...) aufgrund schlampiger Programmierung (...)
Das hab ich überhört.
Die Frage ist doch viel mehr warum es dich überhaupt juckt wenn der Anwender nebenher eigene Instanzen von Excel startet.
Genau diese Frage finde ich auch wichtig.Falls dir einfach ein Problem aufgefallen ist, dann beschreibe besser dieses, als hier nach einer Lösung zu fragen, die du dir mit deinem Wissensstand überlegt hast.(Immer mal wieder gehen Fragen am eigentlichen Problem vorbei..).Falls es um etwas anderes geht, vergiss meinen Beitrag.
Edit: Vor meinem Beitrag am Handy stand da nur die erste Antwort 
(...) Präventiv wirst du da nicht viel machen können (...)
Also einfach ausgedrückt, "No Way"!?
Also einfach ausgedrückt, "No Way"!?
Es ist so wie @autoiter es schon gesagt hatte. Warum willst du mehrere Instanzen denn verhindern?
Willst du nicht, dass jemand die Datei editiert wärend du sie in AutoIt editierst? Dann kopier, bearbeite und benenn sie wieder um.
Du musst uns schon ein bisschen mehr verraten, dann können wir dir auch bessere Lösungswege geben.
Aber wie gesagt, präventiv kannst du da nicht viel machen.
Naja eine extreme Möglichkeit wäre noch die Datei excel.exe oder wie auch immer sie genau heißen mag zu Programmstart umzubenennen und ggf. die Excel UDF so anzupassen, dass deine Excel.exe - Kopie mit anderem Namen gestartet wird. Dadurch sollten alle Dateiverknüpfungen und sonstige Möglichkeiten Excel selbst zu starten solange ins Leere laufen bis du die Datei wieder zurückbenannt hast.
Eine weitere Variante ist es temporör in der Registry einen Dummy "Debugger" für die Excel.exe festzulegen um so weitere Starts zu verhindern. Diese Methode wird hier anhand des nervigen Werbepopups von Avira Antivir demonstriert (in aktuellen Versionen nicht mehr notwendig / möglich)
https://www.youtube.com/watch?v=eMGsw44iY00
Beide Varianten erfordern Admin Rechte und können außerdem ggf. Schutzmechanismen des installierten Virenscanners triggern. Wie oben schon erwähnt sind diese Lösungen ebenfalls problematisch wenn dein Script abstürzt, da deine Änderung dann eben erstmal permanent ist. Allerdings wären diese Varianten sehr einfach rückgängig zu machen.
(...) Warum willst du mehrere Instanzen denn verhindern? (...)
Wie ich schon schrieb möchte ich verhindern dass ein Anwender aus ein er anderen Instanz heraus in die durch AutoIt erzeugte Instanz "eindringt". Der Standardanwender wird das zwar nicht können, aber sicher sein kann man nie.
(...) in der Registry (...)
Soetwas sollte man nicht machen. Alles was der Sicherheit zuwiderläuft lasse ich.
Danke für die Tipps. Aber dann muss es so bleiben wie es jetzt ist. Im Vertrauen darauf dass niemand weiss wie man fremde Instanzen manipulieren kann.
Hallo @mumpel,
Muss die Excel Instanz denn überhaupt sichtbar sein? Das ist ja nicht immer notwendig.
Ansonsten verschiebe das Fenster in den nicht sichtbaren Bereich.
Ehrlich gesagt ist mir dein Szenario überhaupt nicht klar.
Ja ich weiß. Es wird Excel geöffnet und es soll keiner eine neue Instanz öffnen. Aber ich verstehe es nicht, warum das notwendig sein sollte. Was willst du genau verhindern?
(...) Muss die Excel Instanz denn überhaupt sichtbar sein? (...)
Natürlich. Da läuft ja eine Userform drin.
(...) Was willst du genau verhindern? (...)
Das schrieb ich schon in #10 und in #3
Aber ich verstehe es nicht, warum das notwendig sein sollte. Was willst du genau verhindern?
Frag ich mich auch immernoch. Warum soll überhaupt eine geheime, passwortgeschützte Excel Tabelle auf einem "Fremdrechner" automatisiert gelesen/bearbeitet werden? Das ist ansich schon unsicher! Um an die Excel Tabelle zu kommen brauch ich keine weitere Excel Instanz, sondern nur einen Dekompiler und/oder Networksniffer, werlche mir die Zugangsdaten zum Netzlaufwerk / Webspace und zur Excel Datei bermutlich in Sekunden offenbart.
(...) Warum soll überhaupt eine geheime, passwortgeschützte Excel Tabelle auf einem "Fremdrechner" automatisiert gelesen/bearbeitet werden? (...)
Da ist nichts Geheimes dran. Die Datei wird über mein AutIt-Scrip geöffnet. Die Userform darin ist ein "alternativer Richtlinien-Editor" Kennwörter werden automatisch übergeben. Die Datei soll nur noch besser geschützt sein, vor allem das VBA-Projekt (das erreiche ich schon mit dem geheimen Kennwort, das verhindert das Öffnen der Datei mit z.B. Hex-Editoren), damit niemand Schadcode einschleusen kann...
(das erreiche ich schon mit dem geheimen Kennwort, das verhindert das Öffnen der Datei mit z.B. Hex-Editoren)
Ja aber wo steht denn dein geheimes Passwort? Vermutlich im Quellcode deines Autoit Scriptes. Also alles andere als geheim und extrem leicht auslesbar.
Das heißt, du willst das nur so machen, weil du in vba firm bist und auch schon deine Routinen eingebaut hast.
Sorry, aber ich kann dir leider bei deiner Vorgehensweise nichts nennen, das dich weiter bringt.
Stattdessen würde ich dir raten, dich davon zu lösen und dir eine GUI zu bauen, in der der Anwender kontrolliert werkeln darf.
EDIT: Was misterspeed sagt, ist übrigens schlagend. Wenn du Angst vor den Nutzern hast, darfst du AutoIt fast nicht verwenden..
EDIT: Was misterspeed sagt, ist übrigens schlagend. Wenn du Angst vor den Nutzern hast, darfst du AutoIt fast nicht verwenden..
Naja wenn mans richtig macht schon. Man kann sowas auch mittels Client / Server Scripten machen. Die richtig kritischen Berechtigungen hat nur der Server Teil, welcher für den Benutzer weder zugreifbar noch manipulierbar ist. Der Client schickt lediglich mittels eigener API, bevorzugt verschlüsselt und authentifiziert die gewünschten Änderungsanfragen an den Server, welcher diese nach Prüfung dann umsetzt. Der Benutzer (Client) kann dann nur im begrenzten Umfang der API bestimmte Änderungen anfragen und hat niemals Zugriff auf fremde Zugangsdaten, welche das Serverscript evtl. für die Umsetzung benötigt.
(...) und dir eine GUI zu bauen (...)
Daran habe ich natürlich auch schon gedacht. Nur ist es nicht so leicht das extern nachzubauen. In Excel ist es viel leichter die Datensätze in den Exceltabellen anzusteuern, ohne ein zusätzliches Datenbankprogramm im Hintergrund laufen lassen zu müssen. Würde ich das komplett in AutoIt nachbauen wollen bräuchte ich ja ein Datenbankprogramm, welches aber nicht jeder Anwender hat.
(...) Vermutlich im Quellcode deines Autoit Scriptes (...)
Nein. Nicht im Klartext, sondern verschlüsselt (AES256). Da müsste sich der Anwender schon auskennen, also wissen wie man esw entschlüsselt. Und der Anwender müsste wissen wie man die EXE dekompiliert. Ich liefere logischerweise nicht deas AutoIt-Script, sondern eine kompilierte Exe (AutoIt hat auch nicht jeder).
