Intune / Autopilotを体験する

注：本エントリは試験対策記事ではありません。あくまでIntune / Autopilotの体験記事です。

Microsoft 365 認定試験の一つである 『エンドポイント管理者アソシエイト』 (MD-102)というものがあります。
模擬試験などをやり込むだけで受かっている人も居るようなのですが、筆者はテキストの読み込みや暗記が絶望的に苦手なため、ある程度は実機に触れてからでないと太刀打ちできないと判断して仕方なく私費で環境を整えました。その時のメモを残しておきます。

資格試験が得意な人はこんなことする必要はありません。Udemyなどでひたすら問題をやり込むだけで大丈夫なんじゃないでしょうか。

この手の記事は無数にあるはずですが、クラウド方面の記事は1～2年で内容が陳腐化するので同じようなものが沢山あっても良いかと思った次第です。

本記事では「こうしましょう」という書き方をしている箇所がありますが、それは筆者が単に一通り試した上で執筆しているため、うまくいったことに関してのみ自信を持って書いているというだけです。決して実戦経験があるわけでは無いので、あまり過信はしないでください。

なぜMD-102を目指すのか

筆者のゴールはWindows Server Hybrid Administratorの取得または取得相当の知識を蓄える事にあります。そういうこともあってAZ-800（もうすぐ廃止予定らしい）方面の知識を仕入れておきたいと思っていたのですが、筆者はAWSやAzureのようなサービスに関する知識が殆ど無く、さらにEntra IDの文献を読んでもピンときませんでした。
技術的な構造を考えると上位レイヤーに位置するIntune/Autopilotを先に学ぶのは非効率だと思いますが、まずはEntra IDの活用事例であるIntuneを実際に触ってみることで、クラウドサービス全体の構造を肌で理解しようと考えました。

この記事のゴール

本記事のゴールは以下の状態を自分の手で再現することです。

工場出荷状態（またはリセット済み）のWindowsパソコンの電源を入れ、Microsoftアカウントの認証だけ済ませたら、あとは自動で以下がすべて完了する。

• Entra IDへの参加とIntuneへの登録
• 指定したWin32アプリケーションのインストール
• BitLockerの有効化
• Edgeの初回ウィザードのスキップ
• コンプライアンスポリシーの適用

本記事では作業前と作業後との比較を通じてIntuneの各機能が何をしているのかを体感的に理解することを目的としています。
ITスタッフが手作業でセットアップしなくても「使える状態のPC」が出来上がるという、Windows Autopilotの基本シナリオを想定しています。

AutopilotというのはAnsibleのようなIaCとは違い、コードだけで環境を完全に揃える技術ではありません。どちらかと言えばMDT(Microsoft Deployment Toolkit)のような従来のOS展開自動化の流れを継承しつつ、クラウド管理（Intune）と組み合わせて デバイスの初期セットアップを最小化することに特化した仕組みだと筆者は理解しています（OOBEも健在でした）。

これをゴールに据えると、Intuneのどの機能が何のために存在するのかが自然と見えきそうな感触があります。

理想はインターネット経由で自宅のネットワークに自動的にVPN接続し、ドメイン参加することなのですがこれは環境整備が大変そうなのでいずれ本命のHybrid環境の構築の記事を書く時に触れようと思います。

本記事の対象読者について

本記事は、個人でMicrosoft 365 Business Premiumを契約し、検証用テナントをゼロから自分で作成した環境を前提としています。

会社から払い出されたアカウントでIntuneやAutopilotを試したい方は、テナントの管理権限や設定可否が会社のポリシーによって異なると思うので社内のIT部門に確認してください。

スキル的には、OSの標準イメージに独自のレジストリ変更やバッチファイルを仕込み、パソコンのキッティングを半自動化した経験があるような人だと全体像は把握しやすいと思います。
ローカルグループポリシーなどの知識があればIntuneの設定時にニヤリとするシーンも多いと思います。

必要なライセンスについて

Windows AutopilotはMicrosoft Intuneと連携してデバイスの自動プロビジョニングを行います。そのためIntuneのライセンスが必須です。
個人でAutopilotを試す場合、最も手軽にIntuneライセンスを入手できるのはMicrosoft 365 Business Premiumのようです。

月額約4400円（1ユーザー）程度で契約でき、IntuneだけでなくMicrosoft Entra ID P1も含まれているようです。
数年前は無料で試す方法があったり、別料金のコースがあったようなのですが2026年6月現在ではもっとも安く済ませる場合はこれだと思います。違っていたらご指摘頂けると幸いです。
（新規のAzureユーザーだと無料で試せるようなサービスがあるかもしれませんのであまり真に受けないでください）

テナントとアカウントについて

Business Premiumを契約すると、Microsoftは「テナント」と呼ばれる組織単位の管理領域が自動的に作成されました。テナントはMicrosoft Entra ID上の組織そのものだと思ってください。

↑申込時のアカウント設定画面

筆者は数年前にMicrosoftアカウントを取得し、Azureにもサインインをしたことがあるのですが、今回はこの時のMicrosoftアカウント（GmailアドレスをMicrosoftアカウントとして登録したもの）を使ってBusiness Premiumを新規契約しております。
しかしこれはあくまで購入手続きのための入口です。契約が完了すると、そのテナントのグローバル管理者アカウントとして以下の形式のアカウントが別途払い出されます。

