fehlende Rechte nach EXE start auf WIN7

[ChrisE]

Zitat von Dalai:

Noch allgemeiner formuliert: Netzlaufwerke sind seit Windows XP nutzerspezifisch (bei Win2k zwar ebenfalls, aber noch nicht so strikt getrennt wie bei XP+). D.h. jeder Nutzer hat seine eigenen Netzlaufwerke, so dass man bei Geschichten wie RunAs darauf achten muss. Das wäre dir übrigens auch aufgefallen, wenn du den Nutzerwechsel unter XP ebenfalls gemacht hättest - was nebenbei gesagt eine gute Idee wäre, denn momentan liest sich das so, als gingest du davon aus, dass der Nutzer Adminrechte hat...

MfG Dalai

Hmm - also eigentlich ist es noch ne Ecke härter. Seit Windows Vista kann der Benutzer Adminrechte haben aber Prozesse laufen trotzdem ohne diese Rechte (Stichwort UAC). Hebt der Anwender jetzt unter Windows Vista / 7 einen Prozess in seinem eigenen Namen auf Adminrechteebene (selber USER!) - existieren die Netzlaufwerke noch sind aber nicht verbunden. Seit Windows 8 gibt es nicht mal mehr die Netzlaufwerke auf der Adminrechte-Ebene des selben Benutzers.

Aber das ist glaube ich nicht das Problem hier.

Gruß, Chris

[EDIT]
Is doch immer mal wieder gut, sein vermeintliches Wissen zu überprüfen. Die Aussage bzgl. Windows 8 / 8.1 stimmt nur wenn man die Netzlaufwerke per WNetEnumResource macht. Prüft man hingegen hart jeden Laufwerksbuchstaben durch mit WNetGetConnection scheint es die Verbindungen zu geben? Warum ist mir im Augenblick noch völlig unklar
[/EDIT]

[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!