Skip to content
Retour au blogTutorial

Déploiement MSI de bureau à distance en entreprise via Group Policy

GoDesk Editorial Team9 min de lecture
Déploiement MSI de bureau à distance en entreprise via Group Policy

Si vous gérez des centaines ou des milliers de postes Windows, déployer un agent d'accès à distance machine par machine est fastidieux et source d'erreurs. Il vous faut une méthode répétable et traçable pour installer un MSI de bureau à distance sur tout votre parc — sans saturer le service d'assistance.

Si vous gérez des centaines ou des milliers de postes Windows, déployer un agent d'accès à distance machine par machine est fastidieux et source d'erreurs. Vous avez besoin d'une méthode répétable et auditable pour installer un MSI de bureau à distance sur votre parc — sans que les utilisateurs appellent le help desk. Ce guide explique comment effectuer un déploiement d'entreprise d'un MSI de bureau à distance avec Active Directory Group Policy (GPO), ce qu'il faut tester en priorité, les modes d'échec courants et quand préférer SCCM/Intune ou une solution cloud fournisseur.

1. Planification et prérequis — quoi vérifier avant de commencer

La fonctionnalité d'installation de logiciels via Group Policy est fiable pour de grands domaines Windows, mais elle comporte des contraintes. Avant d'ouvrir GPMC, assurez‑vous d'avoir :

  • Un domaine Active Directory et un point de gestion des GPO (Windows Server 2016 / 2019 / 2022 sont tous pris en charge).
  • Un serveur de fichiers avec un partage SMB (chemin UNC) que le compte ordinateur (SYSTEM) peut lire. N'utilisez pas de chemins locaux — GPO lit depuis le réseau au démarrage de la machine.
  • Le package MSI de votre agent distant. Vérifiez qu'il s'agit bien d'un package Windows Installer (.msi) et non d'un EXE wrapper.
  • Une OU de test avec des machines représentatives et un groupe pilote d'utilisateurs. Ne déployez jamais directement sur tout le domaine.
  • Un accès à la Group Policy Management Console (GPMC) et les droits pour créer/modifier des GPO.

Deux remarques pratiques : d'abord, les installations logicielles via GPO s'exécutent sous le compte Local System au démarrage de la machine (pour les packages assignés aux ordinateurs), donc votre partage et les ACLs de fichiers doivent permettre la lecture/exécution pour Domain Computers ou Authenticated Users. Ensuite, les installations basées sur MSI conviennent mieux aux agents au niveau machine qui doivent démarrer automatiquement pour tous les comptes ; si le package est strictement par‑utilisateur, l'assignation GPO au niveau machine n'est pas appropriée.

2. Préparer le MSI pour un déploiement massif