（任意の名前）@（テナント名）.onmicrosoft.com

IntuneやAzure Portalへのサインインや操作は、基本的にはこのonmicrosoft.comアカウントで行います。契約時のMicrosoftアカウント（GmailやOutlookなど）でサインインしようとしてもテナントの管理画面には入れないので注意してください（筆者は少し混乱しました）。
その名前が示す通り、Business Premiumはもともと企業向けの製品です。「契約した個人」と「組織の管理者」を分離する思想で設計されているためだと考えます。

本記事の環境

一般的なインターネットサイトに接続可能な環境が必要です。
家庭用のインターネット向きのルーターについては殆どの方はDHCPサーバーを有効にしていると思います。もしStaticの場合は今回はAutopilotの実験ですから、IPの自動割り当てを有効にしておいてください（PCの電源をONにしてMSアカウントの認証を済ませるだけでセットアップが始まる、という状況を目指していますので）。
筆者は仮想環境を使っておりますが、物理パソコンを使って試しても良いと思います。

項目	内容
検証端末	prov-01（仮想環境 vTPM有効）
	OS: Windows11 LTSC 2024
ルーター/DHCPサーバー	インターネット接続用ルーター

prov-01 のリソース・設定

今回は他に動作させるVMが無いので潤沢に割り当てています。Hyper-V前提で書いていますが、VirtualBOXなどでももちろんOKです。

項目	設定値
仮想プロセッサ数	4
RAM	8096 MB
動的メモリ	無効
仮想ディスク	60GB
ネットワークアダプタ（NIC)	1枚
セキュアブート	有効
トラステッドプラットフォームモジュール（TPM）	有効
DVDドライブ	なし（ISOをマウントしたままにしない）

BitLockerのTPMキー保護機能を有効化する際、仮想DVDドライブにISOがマウントされた状態だと処理が失敗します。OSインストール後は必ずDVDドライブをアンマウントまたは取り外した状態にしておいてください。

手順

1.インフラ準備（Entra ID参加・Intune登録）

【1-1】`prov-01`のクリーンインストール

まずはOSのインストールを行い、デスクトップが表示されるところまで作業を進めてください。その後、Powershellコマンドを叩き、デバイスIDハッシュ（ハードウェアハッシュ）を取得します。

実際の企業導入では、PCの購入時にOEMメーカーや販売代理店がMicrosoft CSP（クラウドソリューションプロバイダー）経由であらかじめAutopilotに登録した状態で納品するのが一般的のようです。この場合、IT部門がハッシュを手動で取得・登録する作業は発生しません。
今回は個人による検証なので本作業が必要です。

なお、OSのインストール中に以下の画面（サインイン画面）が表示されている時に一旦シャットダウンを行い、スナップショットを取得される事をお勧めしておきます。

①上記画面が表示されている時にShift + F10 でコマンドプロンプトを開く
②以下のコマンドを実行してシャットダウン

shutdown /s /t 0

③スナップショットを取得して再度OSを起動し、インストールを続行する

sysprepの事がわかる方は:
（この箇所は撤回します）
一旦OSインストールを最後まで終えて、累積更新プログラムをすべて当ててからsysprepを行い、シャットダウン後にスナップショットを取るという方法でも可です。Autopilot開始時にその都度、巨大な更新プログラムがダウンロードされてしまうので待機時間が長くなるためです

【1-2】デバイスIDハッシュを取得する

実は上記③の段階でデバイスIDハッシュ(CSVファイル)を取得することは可能です。しかしそれを行うには仮想ディスクをホスト側から直接操作する必要があるため、本エントリでそのノウハウを取り扱うのは避けたいところです。ですので、お手数ですがデスクトップ表示までセットアップを続行してください。

MSアカウントを入力して作業したくない方は、Shift + F10 でコマンドプロンプトを開き、start ms-cxh:localonlyを実行しても良いと思います。ただ、この技はいつまで通用するかわかりません。

デスクトップまで表示されたら管理者権限でPowershellを起動してください。
以下のコマンドを順番に実行して下さい

# Get-WindowsAutopilotInfoコマンドのインストール
Install-Script -Name Get-WindowsAutopilotInfo -Force

# 実行許可
Set-ExecutionPolicy RemoteSigned

# デバイスIDハッシュ(CSVファイル)格納場所の作成
mkdir c:\HID\

# CSVファイルの出力
Get-WindowsAutopilotInfo -OutputFile C:\HID\intune.csv

c:\HID\にintune.csvという8000バイト程度のファイルが作成されていたら成功です。このファイルをprov-01以外のPCにコピーするなどして、保管しておいてください。

【1-3】インストール直後のOSの状態を把握しておく

必須の作業ではありませんが、AutopilotでPCをセットアップすることでどのような変化があるのかを知っておいた方が良いと思います。たとえば以下のようなステータスです。

• HOSTNAMEの確認

c:\>hostname

表示されるホスト名は一時的なものです。（このあとOSの再セットアップを行いますが、その時にMSアカウントでサインイン後、Autopilotによって正式にprov-01になる予定です）

• Edgeを初回起動したときの動作（通常は ようこそ 画面が表示される）
  Edgeを起動してみてください。すぐにはウェブ接続が出来ません。初回はうざいウィザード画面が表示されるはずです。今回は、この動作を無効にする設定をIntuneで行います。

