皆さんこんにちは。国井です。今回は Intuneの同期に時間がかかる理由 について考えてみたいと思います。
Microsoft Intuneで構成プロファイルを設定したり、アプリを展開したりするときに
その設定が反映までに時間がかかる経験って、Intuneを使ったことのある人なら誰でもあるかと思います。
この部分だけを切り取れば「使えない」サービスってことになるんだけど、
私はこれって理由があってのことではないかと思っています。
結論を先に言えば「大規模な環境で利用できるようにするため」
今日はその理由をここに示してみます。
大規模な環境では負荷も大規模
従業員数で言えば10000人を超えてくるような環境の場合、みんなで同じ製品を使えば同じアーキテクチャなので、同じタイミングで何かの処理をするだろうし、同じタイミングで通信を発生させます。更新プログラムの適用を考えてもらえればわかりやすいけど、数GBもある機能更新プログラムを皆で同じタイミングでダウンロードしたら会社のネットワークは阿鼻叫喚な事態になると思います。そうしたことを回避するために「今すぐ」ではなく、タイミングをずらしたり、キャッシュを活用したり、色々な工夫をするわけです。それはIntuneの同期においても同じで「今すぐ」に実行することが必ずしも正義ではないのです。
IntuneはSCCMの流れをくむサービス
クラウドベースのシステム管理製品であるIntuneが作られるよりも遥か昔、オンプレミスのシステム管理製品としてSystem Center Configuration Manager (SCCM)と呼ばれる製品がありました (現在の名称はMicrosoft Configuration Manager)。
この製品はオンプレミスのWindowsサーバーやクライアントの管理を目的とした製品で、1999年にリリースされたSMS2.0以来、ずっと同じアーキテクチャで製品を提供してきました。その20年以上変わらないアーキテクチャとは「設定を即時反映することを目的としない」アーキテクチャです。一見するとバカげていると思うかもしれないけど、このことは大規模な環境においてはとても重要な要素なのです。
ここにあるデータは私が2000年当時にSMS(SCCM)の講師をしていた時に使っていたテキストのメモで、SMS2.0時代のインベントリ収集プロセスを表しています。メモに書いてあるようにクライアントで収集したデータをいきなりDBに書き込まず、複数のプロセスを段階的に経てDBに書き込まれていることがわかります。段階的なプロセスを踏むことで、処理待ちのデータをうまく捌くことを実現しているのです。こんな面倒なことをすれば時間がかかるのは当たり前なんだけど、それは同時にどんなに大量なデータであっても確実に処理を完結させる仕組みでもあるのです。
Intuneはこのような考え方をクラウドに持ち込んだサービスなのです。
現在のIntuneの処理形態
Intuneの内部的なアーキテクチャについては公式ドキュメントを含めて多くを語られていないので、わからない部分も多いですが、現時点で明らかなのは同期プロセスには主にDeviceEnroller.exeが使われることです。DeviceEnroller.exeはc:\windows\system32フォルダーに格納されるWindows標準のプログラムで、次のようにオプションスイッチをつけて実行することでIntuneとクライアントの間での同期が行われます。
c:\windows\system32\deviceenroller.exe /o “ID番号” /c
ID番号はデバイスごとに異なるもので、調べ方としては以下のブログに記載した方法の他、
レジストリではHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\ApplicationDefaults\DefaultAssociationsConfiguration_WinningProvider や
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\Diagnostics\Enrollment などから確認することができました。
■ ■ ■
話を元に戻します。
公式ドキュメントによるとIntuneの同期は8時間に一度の間隔で行われると書いてあります。これはタスクスケジューラに設定されたタスクで8時間に一度DeviceEnroller.exeを実行するように設定されているからです。こちらはタスクスケジューラの[Microsoft]-[Windows]-[EnterpriseMgmt]からID番号の入ったフォルダーを開いた画面です。
Schedule #1から#3までのタスクが登録されており、#3が8時間ごとにDeviceEnroller.exeを実行するように設定されているタスクに当たります。このタスクで実行しているコマンドのオプションスイッチを見てみると次のようになっています。
%windir%\system32\deviceenroller.exe /o “ID番号” /c /b
オプションスイッチの公式な解説が見当たらなかったので憶測になってしまうのだけど /b はBackgroundを表すものではないかと思います。つまりバックグラウンドで「お手すきのタイミングで」実行するというモードなのかと思います。だからこそ8時間に一度の同期が行われても、すぐに設定が反映されないということが起きるのでしょう。事実、DeviceEnroller.exeのオプションスイッチでご覧のように /b の代わりに /q を使うとすぐに同期が行われるようになります。
%windir%\system32\deviceenroller.exe /o “ID番号” /c /q
こういうオプションがありながら普段から使わないことからも即時反映よりも安定的な反映を優先している様子がうかがえます。
まとめと今後のIntuneに望むこと
ここまでIntuneがなぜ即時に同期が行われ、設定が反映されないかについて見てみました。
あくまでも私の憶測に基づくものなので、これが真実であるかはわかりません。
しかし、SCCMやIntuneの仕組みを見る限り、明らかに即時性よりも大規模な環境での安定的な動作を優先しており、そのことが、なんだかんだで多くの企業でIntuneが採用される理由のひとつなのだと思います。
一方、Intuneが人を待たせるサービスなのだとしたら「待っていれば問題解決するのか？」それとも「トラブルが起きているから、いくら待ってもムダなのか？」の切り分けはできるようにしてほしいです。それはSCCMのようにログをもっと充実させることによって実現できると思います。イベントビューアにログを残すのも良いんだけど、IntuneManagementExtension.log ファイルのようにテキストファイルであってくれるとログの追跡もしやすくて、ありがたい。そんな未来であることを願っています。
