Windows Autopilotを使ってデバイス展開している環境で、「展開用のグループ」と「その後のアプリ・ポリシー配布用のグループ」を同じグループで兼用してしまい、
後から身動きが取れなくなるケースをよく見かけます。この記事では、Autopilotの「Group Tag」を使った動的グループ設計と、安全なロールアウト手順をまとめます。
■ よくある設計ミス
Autopilotのハイブリッド Azure AD 参加デプロイプロファイルにアサインしているデバイスグループを、
そのままアプリ配布やポリシー適用の対象グループとしても使ってしまう設計です。
これがなぜ問題かというと、
・デプロイプロファイルの割り当ては「どのグループ経由でも展開プロファイル自体は同じものが適用される」ため、割り当て元グループはそれほど重要ではない
・一方でアプリ配布・ポリシー適用は「対象を細かく分けたい」ニーズが後から必ず出てくる
という、2つの異なる目的が1つのグループに混ざってしまい、後から分離しようとすると既存デバイスへの影響を気にしながらの作業になり手間が増えます。
■ 設計パターン: Group Tagを軸にした動的グループ
Windows Autopilotのデバイス登録時に付与する「Group Tag」(発注ロットや用途などを表すタグ)を、Entra IDの動的グループのメンバーシップルールで参照する設計です。
メンバーシップルールの例(値は環境に合わせて置き換え):
(device.devicePhysicalIds -any (_ -eq “[OrderID]:SITE-A”)) and (device.deviceOwnership -eq “Company”)
このように「Group Tagの値」を条件にすることで、
・Autopilotのデプロイプロファイル用グループ(ハイブリッド参加のトリガーになる方)
・アプリ・ポリシー配布用のグループ(用途別に細分化したい方)
を、同じGroup Tagを起点にしつつ別グループとして設計できます。デプロイプロファイル側は購入・登録時点のGroup Tagにひもづくため一度決めれば安定していますが、
配布用グループ側は後から柔軟に条件を追加・変更できる形にしておくのがポイントです。
■ 安全なロールアウト手順
本番グループのメンバーシップルールをいきなり変更するのはリスクがあります。
実務では次の手順が安全です。
- 本番グループとは別に、同じ条件をテストするための小さいグループを先に作る
例えば対象デバイスを1〜2台に絞れる条件(特定のシリアル番号など)でテスト用の動的グループを作成します。 - テストグループが意図通りのデバイスだけを拾っているか確認する
条件式の書き方次第では、意図しない広い範囲のデバイスを巻き込んでしまうことがあります。少数のテストデバイスで動作を確認してから次に進みます。 - 確認が取れたら本番グループのルールに反映する
このとき、本番グループに既存のデバイスがすでに大量に入っている場合は、ルール変更によって対象が急に増減しないか事前にシミュレーション(Entra管理センターの「メンバーシップのプレビュー」機能など)で確認してから適用します。
■ まとめ
Autopilotの展開とその後の運用(アプリ配布・ポリシー適用)は目的が異なるため、グループを分けて設計するのが基本です。
Group Tagを共通の軸にしつつ、テスト用の小さいグループで動作確認してから本番ルールに反映する、という2段階の進め方でリスクを抑えられます。
コメント