• シリアル番号の確認(Powershellで実行すること)

Get-WmiObject -Class Win32_BIOS

表示されるシリアル番号はこの後、Intuneにデバイス登録する際に確認が行いやすくなるので意識しておくと良いと思います。なお、シリアル番号はたとえOSを再インストールしても変わるものではないようです。物理PCならシステムボードやCPUを交換したり、VMだったら再作成しない限りは変わらないと思います。ロジックは把握しておりません。

• Entra Join・MDM登録の状態
  もちろん、まだAzureAdJoinedはNOのままです。

c:\>cd c:\windows\system32

c:\Windows\System32>dsregcmd /status

+----------------------------------------------------------------------+
| Device State                                                         |
+----------------------------------------------------------------------+

             AzureAdJoined : NO
          EnterpriseJoined : NO
              DomainJoined : NO
              (以下略)

• BitLockerの有効・無効の状態
  保護はオフのままであることを確認します。

c:\Windows\System32>manage-bde -status
BitLocker ドライブ暗号化: 構成ツール Version 10.0.26100
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

BitLocker ドライブ暗号化で保護可能な
ディスク ボリューム:
ボリューム C: []
[OS ボリューム]

    サイズ:                 59.21 GB
    BitLocker のバージョン: 2.0
    変換状態:               使用領域のみ暗号化
    暗号化された割合:       100.0%
    暗号化の方法:           XTS-AES 128
    保護状態:               保護はオフです
    ロック状態:             ロック解除
    識別子フィールド:       不明
    キーの保護機能:         見つかりません

• 証明書ストアの状態

c:\Windows\System32> certlm.msc

証明書（ローカルコンピューター）
└── 個人
※まだ何も証明書が無い事を確認。

【1-4】デバイスIDハッシュをIntuneポータルにインポートする

ここからはEdgeやChromeでIntuneポータルに接続し、さきほど作成したintune.csvを登録する作業に入ります。

なお、prov-01は既にインターネットに接続できる状態のはずです。ですから、本手順についてはprov-01でEdgeを起動して実施しても構いません。ホストOS側で実施してもOKです。

Intuneポータルにサインインする

https://intune.microsoft.com/

サインインは（任意の名前）@（テナント名）.onmicrosoft.comの方で行ってください。

• [デバイス] - [デバイスのオンボーディング] - [登録] - [Windowsタブ] - [Windows Autopilot] - [デバイス] の順で選択する

• [インポート] を選択し、先ほど出力したintune.csvを登録してインポートをクリックする

• 最大で15分ほど待機する（最新の情報に更新をクリック）

シリアル番号が表示されたら成功です。

【1-5】MDM自動登録の設定【重要・必須】

この設定を忘れると、Autopilot完了後にEntra IDへの参加は成功してもIntuneへのMDM登録が行われないという状態になります。筆者は実際にこれでハマりました。

• [デバイス] - [デバイスのオンボーディング] - [登録] - [Windowsタブ] - [自動登録]

項目	設定値
MDMユーザースコープ	すべて

保存をクリックして完了です。

この設定はEntra IDに参加したデバイスをIntuneに自動登録するためのものです。「なし」のままだとEntra Joinは成功するのにIntuneのデバイス一覧には何も表示されない、という状況になります。Entra IDのデバイス管理画面では「アンマネージドデバイス」として検出されます。

【1-6】Autopilotプロファイルの作成・割り当て

Intuneがデバイスのセットアップ方法を知るための「設計図」にあたるのがAutopilotプロファイルです。どの配置モードを使うか、デバイス名をどうするかといった設定をここで定義します。以下のメニューから設定します。

• [デバイス] - [デバイスのオンボーディング] - [登録] - [Windowsタブ] - [Windows Autopilot] - [デプロイ プロファイル] - [プロファイルの作成] - [Windows PC]

①基本情報

項目	設定値
名前	autopilot_profile_01
すべての対象デバイスをAutopilotに変換する	いいえ

「すべての対象デバイスをAutopilotに変換する」はIntune管理済みだがAutopilot未登録のデバイスを自動変換する機能です。今回はCSVで手動登録済みなので不要です。

②Out-of-box experience (OOBE)

項目	設定値
配置モード	ユーザードリブン
次のようにMicrosoft Entra IDに参加	Microsoft Entra参加済み
マイクロソフトソフトウェアライセンス条項	非表示にする
プライバシーの設定	非表示にする
アカウントの変更オプションを非表示にする	非表示にする
ユーザーアカウントの種類	管理者
事前プロビジョニングされたデプロイを許可する	いいえ
言語（リージョン）	オペレーティングシステムの既定値
キーボードを自動的に構成する	はい
デバイス名のテンプレートを適用する	はい
名前の入力	prov-01

デバイス名テンプレートには%SERIAL%や%RAND:4%といったマクロ変数も使えるみたいです（というかデフォルトでそういう設定になっていました）。複数台を一括デプロイする企業環境ではこれらを使ってユニークな名前を自動生成するのが一般的のようです。今回は1台のみなので固定名にしています。こんなことは普通はしないと思うので現場では気を付けてください。（もし複数台でこのプロファイルを使ってデプロイすると同じhostnameのPCが複数台出来上がってしまいます。それはあってはならない事です）

