fehlende Rechte nach EXE start auf WIN7

[ZOD]

Danke für die Tipps an alle.

@Dalai
ich hatte bereits Nutzerwechsel im XP und im Win7 und unter W2K (ja - das tuckert auch noch manchmal ) gemacht.
Ergebnis: es gibt nur beim Win7 das geschilderte Problem.

Mittels procexp.exe habe ich nun mir die Properties der EXE nach dem Aufruf aus der
Startroutine heraus angeschaut und mit denen nach Aufruf per Doppelklick verglichen.

Ergebnis:

a) in beiden Fällen ist der richtige User angegeben.
@Dalai: dies gilt auch nach Userwechsel für unterschiedliche User.

b) beim Aufruf per Doppelklick ist als Parent "explorer.exe" angegeben,
beim Aufruf aus der Startroutine ist als Parent die Exe der Startroutine angegeben.

Wenn man den Startvorgang im procexp.exe beobachtet "hängt" die Programm-Exe als Prozess zuerst
unter dem Prozess der Startroutine. Dann beendet sich die Startroutine und die
Programm-Exe ist auf die oberste Ebene der Prozesshirachie verschoben.

Ich würde daher gerne die Programm-Exe aus der Startroutine mit dem parent
"explorer.exe" starten.
Kann mir jemand sagen, wie das gehen könnte?
Danke.

[jaenicke]

Zitat von ZOD:

Ich würde daher gerne die Programm-Exe aus der Startroutine mit dem parent
"explorer.exe" starten.

Der Parent hat damit nichts zu tun, der ist rein informativ (lässt sich z.B. per WMI abfragen, ist aber auch nicht immer korrekt, z.B. wenn die Prozess ID des Parents schon neu vergeben wurde). Der Benutzerkontext ist das Entscheidende.

[ZOD]

OK, aber der Benutzer ist laut procexp der gleiche.
Dann müsste es mehrere "Benutzerkontexte" pro Benutzer geben,
was ich dann nicht verstehe.

Eigentlich suche ich nun nach einer Möglichkeit, das Programm
aus der Startroutine heraus so zu starten, als ob es per
Doppelklick aus einem Explorerfenster heraus gestartet würde.
Denn dann geht ja alles.

Ist es in diesem Fall besser mit ShellExecut bzw. ShellExecutEx zu arbeiten?
Oder handle ich mir da neue Probleme ein?

[Dalai]

OK, ich versuch's nochmal anders zu erklären: Jeder Benutzer hat eigene Netzlaufwerke, aber auch ein Elevated-Prozess im Falle der UAC hat eigene. Die Netzlaufwerke hängen von einem (Security) Token ab - Elevated-Prozesse haben ein anderes Token als Non-Elevated - völlig unabhängig davon, ob der Benutzer(name) derselbe ist. Das sind dann "mehrere Benutzerkontexte pro Benutzer", wenn du so willst.

MfG Dalai

[musicman56]

Hallo,

aus genau diesem Grund würde ich es mit ShellExecute und dem Verb "runas" probieren. Wenn die Startroutine des Setup dann als Administrator gestartet würde, müssten doch alle von dieser Routine gestarteten Prozesse ebenfalls unter dem Admin-Konto laufen.

[ZOD]

Guten Abend zusammen,

das probiere ich morgen aus und melde dann, wie es geklappt hat.

Danke für heute!

[ZOD]

Ich habe den Programmaufruf aus der Startroutine nun
mit

Delphi-Quellcode:

     ShellExecute(
        0,
        PChar('open'),
        PChar(ProgDateiPfad),
        PChar(ProgParameter),
        PChar(ArbeitsVerzeichnis),
        SW_SHOW
        );

gemacht - das Problem bleibt bestehen. Im procexp bekomme ich
(wie bei CreateProcess auch) den richtigen Benutzer angezeigt.

Wenn ich aus dem gestarteten Programm heraus einen Explorer starte mit

ShellExecute(Application.Handle, 'explore', PChar(Directoryname), nil, nil, SW_SHOWNORMAL);

dann sind die Netzverbindungen zwar da, jedoch die Verzeichnisse mit dem Attribut
"versteckt" werden nicht angezeigt.

Hängt das auch mit dem "(Security) Token" zusammen? Die Einstellung zur
Anzeige von versteckten Dateien wird doch normalerweise im Explorer unter

"Extras|Ordneroptionen|Ansicht|Versteckte Dateien und Ordner"

eingestelt bzw. im entspr. Registry-Schlüssel gespeichert.

Was mache ich hier falsch?