Roll Back to Previous Version of Office When on Microsoft 365 Current Channel (Preview)

Rolling back to previous versions of Microsoft 365 (nee Office 365) is hard enough in the best-case scenario. Troubleshooting problems is a nightmare.

Roll Back to Previous Version of Office When on Microsoft 365 Current Channel (Preview)

Backing out an Office update from the preview channel of Microsoft 365 is needlessly difficult.

On my home computer, I'm subscribed to the "Current Channel (Preview)" of Microsoft 365.  I'm troubleshooting an error that may be related to a recent update, so I'm trying to roll back my Office version.  The normal instructions for backing out updates from Click-to-Run versions of Office are convoluted enough on their own:

How to revert to an earlier version of Office

Install the previous version of Office

To install the previous version of Office, follow these steps:

  1. Determine and note the previous version number. Use the following Microsoft website to find the update version that is previous to the current version:

Update history for Microsoft 365 Apps for enterprise (listed by date)

  1. Download and run the self-extracting executable file from the following Download Center link. This file contains the Office Deployment Tool executable (Setup.exe) and a sample configuration file (Configuration.xml):

Office Deployment Tool

  1. Start Notepad and copy the following XML. Then, save the file as Config.xml in the same file location as the Setup.exe file from Step 2.

    <Configuration>
    <Updates Enabled="TRUE" TargetVersion="16.0.xxxxx.yyyyy" />
    </Configuration>
    

Note: In the XML, 16.0.xxxxx.yyyyy represents the full version number that you noted in step 1.

  1. Open an elevated Command Prompt window. To do this, click Start, type cmd in the Start Search box, right-click cmd.exe, and then click Run as administrator. Switch to the file location for the Setup.exe and Config.xml files.

  2. Run the following command:

    setup.exe /configure config.xml
    
  3. Start an Office application (such as Excel), and then select File > Account.

  4. In the Product Information section, select Update Options > Update Now.

Note If you are prompted to activate Office again, enter your Microsoft account and password. This step does not add your computer to your account a second time.

The above convoluted instructions are the steps you have to follow in the best-case scenario: when everything works like it's supposed to.

Unfortunately for me, today is not one of those days.  I will be honest: I don't know what's wrong with my setup or why it's not working.  There's a chance that the ultimate solution to my problem will never apply to another person or computer in the world.  

That said, I've learned a lot of advanced troubleshooting techniques over the years that can be applied to all sorts of situations even if they are not exactly the same as this.  And if you are one of the (un)lucky few who are having the exact same problem as me, I hope to be able to deliver you a working solution by the end of this article.

After all, the world doesn't need another DenverCoder9:

Something went wrong

For some reason, I kept getting the following error message despite following the above instructions to the letter:

Something went wrong
We're sorry, we ran into a problem while looking for updates.  Please check your network connections and try again later.

Go online for additional help.
Error Code: 30183-27 (400)

I tried several different approaches to fixing this error message without success, including:

  • Closing all other Office programs
  • Restarting the computer
  • Running Word as an administrator before checking for updates
  • Adding Channel="Current" to the Updates node in config.xml: <Updates Enabled="TRUE" TargetVersion="16.0.17029.20140" Channel="Current" /> and then restarting the process from step 4 above
  • Disconnect from all VPNs
  • Performing a "Quick Repair" of Office via Apps & Features > "Microsoft 365 Apps for business - en-us" > [Modify] > (•) Quick Repair > [Repair]
  • Performing an "Online Repair" of Office via Apps & Features > "Microsoft 365 Apps for business - en-us" > [Modify] > (•) Online Repair > [Repair]
  • Attempting to change to several other update channels, to no avail
  • Disabling unused network adapters, including a "VirtualBox Host-Only Ethernet Adapter"
  • Using the Office Click-to-Run client with the command line, "C:\Program Files\Common Files\microsoft shared\ClickToRun\officec2rclient.exe" /update user updatetoversion=16.0.17029.20140 (thanks for the idea, Sandor!)

No matter what I tried, I got the same result, "We're sorry, we ran into a problem while looking for updates.  Please check your network connections and try again later."

My Original Configuration

As I mentioned above, I'm subscribed to the preview channel of Microsoft 365.  Here's what that looks like on the Account screen in Microsoft Access:

Here are the details when I click on the [About Access] button:

NOTE: I have no idea if the License ID and Session ID values are sensitive, but they are likely globally unique, so it seemed prudent to blur them out.

With Microsoft 365, the version and build number are the same for all Office applications.  For example, here's my About info for Microsoft Word:

Microsoft Word shows the same version, same build number, same bitness, and same License ID as Microsoft Access.  The only difference is in the Session ID values.

The Contents of My Config.xml File

Here are the contents of my config.xml file:

<Configuration>
<Updates Enabled="TRUE" TargetVersion="16.0.17029.20140" />
</Configuration>

My intent was to rollback from Version 2401 to Version 2311.  I got the TargetVersion value from here: Update history for Microsoft 365 Apps (listed by date).

So, what was I doing wrong?

My Troubleshooting Approach

Check the Log Files

First, I checked the log files that get generated when you click Update Options > Update Now from an Office application.

The log files get created automatically in the current user's temp folder.  They appear to be named with the following convention:

%COMPUTERNAME%-YYYYMMDD-HHNN.log

I found the files by using Everything and sorting the "Date Modified" column in descending order.  However, if you don't have the Everything utility, you should get it.  Furtherhowevermore, if you refuse to get the Everything utility, you can use a couple simple commands in a command window to find the log files:

  1. Open a cmd window
  2. Enter cd %tmp% to change the working directory to the user's temp folder
  3. Enter dir /P /O-D *.log to list one screen's worth of the most recently created files whose filenames end with .log
  4. Open the most recent .log file that matches the above filename format to look for clues

Unfortunately for me, the log file held no useful clues.  Perhaps you will have more luck.

Try ProcMon

My next go to tool when I get desperate is Process Monitor:

Using ProcMon to Troubleshoot Registry Calls
Finding the correct registry keys for JetShowPlan and ODBC TraceSqlMode can be tricky. Let ProcMon take the guesswork out of the process.

I wanted to see what registry entries got changed when I ran the Office Deployment Tool.  To do that, I ran procmon with the following filters:

  • INCLUDE: "Process Name" is setup.exe
  • INCLUDE: "Operation" is RegSetValue
  • INCLUDE: "Path" contains Office

This filtered my results down to 7 events from a total of over 240,000 (captured in the span of about five to ten seconds).  While a few of them were irrelevant, three of them all pointed to the same subkey:

HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\UpdateToVersion

For reference, here's what the values in that registry key look like for my machine:

Bear in mind that Office updates are currently broken on my machine, so one or more values above may be problematic.  In fact, one Reddit thread suggested that updates would not work if the CDNBaseUrl and UpdateChannel values did not match.

Note that the values in my screenshot above do not match.  

Based on my testing, I believe that the GUIDs from these URLs correspond with the following update channels:

  • 5440fd1f-7ecb-4221-8110-145efaa6372f: BetaChannel
  • 64256afe-f5d9-4f86-8936-8840a6a4f5be: CurrentPreview
  • 492350f6-3a01-4f97-b9c0-c7c6ddf67d60: Current
  • 55336b82-a18d-4dd6-b5f6-9e5095c314a6: MonthlyEnterprise
  • b8f9b850-328d-4355-9145-c59439a0c4cf: SemiAnnualPreview
  • 7ffbc6bf-bc32-4f92-8982-f9dd17fd3114: SemiAnnual

To get these values, I simply set my config.xml file to the following...

<Configuration>
<Updates Channel="BetaChannel" />
</Configuration>

...saved the file, then ran ODT in configure mode–setup.exe /configure config.xml– and refreshed the registry key listed above.  Each time I did this, the CDNBaseUrl would change.  Curiously, the AudienceId and UpdateChannel values did not change.  Curiouslier, the UpdateChannelChanged value remained set to False the entire time, even though literally the only thing I was doing was changing the update channel.

The Fix/Workaround

Ever the eternal optimist, I began writing this article assuming I'd have a solution by the time I reached the end.  Alas, it was not to be.  Three hours is simply not enough time.  As of publication, I'm still searching for an answer to the problem.

If I figure it out, I will be sure to let you know.  Unlike DenverCoder9.

To be continued...

UPDATE [2024-01-25]: Attempted to use officec2rclient.exe to roll back updates, but got the same error message as with all other attempts.

All original code samples by Mike Wolfe are licensed under CC BY 4.0