MicrosoftWhilst using the CDN solution with three different phased deployment rings configured it quickly became clear that the different schedules were not being adhered to. We had systems in Enterprise ring getting the update before those in our Initial and Pilot rings… Not good!
After working through this with Microsoft it appears the delay and random scheduling is apparently "by design", and 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 when following the standard configuration for CDN.
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 These values cannot be altered as they are controlled by Microsoft. 
However according to the Microsoft engineer the only way around this is to use the updatetargetversion value which apparently overrides the throttling configuration.
So it appears all is not lost, however this isn’t great given that this is meant to be a modern more secure service, just one that isn’t easily controlled.
Can Office36 update management be introduced to co-management and Intune in the same way as Windows Update for Business? This would be great to see and would enable us to move away from Group Policy… Just a thought.
Come patch Tuesday I will be testing this and will report back with another update (no pun intended) 
Richard
