Comment installer à distance un logiciel sur un autre ordinateur

Q: Comment puis-je installer des logiciels à distance sur un ordinateur d'un groupe de travail ?

Définissez LocalAccountTokenFilterPolicy sur 1 sur la cible, puis utilisez PsExec avec -h ou PowerShell avec la machine ajoutée à TrustedHosts. Les machines en groupe de travail n’ont pas de domaine pour délivrer des jetons complets, donc la valeur de registre et l’authentification NTLM avec des informations d’identification locales explicites sont toutes deux requises.

Pour installer à distance un logiciel sur un autre ordinateur, connectez-vous via Bureau à distance et exécutez le programme d’installation comme si vous étiez au clavier, ou déployez une installation silencieuse depuis la ligne de commande avec PowerShell Invoke-Command ou PsExec et msiexec /qn. C’est en ligne de commande que la plupart des gens rencontrent Access is denied même avec le bon mot de passe administrateur, car Windows remet aux comptes d’administrateur locaux ordinaires un jeton filtré lors d’une ouverture de session réseau. Bureau à distance évite ce filtrage car il s’agit d’une ouverture de session interactive, et un compte de domaine provenant du domaine de la machine cible obtient dans tous les cas un jeton complet.

Pour un compte d’administrateur local ordinaire, la solution la plus rapide est une valeur de Registre sur la machine cible : définissez LocalAccountTokenFilterPolicy sur 1 sous HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, puis exécutez le programme d’installation en mode silencieux et capturez son code de sortie. Ce guide couvre chaque méthode avec des commandes testées, un script pour plusieurs ordinateurs, et une correction pour chaque erreur courante, des échecs PSEXESVC à winget 0x8a15000f.

Si vous préférez ignorer complètement le casse-tête du jeton, HelpWire est un logiciel d’assistance à distance qui se connecte à une machine distante, et vous pouvez demander des droits d’administrateur pendant la session. Vous exécutez le programme d’installation dans un véritable bureau interactif, de sorte que l’invite d’élévation se comporte comme elle le ferait au clavier.

Table des matières

La cause vient des restrictions UAC à distance, aussi appelées filtrage de jeton. Lorsqu’un compte local appartenant au groupe Administrateurs se connecte via le réseau, l’Autorité de sécurité locale lui remet un jeton filtré avec un niveau d’intégrité moyen, de sorte que le groupe Administrateurs se trouve en état de refus uniquement et que les actions privilégiées sont bloquées. L’ouverture de session réseau, c’est‑à‑dire via WinRM, PsExec, WMI ou une copie C$, produit un jeton filtré pour les administrateurs locaux.

Deux détails déterminent si vous êtes concerné. Un compte d’un domaine, provenant du domaine même de la cible, et membre du groupe local Administrateurs, est exempté et reçoit un jeton complet, raison pour laquelle les environnements de domaine voient rarement ce problème. Le compte Administrateur intégré RID 500 est également un cas particulier et n’est pas filtré sauf si FilterAdministratorToken est activé. Tous les autres, c’est‑à‑dire les comptes d’administrateur locaux ordinaires et les comptes issus d’un autre domaine, reçoivent le jeton filtré, que la cible soit dans un groupe de travail ou jointe à un domaine. Ce seul fait explique pourquoi Access is denied depuis PsExec, net use, une copie C$, ainsi que le jeton filtré non administrateur avec lequel vous vous retrouvez via Invoke-Command.

La seconde cause fondamentale est la session non interactive. Une commande distante s’exécute là où personne ne peut cliquer, de sorte qu’un programme d’installation qui attend une fenêtre se bloque en attendant un bouton ou échoue purement et simplement.

La façon la plus rapide d’installer des logiciels à distance est d’adapter la méthode à votre environnement, car chacune se comporte différemment avec les jetons d’administrateur, les groupes de travail et Windows Home. Ce tableau tranche ce choix avant que vous n’exécutiez la moindre commande. Stratégie de groupe est incluse ici car elle ne fonctionne que dans un domaine et mérite d’être retenue ou écartée dès le départ.

