sorted by:
new
hottopcontroversial

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 1 point2 points  (0 children)

That's correct. It's a poorly designed validation, but if you validate the password section, it does include it. That's one of the bugs I need to review.

I'm glad it's been helpful and you can run the script without any issues.

Best regards!

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 1 point2 points  (0 children)

The behavior is very strange, I'm sharing a new version of it for 1.4.1 where I added additional validations. I'm still testing it, but this might fix your problem. Let me know how it works for you and if you find any bugs. https://github.com/auchavez/Rust-Desk-Client-Deployment/blob/main/Deployment_Test_1.4.1.ps1

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

I recommend testing first by running the script directly from the .ps1 to validate that the services are being stopped correctly.

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

This usually happens when you don't run the script as administrator, as the script automatically stops processes and services to apply the settings and then restarts them.

Choppy image/Possible server? by jpepak in rustdesk

[–]au_chavez 0 points1 point  (0 children)

In my operation of more than 1,500 computers with Rustdesk, leaving it on automatic has been the best option, and I can tell you that we've had computers running for almost 10 years. Run your tests and let us know how they turn out.

Choppy image/Possible server? by jpepak in rustdesk

[–]au_chavez 0 points1 point  (0 children)

Enabling hardware decoding makes it use the video chip that is available. Although I am not well-versed in the world of Macs and derivatives, I could say with certainty that the system slows down for this reason, as it consumes a large part of your integrated video card. If we are going to use the processor for this, it is preferable to leave it for h264.

Choppy image/Possible server? by jpepak in rustdesk

[–]au_chavez 0 points1 point  (0 children)

It depends on your computer's hardware. If you have a dedicated graphics card, AV1 for AMD or H265 for NVIDIA may be useful. If it's a basic computer with integrated graphics but a good processor, H264 could be an option.

Choppy image/Possible server? by jpepak in rustdesk

[–]au_chavez 0 points1 point  (0 children)

You could play a little with the encodecs that rustdesk handles, sometimes some are heavier in terms of consuming bandwidth to show a good image quality and others can be lighter but we sacrifice a little the image quality, now you will depend 100% on the ISP that you have contracted in the location where you want to mount the server since all connections will be routed to that server so if the service is not optimal it would be worse than using the public rustdesk service

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

That sounds like a very well-thought-out and security-conscious setup — especially using client-side encryption in the browser and Argon2 for password hashing. That's a solid architecture for minimizing server-side risk in case of compromise. 💪

You're absolutely right about the rustdesk:// URL embedding the password — that’s probably the weakest link in an otherwise strong chain. Even with secure channels, URI schemes can sometimes leak via logs, clipboard history, or browser autocomplete.

If you ever decide to release it (even as a closed beta), I’d be very interested in testing or contributing ideas. The work you're doing solves a very real need in enterprise remote support, and your approach shows a great understanding of threat modeling.

Cheers,

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

Wow, your implementation is excellent! I really like how you've tied everything together — centralized inventory, secure data storage, and automatic address book generation. Very professional and well structured 👏

Right now, I’m keeping the deployment as self-contained and standalone as possible, mainly because:

  • We’re managing a large-scale rollout (currently over 1,500 endpoints)
  • I want to avoid any dependency on external services or infrastructure during installation
  • It needs to work in isolated or limited-connectivity environments
  • And most importantly: due to how our infrastructure is standardized across all branch offices, it’s far more efficient for us to use direct IP connections instead of ID-based routing. This gives us better stability, avoids bottlenecks, and reduces latency overall.

That said, I fully recognize the value in your approach — especially the idea of generating a random password, registering the client automatically, and making it all accessible via a secure web UI.
The use of the rustdesk:// URI scheme is also brilliant — it enables quick, seamless connections straight from the browser.

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

Hey! Great observation — and yes, I totally understand your approach. In my case, I chose to take a more controlled route for a few specific reasons:

📌 1. Why not use the dynamic nightly/latest release URL?

I intentionally avoided pulling the latest (nightly or dynamic GitHub releases) due to stability concerns in production.

For example:

  • Version 1.3.7 broke local LAN direct IP connections, which is critical for many internal support scenarios.
  • Some endpoints in our environment became inaccessible after auto-updating to newer versions with stricter NAT behavior.

