Cómo instalar software de forma remota en otro equipo

Q: ¿Cómo instalo software de forma remota en un equipo de grupo de trabajo?

Establece LocalAccountTokenFilterPolicy en 1 en el destino, luego usa PsExec con -h o PowerShell con la máquina agregada a TrustedHosts. Las máquinas en grupo de trabajo no tienen un dominio que emita tokens completos, por lo que se requieren tanto el valor del registro como la autenticación NTLM con una credencial local explícita.

Para instalar software de forma remota en otro equipo, conéctate mediante Escritorio remoto y ejecuta el instalador como lo harías en el teclado, o despliega una instalación silenciosa desde la línea de comandos con PowerShell Invoke-Command o PsExec y msiexec /qn. La línea de comandos es donde la mayoría se encuentra con Access is denied incluso con la contraseña de administrador correcta, porque Windows entrega a las cuentas de administrador local comunes un token filtrado en un inicio de sesión de red. Escritorio remoto evita el filtro porque es un inicio de sesión interactivo, y una cuenta de dominio del propio dominio del equipo de destino obtiene un token completo de cualquier forma.

Para una cuenta de administrador local común, la solución más rápida es un valor del registro en el equipo de destino: establece LocalAccountTokenFilterPolicy en 1 en HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, luego ejecuta el instalador en modo silencioso y captura su código de salida. Esta guía cubre cada método con comandos probados, un script para varios equipos y una solución para cada error común, desde fallos de PSEXESVC hasta winget 0x8a15000f.

Si prefieres saltarte por completo el rompecabezas del token, HelpWire es un software de asistencia remota que se conecta a una máquina en el otro extremo, y puedes solicitar permisos de administrador durante la sesión. Ejecutas el instalador dentro de un escritorio interactivo real, por lo que el aviso de elevación se comporta igual que en el teclado.

Tabla de contenidos

La causa son las restricciones remotas de UAC, también conocidas como filtrado de tokens. Cuando una cuenta local que pertenece al grupo Administradores inicia sesión a través de la red, la Autoridad de Seguridad Local le entrega un token filtrado con un nivel de integridad medio, por lo que el grupo de Administradores queda en un estado de solo denegación y se bloquean las acciones con privilegios. El inicio de sesión de red, es decir, WinRM, PsExec, WMI o una copia a C$, produce un token filtrado para los administradores locales.

Dos detalles determinan si se ve afectado. Una cuenta de dominio del propio dominio del destino, en el grupo local de Administradores, está exenta y recibe un token completo, por lo que en los entornos de dominio esto rara vez se ve. El Administrador integrado con RID 500 también es un caso especial y no se filtra a menos que FilterAdministratorToken esté habilitado. Todos los demás, es decir, las cuentas locales de administrador comunes y las cuentas de un dominio distinto, reciben el token filtrado, tanto si el destino está en un grupo de trabajo como si está unido a un dominio. Ese único hecho explica por qué Access is denied desde PsExec, net use, una copia a C$, además del token filtrado, sin privilegios de administrador, con el que se queda al usar Invoke-Command.

La segunda causa raíz es la sesión no interactiva. Un comando remoto se ejecuta donde nadie puede hacer clic, por lo que un instalador que espera una ventana o bien se queda colgado esperando un botón o bien falla por completo.

La forma más rápida de instalar software de forma remota es adaptar el método a tu entorno, porque cada uno se comporta de manera diferente con los tokens de administrador, los grupos de trabajo y Windows Home. Esta tabla resuelve esa elección antes de ejecutar un solo comando. Directiva de grupo se incluye aquí porque es solo para dominios y vale la pena descartarla o incluirla desde el principio.