③割り当て

項目	設定値
包含されたグループ	すべてのデバイス

④レビューと作成

内容を確認して作成をクリック。

【1-7】登録状態ページ（ESP）の設定

ESPはAutopilot中にユーザーが目にする進捗画面です。ポリシーやアプリの適用が完了するまでデスクトップへのアクセスをブロックし、中途半端な状態でユーザーが操作を始めてしまうのを防ぐためにあるようです。以下のメニューから設定します。

• [デバイス] - [デバイスのオンボーディング] - [登録] - [Windowsタブ] - [Windows Autopilot] - [登録状態ページ]

既定のポリシー「すべてのユーザーおよびすべてのデバイス」を開き、設定の編集をクリックする。

項目	設定値
アプリとプロファイルの構成の進行状況を表示します	はい
インストールに要する時間が指定された分数を超えたらエラーを表示します	60
時間制限またはエラーの発生時にカスタムメッセージを表示する	はい
エラーメッセージ	（任意のメッセージ）
エンドユーザーのログ収集と診断ページを有効にする	はい
OOBEでプロビジョニングされたデバイスにのみページを表示する	はい
Windows更新プログラムのインストール（デバイスの再起動を伴う可能性があります）	いいえ
すべてのアプリとプロファイルがインストールされるまでデバイスの使用をブロックする	はい
インストールエラーが発生した場合にデバイスのリセットをユーザーに許可する	はい
インストールエラーが発生した場合にデバイスの使用をユーザーに許可する	はい
これらの必要なアプリがユーザーまたはデバイスに割り当てられている場合、それらがインストールされるまでデバイスの使用をブロックします	すべて

エラーメッセージは実際の運用では社内のサポート窓口情報を記載しておくと良いでしょう。

【1-8】コンプライアンスポリシーの作成

コンプライアンスポリシーは「このデバイスは安全な状態か」を判定するための仕組みのようです。ここで設定した条件を満たしているかどうかでIntuneが準拠・非準拠を判定します。ただしこのポリシー単体では何か動作を強制することは無いようです。

• [デバイス] - [コンプライアンス] - [ポリシーの作成]

項目	設定値
プラットフォーム	Windows 10 以降
プロファイルの種類	Windows 10/11 コンプライアンスポリシー
名前	compliance_policy_01

コンプライアンス設定（システムセキュリティ）

項目	設定値
デバイス上のデータストレージの暗号化が必要	必要
ファイアウォール	必要
トラステッドプラットフォームモジュール（TPM）	必要
ウイルス対策	必要
スパイウェア対策	必要
Microsoft Defenderマルウェア対策	必要
最新のMicrosoft Defenderマルウェア対策セキュリティインテリジェンス	必要
リアルタイム保護	必要

コンプライアンス非対応に対するアクション

アクション	スケジュール
デバイスに非準拠のマークを付ける	即時

割り当て

項目	設定値
包含されたグループ	すべてのデバイス

コンプライアンスポリシー単体では何も強制しません。「判定」するだけです。後述のConditional Accessと組み合わせることで初めて「非準拠デバイスはMicrosoft 365にアクセスさせない」という強制力が生まれます。

【1-9】構成プロファイルの作成（BitLocker）

IntuneからBitLockerをサイレントで有効化するための構成プロファイルです。通常のBitLocker有効化はユーザーの操作が必要ですが、この設定によりAutopilot中に自動で有効化されます。

• [デバイス] - [構成] - [作成] - [新しいポリシー]

項目	設定値
プラットフォーム	Windows 10 以降
プロファイルの種類	テンプレート
テンプレート名	Endpoint Protection
名前	config_bitlocker_01

構成設定

Windows暗号化を展開し、以下を設定する。

項目	設定値
デバイスの暗号化	必要
他のディスクの暗号化に対する警告	ブロック
Microsoft Entra参加中に暗号化を有効にすることを標準ユーザーに許可する	許可
起動時の追加認証	必要
互換性のないTPMチップでのBitLocker	ブロック
固定ドライブの回復	有効にする
BitLocker回復情報をMicrosoft Entra IDに保存する（固定データドライブ）	有効にする

「BitLocker回復情報をMicrosoft Entra IDに保存する」を有効にすると、回復キーがEntra IDに自動バックアップされます。デバイスがロックされた場合でも[Entra管理センター] - [デバイス] - [BitLockerキー]から回復キーを確認できます。

スコープタグ

何もせずそのまま次へをクリック。

割り当て

項目	設定値
包含されたグループ	すべてのデバイス

【1-10】構成プロファイルの作成（Edgeの初回ウィザード抑制）

Edgeを初回起動した時に表示される例のうざい「ようこそ」ウィザードを抑制するプロファイルです。

• [デバイス] - [構成] - [作成] - [新しいポリシー]

項目	設定値
プラットフォーム	Windows 10 以降
プロファイルの種類	設定カタログ
名前	config_edge_01

構成設定

設定カタログの設定の追加からFirst-runで検索し、以下を追加する。

設定名	設定値
Hide the First-run experience and splash screen	Enabled

スコープタグ

何もせずそのまま次へをクリック。

割り当て

項目	設定値
包含されたグループ	すべてのデバイス

【1-11】Win32アプリの登録（7-zip）

