ConfigMgr 25 週年

上週末,我寫了一篇非凡的 25 年里程碑,這是有關 ConfigMgr 達成的成果,今天我想更深入探討這項卓越產品的背景故事、分享數則公告,以及首次公開一部精彩的全新紀實 (lookout 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,而此小組不想讓它看起來與 Windows 相差太遠,但又覺得挑選太接近 300 的數字會引起猜測。所以挑選了 245!

SMS 是在 1994 年 11 月 7 日正式推出。當時第一個版本花了稍微超過兩年的時間,現在我們「每個月」都會發行新的測試人員組建!

在那次推出 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 歷史」

我迫不及待想觀看。

_______________________________________________

請注意,這些部落格文章內容所描述的特色和功能可能會因市場而異。如需有關您所在市場的特定產品方案完整詳細資料,請瀏覽 Microsoft 365Office 365Windows 10Enterprise Mobility + Security
這些文章所連結的內容可能未提供您當地的語言版本。