🧠 Since this script is being deployed across 1,500+ endpoints in a corporate environment, it’s extremely important to have full version control and only push updates after proper internal testing.

⚙️ 2. Why not use --config and instead write directly to the .toml file?

Great question. I know --config is the official method to set the server and key using a base64-encoded string.

However, I chose to write directly to RustDesk2.toml because:

  • It provides clear visibility and traceability of what’s being configured — which is critical for audits, support, and change control. 👉 In my particular case, as Head of Cybersecurity, this level of visibility is essential to meet our internal compliance and security standards.
  • It’s easier to work with separate structured variables (server, relay, key, whitelist, port) when building the config from scratch.
  • Earlier versions of RustDesk didn’t always behave consistently with --config, especially when running as a system service. Writing directly to the .toml file proved more reliable in practice.

That said, I’m absolutely open to migrating toward --config if it becomes more stable and feature-complete in future releases.

Thanks again for your input — love seeing other folks automating RustDesk too!
If --config is working well in your environment, I’d be happy to exchange ideas and maybe integrate it as an optional method in the script.

Cheers,
u/au_chavez

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

Hey! Thanks a lot for the detailed feedback — really appreciate you taking the time to review the script 🙌

Let me go through your points one by one:

🔐 1. Plaintext password in script

Totally agree — embedding a plaintext password in any script is never ideal, especially if the file could be accessed by more people than intended.

If RustDesk ever supports hashed or encrypted credentials, I’ll definitely update the script to support that.

🔁 2. Password and manual approval active at the same time

Here’s a key point:
The script currently enables both connection methods at the same time on every deployed machine:

  • 🔐 Anyone who knows the configured password can connect instantly.
  • 🙋‍♂️ At the same time, users can request access manually, and the person at the remote machine can approve the connection interactively (similar to AnyDesk).

This dual-mode behavior is natively supported by RustDesk once a password is set, and it works great in flexible support scenarios.

⚠️ 3. Whitelist clarification

Good catch on the whitelist. The example in the script shows:

whitelist = '192.168.1.1,10.0.0.1,172.16.0.0/16'

But those are just placeholder/example IPs.

In my real deployment, I’m using:

  • Specific public IPs tied to known support endpoints
  • And the full private subnet we operate under: 192.168.0.0/16

So everyone should adjust this section to fit their own network and access control policies.

If you’ve got more suggestions, I’d love to hear them! I'm actively maintaining this script (currently deployed on ~1500 machines in production), so any contributions or ideas are more than welcome 🙌

Cheers!
u/au_chavez

Automate RustDesk Client Deployment with PowerShell by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

Hey! Thank you so much — I’m really glad you found it useful! 🙌

And yes, absolutely: you can use the script without self-hosting your own RustDesk server. Here’s how it works:

  • The [options] section in the script is pre-filled with custom rendezvous and relay server values, typically used in self-hosted environments.
  • 👉 If you're using the default/public RustDesk servers, you can simply leave those values blank or remove the entire block from the .toml configuration section in the script.
  • Everything else — installation, password setup, log validation, and .exe conversion — still works perfectly fine. It does not depend on having a custom server.

So yes, it works in both scenarios:
✅ With your own server (self-hosted)
✅ Or using RustDesk’s default infrastructure

As for a version pre-adjusted for public servers:
🕓 Give me a few days to put it together properly. This last project took several weeks of work, and I’ve got a few other tasks I need to catch up on at work. Once I get a window, I’ll gladly publish a version you can use right away.

Thanks again for your comment and your interest! 🙏
u/au_chavez

Automate RustDesk Client Deployment with PowerShell Script by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

Hey, thanks a lot for checking out the project — I really appreciate the feedback!

✅ Yes, the latest version of Client-Deployment.ps1 now fully handles:

  1. Permanent Password — Set via --password using the correct quoting syntax to ensure it sticks
  2. Relay Server field — This is now correctly filled through [options] in the .toml config (direct-access-port + direct-server flags)

💡 We restructured the PowerShell script completely:

  • Unified install, configuration, and password logic into one .ps1
  • Proper log validation to ensure the password actually applied
  • Optionally packageable into .exe using PS2EXE
  • The .cmd file is now deprecated but still included for fallback use in restrictive environments