今までの章はIntuneポータル上での設定作業が中心でしたが、この章は一味違います。ホストPC側での作業が発生し、専用ツールを使ってインストーラーを変換するという手順が加わります。

なぜ変換が必要か

IntuneはWindowsアプリの.exeや.msiをそのままアップロードできません。
IntuneWinAppUtil.exe（Win32 Content Prep Tool）を使って.intunewinという専用フォーマットに変換することで、Intuneが配布・管理できる形になります。
もちろん複数のファイルやディレクトリを内包できるので、パラメータファイルを読み込んで処理をするスタイルの実行ファイルやスクリプトなどもここでまとめることができます。

サイレントインストールできることが絶対条件

Autopilotのセットアップ中にアプリを自動インストールするには、ユーザーの操作なしに完結する「サイレントインストール」に対応したインストーラーが必要です。
ほとんどの主要なアプリはサイレントインストールに対応しており、7-zipの場合は以下のコマンドがそれにあたります。

7z2601-x64.exe /S

事前準備

以下のファイルをダウンロードしてください。

• 7-zip公式サイトから7z2601-x64.exe（64ビット版）
• Win32 Content Prep ToolからIntuneWinAppUtil.exe

ダウンロードしたら以下のフォルダ構成を作成します。

C:\tmp\
  ├── IntuneWinAppUtil.exe
  ├── source\    <- 7-zipのインストーラーをここに置く
  └── output\    <- 変換後の.intunewinファイルの出力先

.intunewinへの変換

管理者権限でコマンドプロンプトを開き、以下を実行します。

C:\tmp\IntuneWinAppUtil.exe -c C:\tmp\source -s 7z2601-x64.exe -o C:\tmp\output

オプション	値	意味
-c	C:\tmp\source	ソースフォルダ
-s	7z2601-x64.exe	変換対象のインストーラー
-o	C:\tmp\output	出力先フォルダ

INFO Done!!!と表示されたら成功です。C:\tmp\output\に7z2601-x64.intunewinが生成されます。

Intuneポータルへの登録

[アプリ] - [すべてのアプリ] - [作成]

アプリの種類で Windowsアプリ（Win32） を選択し、先ほど生成した7z2601-x64.intunewinを選択します。

①アプリ情報

項目	設定値
名前	7-Zip 26.01 (x64)
説明	7-Zip 26.01 x64版
発行元	Igor Pavlov

②プログラム

項目	設定値
インストールコマンド	7z2601-x64.exe /S
アンインストールコマンド	C:\Program Files\7-Zip\Uninstall.exe /S
インストールの処理	システム

③必要条件

項目	設定値
オペレーティングシステムのアーキテクチャ	x64
最小なオペレーティングシステム	Windows 11 21H2

④検出規則

検出規則はIntuneがアプリの「インストール済み/未インストール」を判断するための条件です。条件を間違えると再インストールを試み続けるという事態にも陥ることもあるため、慎重に設定します。

規則の形式は検出規則を手動で構成するを選択し、+追加をクリックします。

項目	設定値
規則の種類	ファイル
パス	C:\Program Files\7-Zip
ファイルまたはフォルダー	7z.exe
検出方法	ファイルまたはフォルダーが存在する
64ビットクライアント上で32ビットアプリに関連付ける	いいえ

筆者の感覚では検出規則というやつは極めて重要なパラメータです。ここを安易に考えていると現場では大変苦労すると思います。また、「インストールしたらどのファイルが生成されるか」を知っていないと、こうした検出規則も書けないので、このあたりはキッティング設計業務の経験値がものをいってきます。検証や裏取りがとても重要な場面です。
ファイル・フォルダの有無だけでなく、レジストリの値によっても合否をコントロールできます。ここはWindows管理者としてのセンスが問われてきます。

⑤依存関係・⑥置き換え

今回は設定不要です。

⑦割り当て

種類	グループ
必須	すべてのデバイス

必須に割り当てることでAutopilot中に自動インストールされます。登録済みデバイスで使用可能にした場合はポータルサイトからユーザーが任意でインストールする形になります。

2.デプロイ

ここまで来ればAutopilotの準備は完了です。
あとはprov-01を工場出荷時の状態に戻してください（仮想環境の場合はスナップショットをOS初期セットアップ前の状態まで切り戻してください）。
要するに以下の画面が表示される状態にしてください。

• サインインを行うとAutopilotが開始されます。10分程度で終わると思います。
  これがESPの画面です。

• PINを求められたら任意の文字列を入力して先へ進んでください

• Windowsの通常のサインイン画面が表示された場合(Hyper-V環境でテストしている人はほぼ確実に表示されてしまいます)は、同じアカウントでサインインを行って続行してください。

• デスクトップが表示されたらひとまずOKです。次の章で設定値が反映されているかをチェックしてみてください。

PINセットアップに関するエラーについて

仮想環境でAutopilotを実行しているとエラーコード0x80090010が表示されることがあります。これは無視して今はしないを選択してください。

原因ははっきりしています。
Hyper-V上のVMに対して「拡張セッションモード」で接続しているとそもそもPINをはじめとしたWindows Hello for Business関連の設定ができないからです。これはIntune云々は関係ありません。
どうしても気になる人はHyper-V側の設定を変更してください（筆者は不便なので実験の時だけ無効にしております）。なお、この設定はVMごとに行うことは出来ないようです。設定変更した場合はほかのVMにも影響が出るので気を付けてください。

