How to manage Office 365 ProPlus Channels for IT Pros

Published Aug 08 2019 11:03 AM 81.6K Views

We’ve updated official guidance and published it as an article on Change the Microsoft 365 Apps update channel for devices in your organization. We recommend that you follow the steps in that article to change channels.”


The goal of the blog is to provide clarification around the mechanics on how Microsoft 365 Apps processes channel change requests.


To read more about Channels please see Overview of update channels for Microsoft 365 Apps


Ideally, minimizing the number of Microsoft 365 Apps packages reduces overall cost of ownership. Therefore, the next step is to develop a process where machines receive standard package placing them on Semi-Annual Enterprise Channel but dynamically move validation machines to faster channel such as Semi-Annual Enterprise Channel (Preview).

Change the update channel with ODT

Step 1: Before you begin, make sure the scheduled task "Office Automatic Update 2.0" is enabled on the client devices. This task, which updates the assigned channel, is a required part of managing updates for Microsoft 365 Apps, whether you use Group Policy, the Office Deployment Tool, or Configuration Manager (ConfigMgr).


Step 2: Download the latest version of the ODT (setup.exe) from the Microsoft Download Center.


Step 3: Create a configuration file that specifies the new channel name. In the example below, the   channel changes to Semi-Annual Enterprise Channel (Preview). For more information on channel names, see Channel attribute in the Configuration Options article.

<Updates Channel="Targeted" />

Step 4: Deploy the configuration file using your standard processes.

After execution of Office Deployment Tool (ODT), the Office Automatic Update 2.0 task will automatically run based on trigger definition in scheduled task. After that task runs, it detects the updated policy and updates the assigned channel. After the task runs again, it detects the new assigned channel and Office updates to a new build from that channel.

The Office user interface such as the "backstage", will not show the updated channel name until a build of Office from the new channel is installed.The Office user interface such as the "backstage", will not show the updated channel name until a build of Office from the new channel is installed.


Change the update channel with Group Policy

Step 1: Deploy your standard Microsoft 365 Apps package based on Semi-Annual Enterprise Channel


Step 2: Assign GPO to validation machine(s) or add policy registry key specifying Semi-Annual Enterprise Channel (Preview)


Using Office ADMX files, use Update Channel GPO to set Semi-Annual Enterprise Channel (Preview)


* Group Policy refreshes in the background every 90 minutes by default.  Use gpupdate /force to expedite.  Alternatively, add registry key manually to policy key

             HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate "updatebranch"="FirstReleaseDeferred"

Step 3: Allow Microsoft\Office\Office Automatic Updates 2.0 scheduled task to run

Group Policy will set registry keys, that’s all. Microsoft 365 Apps uniquely leverages a scheduled task named Office Automatic Updates to maintain product configuration including channel management. The name itself “Automatic Updates” can cause confusion for IT Pros in enterprise environments where System Center Configuration (ConfigMgr) is used to deploy updates. When you enable management of the Office 365 Client Agent setting in client settings (COM), rebranded in ConfigMgr client setting to "Management of Microsoft 365 Apps for enterprise", or via domain policy, software updates for Office 365 Client will be delivered only from ConfigMgr. The Office Automatic Updates scheduled task will fire based on default set of triggers, regardless if COM is enabled or not, or by manually running task you can compress time frame to validate change.



See 2:00 in Managing Office with SCCM (2019) video for more information, applicable for CDN update workflow.


Tip: List of Channels and respective URL identifiersTip: List of Channels and respective URL identifiers

CDNBaseUrl represents the channel where product was installed. If no channel was defined in unattend, Monthly is default selection.

Monthly Enterprise Channel
CDNBaseUrl =

Current Channel 

CDNBaseUrl =

Current Channel (Preview)
CDNBaseUrl =

Semi-Annual Enterprise Channel
CDNBaseUrl =

Semi-Annual Enterprise Channel (Preview)
CDNBaseUrl =

Beta Channel
CDNBaseUrl =

Tip: IT Pros can monitor several registry keys to validate change has occurred after scheduled task has completed. Registry keys of interest when monitoring can be found under the following key: HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration.  Editing key(s) should not be done directly and can lead to unintended consequences. Rather, monitor keys for desired outcome.Tip: IT Pros can monitor several registry keys to validate change has occurred after scheduled task has completed. Registry keys of interest when monitoring can be found under the following key: HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration. Editing key(s) should not be done directly and can lead to unintended consequences. Rather, monitor keys for desired outcome.                                                                                                         

UpdateChannel: This is the channel configuration “winner”.  This is dynamically managed by the Automatic Updates scheduled task and should not be edited directly.


In our example where we are using GPO to move Office 365 ProPlus to Semi-Annual Enterprise Channel (Preview), Office Automatic Updates scheduled task will discover policy key and then will flip UpdateChannel to new value, in this case from (SAC) to (SAC-T). Additionally, UpdateChannelChanged will be set to True. Upon next successful Office 365 Client update, UpdateChannelChanged will reset to False. The product can only accept one channel change request at a time with successful update as a prerequisite prior to accepting another change.


