什么是 Microsoft 365 消息中心?不局限于“仅阅读”变更通知的实际业务运营
关于本文
本文是通过利用生成式 AI 的自动生成流程创建的。我们确认了 Microsoft Learn 的消息中心(Message center)、Microsoft Graph 的服务通信(service communications)API 以及 Planner 联动的官方信息,并将其整理为将变更通知落实到用户影响、负责人、期限和验证的实际业务运营。验证状态:📘 已确认 Microsoft 官方信息,未在真机上验证(2026-09-18)
Microsoft 365 消息中心(Message center)是一项管理功能,用于向签约租户通知 Microsoft 365 中计划的新功能、规格变更、停用以及需要管理员应对的变更等。
“租户”是贵公司使用 Microsoft 365 的组织单位。与普通的 IT 新闻不同,消息中心是管理员追踪与本公司签约服务相关的变更的入口,可以作为此用途使用。
首先要记住的 4 个词汇
| 术语 | 含义 | 实际业务中的关注点 |
|---|---|---|
| 消息 ID (Message ID) | 每个通知的识别编号 | 记录在台账或咨询记录中,以便追踪原文 |
| 发布 (rollout) | 向用户逐步部署功能 | 不仅要看开始日期,还要看预计完成时间 |
| 重大更新 (Major update) | 影响较大的变更分类 | Microsoft 说明称,原则上会在至少 30 天前通知需要管理员应对的主要更新 |
| 截止日期 (Act by) | 管理员应当应对的期限 | 如果填有日期,则优先确认 |
计划日期可能会发生变更。不要武断地认为“9 月 20 日会同时反映给所有人”,将部署周期与本公司的实际到达情况分开管理这样更为安全。
E3 和 E5 有什么区别?
将消息中心本身区分为“E3 版”或“E5 版”是不恰当的。作为 Microsoft 365 管理中心的一项管理功能,它会显示与签约服务和租户相关的通知。
因此,关键并不在于“因为是 E5,所以消息中心功能更强大”这种对比,而是根据本公司的订阅配置(如 E3/E5、Teams 的 SKU、附加许可证等),确认收到的变更是否适用于本公司。
消息中心、服务健康状况与路线图的区别
| 位置 | 主要确认内容 | 示例 |
|---|---|---|
| 消息中心 (Message center) | 与自身组织相关的计划变更和待办事项 | Teams 会议 UI 变更、功能停用 |
| 服务健康状况 (Service health) | 当前发生的服务故障和问题 | Exchange Online 故障 |
| Microsoft 公开路线图 (Roadmap) | 广泛查询产品功能的发布计划 | 今后计划提供的功能 |
关键在于不要仅将消息中心用于故障监控。
flowchart LR
A[Microsoftから変更通知] --> B[Message center]
B --> C{自社影響を評価}
C -->|利用者影響| D[周知・FAQ]
C -->|設定影響| E[管理者テスト]
C -->|セキュリティ/法務| F[専門部署レビュー]
C -->|影響なし| G[根拠を残して完了]
D --> H[変更台帳]
E --> H
F --> H
G --> H
首先尝试:阅读 1 条通知
在 Microsoft 365 管理中心的 “健康状况” > “消息中心” 中选择一条通知。开始时不要更改设置,仅进行阅读。
消息 ID (Message ID)
目标服务
最近更新时间 (Last updated)
发布的预计开始和完成时间
是否有截止日期 (Act by)
对用户和管理员的影响
Microsoft 要求做好的准备
关注这里
不要觉得“因为是新功能,所以看起来很方便”,而是要看谁的操作会在什么时候发生怎样的变化。Major update(重大更新)、Retirement(停用)、Admin impact(管理员影响)、User impact(用户影响)等标签也可用于判断优先级。
尝试更改一处
将服务(Service)筛选器设置为仅限 Teams。按负责的产品进行筛选,可以更容易地看出该通知应该转交给谁。
普通用户、行政人员和 IT 部门的关注点不同
普通用户关注的中心是“自己的操作是否会发生变化”,例如按钮位置、会议操作、共享方式等。
行政人员/部门负责人会考虑到何时修改手册、培训材料、公司内部通知以及咨询 FAQ。
IT 部门会确认目标 SKU、管理设置、默认值、发布(rollout)、安全性、审计以及对支持服务的影响。
例如,如果是关于 Teams 会议界面变更的通知,并不仅仅是 IT 部门阅读完就结束了。这可能会影响到负责接待或会议运营的部门的操作指南。
在实际业务中将其转化为“变更台账”
| 列 | 记录示例 |
|---|---|
| 消息 ID (Message ID) | MC123456 |
| 服务 | Microsoft Teams |
| 变更内容 | 会议操作 UI 变更 |
| 发布 (rollout) | 预计开始/完成时间 |
| 截止日期 (Act by) | 期限或无 |
| 对本公司的影响 | 有 / 调查中 / 无 |
| 目标受众 | 全体员工 / 管理员 / 部分部门 |
| 负责人 | Teams 管理负责人 |
| 应对措施 | 验证、通知、设置确认 |
| 完成条件 | 测试完成 + 发布用户指南 |
| 再次确认日期 | 发布过程中的确认日期 |
对于“无影响”的结论,不仅要记录结论,还要留存“不属于目标 SKU”等原因,以便日后追溯。
可以使用 Microsoft Graph 实现自动读取
通过 Microsoft Graph 的服务通信(service communications)API,可以获取消息中心帖子并将其集成到变更管理工作流中。由于旧版 Office 365 Service Communications API 已停用,因此在进行新开发时请确认 Graph 侧的 API。
如果想安全地进行尝试,首先可以在 Graph Explorer 等工具中仅进行读取操作。
GET https://graph.microsoft.com/v1.0/admin/serviceAnnouncement/messages?$top=10
关注这里
确认响应为 HTTP 200,并且value 数组中返回了消息中心的帖子。由于运行可能需要适当的 Graph 权限和管理员同意,请勿将凭据嵌入到生产应用程序中。
更改一处
$top=10 更改为 $top=5 ,即可理解如何指定获取的条数。开始时不要编写更新或删除处理,而是从读取和台账化开始。
也可以连接到 Planner
Microsoft 还提供了将消息中心任务同步到 Planner 的机制。在管理中心侧启用 Planner 同步后,可以将负责人和期限作为任务进行追踪。
但是,存在一些限制,例如如果设置同步的用户失去了对 Planner 或 Microsoft 365 管理中心的访问权限,联动将停止工作。实现自动化后,还要在运营台账中记录“该自动化是在谁的权限下运行的”。
如果要交给生成式 AI,应让其负责整理而非做出判断
次のMicrosoft 365 Message center本文を整理してください。 本文にない事実を追加しないでください。 1. Message ID 2. 対象サービス/SKU 3. 変更内容 4. rollout期間 5. Act by 6. 利用者への影響 7. 管理者が確認すべき事項 8. 不明点 を表にしてください。 判断できない項目は「本文から判断不可」としてください。
不要仅凭 AI 的摘要就做出“无影响”的判断,应保持能够追溯到消息 ID 和 Microsoft 原文的状态。
管理员需要确认的要点
负责阅读消息中心的人员及备用人员
是否可以使用最小权限的消息中心读者(Message center reader)等角色
Major update(重大更新)/ Retirement(停用)/ Admin impact(管理员影响)的优先级规则
邮件通知和每周摘要(weekly digest)的接收地址
是否将定向发布(Targeted Release)用户用于先行验证
与服务健康状况(Service health)的责任分界
Planner 或 Graph 自动化的运行主体
保留了消息 ID 的变更管理台账
Microsoft 推荐使用最小权限角色。应避免为了阅读消息中心而在日常使用全局管理员(Global Administrator)角色的设计。
官方信息/一手信息
Track new and changed features in the Microsoft 365 Message center
Office 365 Service Communications API reference(旧版 API 停用通知)
消息中心的价值并不在于阅读大量的通知。而是在于能够将 Microsoft 的变更转化为本公司的“谁、在什么时候之前、需要确认什么”。