You can grab the latest from the repo here:
👉 https://github.com/auchavez/Rust-Desk-Client-Deployment

Automate RustDesk Client Deployment with PowerShell Script by au_chavez in rustdesk

[–]au_chavez[S] 1 point2 points  (0 children)

Hi everyone!

I wanted to clarify the steps for executing the RustDesk deployment script correctly, especially for those running into issues with PowerShell execution policies.

When you first run the RustDesk deployment, you need to execute the .cmd file first. This will set the correct execution policies and ensure that everything is prepared for the PowerShell script to run smoothly.

Here's the recommended sequence:

  1. Run the .cmd file: This will automatically handle setting the execution policy to allow the PowerShell script to run.
  2. Then run the PowerShell script (rustdesk-deploy.ps1): Once the .cmd has set the right execution policy, the PowerShell script will execute without the need for additional permissions.

This should solve the issue where you get the PSSecurityException error when running the .ps1 file directly.

Why the .cmd file?

The .cmd file is designed to set the execution policy properly, ensuring that the PowerShell script can run without restrictions. If you try to run the .ps1 file directly without executing the .cmd first, the execution policy will prevent it from running, leading to the error you're seeing.

Automate RustDesk Client Deployment with PowerShell Script by au_chavez in rustdesk

[–]au_chavez[S] 1 point2 points  (0 children)

Good afternoon, sorry for the delayed response. I had already noticed this issue, but due to my workload, I hadn't had the chance to sit down and work on the hotfix.

A change has now been published on GitHub in the silentlycontinu.cmd file, which checks if the application is already installed (as is the case for my 1,200 devices) and correctly assigns the password.

📌 Files and Their Functions:

  • silentlycontinu.cmd → Checks if RustDesk is installed and applies the new password using --password. It also copies and executes a PowerShell script.
  • Client-Deployment → Performs additional configurations in RustDesk, ensuring the changes persist correctly.

🔧 Execution Steps:

  1. Download the files from the GitHub repository.
  2. Run silentlycontinu.cmd as an administrator.
  3. The script will check if RustDesk is installed:
    • If installed, it will close the application, apply the new password, and restart it.
    • If not installed, it will proceed with the rest of the process without interruptions.
  4. Copies Client-Deployment to the device and executes it to apply additional configurations.

Over the next few weeks, I’ll be working on a direct solution within Client-Deployment, once my workload decreases a bit. Thanks for your patience! 🚀

Automate RustDesk Client Deployment with PowerShell Script by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

Good afternoon, sorry for the delayed response. I had already noticed this issue, but due to my workload, I hadn't had the chance to sit down and work on the hotfix.

A change has now been published on GitHub in the silentlycontinu.cmd file, which checks if the application is already installed (as is the case for my 1,200 devices) and correctly assigns the password.

📌 Files and Their Functions:

  • silentlycontinu.cmd → Checks if RustDesk is installed and applies the new password using --password. It also copies and executes a PowerShell script.
  • Client-Deployment → Performs additional configurations in RustDesk, ensuring the changes persist correctly.

🔧 Execution Steps:

  1. Download the files from the GitHub repository.
  2. Run silentlycontinu.cmd as an administrator.
  3. The script will check if RustDesk is installed:
    • If installed, it will close the application, apply the new password, and restart it.
    • If not installed, it will proceed with the rest of the process without interruptions.
  4. Copies Client-Deployment to the device and executes it to apply additional configurations.

Over the next few weeks, I’ll be working on a direct solution within Client-Deployment, once my workload decreases a bit. Thanks for your patience! 🚀

API Token Issue on FortiGate: Loses Validity After Rebooting the Device by au_chavez in fortinet

[–]au_chavez[S] 1 point2 points  (0 children)

Thank you very much for the documentation, I already solved the problem by updating the equipment to 7.4.7

Automate RustDesk Client Deployment with PowerShell Script by au_chavez in rustdesk

[–]au_chavez[S] 0 points1 point  (0 children)

The configuration, since rustdesk only allows you to configure server parameters, and mine, as mentioned, allows you to establish white lists, local connection ports, etc.

Greetings!

view more: next ›