Método	Comportamiento del token de administrador	Funciona en un grupo de trabajo	Host de Windows Home	Interrumpe al usuario	A través de Internet
RDP	Token completo, interactivo	Sí	`No host`	Sí, los desconecta	Con VPN
Remoting de PowerShell	Filtrado para administradores locales	Con `TrustedHosts`	Sí	No	Rara vez
`cmd` + `PsExec`	Filtrado. Usa `-h`.	Con corrección del registro	Sí	No	No
winget	Falla con `WinRM`	Solo ejecución local	Sí	No	No
Directiva de grupo	SYSTEM, asignado al equipo	`No`, solo dominio	Solo dominio	No	No
HelpWire	Elevación completa e interactiva	Sí	Sí	No	Sí

Hay un factor que condiciona todos los métodos de línea de comandos que se indican a continuación: la cuenta con la que te conectas. Una cuenta de dominio del propio dominio del destino, en su grupo Administrators, obtiene un token completo y funciona tal cual. Una cuenta de administrador local normal recibe el token filtrado, por lo que sus copias a C$ y llamadas a PsExec devuelven Access is denied, y la administración remota de PowerShell o bien rechaza la sesión o la ejecuta sin privilegios de administrador, hasta que establezcas LocalAccountTokenFilterPolicy en 1 en el destino, tratado en la sección de correcciones. RDP es la excepción, porque es un inicio de sesión interactivo en lugar de uno de red.

Escritorio remoto es la forma más limpia de instalar software de forma remota en otro equipo, porque es una sesión interactiva que se ejecuta con un token de administrador completo una vez que aceptas el aviso de UAC. Conéctate y luego instala como si estuvieras sentado frente a la máquina.

En el equipo de destino, presiona Win + R, escribe SystemPropertiesRemote, y activa Permitir las conexiones remotas a este equipo.
En su equipo, abra Conexión a Escritorio remoto (mstsc.exe), introduzca el nombre o la IP de destino y inicie sesión con una cuenta que sea administrador local allí.
Copie el instalador a través de la sesión, o asigne una unidad local en Recursos locales para poder acceder a él.
Ejecute el instalador. Cuando aparezca el aviso de UAC, apruébelo dentro de la ventana de RDP y luego finalice el asistente.

Conviene conocer las limitaciones antes de depender de ello. Las ediciones Home de Windows no pueden alojar una sesión de RDP en absoluto. Solo ejecutan el cliente. En Windows cliente, solo cuenta una consola, por lo que al conectarse se desconecta a la persona que ha iniciado sesión en la máquina. Y un usuario estándar sin credenciales de administrador en el equipo remoto tampoco puede aprobar el aviso, lo que te remite a los métodos de línea de comandos que se indican a continuación.

Para instalar software de forma remota usando PowerShell, se recurre a Invoke-Command, pero dos trampas atrapan a casi todos. La sesión remota es no interactiva, por lo que el instalador debe ejecutarse completamente de forma silenciosa, y la sesión puede cerrarse antes de que un instalador que devuelve el control rápidamente termine, lo que cancela la instalación. El conocido artículo sobre instalaciones remotas de Kevin Marquette documenta ambas, y la solución para la segunda es Start-Process -Wait.

En el equipo de destino, habilite la ejecución remota una vez. Desde una ventana de PowerShell con privilegios elevados, ejecute Enable-PSRemoting -Force.
Copie el instalador al destino para que la sesión nunca tenga que acceder a una ruta de red:
Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi"
Ejecútalo en modo silencioso y espera a que termine:
Invoke-Command -ComputerName PC01 -ScriptBlock {

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

}

Si omites -Wait, el bloque de script puede finalizar mientras el instalador aún está copiando archivos, y al cerrar la sesión se interrumpe la instalación a mitad de escritura. Si el instalador muestra alguna ventana, se cuelga, porque en una sesión no interactiva nada puede hacer clic en ella.

Un script de PowerShell recorre una lista de equipos, copia el instalador a cada equipo a través de su propia sesión, lo ejecuta y registra el código de salida para saber qué se instaló en cada equipo. Esto evita el problema del doble salto al copiar previamente el instalador, en lugar de acceder a un recurso compartido desde dentro de la sesión.

