26
Installation und Admin-Rechte
Annahme: UAC ist aktiv, der User ist "normaler" Benutzer.
Eine Installation via setup.exe kann man in der Regel auf verschiedene Arten durchführen:
1. Als Administrator eingeloggt
2. Als "normaler" User, der das Programm setup.exe im Modus "Als Administrator ausführen" startet
3. Als "normaler" User, der das Programm setup.exe ganz normal startet
Wenn (3), dann wird das Installationsprogramm gestartet und der User wird aufgefordert, Admin-Credentials anzugeben. Bei (2) müssen die Admin-Credentials bereits zum Starten der setup.exe angegeben werden. Bei (1) reicht es, auf Anforderung "Fortsetzen" zu klicken.
Ich beobachte, dass nach Installationen oft die Verknüpfung auf dem Desktop oder einzelne Verzeichnisse oder Dateien für den User nur Lese-/Ausführungsrechte haben, löschen oder verschieben etc. ist nur mit Admin-Rechten möglich. Auch erfolgen Einträge in verschiedenen Benutzerverzeichnissen (C:\Users\...). Das alles kann ziemlich lästig sein.
Vermutlich hängt das unterschiedliche Verhalten auch vom Installationsprogramm selbst ab.
Gibt es einen guten Link dazu, oder kann mir es jemand erklären?
Dank im Voraus!, Ulrich
PS: Ich setze aus gegebenem Anlass gerade meinen Rechner neu auf!
Eine Installation via setup.exe kann man in der Regel auf verschiedene Arten durchführen:
1. Als Administrator eingeloggt
2. Als "normaler" User, der das Programm setup.exe im Modus "Als Administrator ausführen" startet
3. Als "normaler" User, der das Programm setup.exe ganz normal startet
Wenn (3), dann wird das Installationsprogramm gestartet und der User wird aufgefordert, Admin-Credentials anzugeben. Bei (2) müssen die Admin-Credentials bereits zum Starten der setup.exe angegeben werden. Bei (1) reicht es, auf Anforderung "Fortsetzen" zu klicken.
Ich beobachte, dass nach Installationen oft die Verknüpfung auf dem Desktop oder einzelne Verzeichnisse oder Dateien für den User nur Lese-/Ausführungsrechte haben, löschen oder verschieben etc. ist nur mit Admin-Rechten möglich. Auch erfolgen Einträge in verschiedenen Benutzerverzeichnissen (C:\Users\...). Das alles kann ziemlich lästig sein.
Vermutlich hängt das unterschiedliche Verhalten auch vom Installationsprogramm selbst ab.
Gibt es einen guten Link dazu, oder kann mir es jemand erklären?
Dank im Voraus!, Ulrich
PS: Ich setze aus gegebenem Anlass gerade meinen Rechner neu auf!
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 535832
Url: https://administrator.de/contentid/535832
Printed on: April 24, 2024 at 12:04 o'clock
26 Comments
Latest comment
Moin, prügel so lange auf die Programmierer ein, bis sie die von MS geforderten Standards umsetzen. Anders lernen die es nicht.
Henere
Henere
1
Das ist alles von den Installationsroutine definiert. Nur was ist denn genau deine Frage?
Gruß
Spirit
Gruß
Spirit
Hi,
E.
Zitat von @UserUW:
Ich beobachte, dass nach Installationen oft die Verknüpfung auf dem Desktop oder einzelne Verzeichnisse oder Dateien für den User nur Lese-/Ausführungsrechte haben, löschen oder verschieben etc. ist nur mit Admin-Rechten möglich.
Was logisch scheint. Die Setup.exe läuft dann im Kontext eines Administrators und wird höchstwahrscheinlich eine Installation für AllUsers ausführen. Damit landen die Desktop-Icons auf dem AllUsers-Desktop ("öffentlicher Desktop") und die Programmpfade im "Programme" bzw. "Programme (x86)" bekommen durch die Vererbung eh festgelegte Rechte.Ich beobachte, dass nach Installationen oft die Verknüpfung auf dem Desktop oder einzelne Verzeichnisse oder Dateien für den User nur Lese-/Ausführungsrechte haben, löschen oder verschieben etc. ist nur mit Admin-Rechten möglich.
Auch erfolgen Einträge in verschiedenen Benutzerverzeichnissen (C:\Users\...).
Das wäre doch sehr ungewöhnlich. Entweder landen sie bei einer "CurrentUser"-Installation im Profilpfad des ausführenden Benutzers oder bei einer "AllUsers"-Installation im "AllUsers" "Profil" ("Öffentlich") bzw. im Default-Profil. Oder, was auch sein kann: Man kann Einträge festlegen (i.a. Programmstarts, anpassungen in der Registry), welche dann bei jedem User ausgeführt werden, welcher sich nach der Installation dieses Programms anmeldet. Und diese Aktionen könnten dann im Kontext des gerade angemeldeten Benutzer Elemente erstellen, welche dann auch nur im Profil dieses Benutzers erscheinen. Das erflgt dann aber nicht schon bei der Installation sondern erst so nach und nach, wenn sich die Benutzer anmelden.E.
Anmerkung zu (3):
Es gibt Setups, die installieren sich im Usercontext (AppData), wenn sie nicht mit Adminrechten ausgeführt werden.
Ob das Programm nach Admin-Rechten fragt legt ein Flag im Header der Datei fest.
Schönen Gruß,
@Snowman25
Es gibt Setups, die installieren sich im Usercontext (AppData), wenn sie nicht mit Adminrechten ausgeführt werden.
Ob das Programm nach Admin-Rechten fragt legt ein Flag im Header der Datei fest.
Schönen Gruß,
@Snowman25
Zitat von @Snowman25:
Anmerkung zu (3):
Es gibt Setups, die installieren sich im Usercontext (AppData), wenn sie nicht mit Adminrechten ausgeführt werden.
Anmerkung zu (3):
Es gibt Setups, die installieren sich im Usercontext (AppData), wenn sie nicht mit Adminrechten ausgeführt werden.
Das ist bei uns ein ganz wunder Punkt, der die SRP kaputt macht. Bei meinem frisch aufgesetzten Rechner (nur sehr wenige Programme installiert, AppData ist für Ausführung gesperrt) meckern bereits drei Programme:
- Onedrive (bereits ab Installation! Habe den Rechner nicht zur Hand, kann deswegen nicht nachsehen, es ist ein Prozess der nach unverträglichen Programmen o.ä. scannt)
- Firefox (von denen hätte ich es wirklich nicht erwartet!), das bei jedem Start deswegen erst einmal eine Denkpause einlegt
- und noch ein drittes Programm (habe wie gesagt Rechner nicht zur Hand).
Wie gehen andere damit um? Man kann ja nicht jedes Programm und jede DLL auf eine Whitelist setzen!
Ulrich
Es gibt sogar noch wesentlich mehr Unterschiede wie ein Setup reagiert oder welche Credentials es benötigt.
Grundsätzlich kannst du wie folgt unterscheiden:
PS: Aufgrund der neuen Windows-Sicherheit-Schiene (ab Vista) ist es egal ob du lokaler Administrator bist oder nicht. Vorgänge die Administrative Rechte benötigen, werden immer abgefragt.
Shortcuts:
Es gibt mehrere Wege ein Shortcut am Desktop bereitzustellen. Der gängigste Weg ist unter "C:\Users\Public\Desktop". Dazu werden aber Admin-Rechte benötigt
Manche Setups legen Shortcuts prinzipiell unter "%userprofile%\Desktop" ab. Das sind aber schon sehr alte Installer .... die leider immer noch in Verwendung sind, oder solche Wrapper wie NullSoft die sich an keinen einzigen Standard (laut MS Whitepaper) halten.
Manche Shortcuts werden auch über die Registry in den Desktop eingebrannt. Ist aber eher selten.
Setups die als User ausgeführt werden haben nur die Möglichkeit ein Shortcut unter "%userprofile%\Desktop" anzulegen.
Wie du siehst, hat das ganze schon System und ist nicht unbedingt willkürlich.
Wo die ganzen AblageOrte sind kannst du aus der Registry holen:
Grundsätzlich kannst du wie folgt unterscheiden:
- Setup benötigt Admin-Rechte (hauptsächlich weil es sich unter ProgramFiles installieren will, oder weil einige Dateien irgendwo im Windows-Ordner abgelegt werden sollen)
- Setup benötigt keine Admin-Rechte (dann wird es "immer" unter $UserProfile% installiert)
PS: Aufgrund der neuen Windows-Sicherheit-Schiene (ab Vista) ist es egal ob du lokaler Administrator bist oder nicht. Vorgänge die Administrative Rechte benötigen, werden immer abgefragt.
Shortcuts:
Es gibt mehrere Wege ein Shortcut am Desktop bereitzustellen. Der gängigste Weg ist unter "C:\Users\Public\Desktop". Dazu werden aber Admin-Rechte benötigt
Manche Setups legen Shortcuts prinzipiell unter "%userprofile%\Desktop" ab. Das sind aber schon sehr alte Installer .... die leider immer noch in Verwendung sind, oder solche Wrapper wie NullSoft die sich an keinen einzigen Standard (laut MS Whitepaper) halten.
Manche Shortcuts werden auch über die Registry in den Desktop eingebrannt. Ist aber eher selten.
Setups die als User ausgeführt werden haben nur die Möglichkeit ein Shortcut unter "%userprofile%\Desktop" anzulegen.
Wie du siehst, hat das ganze schon System und ist nicht unbedingt willkürlich.
Wo die ganzen AblageOrte sind kannst du aus der Registry holen:
- USER = HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
- MACHINE = HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders
Na, das stimmt aber auch nicht ganz, was Du da schreibst.
Entweder es ist in der EXE selbst festgelegt, wie @Snowman25 schon schrieb.
Oder es wird vom Windows als "Setup" erkannt. Das ist zwar standardmäßig so aktiviert, kann aber per offizieller GPO abgeschaltet werden.
Edit: Wenn beides nicht zutrifft und man die EXE als Nicht-Admin startet bzw. als Admin aber nicht eleviert, dann läuft die EXE in einen Fehler, wenn sie versucht in "hoheitliche" Bereiche zu schreiben.
* Setup benötigt Admin-Rechte (hauptsächlich weil es sich unter ProgramFiles installieren will, oder weil einige Dateien irgendwo im Windows-Ordner abgelegt werden sollen)
Oder Registry.PS: Aufgrund der neuen Windows-Sicherheit-Schiene (ab Vista) ist es egal ob du lokaler Administrator bist oder nicht. Vorgänge die Administrative Rechte benötigen, werden immer abgefragt.
Nein, ganz sicher nicht.Entweder es ist in der EXE selbst festgelegt, wie @Snowman25 schon schrieb.
Oder es wird vom Windows als "Setup" erkannt. Das ist zwar standardmäßig so aktiviert, kann aber per offizieller GPO abgeschaltet werden.
Edit: Wenn beides nicht zutrifft und man die EXE als Nicht-Admin startet bzw. als Admin aber nicht eleviert, dann läuft die EXE in einen Fehler, wenn sie versucht in "hoheitliche" Bereiche zu schreiben.
Manche Setups legen Shortcuts prinzipiell unter "%userprofile%\Desktop" ab. Das sind aber schon sehr alte Installer .... die leider immer noch in Verwendung sind, oder solche Wrapper wie NullSoft die sich an keinen einzigen Standard (laut MS Whitepaper) halten.
Es kann sehr gut Gründe geben, das im Benutzerdesktop anzulegen. Eben wenn man bewuss eine "nur für mich"-Installation ausführt.Setups die als User ausgeführt werden haben nur die Möglichkeit ein Shortcut unter "%userprofile%\Desktop" anzulegen.
Nö. Startmenü, Favoriten, wo auch immer Schreibrechte auf einem Laufwerk sind.Zitat von @emeriks:
Na, das stimmt aber auch nicht ganz, was Du da schreibst.
Na, das stimmt aber auch nicht ganz, was Du da schreibst.
* Setup benötigt Admin-Rechte (hauptsächlich weil es sich unter ProgramFiles installieren will, oder weil einige Dateien irgendwo im Windows-Ordner abgelegt werden sollen)
Oder Registry.Würde ich jetzt ganz genau ausführen für was auch immer Adminrechte benötigt werden und wo nicht, hätten wir hier einen kleinen 10- Seiten Aufsatz. Wollen wir also mal die Kirche im Dorf lassen.
PS: Aufgrund der neuen Windows-Sicherheit-Schiene (ab Vista) ist es egal ob du lokaler Administrator bist oder nicht. Vorgänge die Administrative Rechte benötigen, werden immer abgefragt.
Nein, ganz sicher nicht.Entweder es ist in der EXE selbst festgelegt, wie @Snowman25 schon schrieb.
Oder es wird vom Windows als "Setup" erkannt. Das ist zwar standardmäßig so aktiviert, kann aber per offizieller GPO abgeschaltet werden.
verstehe nicht was du damit meinst: "Oder es wird vom Windows als "Setup" erkannt." Ich habe @Snowman25 ja auch nicht widersprochen. Um das nochmal hervorzuheben: Er hat vollkommen recht
Will eine Exe oder MSI die im User-Kontext ausgeführt wird, in Bereiche schreiben die (ohne etwas via GPO getrickst zu haben) ohne erhöhte Rechte nicht beschrieben werden dürfen, springt die UAC an und Credentials werden angefordert. Das ist kein Feature des Setups, sondern ein Feature des Betriebssystems. In XP konnte man sowas noch leicht umgehen. Ab Vista wurde eine zusätzliche Sicherheitsschiene eingeführt die auch lokale Administratoren auffordert Prozesse zu bestätigen die erhöhte Rechte erfordern.
Das kannst du sogar schon am Icon mancher Setups erkennen. Da ist nämlich unten rechts das UAC-logo eingebrannt.
Was sich ab Vista geändert hat kannst du hier noch (vereinfacht) nachlesen:
https://www.ionas.com/wissen/windows-sicherheitskonzept-benutzerkonten-u ...
Edit: Wenn beides nicht zutrifft und man die EXE als Nicht-Admin startet bzw. als Admin aber nicht eleviert, dann läuft die EXE in einen Fehler, wenn sie versucht in "hoheitliche" Bereiche zu schreiben.
Nur, wenn du die UAC deaktiviert hast.
Manche Setups legen Shortcuts prinzipiell unter "%userprofile%\Desktop" ab. Das sind aber schon sehr alte Installer .... die leider immer noch in Verwendung sind, oder solche Wrapper wie NullSoft die sich an keinen einzigen Standard (laut MS Whitepaper) halten.
Es kann sehr gut Gründe geben, das im Benutzerdesktop anzulegen. Eben wenn man bewuss eine "nur für mich"-Installation ausführt.Ja! da gebe ich dir vollkommen recht! Darum habe ich auch "Grundsätzlich" geschrieben und nicht "universell" oder "das gilt für alle"
Setups die als User ausgeführt werden haben nur die Möglichkeit ein Shortcut unter "%userprofile%\Desktop" anzulegen.
Nö. Startmenü, Favoriten, wo auch immer Schreibrechte auf einem Laufwerk sind.Wirklich? Erzählst du mir jetzt auch noch dass mache Icons auch grün sein können?
HINWEIS! Eventuelle Satzfehler, nicht aufgeführte oder nicht genau genug beschriebene Begebenheiten bitte selbst nachlesen! Mein Kommentar soll dem TO nur einen groben Überblick liefern und ihn nicht gleich überfrachten!
Grüße!
Dieser Part ist falsch.
Und um das zu untermauern, habe ich eben extra für Dich eine EXE kompiliert, die im C:\Wndows eine TXT schreiben will. Als Nicht-Admin ausgeführt, wird eine Ausnahme ausgelöst, als Admin ausgeführt, funktioniert es.
Erst wenn ich ich die EXE explizit dafür vorbereite, dass sie erhöhte Rechte anfordern soll (bzw. beim Start überprüft) ("requireAdministrator"), erst dann springt ggf. UAC dazwischen.
verstehe nicht was du damit meinst: "Oder es wird vom Windows als "Setup" erkannt."
Windows hat dafür einen simplem Algorithmus eingebaut. Das kann man abschalten. Ich finde es bloß gerade nicht. Klar - wenn es mal braucht ...Will eine Exe oder MSI die im User-Kontext ausgeführt wird, in Bereiche schreiben die (ohne etwas via GPO getrickst zu haben) ohne erhöhte Rechte nicht beschrieben werden dürfen, springt die UAC an und Credentials werden angefordert.
Nein, nicht einfach so.Und um das zu untermauern, habe ich eben extra für Dich eine EXE kompiliert, die im C:\Wndows eine TXT schreiben will. Als Nicht-Admin ausgeführt, wird eine Ausnahme ausgelöst, als Admin ausgeführt, funktioniert es.
Erst wenn ich ich die EXE explizit dafür vorbereite, dass sie erhöhte Rechte anfordern soll (bzw. beim Start überprüft) ("requireAdministrator"), erst dann springt ggf. UAC dazwischen.
Das kannst du sogar schon am Icon mancher Setups erkennen. Da ist nämlich unten rechts das UAC-logo eingebrannt.
Da ist kein UAC-Logo eingebrannt, sondern das ist eine Funktion des Windows Explorers. Nichts weiter. Dieser erkennt, dass die EXE explizit eingestellt hat, dass sie mit erhöhten Rechten ausgeführt werden muss. Möglicherweise tun das andere Dateiexplorer auch.Nur, wenn du die UAC deaktiviert hast.
Nein. s.o.Wirklich? Erzählst du mir jetzt auch noch dass mache Icons auch grün sein können?
Ich könnte Dich auch einfach ignorieren. Aber ich möchte einfach nur vermeiden, dass Deine pauschalen (und deshalb falschen) Aussagen andere möglicherweise in die Irre führen.Ah ja.... Bitte begründe das.
verstehe nicht was du damit meinst: "Oder es wird vom Windows als "Setup" erkannt."
Windows hat dafür einen simplem Algorithmus eingebaut. Das kann man abschalten. Ich finde es bloß gerade nicht. Klar - wenn es mal braucht ...OK! mache ich dir auch nicht zum Vorwurf. Geht mir genauso.
Will eine Exe oder MSI die im User-Kontext ausgeführt wird, in Bereiche schreiben die (ohne etwas via GPO getrickst zu haben) ohne erhöhte Rechte nicht beschrieben werden dürfen, springt die UAC an und Credentials werden angefordert.
Nein, nicht einfach so.Und um das zu untermauern, habe ich eben extra für Dich eine EXE kompiliert, die im C:\Wndows eine TXT schreiben will. Als Nicht-Admin ausgeführt, wird eine Ausnahme ausgelöst, als Admin ausgeführt, funktioniert es.
Wo ist deine kleine Exe? Ich kann sie nicht finden.
Ja komisch, dass ich dieses von dir beschrieben Verhalten auf keinem Rechner der sich in der Domain befindet (und auch sonst bei keinem) nachvollziehen kann.
Erst wenn ich ich die EXE explizit dafür vorbereite, dass sie erhöhte Rechte anfordern soll (bzw. beim Start überprüft) ("requireAdministrator"), erst dann springt ggf. UAC dazwischen.
Das ist Blödsinn! Ob administrative Rechte angefordert werden oder nicht entscheidet nicht das Setup sondern das Betriebssystem. Unter W7 war sowas eventuell noch möglich. Ab VISTA beißt du dir mit sowas aber die Zähne aus. Außer (wie du ja schon so oft erwähnt hast) du schraubst irgendwas an den Security-Settings rum.
Das kannst du sogar schon am Icon mancher Setups erkennen. Da ist nämlich unten rechts das UAC-logo eingebrannt.
Da ist kein UAC-Logo eingebrannt, sondern das ist eine Funktion des Windows Explorers. Nichts weiter. Dieser erkennt, dass die EXE explizit eingestellt hat, dass sie mit erhöhten Rechten ausgeführt werden muss. Möglicherweise tun das andere Dateiexplorer auch."Eingebrannt" ist vielleicht der falsche Ausdruck.
Wie ich schon geschrieben haben: "Das kannst du sogar schon am Icon mancher Setups erkennen."
Hauptsächlich handelt es sich hier um Setups die vom Windows Installer auch gelesen werden können:
https://docs.microsoft.com/en-us/windows/win32/msi/windows-installer-bes ...
Ein Tool (eines der ganz wenigen) das sich an alle Punkte des Whitepaper hält ist Flexera Installshield.
Nur, wenn du die UAC deaktiviert hast.
Nein. s.o.Wirklich? Erzählst du mir jetzt auch noch dass mache Icons auch grün sein können?
Ich könnte Dich auch einfach ignorieren.Jop! Das wollen die meisten, wenn plötzlich die Argumente ausgehen
Aber ich möchte einfach nur vermeiden, dass Deine pauschalen (und deshalb falschen) Aussagen andere möglicherweise in die Irre führen.
Interssant! Na dann zeige ich dir mal, dass eben genau deine Aussagen nicht der Wahrheit entsprechen:
Ich habe dazu ein Setup aus dem Netz geladen (FileZilla_3.46.3_win64_sponsored-setup.exe), welches für die Installation Administrative Rechte erfordert.
Das Wiki zu FileZilla falls es nicht kennst:
https://wiki.filezilla-project.org/Client_Installation
Ich werde es 1x als User ohne und 1x als User mit lokalen administrativen Rechten ausführen. Dazu bekommst auch ein paar Bilderchen:
Zuerst die Benutzer:
als User mit lokalen administrativen Rechten installieren:
Variante 1:
- Doppelklick auf die Setup.exe
- Benutzerkontensteuerung (aka UAC) poppt auf (Das ist das Standardverhalten. MS beschreibt das überall. man muss nur danach suchen)
- UAC mit NEIN bestätigen
- im Setup mit "i Agree" bestätigen
- Setup beendet sich ohne Fehlermeldung
- anschließend ist nichts installiert worden.
Variante 2
- Eingabeaufforderung in Benutzer-Kontext öffnen
- Pfad zur Exe angeben und ENTER drücken
- => Gleiche Verhalten! UAC poppt auf
- UAC mit NEIN bestätigen
- im Setup mit "i Agree" bestätigen
- Setup beendet sich ohne Fehlermeldung
- anschließend ist nichts installiert worden.
als User ohne lokale administrative Rechte installieren:
Ich kopiere dazu (immer noch als User mit lokalen administrativen Rechten) das Setup nach C:\ um es nicht extra nochmal laden zu müssen. Hierbei bekomme ich den Hinweis "Zugriff Verweigert". Um fortfahren zu können, muss ich mit erhöhten Rechten bestätigen. Auch das ist das Standardverhalten von Windows ab VISTA.
Variante 1
- Doppelklick auf die Setup.exe
- Benutzerkontensteuerung (aka UAC) poppt auf und fordert Credentials (Das ist das Standardverhalten.)
- UAC mit NEIN bestätigen
- im Setup mit "i Agree" bestätigen
- Setup beendet sich ohne Fehlermeldung
- anschließend ist nichts installiert worden.
Variante 2:
- Doppelklick auf die Setup.exe
- Benutzerkontensteuerung (aka UAC) poppt auf und fordert Credentials (Das ist das Standardverhalten.)
- Credentials eingeben und mit JA bestätigen
- im Setup mit "i Agree" bestätigen
- Setup läuft durch und beendet sich ohne Fehlermeldung
- anschließend ist FileZilla installiert worden.
Noch Fragen?
Verstehe mich nicht falsch. Ich kann mit dem "Ich hab längere Eier als du"-Gehabe absolut 0 anfangen. Ich möchte mein Wissen vermitteln, wenn mich jemand danach fragt. Im Bereich Automation habe ich 20 Jahre Erfahrung und schon so ziemlich alles gesehen. Unsere Kunden mit insgesamt ~40.000 Clients haben selten Grund zur Beanstandung meiner Lösungen, was Paketierung und Setup-Erstellung (zu 99% MSIs) angeht. In dem bereich kann ich fast jedem das Wasser reichen.
Natürlich gibt es immer wieder Neues und ich lasse mir gerne etwas beibringen. Was ich aber absolut nicht verkraften kann sind "Schlaumeiereien" nur weil der "Level" hier im Forum höher ist.
Also lass uns doch bitte so professionell bleiben wie es die Foren-Regeln gebieten. Ich habe kein TUT erstellt, viele Fragen bleiben offen, mit Sicherheit wurde nicht alles erklärt.Punkt!
Grüße!
@mayho33
Mit Verlaub: Ich habe das Gefühl, dass Du Dich persönlich angemacht fühlst, nur weil ich es gewagt habe, Dir zu widersprechen. Jedenfalls lassen mich Deine Formierungen als Reaktionen auf meine Kommentare das so schließen. Ich möchte Dir empfehlen, mal kurz inne zu halten und nur kurz die Möglichkeit in Betracht zu ziehen, dass es Dir möglicherweise entgangen ist, was ich überhaupt meine, und dass deshalb Dein letzter Kommentar - nicht zuletzt auch wegen seiner erschlagenden Länge - deshalb unnötig gewesen wäre.
Die EXE kann ich Dir gerne senden. Schreib mir ne PN mit einer Email-Adresse. Gerne sende ich auch den Quelltext, damit Du keine Sorgen haben musst, wegen einer Fremd-EXE, und kannst dann selbst kompilieren. Es sind nur 4 Code-Zeilen.
So. Die "längeren Eier"-Sprüche lasse ich jetzt mal aus.
Mit Verlaub: Ich habe das Gefühl, dass Du Dich persönlich angemacht fühlst, nur weil ich es gewagt habe, Dir zu widersprechen. Jedenfalls lassen mich Deine Formierungen als Reaktionen auf meine Kommentare das so schließen. Ich möchte Dir empfehlen, mal kurz inne zu halten und nur kurz die Möglichkeit in Betracht zu ziehen, dass es Dir möglicherweise entgangen ist, was ich überhaupt meine, und dass deshalb Dein letzter Kommentar - nicht zuletzt auch wegen seiner erschlagenden Länge - deshalb unnötig gewesen wäre.
Die EXE kann ich Dir gerne senden. Schreib mir ne PN mit einer Email-Adresse. Gerne sende ich auch den Quelltext, damit Du keine Sorgen haben musst, wegen einer Fremd-EXE, und kannst dann selbst kompilieren. Es sind nur 4 Code-Zeilen.
Bitte begründe das.
Das kann Dir diese EXE demonstrieren.Ob administrative Rechte angefordert werden oder nicht entscheidet nicht das Setup sondern das Betriebssystem.
Ja, sicher. Aber nur wenn es das entsprechende Flag in der EXE findet. Wir drehen uns im Kreis ...- Lade Dir einfach Microsoft Visual Studio Community herunter.
- Erstelle ein neues Visual Basic Projekt, Type "Windows Form-Anwendung"
- Doppelklicke auf das Formular "Form1"
- editiere Form1.vb wie folgt
Public Class Form1
Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
Try
CreateObject("Scripting.FileSystemObject").OpenTextFile("C:\Windows\Test123.txt", 2, True).WriteLine("Hallo mayho33!")
MsgBox("Erfolgreich!")
Catch ex As Exception
MsgBox("Fehlgeschlagen!")
End Try
End
End Sub
End Class- kopiliere die EXE
- melde Dich als Admin an (bei UAC-Standard-Einstellungen)
- starte über den Explorer die selbst kompilierte EXE (beachte auch das Icon der EXE)
- Du bekommst gemeldet "Fehlgeschlagen!"
- bearbeite das Projekt
- Eigenschaften des Projekts
- "Windows Einstellungen anzeigen"
- editiere die Zeile: <requestedExecutionLevel level="asInvoker" uiAccess="false" />
- ändern in: <requestedExecutionLevel level="requireAdministrator" uiAccess="false" />
- kopiliere die EXE
- melde Dich als Admin an (bei UAC-Standard-Einstellungen)
- starte über den Explorer die selbst kompilierte EXE (beachte wieder das Icon der EXE !)
- Das Icon im Explorer hat dieses kleine UAC-Schild drin.
- UAC meldet sich
So. Die "längeren Eier"-Sprüche lasse ich jetzt mal aus.
Hi Emeriks,
Ja! Ich habe mich von dir veräppelt gefühlt. Nicht, weil du mir widersprochen hast sondern weil du viele, eigentlich selbsterklärend, aber den Rahmen sprengende (zum Teil natürlich korrekte) Einwände in den Raum geworfen hast ohne diese zu begründen.
Mir schien du wolltest mich einfach bloßstellen. Entschuldige, wenn das nicht deine Intention war.
Zu deinem Beispiel:
Der TO spricht von einem Setup, nicht von einer simplen Exe. Vielleicht haben wir genau da aneinander vorbei geredet.
Ich gebe dir vollkommen recht, dass ich im Projekt explizit den Invoker angeben kann. Das hat aber nichts mit einem Setup zu tun.
Ja! Würde ich deine Exe als User ohne Adminrechte ausführen, würde sie beim Schreiben nach %windir% einen Fehler werfen. Genauso gut könnte man aber den Fehler abfangen und erhöhte Rechte anfordern.
Oben habe ich dir einen Screenshot eines Setups eingefügt. Unten Rechts im Bild das UAC-Icon. Das Setup ist übrigends nicht das Original von Flexera, sondern selbst erstellt mit Installshield 2013 Pro.
Das Einblenden des UAC-Emblems habe ich durch eine Condition erreicht die besagt, dass beim Ausführen explizit erhöhte Rechte notwendig sind. Windows erkennt das automatisch, weil der Windows Installer ab version 3 das automatisch erkennt.
Zu den langen Eiern:
Es müsste einfach mal sein. Mir scheint, das sich hier sehr oft jemand auf den Schlips getreten fühlt, wenn man anderer Meinung ist, oder sich sonst auf irgendeine Art und Weise angegriffen fühlt.
Warum kann man nicht höflich korrigieren, wenn begründet und gleich eine fundierte Erklärung liefern?
Immerhin will jeder hier entweder helfen oder geholfen werden
Wen du also einverstanden bist, dann *shake hands* und auf gute Zusammenarbeit?
LG, Mayho
Ja! Ich habe mich von dir veräppelt gefühlt. Nicht, weil du mir widersprochen hast sondern weil du viele, eigentlich selbsterklärend, aber den Rahmen sprengende (zum Teil natürlich korrekte) Einwände in den Raum geworfen hast ohne diese zu begründen.
Mir schien du wolltest mich einfach bloßstellen. Entschuldige, wenn das nicht deine Intention war.
Zu deinem Beispiel:
Der TO spricht von einem Setup, nicht von einer simplen Exe. Vielleicht haben wir genau da aneinander vorbei geredet.
Ich gebe dir vollkommen recht, dass ich im Projekt explizit den Invoker angeben kann. Das hat aber nichts mit einem Setup zu tun.
Ja! Würde ich deine Exe als User ohne Adminrechte ausführen, würde sie beim Schreiben nach %windir% einen Fehler werfen. Genauso gut könnte man aber den Fehler abfangen und erhöhte Rechte anfordern.
Oben habe ich dir einen Screenshot eines Setups eingefügt. Unten Rechts im Bild das UAC-Icon. Das Setup ist übrigends nicht das Original von Flexera, sondern selbst erstellt mit Installshield 2013 Pro.
Das Einblenden des UAC-Emblems habe ich durch eine Condition erreicht die besagt, dass beim Ausführen explizit erhöhte Rechte notwendig sind. Windows erkennt das automatisch, weil der Windows Installer ab version 3 das automatisch erkennt.
Zu den langen Eiern:
Es müsste einfach mal sein. Mir scheint, das sich hier sehr oft jemand auf den Schlips getreten fühlt, wenn man anderer Meinung ist, oder sich sonst auf irgendeine Art und Weise angegriffen fühlt.
Warum kann man nicht höflich korrigieren, wenn begründet und gleich eine fundierte Erklärung liefern?
Immerhin will jeder hier entweder helfen oder geholfen werden
Wen du also einverstanden bist, dann *shake hands* und auf gute Zusammenarbeit?
LG, Mayho
Auf meine Ursprungsfrage bezogen möchte ich nunmehr gerne ergänzen:
1. So wie ich es verstanden habe, sind die Installationsmethoden 1 (als Administrator eingeloggt) und 3 (als "normaler" User eingeloggt, der das Programm setup.exe ganz normal startet) beide OK. Wenn ich ein Programm nur allein nutzen möchte, muss ich natürlich nach 2 installieren (vorausgesetzt, das Programm unterstützt das überhaupt).
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen. Wer ist das dann überhaupt? Wer kann das Programm nutzen, wenn ich bei der Installation die Option "nur für mich installieren" wähle?
3. Neu war für mich, dass Icons bei der Installation auf dem Desktop des "öffentlichen Users" platziert werden sollen. Als ich jetzt nachgesehen habe, fand ich da tatsächlich auch zahlreiche Icons! Auf meinem persönlichen Desktop kann ich sie dann aber offenbar dennoch löschen, wenn ich sie nicht mehr brauche, und zwar ohne dass ich normalerweise dazu Admin-Rechte benötige.
Frage: Wieso benötige ich dennoch zum Löschen einzelner Icons Admin-Rechte? Liegt das dann am Programm oder an meiner Installationsweise?
Nun gibt es ja nicht nur den Desktop, sondern auch das Verzeichnis Appdata. Hier werden teilweise sogar ausführbare Programme reininstalliert. Da besteht ja eigentlich dasselbe Problem: Einem anderen User müssen diese Programme oder DLLs ebenfalls zur Verfügung gestellt werden. Werden die dann in das AppData jedes Benutzers eingefügt? Oder sind das irgendwelche Verknüpfungen, die letztlich alle auf den öffentlichen User verweisen?
Ulrich
1. So wie ich es verstanden habe, sind die Installationsmethoden 1 (als Administrator eingeloggt) und 3 (als "normaler" User eingeloggt, der das Programm setup.exe ganz normal startet) beide OK. Wenn ich ein Programm nur allein nutzen möchte, muss ich natürlich nach 2 installieren (vorausgesetzt, das Programm unterstützt das überhaupt).
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen. Wer ist das dann überhaupt? Wer kann das Programm nutzen, wenn ich bei der Installation die Option "nur für mich installieren" wähle?
3. Neu war für mich, dass Icons bei der Installation auf dem Desktop des "öffentlichen Users" platziert werden sollen. Als ich jetzt nachgesehen habe, fand ich da tatsächlich auch zahlreiche Icons! Auf meinem persönlichen Desktop kann ich sie dann aber offenbar dennoch löschen, wenn ich sie nicht mehr brauche, und zwar ohne dass ich normalerweise dazu Admin-Rechte benötige.
Frage: Wieso benötige ich dennoch zum Löschen einzelner Icons Admin-Rechte? Liegt das dann am Programm oder an meiner Installationsweise?
Nun gibt es ja nicht nur den Desktop, sondern auch das Verzeichnis Appdata. Hier werden teilweise sogar ausführbare Programme reininstalliert. Da besteht ja eigentlich dasselbe Problem: Einem anderen User müssen diese Programme oder DLLs ebenfalls zur Verfügung gestellt werden. Werden die dann in das AppData jedes Benutzers eingefügt? Oder sind das irgendwelche Verknüpfungen, die letztlich alle auf den öffentlichen User verweisen?
Ulrich
Zitat von @UserUW:
1. So wie ich es verstanden habe, sind die Installationsmethoden 1 (als Administrator eingeloggt) und 3 (als "normaler" User eingeloggt, der das Programm setup.exe ganz normal startet) beide OK. Wenn ich ein Programm nur allein nutzen möchte, muss ich natürlich nach 2 installieren (vorausgesetzt, das Programm unterstützt das überhaupt).
1. So wie ich es verstanden habe, sind die Installationsmethoden 1 (als Administrator eingeloggt) und 3 (als "normaler" User eingeloggt, der das Programm setup.exe ganz normal startet) beide OK. Wenn ich ein Programm nur allein nutzen möchte, muss ich natürlich nach 2 installieren (vorausgesetzt, das Programm unterstützt das überhaupt).
In Grunde sind alle Installations-Methoden OK. Es macht einfach nur einen Unterschied wie am Ende das Resultat ausschaut.
Wie du und einige andere schon geschrieben haben, kommt es darauf an was des Setup machen will. Will es generell nur im AppData schreiben (z.B. der Click-Once-Installer für GitHub for Windows), dann hast du auch die Desktop-Verknüpfung im User-Desktop liegen. Da macht es auch keinen Unterschied ob de den Installer mit erhöhten Rechten ausführst.
AT&T Paticipant (Enterprise Meeting-Software) unterstützt beides.
- Mit erhöhten Rechten ausgeführt und unter Angabe des Installations-Pfades (C:\ProgramFiles\...\) und eines weiteren Parameters der mir momentan nicht einfällt, wird unter ProgramFiles installert
- ohne administrative Rechte ausgeführt landen die Sourcen im AppData.
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen.
Genau das gleiche wie bei Methode 1
Wer ist das dann überhaupt? Wer kann das Programm nutzen, wenn ich bei der Installation die Option "nur für mich installieren" wähle?
"Nur für mich" bedeutet für den User der gerade am PC angemeldet ist und die Installation durchführt.
Administrator ist der lokale Administrator-Account. Er wird verwendet um deinen User in dessen Kontext erhöhte Rechte zu erteilen und die Installation durchführen zu lassen.
Manche würden jetzt vermutlich sagen: "Stimmt nicht!" Das ist richtig! Man kann ein Setup auch im SYSTEM-Kontext ausführen oder z.B. in einer Domain die Zuweisung der admin. Rechte via AD durchführen. usw...
3. Neu war für mich, dass Icons bei der Installation auf dem Desktop des "öffentlichen Users" platziert werden sollen. Als ich jetzt nachgesehen habe, fand ich da tatsächlich auch zahlreiche Icons!
Das wird von den verschiedenen Herstellern der Setups unterschiedlich gehandhabt und hat an und für sich nicht unbedingt damit zu tun ob du als Administrator oder nicht installierst. Auch macht es einen Unterschied welche Mechanismen das jeweilige Packaging-Tool, also das Tool mit dem das Setup erstellt wird, nutzen. Da gibts si viele wie Sand am Meer:
- NullSoft
- Wise
- Advanced-Installer
- Installshield v9 (Die Setups die eine ISS-Datei unterstützen)
- Installshield ab v12 ( und da gibts wieder Unterteilungen in MSI, Setup, Install-Script, MergeModules, usw.)
- WIX (Windows Installer XML)
- Auch in Visual Studio lassen sich Setups basteln
- usw...
Außerdem bieten viele dieser Tools die Möglichkeit das selbst zu definieren ob ein Shortcut da oder dort platziert wir. Da müsste man ziemlich ausschweifen um das genau zu erklären.
Wenn du es ganz genau wissen willst, dann ließ erst mal die Whitepapers:
https://docs.microsoft.com/en-us/windows/win32/msi/windows-installer-bes ...
Danach ist es auch wesentlich leichter weitere Infos im Netz zu finden.
Auf meinem persönlichen Desktop kann ich sie dann aber offenbar dennoch löschen, wenn ich sie nicht mehr brauche, und zwar ohne dass ich normalerweise dazu Admin-Rechte benötige.
Auf deinem persönlichen Desktop kannst du immer ohne Administratorrechte löschen. Das wäre sinnigerweise %USERPROFILE%\Desktop
Frage: Wieso benötige ich dennoch zum Löschen einzelner Icons Admin-Rechte? Liegt das dann am Programm oder an meiner Installationsweise?
Weil diese Icons im AllUsers-Desktop liegen, also hier: C:\Users\Public\Desktop
Nun gibt es ja nicht nur den Desktop, sondern auch das Verzeichnis Appdata. Hier werden teilweise sogar ausführbare Programme reininstalliert. Da besteht ja eigentlich dasselbe Problem: Einem anderen User müssen diese Programme oder DLLs ebenfalls zur Verfügung gestellt werden. Werden die dann in das AppData jedes Benutzers eingefügt? Oder sind das irgendwelche Verknüpfungen, die letztlich alle auf den öffentlichen User verweisen?
Wenn eine Installation im AppData durchgeführt wird, dann ist sie nur für den User verfügbar unter dessen Profil die Installation durchgeführt wurde. Kein anderer User kann darauf zugreifen.
Manche Setups legen aber unter C:\ProgramData den userspezifischen Teil an. Beim ersten Start des Programms werden dann Teile daraus nach AppData kopiert. Z.B. Firefox und auch Chrome machen das so, wenn man sie für ein Mass-Deployment konfiguriert.
Bereitstellungshandbuch für Chrome (Windows): https://support.google.com/chrome/a/answer/3115278?hl=de
Deploying Firefox in an enterprise environment: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Enterprise_depl ...
Die beiden Browser lassen sich nämlich auch ohne Adminrechte installieren. Dann landen sie aber im AppData des Users und nicht unter %ProgramFiles%
Jetzt ist es nochmal viel geworden. Und noch lange nicht alle Möglichkeiten erklärt.
Gute Nacht und beste Grüße!
Zitat von @mayho33:
Das ist Blödsinn! Ob administrative Rechte angefordert werden oder nicht entscheidet nicht das Setup sondern das Betriebssystem. Unter W7 war sowas eventuell noch möglich. Ab VISTA beißt du dir mit sowas aber die Zähne aus. Außer (wie du ja schon so oft erwähnt hast) du schraubst irgendwas an den Security-Settings rum.
Das ist Blödsinn! Ob administrative Rechte angefordert werden oder nicht entscheidet nicht das Setup sondern das Betriebssystem. Unter W7 war sowas eventuell noch möglich. Ab VISTA beißt du dir mit sowas aber die Zähne aus. Außer (wie du ja schon so oft erwähnt hast) du schraubst irgendwas an den Security-Settings rum.
Diese Aussage ist falsch, Windows 7 ist das Betriebssystem nach Vista, insofern sind die Sicherheitsmechanismen von Vista auch in Windows 7 enthalten. Ob Administrative Rechte angefordet werden wird im Manifest der EXE festgelegt, das Betriebssystem führt nur aus was dort festgelegt ist.
/Thomas
Zitat von @Th0mKa:
Diese Aussage ist falsch, Windows 7 ist das Betriebssystem nach Vista, insofern sind die Sicherheitsmechanismen von Vista auch in Windows 7 enthalten. Ob Administrative Rechte angefordet werden wird im Manifest der EXE festgelegt, das Betriebssystem führt nur aus was dort festgelegt ist.
Zitat von @mayho33:
Das ist Blödsinn! Ob administrative Rechte angefordert werden oder nicht entscheidet nicht das Setup sondern das Betriebssystem. Unter W7 war sowas eventuell noch möglich. Ab VISTA beißt du dir mit sowas aber die Zähne aus. Außer (wie du ja schon so oft erwähnt hast) du schraubst irgendwas an den Security-Settings rum.
Das ist Blödsinn! Ob administrative Rechte angefordert werden oder nicht entscheidet nicht das Setup sondern das Betriebssystem. Unter W7 war sowas eventuell noch möglich. Ab VISTA beißt du dir mit sowas aber die Zähne aus. Außer (wie du ja schon so oft erwähnt hast) du schraubst irgendwas an den Security-Settings rum.
Diese Aussage ist falsch, Windows 7 ist das Betriebssystem nach Vista, insofern sind die Sicherheitsmechanismen von Vista auch in Windows 7 enthalten. Ob Administrative Rechte angefordet werden wird im Manifest der EXE festgelegt, das Betriebssystem führt nur aus was dort festgelegt ist.
Stimmt natürlich! Absoluter Dummfug mit W7. Ich meinte natürlich XP.
Mit der Manifest-Datei gebe ich dir auch recht und da habe ich ja nie widersprochen. Im Manifest kann aber nur festgelegt werden in welcher Sicherheitsstufe das Programm laufen soll und ein paar Kompatibilitäts- und andere Eigenschaften, nicht aber ob man nun nach z.B. %Windir%\system32 schreiben darf. Dafür ist das NTFS-Berechtigungs-Model und einige andere Mechanismen da. Diese werden allein vom OS gesteuert. Und genau darum geht es ja dem To
Siehe: https://docs.microsoft.com/en-us/cpp/build/understanding-manifest-genera ...
Danke für den Hinweis.
Zitat von @mayho33:
Genau das gleiche wie bei Methode 1
Zitat von @UserUW:
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen.
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen.
Genau das gleiche wie bei Methode 1
Es gibt allerdings folgenden Unterschied: Lege ich das Installationsprogramm in ein Verzeichnis, in dem die Ausführung von Programmen per SRP gesperrt ist, dann kann ich das Programm auch nicht starten, wenn ich mich als Admin einlogge. Starte ich das Programm aber als normaler User via "als Administrator ausführen", und gebe ich dann denselben Admin an, dann startet das Programm.
Werden also via "als Administrator ausführen" lediglich die SRP ausgehebelt, oder führen die zusätzliche Berechtigungen ggf. nicht doch auch zu einem anderen Installationsergebnis?
Die beiden Browser lassen sich nämlich auch ohne Adminrechte installieren. Dann landen sie aber im AppData des Users und nicht unter %ProgramFiles%
Damit, das Programme bzw. exe-Files und DLLs nach AppData/... installiert werden, habe ich ein echtes Problem: Es macht mir eine strikte Trennung der Verzeichnisse in solche, in die geschrieben werden kann, aber in denen keine Programme ausgeführt werden können, und solche wo das Umgekehrte gilt, praktisch unmöglich. Für eine Whitelist-Behandlung ist die Anzahl der Dateien, die man aufnehmen müsste, zu groß. Teilweise kommen auch bei automatisch ausgeführten Programmupdates neue hinzu.
Verfolge ich ein falsches Ziel, oder mache ich es nur falsch?
Zitat von @UserUW:
Es gibt allerdings folgenden Unterschied: Lege ich das Installationsprogramm in ein Verzeichnis, in dem die Ausführung von Programmen per SRP gesperrt ist, dann kann ich das Programm auch nicht starten, wenn ich mich als Admin einlogge. Starte ich das Programm aber als normaler User via "als Administrator ausführen", und gebe ich dann denselben Admin an, dann startet das Programm.
Zitat von @mayho33:
Genau das gleiche wie bei Methode 1
Zitat von @UserUW:
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen.
2. Was genau passiert, wenn ich nach der Methode 2 (als Administrator ausführen) installiere? Darauf wurde bisher nicht eingegangen.
Genau das gleiche wie bei Methode 1
Es gibt allerdings folgenden Unterschied: Lege ich das Installationsprogramm in ein Verzeichnis, in dem die Ausführung von Programmen per SRP gesperrt ist, dann kann ich das Programm auch nicht starten, wenn ich mich als Admin einlogge. Starte ich das Programm aber als normaler User via "als Administrator ausführen", und gebe ich dann denselben Admin an, dann startet das Programm.
Darin liegt doch der Sinn der Sache oder?
Werden also via "als Administrator ausführen" lediglich die SRP ausgehebelt, oder führen die zusätzliche Berechtigungen ggf. nicht doch auch zu einem anderen Installationsergebnis?
Wenn du meinst ob die Installation dann anders aussieht, dann nein.
Du verhindert damit ja nur die Ausführung des Programms unter bestimmten Bedingungen
Die beiden Browser lassen sich nämlich auch ohne Adminrechte installieren. Dann landen sie aber im AppData des Users und nicht unter %ProgramFiles%
Damit, das Programme bzw. exe-Files und DLLs nach AppData/... installiert werden, habe ich ein echtes Problem: Es macht mir eine strikte Trennung der Verzeichnisse in solche, in die geschrieben werden kann, aber in denen keine Programme ausgeführt werden können, und solche wo das Umgekehrte gilt, praktisch unmöglich. Für eine Whitelist-Behandlung ist die Anzahl der Dateien, die man aufnehmen müsste, zu groß. Teilweise kommen auch bei automatisch ausgeführten Programmupdates neue hinzu.
Verfolge ich ein falsches Ziel, oder mache ich es nur falsch?
Mir ist nicht ganz klar was dein Ziel eigentlich ist. Deine Frage handelt ursprünglich von Unterschieden bei der Ausführung eines Setups mit oder ohne Adminrechte. Jetzt kommst du mir SRP.
Ein ziemlich großer Sprung.
Bei FF und Chrome kannst den Installations Pfad angeben. Lese die Installation guides oben.
Genauso findest du Hilfe dazu, wie Updates gesteuert werden können. Du kannst diese z. B. komplett deaktivieren oder auch nur z. B. monatlich durchführen.
Grüße!
Ein kleiner Zusatz noch:
Wenn du wissen willst wie umfangreich und unterschiedlich Setups sein können, dann machfolgendes:
Hole dir eine Testversion von Installshield
Öffne damit eine MSI und schaue dir die Settings an. Wichtig sind Custon Actions, Coditons, Properties, usw.
Zusätzlich kannst du das Flexera Forum besuchen und dir die Fragen dort ansehen.
Du wirst schnell sehen, dass es unzählige Möglichkeiten gibt wie etwas auf das System aufgebracht werden kann. Du erfährst dabei aber auch, dass sehr viele Dinge einfach nur simple Jobs sind die erst dann ein ganzes sind, wenn man bedenkt, dass ~80% davon Mechanismen des OS bedienen.
Bsp. Conditions:
Eine Condition
... kann das Setup selbst betreffen (nur als Admin ausführbar, die Architektur des OS betreffend (64-bit, 32-bit), Hardware Voraussetzungen, usw)
... Kann eine Feature betreffen (VersionNT > 601 bedeutet z. B. nur wenn das OS gr. W7)
... Oder einen Component (eine einzelne Datei, einen RegKey oder auch nur eine Ordnerstruktur)
Bsp Shortcuts:
Ein Shortcut kannst so konfigurieren, dass es entweder im AllUser abgelegt wird oder im User. Du kannst aber auch bestimmen, dass es nur angelegt wird, wenn bestimmte Prerequisites zutreffen. Oder auch, dass es erst beim ersten Programmstart angelegt wird. Das betrifft nur das integrierte Feature.
Usw. Usw.
Das Netz ist voll von Tipps wie man ein Setup aufbaut und alle unterscheiden sich.
Wenn du wissen willst wie umfangreich und unterschiedlich Setups sein können, dann machfolgendes:
Hole dir eine Testversion von Installshield
Öffne damit eine MSI und schaue dir die Settings an. Wichtig sind Custon Actions, Coditons, Properties, usw.
Zusätzlich kannst du das Flexera Forum besuchen und dir die Fragen dort ansehen.
Du wirst schnell sehen, dass es unzählige Möglichkeiten gibt wie etwas auf das System aufgebracht werden kann. Du erfährst dabei aber auch, dass sehr viele Dinge einfach nur simple Jobs sind die erst dann ein ganzes sind, wenn man bedenkt, dass ~80% davon Mechanismen des OS bedienen.
Bsp. Conditions:
Eine Condition
... kann das Setup selbst betreffen (nur als Admin ausführbar, die Architektur des OS betreffend (64-bit, 32-bit), Hardware Voraussetzungen, usw)
... Kann eine Feature betreffen (VersionNT > 601 bedeutet z. B. nur wenn das OS gr. W7)
... Oder einen Component (eine einzelne Datei, einen RegKey oder auch nur eine Ordnerstruktur)
Bsp Shortcuts:
Ein Shortcut kannst so konfigurieren, dass es entweder im AllUser abgelegt wird oder im User. Du kannst aber auch bestimmen, dass es nur angelegt wird, wenn bestimmte Prerequisites zutreffen. Oder auch, dass es erst beim ersten Programmstart angelegt wird. Das betrifft nur das integrierte Feature.
Usw. Usw.
Das Netz ist voll von Tipps wie man ein Setup aufbaut und alle unterscheiden sich.
Zitat von @mayho33:
Wenn beides zutrifft, ja.Wer ist das dann überhaupt? Wer kann das Programm nutzen, wenn ich bei der Installation die Option "nur für mich installieren" wähle?
"Nur für mich" bedeutet für den User der gerade am PC angemeldet ist und die Installation durchführt.Administrator ist der lokale Administrator-Account. ...
Richtig, aber was hat das damit zu tun?... Er wird verwendet um deinen User in dessen Kontext erhöhte Rechte zu erteilen und die Installation durchführen zu lassen.
Das ist schon wieder so eine pauschale Aussage, welche so nicht stimmt.DER Administrator nicht zwangsläufig. Ausschließlich dann, wenn man mit diesem selbst interaktiv angemeldet ist oder wenn man dessen Anmelddaten im UAC-Dialog explizit angibt. Sonst nicht.
Wenn man eine Anwendung explizit über "als Administrator ausführen" startet und/oder "über" den automatisch erscheinenden UAC-Dialog ausführt, dann passiert folgendes:
Entweder verfügt der ausführende Benutzer bereits über Administrator-Privilegien - dann wird nach der Bestätigung ohne Abfrage anderer Anmeldedaten mit erhöten Rechten fortgesetzt, wobei dann erst seine Administrator-Privilegien für diesen Prozess aktiviert werden. Nur dann ist "nur für mich" der Benutzer, der die Ausführung des Programms initiiert hat.
Oder er verfügt nicht über Administrator-Privilegien - dann erscheint in jedem Fall der UAC-Dialog mit der Abfrage von Anmeldedaten. Hier muss man dann die Anmeldedaten eines Benutzers angeben, welcher über Administrator-Privilegien verfügt, um fortsetzen zu können. Dann erfolgt die Ausführung im Kontext dieses anderen Benutzers. Und dann ist "nur für mich" dieser andere Benutzer! Nicht der initiierende Benutzer.
Und es ist vollkommen irrelevant, wie der verwendete Adminbenutzer an die administrativen Privilegien kommt. Sei es nun DER lokale Administrator, oder ein Mitglied DER lokalen Gruppe "Administratoren" oder sei es ein Konto, welchem explizit direkt diese Rechte erteilt wurden, manuell oder per GPO. Und es ist dann auch vollkommen irrelvant, ob es sich dabei um ein lokales Konto handelt oder eins aus einer vetrauten Windows Domäne oder DAS System-Konto. Ich erwähne das, weil ich explizit darauf hinweisen möchte, dass mit "als Administrator ausführen" nicht DER Administrator gemeint ist, sondern EIN Administrator.
Zitat von @emeriks:
Wenn man eine Anwendung explizit über "als Administrator ausführen" startet und/oder "über" den automatisch erscheinenden UAC-Dialog ausführt, dann passiert folgendes:
[...] Oder er verfügt nicht über Administrator-Privilegien - dann erscheint in jedem Fall der UAC-Dialog mit der Abfrage von Anmeldedaten. Hier muss man dann die Anmeldedaten eines Benutzers angeben, welcher über Administrator-Privilegien verfügt, um fortsetzen zu können. Dann erfolgt die Ausführung im Kontext dieses anderen Benutzers. Und dann ist "nur für mich" dieser andere Benutzer! Nicht der initiierende Benutzer.
Wenn man eine Anwendung explizit über "als Administrator ausführen" startet und/oder "über" den automatisch erscheinenden UAC-Dialog ausführt, dann passiert folgendes:
[...] Oder er verfügt nicht über Administrator-Privilegien - dann erscheint in jedem Fall der UAC-Dialog mit der Abfrage von Anmeldedaten. Hier muss man dann die Anmeldedaten eines Benutzers angeben, welcher über Administrator-Privilegien verfügt, um fortsetzen zu können. Dann erfolgt die Ausführung im Kontext dieses anderen Benutzers. Und dann ist "nur für mich" dieser andere Benutzer! Nicht der initiierende Benutzer.
Also:
Ich installiere als "normaler" User und UAC fordert mich zur Angabe eines Admins auf (im OP Methode 3), dann wird bei "nur für mich" für meinen normalen User installiert.
Installiere ich aber via "als Administrator ausführen", dann fordert mich diesmal (vermutlich) Windows, nicht UAC ebenfalls zur Angabe eines Admins auf (im OP Methode 2), "nur für mich" wird jetzt aber für diesen Admin installiert.
Korrekt?
Hast Du auch eine Erklärung, wieso "als Admin ausführen" die SRP aushebelt, während mit demselben Admin eingeloggt die SRP wirken?
Zitat von @UserUW:
Ich installiere als "normaler" User und UAC fordert mich zur Angabe eines Admins auf (im OP Methode 3), dann wird bei "nur für mich" für meinen normalen User installiert.
Nein. Hier ist "nur für mich" der explizit benannte Administrator.Ich installiere als "normaler" User und UAC fordert mich zur Angabe eines Admins auf (im OP Methode 3), dann wird bei "nur für mich" für meinen normalen User installiert.
Installiere ich aber via "als Administrator ausführen", dann fordert mich diesmal (vermutlich) Windows, nicht UAC ebenfalls zur Angabe eines Admins auf (im OP Methode 2), "nur für mich" wird jetzt aber für diesen Admin installiert.
Habe ich doch alles schon geschrieben. Wenn Du bereits Admin bist und "als Administrator ausführen" wählst, dann sorgt das nur dafür, dass die bereits gegebenen Administrator-Priviliegien aktiviert werden können (der Prozess eleviert läuft). Also fragt er dann nicht noch einmal einen anderen Admin ab. Also ist "nur für mich" der initiierende Admin.Wenn Du aber kein Admin bist und und "als Administrator ausführen" wählst, dann muss er nach einem anderen Benutzer fragen. Also ist hier "nur für mich" dieser andere Admin-Benutzer.
Zitat von @emeriks:
Zitat von @UserUW:
Ich installiere als "normaler" User und UAC fordert mich zur Angabe eines Admins auf (im OP Methode 3), dann wird bei "nur für mich" für meinen normalen User installiert.
Nein. Hier ist "nur für mich" der explizit benannte Administrator.Ich installiere als "normaler" User und UAC fordert mich zur Angabe eines Admins auf (im OP Methode 3), dann wird bei "nur für mich" für meinen normalen User installiert.
Sorry, bei allem Respekt. Aber das glaube ich nicht. Das wäre mir aufgefallen und würde vor allem bedeuten, dass man für einen "normalen" User keine Für-mich-Installation hinbekommt!
Installiere ich aber via "als Administrator ausführen", dann fordert mich diesmal (vermutlich) Windows, nicht UAC ebenfalls zur Angabe eines Admins auf (im OP Methode 2), "nur für mich" wird jetzt aber für diesen Admin installiert.
Habe ich doch alles schon geschrieben..Hatte ich nur zur Rekapitulation wiederholt. Aber stimmt der Zusatz "dann fordert mich diesmal (vermutlich) Windows, nicht UAC ebenfalls zur Angabe eines Admins auf"?
Danke, Ulrich
Zitat von @UserUW:
Sorry, bei allem Respekt. Aber das glaube ich nicht. Das wäre mir aufgefallen und würde vor allem bedeuten, dass man für einen "normalen" User keine Für-mich-Installation hinbekommt!
Wenn wir uns da mißverstanden haben sollten: Ich war noch im Kontext "als Administrator", also dass das Setup-Programm "requireAdministrator" eingestellt hat. (s.o.)Sorry, bei allem Respekt. Aber das glaube ich nicht. Das wäre mir aufgefallen und würde vor allem bedeuten, dass man für einen "normalen" User keine Für-mich-Installation hinbekommt!
Wenn es das nicht hat, dann kann der Benutzer "nur für mich" installieren, sofern das Setup-Paket das unterstützt und keine Änderungen im "AllUsers"-Bereich durchführen will.
Hatte ich nur zur Rekapitulation wiederholt. Aber stimmt der Zusatz "dann fordert mich diesmal (vermutlich) Windows, nicht UAC ebenfalls zur Angabe eines Admins auf"?
Ich nehme an, Dein Fokus liegt hier bei dieser Frage hier: "... Windows, nicht UAC ..."?Falls ja:
Das kann ich so nicht schwören, habe das nicht programmiert. Ich vermute aber, dass das im Endeffekt die selbe Schiene ist:
Wenn die Anwendung dieses Flag gesetzt hat, dass es als Admin ausgeführt werden muss ("requireAdministrator"), dann muss Windows die Anwendung elevieren starten, sonst nicht.
Wenn man die Anwendung über "als Administrator" ausführt, dann wird Windows das unabhängig von diesem Flag tun. Es ist aber der selbe Mechanismus.
Also wird bei beiden Wegen die Schiene sein:
a) Anwendung eleviert starten - UAC - User ist Admin - fragen und dann los
b) Anwendung eleviert starten - UAC - User ist kein Admin - Anmeldedaten abfragen und dann damit weiter