ESPが終わらない謎

Windowsのサインイン画面まで到達できないことがあります。
具体的には以下の画面で「セキュリティポリシー(識別中)」となったままの状態です。

これは原因がわかりません。
こういう時は再度デプロイをやり直してみてください。

デプロイをやり直す時

スナップショットやOSの再インストールでデプロイをやり直すときの手順ですが、この点については自信がほとんどありません。おまじないじみていますが、筆者はこういう手順を踏んでいます。

• Microsoft Intune 管理センターを開き、[デバイス] - [Windows] - [Windowsデバイス]のメニューからprov-01を選択し、削除 をクリックします。

表示が消えるまでに数分かかることが多いようです。

• [デバイス] - [デバイスのオンボーディング] - [登録] - [Windowsタブ] - [Windows Autopilot] - [デバイス] から、prov-01のシリアル番号にチェックを入れて 削除 をクリックします。

• Microsoft Entra 管理センターにサインインし、[デバイス] - [すべてのデバイス]
  から登録デバイスを削除します。

その後は15分程度待機して次の作業に進んでください。
（デバイスの登録・削除作業についてはどうやら数分の時間がかかるようなので、筆者はあまり短時間のうちに登録・削除をGUIから行いたくないのです。確証は無いのですがフロントエンドからの操作で表示されたステータスと実際のバックエンドの状況との整合性が取れていないかのような感覚を覚える事がときどきあります)

• 【1-4】デバイスIDハッシュをIntuneポータルにインポートする の作業を再実行する。
  インポート後、このシリアル番号のステータスを確認します。関連付けられている Intune デバイス が N/Aになっていることが重要です。

（筆者が15分程度の待機の習慣がついた理由はこれです。急いで[削除] → [インポート]を実施すると、なぜか過去のデバイスが紐づいた状態になってしまいます）

• prov-01をスナップショットで初期状態に戻す

• OSを起動する（Autopilotを再実行する）

• OSを起動したときに一直線にMSアカウントの認証画面が表示されたら、デバイスIDハッシュがIntuneポータルにインポートされている証拠だと思います。そうにはならず、最初に以下のような国・地域の選択画面などが出るようだとおそらくほぼ確実に作業に失敗しています。デバイスIDハッシュを取得する作業からやり直したほうが良いと思います。

3.デプロイ後の確認作業

【3-1】OS側の事後確認

以下の作業を行い、【1-3】インストール直後のOSの状態を把握しておく の章で実施した結果と比較してみます。

• dsregcmd /statusの実行結果の確認
  相当違う点があると思います。AzureAdJoined : YESとなっていたらOKです。

• manage-bde -statusの実行結果の確認
  保護はオンですになっていたらOKです。

• certlm.mscの実行結果の確認
  証明書は4つ追加されているはずです。

• 7-Zipがインストールされている事の確認
  起動まで出来たらOKです。

• Edgeを起動したときの動作を確認
  「ようこそ」の画面が表示されなければOKです。

【3-2】Intuneポータル上の事後確認

[デバイス] - [すべてのデバイス] - [prov-01]を確認してみてください。

• 管理者（Intuneになっているか）
• コンプライアンスの状態（準拠/非準拠）
• 最終チェックイン日時

コンプライアンスが「準拠」となっているということは、つまりコンプライアンスポリシーで設定した条件をすべて満たしているということでしょう。調べたところ、非準拠デバイスからはMicrosoft 365にアクセスさせないという設定をMicrosoft Entra管理センターから行うことも可能のようです。この設定は今回はやりませんが、現場では活用頻度は高いのではないでしょうか。
なお、筆者は最初に設定ミスでBitlockerのディスク暗号化に失敗していたため、「非準拠」となっておりました。コンプライアンスの設定でデバイス上のデータストレージの暗号化が必要を有効にしていたからですね。きちんと機能が働いていたという事です。

【3-3】Microsoft Entra管理センター上の事後確認

Microsoft Entra管理センターにサインインし、[デバイス] - [管理] - [Bitlockerキー]を開いて、Bitlockerのキーを省略せずに検索窓に入れてみてください。

対応する回復キーが表示されたらOKです。

Bitlockerのキーとは、manage-bde -protectors -get C:で確認できます。数字パスワードのIDを確認してください。

【3-4】あとは好きに操作してみる

Intuneポータルには山ほど設定項目があるので、気になるところを好きに変更して挙動を確認するのが良いと思います。OS側で何か設定を変更したとしてもIntuneによって強制的に切り戻ることが確認できると思います。
ちなみにIntuneポータルで何か変更を行った場合は、OS側で「同期」ボタンをクリックすると設定がすぐに反映されました。（筆者の環境では1分以内で反映されておりました）

同期の方法

prov-01側で同期を行う方法を書いておきます。

• [設定] - [アカウント] - [職場または学校にアクセスする] - [接続済みアカウントをクリック] - [情報]ボタンをクリック。

• [同期]ボタンをクリック

ちなみに「同期」は同期ボタンを押さなくても一定周期で自動的に適用されているようでした。
アプリケーションのインストールについても同様です。
試しに7-zipをアンインストールしてみたのですが数分後には自動的に再インストールされておりました。これはIntuneがこうしたドリフト検知を常に行っており、一定のタイミングで「インストールされていない」と検出して自動的に再インストールしているということでしょう（検出規則が密接に絡んでいるはずです）。