$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/D"; Success = $false } } } $results | Export-Csv "C:\Installers\install-report.csv" -NoTypeInformation

Considere 3010 y 1641 como éxito, no como fallo. Ambos significan que la instalación se realizó correctamente: 3010 significa que se requiere un reinicio para finalizar, y 1641 significa que el instalador ya inició el reinicio. Muchos scripts rudimentarios los marcan erróneamente como fallos. Tenga en cuenta que Copy-Item -ToSession ejecuta una sesión a la vez, por lo que el paso de copia es por máquina aunque Invoke-Command pueda distribuirse.

Evite el atajo con CredSSP que verá sugerido para el doble salto. La comunidad se alejó de él porque almacena en caché su credencial de administrador en el host remoto, donde un atacante puede robarla. La copia previa, como arriba, evita todo el problema.

Códigos de salida comunes de msiexec para verificar:

Código de salida	Significado
`0`	Correcto
`1603`	Error fatal durante la instalación
`1618`	Ya hay otra instalación en curso
`1619`	No se pudo abrir el paquete del instalador
`1638`	Ya hay instalada otra versión del producto
`1641`	Correcto, se inició el reinicio
`3010`	Correcto, se requiere reinicio

Para instalar software de forma remota usando cmd, tienes tres vías: PsExec, winget y el antiguo comando WMIC, aunque solo los dos primeros son fiables en las versiones actuales de Windows. Cada uno interactúa de manera diferente con el token de administrador, por lo que los conmutadores importan más que la herramienta.

Descarga PsExec de Microsoft Sysinternals y extráelo. Abre cmd como administrador, porque PsExec instala un servicio (PSEXESVC) en cada ejecución, y eso requiere elevación.
Copie el MSI en el recurso compartido administrativo del destino:
copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\
Ejecute la instalación silenciosa con un token elevado. La opción -h es la importante. Esta opción ejecuta el proceso con el token elevado de la cuenta:
psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart

Omite el indicador -i que las guías antiguas suelen copiar. Obliga a la interacción con el escritorio, lo que va en contra de una instalación silenciosa y puede causar exactamente los bloqueos que intentas evitar. El comportamiento de -h y la lista completa de opciones provienen directamente de la referencia de PsExec. Si ves Couldn't install PSEXESVC service: Access Denied, la causa habitual es un símbolo del sistema local que no está elevado, aunque un recurso compartido ADMIN$ bloqueado o el token filtrado en el destino da el mismo resultado. Si ves Couldn't access <PC>: Access is denied en un equipo de grupo de trabajo, se trata del filtrado de tokens descrito en la sección de soluciones.

winget instala aplicaciones localmente desde cmd con una sola línea, y es el reemplazo moderno de las herramientas heredadas:

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

Ejecutarlo de forma remota es donde empieza a dar problemas. En una sesión de WinRM, winget con frecuencia arroja A specified logon session does not exist o informa que winget no se reconoce, porque se ejecuta como una aplicación empaquetada que espera un inicio de sesión interactivo. Un problema de winget-cli de larga data hace seguimiento a esto, y un informe relacionado muestra que una primera llamada remota falla con 0x8a15000f hasta que un administrador haya ejecutado cualquier comando de winget localmente en esa máquina una vez. En una máquina nueva, también te encontrarás con 0x8a150042, un error de solicitud de entrada, a menos que pases --accept-source-agreements. winget tampoco admite oficialmente la cuenta SYSTEM, y en Windows Server solo se admite a partir de 2025, excluyendo Server Core, con 2019 y 2022 no admitidos y experimentales.

