RustDeskIntuneDeployment

Problem

Deploying RustDesk in an enterprise environment requires more than sending an MSI to Windows endpoints.

The client must receive the approved self-hosted HBBS, HBBR, and API addresses, the server public key, configuration that works for service and user contexts, operational logs, and a detection rule that proves more than executable presence.

Installation is normally executed by the Intune Management Extension as SYSTEM, while the Windows service and interactive users may read configuration from different profile locations. A successful MSI return code does not guarantee that the service started, the expected server was written, or Intune can detect the intended state.

Solution

RustDeskIntuneDeployment packages the deployment into three PowerShell workflows:

• install.ps1 performs the silent MSI installation, distributes configuration, validates written files, provisions the service, records logs, and creates a completion marker;
• detect.ps1 verifies the executable, an expected machine-level configuration, and the deployment marker;
• uninstall.ps1 locates the installed RustDesk MSI product and requests a silent removal.

The resulting source directory is converted into a Microsoft Intune Win32 application with the Microsoft Win32 Content Prep Tool.

The RustDesk server infrastructure remains outside the project scope. The package configures endpoints to connect to an approved service; it does not deploy HBBS, HBBR, the API, web console, operator identities, or server-side authorization.

Installation flow

The installer runs as SYSTEM and follows explicit stages:

1. creates organization-specific log and marker directories;
2. stops existing RustDesk processes and service when required;
3. selects the intended MSI and executes msiexec silently;
4. accepts Windows Installer success codes 0 and 3010;
5. locates the installed executable;
6. generates RustDesk2.toml from reviewed deployment values;
7. writes configuration to machine, service, default-user, and existing-user contexts;
8. validates that at least one configuration contains the expected host;
9. installs or starts the RustDesk service;
10. creates final operational evidence for Intune detection.

Any unexpected MSI code or missing validated configuration stops the workflow before the final marker is written.

Multi-context configuration

The configuration is written to several locations because the service and client may read different profiles depending on runtime context and RustDesk version:

• the LocalService profile;
• the system profile used by SYSTEM processes;
• C:\ProgramData\RustDesk\config;
• the Windows default-user profile;
• existing user profiles discovered through ProfileList in the Registry.

The default-user copy supports accounts that sign in after deployment. Existing profiles receive their configuration during installation.

The script validates the resulting files instead of assuming that a successful write operation produced the intended content.

Detection semantics

The custom Intune detection script requires three conditions:

1. a RustDesk executable in a recognized installation path;
2. at least one machine-level RustDesk2.toml containing the expected server;
3. the organization-specific deployment marker.

This is stronger than checking only the MSI product or executable, but it is intentionally package-state detection rather than complete health monitoring.

It does not currently prove service availability, every configured port, the public-key value, all user-profile copies, end-to-end connectivity, or support-operator authorization. Those responsibilities belong to operational monitoring and security governance.

Security decisions

Remote-support software has privileged endpoint impact. The project therefore requires:

• a trusted MSI with reviewed publisher signature, version, SHA-256 hash, provenance, and redistribution terms;
• reviewed server addresses, ports, and public key before packaging;
• inclusion of the RustDesk server public key only;
• exclusion of the server private key and production credentials;
• a pilot-first deployment ring;
• restricted and monitored access to the self-hosted infrastructure;
• sanitized logs, markers, screenshots, and documentation before publication;
• separation between authority to deploy the client and authority to initiate remote sessions.

An optional permanent-password block exists in the installer but is disabled. Embedding one shared plaintext password in a broadly distributed package is explicitly discouraged.

Logging and operational evidence

The deployment produces both a PowerShell orchestration log and a verbose Windows Installer log. After all stages succeed, it creates a marker containing deployment metadata such as the server, executable path, detected version, and validated configuration locations.

The marker is removed at the beginning of reinstall or repair. This prevents stale evidence from making a failed deployment appear compliant.

Known limitations

The current uninstall script queries Win32_Product, which can trigger Windows Installer consistency checks. A Registry-based product-code lookup is the planned hardening path.

The uninstall workflow focuses on the MSI product and does not automatically remove every configuration file, log, marker, or server-side record. Detection also does not continuously reconcile every TOML value.

These limitations are documented rather than hidden because deployment automation must distinguish its actual guarantees from broader operational health.

Current state

The repository contains the installation, detection, and removal scripts; bilingual architecture, configuration, and Intune documentation; security guidance; changelog; MIT license for the original automation; and placeholders for sanitized pilot evidence.

Environment-specific hostnames, ports, public keys, credentials, tenant information, and organizational identifiers remain outside the public configuration.

What it demonstrates

RustDeskIntuneDeployment demonstrates endpoint deployment as a state, context, and trust problem. It converts a vendor installer into a controlled Win32 application with multi-profile configuration, post-write validation, service provisioning, operational logs, explicit evidence, custom detection, staged rollout, and documented security boundaries.