Configuration Manager 誕生から 25 年
先週、Configuration Manager が達成した重要な四半世紀のマイルストーンについて記事を書きました。本日は、このすばらしい製品の知られざる内側を詳しくお見せし、いくつかのお知らせをし、目を見張るようなドキュメンタリー (サンダンス映画祭にご注目ください) をご紹介します。この作品では、Windows PC 管理という業界を生み出した製品の誕生と成長を詳しく追っています。
次は、Configuration Manager に関するお知らせです。
現在のこのマイルストーンを踏まえて、皆さんが初めて目にするであろうストーリーをご紹介します。
すべての始まり
先週後半、ヘルメス プロジェクトの “仕様” とも言われる、ビジョンに関するドキュメントの原本を読み返す機会がありました。このドキュメントは数年間読んでいなかったのですが、Configuration Manager がいかに当初のビジョンを忠実に保っているかを見て驚きました。このドキュメントで説明されている基本的な構成要素は、現在も使用され、基礎の一部となっています。
1992 年という時期は、Microsoft による当初のミッション (すべての家庭とすべてのデスクの上に Windows PC を) がクリティカル マスに達したばかりでした。組織は端末エミュレーションから x86 マシンによる分散コンピューティング モデルへの移行を積極的に進めていました、大規模な Windows PC 管理のためのソリューションは存在していませんでした。チームは、ヘルメス プロジェクトにインパクトが必要であることを認識していました。
当初の SMS チームは、2 人のフルタイム開発者と、Ken Pan というインターンで構成されていましたが、 2003 年に私がこのチームに入ったときには、元インターンの Ken が 150 人のエンジニアのリーダーとなっていました。それから今日まで、Ken は SCCM と Intune へのエンジニアリングの取り組みを率いています。
楽しいエピソード: Systems Management Server (SMS) の最初のビルドは 245 でした。なぜ 1 ではないのでしょうか。それは、当時 Windows がビルド 300 で、チームは自分たちがあまりに後れを取っているかのように見られたくなく、しかし 300 にあまり近い数を選ぶと、かえって疑いの目で見られると考えたのです。そして選ばれたのが 245 だったというわけです。
SMS は 1994 年 11 月 7 日に正式提供されました。最初のリリースまでには 2 年以上かかりましたが、現在、私たちは新しい Insider 向けビルドを毎月リリースしています。
その提供開始の後で最も盛り上がったのは、ビル・ゲイツから Microsoft 全従業員に宛てたメールで、SMS が全社に展開されると説明されたときです。当時まだエンジニア気質だったビルは、どうしてもいやだという場合に各自のコンピューターから SMS のソフトウェアを削除する方法をメールの中で説明していました。
そのメールをお読みになりたい方のために、この投稿の最後に載せておきます。
アーキテクチャの進化
SMS 1.0、1.1、1.2 は、いずれも速いペースでリリースされ、それによって新しい市場が生まれました。チームはすぐに SMS 2.0 への取り組みを開始します。
そこで、困難が生じました。
正直に言えば、いくつか判断を誤りました。成長を支える心構えの主要部分は、すばやい学習能力です。これは、当初から SMS チームの中心を成していました。
クライアント/サーバー アプリケーションの構築方法に関するアーキテクチャが、1992 年のものとはあまりにもかけ離れたものになったため、チームは SMS サーバーのインフラストラクチャを 1997 年と 1998 年に根本から書き換えて SMS のスケールとパフォーマンスを進化させると共に、来たるべき Windows Server 2000 の機能と連携を図りました。これは、SMS をその当時最高のものとするためであり、SMS アーキテクチャを書き換える最初の取り組みでした。
SMS 2.0 は 1999 年 1 月にリリースされ、順調に採用と利用が広がっていきました。当時、私は SMS の最大のライバルである Novell で働いており、Novell ZENworks チームに属していました。ユーザー (ID) を中心に置き、深いディレクトリ統合を行う ZENworks の特徴について、SMS のお客様に会ってお話しした時間は、はかり知れません。
この投稿を書いていて、SMS 2.0 にはイースター エッグが仕込まれていたことを思い出しました。それは製品に取り組んだ人たちの名前と写真のビデオで、今週それを見返していると 1 つの名前が目に留まりました。
Terry Myerson です。私の上司であり、Microsoft 執行副社長です。優秀な人はすべて、そのキャリアのどこかで SMS を通過しているのではないかと思います。
私が SMS チームに加わったのは、後に SMS 2003 となるものへの取り組みが立ち上がりつつあるときでした。
SMS 2003 では、製品のかなりの部分が書き直されました。当時の大きなマイルストーンは、パッチを適用するために SMS を WSUS に合わせることでした。それにより、一般ユーザーと企業に向けてクラウド (Windows Update) からの Microsoft パッチ適用が実行できるようになります。WSUS は基本的に Windows Update と同じプログラムですが、ユーザーのデータセンターで実行される点が異なります。
Windows Update は世界最大のクラウド サービスの 1 つであり、毎月 10 億台のデバイスがこれによって更新されています。少し考えてみてください。 パブリック クラウドでの Microsoft の主要な強みの 1 つは、ハイブリッド機能と、お客様のデータセンターで Microsoft のパブリック クラウドを実行できることです。お客様のデータセンターでの Windows Update の実行 (WSUS) は、クラウド接続とハイブリッドの先駆けであり、おそらくは最も初期の例でしょう。これはノート PC の利用が急速に増え出した時期でもあり、私たちには非接続またはゆるい接続のモデルで動作する新しいクライアントを構築することが求められていました。
SMS 2003 のリリースが近付くと、私たちは毎週金曜日の朝に社内の他のグループとミーティングを開いて、プロジェクトの状態を評価しました。招待したグループの中で重要なグループの 1 つが、Microsoft IT 部門 (MSIT) です。Microsoft では前例がないことでしたが、私は IT チームに対して、彼らがまだ不十分な状態であると考えるならば、SMS 2003 の出荷に対して拒否権を行使できる許可を与えました。それ以降、MSIT は私たちにとって最初の、そして最高の顧客となっており、早い段階のビルドに対する最良のフィードバック元の 1 つです。
現在、私たちが Microsoft 社内で管理している Windows PC およびモバイル デバイスの数は 50 万台を超えていますが (この数字は 1 億台の月間アクティブ デバイス数には含まれていません)、これらはすべて 1 つの Configuration Manager 展開を通じて管理されています。私たちは、毎月のリリースをビルドするたびに、新しいプログラムを Microsoft 全体に展開しています。間違いなく社内で試験運用をしているのです。もう 1 つのエピソードとして、 私たちのチームは Configuration Manager の社内展開を実際に監督します。何かを学ぶには実行するのが一番であるからです。
2003 年から 2007 年までの間に、私たちは 2 つの “機能パック” をリリースしました。 新しい機能を提供するのに、フル機能版の新製品がリリースされるまで待ちたくなかったので、この新しい方法を採り入れて機能をリリースしたのです。最初の機能パックでは、パッチ適用のための WSUS との調整を完了させました。2 つ目の機能パックは、OS 展開をリリースしたときです。
当時の思い出として気に入っていることは、2003 年 11 月にヨーロッパで開催したイベントでのデモで、新しい OS 展開機能を披露したことです。ビル・ゲイツが基調講演を行ったのですが、”SMS の新機能” というセクションのときに、彼の背後の壁にモニターを配置した 100 台の Windows PC をライブでアップグレードしたのです。私たちはこのデモのことを “炎の壁” と呼んでいました。
この写真は、ビルがデモの実行を見回している様子を捉えたものです。
こちらは、果敢にデモを披露した SMS チームのメンバーです。
影響を与える
2004 年の秋、ビルとスティーブは全社から上位のリーダーを集めて社外ミーティングを開き、その日の最後のセッションは両名による自由な質疑応答となりました。 誰かがビルに「去年 Microsoft で起きた最も大きなこと」について考えをたずねたところ、 ビルの答えは「我々は SMS と Active Directory を成功させました。この 2 つはこの先、とてつもなく大きな資産となるでしょう」だったのです。
この日は私の職業人生の中で最高の日となりました。
2007 年、私たちは “SMS” という名前を System Center ブランドに合わせて “Configuration Manager” に変更しました。Desired State Configuration (DSC) は、お客様が望んでいた最新の革新シナリオでした。そこで私たちは DSC が本来の力を発揮するように、再度アーキテクチャを大きく変更しました。また、管理機能を全面的に書き換えました。
2011 年 2 月、SCCM 2012 のエンジニアリングを進めている途中で、Satya が Server and Tools Business (STB) を引き継ぎ、Cloud and Enterprise (C+E) と改名し、私の上司になりました。2 人だけの最初のミーティングのとき、Satya は私の部屋に来て長時間話をし、私のことを個人的によく理解してくれました。数年間 Satya を直属上司として働いた経験は貴重なもので、私は彼の驚くほど探究心に満ちた性格、向上心、控えめなサポート役としてのリーダーであるということを学びました。Satya は、このリリースを通じて、Configuration Manager の将来とアーキテクチャに多大な影響を与えました。
Configuration Manager 2012 で、私たちはアーキテクチャと機能の焦点をデバイスだけでなくユーザーにも向けることで、アーキテクチャの方向性を根本的に転換しました。
お客様からは常々、今後はモビリティが重要になると聞かされており、私たちはモビリティとはデバイスだけでなく人間も移動することを意味すると考えたのです。 お客様からそのような情報を受けていた私たちは、アーキテクチャを大きく簡素化してハードウェア要件を下げ、規模の上限を大幅に引き上げました。これにより、クラウドに向かう私たちの旅が本当の意味で本格化しました。Configuration Manager を Microsoft Intune につなげて、実質的に Intune を Configuration Manager のエッジとしたのです。
このハイブリッド構成がモデルとなって、クラウドでイノベーションを起こすことができ、ハイブリッド展開を通じて新しい価値をオンプレミスの Configuration Manager にもたらすことができました。私たちは、クラウドでは今まで不可能だったシナリオを実現できると考え、Satya にはクラウドがデバイス管理に与える影響の可能性が見えていました。そして彼は実際に、私たちを現在のイノベーションと試みの場に連れてきてくれました。
クラウドに向かう Configuration Manager
アーキテクチャの次の変革は、最も困難なものでした。
Windows 10 が毎年、複数回のアップデートを伴う as-a-service という形で提供されると知らされたとき、私たちは Configuration Manager にも同様のことが求められ、クラウドに移行する必要があるとわかりました。
そこからの取り組みは大変なものでした。
それまで Configuration Manager は、2 年から 3 年の間隔でリリースされていました。SCCM 2007 の最初の全体計画を見たとき、コード完成を宣言してからリリースまでの間に、安定版とベータの期間が 16 か月あったのを覚えています。16 か月です。 1 年に複数のリリースという流れを維持するために、Configuration Manager を “SaaS 化” する必要があることは明らかでした。
この巨大なタスクを目の前にして私たちが構成したチームは、Configuration Manager を隅々まで知り尽くし、向上心があり、この顧客ベースに向かう情熱を持っている、選りすぐりのエンジニアとプログラム マネージャーからなる小さなチームでした。 これをやり遂げる唯一の方法は、小さく求心力のあるチームでアーキテクチャ全体を根本的に見直し、クラウド配信型サービスを一から作り上げることだと信じていたのです。
この全面改訂のための行程表を見たとき、私のいつものような楽観視の姿勢に多少の影が差したことは確かです。これほどまでに短期間ですべてをやり遂げることは、信じがたい試みでした。
しかし今、その結果は明らかになっています。 並外れた集中力を備えたこのエンジニアリング チームは、あらゆるベンチマークを上回り、毎月リリースというサイクルに移行できるクラウドベースの新しいアプローチを Windows PC 管理にもたらしました。この更新ペースに合わせるために、私たちは従来のバージョン番号 (例: 2003、2007、2012 など) を廃止し、代わりに年と月による命名規則を採用しました。これにより、最初のリリースは 2015 年 11 月だったのでバージョン 1511 となりました。
それ以来、Configuration Manager の新しい Insider 向けバージョンを毎月、主要な Current Branch リリースをおよそ 4 か月ごとにリリースしてきました。
これは間違いなく、私が関わったあらゆるものの中で最も驚くべきエンジニアリング成果の 1 つです。
この新しいクラウド配信型モデルに対するお客様の反応は、素晴らしいものでした。
こちらのグラフをご覧ください。
既に Configuration Manager の半数強が新しい Current Branch モデルにアップグレードしており、1 億台を超えるデバイスが日々管理され、テレメトリを送信してきています。
1 億台とは驚きの数字です。
私の知る限り、毎月 1 億を超えるアクティブなユーザーまたはデバイスが管理対象となってテレメトリを送信している企業向けサービスは、世界で 3 つしかありません。 Office 365、Azure Active Directory、そして Configuration Manager です。これら 3 つの共通点は何でしょうか。 どれも Microsoft 365 サービスの一部として統合されているということです。
このグラフは、1511 リリース以降の Configuration Manager Current Branch の主要リリースの採用状況を示しています。私たちの手元には、このデータがリアルタイムで表示されるダッシュボードがあり、毎週日曜日の朝 8 時半にはチーム全員にこのグラフを送っています。
日曜日の朝 8 時半というのは本当です。これは私にとって、週の中でもお気に入りの瞬間の 1 つなのです。
Configuration Manager は常に最も早いアップグレードが行われています。グラフを見ると、リリースを重ねるごとに採用の進み方がより早く (左から右に進むにつれて線の傾斜が急に) なっているのがわかります。当初、私たちは、このように速いペースでのリリースに対して Configuration Manager コミュニティがどのように反応するか、やや心配していましたが、やがてそれは皆さんからの信頼に対する驚きと感謝に変わりました。
ヘルメス プロジェクトほど没頭し、情熱を注いだことは、現在に至るまで一度もありません。
今後について
私たちはクラウドへの旅を Configuration Manager Current Branch の 1511 リリースによって 2015 年 11 月に開始しましたが、そのとき、これは自分たちが向かわなければいけない目的地への大きな一歩であることがわかっていました。また、それ以外にも取り組む必要があることがたくさんあることも明らかでした。
1511 以降、イノベーションのスピードは増す一方です。組織は、モバイル デバイスとつながったクラウド サービスの世界に猛スピードで移行しています。そして、この加速していく環境の中で私たちがお客様の必要とするものを提供するために、Configuration Manager インフラストラクチャは真のクラウド サービスとなるための大きな一歩を踏み出しました。現在では、機能の追加を伴う更新が継続的に行われるサービスとなり、クラウドの AI 機能を利用してお客様のニーズを調整することによって必要な保護を提供しており、世界中の 1 億台ものデバイスを対象としたクラウドベースのサービスとして利用できます。
これらはどれも、世界中の IT リーダーの皆さんから最もよく聞くお話を思い起こさせます。 彼らは、仕事を進めるために自分やチームが処理しなければならない複雑さにいらだちを覚えています。組織は、自分たちが展開してきたものを簡素化する方法を探しています。また、ユーザーがデバイスの制約を受けずに活動でき、必要な管理とセキュリティも得られる統一的な方法を求めています。私たちが Microsoft 365 を作った理由はそこにあります。 Microsoft 365 は、最新の安全なワークスペースと、統合されたクラウド サービスを備えており、ユーザーの能力を引き出します。ユーザーに愛され、IT 部門に信頼される、機能豊富で従業員に力を与える作業環境を、IT 部門が提供できるように構築されています。
これが、Windows、Office、Active Directory、Configuration Manager など、長年愛用していただいてきた Microsoft の全製品に対して行われる次の大変化です。これらすべてを Microsoft 365 でクラウドに移行しました。 企業のお客様は世界中でクラウドに (Windows 10 as-a-Service、Office 365、EMS の各サービスを使用して) 移行しており、これは Configuration Manager アーキテクチャの次の大変化として自然な流れです。
現在、世界中のほとんどすべての企業と営利団体は、Active Directory、グループ ポリシー、Configuration Manager を管理ツールとして使用するオンプレミス モデルから出発しています。より簡素化され、より新しいモデルに移行する気持ちは強くても、新しいモデルの採用には常に困難が伴います。指を鳴らすだけでユーザーやデバイスを Active Directory、グループ ポリシー、Configuration Manager から Azure AD、Intune に移せるわけではありません。お客様が私たちに求めているものは、この動きを簡単ですばやいものにでき、リスクを取り除くことのできる橋です。この分野については、私たちはオンプレミスの Exchange から Exchange Online に組織が移行する過程を数多く観察して既に学んでいます。
本日、私たちは共同管理を発表できることを喜ばしく思います。これは新しい機能セットであり、クラウドからの最新の管理へのスムーズな移行を支えるものです。Windows 10 デバイスは Fall Creators Update により、オンプレミスの Active Directory (AD) と Azure AD に同時に参加できるようになりました。
共同管理はこの拡張を利用して、デバイスを Configuration Manager エージェントと Intune MDM の両方によって管理できるようにします。最新の管理への移行には、もはや崖を飛び降りるような覚悟は不要です。共同管理を使用すれば、組織に合った方法とペースで、それぞれの道を一歩ずつクラウドに向かって進むことができます。
これは、Configuration Manager コンソール内で扱ってデバイスを管理下に置くと同時に、デバイスを Intune による管理に参加させることが容易にできるようになっています。そのため、クラウドに移行するワークロードを選ぶだけで (これは文字どおり、スライダー バーで Configuration Manager から Intune に移動するだけです)、それがクラウドに移動します。
この共同管理シナリオでの Microsoft 365 独自の機能の 1 つは、Configuration Manager と Intune の間で常にやり取りが行われるという点です。ワークロードを移行する過程で、ユーザーとデバイスの各属性に対して権限を持っているソースがどちらであるか (Intune または Configuration Manager) がわかり、競合するポリシーが適用されることを避けられます。
これにより、Windows 10、およびクラウドからの最新の管理への移行が劇的に加速します。
* * * * *
私にとって、この記事を書くことは思い出の小径を歩む、この上ない体験でした。SMS、Configuration Manager、Intune という組み合わせは、私の生活、家族の生活、そしてプロジェクトに関わった数千人のエンジニアの生活に大きな影響を与えただけでなく、今までそれを使用し、また現在使用している数百万人もの IT 担当者の生活にも影響しています。私はこの製品とこのコミュニティを愛しています。
また、Configuration Manager の歴史をまとめた最新のドキュメンタリーは心から楽しめるものでした。しかし、それは第 1 部に過ぎません。第 2 部の方がはるかに重要です。それは、第 2 部が皆さんによって作られるからです。
Ignite で、Microsoft のブースで管理とセキュリティのセクションにぜひ立ち寄り、ご自身の体験をお話しください。簡単な案内をこちらにご用意しました。
Ignite に参加されない場合でも、簡単に関わりを持つことができます。Configuration Manager にまつわる思い出話や体験談を、こちら aka.ms/ConfigMgr25 からアップロードしてお伝えください。基本的な手順はこちらです。
いただいた投稿を元に第 2 部を動画で作成し、次のようなタイトルを付けたいと思います。
「Configuration Manager の歴史を作った人々」
投稿をお待ちしています。
_______________________________________________
