2008-08-27 12 views
2

Ich habe hier ein Problem mit einer MSI-Bereitstellung, an der ich gerade arbeite (mit InstallShield). Im Hintergrund läuft ein Programm, das pro Benutzer ausgeführt werden muss. Es muss automatisch ohne Benutzereingriff gestartet werden. Das Problem ist mit Group Policy Object/Active Directory (GPO/AD) Deployment die Anwendung wird im Systemkontext gestartet, bevor jemand angemeldet ist, anstatt als der Benutzer, der sich gerade anmeldet. Die Anwendung kann nur einmal pro Benutzer ausgeführt werden und es scheint, dass der SYSTEM-Prozess den Start des USER-Prozesses verhindert. Dies bedeutet, dass die PCs zweimal neu gestartet werden müssen, bevor die Software für die Benutzer bereitgestellt werden kann. Wie können wir das stoppen?Beenden von MSI beim Starten einer EXE im Systemkontext

Grundsätzlich ist der aktuelle Workflow ist:

  1. Installation/Upgrade läuft ... töten Hintergrund Anwendung
  2. neu installieren Dateien
  3. Startup Hintergrund Anwendung

Diese für veröffentlichte Anwendungen arbeitet und interaktive MSI Installationen - es ist nur "zugewiesene" Anwendungen, die das Problem zu haben scheinen. Da Schritt 3 im Kontext SYSTEM statt im Benutzerkontext passiert :(

Idealerweise hätte ich das Entwicklungsteam die EXE-Datei patchen, um zu verhindern, dass es im SYSTEM-Kontext startet, aber das ist ein Release-Zyklus entfernt, und ich ' m für die Zwischen für einen Installateur-basierte Lösung suchen.

(ich weiß InstallScript- nicht ... Also ich bin VBScript erraten ist wahrscheinlich der Weg zu gehen, wenn es keine native Install Zeug, das ich benutzen kann.)

Antwort

5

Sie können die LogonUser-Eigenschaft von Windows Installer als Bedingung für die Aktion verwenden, die die EXE startet

+0

Dies ist nur in unserer neuesten Version hinzugefügt (ersetzt meinen Code unten) - Funktioniert wie ein Charme! Danke :) – saschabeaumont

+1

wäre toll, wenn Sie erklären könnten, wie Sie das ausführlicher machen. –

1

AHA! Ich wusste, dass es eine saubere Lösung sein ... der Code, den ich gerade arbeitete begann so etwas wie folgt aussehen:

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 
1

Ich würde nicht auf einem Windows Installer-Eigenschaft verlassen, dies zu erreichen. Wenn ich richtig verstehe, dass Sie eine EXE-Datei einmal pro Benutzer ausführen möchten - wahrscheinlich, um Benutzereinstellungen einzurichten? Der einzige Zeitpunkt, an dem Sie sicherstellen können, dass Sie sich im richtigen Kontext befinden, ist der Zeitpunkt, zu dem sich der Benutzer tatsächlich anmeldet. Angesichts der Menge an Identitätswechsel, die an diesen Tagen im durchschnittlichen Bereitstellungsszenario stattfindet, traue ich nur einer echten Benutzeranmeldung als korrekt zu Bühne, um EXE-Dateien auszuführen.

Es gibt zu viele Fehlerquellen: benutzerdefinierte Berechtigung und priviledge lockdowns, Terminal-Server-Lockdown, Virtualisierung umleitet, Identitätswechsel durch das Entfaltungssystem laufen, das Betriebssystem überschreibt auf Registry usw. schreibt ...

Microsoft verfügt über eine Funktion namens Active Setup, mit dem Sie bei der Anmeldung pro Benutzer einmal "runnable" ausführen können. Dies kann alles von einem Skript zu einer ausführbaren Datei sein. Sehen Sie meine Antwort hier für weitere Details: Updating every profile's registry on Windows Server 2003