Arresto di MSI dall'avvio di un EXE nel contesto SYSTEM

Question

Ho un problema con una distribuzione MSI su cui sto lavorando (utilizzando Installa Shield).Abbiamo un programma in esecuzione in background che deve essere eseguito per utente e deve avviarsi automaticamente senza l'intervento dell'utente.

Il problema è con Oggetto Criteri di gruppo/Directory attiva (GPO/AD) l'applicazione viene avviata nel contesto SYSTEM prima che qualcuno abbia effettuato l'accesso anziché come utente che sta per accedere.L'applicazione può essere eseguita solo una volta per utente e sembra che il processo SYSTEM impedisca l'avvio del processo USER.Ciò significa che i PC devono essere riavviati due volte prima che il software possa essere distribuito agli utenti.Come possiamo fermare tutto questo?

Fondamentalmente il flusso di lavoro attuale è:

1. L'installazione/aggiornamento viene eseguito...uccidi l'applicazione in background
2. Installa nuovi file
3. Applicazione in background di avvio

Funziona per le applicazioni pubblicate e interattive MSI installazioni: solo le applicazioni "assegnate" sembrano avere il problema.Poiché il passaggio 3 avviene nel contesto SYSTEM anziché nel contesto utente :(

Idealmente, chiederei al team di sviluppo di applicare una patch al file EXE per impedire l'avvio nel contesto SYSTEM, ma manca un ciclo di rilascio e per il momento sto cercando una soluzione basata sul programma di installazione.

(Non conosco Installscript...Quindi immagino VBScript è probabilmente la strada da percorrere se non ci sono elementi nativi di InstallShield che posso usare.)

Answer 1

Puoi usare il Utente di accesso proprietà di Windows Installer come condizione per l'azione di avvio dell'EXE.

Answer 2

Non farei affidamento su una proprietà del programma di installazione di Windows per ottenere questo risultato.Se ho capito bene, vuoi eseguire un file EXE una volta per utente, probabilmente per impostare le impostazioni predefinite dell'utente?L'unico momento in cui puoi garantire di essere nel contesto giusto è quando l'utente effettua effettivamente l'accesso.Con la quantità di imitazione in atto in questi giorni nello scenario di distribuzione medio, non mi fido di altro che dell'accesso di un utente reale come fase corretta per eseguire i file EXE.

Ci sono troppe fonti di problemi:blocchi personalizzati di autorizzazioni e privilegi, blocco del server terminal, reindirizzamenti della virtualizzazione, rappresentazione eseguita dal sistema di distribuzione, sovrascritture del sistema operativo per le scritture del registro, ecc...

Microsoft ha una funzionalità chiamata Active Setup che ti consentirà di eseguire "qualcosa di eseguibile" una volta per utente, all'accesso.Può trattarsi di qualsiasi cosa, da uno script a un eseguibile.Vedi la mia risposta qui per maggiori dettagli: Aggiornamento del registro di ogni profilo su Windows Server 2003

Answer 3

AHA!Sapevo che doveva esserci una soluzione più pulita...il codice su cui stavo lavorando stava iniziando ad assomigliare a questo:

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