テレワークが普及する中で、各企業のシステム管理者から注目を集めている「インテル vPro プラットフォーム」。そのすべてを知り尽くした“匠”こと牧真一郎氏によると、プラットフォームの登場によって、いよいよサーバー管理の現場ではリモートデスクトップ機能が利用されるようになっていったという。
連載の第4回目では「インテル vPro プラットフォーム」がリリース後に、どのように進化していったのかを探っていきたい。
リモートデスクトップがついに実装、「ブルースクリーン」もリモート表示！
――前回は2006年の「インテル vPro プラットフォーム」登場と、それに伴うリモート管理の現場における変化について話を伺いました。その後、このプラットフォームは、どのように進化していったのでしょうか？
牧氏：これは前回もお話しましたが、リモート操作への要望が高まっていたため、その強化が進んでいくことになります。
――つまり、リモートデスクトップ機能の実装ですね。
牧氏：AMTに実装されていたSOL（Serial Over LAN）では、BIOSのセットアップなどの場面で、テキストベースでのリモート操作は可能でした。ただ、これも前回お話したように、GUIを使用したOSのインストールや修復ができないなど、いくつかの制限があったのです。
さらに、BIOS Setupでも日本語や中国語などのような2バイト文字の表示が可能になったり、UEFIに移行してGUIベースの設定画面が実装されたりし始めるようになりました。こうした背景もあって、AMTではリモート操作機能の強化が望まれるようになっていきます。
――リモートデスクトップ環境は、どのようにして実現されたのでしょうか？
牧氏：リモートKVMはインテルME（Management Engine）のAMTファームウェアに、RealVNC社からライセンスされたVNCサーバーを組み込んだことで実現しました。内蔵グラフィックコントローラーからの出力を、RFBというプロトコルに乗せて、管理者側のVNCクライアントと通信を行います。
ただ、内蔵グラフィックを利用しているため、デスクトップPCやワークステーションに外付けのビデオカードを追加し、内蔵グラフィック機能が無効になってしまうと、KVM機能は利用できませんでした。モバイルPCでは他社のグラフィックコントローラーが載っていても、内蔵グラフィックコントローラーに切り替えることができたので、この機能を利用できたのですが……。
ちなみに、インテルMEとネットワークコントローラーはスタンバイ電源で動作するので、PCの電源が落ちた状態でも、VNC接続を行うことができます。ここに、IDE-R（IDE Redirection）を組み合わせることで、OSインストールを、フルリモートで行えるようになりました。ブルースクリーンの内容もリモートで表示できるので、展示会ではよくデモを見せていましたね。
システム管理者の方は当時のリモートKVMを、主にトラブルシューティングに使っていたようです。遠隔地のPCに不具合が発生したときに、現場に行かなくても画面が確認できる、いちいち電話越しに「コントロールパネルを開いて……」と指示をしなくても遠隔操作ができるというのは、当時としては画期的でした。
――スタンバイ電源だけで、そこまで動作するとは……。リモート管理でできることは、ほとんどPCが起動している時と変わらないですね。
牧氏：この頃にチップセットのノースブリッジがCPUと統合されたので、インテルMEはRISCベースの極小なマイコン（32bit）として、CPUに組み込まれるようになりました。ファームウェアはBIOSと同じフラッシュメモリーに書き込まれ、PCのメインメモリーの一部を割り当てて使っています。
ただ、リモートKVMなどで大量のデータを扱うようになったこともあり、このタイミングでインテルMEが強化されています。これにより、AMT以外にも、
- 著作権保護されたメディアの暗号処理（PAVP：Protected Audio-Video Path)
- 盗難防止機能（AT：Anti-Theft Technology）
- 認証の強化（IPT：Identity Protection Technology）
といった役割をシステム上で担うようになっていきます。とはいえ、AMT以外はスタンバイ電源での動作時には使われませんが。
――その後、AMT6.0の登場で、AMTは現在の形にかなり近づいたかと思います。それまでには、どのようなバージョンアップが行われていたのでしょうか？
牧氏：発表当初の「vPro」に採用されていたAMT2.0は、デスクトップPCだけを対象としていました。しかし、「Centrino Pro」にAMT2.5が搭載されたことで、モバイルPCでもAMTを利用できるようになっていきます。
――モバイルPCに搭載するとなると、無線LANにも対応していたのでしょうか？
牧氏：それはまだ限定的でしたね。残念な事に電源が入っている時しか、AMTでの通信ができませんでした。電源状態に関係なく無線LANが使えるようになったのは、2008年に登場した「Centrino 2 vPro」に搭載されたAMT 4.0からですね。インテル EMAで使用しているリモートアクセス機能（CIRA：Client Initiated Remote Access）のサポートも、同じくAMT 4.0からになります。
無線LANは有線LANとはアーキテクチャが異なり、ソフトウェアに依存する部分がとても大きいんです。 新しい無線LANの規格がリリースされたり、規格そのものがドラフト版から正式版になったりした時などは、ソフトウェアのアップデートなどで柔軟に対応できるのですが、その一方で動作するには必ずデバイスドライバーが必要になります。
これは、普通にPCを使う分には何の問題もありませんが、帯域外で無線LANを使う場合には、その制御を行うインテルME用のデバイスドライバーが必要になります。また、無線LANの接続プロファイルも、OSとは別にME側でも保持する必要があるんです。
――なるほど。その1年前にリリースされたAMT3.0は、どのようなバージョンだったのでしょうか？
牧氏：それまでのAMTでは、SOAP（Simple Object Access Protocol）というプロトコルによる独自のAPIを使用していたのですが、このプロトコルをSOAPの上位レイヤーにあたるWS-Management（Web Services for Management）に置き換えました。
さらに、AMT5.0は当時制定されたばかりの標準規格「DASH（Desktop and Mobile Architecture for System Hardware）」に準拠しています。これにより、AMTの機能のうち、電源制御などのDASHで規定されている部分はすべてDASH準拠となり、常に上位互換の形を取るようになりました。まぁ、PCを利用する側からすると、全く目に見えない部分の話ではありますが（笑）。
当時はデスクトップPC用とモバイルPC用に、AMTが交互にリリースされていたのです。デスクトップPC用は2.0→3.0→5.0と、モバイルPC用は2.5→4.0とバージョンが上がっていて、製品事業部が足並みを合わせたAMT6.0から両プラットフォームのバージョンがそろうようになりました。
――APIの変更や標準規格への準拠によって、実現した機能などがあれば教えてください。
牧氏：WS-Management がWindowsなどのOSに標準で搭載されるようになったこともあり、OSのコンポーネントを丸々流用できるようになりました。アプリケーション側でプロトコル部分をあまり気にしなくてもよくなったので、結果として安定度は増したと思います。
従来のSOAPベースのAPIも、しばらくの間は併用できる状態でしたが、ファームウェアの容量にも限りがあることから、AMT 6.0以降の新機能はWS-Managementでしか扱えなくなっています。そのうちにSOAP APIの搭載も廃止されましたね。
DASH はASFの時にもお話しした、DMTFという標準化団体で制定された規格です。この規格に対応した管理アプリケーションでは、「AMD PRO」のようにAMT以外のDASHに準拠した管理機能が混在していても、特に意識すること無く管理することができます。
（次回に続く）