With Microsoft’s major push of Office 365, more specifically Click-to-run (C2R or CTR), I think it important to briefly touch base on the entire update process.
Do note that the following also applies to the C2R versions of Access 2013, 2016, 2019, 2021+ the only difference being the build numbers.
While Office 365 will, unless reconfigured, automatically updates itself based on the Update Channel (you can learn more about Update Channel by reviewing Overview of update channels for Office 365 ProPlus) you have chosen to use (and yes, I too, never made any such choice and was automatically setup on the Deferred Channel). This, on the surface, sounds like a brilliant approach, but as we have recently seen (updates 1705, 1706, 1707) sometimes updates can introduce new bugs that are more problematic then the ones they are supposedly resolving.
With Office 365, much to most people’s dismay, one can no longer simply open the Control Panel to uninstall an update. Microsoft no longer offers a graphic interface to manage the updates and one must use the “DOS” command prompt to uninstall updates (or as Microsoft now refers to it as “Revert to an earlier version”).
You can read Microsoft’s instructions on uninstalling an update by using the following link:
Corrections
Now let’s make a few corrections and additions to their article!
Not Limited to Only Uninstalling Updates
First and foremost, I think it important to point out that while this command can be used to uninstall an update and revert back to any build of your choosing (probably it primary function), it can also be used to perform an upgrade.
Version/Build, Even Microsoft Can’t Keep Things Straight!
In the article, they mention that you have to execute a command similar to the one below
officec2rclient.exe /update user updatetoversion=16.0.xxxx.yyyy
and then later they explain
16.0.xxxx.yyyy represents the full version number
Yet, when you look at the Version and build numbers of update channel releases you’ll notice that the versions is actually a 4 character long number (1705, 1706, 1707, …). So in fact, the xxxx.yyyy does not represent the version number but rather the build number!
Whenever performing a reversion or upgrade, I’d urge you to take note of the current Version/Build No of your installation should the change not be beneficial and you wish to return back to the initial state.
How-to Update or Revert your Build No.
It is in fact very simple to do and takes but 2 command.
These are the steps to revert/update to a specific build number:
- Open a Command Prompt (as an administrator)
- Change into the folder that houses the officec2rclient.exe (the location/path may vary from the example provided below)
- Run the officec2rclient.exe /update command indicating the exact build number you which implemented
A Concrete Example
cd C:\Program Files\Common Files\Microsoft Shared\ClickToRun officec2rclient.exe /update user updatetoversion=16.0.8431.2094
That’s it! Simply replace the 16.0.8431.2094 with the build number you want installed on your machine. Remember to to disable automatic update should you wish to be frozen at this specific build.
Your Update Channel is Critical
Another thing to be aware of is that even though say 1708 is available in the current channel, but is not in the Deferred channel, if you are using the Deferred channel you cannot upgrade to 1708. You would first need to switch update channels to make that version/build available to your installation and then you could perform the upgrade.
What Build Number Do I Want/Need?
One of the biggest issues is figuring out which version/build you actually want to implement. To determine this, I have found that you have to use the following pages:
Especially the latter can be useful to see exactly what each build implemented. Typically, if you suddenly encounter a new issue, I’d determine my current build number and then try reverting to previous build number. If that didn’t work, then I look to go further back, and so on. Also, you could see if there was a more recent build number available, and first try performing an update (moving forwards is always preferable than going backwards, no).
Some Useful References:
