Tutorial

How to Install RDCMan on Windows

A clean installation and first-launch workflow for the current Microsoft Sysinternals RDCMan release.

Primary topic: install RDCManReviewed: August 10, 2026

RDCMan is distributed by Microsoft Sysinternals and should be acquired from the official product page. Installation guidance on older websites can be confusing because historic RDCMan releases used different packaging and supported older Windows versions. Start by checking Microsoft’s current page rather than following a legacy MSI walkthrough.

For v3.12, Microsoft provides a downloadable package and Sysinternals Live access. The official page lists Windows 11 and higher for client systems and Windows Server 2016 and higher for server systems. Use those current statements when deciding whether a machine is an appropriate target.

Conceptual RDCMan administration workflow

Before installing or launching RDCMan

Confirm that the workstation is in the current supported environment, that you obtained the package from Microsoft, and that your account is allowed to run administrative utilities. If endpoint application control is in use, complete the same approval path you would use for other Sysinternals tools.

If this is an upgrade, find any RDG files you rely on and make a backup outside the working folder. Microsoft warns that RDG files saved by the current version are not compatible with older RDCMan versions. A legacy RDG opened and saved by the current build is backed up as filename.old, but an intentional backup still gives you a clearer rollback point.

Step-by-step setup

Download from Microsoft

Open the Sysinternals product page and use the Microsoft-provided package. Avoid repackaged installers when the publisher already offers a direct source.

Place the files in an approved location

Use a folder that matches your workstation-management policy. Avoid temporary folders that will be cleaned unexpectedly if RDCMan and its related files need to remain available.

Launch RDCMan

Start the application under the Windows account that will own the local configuration context. If Windows or your security software presents a publisher or application-control prompt, verify the details rather than bypassing it reflexively.

Create or open an RDG file

For a new environment, create a new file and plan the group hierarchy. For an existing environment, work from a backed-up copy until you have confirmed the upgrade behavior.

First-run configuration priorities

Do not begin by adding every server you can find. First decide how groups should map to environments, sites or roles. Group-level settings can be inherited, so a good hierarchy prevents you from entering the same values dozens of times. A poor hierarchy does the opposite and can also make it difficult to see which settings a child server inherits.

Next decide how credentials should be handled. Microsoft documents credential profiles and encrypted password storage, but that does not remove the need for least-privilege accounts, protected administrator workstations and your organization’s credential policy. Store only what your operational policy permits.

Portable utility does not mean unmanaged utility

Sysinternals tools are commonly easy to run, but operational convenience should not be confused with a lack of governance. RDCMan can reach many remote systems from one interface. That concentration of access makes the host workstation, RDG files and credentials important assets.

On a shared or sensitive administration workstation, document who maintains the tool, where the approved package came from, when it was reviewed and how configuration is backed up. These controls are simple, but they make troubleshooting and incident response much easier later.

Upgrade and rollback considerations

Because v3.12 includes an explicit RDG compatibility warning, treat an RDCMan upgrade as a configuration-format change, not only an executable replacement. Test an important RDG file with the newer version before rolling the change across every admin workstation.

If multiple administrators exchange RDG files, coordinate the application version as well. One person saving a shared file with the newer release can make that file unsuitable for a colleague who still relies on an older version. A small version note in the team runbook can prevent unnecessary recovery work.

What to configure next

After RDCMan launches successfully, build the connection tree in a controlled sequence: create groups, set inherited connection preferences, add a small number of servers, test credentials and display settings, and only then expand the inventory. This makes it easier to identify which setting caused a problem.

The beginner setup guide continues with a practical first configuration. For a focused server workflow, use how to add servers in RDCMan.

Example: first deployment on an admin workstation

Consider an administrator preparing RDCMan on a newly built Windows 11 administration workstation. The clean sequence is to confirm the current Sysinternals support statement, obtain the package through the approved Microsoft source, place it in the organization’s normal tools location, and launch it under the account that will use the configuration. Before importing a production server list, the administrator creates a small test RDG file with two lab hosts and verifies authentication, gateway behavior, display settings, and local-resource redirection.

This small test creates a baseline. If a later bulk import behaves incorrectly, the team already knows the application itself launches and the basic connection path works. It also gives security controls such as application allow-listing or endpoint protection a chance to surface any policy issue before dozens of connection definitions depend on the tool.

Upgrade planning is part of installation

For RDCMan, “installation” also includes version coordination because the current documentation warns about RDG compatibility. A team with several administration workstations should avoid a situation where one operator upgrades, saves a shared RDG file, and unintentionally prevents colleagues on an older release from using that file.

Before an upgrade, identify shared RDG files, create independent backups, note the existing RDCMan version, and choose a small file for validation. After the new release is approved, update the team together or establish a temporary rule that upgraded files are not shared back to older workstations. This is a lightweight change-control step, but it prevents a format issue from becoming an access problem during an incident.

Practical checklist

  • Verify current Microsoft support before running RDCMan.
  • Download from Microsoft Sysinternals, not a repackaged installer.
  • Back up RDG files before upgrading.
  • Plan groups before bulk-adding servers.
  • Test with a small set of hosts before expanding the configuration.