Implantando o RustDesk com Microsoft Intune

Instalar um aplicativo remotamente é relativamente simples. Implantá-lo de forma consistente, configurá-lo para diferentes contextos do Windows, validar o resultado e permitir que o Microsoft Intune detecte corretamente o estado final é um problema bem mais amplo.

Foi esse o desafio que encontrei ao preparar o RustDesk para distribuição em endpoints Windows gerenciados.

O RustDesk seria usado como cliente de suporte remoto conectado a uma infraestrutura própria. Portanto, não bastava enviar o MSI para os computadores. Cada endpoint também precisava receber os endereços corretos dos serviços HBBS, HBBR e API, a chave pública do servidor, a configuração adequada para serviço e usuários, além de logs e uma regra de detecção confiável.

Para resolver isso, criei o projeto RustDeskIntuneDeployment, um pacote baseado em PowerShell para instalar, configurar, detectar e remover o RustDesk por meio de aplicações Win32 do Microsoft Intune.

O código-fonte está disponível no GitHub:

• RustDeskIntuneDeployment

O problema

Uma instalação manual do RustDesk pode ser configurada diretamente na interface do aplicativo. Em uma implantação corporativa, porém, esse modelo não escala.

Os dispositivos precisam receber a mesma configuração aprovada sem depender de intervenção local. Além disso, a instalação normalmente é executada pelo Intune Management Extension no contexto de SYSTEM, enquanto o aplicativo e seu serviço podem consultar arquivos de configuração em contextos diferentes.

Isso cria algumas questões importantes:

1. Como instalar o MSI silenciosamente e tratar corretamente os códigos de retorno?
2. Onde gravar a configuração para que ela seja encontrada pelo serviço, pelo sistema e pelos usuários?
3. Como configurar usuários que já existem e também aqueles que só farão logon depois da implantação?
4. Como impedir que o Intune considere o aplicativo instalado quando apenas o executável existe, mas a configuração falhou?
5. Como produzir evidências suficientes para investigar erros de instalação?
6. Como evitar incorporar segredos perigosos no pacote?

O objetivo deixou de ser simplesmente “instalar o RustDesk” e passou a ser:

Entregar um estado configurado e verificável, não apenas executar um instalador.

Arquitetura do pacote

O projeto contém três scripts principais:

O fluxo de implantação pode ser resumido assim:

Administrador
    │
    ├── MSI confiável
    ├── scripts PowerShell
    └── valores de configuração
             │
             ▼
      Pacote .intunewin
             │
             ▼
      Microsoft Intune
             │
             ▼
 Intune Management Extension
             │
             ▼
       Endpoint Windows
    ├── aplicativo RustDesk
    ├── serviço do Windows
    ├── arquivos RustDesk2.toml
    ├── logs de instalação
    └── marcador de detecção

A infraestrutura do servidor RustDesk permanece fora do escopo do pacote. O projeto configura os clientes para se conectarem aos serviços aprovados, mas não implanta nem administra HBBS, HBBR, API, console web ou controles de acesso do servidor.

Instalando o MSI silenciosamente

O instalador localiza o primeiro arquivo *.msi no diretório de origem e executa o Windows Installer com parâmetros silenciosos.