こうした挙動はGPOとの比較で考えると面白いです。GPOはレジストリやOS設定値を強制することが得意ですが、アプリケーションの導入状況まで一元管理する使い方には不向きです。Intuneはその両方をカバーできます。GPOと重複する領域もありますが、IntuneはGPOのクラウド版でもなければラッパーでもありません。似て非なるものだと筆者は理解しています。

(付録)管理・セキュリティ機能を追加する

ここからさらに別の設定を追加してみたのですが、興味のある方だけご覧ください。

【3-5】セキュリティベースライン

セキュリティベースラインとはMicrosoftがWindowsやEdge、Defenderなどに推奨するセキュリティ設定をまとめたテンプレートのようです。数百項目にも及ぶセキュリティ設定を1クリックで一括適用できるというもので、個別にSettings Catalogで設定するより手軽に「とりあえずMicrosoftの推奨設定を当てる」という使い方ができる、ということのようです。

ただし何が適用されるかを把握しておかないと予期しない挙動になることもあるようで、個人的にはいきなり本番環境に適用するのは少し怖い代物でもあります。

今回は動作確認のため、セキュリティベースラインのファイアウォール設定をあえて無効化します。OSのデフォルトはファイアウォールONなので、ベースライン適用後にOFFになることで「ポリシーが効いている」ことを確認してみます。

Before：現在のファイアウォールの状態を確認する

確認方法は本エントリでは触れません。

プライベート・パブリックの2つのプロファイルすべてが有効（State オン）になっているはずです。

セキュリティベースラインの作成

[エンドポイントセキュリティ] - [セキュリティのベースライン] - [Windows 10以降のセキュリティベースライン] - [プロファイルの作成]

項目	設定値
名前	security_baseline_01

②構成設定でFirewallを展開し、以下の2項目をFalseに変更する。

項目	設定値
Enable Private Network Firewall	False
Enable Public Network Firewall	False

※ドメイン非参加PCなのでドメインネットワークの分は不要でしょう。

その他の項目はデフォルトのまま変更しない。割り当てはすべてのデバイス。

同期して確認する

ポリシー作成後、prov-01側で同期を行います。

After：現在のファイアウォールの状態を確認する

ファイアウォールが無効になっていることを確認してください。
簡単ですがセキュリティベースラインの確認は以上です。自分なりに変更したい項目があればいろいろ試してその都度「同期」をしてみると良いと思います。

しかしこの機能、エクスポートというメニューはあるくせに、インポートが見当たらないんですよね。このカスタムテンプレートを他の環境にインポートできないのでしょうか？GUIメニューに無いだけで、別の環境で再利用するコマンドが実はあったりするのでしょうか。

【3-6】LAPS

LAPS（Local Administrator Password Solution）は、ローカル管理者アカウントのパスワードをIntuneが自動でランダム生成・ローテーションして、それをEntra管理センター側に保管する仕組みのようです。
全てのPCのローカル管理者パスワードが同じという状態を好ましくないと考える管理者も居るのでしょう（筆者はそんな現場を見たことがないですが）。
1台が侵害されると全台に横展開されるリスクがあるからです。LAPSはPC毎に異なるパスワードを自動管理します。

Entra管理センター側の設定

まずEntra管理センター側でLAPSを有効化します。

https://entra.microsoft.com/

[デバイス] - [デバイスの設定]

Microsoft Entra Local Administrator Password Solution（LAPS）の有効化をはいに設定して保存してください。

Intuneでの設定

[エンドポイントセキュリティ] - [アカウント保護] - [ポリシーの作成]

項目	設定値
プラットフォーム	Windows 10以降
プロファイルの種類	設定カタログ
名前	laps_policy_01

Configuration settings

LAPSで検索して以下を設定する。
今回はintuneRootというローカル管理者アカウントを作成します。

項目	設定値
Backup Directory	Backup the password to Microsoft Entra ID only
Password Age Days	30
Automatic Account Management Enabled	The target account will be automatically managed
Automatic Account Management Target	Manage a new custom administrator account
Automatic Account Management Name Or Prefix	[構成済み] - intuneRoot
Automatic Account Management Randomize Name	The name of the target account will not use a random numeric suffix
Automatic Account Management Enable Account	The target account will be enabled

Automatic Account Management Name Or Prefixを指定しない場合はデフォルトでWLapsAdminというアカウント名が使われます。任意の名前を付けたい場合はここで指定してください。

割り当て

項目	設定値
包含されたグループ	すべてのデバイス

確認

ポリシー適用後、prov-01側で同期を行います。

[設定] - [アカウント] - [職場または学校にアクセスする] - [接続済みアカウントをクリック] - [情報] - [同期]

数分待ってから以下を実行してください。筆者の環境ではここの設定は結構待たされました。15分ぐらいで反映されたこともあります。Entra管理センターとも密接に絡んでいるので何か厳格な同期処理でも走っているのでしょう。

Get-LocalUser | Select-Object name, enabled

intuneRootアカウントが有効状態で作成されていればOKです。

次にEntra管理センター側でパスワードが確認できるか確認します。

[Entra管理センター] - [デバイス] - [すべてのデバイス] - [prov-01] - [ローカル管理者パスワードの回復]

