Roll Back Microsoft Edge to a Specific Version

Customer case: Citrix-published Edge breaks .rdp downloads

I was working with a customer who publishes Microsoft Edge through Citrix for secure access to their T0 management environment.

After updating Edge to the latest stable build, users suddenly could no longer download .rdp files from a critical web application. Everything else in the app seemed fine, but the download simply failed from the published Edge instance.

Because this was a highly privileged environment, we wanted:

• Minimal change surface (no code changes in the web app)
• A fast way to confirm whether the new Edge build was the root cause
• A reversible test that we could safely run on the Citrix-delivered browser.

Hypothesis: recent Edge update introduced the regression

After a quick call with some Microsoft engineers, the working hypothesis was:

• The issue was introduced by the latest Edge stable update.
• If we could roll the browser back to the previous known-good build on the same machines, we could:
  • Validate the hypothesis quickly.
  • Decide whether to pin that version temporarily while engineering investigated.

That’s when the Microsoft team suggested using the rollback capability in EdgeUpdate via Group Policy / registry.

Setting up a live rollback test

The mechanism behind the test is straightforward:

• You configure EdgeUpdate to target a specific version prefix.
• You explicitly tell EdgeUpdate to roll back to that version if the current build is newer.
• Edge then downloads the desired build and switches over on the next restart.

Everything is driven via policies living under:

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate

For the Stable Channel of Microsoft Edge, you use the application GUID:

{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}

Implementation steps (registry-based)

1. Enable rollback for the Stable Channel

   In HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate, create or set:

   • Value name: RollbackToTargetVersion{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
   • Type: REG_DWORD
   • Data: 1

2. Specify the target Edge version

   In the same key, create or set:

   • Value name: TargetVersionPrefix{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
   • Type: REG_SZ
   • Data: 136.0.3240.50 (or whatever known-good version you want to roll back to)

3. Confirm the policy is applied in Edge

   Open Edge (in this case, the Citrix-published instance) and navigate to:

   • edge://policy

   There you should see both RollbackToTargetVersion and TargetVersionPrefix entries listed and marked as active:

4. Trigger the rollback

   Next, go to:

   • edge://settings/help

   Edge will check for updates, then download the specified target version if the configured prefix is older than the currently installed build. After the download completes, restart Edge to actually roll back to the pinned version.

Result of the test

Once the rollback completed and the Citrix-published Edge was running the specified older build, we re-ran the test in the T0 management web app:

• .rdp file downloads worked again with no changes to the application or Citrix configuration.
• That confirmed the regression was tied to the newer Edge version.
• The customer then chose to pin the working version temporarily using the same policies while coordinating with Microsoft for a permanent fix.

This pattern turned out to be a safe, low-friction way to A/B test Edge versions in a sensitive environment where changing the app or infrastructure would have been far more disruptive.

Appendix: Edge update channel GUIDs

The long GUID in the policy names is simply the application identifier for the Edge channel you are controlling. Microsoft uses separate GUIDs for each channel:

• Stable Channel: {56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}
• Beta Channel: {2CD8A007-E189-409D-A2C8-9AF4EF3C72AA}
• Dev Channel: {0D50BFEC-CD6A-4F9A-964C-C7416E3ACB10}
• Canary Channel: {4ea16ac7-fd5a-47c3-875b-dbf4a2008c20}

As long as you plug the right GUID into the policy names, you can use the same rollback pattern to test different versions across the Edge channels.

TL;DR for specialists

• Goal: Quickly confirm whether a new Microsoft Edge build is responsible for a regression in a published Edge instance running via Citrix (users could no longer download .rdp files from a T0 management web app).
• Approach: Use the RollbackToTargetVersion and TargetVersionPrefix policies to roll the published Edge back to a known-good build, without changing anything in Citrix or on the web app.
• Key registry location: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\EdgeUpdate
• Required values (for Edge Stable Channel {56EB18F8-B008-4CBD-B6D2-8C97FE7E9062}):
  • RollbackToTargetVersion{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} (REG_DWORD) = 1
  • TargetVersionPrefix{56EB18F8-B008-4CBD-B6D2-8C97FE7E9062} (REG_SZ) = e.g. 136.0.3240.50
• Verification steps:
  • In Edge: check edge://policy to confirm policies are applied.
  • In Edge: open edge://settings/help to trigger download and rollback to the specified version, then restart the browser.