Méthode	Comportement du jeton administrateur	Fonctionne dans un groupe de travail	Hôte Windows Home	Interrompt l’utilisateur	Via Internet
RDP	Jeton complet, interactif	Oui	`No host`	Oui, les déconnecte	Avec VPN
PowerShell à distance	Filtré pour les administrateurs locaux	Avec `TrustedHosts`	Oui	Non	Rarement
`cmd` + `PsExec`	Filtré. Utilisez `-h`.	Avec correctif du registre	Oui	Non	Non
winget	Ne fonctionne pas avec `WinRM`	Exécution locale uniquement	Oui	Non	Non
Stratégie de groupe	SYSTEM, assignée à l’ordinateur	`No`, domaine uniquement	Domaine uniquement	Non	Non
HelpWire	Élévation complète et interactive	Oui	Oui	Non	Oui

Un facteur conditionne toutes les méthodes en ligne de commande ci-dessous : le compte avec lequel vous vous connectez. Un compte de domaine provenant du propre domaine de la cible, membre de son groupe Administrators, reçoit un jeton complet et fonctionne tel quel. Un simple compte d’administrateur local obtient le jeton filtré, de sorte que ses copies via C$ et ses appels PsExec renvoient Access is denied, et PowerShell à distance refuse la session ou l’exécute sans droits d’administrateur, jusqu’à ce que vous définissiez LocalAccountTokenFilterPolicy sur 1 sur la cible, comme indiqué dans la section des correctifs. RDP fait exception, car il s’agit d’une ouverture de session interactive plutôt que d’une ouverture de session réseau.

Bureau à distance est la méthode la plus propre pour installer des logiciels à distance sur un autre ordinateur, car il s’agit d’une session interactive qui s’exécute avec un jeton d’administrateur complet une fois l’invite du Contrôle de compte d’utilisateur (UAC) validée. Connectez-vous, puis installez comme si vous étiez devant la machine.

Sur l’ordinateur cible, appuyez sur Win + R, tapez SystemPropertiesRemote, et activez Autoriser les connexions à distance à cet ordinateur.
Sur votre machine, ouvrez Connexion Bureau à distance (mstsc.exe), saisissez le nom de la cible ou son adresse IP, et connectez-vous avec un compte qui est administrateur local sur celle-ci.
Copiez le programme d’installation via la session, ou redirigez un lecteur local dans Ressources locales afin de pouvoir y accéder.
Exécutez le programme d’installation. Lorsque l’invite UAC apparaît, approuvez-la dans la fenêtre RDP, puis terminez l’assistant.

Il est utile de connaître les limites avant de vous y fier. Les éditions Windows Home ne peuvent pas héberger de session RDP du tout. Elles n’exécutent que le client. Sur les versions clientes de Windows, une seule console est prise en compte, donc se connecter déconnecte la personne déjà connectée sur la machine. Et un utilisateur standard sans identifiants d’administrateur sur la machine distante ne peut toujours pas approuver l’invite, ce qui vous renvoie vers les méthodes en ligne de commande ci-dessous.

Pour installer des logiciels à distance avec PowerShell, vous vous appuyez sur Invoke-Command, mais deux écueils piègent la plupart des gens. La session distante est non interactive, donc l’installateur doit s’exécuter entièrement en mode silencieux, et la session peut se fermer avant qu’un installateur qui rend la main rapidement n’ait fini, ce qui annule l’installation. L’article bien connu de Kevin Marquette sur les installations à distance documente les deux, et la solution au second est Start-Process -Wait.

Sur la cible, activez l’administration à distance une fois. Depuis une fenêtre PowerShell ouverte en tant qu’administrateur, exécutez Enable-PSRemoting -Force.
Copiez le programme d’installation sur la cible pour que la session n’ait jamais à accéder à un chemin réseau:
Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi"
Exécutez-le silencieusement et attendez qu’il se termine :
Invoke-Command -ComputerName PC01 -ScriptBlock {

Start-Process msiexec.exe -ArgumentList "/i C:\Windows\Temp\app.msi /qn /norestart" -Wait

}

Si vous omettez -Wait, le bloc de script peut se terminer alors que le programme d’installation est encore en train de copier des fichiers, et la fermeture de la session interrompt l’installation en cours d’écriture. Si le programme d’installation affiche une fenêtre, il se bloque, car, dans une session non interactive, rien ne peut cliquer dessus.

Un script PowerShell parcourt une liste d’ordinateurs, copie le programme d’installation sur chaque machine via sa propre session, l’exécute et enregistre le code de sortie afin que vous sachiez ce qui a été installé sur chaque machine. Cela gère le problème du double saut en effectuant une pré-copie plutôt qu’en accédant à un partage depuis l’intérieur de la session.