Tous les packages MSI ne sont pas prêts pour un déploiement en entreprise tel quel. Ce qu'il faut confirmer ou créer : commutateurs d'installation silencieuse, transforms de configuration et fichiers de configuration pré‑remplis (clés de licence, adresses de serveur, politiques).

  • Commande d'installation silencieuse : la plupart des MSI supportent les commutateurs msiexec. Testez sur une VM de labo avec :
    msiexec /i "\\fileserver\share\remote‑agent.msi" /qn /norestart /l*v "C:\Windows\Temp\remote‑agent‑install.log"
    Utilisez /qn pour des installations totalement silencieuses. Capturez des logs détaillés avec /l*v et inspectez‑les après un échec.
  • Transforms (MST) : si vous devez modifier des propriétés MSI (répertoire d'installation, démarrage automatique du service, clé de licence) créez un MST avec Orca (inclus dans le Windows SDK). Ouvrez le MSI dans Orca, choisissez Transform → New Transform, modifiez la table Property ou les entrées ServiceConfig, puis enregistrez le transform en .mst. Dans GPO vous ajouterez le MST sous Modifications.
  • Fichiers de config : certains agents lisent un JSON ou un INI à l'installation. Si c'est le cas, utilisez Group Policy Preferences pour copier cette configuration dans ProgramData ou Program Files immédiatement après l'installation, ou incluez‑la dans le MST.

Comment découvrir les propriétés MSI : ouvrez le MSI avec Orca et inspectez la table Property et les CustomAction. Si le fournisseur publie des paramètres silencieux ou un switch d'installation administrative (msiexec /a), suivez ses instructions. Si vous n'êtes pas sûr des propriétés correspondant à une clé de licence ou à une URL de serveur, demandez au support du fournisseur — ne stockez pas de secrets sur un partage accessible sans ACLs appropriées.

3. Créer la GPO et assigner le package

Étapes : préparez le chemin UNC, créez la GPO et assignez le MSI aux ordinateurs. Voici les actions exactes que j'utilise dans des environnements moyens et larges.

  1. Copiez le MSI et le MST sur un partage réseau accessible. Exemple de chemin : \\fileserver\software\godesk. Configurez les permissions NTFS+partage pour que SYSTEM (ou Domain Computers) ait Read & Execute, et seul votre groupe d'admins de déploiement ait Modify.
  2. Ouvrez Group Policy Management Console (GPMC.msc) en tant qu'admin, faites un clic droit sur l'OU de test et choisissez Create a GPO in this domain and Link it here. Nommez‑le clairement (par exemple « RemoteAgent – Pilot – Software Install »).
  3. Éditez la GPO : Computer Configuration → Policies → Software Settings → Software Installation. Clic droit → New → Package. Important : sélectionnez le MSI via le chemin UNC (\\fileserver\share\remote‑agent.msi), pas une copie locale.
  4. Choisissez Assigned (et non Published). Assigned to Computers s'installe au démarrage ; Published to Users expose le MSI dans Add/Remove Programs, ce qui n'est pas adapté pour des agents toujours actifs.
  5. Pour ajouter des transforms MST : double‑cliquez le package dans GPMC → Deployment → Advanced → onglet Modifications → Add → pointez sur votre fichier .mst. Si vous devez définir l'ordre des transforms ou plusieurs transforms, organisez‑les ici.
  6. Configurez éventuellement les paramètres d'Upgrade pour remplacer les versions MSI plus anciennes afin que GPO réalise les mises à jour automatiques. Utilisez l'onglet Upgrades et définissez les relations d'upgrade appropriées pour éviter les doublons de product code.

Quelques pièges fréquents : GPO installera les packages machine assignés au prochain redémarrage ou au démarrage ; sur les machines de test vous pouvez forcer l'application avec gpupdate /force puis un redémarrage. Si le MSI requiert une interaction utilisateur, GPO échouera — utilisez un script de démarrage (voir la section suivante) ou un autre système de déploiement.

4. Alternatives et quand les utiliser (SCCM, Intune, cloud fournisseur)

GPO est pertinent quand vous avez un domaine AD traditionnel et que vous voulez un déploiement simple sans infrastructure supplémentaire. Cependant, pour des environnements très larges, pour des déploiements étagés avec télémetrie avancée, ou pour des endpoints hors domaine (Azure AD ou distants), vous utiliserez souvent Microsoft Endpoint Configuration Manager (SCCM) ou Intune.

  • SCCM (ConfigMgr) offre une meilleure planification, une logique de retry et un reporting d'état. Utilisez SCCM lorsque vous devez garantir une conformité à 100% et conserver l'historique des révisions par appareil.
  • Microsoft Intune est adapté pour les machines hybrid/Azure AD joined ou quand vous souhaitez une distribution cloud et une gestion moderne. Le modèle Win32 d'Intune encapsule les MSI en .intunewin et prend en charge les règles de détection, les codes de retour et les dépendances.
  • La gestion de périphériques via le cloud du fournisseur (style TeamViewer/AnyDesk) peut être plus rapide pour des installations ad‑hoc car le fournisseur fournit des outils, des packages hôtes pré‑authentifiés et une distribution dynamique par groupes. Ces plateformes sont pratiques mais coûtent souvent plus par poste et peuvent nécessiter un accès sortant vers les serveurs du fournisseur. Voir notre comparaison des prix et compromis dans godeskflow‑vs‑teamviewer‑pricing.

Pour de nombreuses équipes qui veulent le contrôle et l'auto‑hébergement, GPO + MSI constitue le compromis idéal. Si vous utilisez GoDesk et souhaitez la voie la plus simple, vous pouvez télécharger le MSI depuis /download puis suivre les étapes GPO ; si la gestion cloud des appareils ou la facturation par appareil est un facteur, consultez /pricing avant de modéliser les coûts face à la charge opérationnelle SCCM/Intune.

5. Scripts et solutions de repli : scripts de démarrage, tâches planifiées et push à distance

Si le MSI a des particularités ou si vous devez garantir une logique de retry, un script de démarrage est souvent une solution pragmatique de repli. Les scripts de démarrage GPO s'exécutent en tant que SYSTEM et peuvent appeler msiexec directement sur le chemin UNC. Exemple de script de démarrage (batch) :

msiexec /i "\\fileserver\software\remote‑agent.msi" /qn /norestart /l*v "C:\Windows\Temp\remote‑agent‑install.log"
exit /b %ERRORLEVEL%

Placez ce script sous Computer Configuration → Policies → Windows Settings → Scripts (Startup/Shutdown). N'utilisez cela que si l'extension Software Installation via GPO échoue à cause d'une incompatibilité MSI — l'extension Software Installation offre des avantages tels que les installs annoncées, le suivi des upgrades et la suppression native lors de la désaffectation.

Une autre option est d'utiliser un push WinRM/PowerShell ponctuel (Invoke‑Command) ou PsExec pour des machines ciblées. Ceux‑ci requièrent que la gestion à distance soit activée et des règles de pare‑feu adéquates, et sont bruyants pour de grands parcs, mais utiles pour une remédiation d'urgence sur des machines sélectionnées.

6. Tests, supervision et procédures de dépannage courantes

Tester méthodiquement vous fera gagner des heures. Utilisez une OU de test dédiée avec quelques machines représentant différentes builds OS (Windows 10 21H2, Windows 10 22H2, Windows 11 22H2, Windows Server 2019/2022). Votre checklist devrait inclure :

  • Déplacez une machine dans l'OU pilote et redémarrez‑la pour déclencher l'installation au démarrage.
  • Forcez l'évaluation des GPO : gpupdate /force puis redémarrez. Utilisez gpresult /r ou rsop.msc pour confirmer que la stratégie est appliquée.
  • Inspectez les logs MSI : si vous avez utilisé le logging /l*v, vérifiez C:\Windows\Temp pour les logs détaillés. Vérifiez aussi Observateur d'événements → Application → MsiInstaller pour les événements Windows Installer.
  • Codes de sortie MSI et erreurs courantes : 1603 (erreur fatale pendant l'installation), 1612 (source d'installation introuvable), 0x80070005 (accès refusé). Pour 1612, vérifiez le chemin UNC et les permissions du partage ; pour 0x80070005, assurez‑vous que le compte machine a les permissions de lecture.
  • Si le package n'apparaît jamais dans Software Installation, confirmez que la GPO est liée à la bonne OU et que le compte machine appartient à cette OU. N'oubliez pas que la réplication des contrôleurs de domaine et de SYSVOL peut retarder la disponibilité ; attendez quelques minutes ou exécutez gpupdate.

Supervision dans le temps : GPO ne fournit pas de métriques de succès détaillées. Vous pouvez utiliser SCCM/Intune ou un script simple qui interroge l'existence du service de l'agent et remonte un état vers un log central. Par exemple, un script de remédiation programmé peut s'exécuter au démarrage pour vérifier si le service existe et, sinon, tenter une réinstallation et consigner les résultats sur un partage central.

7. Considérations de sécurité et hygiène de déploiement

Les agents d'accès à distance sont des cibles attractives. Traitez leur déploiement comme tout autre changement d'infrastructure :

  • Signez vos MSI ou vérifiez les signatures fournisseur. Les installateurs non signés peuvent être bloqués par AppLocker ou par des politiques PKI strictes.
  • Limitez l'accès au partage de distribution et évitez d'embarquer des secrets en clair. Si une clé de licence est requise, privilégiez un provisionnement par appareil ou des mécanismes de stockage sécurisés ; autrement restreignez l'ACL du partage pour que seuls les dispositifs de déploiement et les admins puissent lire.
  • Assurez‑vous que l'agent s'exécute avec les privilèges minimaux requis et que son compte de service est contraint. Suivez le guide de durcissement du fournisseur ; si vous utilisez TLS, vérifiez les certificats et effectuez du certificate pinning quand c'est possible.

Rappelez‑vous aussi que certains concurrents offrent des fonctionnalités que GPO ne propose pas nativement : regroupement propre des appareils, application de politiques à distance et console de gestion centralisée. Si cela compte pour votre organisation, incluez les capacités fournisseur dans votre analyse et comparez‑les aux outils internes de gestion. Notre primer IT entreprise (enterprise‑it‑management) couvre ces compromis plus en détail.

8. Checklist finale avant un déploiement large

  • Testez le MSI + MST sur toutes les familles d'OS que vous supportez.
  • Validez le comportement d'installation au démarrage et le démarrage du service après reboot.
  • Confirmez l'accès au partage UNC depuis les comptes machine et sur tous les sous‑réseaux (surveillez les problèmes SMB/DFS et les liens lents).
  • Planifiez un rollback : créez une GPO qui supprime le package ou planifiez un script pour désinstaller via msiexec /x ProductCode /qn si vous devez revenir en arrière rapidement.
  • Documentez la procédure de déploiement, les emplacements du MSI/MST et qui est propriétaire du partage et de la GPO. Stockez ce runbook dans votre système de gestion de configuration.

Si vous dépassez le pilote, effectuez des déploiements progressifs par OU ou par appartenance à un groupe AD. Surveillez les tickets help‑desk et les erreurs d'automatisation, puis passez au lot suivant.

Wrap up and next steps

Group Policy reste un moyen pragmatique et peu coûteux pour effectuer un déploiement MSI de bureau à distance à l'échelle d'une entreprise. Il est robuste pour les agents au niveau machine, s'intègre aux workflows AD existants et évite des licences supplémentaires pour de nombreuses organisations. Pour des environnements où la gestion cloud, des rapports enrichis ou les appareils hors domaine sont prioritaires, envisagez SCCM/Intune ou des outils cloud fournisseurs.

Pour des lectures complémentaires sur les choix d'accès à distance et la sécurité, voyez nos articles sur setting up remote access on Windows et remote desktop security. Si vous voulez tester un agent auto‑hébergé d'abord, téléchargez le MSI de GoDesk sur /download et modélisez un déploiement pilote ; vérifiez les détails de tarification et de licence sur /pricing avant de lancer un déploiement large.

Prêt à tester ? Téléchargez l'installateur depuis /download et suivez la checklist ci‑dessus pour réaliser un déploiement pilote OU cette semaine.