Para instalar software remotamente em outro computador, conecte via Área de Trabalho Remota e execute o instalador como se estivesse no teclado, ou faça uma instalação silenciosa pela linha de comando com PowerShell Invoke-Command ou PsExec e msiexec /qn. A linha de comando é onde a maioria das pessoas se depara com Access is denied mesmo com a senha de administrador correta, porque o Windows entrega às contas de administrador local comuns um token filtrado em um logon de rede. Área de Trabalho Remota evita o filtro porque é um logon interativo, e uma conta de domínio do próprio domínio do destino recebe um token completo de qualquer maneira.
Para uma conta de administrador local comum, a correção mais rápida é um valor do Registro no computador de destino: defina LocalAccountTokenFilterPolicy como 1 em HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, em seguida execute o instalador silenciosamente e capture seu código de saída. Este guia cobre cada método com comandos testados, um script para vários computadores e uma correção para cada erro comum, desde falhas do PSEXESVC até winget 0x8a15000f.
Se você preferir ignorar completamente o enigma do token, HelpWire é um software de suporte remoto que se conecta a uma máquina na outra ponta, e você pode solicitar permissões de administrador durante a sessão. Você executa o instalador dentro de uma área de trabalho interativa real, então o prompt de elevação se comporta como faria no teclado.
Por que instalações de software remotas falham mesmo com uma conta de administrador
A causa são as restrições remotas do UAC, também chamadas de filtragem de token. Quando uma conta local que pertence ao grupo Administradores faz logon pela rede, a Autoridade de Segurança Local entrega a ela um token filtrado com nível de integridade médio, de modo que o grupo Administradores fica em estado de somente negação e ações privilegiadas são bloqueadas. O logon de rede, ou seja, WinRM, PsExec, WMI, ou uma C$ cópia, produz um token filtrado para administradores locais.
Dois detalhes determinam se você é afetado. Uma conta de domínio do próprio domínio do destino, no grupo local Administradores, é isenta e recebe um token completo, razão pela qual ambientes de domínio raramente veem isso. O Administrador interno RID 500 também é um caso especial e não é filtrado, a menos que FilterAdministratorToken esteja habilitado. Todos os demais, ou seja, contas locais de administrador comuns e contas de um domínio diferente, recebem o token filtrado, esteja o destino em um grupo de trabalho ou ingressado em um domínio. Esse único fato explica por que Access is denied em PsExec, net use, uma C$ cópia, além do token filtrado, não administrativo, com o qual você fica ao usar Invoke-Command.
A segunda causa raiz é a sessão não interativa. Um comando remoto é executado onde ninguém pode clicar, então um instalador que espera uma janela ou fica aguardando um botão ou falha imediatamente.
Como instalar software remotamente: suas opções de método comparadas
A maneira mais rápida de instalar software remotamente é ajustar o método ao seu ambiente, pois cada um se comporta de forma diferente com tokens de administrador, grupos de trabalho e o Windows Home. Esta tabela resolve essa escolha antes de você executar um único comando. Política de Grupo está incluída aqui porque é exclusiva de domínio e vale a pena decidir a favor ou contra logo no início.
| Método | Comportamento do token de administrador | Funciona em um grupo de trabalho | Host do Windows Home | Interrompe o usuário | Pela internet |
| RDP | Token completo, interativo | Sim | Sem host |
Sim, desconecta o usuário | Com VPN |
| Execução remota do PowerShell | Filtrado para administradores locais | Com TrustedHosts |
Sim | Não | Raramente |
cmd + PsExec |
Filtrado. Use -h. |
Com correção no Registro | Sim | Não | Não |
| winget | Falha com WinRM |
Somente execução local | Sim | Não | Não |
| Política de Grupo | SYSTEM, atribuído ao computador | Não, somente domínio |
Somente domínio | Não | Não |
| HelpWire | Completo, elevação interativa | Sim | Sim | Não | Sim |
Uma coisa limita todos os métodos de linha de comando abaixo: a conta com a qual você se conecta. Uma conta de domínio do próprio domínio do destino, no grupo Administrators, recebe um token completo e funciona tal como está. Uma conta de administrador local comum recebe o token filtrado, então suas cópias via C$ e chamadas do PsExec retornam Access is denied, e o PowerShell remoting ou recusa a sessão ou a executa sem privilégios de administrador, até que você defina LocalAccountTokenFilterPolicy como 1 no destino, conforme abordado na seção de correções. RDP é a exceção, porque é um logon interativo em vez de um de rede.
Como instalar software remotamente em outro computador com a Área de Trabalho Remota
Área de Trabalho Remota é a maneira mais limpa de instalar software remotamente em outro computador, porque é uma sessão interativa que é executada com um token de administrador completo depois que você confirma o prompt do UAC. Conecte-se e instale como se estivesse sentado na máquina.
-
No destino, pressione Win + R, digite
SystemPropertiesRemotee ative Permitir conexões remotas a este computador. -
No seu computador, abra a Conexão de Área de Trabalho Remota (
mstsc.exe), insira o nome ou o IP do destino e faça logon com uma conta de administrador local no computador de destino. -
Copie o instalador através da sessão, ou mapeie uma unidade local em Local Resources para poder acessá-lo.
-
Execute o instalador. Quando o prompt do UAC aparecer, autorize-o dentro da janela do RDP e, em seguida, conclua o assistente.
Vale a pena conhecer as limitações antes de depender disso. As edições do Windows Home não podem hospedar uma sessão RDP. Elas apenas executam o cliente. No Windows cliente, há apenas um console, então, ao se conectar, a pessoa conectada na máquina é desconectada. E um usuário padrão, sem credenciais de administrador na máquina remota, ainda assim não pode aprovar o prompt, o que o leva aos métodos de linha de comando abaixo.
Como instalar software remotamente usando o PowerShell
Para instalar software remotamente usando PowerShell, você depende de Invoke-Command, mas duas armadilhas pegam quase todo mundo. A sessão remota é não interativa, então o instalador deve ser totalmente silencioso, e a sessão pode se encerrar antes que um instalador que retorna rapidamente termine, o que cancela a instalação. O artigo amplamente conhecido sobre instalações remotas de Kevin Marquette documenta as duas, e a correção para a segunda é Start-Process -Wait.
Instalar num único computador com Invoke-Command
-
No destino, habilite o remoting uma vez. Em uma janela do PowerShell elevada, execute
Enable-PSRemoting -Force. -
Copie o instalador para o destino para que a sessão nunca precise acessar um caminho de rede:
Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi" -
Execute-o silenciosamente e aguarde até que termine:
Invoke-Command -ComputerName PC01 -ScriptBlock {Start-Process msiexec.exe -ArgumentList "/i
C:\Windows\Temp\app.msi /qn /norestart" -Wait}Se você omitir
-Wait, o bloco de script pode terminar enquanto o instalador ainda está copiando arquivos, e fechar a sessão interrompe a instalação no meio da escrita. Se o instalador mostrar qualquer janela, ele fica travado, porque nada em uma sessão não interativa pode clicar nela.
Script do PowerShell para instalar software remotamente em vários computadores
Um script do PowerShell percorre uma lista de computadores, copia o instalador para cada máquina por meio de sua própria sessão, executa-o e registra o código de saída para que você saiba o que foi implantado em cada máquina. Isso resolve o problema de double-hop ao pré-copiar, em vez de acessar um compartilhamento de dentro da sessão.
$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
Trate 3010 e 1641 como sucesso, não falha. Ambos significam que a instalação funcionou: 3010 significa que é necessário reiniciar para concluir, e 1641 significa que o instalador já iniciou a reinicialização. Muitos scripts simples marcam erroneamente esses códigos como falhas. Observe que Copy-Item -ToSession executa uma sessão por vez, então a etapa de cópia é por máquina, mesmo que Invoke-Command possa se distribuir.
Evite o atalho CredSSP que você encontrará sugerido para o salto duplo. A comunidade deixou de usá-lo porque ele armazena em cache sua credencial de administrador no host remoto, onde um invasor pode capturá-la. A cópia prévia, como acima, contorna todo o problema.
Códigos de saída comuns do msiexec para verificar:
| Código de saída | Significado |
0 |
Sucesso |
1603 |
Erro fatal durante a instalação |
1618 |
Outra instalação já está em andamento |
1619 |
O pacote do instalador não pôde ser aberto |
1638 |
Outra versão do produto já está instalada |
1641 |
Sucesso, reinicialização iniciada |
3010 |
Sucesso, reinicialização necessária |
Como instalar software remotamente usando o cmd
Para instalar software remotamente usando cmd, há três caminhos: PsExec, winget e o comando mais antigo WMIC, embora apenas os dois primeiros sejam confiáveis no Windows atual. Cada um interage de forma diferente com o token de administrador, então os parâmetros importam mais do que a ferramenta.
PsExec com msiexec
-
Faça o download do PsExec da Microsoft Sysinternals e extraia-o. Abra o
cmdcomo administrador, porque oPsExecinstala um serviço (PSEXESVC) a cada execução, e isso requer elevação. -
Copie o MSI para o compartilhamento administrativo do destino:
copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\ -
Execute a instalação silenciosa com um token elevado. A opção
-hé a importante. Ela executa o processo com o token elevado da conta:psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart
Ignore a opção -i que guias mais antigos costumam copiar. Ela força a interação com a área de trabalho, o que conflita com uma instalação silenciosa e pode causar exatamente os travamentos que você está tentando evitar. O comportamento de -h e a lista completa de opções vêm diretamente da referência do PsExec. Se você vir Couldn't install PSEXESVC service: Access Denied, a causa mais comum é um prompt local sem elevação, embora um compartilhamento ADMIN$ bloqueado ou o token filtrado no destino também provoquem o mesmo. Se você vir Couldn't access <PC>: Access is denied em um computador de grupo de trabalho, isso é o filtro de token abordado na seção de correções.
winget a partir da linha de comando
winget instala aplicativos localmente pelo cmd com uma única linha, e é o substituto moderno para ferramentas legadas:
winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
Executá-lo remotamente é onde surgem os problemas. Em uma sessão WinRM, o winget frequentemente lança A specified logon session does not exist ou informa que winget não é reconhecido, porque é executado como um aplicativo empacotado que espera um logon interativo. Um problema antigo do winget-cli acompanha isso, e um relato relacionado mostra uma primeira chamada remota falhando com 0x8a15000f até que um administrador tenha executado qualquer comando do winget localmente nessa máquina uma vez. Em uma máquina nova, você também encontrará 0x8a150042, um erro de prompt de entrada, a menos que você passe --accept-source-agreements. winget também não oferece suporte oficial à conta SYSTEM, e no Windows Server ele é suportado apenas em 2025 e versões posteriores, excluindo o Server Core, com 2019 e 2022 sem suporte e experimentais.
Por que o método WMIC não funciona mais
O antigo truque wmic product call install não funciona mais no Windows 11 24H2 e posteriores. De acordo com o aviso de remoção do WMIC da Microsoft, o utilitário foi desativado por padrão no Windows 11 23H2 e 24H2, removido na atualização para 25H2 e retirado do 24H2 e 25H2 pela atualização de visualização de agosto de 2026, com o 26H1 sendo distribuído sem ele e sem Feature on Demand para restaurá-lo. Nessas versões, scripts que chamam wmic.exe retornam 'wmic' is not recognized. A Microsoft limitou a remoção ao Windows 11, então WMIC ainda é fornecido no Windows 10 e no Windows Server por enquanto, mas a orientação geral é migrar para os comandos do PowerShell Get-CimInstance e Invoke-Command. O guia de instalação via cmd da HelpWire detalha as opções de linha de comando com mais profundidade.
Suporte a ferramentas de linha de comando por versão do Windows:
| Recurso | Status | Observações |
WMIC |
Removido em 24H2, 25H2, 26H1 |
Sem Recurso sob Demanda a partir de agosto de 2026 |
winget |
Win 10 1809+, Win 11, Server 2025 (não Core) |
Sem suporte para SYSTEM; Server 2019/2022 experimental |
| Host RDP | Pro, Enterprise, Education | As edições Home executam apenas o cliente |
O que a maioria das pessoas tenta primeiro e por que falha
As correções superficiais desperdiçam horas porque tratam o sintoma, não o token filtrado do lado remoto. Executar o seu cmd local como administrador não muda nada, já que a filtragem ocorre no destino, não na sua máquina. Usar runas com uma conta de administrador comum fornece uma janela que tem associação ao grupo de administradores, mas não está elevada, então as instalações ainda falham.
Desativar completamente o UAC com EnableLUA definido como 0 permite que a instalação passe, mas deixa os direitos de administrador sem controle e quebra aplicativos da Store, razão pela qual a Microsoft e a comunidade alertam contra isso. Nenhuma delas aborda a causa real, o que a próxima seção faz.
As correções comprovadas para “Acesso negado” e erros de elevação
Comece pela mensagem de erro e, em seguida, vá para a correção correspondente. Cada uma abaixo está confirmada na documentação da Microsoft, nas bases de conhecimento de fornecedores e em tópicos da comunidade.
| Mensagem de erro | Gerado por | Causa raiz |
Access is denied |
PsExec, net use, C$ |
Token de administrador filtrado |
Couldn't install PSEXESVC service |
PsExec |
Prompt local não elevado, ou destino ADMIN$/token bloqueado |
0x80090322 |
WinRM |
Problema de grupo de trabalho ou SPN |
Access denied |
Invoke-Command para um compartilhamento |
Salto duplo |
0x8a15000f |
winget via WinRM |
Dados de origem ausentes |
1603 |
msiexec |
Erro fatal de instalação |
Corrigir “Acesso negado” com LocalAccountTokenFilterPolicy
Defina um valor do Registro no destino para conceder às contas de administrador local um token completo pela rede. Esta é a correção confirmada por PDQ, Broadcom e por incontáveis tópicos sobre PsExec.
-
No destino, abra o Editor do Registro (
regedit) e vá para:HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -
Crie um DWORD chamado
LocalAccountTokenFilterPolicye defina-o como 1. Ou execute isto a partir de um prompt elevado:reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f -
Tente instalar novamente. Para reverter depois, defina o valor de volta para
0, o que reativa a filtragem UAC remota.
Não é necessário quando você se conecta com uma conta de administrador de domínio do próprio domínio do alvo, que já recebe um token completo. A Microsoft projetou a filtragem para bloquear ataques de loopback, portanto desativá-la amplia a superfície de ataque. Configure-o deliberadamente e reverta quando o trabalho estiver concluído.
Corrigir “Não foi possível instalar o serviço PSEXESVC”
Este é quase sempre um problema de elevação local de privilégios, confirmado no Microsoft Q&A.
-
Feche o seu prompt e reabra o
cmdou o PowerShell como administrador.PsExecinstala o seu serviço a cada execução e não pode fazê-lo a partir de um prompt padrão. -
Se ainda falhar, um
psexecsvc.exeobsoleto pode ficar preso no destino. Verifique%windir%na máquina remota e remova qualquer cópia remanescente, depois tente novamente. -
Confirme que o compartilhamento
ADMIN$do destino está acessível e que o Compartilhamento de Arquivos e Impressoras (SMB sobre TCP445) é permitido pelo firewall do destino, pois oPsExeccopia o serviçoPSEXESVCpara lá para executá-lo.
Corrigir WinRM 0x80090322 em máquinas de grupo de trabalho
A execução remota do PowerShell em grupo de trabalho falha porque o Kerberos não consegue autenticar uma conta local, então você adiciona o destino a TrustedHosts e força o NTLM. O próprio texto de erro do WinRM menciona o caminho de TrustedHosts.
-
No seu computador, a partir de um PowerShell com privilégios elevados, adicione o destino:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate -
Conecte-se com uma credencial local explícita para que o Negotiate volte para NTLM:
$cred = Get-CredentialInvoke-Command -ComputerName PC01 -Credential $cred -ScriptBlock { hostname }
-
Se o erro persistir em um FQDN de domínio em vez de um grupo de trabalho, trata-se de um problema de SPN. Microsoft KB 4549715 aborda as soluções alternativas
-IncludePortInSPNespn_prefix.
Corrigir o “Acesso negado” de salto duplo
Quando a sessão remota acessa um caminho UNC, ela não consegue se autenticar, copiar previamente o arquivo ou se reautenticar dentro do bloco de script.
-
Preferível: copie o instalador para o destino primeiro, como no script para vários computadores, para que a sessão acesse apenas um caminho local.
-
Ou mapeie uma unidade com uma credencial nova dentro da sessão. A chamada
New-PSDriveautentica uma conexão com o servidor de arquivos, e a execução direta via UNC abaixo reutiliza essa conexão, de modo que a credencial permanece válida mesmo que o comando nunca faça referência à unidade mapeada:
$cred = Get-CredentialInvoke-Command -ComputerName PC01 -ScriptBlock {New-PSDrive -Name X -PSProvider FileSystem -Root "\\fileserver\share" -Credential $using:cred | Out-NullStart-Process "\\fileserver\share\app.exe" -ArgumentList "/silent" -Wait}
Corrigir winget 0x8a15000f e 0x8a150042
Ambos os erros ocorrem porque o winget espera um logon interativo que não está disponível. A solução alternativa está documentada no rastreador do winget-cli.
-
Entre no destino uma vez como administrador e execute qualquer comando do winget, por exemplo,
winget list. Isso inicializa a origem e limpa0x8a15000fem chamadas remotas posteriores. -
Sempre passe os sinalizadores de aceitação para evitar o prompt de entrada
0x8a150042na primeira execução:winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements -
Não dependa do winget no contexto do SYSTEM. O pacote App Installer que fornece o winget é registrado por usuário, e esse registro normalmente não está presente para a conta SYSTEM, então mesmo chamando o caminho completo em
C:\Program Files\WindowsAppsmuitas vezes ainda falha ao instalar. Para implantação no contexto do SYSTEM, usemsiexecpor meio doPsExecou uma ferramenta de empacotamento em vez disso.
Corrigir erro 1603 do msiexec
O código de saída 1603 é um erro fatal genérico, portanto a correção é sempre ler o log detalhado em vez de adivinhar. A solução de problemas da Microsoft sobre o 1603 aponta para a mesma abordagem.
-
Execute novamente com log detalhado para um caminho com permissão de escrita no destino:
msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log" -
Abra o log e procure por
return value 3, que aparece logo após a ação com falha. As causas comuns incluem pouco espaço em disco, incompatibilidade de propriedades por usuário versus por máquina ou um arquivo bloqueado. -
Se o log for inconclusivo, reproduza a instalação de forma interativa no destino via RDP, onde um instalador com interface gráfica pode mostrar o erro real, já que uma execução no contexto do SYSTEM não tem área de trabalho para exibi-lo.
Como instalar software remotamente com permissões de administrador usando o HelpWire
HelpWire é um software de acesso remoto que permite executar uma instalação em uma máquina no lado remoto dentro de uma sessão interativa ao vivo a partir do aplicativo (Operator) no seu dispositivo. Você se conecta por meio de um link e solicita permissões de administrador no lado remoto. Depois que as permissões são concedidas, o aplicativo do usuário remoto (Client) é reiniciado para que você possa executar instaladores diretamente.
Solicitar acesso de administrador durante uma sessão
-
Inicie uma sessão e conecte-se à estação de trabalho remota. Consulte o guia de privilégios de administrador do HelpWire para ver o fluxo completo.
-
Clique em Solicitar acesso de administrador na barra de ferramentas do app Operator.
-
O cliente clica em Conceder acesso, depois em Sim no prompt de alteração de dispositivo. O aplicativo Client reinicia com permissões de administrador e a conexão é restabelecida.
-
Com Acesso de administrador concedido exibido na barra de ferramentas, execute o seu instalador pela área de trabalho remota como administrador com privilégios totais.
Se você tiver as credenciais, use o menu suspenso ao lado de Solicitar acesso de administrador e escolha Administrador com credenciais; em seguida, insira o nome de usuário e a senha da conta de administrador. O usuário remoto também pode obter privilégios elevados do lado dele com Reiniciar como administrador no aplicativo Client.
Transfira o instalador, em seguida reconecte mais tarde
Você pode colocar um instalador diretamente na sessão sem problemas de copiar e colar no RDP, ou arrastá-lo para a janela do Operator. Quando uma correção precisar de acompanhamento, o acesso não assistido permite que você se reconecte mais tarde à mesma máquina ligada, sem a presença do usuário remoto.
A elevação administrativa ocorre dentro de uma área de trabalho interativa real, então os instaladores e seus prompts do UAC se comportam normalmente, sem alterações no Registro do destino.
O usuário remoto mantém o controle. Toda solicitação de administrador requer a aprovação do usuário, e ele pode revogar o acesso a qualquer momento.
Perguntas frequentes
Depende de quem está sem permissões. Uma instalação por máquina que grava em Program Files ou HKLM precisa de permissões de administrador no destino, portanto, se você é quem a inicia, forneça credenciais de administrador ou eleve por meio de uma ferramenta que solicita ao usuário. O usuário final no destino não precisa de permissões de administrador quando um administrador pré-configurou um mecanismo de implantação: Instalações de software atribuídas ao computador pela Política de Grupo instalam aplicativos por máquina no contexto do SYSTEM na inicialização, sem elevação por parte do usuário. Aplicativos por usuário, como o Google Chrome, também se instalam no perfil do usuário sem permissões de administrador.
Defina LocalAccountTokenFilterPolicy como 1 no destino e, em seguida, use PsExec com -h ou PowerShell com a máquina adicionada a TrustedHosts. Máquinas em grupo de trabalho não têm um domínio para conceder tokens completos, portanto, tanto o valor do registro quanto a autenticação NTLM com uma credencial local explícita são necessários.
Depende do método. Uma conexão RDP desconecta a pessoa no console, bloqueando sua sessão enquanto seus programas continuam em execução, ao passo que PsExec, PowerShell remoting e uma instalação silenciosa com /qn são executados em segundo plano sem interrompê-la. Uma ferramenta de suporte remoto que compartilha a área de trabalho ativa também deixa o usuário no lugar, o que é importante quando você instala na máquina de alguém no meio do expediente.
Verifique o código de saída do instalador, não apenas se o comando retornou. Um 0 significa sucesso, 3010 e 1641 significam sucesso com reinicialização, e 1603 significa um erro fatal. O código de saída é o sinal confiável, portanto, capture-o com -PassThru no PowerShell. A maioria dos aplicativos MSI e EXE que registram um desinstalador também aparecem nas chaves de desinstalação em HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, seu ramo WOW6432Node para apps de 32 bits, e HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall para instalações por usuário, embora nem todo app escreva uma entrada lá. MSIX e outros apps empacotados como AppX aparecem por meio de Get-AppxPackage em vez disso, independentemente da origem. Evite Get-CimInstance Win32_Product, pois ele lista apenas produtos do Windows Installer e sua consulta pode acionar uma verificação de consistência do MSI lenta.