$MsiArgs = @(
    "/i"
    "`"$($Msi.FullName)`""
    "/qn"
    "/norestart"
    "INSTALLFOLDER=`"$InstallFolder`""
    "CREATEDESKTOPSHORTCUTS=`"N`""
    "INSTALLPRINTER=`"N`""
    "/l*v"
    "`"$MsiLog`""
)

O script aceita os códigos 0 e 3010. O segundo indica que a instalação foi concluída, mas pode exigir reinicialização.

Qualquer outro código interrompe a execução. Isso evita continuar para a configuração quando o MSI não foi instalado corretamente.

Há também uma implicação operacional: como o script seleciona o primeiro MSI encontrado, o diretório de origem deve conter apenas o instalador pretendido. Antes de empacotar, é necessário validar a assinatura do fornecedor, a versão, o hash SHA-256 e as condições de distribuição do arquivo.

Distribuindo a configuração para múltiplos contextos

Um dos pontos centrais do projeto foi entender que um único arquivo em um perfil de usuário não atenderia todos os cenários.

O instalador gera o RustDesk2.toml com os valores do servidor e o distribui para diferentes locais:

• perfil LocalService;
• perfil de sistema usado por processos executados como SYSTEM;
• diretório compartilhado em C:\ProgramData\RustDesk\config;
• perfil padrão do Windows;
• perfis de usuários existentes encontrados no Registro.

Os perfis já criados são descobertos em:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

O script expande os caminhos registrados e exclui perfis compartilhados ou de modelo, como Public, Default e All Users.

Essa duplicação é deliberada. O serviço e o cliente interativo podem ler a configuração em contextos distintos, e o comportamento pode variar conforme a versão e o método de instalação.

O perfil padrão atende usuários que ainda não fizeram logon. Os perfis existentes recebem uma cópia direta no momento da implantação.

Validando a configuração gravada

O script não assume que uma operação foi bem-sucedida apenas porque não gerou uma exceção.

Depois de escrever os arquivos, ele percorre os destinos e procura o hostname esperado:

if (Select-String -Path $ConfigFile -SimpleMatch $ExpectedHost -Quiet) {
    $ValidConfigs.Add($ConfigFile)
}

A instalação falha caso nenhum arquivo contenha o servidor configurado.

Essa validação é simples, mas importante. Sem ela, o Intune poderia receber um código de sucesso mesmo que os arquivos fossem gravados incorretamente, permanecessem vazios ou contivessem uma configuração diferente da esperada.

Instalando e verificando o serviço

Após localizar o executável, o script verifica a existência do serviço RustDesk.

Quando necessário, tenta instalá-lo com:

& $RustDeskExe --install-service

Depois, inicia o serviço e consulta suas propriedades por CIM.

A instalação só chega à etapa final quando o serviço pode ser confirmado. Dessa forma, o pacote não trata a simples presença do executável como evidência suficiente de uma implantação funcional.

Logs e marcador de conclusão

O projeto separa dois tipos de log:

• um transcript do PowerShell com as decisões do fluxo de instalação;
• um log detalhado do Windows Installer.

Com uma organização configurada como orgname, os caminhos ficam semelhantes a:

C:\ProgramData\orgname\IntuneLogs\RustDesk-Intune-Install.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\RustDesk-msi-install.log

Ao final, o instalador cria um marcador em:

C:\ProgramData\orgname\IntuneMarkers\RustDesk-Configured.marker

Esse arquivo registra informações como data, servidor, caminho do executável, versão detectada e arquivos de configuração validados.

O marcador é removido no início de uma reinstalação ou reparo. Isso reduz o risco de uma instalação com falha manter uma evidência antiga e gerar um falso positivo na detecção.

Ele não é uma atestação criptográfica. É uma evidência operacional de que o fluxo personalizado chegou à etapa final.

Detecção no Microsoft Intune

A detecção personalizada exige três condições:

1. um executável do RustDesk em um caminho reconhecido;
2. pelo menos um arquivo de configuração de máquina contendo o servidor esperado;
3. o marcador de conclusão.

if ($ExeExists -and $ConfigOk -and (Test-Path $MarkerFile)) {
    exit 0
}

exit 1

Essa abordagem é mais confiável do que verificar apenas se um arquivo ou produto MSI existe.

Entretanto, a detecção foi projetada para confirmar o estado do pacote, não a saúde completa do serviço remoto.

Ela não verifica atualmente:

• se o serviço está em execução;
• todos os valores de porta;
• a chave pública configurada;
• todos os perfis de usuário;
• conectividade com HBBS, HBBR ou API;
• sucesso de uma sessão remota;
• autorização dos operadores de suporte.

Essa distinção é importante. Uma regra de detecção do Intune não deve ser confundida com monitoramento de disponibilidade ou validação de segurança ponta a ponta.

Configuração recomendada no Intune

O pacote é preparado com o Microsoft Win32 Content Prep Tool e enviado como uma aplicação Win32.

Os comandos recomendados são:

Instalação:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File install.ps1

Desinstalação:
powershell.exe -NoProfile -ExecutionPolicy Bypass -File uninstall.ps1

As configurações principais incluem:

O rollout deve começar por um grupo piloto pequeno e representativo. Depois da validação, a atribuição pode avançar progressivamente para suporte, TI, departamentos selecionados e, por fim, implantação geral.

Modelo de segurança

Uma ferramenta de suporte remoto possui impacto elevado no endpoint. Por isso, tratei o pacote como automação privilegiada.

Os principais cuidados são:

• executar somente um MSI obtido de uma origem confiável;
• validar assinatura, versão e hash antes de empacotar;
• revisar os endereços e portas antes da distribuição;
• incluir apenas a chave pública do servidor;
• nunca incluir a chave privada da infraestrutura RustDesk;
• restringir e monitorar o acesso ao servidor de suporte remoto;
• usar implantação em anéis;
• proteger e sanitizar logs e marcadores antes de publicá-los;
• separar autorização de implantação da autorização para iniciar sessões remotas.

O projeto contém um bloco opcional para configurar senha permanente, mas ele fica desabilitado por padrão.

Uma senha compartilhada em texto claro dentro de um pacote distribuído para todos os endpoints criaria uma credencial de amplo alcance e difícil rotação. Em produção, o melhor desenho é usar credenciais únicas, controladas centralmente ou provisionadas por um mecanismo específico para segredos.

Limitações assumidas

Documentar limitações faz parte do projeto.

A desinstalação atual consulta Win32_Product para localizar o MSI. Essa classe pode iniciar verificações de consistência do Windows Installer e não é a abordagem ideal para ambientes maiores.

Uma versão futura deve localizar o produto pelas chaves de desinstalação do Registro e validar explicitamente o código de retorno do msiexec.

Além disso, a remoção atual se concentra no produto MSI. Ela não remove automaticamente todos os arquivos de configuração copiados, logs, marcadores ou registros existentes no servidor RustDesk.

Também não há reconciliação contínua de toda a configuração. O pacote é uma aplicação gerenciada, não um agente permanente de conformidade. A detecção pode provocar uma reinstalação quando as condições verificadas deixam de existir, mas não compara continuamente cada parâmetro do RustDesk2.toml.

O que aprendi

Este projeto reforçou que implantação de endpoints é um problema de estado, contexto e confiança.

O instalador pode terminar com sucesso, mas o serviço ainda pode estar ausente. O executável pode existir, mas apontar para a infraestrutura errada. A configuração pode funcionar no perfil de um usuário e não no contexto de SYSTEM. O Intune pode declarar sucesso com uma regra de detecção superficial, mesmo quando a finalidade real do pacote não foi alcançada.

A solução foi decompor a implantação em etapas verificáveis:

• validar o artefato de origem;
• instalar silenciosamente;
• localizar o executável real;
• gravar a configuração nos contextos necessários;
• verificar o conteúdo escrito;
• confirmar o serviço;
• produzir logs;
• criar uma evidência final;
• detectar o conjunto mínimo de condições esperadas.

Mais importante, o projeto demonstra que uma automação de suporte remoto deve ser desenhada junto com controles de segurança. Distribuir o cliente é apenas uma parte da solução. Identidade, autorização, auditoria, proteção de segredos, infraestrutura do servidor e governança dos operadores continuam sendo responsabilidades separadas.

Próximos passos

As principais melhorias planejadas incluem:

• substituir Win32_Product por descoberta via Registro;
• validar o código de saída da desinstalação;
• tornar a detecção mais granular para portas e chave pública;
• adicionar testes automatizados para geração e validação da configuração;
• definir uma política explícita para remoção ou retenção de logs e marcadores;
• avaliar um modelo de remediação para configurações divergentes;
• publicar evidências sanitizadas de uma implantação piloto.

O projeto já fornece uma base reutilizável para transformar o RustDesk em uma aplicação Win32 gerenciada, com instalação silenciosa, configuração multi-contexto, logs operacionais e detecção personalizada.

Código-fonte

A implementação completa, a documentação de arquitetura, as orientações de configuração e o procedimento de implantação estão disponíveis no GitHub:

• RustDeskIntuneDeployment