$computers = Get-Content "C:\Installers\computers.txt" $source = "C:\Installers\app.msi" $results = @() foreach ($pc in $computers) { try { $s = New-PSSession -ComputerName $pc -ErrorAction Stop Copy-Item -Path $source -ToSession $s -Destination "C:\Windows\Temp\app.msi" $code = Invoke-Command -Session $s -ScriptBlock { $p = Start-Process msiexec.exe -ArgumentList "/i C:\Windows\Temp\app.msi /qn /norestart" -Wait -PassThru $p.ExitCode } $ok = @(0, 3010, 1641) -contains $code $results += [pscustomobject]@{ Computer = $pc; ExitCode = $code; Success = $ok } Remove-PSSession $s } catch { $results += [pscustomobject]@{ Computer = $pc; ExitCode = "N/A"; Success = $false } } } $results | Export-Csv "C:\Installers\install-report.csv" -NoTypeInformation

Considérez 3010 et 1641 comme des succès, pas des échecs. Tous deux signifient que l’installation a réussi : 3010 signifie qu’un redémarrage est nécessaire pour terminer, et 1641 signifie que le programme d’installation a déjà initié le redémarrage. De nombreux scripts basiques les signalent à tort comme des échecs. Notez que Copy-Item -ToSession s’exécute une session à la fois, donc l’étape de copie est par machine même si Invoke-Command peut se déployer en parallèle.

Évitez le raccourci CredSSP que vous verrez suggéré pour le double saut. La communauté s’en est éloignée parce qu’il met en cache vos informations d’identification d’administrateur sur l’hôte distant, où un attaquant peut les dérober. La pré-copie, comme ci-dessus, contourne entièrement le problème.

Codes de sortie msiexec courants à vérifier :

Code de sortie	Signification
`0`	Réussite
`1603`	Erreur fatale lors de l’installation
`1618`	Une autre installation est déjà en cours
`1619`	Le package d’installation n’a pas pu être ouvert
`1638`	Une autre version du produit est déjà installée
`1641`	Réussite, redémarrage initié
`3010`	Réussite, redémarrage requis

Pour installer des logiciels à distance avec cmd, vous disposez de trois méthodes : PsExec, winget et l’ancienne commande WMIC, bien que seules les deux premières soient fiables sur les versions actuelles de Windows. Chacune interagit différemment avec le jeton d’administrateur, de sorte que les options comptent davantage que l’outil.

Téléchargez PsExec de Microsoft Sysinternals et extrayez-le. Ouvrez cmd en tant qu’administrateur, car PsExec installe un service (PSEXESVC) à chaque exécution, et cela nécessite une élévation.
Copiez le MSI dans le partage administratif de la cible:
copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\
Exécutez l’installation silencieuse avec un jeton élevé. L’option -h est la plus importante. Elle exécute le processus avec le jeton élevé du compte:
psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart

Ignorez l’indicateur -i que de vieux guides recopient partout. Il impose une interaction avec le bureau, ce qui va à l’encontre d’une installation silencieuse et peut provoquer exactement les blocages que vous essayez d’éviter. Le comportement de -h et la liste complète des commutateurs proviennent directement de la référence PsExec. Si vous voyez Couldn't install PSEXESVC service: Access Denied, la cause habituelle est une invite locale non élevée, bien qu’un partage ADMIN$ bloqué ou le jeton filtré sur la cible ait le même effet. Si vous voyez Couldn't access <PC>: Access is denied sur une machine en groupe de travail, il s’agit du filtrage de jeton couvert dans la section des correctifs.

winget installe des applications localement depuis cmd avec une seule ligne, et c’est le remplacement moderne des outils hérités :

winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements

Son exécution à distance est là où ça se complique. Au cours d’une session WinRM, winget renvoie fréquemment A specified logon session does not exist ou indique que winget n’est pas reconnu, car il s’exécute en tant qu’application packagée qui attend une ouverture de session interactive. Un problème winget-cli de longue date suit cela, et un rapport connexe montre qu’un premier appel distant échoue avec 0x8a15000f jusqu’à ce qu’un administrateur ait exécuté une commande winget localement sur cette machine une fois. Sur une machine neuve, vous rencontrerez aussi 0x8a150042, une erreur d’invite de saisie, à moins de passer --accept-source-agreements. winget ne prend pas non plus officiellement en charge le compte SYSTEM, et sur Windows Server il n’est pris en charge que sur 2025 et versions ultérieures, à l’exclusion de Server Core, tandis que 2019 et 2022 ne sont pas pris en charge et sont expérimentaux.