If you have completed steps above and channel change is still not being reflected, you may be blocked by timers referred to as “Discovery Period” or "DoFrequentUpdates". IT Pros may encounter this scenario during compressed time validation in lab scenarios.  During this period channel changes and Office downloads will not occur. (default timer period is 24 hours).  The Office logs in C:\windows\temp\%Computername%* will provide "Less than a day since last update run, just trying to apply!".  This is an example where timer is in scope.


After UpdateChannel has successfully changed, Office 365 Clients pointing to CDN will download latest build from faster channel. Office 365 Clients which have COM enabled for ConfigMgr integration will download newer build next time Software Updates Deployment Evaluation cycle runs based on configuration of Software Deployment within ConfigMgr. IT Pros can expedite testing channel migration by deploying desired build to validation collection (should be a build from Semi-Annual Enterprise Channel (Preview), use the Configuration Manager applet from control panel to perform Machine Policy Retrieval followed by Software Updates Deployment Evaluation Cycle.




Tip: Office 365 ProPlus behavior – slow to fast vs fast to slowTip: Office 365 ProPlus behavior – slow to fast vs fast to slow

Slower -> Faster (Example: Semi-Annual Enterprise Channel to Semi-Annual Enterprise Channel (Preview)

  • Client will always gracefully move forward when now available build number is higher.  For example, a client on June 2019 Semi-Annual Enterprise Channel with build version 1808 (Build 10730.20348) will move to Semi-Annual Enterprise Channel (Preview) with build Version 1902 (Build 11328.20318).  No other Administrative intervention is required, normal update process\workflow applies the change.

Faster -> Slower (Example: SAC-T to SAC)

  • In ConfigMgr managed environment where management of the Office 365 Client Agent setting (COM) is enabled, Office will not auto downgrade when channel is changed.  It will only move forward once build advertised is greater than what’s currently installed.  For example, Office client on Semi-Annual Enterprise Channel (Preview) build June 2019 Version 1902 (Build 11328.20318) will have to wait until Semi-Annual Enterprise Channel build number is greater to move forward such as July 2019 Version 1902 (Build 11328.20368).  Supported downgrade method is to re-run Office Deployment Tool (ODT) with desired build and channel.  Keep in mind during waiting period, Office 365 Client will not receive any updates including security.
  • In non COM managed environment such as default configuration CDN, we will downgrade your new version to match the Group Policy assigned.  

*Since we can’t do binary delta compression (BDC) the download will be larger.  As a result, network considerations should be considered when downgrading from CDN.  For example, Delivery Optimization should be enabled in Windows to allow clients to share content peer to peer.  This also can be combined with features in ConfigMgr such as Connected Cache for further optimization.



How does channel management work when Office 2019 is installed and GPO "Upgrade Office 2019 to Microsoft 365 Apps for enterprise" is enabled?

Some customers may have a need to have one factory image of Windows which includes Office 2019 and later upgrade a subset of machines to Office 365 ProPlus.  The steps outlined above still apply in terms of mechanics and how channel changes are processed.  The only difference is Office 2019 will initially have CDNBaseURL and UpdateChannel will reflect  First, the GPO above will set policy key.  Second, The Office Automatic Updates 2.0 scheduled task will flip the UpdateChannel to SAC (3114) by default and dynamically convert the product to Semi-Annual Enterprise Channel.  In short, Office 2019 is just an older version of Microsoft 365 Apps, so differences in content between the two products will download from CDN or from ConfigMgr Distribution Point depending on your configuration. (Size will be significant for one-time conversion).  For CDN, this process is automatic.  For ConfigMgr, IT Pro only needs to deploy latest build for to channel as software update to collection, just like any monthly "Patch Tuesday" process.  ConfigMgr will find build applicable and upgrade like any other Office update.  Licensing\Activation will switch from volume activation (KMS) to subscription based (Office Licensing Service).



The GPO "Upgrade Office 2019 to Microsoft 365 Apps for enterprise" only applies to Office Professional Plus 2019 not Standard.  The language of the GPO is "This policy allows you to upgrade volume licensed versions of Office Professional Plus 2019 to Microsoft 365 Apps for enterprise."


Why does this guidance differ from ConfigMgr page Change the update channel after you enable Office 365 clients to receive updates from Configuration ...?

Microsoft recommends customers leverage Group Policy to change Microsoft 365 Apps channels because its easier for IT Pros. Group Policy sets registry key under policy hive and Office Automatic Updates scheduled task to processes channel change.  The link above references CDNBaseURL.  Notice from the list below this is the 5th item evaluated for priority by the scheduled task.  As a result, if the first three priorities listed are not configured and CDNBaseURL doesn't match UpdateChannel, scheduled task will align them resulting in channel change.  This blog posting leads with Group Policy where link above requires a direct registry change through Group Policy Preferences or Compliance Item in SCCM.


1st Priority : GPO "UpdatePath" - HKLM\software\policies\microsoft\office\16.0\common\officeupdate!updatepath
2nd Priority : GPO "UpdateChannel" - HKLM\software\policies\microsoft\office\16.0\common\officeupdate!updatebranch
3rd Priority : "UpdateURL" or UpdatePath="\\Server\Share" HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
*4th Priority: UnmanagedUpdateURL - HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\UnmanagedUpdateURL
5th Priority
 : CDNBaseURL - HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration\CDNBaseUrl

*This value is new May 2020, official documentation

I installed Office initially on one channel and later used GPO to assign a new one, is it normal for the CDNBaseURL and UpdateChannel not to match?

It depends.  If a GPO is used to change channel, values will not match.  CDNBaseURL will reflect value when Office Deployment Tool (ODT) was run where Update Channel "winner" will reflect the GPO.  If ODT was used to change change channel, ODT will directly change CDNBaseURL to value defined in Config.XML and if priority order above aligns, UpdateChannel value will match.


I tried to assign Monthly Enterprise Channel (MEC) to a collection of machines running old builds of Office and operation failed? Why?

Since Monthly Enterprise Channel is a new channel, this information was backported to all channels so older clients would be informed of change.  In general, Semi-Annual Enterprise Channel needs to be at least March 2020 to in order to move to MEC using group policy.  Alternatively, use the Office Deployment Tool to change channel.


I deployed Microsoft 365 Apps for Windows 10 app from the Intune wizard, does the guidance above apply to me?

No. Customers who deployed Microsoft 365 Apps from Intune wizard are using a feature called OfficeCSP. (super important to understand) What does that mean? The Intune deployment of Office will stamp in the registry a copy of the XML based on the answers provided in the wizard. While the deployment is active in Intune, the Office CSP will continue to check on frequent schedule if Office installation matches the registry entry to ensure no deviation exists. If a deviation is detected, Channel change or Office app\language is installed\removed, Office CSP will re-run Office Deployment Tool using SYSTEM to align with configuration defined within Intune. Therefore, the supported methods to change the channel for OfficeCSP managed installations are as follows:


  1. Simply edit the existing Microsoft 365 Apps for Windows 10 app from the Intune wizard and change the existing channel to the desired channel. Office CSP will continue to retry to execute Office Deployment Tool in the background when Office applications are not running. It’s expected to “settle” of a period of time and report 17006 ERROR_SCENARIO_CANCELLED Blocked update by running apps -Failure which just means Office is open by the end user and therefore change was blocked; retry later.
  2. Delete the existing Microsoft 365 Apps for Windows 10 app from the Intune and create a new one with desired settings.

If Office CSP doesn’t provide required flexibility, consider creating an application within Intune to run the Office Deployment Tool with Configuration.xml to align with traditional on-premises type deployment aligning with original guidance above.  



Using Intune ADMX or Settings Catalog (MDM) to change channel for Office CSP based installation of Office is not supported.  Supported options are listed in bold above.


Change Log:

7/22/2021  Added FAQ section to include Intune\OfficeCSP scenario.

12/2/2020  Added reminder about specific Office 2019 SKU which will transition to Microsoft 365 Apps


This blog post is brought to you by Dave Guenthner, a Senior Premier Field Engineer and “ProPlus Ranger” at Microsoft. Feel free to share your questions and feedback in the comments below.

Senior Member

If you downgrade from a monthly channel to a semi-annual channel, does this mean you are going out of support?


No.  Support life cycle is defined by the channel itself.. coming from another channel doesn't matter.  For example:  If you are on Monthly 1907 11901.20218 and moved client to slower Semi-Annual 190211328.20392, this SAC Version would stay supported until September 8, 2020.  (Of course, need to deliver the SAC Extended builds for security each month but supported as if client was installed on SAC)

Update history for Office 365 ProPlus (listed by date)


Occasional Contributor

Thanks for this great article. I am having an issue where moving from UNC path updates to SCCM updates does not seem to change the UpdateChannel property in the registry so I can't migrate.


My client settings below:


PS HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration> Get-ItemProperty .

OfficeMgmtCOM                  : True
VersionToReport                : 16.0.9126.2259
ClientFolder                   : C:\Program Files\Common Files\Microsoft Shared\ClickToRun
ClientVersionToReport          : 16.0.9126.2259
WatcherInterval                : 3600000
PipelineServerName             : ClickToRun_Pipeline16
PackageLockerPath              : C:\ProgramData\Microsoft\Office
ScenarioCulture                :
InstallID                      : 26CB5AE4-2F17-449F-9338-13A0177C5AC0
Platform                       : x64
InstallationPath               : C:\Program Files\Microsoft Office
ClientCulture                  : en-us
CDNBaseUrl                     :
AudienceId                     : obfuscated
AudienceData                   : Production::DC
None.MediaType                 : Local
O365ProPlusRetail.MediaType    : Local
SharedComputerLicensing        : 0
UpdatesEnabled                 : True
Activate                       : True
O365ProPlusRetail.ExcludedApps : access,groove,onedrive
StreamingFinished              : True
ProductReleaseIds              : O365ProPlusRetail
RSODReset                      : False
O365ProPlusRetail.OSPPReady    : 1
UpdateChannel                  : \\previousuncpath\updates
UpdateChannelChanged           : True
O365ProPlusRetail.TenantId     : obfuscated
O365ProPlusRetail.EmailAddress :
PSPath                         : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Click
PSParentPath                   : Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Click
PSChildName                    : Configuration
PSDrive                        : HKLM
PSProvider                     : Microsoft.PowerShell.Core\Registry


And the policy settings:


PS HKLM:\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate\> Get-ItemProperty .

updatebranch        : Deferred
officemgmtcom       : 1
preventteamsinstall : 1
setbitsasprimary    : 1


I have repeatedly ran the Task as below and the UpdateChannel is stuck on the previous UNC value.

My task though is named "Office Automatic Updates" and not "Office Automatic Updates 2.0" since I am on version 1803 still.


Let me know if I can manually modify that registry entry (possibly delete it and re-run the task or change to a known CDNUrl one) so updates can happen.


Thanks a lot!

Occasional Contributor

I tried changing the UpdateChannel to the same value as CDNBaseUrl and now it works properly.

So it seems my Task is not updating the values properly and most possibly because it's a very old Office build?





Senior Member



thank you very much for your precious reply and the additional information on DO.

I noticed that while Office is updating via SCCM (no content lives on DPs), all files are saved under ccmcache. Is this normal and does it "count" against total size of ccmcache size? Other SUP updates do not count against the ccmcache quota size.





@AlexandrosAP See the FAQ section of my other blog posting where this is answered "If the download is supposed to only contain deltas and stage to C:\Program Files\Microsoft Office\Updates\Download, why in my environment is it staged in C:\Windows\ccmcache and full build? (~2GB)..."

Understanding Office 365 ProPlus Updates for IT Pros (CDN vs SCCM)

Occasional Contributor

Thank you Dave!




Senior Member

Hi @Dave Guenthner 


Just to clarify here, when we are using the ODT to change the channel, are we including *only* the following in the configuration file?


<Updates Channel="MonthlyEnterprise" />

In this case, I'm trying to move from the Monthly Channel to the Monthly Enterprise channel. ODT runs, but nothing happens on the screen, and the channel doesnt change in the client UI or in the registry. I'm just launching the ODT with a /configure switch and pointing to the configuration file. What am I missing here? I know that changes don't show in the UI right away, but it's not showing in the registry either. the CDN URL still displays the Monthly channel. What am I doing wrong here?





@EDubs Try the config.xml below.  

but nothing happens on the screen, and the channel doesnt change in the client UI or in the registry

We don't expect any UI which is desirable as we don't want to disturb end user.  You're right the backstage in Office displaying channel name will not reflect MEC as channel assignment until next successful update. The ODT will change the CDNBaseURL value.  Later, within 24 hours the Office Automatic Scheduled task will evaluate the priority order listed in FAQ and stamp the "winner" in UpdateChannel so they both should match


Note: Since you are moving FASTER->SLOWER, without a GPO the client will have to wait until the build on MEC is newer than currently installed Monthly build.


<Updates Enabled="TRUE" Channel="MonthlyEnterprise"/>
<Display Level="None" AcceptEULA="TRUE" />


Senior Member

Hi @Dave Guenthner 


  Thanks for the quick response. In regards to the Updates Enabled=True switch, which update is this referring to? Is this the Office Automatic Updates 2.0 scheduled task, or is this Office Updates (patching)? We currently disable Office Updates because we use a 3rd party product for that, but Office Automatic Updates 2.0 is enabled on the clients. What I'm trying to do here is test Monthly Enterprise with the goal of just turning on Office Updates.


If I'm reading your response correctly, once I run the ODT, I wont see any change on the client for 24 hours, but after 24 hours the CDNBaseURL value at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration should update to Is that correct?



Senior Member

Hi @Dave Guenthner 


   I just tested this, and it works exactly as you've outlined. On my clients Updates Enabled is set to True, so really, I think the only difference in the configuration you provided was the Accept EULA. I didn't have that in mine, so I guess that's why it wasn't working? (I am using the latest ODT client) If the accept EULA is required, can we add that to the channel change example templates? As far as I can tell, that's what was throwing me off. I appreciate you taking the time to provide detailed responses here. It's been super helpful.


Have a great day!


Using Microsoft Defender ATP Advanced Hunting, is there a script that can be run to report on the service channels broken out by device? Would be nice to reveal what the service channel selection is per Excel, Word, Outlook, and PowerPoint etc. 


If not, what other ways can we collect this information for management?



@Means2anEnd Microsoft Defender ATP is not a "management tool" I think ConfigMgr would be a better option.  A few options, you can use inbox Office 365 Client dashboard which shows clients by channel driven by the hardware inventory class “Office 365 ProPlus Configurations”.  Another option is to use ConfigMgr CMPivot feature using:

registry('HKLM:\software\microsoft\office\clicktorun\configuration') | where Property == 'updatechannel'


Finally, you could create a Compliance Item (CI) and target a collection looking for UpdateChannel so you could monitor collection is indeed on the channel you desire.

Established Member

What options are there for Microsoft 365 Business customers, where group policy is not supported? I'd like to move my users from Semi-Annual to Monthly Enterprise. Do I need to set the registry keys under Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\Configuration to point to the URL of the channel I want to use?


@StephenOtt Use Option #1 ODT.

<Updates Channel="MonthlyEnterprise" />


No user interruption etc.  Just run ODT and then allow a few days and client will move gracefully to Monthly Enterprise.

Established Member

@Dave Guenthner Thanks for prompt reply. By fiddling with registry, I was able to jump to the Current channel. I have just run ODT using the config you provided. Assume I will need to wait until Enterprise Monthly surpasses Current before it'll update. 

Senior Member

Hi @Dave Guenthner 

I’ve been working through my orgs switch from traditional SCCM based O365 Updates to CDN and I’ve seeing some “strange things”


I’ve setup a single GPO using preferences to set the registry keys for four different deployment rings: Initial, Pilot, Live, Early Adopters.. the registry values can be seen in the image attached.

My first question is regarding Microsoft’s release of the updates on the CDN, are they available on the CDN straight away? In some cases for systems in the initial deployment ring we are not seeing anything update until the Monday after patch Tuesday, is this expected?  


Can you seen any glaring issues with the registry config within the image?


I’m seeing some systems with the Live deployment ring configuration update before those with the Initial & Pilot deployment configuration , have you seen this happen before?


Is the deferupdatedays 0 configuration supported? I have seen some articles that state it is..


Many Thanks


Senior Member

If you're using ODT to change the channel, is it also valid to add a ForceAppShutdown=False switch just to make sure the client isnt set to close apps automatically when updating? So it would look like:


<Updates Enabled="TRUE" Channel="MonthlyEnterprise"/>
<Display Level="None" AcceptEULA="TRUE" />
<Property Name="FORCEAPPSHUTDOWN" Value="FALSE" />


@EDubs Yes, although if you omit it will assign default value of False.  In this case, we certainly do not want to interrupt user, just make change silently.

Senior Member

@Dave Guenthner  thank you for your response.. I have now opened a support case and will see where we end up.



New Contributor

Does anyone else have an issue where you need to manually remove KMS registration of a office 2019 installation when you want to upgrade to 365 with gpo setting?


I had the strange result where the build number showed 1908 but everything else was still "ofice 2019". Only after I manually removed the kms activation with


cscript 'C:\Program Files\Microsoft Office\Office16\OSPP.VBS' /unpkey:xxx

the activation of office 365 fully completed.

Senior Member

Hi @Dave Guenthner  


A quick update.. the delay and random scheduling I was experiencing is apparently "by design", it is caused by Microsoft's global throttling policy.   


Throttling configuration is randomly configured by Microsoft on a per-device basis. This essentially renders the phased deployment ring approach useless with the standard, well documented configuration. :facepalm:


In the snippet below taken from the log files you can see the MROThroVal=5 and the MachineThroVal=177. This essentially means the update will not download until the MROThroVal is the same or greater than the MachineThroVal.. In my case this took five days :sad: 




According to Microsoft support the only way around this is to use the updatetargetversion value which will apparently override the throttling configuration.


So it appears all is not lost..


I will be testing this come patch Tuesday and will report back with another update (no pun intended) :smile:




Senior Member



That's an interesting find, and, yes, it *would* make phased deployment kind of useless. After all, what's the point of a test group if some are delayed by 5 days? The update target version option might work, but then you're relying on group policy and network connectivity, and with everyone working remotely these days, that's difficult to manage. I would imagine that there's a better way. I just dont know what it is.

Senior Member



The more I think about this the more it bugs me...


I agree that there has to be better solution. I hope there will be something coming to Intune in a same way to Windows Update for Business and it's deployment rings. That would make more sense to me. I'd best see if there are any jobs going on the O365 team in Redmond - lol


Go modern management & improve security...Hmmmm,  just at a randomized pace with an "old shcool" shim to provide a level of scheduling which most businesses/large enterprises require from the outset. 


I'm lucky in my scenario as direct access provides connectivity for GPO etc. Just glad we aren't further down the modern path with internet only devices as this would have caused a significant challenge. 


Winge over, now to see how Windows Update for Business goes.. 



Senior Member

@RichardStephens How does the process differ with Windows updates for business? I'm in a situation where most of my workforce is now remote and I can't patch office without network connectivity. I'm leaning towards just letting O365 patch itself through the CDN, but not having control over the timing, and testing of patches (even if it's just Office) makes my skin crawl.

Senior Member



First let me talk about the Office365 updates through the CDN... 


The issue I encountered recently was exactly what you have described, however working with Microsoft and identifying the updatetargetversion setting apparently means that the custom schedules will apply as expected. Right now this is unconfirmed as I am waiting on for next week patch release to confirm.  


The design I have implemented is kind of a "halfway house" on the journey to modern management. We are getting the updates from the CDN but using GPO/Policy Preference and AD Groups to deploy the config to the the endpoints, and SCCM and Power-BI dynamic reporting. Ultimately I want to use Azure AD Groups and Custom log analytics to provide the reporting, but I will tackle that at later date. 


The following  shows the current design: 



1) System is added to Office365UpdatePilotRing Active Directory Group