El antiguo truco de wmic product call install ya no funciona en Windows 11 24H2 y posteriores. Según el aviso de eliminación de WMIC de Microsoft, la utilidad se deshabilitó de forma predeterminada en Windows 11 23H2 y 24H2, se eliminó al actualizar a 25H2 y se retiró de 24H2 y 25H2 con la actualización preliminar de agosto de 2026, con 26H1 distribuyéndose sin ella y sin ninguna característica a petición para restaurarla. En esas versiones, los scripts que llaman a wmic.exe devuelven 'wmic' is not recognized. Microsoft limitó la eliminación a Windows 11, por lo que WMIC sigue incluyéndose en Windows 10 y Windows Server por ahora, pero la recomendación general es migrar a Get-CimInstance e Invoke-Command de PowerShell. La guía de instalación de cmd de HelpWire explica con más detalle las opciones de línea de comandos.

Compatibilidad de las herramientas de línea de comandos por versión de Windows:

Característica	Estado	Notas
`WMIC`	Eliminado en `24H2`, `25H2`, `26H1`	Sin Características a petición a partir de agosto de 2026
`winget`	Win 10 `1809+`, Win 11, Server 2025 (no Core)	Sin compatibilidad con SYSTEM; Server 2019/2022 experimental
Host de RDP	Pro, Enterprise, Education	Las ediciones Home solo ejecutan el cliente

Las soluciones superficiales hacen perder horas porque tratan el síntoma, no el token filtrado en el lado remoto. Ejecutar tu cmd local como administrador no cambia nada, ya que el filtrado ocurre en el destino, no en tu máquina. Usar runas con una cuenta de administrador normal te da una ventana que tiene pertenencia al grupo de administradores pero no está elevada, por lo que las instalaciones siguen fallando.

Deshabilitar completamente UAC con EnableLUA establecido en 0 sí permite que la instalación pase, pero deja los derechos de administrador sin control y rompe las aplicaciones de la Tienda, por lo que Microsoft y la comunidad advierten en contra. Ninguna de estas aborda la causa real, cosa que sí hace la siguiente sección.

Empieza con el mensaje de error y luego pasa a su solución. Cada uno de los siguientes está confirmado en la documentación de Microsoft, las bases de conocimiento de los proveedores y los hilos de la comunidad.

Cadena de error	Generado por	Causa raíz
`Access is denied`	`PsExec`, `net use`, `C$`	Token de administrador filtrado
`Couldn't install PSEXESVC service`	`PsExec`	Símbolo del sistema local sin privilegios elevados, o destino `ADMIN$`/token bloqueado
`0x80090322`	`WinRM`	Problema de grupo de trabajo o de SPN
`Access denied`	`Invoke-Command` a un recurso compartido	Salto doble
`0x8a15000f`	`winget` sobre `WinRM`	Faltan los datos de origen
`1603`	`msiexec`	Error fatal de instalación

Configura un valor del registro en el equipo de destino para otorgar a las cuentas de administrador locales un token completo a través de la red. Esta es la solución confirmada por PDQ, Broadcom e innumerables hilos de PsExec.

En el equipo de destino, abre el Editor del Registro (regedit) y ve a:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Cree un valor DWORD llamado LocalAccountTokenFilterPolicy y asígnele el valor 1. O ejecute esto desde un símbolo del sistema con privilegios de administrador:
reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f
Vuelva a intentar la instalación. Para revertirlo después, establezca el valor de nuevo en 0, lo que vuelve a habilitar el filtrado remoto de UAC.

Es innecesario cuando se conecta con una cuenta de administrador de dominio del propio dominio del objetivo, que ya recibe un token completo. Microsoft diseñó el filtrado para bloquear ataques de loopback, por lo que desactivarlo amplía la superficie de ataque. Configúrelo de forma deliberada y reviértalo cuando el trabajo haya terminado.

Este es casi siempre un problema de elevación local, confirmado en Microsoft Q&A.