L’ancienne astuce wmic product call install ne fonctionne plus sur Windows 11 24H2 et versions ultérieures. Conformément à l’avis de suppression de WMIC de Microsoft, l’utilitaire a été désactivé par défaut dans Windows 11 23H2 et 24H2, supprimé lors de la mise à niveau vers 25H2, et retiré de 24H2 et 25H2 par la mise à jour de préversion d’août 2026, avec 26H1 livré sans lui et aucune Feature on Demand pour le rétablir. Sur ces versions, les scripts qui appellent wmic.exe renvoient 'wmic' is not recognized. Microsoft a limité la suppression à Windows 11, donc WMIC est toujours fourni sur Windows 10 et Windows Server pour l’instant, mais la recommandation est de passer aux Get-CimInstance et Invoke-Command de PowerShell. Le guide d’installation cmd de HelpWire passe en revue les options en ligne de commande plus en détail.

Prise en charge des outils en ligne de commande selon la version de Windows :

Fonctionnalité	Statut	Notes
`WMIC`	Supprimé dans `24H2`, `25H2`, `26H1`	Aucune fonctionnalité à la demande à partir d’août 2026
`winget`	Win 10 `1809+`, Win 11, Server 2025 (hors Core)	Aucune prise en charge de SYSTEM; Server 2019/2022 expérimental
Hôte RDP	Pro, Entreprise, Éducation	Les éditions Famille exécutent uniquement le client

Les correctifs superficiels font perdre des heures parce qu’ils traitent le symptôme, pas le jeton filtré du côté distant. Exécuter votre cmd local en tant qu’administrateur ne change rien, puisque le filtrage se produit sur la cible, pas sur votre machine. Utiliser runas avec un compte administrateur ordinaire vous donne une fenêtre qui a l’appartenance au groupe Administrateurs mais n’est pas élevée, donc les installations échouent quand même.

Désactiver complètement l’UAC avec EnableLUA défini sur 0 laisse passer l’installation, mais cela laisse des droits d’administration non contrôlés et casse les applications du Store, raison pour laquelle Microsoft et la communauté le déconseillent. Aucune de ces solutions ne touche la cause réelle, ce que fait la section suivante.

Commencez par le message d’erreur, puis passez à sa correction. Chacune des solutions ci-dessous est confirmée par la documentation Microsoft, les bases de connaissances des éditeurs et les fils de discussion de la communauté.

Chaîne d’erreur	Provoqué par	Cause racine
`Accès refusé`	`PsExec`, `net use`, `C$`	Jeton administrateur filtré
`Impossible d'installer le service PSEXESVC`	`PsExec`	Invite locale non élevée, ou cible `ADMIN$`/jeton bloqué
`0x80090322`	`WinRM`	Problème de groupe de travail ou de SPN
`Accès refusé`	`Invoke-Command` vers un partage	Double saut
`0x8a15000f`	`winget` via `WinRM`	Données source manquantes
`1603`	`msiexec`	Erreur d’installation fatale

Définissez une valeur de registre sur la cible pour donner aux comptes d’administrateur locaux un jeton complet sur le réseau. Il s’agit du correctif confirmé par PDQ, Broadcom et d’innombrables fils de discussion PsExec.

Sur la cible, ouvrez l’Éditeur du Registre (regedit) et accédez à :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Créez une valeur DWORD nommée LocalAccountTokenFilterPolicy et définissez-la sur 1. Ou exécutez ceci depuis une invite de commandes élevée:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Réessayez l’installation. Pour revenir en arrière par la suite, remettez la valeur à 0, ce qui réactive le filtrage UAC à distance.

Il est inutile lorsque vous vous connectez avec un compte d’administrateur du domaine de la cible, qui reçoit déjà un jeton complet. Microsoft a conçu le filtrage pour bloquer les attaques de rebouclage, donc le désactiver élargit la surface d’attaque. Définissez-le délibérément et rétablissez-le une fois le travail terminé.

C’est presque toujours un problème d’élévation de privilèges locale, confirmé sur Microsoft Q&A.