2/3) Office365Updates-Global Group Policy is applied and the Pilot ring configuration is set through policy preferences and item level targeting filtered by the Office365UpdatePilotRing AD group

4) Office Automatic Updates 2.0 runs and the system checks for and installs the update according the scheduling configured through the policy preferences

5) System runs a custom script to determine if office updates have been installed within the previous 24 hours, if yes then an SCCM hardware inventory scan is triggered to update V_GS_InstalledSoftware within the SCCM DB

6) Power-BI dashboard synchronizes through the on-premise gateway and reporting is updated dynamically


Configuration being applied through the policy preferences (there are a two custom keys being written for reporting purposes) : 


Including the updatetargetversion will enable the different scheduling you can see in the above image. 


I'm still testing Windows Update For Business but I hope we don't have the same scheduling issue.

Does this help? 


Senior Member

Hi @Dave Guenthner 


Am I right in thinking Delay downloading and installing updates for Office = deferupdatesdays regsitry value?  If yes then I'm afraid this doesn't work as you say and the Office Product team advised me that we have to use the updatetargetversion as the only way to bypass the throttling.






@RichardStephens I double checked with Dev on this important point and I was wrong.  The GPO "Delay downloading and installing updates for Office" simply blocks all update activities until delay has expired.  Once Delay has expired throttle IS considered.  This is indeed why updates are happening at time which you find unexpected.  The Dev understands this doesn't meet your requirement and as a result I will file a Design Change Request (DCR) on your behalf so throttle is ignored.  Please refer Support Engineer to me and we can add your account\seats etc. to request for consideration.


