Verhindert, dass MSI eine EXE-Datei im SYSTEM-Kontext startet

Question

Ich habe hier ein Problem mit einer MSI-Bereitstellung, an der ich arbeite (mit der ich arbeite). InstallShield).Im Hintergrund läuft ein Programm, das pro Benutzer ausgeführt werden muss und automatisch ohne Benutzereingriff gestartet werden muss.

Das Problem liegt bei Gruppenrichtlinienobjekt/Active Directory (GPO/AD)-Bereitstellung wird die Anwendung im SYSTEM-Kontext gestartet, bevor jemand angemeldet ist, und nicht als der Benutzer, der sich gerade anmelden möchte.Die Anwendung kann nur einmal pro Benutzer ausgeführt werden und es scheint, dass der SYSTEM-Prozess den Start des USER-Prozesses verhindert.Das bedeutet, dass die PCs zweimal neu gestartet werden müssen, bevor die Software den Benutzern bereitgestellt werden kann.Wie können wir das stoppen?

Im Wesentlichen ist der aktuelle Arbeitsablauf:

1. Installation/Upgrade läuft...Hintergrundanwendung beenden
2. Neue Dateien installieren
3. Hintergrundanwendung starten

Dies funktioniert für veröffentlichte Anwendungen und interaktiv MSI Installationen - nur „zugewiesene“ Anwendungen scheinen das Problem zu haben.Da Schritt 3 im SYSTEM-Kontext und nicht im Benutzerkontext erfolgt :(

Im Idealfall würde ich das Entwicklungsteam die EXE-Datei patchen lassen, um den Start im SYSTEM-Kontext zu verhindern, aber das ist noch ein Release-Zyklus entfernt, und ich suche für die Übergangszeit nach einer installerbasierten Lösung.

(Ich kenne Installscript nicht ...Ich vermute also VBScript ist wahrscheinlich der richtige Weg, wenn es keine nativen InstallShield-Inhalte gibt, die ich verwenden kann.)

Answer 1

Du kannst den ... benutzen Anmeldebenutzer Eigenschaft von Windows Installer als Bedingung für die Aktion zum Starten der EXE-Datei.

Answer 2

Ich würde mich nicht auf eine Windows-Installer-Eigenschaft verlassen, um dies zu erreichen.Wenn ich das richtig verstehe, möchten Sie einmal pro Benutzer eine EXE-Datei ausführen – wahrscheinlich, um Benutzerstandards festzulegen?Nur wenn sich der Benutzer tatsächlich anmeldet, können Sie garantieren, dass Sie sich im richtigen Kontext befinden.Angesichts der Menge an Identitätsdiebstahl, der heutzutage in einem durchschnittlichen Bereitstellungsszenario vorkommt, vertraue ich einfach nichts anderem als einer echten Benutzeranmeldung als richtigem Schritt zum Ausführen von EXE-Dateien.

Es gibt zu viele Problemquellen:Benutzerdefinierte Berechtigungs- und Privilegiensperren, Terminalserversperrung, Virtualisierungsumleitungen, vom Bereitstellungssystem ausgeführter Identitätswechsel, Betriebssystemüberschreibungen für Registrierungsschreibvorgänge usw.

Microsoft verfügt über eine Funktion namens „Active Setup“, mit der Sie bei der Anmeldung einmal pro Benutzer „etwas Ausführbares“ ausführen können.Dies kann alles sein, von einem Skript bis hin zu einer ausführbaren Datei.Weitere Einzelheiten finden Sie in meiner Antwort hier: Aktualisieren der Registrierung jedes Profils unter Windows Server 2003

Answer 3

AHA!Ich wusste, dass es eine sauberere Lösung geben musste ...Der Code, an dem ich arbeitete, sah ungefähr so ​​aus:

On Error Resume Next 
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colProcessList = objWMIService.ExecQuery _
    ("Select * from Win32_Process Where Name = 'BackgroundProcess.exe'")
For Each objProcess in colProcessList
    colProperties = objProcess.GetOwner(strNameOfUser,strUserDomain)
    If strNameOfUser = "SYSTEM" Then    
        objProcess.Terminate()
    End If
Next