ローカル管理者パスワードの表示をクリックするとパスワードが平文で表示されます。
デフォルトでは14文字が設定されます。

この操作は監査ログに記録されていました。誰がいつパスワードを確認したか証跡が残る仕組みになっているようです。[Entra管理センター] - [デバイス] - [監査ログ]から確認できました。
Recover device local administrator passwordというログは一見するとパスワード表示したという意味だとは取りにくいとは思いますが、ともあれ、パスワード確認をするたびにこのログが記録されておりました。

なお、本検証は1台のみでの確認です。残念ながら筆者にIntuneを利用可能なライセンスが1デバイス分しか無いため、複数台のPCにそれぞれ異なるパスワードが割り当たっているかを確認する事ができません。ご了承ください。デフォルトならばそういう動作になるはずで、パスワードもそれぞれ30日おきに変わるはずです。
しかし、この機能のメリットってなんでしょう？どのみちDomain Adminsアカウントがあるのだから・・・・と書きかけたのですが、そうか！もうドメインコントローラーが必ずある、という世の中でもなくなって行くのですよね。
Entra Joinした環境では「ドメイン管理者」という概念がそもそも存在しない。Entra IDのグローバル管理者という存在はあるにせよ、それはクラウド上の話でローカルのPCを直接操作する権限とはまた別のはずです。
ドメインのないクラウドネイティブ環境での緊急アクセス手段としてこういう機能は意味を持ってくるのだと筆者は考えます。

【3-7】ASRルール（監査モード）

ASR（Attack Surface Reduction）ルールは、マルウェアがよく使う攻撃手法をブロックするDefenderの機能です。ブロックせずログに残すだけの監査(Audit)モードで動かすこともできました。
手軽に試せそうなルールが意外と少なかったので悩んだのですが、今回はBlock use of copied or impersonated system toolsというルールを試してみました。説明文にはこうありました。

This rule blocks executables that impersonate or are copies of system tools & binaries found on the machine.

つまり「マシン上に存在するシステムツールやバイナリを偽装またはコピーした実行可能ファイルをブロックする」というルールのようです。
なので、notepad.exeをsvchost.exeという名前でコピーして実行するだけで引っかかるのか試してみました。

ポリシーの作成

[エンドポイントセキュリティ] - [攻撃面の減少] - [ポリシーの作成]

項目	設定値
プラットフォーム	Windows
プロファイル	攻撃の回避規則
名前	asr_policy_01

構成設定

項目	設定値
Block use of copied or impersonated system tools	Block

割り当て

項目	設定値
包含されたグループ	すべてのデバイス

動作確認

ポリシー適用後、prov-01側で同期を行い、notepad.exeをsvchost.exeという名前でコピーして実行してみます。

Copy-Item C:\Windows\System32\notepad.exe C:\tmp\svchost.exe
C:\tmp\svchost.exe

実行はブロックされ、Defenderのイベントログを確認したところ、イベント ID 1121が記録されました。

これはEntra管理センターやIntune管理センターでは管理されていないんですかね？探したのですが見つかりませんでした。何かログを横断的に検索する機能でも使わないとダメなのかもしれません。ASRルールについては以上です。

【3-8】KQLクエリ

これ面白そうなのですが、Business PremiumライセンスだとどうもLog Analyticsが使えなさそうなのでまた別の機会にやることにします。

感想

MDTやカスタムイメージ作成といった従来のプロビジョニング手法を経験してきた人間からすると、「Intuneで楽になる」とは一概には言えない、というのが正直なところです。

何千台ものPCの初期セットアップを自動化できるのは確かにメリットです。しかし実際に触ってみると、設定項目の多さと複雑さに戸惑う場面が少なくありませんでした。たとえばBitLockerの有効化ひとつとっても複数のアプローチが存在し、どれを選べばよいのかが直感的にわかりません。洗練されているとは言い難い印象です。

些末なことまで言うなら、UIのローカライズがいまいちでした。同じ画面構成なのに項目によって日本語だったり英語だったりする箇所があるのが気になりました。

またAutopilotはあくまで「初期セットアップをユーザーの手元で自動実行する」仕組みです。ユーザーが操作するわけではありませんが、設計や設定が不十分だとセットアップ中にエラーが発生し、ユーザーはIT窓口に問い合わせるしかない状況になります。結果としてIT管理者の業務負荷が変わらない、という事態にも陥りかねません。そうならないよう、時間をかけて検証する必要があります。

さらに言えば、Intune/Autopilotを使いこなすには決して「クラウドだけ」の知識では足りません。GPOの設定や設計の経験が無いとSettings Catalogの項目の意味が掴みにくく、SYSPREP(＝unattend.xmlの設計)などの経験によって勘が養われていないと結構苦労する場面も多いと思います。結局のところ、オンプレ時代に培った地味～なスキルセットがそのまま問われる場面が多いと感じました。

もちろん面白い技術ではあります。ただSE目線では「導入すれば楽になる」という過度な期待は禁物で、ある程度の心の準備は必要な代物だと思いました。
Autopilot/Intuneの体験についてはここまでです。
冒頭でも書きましたが理想はVPNで社内接続を行い、ドメイン参加するところも含めて自動化することなのですが、それはまた別の機会にやろうと思います。