SysadminNews

RDCMan’s RDG changes: preserve a real rollback copy

On this page
  1. The August update, with its successor
  2. A shared file has multiple readers
  3. Check more than the server tree

Saving a shared connection file with a newer client can affect colleagues who have not upgraded. A backup needs to preserve a usable older file, and credential portability is a separate issue.

RDG migration uses an untouched dated rollback copy and a separate converted working copy. Verify the old copy with the intended old client; verify new readers and credential protection independently. An executable downgrade does not reverse a saved file format.
RDG migration uses an untouched dated rollback copy and a separate converted working copy. Verify the old copy with the intended old client; verify new readers and credential protection independently. An executable downgrade does not reverse a saved file format. Chart : PeopleAreGeek. Data source.
View full-size image

The August update, with its successor

Microsoft's August 12 Sysinternals announcement included RDCMan 3.20 with Azure Virtual Desktop feeds and Dev Box support. It also introduced Process Monitor's ancestor-PID filtering and ZoomIt's DemoMirror. These are separate tools and capabilities, not evidence that a CPU information display traces every thread's placement over time.

At this September review, the RDCMan page lists 3.21, published August 19. Its upgrade note warns about older-client compatibility and says converted legacy files are backed up as filename.old. Password protection can use the logged-in user's Windows protection or an X509 certificate. File readability and the ability to decrypt stored credentials are therefore different checks.

A shared file has multiple readers

Our example has Alice and Bob reading the same server list. Alice saves an updated copy with the newer client. Bob's older client may no longer open that file. Reinstalling Alice's old executable does not itself reverse the serialized file format.

Keep a separately named, dated copy before conversion, with access controls appropriate to its contents. Preserve it outside the normal save path and verify it opens with the intended older client. The automatic .old file is useful, but its mere existence is not a complete rollback test. The earlier claim that a second save necessarily overwrites that backup was not established and is removed.

Coordinate which client versions may save the shared file during the transition. Test a copy first, compare the expected groups and servers, and confirm that references and authentication work on authorized accounts. Do not publish or place a connection file in a public repository merely because its passwords are encrypted.

Check more than the server tree

If a moved file displays its groups but authentication fails, investigate the credential protection context before concluding the file is corrupt. Conversely, successfully decrypting credentials does not prove every remote endpoint is reachable or authorized.

The cover separates original file, converted working copy and retained rollback copy. It is a migration diagram, not a screenshot of a tested RDCMan session. The practical goal is a reversible team rollout with verified readers and credentials, rather than assuming an executable downgrade or a nearby backup filename solves every compatibility problem.

Add current 3.21 update; avoid unsupported backup overwrite and thread-placement claims; separate file-format compatibility from credential portability.