ConfigMgr 25 週年

在那次推出 SMS 的一個重要時刻，就是 Bill Gates 傳送了一封電子郵件給所有 Microsoft 員工，說明 SMS 已部署於全公司。曾為工程師的 Bill 在該電子郵件中指出，如果您真的想從電腦中移除 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 的差異是根據專注於使用者 (身分識別) 與 Directory 的深度整合！

撰寫這篇文章時，我想起了 SMS 2.0 中隱藏的一段意外內容。這段意外內容是一部影片，顯示致力於該產品的人員姓名和相片，而當我這週再重看一次時，我看到了這個姓名：

沒錯，就是我的主管 Terry Myerson，他是 Microsoft 執行副總裁。我猜所有的大人物在職業生涯中確實都有透過 SMS 傳遞訊息。 (:

當所有努力造就了 SMS 2003 的成果時，我加入了 SMS 小組。

在 SMS 2003 中，同樣地，產品有很大部分是經過重新撰寫。當時的重大里程碑是將 SMS 整合到 WSUS 上進行修補。這將來自雲端的 Microsoft 修補 (Windows Update) 整合到消費者與企業。WSUS 除了是在資料中心執行之外，實質上是用於 Windows Update 的相同項目。

Windows Update 是全球最大雲端服務之一，每個月更新超過 10 億部裝置。請思考一下：  Microsoft 的其中一項關鍵差異在於，現今的公用雲端是我們的混合式功能，而且實質上能讓您在資料中心執行我們的公用雲端。在資料中心 (WSUS) 執行 Windows Update 確實是先驅般的創舉，而且可能是連線到雲端和混合式雲端的最早範例。當時膝上型電腦使用量也已加速成長，而我們需要建置可在中斷連線或連線鬆散的模型中運作的新用戶端。

隨著接近 SMS 2003 的發行時間，我們每週五早上都會與全公司的某個小組開會，評估專案的狀態。Microsoft IT 部門 (MSIT) 是受邀參與該會議的其中一個關鍵小組。我授與 IT 小組對於推出 SMS 2003 的否決權 (如果他們認為尚未準備就緒)，此為公司中史無前例之舉。從此之後，MSIT 一直是我們的首要最佳客戶，也是我們初期組建的意見反應最佳來源之一。

現今，我們透過單一 ConfigMgr 部署，在 Microsoft 管理超過 500,000 部電腦和行動裝置 (1 億部 MAD 中不包含此數字)。在建置各個每月版本的同時，我們持續在 Microsoft 部署新項目。我們「絕對」是使用自家的產品。另一項有趣資訊：  我的小組實際上會監督 ConfigMgr 的內部部署。「從做中學」是最好的策略！

在 2003 與 2007 之間，我們發行了兩個 “Feature Pack”。 我們不想等到全新的產品才推出新功能，因此，我們透過這種創新的方式來發佈功能。第一個 Feature Pack 完成在 WSUS 上進行修補的整合工作。第二個 Feature Pack 是在我們發佈 OS 部署時推出。

當時我最珍惜的一段回憶是，我們在 2003 年 11 月於歐洲某一場活動中所設置的示範，進行全新 OS 部署功能的展示。Bill Gates 發表專題演講，而在他發表「SMS 的新增功能」這段內容期間，我們在 Bill 後方的牆上現場升級了 100 部電腦。我們將此次示範稱為「火焰之牆」。

以下是我們在 Bill 轉身觀看示範執行時所拍攝到的相片：

以下是站上舞台進行示範之勇敢的 SMS 小組成員的相片：

發揮影響力

在 2004 年秋季，Bill 和 Steve 主持了一場公司外會議，還有一些公司中的資深主管一同參與，當天的最後一段研討會是與 Bill 和 Steve 進行開放式問與答。  有人問 Bill 他認為「Microsoft 去年發生的最重大的事情是什麼。」 Bill 回答：「我們完成了 SMS 和 Active Directory，這兩者將會是帶領我們向前邁進的重大資產。」

直到今日，這一直是我的職業生涯最難忘的其中一天！

在 2007 年，我們將名稱從 “SMS” 更改為 “ConfigMgr”，以使 SMS 符合 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 測試人員版本，並且每隔 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 基礎結構朝著成為真正的雲端服務邁出重要的一步。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 對我的人生、我家人的人生、致力於這些專案的數千名工程師的人生、曾使用且目前仍持續使用這些產品的數百萬名 IT 專業人員的人生，帶來非常深遠的影響。我很喜歡這項產品，而且也很熱愛這個社群。

我也非常喜歡與大家一起觀看今天呈現 ConfigMgr 歷史的這個紀實，但這只是第 1 部分。而第 2 部分更重要許多。因為第 2 部分將由您進行創作。

如果您在 Ignite 現場，請在 Microsoft 攤位的管理和安全性區域停下您的腳步，並且訴說您的故事。簡單的指示提供在這裡。

如果您不在 Ignite 現場，您仍可輕鬆參與。請在這裡 (aka.ms/ConfigMgr25) 上傳您關於 ConfigMgr 的回憶和故事，訴說您的故事。這裡有一些基本指示。

我們將使用這些提交內容來創作第 2 部分，並將影片稱為：

「人類的 ConfigMgr 歷史」

我迫不及待想觀看。

_______________________________________________