上周晚些时候，我撰写了关于 ConfigMgr 非凡的 25 年里程碑事件。今天，我想深入探讨这个令人赞叹的产品的背景故事，分享一些公告，并首次发布一部很棒的新纪录片（了解 Sundance！），该纪录片深入探讨了创建电脑管理行业的产品的起源和发展。
接下来，ConfigMgr 公告：
由于今天是个里程碑式的时刻，我想分享一个你可能从未听过的故事：
故事是这样开始的
上周晚些时候，我借机会重新阅读了 Hermes 项目的原始愿景文档或“规范”。我已经有好几年没看过这个文档了，看到 ConfigMgr 如此忠实地坚持最初的愿景，我感到很惊讶。该文档中概述的基本构建基块沿用至今，仍然是其基础的一部分。
1992 年，Microsoft 的最初使命（也就是每家每户都拥有一台电脑）刚刚达到临界量。组织正在积极地从终端仿真转换到 x86 分布式计算模型，此时还没有大规模管理电脑的解决方案。团队知道 Hermes 项目必须具有影响力。
最初的 SMS 团队包括两位全职开发人员和一位名叫 Ken Pan 的实习生。 我在 2003 年加入该团队时，实习生 Ken 正在领导整个开发团队（由大约 150 名工程师组成）。从那以后，Ken 一直领导 SCCM 和 Intune 的工程工作！
有趣的事实： Systems Management Server (SMS) 的第一个内部版本是 245。为什么不是 1？Windows 当时正处于内部版本 300，该团队不想显得太落后，但他们知道挑选太接近 300 的内部版本会引起质疑。所以他们选了 245！
SMS 于 1994 年 11 月 7 日正式发布。第一个版本耗时两年多一点，如今，我们每个月都发布新的预览体验成员内部版本！
那次发布的一个重要时刻是 Bill Gates 给每一位 Microsoft 员工都发了一封电子邮件，向大家说明公司正在部署 SMS。Bill Gates 曾经是一名工程师，他在那封电子邮件中表明了在计算机上删除 SMS 软件的方法（如果有意这样做）。(:
如果你想看那封电子邮件，我已经把它添加到了这篇文章的底部。
推动体系结构向前发展
SMS 1.0、1.1 和 1.2 很快发布了，一个新的市场随之诞生。团队立即开始着手研发 SMS 2.0。
这时事情变得复杂起来。
老实说，我们做出了一些糟糕的决定。成长型思维的一个重要部分是快速学习的能力 – 这从一开始就是 SMS 团队的核心。
自 1992 年以来，客户端 – 服务器应用程序的体系结构发生了很大变化，因而该团队在 1997 年和 1998 年重新编写了 SMS 服务器基础结构，以提升 SMS 的规模和性能，他们还集成了 Windows Server 2000 即将推出的功能。这是 SMS 体系结构第一次被重写，以确保其最先进的地位。
SMS 2.0 于 1999 年 1 月发布，其采用和使用实现加速。当时我在 SMS 最大的竞争对手 Novell 工作，领导 Novell ZENworks 团队。我几乎数不清花了多少时间与 SMS 客户见面，谈论 ZENworks 的不同点，这些不同点是基于通过深度目录集成实现对用户（身份）的关注！
我在写这篇文章时，有人提醒我 SMS 2.0 中有一个“复活节彩蛋”。“复活节彩蛋”是一段视频，展示了研发该产品的人员姓名和照片，这周我再看时，一个名字非常显眼：
是的，Terry Myerson，他是我的老板，也是 Microsoft 的执行副总裁。我猜所有的伟大人物在他们职业生涯的某个阶段都有过 SMS 的经历。(:
当我加入 SMS 团队时，团队正为研发 SMS 2003 而努力。
SMS 2003 的相当大一部分也经过了重写。当时一个重要的里程碑是让 SMS 与 WSUS 保持一致以实现补丁分发。这使得 Microsoft 补丁分发从云（Windows 更新）到使用者和企业实现了一致。WSUS 与 Windows 更新基本相同，但它在数据中心运行。
Windows 更新是世界上最大的云服务之一，每月更新超过 1B 台设备。想一下这个问题： 如今，Microsoft 在公共云方面的关键优势之一是我们的混合功能以及用户可在数据中心中运行公共云的能力。在数据中心中运行 Windows 更新 (WSUS) 确实是一个创举，而且可能是云连接和混合的最早示例。这也是笔记本电脑使用真正加速的时候，我们需要构建一个新的客户端，它在断开连接或松散连接的模式下运行。
随着 SMS 2003 发布的临近，我们通常在每周五上午与来自公司各个工作组举行会议，评估项目的状态。受邀参加该会议的重要工作组之一是 Microsoft IT 部门 (MSIT)。对于发布 SMS 2003 的决定，我授予 IT 团队否决权（如果他们认为 SMS 2003 尚未准备就绪），这在公司是没有先例的。从那时起，MSIT 一直是我们第一个也是最好的客户，也是早期内部版本反馈的最佳来源之一。
如今，通过一个 ConfigMgr 部署，我们在 Microsoft 管理着超过 500,000 台电脑和移动设备（这个数字不包括在 100M MAD 中）。我们每个月都会生成一个新版本，并不断在 Microsoft 部署新版本。我们绝对自产自用。另一个有趣的现象： 我的团队实际上负责监督 ConfigMgr 的内部部署。没有比实践更好的学习方法了！
在 2003 年到 2007 年间，我们发布了两个“功能包”。 我们不想等到完整的新产品发布时才提供新功能，因此我们采用这种新方式来发布功能。第一个功能包完成了与 WSUS 保持一致以实现补丁分发的工作。第二个功能包是在我们发布 OS 部署时发布的。
令我印象深刻的是我们在 2003 年 11 月欧洲的一次活动上创建的一个演示，展示了新的 OS 部署功能。Bill Gates 发表了主题演讲，在他讲到“SMS 新增功能”部分时，我们在他身后的墙上实时升级了 100 台电脑。我们把这个演示称为“火墙”。
这是我们在 Bill Gates 转身观看演示时拍下的照片：
下面是进行演示的勇敢的 SMS 团队成员的照片：
发挥影响力
2004 年秋天，Bill 和 Steve 与公司内部的一些高级领导举行了一次非现场会议，当天最后一个环节是与 Bill 和 Steve 的公开问答。 有人问 Bill：“Microsoft 去年发生的最重要的事情是什么？” Bill 回答道：“我们完善了 SMS 和 Active Directory – 它们将成为我们前进的巨大推动力。”
直到今天，我仍然觉得这是我职业生涯中最美好的日子之一！
2007 年，我们将名称从“SMS”更改为“ConfigMgr”，以便与 System Center 品牌保持一致。那时，Desired State Configuration (DSC) 是客户要求的最新创新方案，因此，我们再次改进了体系结构，使 DSC 能够按照它应该的方式工作。我们还完全重写了管理体验。
2011 年 2 月，在 SCCM 2012 工程进行到一半时，Satya 接手了 Server and Tools Business (STB)，并将其更名为 Cloud and Enterprise (C+E)，他成为了我的老板。记得我们初次的面对面会议，Satya 来到我的办公室，花了许多时间来了解我本人。多年来作为 Satya 的直属下属，我向他那令人难以置信的好奇天性、成长型思维和谦逊的领导方式学习，这真是一段不可思议的经历。在此版本中，Satya 对 ConfigMgr 的未来和体系结构产生了巨大的影响。
在 ConfigMgr 2012 中，我们将体系结构和体验的重点放在用户上而不仅仅是设备上，从根本上改变了体系结构的发展方向。
客户告诉我们，移动性将是未来的关键，我们明白移动性是指人的移动性，而不仅仅是设备的移动性。 为了响应这些信息，我们大幅度地简化了体系结构以减少硬件需求，并极大地提高了规模限制。这是我们的云之旅真正重要的阶段；我们将 ConfigMgr 连接到 Microsoft Intune，Intune 实际上成为了 ConfigMgr 的优势。
这种混合配置成为允许我们在云中进行创新，然后通过混合部署为本地 ConfigMgr 提供新价值的模型。我们相信，云将使过去不可能的方案成为可能，而 Satya 能够看到云对设备管理的潜在影响，他真正促使我们进行创新和试验。
ConfigMgr 迈向云
到目前为止，接下来的体系结构演变是最具挑战性的。
当我们了解到 Windows 10 将以服务的形式交付，并且每年交付多个更新时，我们明白 ConfigMgr 需要跟进并移动到云端。
我们面临的挑战是艰巨的。
从历史上看，ConfigMgr 的发布周期为 2 – 3 年。我记得在查看 SCCM 2007 的第一个全面计划时，我了解到从宣布代码完成到发布之间经历了 16 个月的稳定和 beta 版。16 个月！ 很明显，我们需要对 ConfigMgr 进行 SaaS 化，这样我们就可以保持每年多次发布的节奏。
面对如此艰巨的任务，我们开始精心挑选一个由工程师和项目经理组成的小团队，他们非常了解 ConfigMgr，具有成长型思维，并且对这个客户群有着共同的热情。 我们认为，我们实现这一目标的唯一方法是让一个具有专注力的小团队彻底重建整个体系结构，并从头开始构建云服务。
当我看到我们的重建时间表时，我承认我通常的乐观情绪中夹杂着一些怀疑。这么快地完成这项任务是难以置信的。
现在，结果显而易见： 这个具有高度专注力的工程团队的表现超越了每一个基准，并为电脑管理提供了一种新的基于云的方法，实现了每月发布一次的周期。为了跟踪这些更新，我们取消了传统的版本号（例如 2003、2007、2012），而是开始用年/月的惯例命名它们；因此，第一个版本为 1511，因为我们是在 2015 年 11 月发布的。
从那时起，我们每个月都会发布一个新的 ConfigMgr 预览体验成员版本，主 CurrentBranch 大约每 4 个月发布一次。
毫无疑问，这是我参与过的最令人难以置信的工程工作之一。
客户对这种新的云交付模型的反应是惊人的。
看看这个图：
超过一半的 ConfigMgr 基础已经升级到新的当前分支模型，现在有超过 1 亿个设备正在被主动管理并发送回遥测。
天哪 1 亿个！！！！
据我所知，目前世界上只有 3 家企业服务每月管理着超过 1 亿个活跃用户或设备并让其发送回遥测： Office 365、Azure Active Directory 和 ConfigMgr。这三者有什么共同之处？ 他们都属于 Microsoft 365 集成产品/服务。
这个图表显示了自 1511 版本以来 ConfigMgr 当前分支的主要版本的采用情况。我们有一个仪表板可以实时显示这些数据，我们每个星期天早上 8:30 都会把这个图表发送给我们的整个团队。
相信我，星期天早上 8:30 是我每周最喜欢的时刻之一。
这是 ConfigMgr 有史以来最快的升级，你可以看到，随着每个版本的发布，采用的速度（从左到右的直线斜率）越来越快、越来越陡。起初，我们对 ConfigMgr 社区将对如此快速的发布作出何种反应感到有些紧张，我们对你们给予我们的信任和信心感到惊喜和感激。
从来没有像现在这样对 Hermes 项目有如此高的兴趣和热情。
下一步计划
我们的云之旅是从 2015 年 11 月 ConfigMgr 当前分支的 1511 版本开始的，当时我们很清楚，这是朝着我们需要达到的目标迈出的重要一步。我们也清楚地知道还有很多工作要做。
自 1511 版本以来，创新的步伐一直在加快。组织正在迅速进入连接到移动设备的云服务世界，为了使我们能够在这个加速发展的环境中提供你所需的服务，ConfigMgr 基础结构已经迈出了成为真正云服务的重要一步。它现在是一项不断更新功能的服务，它利用云的 AI 功能来根据你的需求进行调整并提供你所需的保护，并且它可以作为基于云的服务使用，可以扩展到遍布全球的数亿台设备。
这些让我想起了我从世界各地的 IT 领导者那里最常听到的话： 他们和他们的团队为了完成工作必须处理复杂性，这让他们感到沮丧。组织正在寻找简化其部署的方法，并且他们需要一种统一的方式在所有设备上支持用户，同时还需要提供他们所需的管理和安全性。这就是我们构建 Microsoft 365 的原因。 M365 提供新式安全工作区和集成的云服务，使用户能够实现更多的目标。它旨在使 IT 能够提供受用户喜爱并受 IT 信任的丰富且赋能的工作环境。
这是你多年来一直使用的 Microsoft 所有产品（Windows、Office、Active Directory、ConfigMgr）的下一步发展，我们已经通过 Microsoft 365 将它们全部移动到云。 全球的企业客户正在迁移到云（使用 Windows 10 即服务、Office 365 和 EMS 服务），这是 ConfigMgr 体系结构自然的下一步发展。
现在，几乎全球每个企业和商业组织都是从使用 Active Directory、组策略和 ConfigMgr 作为管理工具的内部模式开始的。转向更简单、更现代的模式的愿望很强烈，但要实现这种新的现代化模式并不容易。一个组织不可能只打打响指，便将用户/设备从 AD/GP/ConfigMgr 迁移到 AAD/Intune。你需要的是一座桥梁，让迁移过程变得更简单、更快，并消除风险。通过了解组织从本地 Exchange 迁移到 Exchange Online 的过程，我们学到了很多这方面的知识。
今天，我们高兴地宣布推出“共同管理”，这是一套新的功能，也是有助于加快通过云向现代化管理转变的桥梁。借助 Fall Creators Update，Windows 10 设备可以同时加入本地 Active Directory (AD) 和 Azure AD。
“共同管理”利用了这一改进，支持设备由 ConfigMgr 代理和 Intune MDM 共同管理。向现代化管理的转变不再是你必须跳下去的悬崖。借助“共同管理”，可以以一种对组织有利的方式和速度，逐步实现自己的云之旅。
我们简化了 ConfigMgr 控制台中管理设备和将设备注册到 Intune 中进行管理的操作。然后，你可以选择要移动到云的第一个工作负载（它实际上是从 ConfigMgr 移动到 Intune 的滑块），该工作负载会移动到云。
在此共同管理场景中，Microsoft 365 的一个独特功能是 ConfigMgr 和 Intune 始终保持通信。随着工作负载的移动，我们了解到用户和设备上每个属性的权威源（Intune 或 ConfigMgr），这可避免应用冲突策略。
这将极大地加快通过云向 Windows 10 和现代化管理的转变。
* * * * *
撰写这篇文章对我来说是一次奇妙的记忆之旅。SMS/ConfigMgr/Intune 对我的生活、家庭，对参与项目的 1,000 名工程师的生活，对使用并继续使用它的数百万 IT 专业人士的生活都产生了深远的影响。我喜欢这个产品，我喜欢这个社区。
我也很高兴看到今天关于 ConfigMgr 历史的纪录片，但这只是第 1 部分。第 2 部分更重要。这是因为第 2 部分将由你创建。
如果你在 Ignite 会议现场，请访问 Microsoft 展位的管理和安全区域，与我们分享你的故事。此处有简单指示。
如果你不在 Ignite 会议现场，也可以轻松参与。通过在此处 aka.ms/ConfigMgr25 上传有关 ConfigMgr 的回忆和故事，与我们分享你的故事。此处是一些基本说明。
我们将使用这些提交内容来创建第 2 部分 – 我们想把这个视频称作：
“ConfigMgr 的历史记忆”
我对此充满期待。
_______________________________________________