Cierra tu consola y vuelve a abrir cmd o PowerShell como administrador. PsExec instala su servicio en cada ejecución y no puede hacerlo desde una consola estándar.
Si sigue fallando, una copia obsoleta de psexecsvc.exe puede quedarse atascada en el destino. Comprueba %windir% en la máquina remota y elimina cualquier copia restante, luego vuelve a intentarlo.
Confirme que el recurso compartido ADMIN$ del equipo de destino es accesible y que Uso compartido de archivos e impresoras (SMB sobre TCP 445) está permitido a través de su firewall, ya que PsExec copia allí el servicio PSEXESVC para ejecutarlo.

La conexión remota de PowerShell en un grupo de trabajo falla porque Kerberos no puede autenticar una cuenta local, por lo que agregas el destino a TrustedHosts y fuerzas NTLM. El propio texto del error de WinRM menciona la ruta de TrustedHosts.

En su equipo, desde un PowerShell con privilegios elevados, agregue el destino:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate
Conéctese con una credencial local explícita para que Negotiate recurra a NTLM:
$cred = Get-Credential
Invoke-Command -ComputerName PC01 -Credential $cred -ScriptBlock { hostname }
Si el error persiste en un FQDN de dominio en lugar de un grupo de trabajo, es un problema de SPN. Microsoft KB 4549715 cubre las soluciones alternativas -IncludePortInSPN y spn_prefix.

Cuando la sesión remota accede a una ruta UNC, no puede autenticarse, copiar previamente el archivo o volver a autenticarse dentro del bloque de script.

Preferible: copie primero el instalador al destino, como en el script para varios equipos, para que la sesión solo acceda a una ruta local.
O asigna una unidad con credenciales nuevas dentro de la sesión. La llamada a New-PSDrive autentica una conexión con el servidor de archivos, y la ejecución UNC directa que aparece abajo reutiliza esa conexión, por lo que las credenciales se mantienen aunque el comando nunca haga referencia a la unidad asignada:
$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

}

Ambos errores se deben a que winget espera un inicio de sesión interactivo que no tiene. La solución alternativa está documentada en el rastreador de winget-cli.

Inicie sesión una vez en el destino como administrador y ejecute cualquier comando de winget, por ejemplo, winget list. Esto inicializa el origen y borra 0x8a15000f en llamadas remotas posteriores.
Pase siempre las banderas de acuerdo para evitar el aviso de entrada 0x8a150042 en la primera ejecución:
winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
No dependas de winget en el contexto de SYSTEM. El paquete App Installer que proporciona winget se registra por usuario, y ese registro normalmente no está presente para la cuenta SYSTEM, por lo que incluso invocando la ruta completa en C:\Program Files\WindowsApps a menudo la instalación sigue fallando. Para la implementación en el contexto de SYSTEM, utiliza msiexec a través de PsExec o, en su lugar, una herramienta de empaquetado.

El código de salida 1603 es un error fatal genérico, por lo que la solución siempre es leer el registro detallado en lugar de adivinar. La resolución de problemas de Microsoft sobre 1603 apunta al mismo enfoque.

Vuelva a ejecutar con registro detallado a una ruta con permisos de escritura en el destino:
msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log"
Abra el registro y busque return value 3, que aparece justo después de la acción fallida. Las causas comunes son poco espacio en disco, un desajuste de propiedades por usuario frente a por equipo, o un archivo bloqueado.
Si el registro no es concluyente, repite la instalación de forma interactiva en el equipo de destino a través de RDP, donde un instalador con interfaz gráfica puede mostrar su error real, ya que una ejecución en el contexto de SYSTEM no tiene escritorio para mostrarlo.

HelpWire es un software de acceso remoto que te permite ejecutar una instalación en una máquina en el extremo remoto dentro de una sesión interactiva en vivo desde la app (Operador) en tu dispositivo. Te conectas a través de un enlace y solicitas permisos de administrador en el lado remoto. Una vez que se conceden los permisos, la app del usuario remoto (Cliente) se reinicia para que puedas ejecutar instaladores directamente.

