Microsoft 365 Message Center and M365 Change Explained with Brian McGough, Principal Program Manager

Prefer audio?

Who should listen: Microsoft 365 service owners, tenant admins and change/adoption managers who track Message Center and the Roadmap, particularly those in regulated environments or government clouds who need to plan for the frontier/standard/deferred release model.

Guest: Brian McGough — Principal Program Manager, Microsoft 365 Change Management, Microsoft

Brian McGough has run Microsoft 365 Message Center since 2018 and leads change communications across the M365, Dynamics, Windows and Intune posting teams. He explains the operational machinery behind Message Center and Roadmap, the shift to a frontier/standard/deferred release model, and the new MCP servers for change and service health data.

Many thanks to Landis, sponsor of this episode.

Key insights

• Message Center volume has gone from roughly 50 posts a month in 2018 to 225–250 a month for M365 alone, with about 80 posts sitting in queue and 450–500 live at any one time; a typical tenant sees in the order of 2,500 messages on the current cadence. ▶ 3:40
• Posts are no longer 'one and done' — one person on McGough's team does nothing but chase PMs on every single post to confirm whether rollout has actually started or dates have shifted, and the same follow-up now feeds Roadmap updates for items announced in Message Center. ▶ 5:11
• Four separate teams publish to Message Center — M365, Dynamics/Power Platform, Windows, and Intune/Security. Intune runs through the M365 tooling and publishing channel, so its posts appear in the M365 bucket despite being a different team. ▶ 6:43
• Targeting is done three ways: by cloud (Worldwide, GCC, GCC High, DoD, the US Sec/US Nat sovereign clouds and the 21Vianet China cloud), by SKU (E5, F1, Copilot Chat versus premium M365 Copilot, Teams Premium and other add-ons), and by explicit tenant ID lists — which is how prevent-or-fix and config-change posts are delivered. If you received one, there is a specific reason your tenant is affected. ▶ 10:17
• Under the new model, deferred users get a change 30 days after production rollout begins, and customers who name a standard group will have those users deliberately deployed at the front of the queue so the 30-day gap is genuinely honoured. ▶ 15:55
• The key difference from targeted release: standard is production code with documentation, PowerShell and support content ready at the time the Message Center post publishes, with rollout starting around five days later — whereas targeted release bits could still change before GA. ▶ 16:56
• Message Center post structure is being tightened into consistent sections — what and why, rollout timeline, platforms affected, who is impacted, and what admins need to do — on top of the compliance considerations block added a few months ago. Useful if you review multiple workloads and currently have to mentally re-parse each team's writing style. ▶ 19:00
• Two MCP servers are now available: one over Roadmap data (including Azure updates) and an enterprise one that reads Message Center and Service Health Dashboard via Graph, grounded on your own tenant's user counts, licensing and usage — so you can ask which users a change affects and draft the comms from the same session. ▶ 21:32
• Internally, engineering change tracking is being funnelled from around 50 different team-specific systems into a single change management system — the prerequisite for finally telling admins when a change has actually landed in their tenant rather than giving a rollout window. ▶ 34:18
• Per-post feedback is read by McGough's team and passed to engineering: it has stopped feature rollouts and reversed announced retirements where customers explained they depended on the feature daily. Volume of feedback matters, so use the form. ▶ 38:19

Insights summarised by AI from the episode transcript, reviewed by the Empowering.Cloud team.

Listen: Apple Podcasts · Spotify · Other platforms