My apologies for initial incorrect statement.  You must use TargetVersion as instructed in current state.  #sigh



Senior Member

Hi @Dave Guenthner 


Thanks for your continued care and feeding of this thread. There's a TON of useful information here that I havent been able to find anywhere else.


In my case, the biggest hurdle is that in this increasingly remote-worker world, group policy is no longer a viable method of managing anything. Because of things like Teams, Sharepoint, and OneDrive, the only people that connect to the VPN anymore are those of us who've been around long enough where it's just ingrained. Even before COVID, the phrase "What's the VPN" was commonly heard around the office. Now that the majority of the workforce is remote, 90% of people are getting by just fine without access to corporate networks, which makes reliance on GPO that much more difficult.


One thing that might help is if we could manage some of these policy settings through the Office deployment tool. I can't get group policy to many of my endpoints, but I am able to push software to them, even if they're off network. COVID has definitely escalated all of the remote worker timelines, but I feel like the writing has been on the wall for network-based group policy for some time now. A cloud-based solution is really what's required. I'm not sure to what extent azure addresses this.

Senior Member



For some reason my original reply disappeared so I had to re-write:facepalm:


This is how I’ve configured Office365 CDN with the aim of achieving phased schedules..

I’m using a “halfway house” mixing modern management and traditional IT to delivery this. CDN for the modern element and GPO for the traditional. Eventually I want to use pure Azure groups etc.  to deliver the content but that will have to wait a little longer.