Inicia una sesión y conéctate a la estación de trabajo remota. Consulta la guía de privilegios de administrador de HelpWire para ver el proceso completo.
Haga clic en Solicitar acceso de administrador en la barra de herramientas de la aplicación Operator.
El cliente hace clic en Conceder acceso, luego en Sí en el aviso de cambios en el dispositivo. La aplicación Cliente se reinicia con permisos de administrador y la conexión se restablece.
Con Acceso de administrador concedido visible en la barra de herramientas, ejecute su instalador a través del escritorio remoto como administrador con privilegios completos.

Si posee las credenciales, utilice el menú desplegable junto a Solicitar acceso de administrador y seleccione Administrador con credenciales, luego introduzca el nombre de usuario y la contraseña de la cuenta de administrador. El usuario remoto también puede elevar desde su lado con Reiniciar como administrador en la aplicación Cliente.

Puedes introducir un instalador directamente en la sesión sin problemas de copiar y pegar con RDP, o arrastrarlo a la ventana de Operator. Cuando una corrección necesita trabajo de seguimiento, el acceso desatendido te permite volver a conectarte más tarde a la misma máquina encendida sin que el usuario remoto esté presente.

La elevación de privilegios de administrador se realiza dentro de un escritorio interactivo real, por lo que los instaladores y sus avisos de UAC se comportan con normalidad, sin modificar el registro en el equipo de destino.

El usuario remoto mantiene el control. Cada solicitud de administrador requiere su aprobación y puede revocar el acceso en cualquier momento.

Depende de a quién le falten permisos. Una instalación por equipo que escribe en Program Files o HKLM necesita permisos de administrador en el destino, por lo que, si usted es quien la inicia, debe proporcionar credenciales de administrador o elevar privilegios a través de una herramienta que solicite al usuario. El usuario final en el equipo de destino no necesita permisos de administrador cuando un administrador ha preconfigurado un mecanismo de implementación: las instalaciones de software asignado al equipo mediante Directivas de Grupo instalan aplicaciones por equipo en el contexto de SYSTEM al inicio, sin elevación por parte del usuario. Las aplicaciones por usuario como Google Chrome también se instalan en el perfil del usuario sin permisos de administrador.

Establece LocalAccountTokenFilterPolicy en 1 en el destino, luego usa PsExec con -h o PowerShell con la máquina agregada a TrustedHosts. Las máquinas en grupo de trabajo no tienen un dominio que emita tokens completos, por lo que se requieren tanto el valor del registro como la autenticación NTLM con una credencial local explícita.

Depende del método. Una conexión RDP desconecta a la persona en la consola, bloqueando su sesión mientras sus programas siguen ejecutándose, mientras que PsExec, la administración remota de PowerShell y una instalación silenciosa con /qn se ejecutan en segundo plano sin interrumpir a la persona. Una herramienta de soporte remoto que comparte el escritorio activo también deja al usuario en su lugar, lo cual es importante cuando se instala en la máquina de alguien en plena jornada laboral.

Comprueba el código de salida del instalador, no solo si el comando terminó. Un 0 significa éxito, 3010 y 1641 significan éxito con reinicio, y 1603 significa un error fatal. El código de salida es la señal fiable, así que captúralo con -PassThru en PowerShell. La mayoría de las aplicaciones MSI y EXE que registran un desinstalador también aparecen bajo las claves de desinstalación en HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, su rama WOW6432Node para aplicaciones de 32 bits, y HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall para instalaciones por usuario, aunque no todas las aplicaciones escriben una entrada allí. Las aplicaciones MSIX y otras empaquetadas como AppX aparecen mediante Get-AppxPackage en su lugar, independientemente de su origen. Omite Get-CimInstance Win32_Product, ya que solo enumera productos de Windows Installer y su consulta puede activar una lenta comprobación de consistencia de MSI.

Cómo instalar software de forma remota en otra computadora

Por qué fallan las instalaciones de software remotas incluso con una cuenta de administrador

Cómo instalar software de forma remota: comparación de tus métodos disponibles