Fermez votre invite de commandes et rouvrez cmd ou PowerShell en tant qu’administrateur. PsExec installe son service à chaque exécution et ne peut pas le faire depuis une invite de commandes standard.
Si cela échoue toujours, un psexecsvc.exe obsolète peut rester bloqué sur la cible. Vérifiez %windir% sur la machine distante et supprimez toute copie résiduelle, puis réessayez.
Confirmez que le partage ADMIN$ de la cible est accessible, et que le Partage de fichiers et d’imprimantes (SMB sur TCP 445) est autorisé via son pare-feu, car PsExec y copie le service PSEXESVC pour l’exécuter.

L’accès à distance PowerShell en groupe de travail échoue car Kerberos ne peut pas authentifier un compte local, vous ajoutez donc la cible à TrustedHosts et forcez NTLM. Le texte de l’erreur WinRM indique lui-même le chemin de TrustedHosts.

Sur votre machine, depuis un PowerShell exécuté en tant qu’administrateur, ajoutez la cible :
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate
Connectez-vous avec des informations d’identification locales explicites pour que Negotiate se rabatte sur NTLM:
$cred = Get-Credential
Invoke-Command -ComputerName PC01 -Credential $cred -ScriptBlock { hostname }
Si l’erreur persiste sur un FQDN de domaine plutôt que sur un groupe de travail, il s’agit d’un problème de SPN. Microsoft KB 4549715 couvre les solutions de contournement -IncludePortInSPN et spn_prefix.

Lorsqu’une session distante atteint un chemin UNC, elle ne peut pas s’authentifier, copier le fichier au préalable ni se réauthentifier dans le bloc de script.

De préférence : copiez d’abord le programme d’installation sur la cible, comme dans le script pour plusieurs ordinateurs, afin que la session n’accède qu’à un chemin local.
Ou mapper un lecteur avec de nouvelles informations d’identification au sein de la session. L’appel New-PSDrive authentifie une connexion au serveur de fichiers, et le lancement UNC brut ci-dessous réutilise cette connexion, donc les informations d’identification sont conservées même si la commande ne fait jamais référence au lecteur mappé :
$cred = Get-Credential

Invoke-Command -ComputerName PC01 -ScriptBlock {

New-PSDrive -Name X -PSProvider FileSystem -Root "\\fileserver\share" -Credential $using:cred | Out-Null

Start-Process "\\fileserver\share\app.exe" -ArgumentList "/silent" -Wait

}

Les deux erreurs proviennent du fait que winget s’attend à une ouverture de session interactive dont il ne dispose pas. La solution de contournement est documentée dans le tracker winget-cli.

Connectez-vous une fois à la cible en tant qu’administrateur et exécutez n’importe quelle commande winget, par exemple, winget list. Cela initialise la source et efface 0x8a15000f lors des appels distants ultérieurs.
Passez toujours les options d’acceptation pour éviter l’invite de saisie 0x8a150042 lors de la première exécution:
winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
Ne vous fiez pas à winget dans le contexte SYSTEM. Le package App Installer qui fournit winget est enregistré par utilisateur, et cet enregistrement n’est généralement pas présent pour le compte SYSTEM, de sorte que même en utilisant le chemin complet dans C:\Program Files\WindowsApps, l’installation échoue souvent. Pour un déploiement en contexte SYSTEM, utilisez msiexec via PsExec ou un outil de package à la place.

Le code de sortie 1603 est une erreur fatale générique, donc la solution consiste toujours à lire le journal détaillé plutôt que de deviner. Le dépannage de Microsoft sur 1603 préconise la même approche.

Relancez avec une journalisation détaillée vers un chemin accessible en écriture sur la cible:
msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log"
Ouvrez le journal et recherchez return value 3, qui se trouve juste après l’action ayant échoué. Les causes fréquentes sont un espace disque insuffisant, une incohérence de propriété entre une configuration par utilisateur et une configuration par machine, ou un fichier verrouillé.
Si le journal est peu concluant, reproduisez l’installation de manière interactive sur la cible via RDP, où un installateur graphique peut afficher son erreur réelle, puisqu’un lancement dans le contexte SYSTEM n’a pas de bureau pour l’afficher.

HelpWire est un logiciel d’accès à distance qui vous permet de lancer une installation sur une machine distante au sein d’une session interactive en direct depuis l’application (Operator) sur votre appareil. Vous vous connectez via un lien et demandez des droits d’administrateur sur le poste distant. Une fois les droits accordés, l’application de l’utilisateur distant (Client) redémarre afin que vous puissiez lancer les programmes d’installation directement.

Démarrez une session et connectez-vous au poste de travail distant. Consultez le guide des privilèges administrateur de HelpWire pour la procédure complète.
Cliquez sur Demander un accès administrateur dans la barre d’outils de l’application Operator.
Le client clique sur Accorder l’accès, puis sur Oui dans l’invite de changement d’appareil. L’application Client redémarre avec les droits d’administrateur et la connexion est rétablie.
Lorsque Accès administrateur accordé s’affiche dans la barre d’outils, exécutez votre programme d’installation via le Bureau à distance avec les droits d’administrateur complets.

Si vous détenez vous-même les identifiants, utilisez le menu déroulant à côté de Demander un accès administrateur et choisissez Administrateur avec identifiants, puis saisissez le nom d’utilisateur et le mot de passe du compte administrateur. L’utilisateur distant peut également obtenir des privilèges élevés de son côté avec Redémarrer en tant qu’administrateur dans l’application Client.

Vous pouvez transférer un programme d’installation directement dans la session sans problèmes de copier-coller RDP, ou le faire glisser sur la fenêtre Operator. Lorsqu’une correction nécessite un suivi, l’accès non surveillé vous permet de vous reconnecter plus tard au même ordinateur allumé sans que l’utilisateur distant soit présent.

L’élévation des privilèges administrateur s’effectue dans un véritable bureau interactif, de sorte que les programmes d’installation et leurs invites UAC se comportent normalement, sans modification du registre sur la machine cible.

L’utilisateur distant garde le contrôle. Chaque demande d’accès administrateur nécessite son approbation, et il peut révoquer l’accès à tout moment.

Cela dépend de qui n’a pas les droits requis. Une installation par machine qui écrit dans Program Files ou HKLM nécessite des droits d’administrateur sur la cible, donc si c’est vous qui l’initiez, vous fournissez des identifiants d’administrateur ou effectuez une élévation via un outil qui invite l’utilisateur. L’utilisateur final sur la cible n’a pas besoin de droits d’administrateur lorsqu’un administrateur a préconfiguré un mécanisme de déploiement : les installations de logiciels attribués à l’ordinateur via la Stratégie de groupe installent des applications par machine dans le contexte SYSTEM au démarrage, sans élévation de la part de l’utilisateur. Les applications par utilisateur comme Google Chrome s’installent également dans le profil de l’utilisateur sans droits d’administrateur.

Définissez LocalAccountTokenFilterPolicy sur 1 sur la cible, puis utilisez PsExec avec -h ou PowerShell avec la machine ajoutée à TrustedHosts. Les machines en groupe de travail n’ont pas de domaine pour délivrer des jetons complets, donc la valeur de registre et l’authentification NTLM avec des informations d’identification locales explicites sont toutes deux requises.

Cela dépend de la méthode. Une connexion RDP déconnecte la personne à la console, en verrouillant sa session tandis que ses programmes continuent de s’exécuter, alors que PsExec, l’administration à distance PowerShell et une installation silencieuse /qn s’exécutent en arrière-plan sans la déranger. Un outil d’assistance à distance qui partage le bureau actif laisse également l’utilisateur en place, ce qui importe lorsque vous installez sur la machine de quelqu’un en plein milieu de sa journée de travail.

Vérifiez le code de sortie de l’installateur, pas seulement le fait que la commande se soit terminée. Un 0 indique un succès, 3010 et 1641 indiquent un succès avec redémarrage, et 1603 indique une erreur fatale. Le code de sortie est l’indicateur fiable ; capturez-le donc avec -PassThru dans PowerShell. La plupart des applications MSI et EXE qui enregistrent un désinstalleur apparaissent également sous les clés de désinstallation à HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, sa branche WOW6432Node pour les applications 32 bits, et HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall pour les installations par utilisateur, bien que toutes les applications n’y créent pas d’entrée. Les applications MSIX et autres paquets AppX apparaissent plutôt via Get-AppxPackage, quelle que soit leur source. Évitez Get-CimInstance Win32_Product, car il ne répertorie que les produits Windows Installer et sa requête peut déclencher une lente vérification de cohérence MSI.

Comment installer à distance un logiciel sur un autre ordinateur

Pourquoi les installations de logiciels à distance échouent-elles même avec un compte administrateur

Comment installer des logiciels à distance : vos options de méthodes comparées