First Published 27 June 2026

Background

Over the past year or so, there have been several bug reports from users who are on the Current Channel (CC) but have been updated to Current Channel Preview (CCP) builds.
Those users have also been unable to update to newer Preview builds which contain the bug fix.

It was originally assumed that those users had switched to Current Channel Preview by mistake. However, as further reports came in, including both current and former MVPs, it seemed more likely that there was a flaw in the Current Channel update process.

Most recently this issue arose with version 2606 where there were major performance issues with significant slowdowns in complex forms and repeated redraws in continuous subforms.
For more details, see item h) in Access Bug / Issues Summary - June 2026

This was a serious bug and the Access team acted promptly, releasing a fix within a few days in both CCP version 2606 20131.20052 and Beta Channel version 2607 20215.20000. The bug did not affect CC version 2605. Affected users in the insider channels installed the fixed builds and were happy again.

This should have been the end of the story, but then further reports of the same bug came in from several users on the Current Channel. For example, see:
•   Comments by @reggied in Access World Forums thread Access 365 very slow - see post #40 onwards
•   Comments by Mark Mauger in MS Tech Community Access VBA performance dramatically slowed since June Update

In both cases, it was reported that Current Channel users were on version 2606 build 20131.20044, even though that was a CCP build. The reasons have only just been clarified by Microsoft.



Feature and Update Validation Processes

In the past couple of days, Microsoft has confirmed that a small subset of Current Channel (CC) users are placed on a 'pre-release' Current Channel Preview (CCP) build before it is rolled out properly to CC. This is done as a deliberate policy rather than a flaw in the Channel update process as many experienced Access users including myself originally assumed.

The background to this policy is explained in this (undated) Microsoft blog article: Feature and update validation in the Microsoft 365 Apps channels. The article states:

Before features and code changes reach the broadest set of Microsoft 365 Apps users, Microsoft validates them through a progressive series of update channels. As part of this process, Microsoft conducts controlled experiments and validation activities on select channels to ensure that updates meet quality, performance, and reliability standards.:

This experimentation is a key part of how Microsoft delivers continuously improving experiences while minimizing risk. By testing changes with smaller audiences first and measuring real-world impact, Microsoft can catch issues early, iterate on feedback, and make data-informed decisions before broadly releasing updates.

I would STRONGLY recommend that everyone reads the Microsoft article and carefully considers its implications.

It has always been emphasised that users on the two insider channels, Beta and Current Channel Preview, were testing experimental builds with a greater chance of bugs.
Indeed, Microsoft has always advised that insider channels should not be used for production use.
Feedback from those on insider channels is important to Microsoft as it is used to reduce the risk of bugs reaching the production channels.

However, this article now makes it clear that the Current Channel is also subject to experimentation.


The article goes on to describe the different types of experimentation used:
a)   A/B experiments - these compare existing behaviour to proposed new behaviour. Subsets of users on the same channel will receive different experiences
b)   Limited feature exposure - new features are rolled out slowly to a subset of users in participating channels
c)   Production release build candidate validation - before a build is promoted to a broader channel, Microsoft validates it by deploying it to a subset of users on the Current Channel.

The first two items will already have been familiar to most developers and MVPs.
Phased rollouts are understandable though these can cause issues when clients receive a feature several days or even weeks before developers on the same channel.

However, the final item was not known about until a couple of days ago and has caused some significant concerns amongst several experienced developers including MVPs.



Implications for Developers and End Users

It is likely that the final part of this process normally works well with users being unaware it has happened.
In such cases, the only issue may be possible confusion about which channel users are actually on.

However in the case of the recent performance issue with version 2606, the CCP build that was deployed to a small number of CC users still contained the bug. Those users were unable to update to a fixed version as there was no newer build in CC at that time. The affected users were effectively 'stuck' although the bug had been fixed in other channels over a week earlier.

It would have avoided many problems if the newer fixed CCP builds had in turn been rolled out to affected users in CC but that didn't happen for almost 10 days.

An online Office repair wouldn't have helped in this case as affected users would have again ended up with CC version 2606 build 20131.20044

There were other solutions available but those mainly involved changing channels or editing the registry. For example:
•   Using OfficeC2RClient.exe to roll back to an earlier Current Channel version 2605 build which didn't have the bug. For details, see Roll-back to previous versions of Office
•   Switching to version 2605 in the slower Monthly Enterprise Channel
•   Switching to version 2606 in the faster Current Channel Preview which had already been fixed
•   Using the UpdateToVersion registry fix described in my article: Fix Blocked Office Updates

However, depending on the Office edition, some channels may not be available. Consumer editions do not include enterprise channels. Enterprise editions do not have the insider channels.
Not all users are willing or able to apply rollbacks. Similarly many are reluctant to switch channels, especially to an insider channel.
In addition, many users will be concerned about editing the registry or such actions may be blocked by their employer.

Thankfully, the current issue has now been resolved with the latest official Current Channel update to version 2606 20131.20090 released 2026-06-25.


At the time of writing, this is also the latest build in Current Channel Preview where it was released one day earlier! Ongoing confusion!



Recommended Action

The Microsoft blog article clearly states that the only channels NOT subject to experimentation are Monthly Enterprise Channel (MEC) and Semi Annual Enterprise Channel (SAEC).


However, SAEC is being 'retired' in July 2026! This will leave MEC as the only channel receiving fully validated, stable updates.

I would now recommend that all users running production databases should be on the Monthly Enterprise Channel rather than the Current Channel.



Postscript

The vast majority of bugs are discovered by the Access team themselves or by those on the two insider channels, and fixed well before they reach the default Current Channel.
The relatively few bugs that do reach Current Channel are similarly promptly fixed with the result that the Monthly Enterprise Channel is largely bug-free.

If there is a significant shift of users away from CC and onto MEC, there could be a greater chance of some bugs not being discovered earlier and affecting the Monthly Enterprise Channel.

I am concerned by the use of ‘Production release build candidate validation’

Those of us who choose to go on Beta / CCP are aware of the increased risk of bugs.
However, those on CC do not sign up to receive CCP builds (even those displayed as being CC) and are not warned that this may happen.

I realise this policy has been decided by the wider Office team, but I see almost zero benefits and lots of problems with this additional subset in the rollout process.
In this particular case, the problem was exacerbated by the fact that later CCP builds with the fix didn’t rollout to affected CC users for another 10 days.



Feedback

Please use the E-Mail button in the contact form below to let me know whether you found this article useful or if you have any questions.

Please also consider making a donation towards the costs of maintaining this website. Thank you

Colin Riddington	Mendip Data Systems	Last Updated 27 June 2026

Return to Access Blog Page

Return to Top