Empêcher MSI de lancer un EXE dans le contexte SYSTEM

Question

J'ai un problème ici avec un déploiement MSI sur lequel je travaille (en utilisant InstallerShield).Nous avons un programme exécuté en arrière-plan qui doit être exécuté par utilisateur et il doit démarrer automatiquement sans intervention de l'utilisateur.

Le problème vient de Objet de stratégie de groupe/Active Directory (GPO/AD), l'application est démarrée dans le contexte SYSTEM avant que quiconque ne soit connecté plutôt qu'en tant qu'utilisateur sur le point de se connecter.L'application ne peut s'exécuter qu'une seule fois par utilisateur, et il semble que le processus SYSTEM empêche le démarrage du processus USER.Cela signifie que les PC doivent être redémarrés deux fois avant que le logiciel puisse être déployé auprès des utilisateurs.Comment pouvons-nous arrêter cela ?

Fondamentalement, le flux de travail actuel est :

1. Exécutions d'installation/mise à niveau...tuer l'application en arrière-plan
2. Installer de nouveaux fichiers
3. Application d'arrière-plan de démarrage

Cela fonctionne pour les applications publiées et interactives MSI installations - seules les applications « attribuées » semblent avoir le problème.Comme l'étape 3 se déroule dans le contexte SYSTEM plutôt que dans le contexte utilisateur :(

Idéalement, je demanderais à l'équipe de développement de corriger le fichier EXE pour empêcher le lancement dans le contexte SYSTEM, mais c'est un cycle de publication et je recherche une solution basée sur un programme d'installation pour l'intérim.

(Je ne connais pas Installscript...Donc je suppose VBScript est probablement la voie à suivre s'il n'y a aucun élément InstallShield natif que je puisse utiliser.)

Answer 1

Vous pouvez utiliser le ConnexionUtilisateur propriété de Windows Installer comme condition à l’action de lancement de l’EXE.

Answer 2

Je ne compterais pas sur une propriété du programme d'installation Windows pour y parvenir.Si je comprends bien, vous souhaitez exécuter un fichier EXE une fois par utilisateur - probablement pour définir les paramètres par défaut de l'utilisateur ?Le seul moment où vous pouvez garantir que vous êtes dans le bon contexte est lorsque l’utilisateur se connecte réellement.Avec le nombre d'usurpations d'identité qui se produisent ces jours-ci dans le scénario de déploiement moyen, je ne fais confiance à rien d'autre qu'à une véritable connexion d'utilisateur comme étape correcte pour exécuter les fichiers EXE.

Il y a trop de sources de problèmes :verrouillages personnalisés des autorisations et des privilèges, verrouillage du serveur de terminaux, redirections de virtualisation, usurpation d'identité exécutée par le système de déploiement, remplacements du système d'exploitation pour les écritures dans le registre, etc.

Microsoft dispose d'une fonctionnalité appelée Active Setup qui vous permettra d'exécuter "quelque chose d'exécutable" une fois par utilisateur, lors de la connexion.Cela peut aller d'un script à un exécutable.Voir ma réponse ici pour plus de détails : Mise à jour du registre de chaque profil sur Windows Server 2003

Answer 3

AHA !Je savais qu'il devait y avoir une solution plus propre...le code sur lequel je travaillais commençait à ressembler à ceci :

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