Intuneの同期 について
今日はみんなお困り、Intune の同期についてです。
このブログでもIntune の同期についてはこれまでにも何回か取り上げてきました。そんな中、米国マイクロソフトのイベントでIntune 同期に関わるセッションがあったので、まとめ記事を作ってみました。
この動画を見ていたら過去に自分がIntune同期の仕組みについて解説したこちらの記事に近いところが色々あったので
過去に自分が書いた記事も引用しながら同期の仕組みについて見てみたいと思います。
MSさんの肩を持つわけではありませんが
Intuneとしてはできるだけ早く設定を適用させたいと考えている一方で、
・同じアクションに対して同じ結果が同じ時間だけかかるようにすること
・異なるプラットフォームでも異なるデータセンターでも同じように利用できるようにすること
・小規模から大規模までカバーすること
という非常に多様な状況下で結果が求めるという、かなり困難なミッションを化せられています。
だからこそ、ちょっと変わった同期のアーキテクチャを採用している(採用せざるを得ない)ということはアーキテクチャの話をする前に知っておきたいことです。
同期ロジック
Intune同期プロセスに「チェックイン」という表現が使われますが、そのチェックインプロセスには次の3つがあります。
・シングルデバイス：
管理者やユーザーが特定のデバイスに対して行う操作 (デバイスの同期とかワイプなど)
・メンテナンス：
クライアント側からバックグラウンドで行われるチェックイン操作
・変更ベース：
Intuneで何かの変更があったときにデバイスに通知を行いチェックインする方法
この3つは私が以前の投稿で書いた手動で同期、タスクスケジューラで設定したタイミング、通知を受けたタイミングの3つに当たるものです。
それぞれのチェックイン操作について特徴を見ていきましょう
変更ベースのチェックイン
変更ベースの「変更」とは
・既にあるポリシーやアプリの割り当てに新しいユーザーやデバイスグループを追加する
・特定のポリシーの値を変更する
・グループのメンバー変更
・ストアアプリの新しいバージョンが登場した
などのことを指し、これらが発生するとその情報を対象のデバイスに対してプッシュします。プッシュするということは優先度の高いチェックイン方法だということがわかります。
変更ベースのチェックインでは上記の変更が保留中のデバイスがいる場合にはそのチェックインを常に優先される仕組みになっています。
ただしシャットダウンしていたなどの理由で通知を受け取れなかったデバイスがいる場合、チェックインの処理ができる範囲の中で通知は繰り返し行われることになります。
なお以前の投稿ではプッシュ(通知)にはWindows Notification Serviceが使われ、通知を受けたクライアントはomaclient.exeを呼び出して命令を投げていると話をしました。
メンテナンスチェックイン
メンテナンスチェックインの「メンテナンス」とは
・コンプライアンスポリシーの準拠/非準拠の更新
・クライアント登録証明書の更新
・Intune クライアントアプリの最新状態維持
などのことを指します。また、ポリシーやアプリケーションの更新にもメンテナンスチェックインが使われます。
メンテナンスチェックインにはタスクスケジューラから実行するスケジュールベースのチェックインが含まれますが、このチェックインでコンプライアンスポリシーのチェックを行っています。よくコンプライアンスポリシーの状態がいつまでも変わらないって話を聞きますが、コンプライアンスポリシーをつかさどるメンテナンスチェックインは変更ベースのチェックイン時には処理しないので、次のスケジュールにならない限りコンプライアンスポリシーの状態が変わらないってことが起きるのです。
メンテナンスに当たる作業はすべてを平等に扱うわけではなく、デバイスの変更につながる可能性が高いチェックインに対して優先順位を設けて処理するようにしています。
例えばその日初めてサインインしたというタイミングだったり、コンプライアンスチェックに使われるようなデバイスの変更が生じたい場合など。
また、メンテナンスチェックインは必ずしもスケジュールどおりに実行するとは限らず
直近でチェックインしたばかりであれば、スケジュールどおりに行うチェックインはわざと遅延させて無駄なチェックインが発生しないような工夫をしています。
なお、メンテナンスチェックインにはテナントや時間でチェックイン数の上限が設けられていて、上限値に達すると(変更ベースのチェックインに支障をきたさないようにするために)、チェックイン要求は延期されます。
[同期] ボタンを連打しても同期されない！って話をよく聞きますが、連打するから同期されないってことになるのです。
チェックイントラフィック
チェックインの謎を解き明かす話からはちょっと外れますが、こんな話があったので取り上げさせてください。
Intuneのチェックインのトラフィックは変更ベースが15～20%、残りがメンテナンスチェックインを含むトラフィックになります。「残り」の部分を構成しているのがスケジュールタスクから実行するチェックイン(詳細はこちら) でこれが一番大きな割合になっていて、その他、サインイン時、デバイス登録時、同期ボタンを押したとき、などなどになっています。
新しいチェックインの仕組み：Declarative Device Management
これまでIntuneのチェックインではチェックイン中にポリシーA,B,Cの設定を適用する必要があった場合、チェックインプロセスの中でA,B,Cを順番に受け渡ししていました。
そして、それが途中で失敗すると次のチェックインでまた1からやり直しをしていました。これはすごく効率の悪い仕組みでした。
この課題を解決するためにIntuneでは新しくDeclarative Device Management (DDM) という仕組みを採用するそうです。
(一説によると現在既に従来型とDDM型は平行運用されていて、DDMの設定についてはレジストリのHKLM\Software\Microsoft\Entrallments\GUID\LinkedEnrollment から確認できるそうなのですが、私のデバイスではそのレジストリ項目を確認できませんでした)
DDMではデバイスの構成に関わるメタデータ (A,B,Cの情報がすべて含まれる情報だとおもってください) を一度の通信でまとめて渡してしまいます。そのため少ない通信プロセスでチェックインが完了できるメリットがあります。
この仕組みはPowerShell DSCをイメージしてもらうとわかりやすいと思います。
PowerShell DSCは理想の設定を構成ファイルとして作成しておき、そのファイルをクライアントに配布します。
クライアントは構成ファイルの状態と自分のデバイスの状態を比較し、違う点があれば自動的に修正するというものなのですが、これと同じことをIntuneクライアントでも行うことになります。
Intuneで設定した、すべてのポリシーやアプリの設定はひとつの構成ファイルにまとめられるので、デバイスはこれまでのIntuneのチェックインのように毎回ポリシーの設定を受け取らなくても、ローカルで適用すべきポリシーやアプリを把握できます。また、構成ファイルとの比較結果としてIntune側に送信する必要のあるレポートやコンプライアンスポリシーの状態情報は随時Intuneに送信されます。これによりコンプライアンスポリシーの状態がいつまでたっても変わらない状態は解消されると信じています！
最後にチェックインの結果については新しいレポートが用意される予定で、これを見る限りチェックインプロセスが追跡できるので
チェックインが行われない場合にはどこに問題があるのかがわかりやすくなるようです。
最後に
YouTube動画を中心に自分の過去の投稿なども振り返りながらまとめてみました。変更ベース、メンテナンス、シングルデバイスという3つのチェックイン方法があり、変更ベースが優先されるのでメンテナンスチェックインは時刻どおりに行われるとはかぎらないこと、そしてポリシーのチェックなどはメンテナンスチェックインが行われるたびにIntuneと通信をしていました。しかしDDMの登場により、
・基本的なポリシー設定等は構成ファイルがあればローカルで完結
・メンテナンスチェックインを待たず、継続的にコンプライアンスポリシーの状態をチェックし、結果を報告
・Intuneとの通信回数・トラフィックは減少
というメリットがあります。これらにより、これまで私たちが同期で味わってきた苦い経験を解消できることを願っています。