Below you can see a diagram of the solution.



1) Laptop is added to the O365UpdatePilotRing AD Group

2/3) The Office365Updates-Global GPO is applied to the laptop and the Pilot Ring configuration (including scheduling) is applied to the system through ILT on the GPO Registry Preferences (ILT filtered to the O365UpdatePilotRing AD Group)

4) Laptop initiates the updates process through the Office Automatic Updates 2.0 scheduled task.

5) Updates are downloaded and installed per configuration applied through the GPO (including scheduling)

6) Laptop runs a custom script to determine if office updates have been installed within the previous 24 hours, if they have then a SCCM hardware inventory scan is triggered to update V_GS_InstalledSoftware within the SCCM DB

7) Power-BI dashboard synchronizes through the on-premise gateway and reporting is updated dynamically and quickly to provide near real-time insights


I use preference order processing to ensure the ring configuration is applied correctly, below you can see the registry configuration per registry preference group (some custom Office365UpdateRing keys are included to provide granular reporting):



On the guidance received through premier support and the product group I now include the updatetargetversion key in an attempt to bypass the throttling and achieve the phased deployments: Initial, Pilot, & live.


I'm still in the early phase of testing Windows Update For Business and I should know more shortly :smile:


I hope this helps.

Senior Member

@Dave Guenthner 


