2008-08-27 9 views
2

J'ai un problème avec un déploiement MSI sur lequel je travaille (en utilisant InstallShield). Nous avons un programme 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 est avec le déploiement Group Policy Object/Active Directory (GPO/AD) l'application est démarrée dans le contexte SYSTEM avant que quiconque soit connecté plutôt que comme l'utilisateur qui est sur le point de se connecter. L'application ne peut être exécutée qu'une fois par utilisateur , et il semble que le processus système 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é sur les utilisateurs. Comment pouvons-nous arrêter cela?Arrêt de MSI du lancement d'un fichier EXE dans le contexte SYSTEM

Fondamentalement, le flux de travail actuel est:

  1. Installation/mise à niveau fonctionne ... tuer application fond
  2. installer de nouveaux fichiers
  3. application fond de démarrage

Cela fonctionne pour les applications publiées et installations interactives MSI - ce sont seulement les applications 'affectées' qui semblent avoir le problème. Comme l'étape 3 se produit dans le contexte SYSTEM plutôt que dans le contexte utilisateur :(

Idéalement, l'équipe de développement corrige le fichier EXE pour empêcher le lancement dans le contexte SYSTEM, mais c'est un cycle de publication, et m à la recherche d'une solution installateur pour assurer l'intérim.

(Je ne sais pas ... InstallScript Je devine VBScript est probablement la voie à suivre s'il n'y a pas de choses natif InstallShield je peux utiliser.)

Répondre

5

Vous pouvez utiliser la propriété LogonUser de Windows Installer comme condition à l'action de lancer le

EXE.
+0

Juste ajouté ceci dans notre dernière version (en remplaçant mon code ci-dessous) - Fonctionne comme un charme! Merci :) – saschabeaumont

+1

serait génial si vous pouviez expliquer comment faire cela plus en détail. –

1

AHA! Je savais qu'il devait y avoir une solution plus propre ... le code que je travaillais sur commençait à ressembler à quelque chose comme 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 
1

Je ne me fierais pas sur une propriété d'installation de Windows pour y parvenir. Si je comprends bien, vous voulez exécuter un fichier EXE une fois par utilisateur - probablement pour configurer les paramètres par défaut de l'utilisateur? La seule fois où vous pouvez garantir que vous êtes dans le bon contexte, c'est quand l'utilisateur se connecte réellement. Avec la quantité d'usurpation d'identité qui se passe ces jours-ci dans le scénario de déploiement moyen, je ne fais confiance qu'à un utilisateur réel. étape pour exécuter les fichiers EXE.

Il y a trop de sources de problèmes: autorisation personnalisés et Privilège bouclages, lockdown Terminal Server, la virtualisation redirections, usurpation d'identité gérés par le système de déploiement, système d'exploitation overrides pour registre écrit etc ...

Microsoft a une fonction appelée Configuration active qui vous permettra d'exécuter "quelque chose de runnable" une fois par utilisateur, lors de la connexion. Cela peut être n'importe quoi d'un script à un exécutable. Voir ma réponse ici pour plus de détails: Updating every profile's registry on Windows Server 2003

Questions connexes