皆さんこんにちは。国井です。
Microsoft Intuneと言えば「なんもわからん」という言葉が使われるほど、謎に感じることが多いと思います。どうして謎に思うかと言えば
「設定したことがいつ反映されるかわからない」
このことに尽きるのではないかと思います。
MECM/SCCMをこれまでに使ってきた立場からしてみれば[同期]ボタンを連打してナンボ。
システム管理製品なんてこんなもんだよなと思っていたりもします。
しかし、お客さんにそんな説明は通用しません。
そこで今日はIntuneってどんな時に同期が行われるのかを整理し、
少しでも心穏やかにIntuneを使えるようにトライしてみたいと思います。
Intuneの同期とチェックイン
Intuneで設定したポリシーやアプリなどは同期を行うことにより適用すべき存在を知り、そしてデバイスに適用を行います。同期を行ったときに自分に適用すべき存在があるかどうかを判断するために行うプロセスをチェックインと呼びます。
Windowsの場合、チェックインは次の3つのタイミングで実行されます。
1. タスクスケジューラで設定したタイミング
Microsoft Learnの解説ではデバイスを登録したばかりだと短い間隔でチェックインを行うけど、登録してから2時間以上経過したデバイスは8時間ごとにチェックインを行うとあります。
これはタスクスケジューラに登録されたタスクによってコントロールされていて、タスクが実行されることでチェックインが開始します。タスクスケジューラに登録されたタスクの詳細についてはこちらにも書いたので参考にしてみてください。
このケースではタスクスケジューラのタスクを見るとわかると思いますがdeviceenroller.exeを実行してチェックインを開始するような仕組みになっています。
2. 手動で同期したタイミング
Windowsの設定アプリからアクセス可能なこの画面。同期ボタンを押してチェックインを開始するというIntune使いなら誰もが知るチェックイン方法だと思います。
同期ボタンをクリックして行うチェックインはsvchost.exeからomadmclient.exeを呼び出して開始する仕組みになっています。
このことはイベントビューアの[アプリケーションとサービス ログ]-[Microsoft]-[Windows]-[DeviceManagement-Enterprise-Diagnostics-Provider]-[Admin]からイベントID 256を参照すると確認できます。(※イベントログだとomadmclient.exeを実行した事実までは追跡できません)
なお、同期ボタンはIntune管理センター画面から特定のデバイスを選択して実行することもできますが、この場合にはdeviceenroller.exeが実行された履歴がログで確認できました。
3. 通知を受けたタイミング
通知というのはチェックインをしなさいという命令でMicrosoft Intune側から「あなたのデバイスにインストールすべきアプリがあるよ」などの通知がデバイスに対して飛んでくると即時にチェックインを開始します。
Microsoft Learnの解説では次のような説明があります。
通知がトリガーされるさまざまな操作があります。 たとえば、ポリシー、プロファイル、またはアプリの割り当て (または割り当て解除)、更新、削除などが行われたときです。
ポリシーを割り当てた時って、すぐにチェックインが始まらないのでホントかな？とも思いますが、少なくとも必須でアプリを割り当てたり、Intune管理センター画面からデバイスに対して今すぐウイルススキャンを行うように命令したりすると、この方法に当てはまると思っています。
通知自体は Windows Notification Service (WNS) と呼ばれるサービスがつかさどっていて、Intune自体がクライアントに対して通知が必要と判断するとWNSを使って通知を行い、チェックインをプッシュで開始する仕組みになっています。WNSによる通知きっかけでチェックインが始まった場合もdeviceenroller.exeを実行したとイベントビューアのログには書かれていましたが、実際に通知経由で行われた命令をMDEで追跡してみるとsvchost.exeからomaclient.exeを呼び出し、そこから命令を実行しているんですよね..
ちなみにWNSはwns.windows.comまたはnotify.windows.comと通信を行い、セッションを確立した上で通知の待ち受けをするモデルなので通知によるチェックインが行われたか？ということを通信履歴から追跡することはなかなか難しいです (少なくともMDEからの追跡は断念しました)。
イベントビューアを参照する
ここまで見てきたように3種類のチェックイン方法があるけど、結局どれが有効なのか？についてはわからずじまいだったわけですが、少なくともどのチェックイン方法でも共通するのはその処理結果はイベントビューアで参照できるってことです。
ですので同期ボタンを押しながら文句を言うくらいなら、その前にイベントビューアを見て「処理をしようとしているのか？」を確認されるのが良いかと思います。この辺の情報はまったく探すことができなかったので、私なりの解釈でまとめておきます。
・イベントID 256：チェックインプロセスに使用したプロセス名の確認
・イベントID 202：OMA-DMサーバーのメッセージを受信しました(ポリシーを受信したってこと？？)
・イベントID 209：OMA-DMセッションの終了
・イベントID 814：ポリシーの適用 (すべての適用を網羅していないような..)
おまけ
構成プロファイルの設定って二度適用されるの？というのを探るためにIntuneでご覧のような構成プロファイルを作ってみました。
Microsoft Edgeの設定ですが、Edgeの設定は適用後にユーザーが設定変更できるため、構成プロファイルを割り当てるたびにこの設定が再適用されるか？というテストです。事前に2つの設定のうち、ブラウザーの起動時に開くサイトだけを先に割り当てておき、ユーザーが設定をbing.comに変えておきました。
設定を行った後にクライアントデバイスのイベントビューアの[アプリケーションとサービス ログ]-[Microsoft]-[Windows]-[DeviceManagement-Enterprise-Diagnostics-Provider]を参照してみました。すると新しく設定した検索プロバイダーの検索URLを設定として適用したことはログから確認できるのですが、
過去に適用したブラウザーの起動時に開くサイトの設定は適用されませんでした。
(※タスクスケジューラからチェックインを行っても、同期ボタンをクリックしてチェックインを行っても同じ結果でした)
つまり、構成プロファイル等で設定した内容は最初だけ適用するけど、同じ設定は複数回適用されることはないことがわかりました。Active Directoryをご存じの方であればグループポリシーと同じ動きだってことに気が付くと思います。
よくコンプライアンスポリシーで非準拠になったデバイスが設定を見直し、準拠になるように再構成したのに非準拠の状態がいつまでたっても変化しないという問題があると思います。
これに対するワークアラウンドとしてコンプライアンスポリシーを再作成してくださいって話を聞くことがあるんだけど、それって一度作成・設定したポリシーが再適用されることがないからっていうのも影響しているように感じますね。