Thanks I'll forward this onto the engineer and ask them to reach out to you.  


PS. Snipped the promotion comment and sent it to my boss :cryingwithlaughter:

Thanks again





@EDubs Microsoft understands more than ever CDN offering needs to be best in class and Office Engineering is working on providing additional controls\features in the future.  (all I can comment about that for now)  Based on your description, if you have ConfigMgr using a CMG would unlock a lot of options or Intune for co-management.  Crazy times and we're all racing to adapt.  Thank you for feedback on blog.

Senior Member

@Dave Guenthner On the topic of the randomized delay of downloads from the CDN, do you know what the delay range is? I just need to set expectations if I'm going to propose patching Office from the CDN. Assuming everyone is on the Monthly Enterprise Channel, which if I recall, is the second Tuesday of each month, from the time that the patches become available, I just want to give a range for when they'll download and patch. Thanks!


@EDubs Its a fair question but a difficult one to answer.  The throttle is dynamic based on telemetry\signals we receive from our audience.  Typically, when a new build is released, very conservative number is initially used and once confidence based on signals are verified, volume is turned up to get everyone up-to-date in a controlled manner.  I would ensure UpdateDeadline is set, for example 5 and I think you'll find machines are updated by your compliance deadline.  Again, we're working on providing additional tools for CDN experience in the future but for now, I'd recommend moving subset of machines over to CDN and then monitor rollout.  Build confidence using CDN method and then slowly turn COM off across your real estate.  Remember, this is how Office was designed and works for hundreds of millions every month, its just new to many Enterprise customers.

Senior Member

@Dave Guenthner  & @EDubs 


Scheduling bugs aside what I can say is that servicing Office 365 Updates through the CDN has massively (i hate to say it) "flattened the curve" of legacy instances within our enterprise. I cannot fault the reliability of the upgrade mechanism itself it does exactly what it should.  


Another plus has been the lack of negative feedback from our businesses regarding the user experience. It is a great improvement over the old SCCM notifications, and I love the fact that most don't even see the notification as it's updated seamlessly :smile:


If we could see a high-level log file containing key status points that would be awesome to. The logs at the moment contain way too much "noise" and are a headache for techies to scroll through.  If this and the throttle bypass can be sorted then I would be one happy customer! 


Have a great weekend



Senior Member

@RichardStephens Glad to hear it. I have many legacy instances in my environment, and that's exactly what I'm hoping to fix by patching through the CDN. My challenge is that we currently use a third party platform to patch, so Office updates are disabled by GPO. Changing that means having to tell a couple thousand people to connect to the VPN, unfortunately. I just wish the ODT had more functionality and control so that we weren't so reliant on network connectivity. I appreciate your feedback, it's great to hear other Enterprises having some success through the CDN. Have a great weekend!

Senior Member

Hi @Dave Guenthner 


Testing today has shown that adding the updatetargetversion not only seems to bypass the throttling but also bypassing the scheduling configured in the deferupdatedays and updatedeadline registry keys.  


Once I set the updatetargetversion to 16.0.12527.20880 like this: 


I logged on to a system which had the Live configuration applied e.g. defer the updates for 7 days.. I ran the Office Update Scheduled task and Office updated itself immediately :facepalm:  


So throttling is now bypassed which is great, but so is the scheduling configuration resulting in the endpoints downloading and installing the update immediately, which is bad :sad: 

Was this the expected outcome? Did I miss this in the previous posts? 









Senior Member

Firstly I would like to say this is a great article, it has helped me immensely.


We have recently upgraded to Win10 and Office 365 (Semi-Annual) managed by SCCM.

I need to now set up some devices with Office 465 (MonthlyEnterprise).

Have added the new ADMX to accomodate the new Channel Names, created GPO to change to UpdateBranch to MonthlyEnterprise.

The GPO works as expected, but when the Office Auto Update 2.0 task runs it changes the UpdateChannel value to (Current Channel) instead of (MonthlyEnterprise).

Have confirmed no other GPO is affecting this.

Any idea where the Office Auto Update 2.0 task gets these values and why it wouldn't be recognizing the UpdateBranch value?


@D_Staples Thanks.  Can you please private message me the export of following registry locations from reference machine in state?

HKLM\SOFTWARE\Policies\Microsoft\office\16.0\common\officeupdate and HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration


Senior Member

Hi @Dave Guenthner  I think I have discovered the cause.

We are running 1902 Semi-annual Channel (build11328.20438).  This is the version that was deployed when we upgraded to Win10 earlier this year and it is the one I having issues with.  This version will correctly change to all the Channels except for MonthlyEnterprise.


If I install 2002 Semi-Annual Enterprise the Group Policy setting UpdateBranch of MonthlyEnterprise is recognized and the UpdateChannel value is updated correctly.


Appears to be some issue with 1902 version.


@D_Staples Yes.  I believe the issue is because the knowledge of MEC as a channel wasn't backported to SAC until March of 2020.  So if the build is from Oct of 2019 it won't understand channel assignment.  For those machines down-level, best to deliver latest SAC build to update them and then move to MEC.  Thanks for feedback, I've added an item to FAQ for this one.

Senior Member

@Dave Guenthner Rather than updating to the latest SAC, then updating to MEC, couldnt you just use the latest ODT to change the channel? Or does the Office client itself need up to date enough to be "aware" of the MEC?


@EDubs Yes, that's been added to FAQ at bottom of article including both options.

Senior Member

@Dave Guenthner you are correct, it appears the Office Client needs to be a build after the new Channel Names were released.  I updated 1902 to build  11328.20644 and the MonthlyEnterprise GPO setting works.  


@D_Staples Thanks for sharing update.  Have a nice weekend.

Senior Member

Does anyone know a good source for trying to parse O365 update logs located in C:\Windows\Temp? I'm testing out Office updates through the CDN with a group of users. We enabled office updates on an OU, put the devices in it, and asked the users to connect to the VPN to get the group policy update. Roughly half of the clients have updated. It's been about 10 days. I'm looking through the logs to see if I can determine why some wont update. The first error that pops out is "Failure sending DMS web request." followed by "OException encountered retrieving TargetAudience". For what its worth, if I look in Program Files\Common Files\microsoft shared\ClickToRun\Updates on the client, I see a folder with the current version of Office, but it's empty. I figure the device has received the Gpupdate but it doesnt seem to be downloading the update, while others have. Any ideas on where to start troubleshooting this one?




Not applicable

Hi @EDubs 


Here is an article from MS to enable ULS logging to diagnose installation and patching issue. Source:


I've never come across this error so won't be able to help with this message "Failure sending DMS web request." followed by "OException encountered retrieving TargetAudience"




@EDubs Use Notepad++ and use FindinFiles feature where you point the search to folder where all Office logs have been collected (search all logs at one time.)  Search for strings like 'unexpected' or 'COM Enabled'.  Remember, if you were using SCCM and are moving to CDN the GPO itself doesn't deregister COM.  It requires a restart of the Microsoft Office Click-to-Run Service in order for the scheduled task Automatic Office Updates to perform update.  Finally, the System account needs access to CDN or the User must be interactively logged on in order for user impersonation to succeed.  Pick a machine, call CSS, they should be able resolve very quickly as likely configuration issue.

Senior Member

Hi @Dave Guenthner 


Prior to turning the GPO on, I pushed out a channel change with the ODT and the following parameters:


<Updates Enabled="TRUE" Channel="MonthlyEnterprise"/>
<Display Level="None" AcceptEULA="TRUE" />


I just checked one of the laptops that hasnt upgraded, and used Notepad++ to search 34 log files, and there is nothing found for COM Enabled. What I do see when I search for "unexpected" is http transport errors


"10/02/2020 20:32:52.829 OFFICECL (0x12c0) 0x8d4 Click-To-Run Non Task Error bqyxs Unexpected DmsClient::GetTargetAudienceData , "SessionID, "GeoID": 244, "Ver": "16.0.13029.20534", "C2RClientVer": "16.0.13029.20342", "ErrorCode": 30183, "ErrorType": "HttpTransportError", "AppVErrorSource": "DmsClient::GetTargetAudienceData", "ErrorMessage": "HttpTransportError (DmsClient::MakeDmsWebRequest: {message:'request-Error:0x80072ee7)", "ErrorDetails": "Failure during processing of DMS Target Audience request."} 


10/02/2020 21:28:31.525 OFFICECL (0x12c0) 0x8d4 Click-To-Run Non Task Error bqyxs Unexpected DmsClient::GetMroDataForFFNv2 {"MachineId": "", "SessionID": "", "GeoID": 244, "Ver": "16.0.13029.20534", "C2RClientVer": "16.0.13029.20342", "ErrorCode": 30183, "ErrorType": "HttpTransportError", "AppVErrorSource": "DmsClient::GetMroDataForFFNv2", "ErrorMessage": "HttpTransportError (DmsClient::MakeDmsWebRequest: {message:'request->sendStream' requestUrl:' =O365ProPlusRetail.16_x-none_en-us&osver=Client|1 , Error:0x80072ee7)", "ErrorDetails": "Failure during processing of DMSv2 request."}


(I deleted the audience and machine ID info from the errors)


These errors are repeated in the logs on this device. I assume that it's attempting to download the updates and failing, since I can see an empty folder with the appropriate update version on the device



I just cant tell why it's failing to download the updates. Other devices are doing this as well, but roughly half have had no issue. These would be a mix of devices that are physically on the network, on a home network, or on the VPN




@EDubs I think question is too complicated for blog forum.  I recommend you target a machine where you have access and full control where issue can be reproduced and give MS Support a call to help investigate.  The error you shared, WININET_E_NAME_NOT_RESOLVED may mean the proxy configured for SYSTEM or User cannot access these endpoints below.

One option is to collect a Fiddler in SYSTEM\User and see if traffic is being blocked or cannot access OfficeCDN location to download content.

Version history
Last update:
‎Jul 23 2021 04:12 AM
Updated by: