Windows Hello for Business（WHfB）を Intune で有効化すると、初回サインイン直後に全画面の PIN／顔認証セットアップが表示され、「やらないと先に進めない」ような印象を与えがちです。この記事では、この全画面セットアップだけを抑止しつつ、ユーザーが後から［設定］→［アカウント］→［サインイン オプション］から任意で Windows Hello を有効化できる構成を、実務でそのまま使える 2 パターンで整理します。
背景：Windows Hello for Business の「全画面セットアップ」が問題になる理由
Windows Hello for Business は、PIN や生体認証でパスワードレスなサインインを実現する仕組みで、Entra ID（旧 Azure AD）やオンプレ AD と連携して強固な認証を提供します。
Intune で WHfB を有効化すると、次のような動きになりがちです。
- Autopilot や通常の Intune 登録直後に、全画面の「Windows Hello セットアップ」ウィザードが起動
- ユーザーは PIN／顔認証の登録を完了しないと先に進めないように感じる
- ヘルプデスクには「何をすればいいのか分からない」「カメラがない PC なのに顔認証を求められる」といった問い合わせが増える
一方で、現場でよく聞く要望は次のようなものです。
- セキュリティ上、WHfB 自体は有効化したい
- ただし、初回サインイン時の全画面セットアップは出したくない
- ユーザーが使いたくなったタイミングで、設定画面から任意で登録できるようにしたい
この「WHfB の強みは活かしつつ、ユーザー体験を柔らかくする」ためのカギになるのが、PassportForWork CSP の DisablePostLogonProvisioning と、Intune のテナント全体 WHfB ポリシーです。
実現したい状態の整理
| 項目 | 要件 |
|---|---|
| WHfB 機能そのもの | 有効（PIN／顔認証は利用可能） |
| 初回サインイン直後の全画面セットアップ | 非表示（自動プロビジョニングを抑止） |
| ユーザーによる任意登録 | ［設定］→［アカウント］→［サインイン オプション］からいつでもセットアップ可能 |
| 対象スコープ | テナント全体ではなく、グループ単位などで段階的に展開できること |
| 管理方法 | 基本は Intune（CSP）。GPO は併用せず、いずれかに統一する |
この要件を満たす代表的な構成が、以下の 2 パターンです。
- パターンA：PassportForWork CSP の
DisablePostLogonProvisioningで「サインイン直後の自動プロビジョニングだけ」止める（推奨） - パターンB：テナント全体の WHfB（登録時）ポリシーを抑止し、必要な範囲だけ別ポリシー（CSP/GPO）で有効化
パターンA：CSP「DisablePostLogonProvisioning」でサインイン直後の自動プロビジョニングだけ止める（推奨）
パターンAの考え方
PassportForWork CSP には、以下の 2 つの重要な設定があります。
UsePassportForWork（bool） → WHfB 自体を有効／無効にするスイッチDisablePostLogonProvisioning（bool） → 「サインイン後に Windows Hello プロビジョニングを開始しない」スイッチ
UsePassportForWork = true のまま、DisablePostLogonProvisioning = true を設定すると、動作は次のようになります。
- WHfB 機能は有効（PIN/顔認証は利用可能）
- サインイン直後に自動で全画面セットアップは起動しない
- ユーザーが ［設定］→［アカウント］→［サインイン オプション］ から「Windows Hello のセットアップ」をクリックしたタイミングでウィザードが起動
まさに「強制しないが、いつでも使える」状態が実現できます。
対応 OS とビルド要件
DisablePostLogonProvisioning は、比較的新しいビルドからサポートされた機能です。公式ドキュメントでは、適用可能な OS／ビルドが明示されています。
- Windows 10 2004 以降 ビルド 19041.4239 以上
- Windows 11 21H2 更新プログラム KB5036894 以降（ビルド 22000.2899+）
- Windows 11 22H2 更新プログラム KB5035942 以降（ビルド 22621.3374+）
- Windows Server 2022 ビルド 20348.2402 以降
社内の標準イメージや既存端末がこれらのビルドを満たしていない場合、Windows Update や WSUS／WUfB での更新を先に完了しておくのが安全です。
Intune での構成手順（カスタム OMA-URI プロファイル）
ここでは、「Windows 10/11 + Entra ID 参加 + Intune 管理」という構成を前提にしています。
手順 1：テナント ID（TenantId）の確認
PassportForWork CSP の OMA-URI には、{TenantId} として Entra テナント ID（GUID） を埋め込む必要があります。
- Entra 管理センターや Azure Portal で「テナント ID」をコピー
- PowerShell で Graph API を叩く方法も公式に案内されています 例：
GET https://graph.microsoft.com/v1.0/organization?$select=id
取得した GUID を、そのまま {TenantId} の位置に使います（波括弧 { } は不要）。
手順 2：Intune でカスタム構成プロファイルを作成
Intune 管理センターにサインインし、次のように進みます（メニュー名はバージョンにより多少異なります）。
- [デバイス] → [Windows] → [構成プロファイル] → [プロファイルの作成]
- プラットフォーム： Windows 10 以降
- プロファイルの種類：「テンプレート」→「カスタム」
プロファイル名は、例えば 「WHfB – DisablePostLogonProvisioning」 など、意図が分かるものにしておくと後から見直しやすくなります。
手順 3：OMA-URI 設定の追加
カスタムプロファイル内で、以下の 2～3 つの OMA-URI を追加します。
| 目的 | OMA-URI | データ型 | 値 |
|---|---|---|---|
| WHfB 機能を有効化 | ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork | Boolean | true（有効） |
| サインイン直後の自動プロビジョニングを抑止 | ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/DisablePostLogonProvisioning | Boolean | true（「サインイン後にプロビジョニングを開始しない」） |
| （任意）PIN リカバリーを有効化 | ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/EnablePinRecovery | Boolean | true（推奨） |
UsePassportForWork は既定値で true ですが、実務では「明示的に true を配布しておく」ことが推奨されます。Microsoft Q&A でも、DisablePostLogonProvisioning を効かせるために UsePassportForWork を設定する必要があるという指摘があります。
手順 4：割り当てとパイロット
作成したプロファイルを、まずは少数のパイロット グループ（IT 部門やテスト用デバイス）に割り当て、動作を確認します。
- 対象：ユーザー グループでもデバイス グループでも可（運用ポリシーに合わせて選択）
- Autopilot 用のデバイスのみを含むグループを用意しても良い
手順 5：動作確認のポイント
パイロット端末で、次を確認します。
- 初回サインイン後、全画面の Windows Hello セットアップが表示されないこと
- ［設定］→［アカウント］→［サインイン オプション］にて、「Windows Hello PIN／顔認証の［セットアップ］ボタン」が表示され、クリックするとウィザードが起動すること
- イベントログ「DeviceManagement-Enterprise-Diagnostic-Provider」に OMA-URI エラーが出ていないこと
パターンAのメリット／デメリット
| 観点 | メリット | 注意点 |
|---|---|---|
| ユーザー体験 | 全画面ウィザードが出ないため、初回サインインのストレスが減る | ユーザーが自分で設定画面を開かない限り、WHfB が使われない可能性がある |
| セキュリティ／CA | WHfB 自体は有効なので、将来的に CA で「多要素 + WHfB 必須」などへ拡張しやすい | Autopilot + 条件付きアクセスで、初回から SSO を期待していると挙動が変わる（後述） |
| 運用 | Intune のカスタム プロファイル 1 つで完結し、ポリシー構造がシンプル | OS ビルド要件を満たしていない端末では効かない／エラーになる |
パターンB：テナント全体の WHfB 登録ポリシーを抑止し、必要範囲だけ別ポリシーで有効化
テナント全体の Windows Hello for Business ポリシーとは
Intune には、「デバイス登録時に Windows Hello for Business をどう扱うか」を決めるテナント全体のポリシーがあります。
場所（2025年時点）：
- [デバイス] → [Windows] → [Windows の登録] → [Windows Hello for Business]
ここで設定する [Configure Windows Hello for Business] には、次の 3 つの選択肢があります。
| 設定値 | 意味 | 本記事の文脈での使いどころ |
|---|---|---|
| Enabled | デバイス登録（Autopilot OOBE 含む）のタイミングで WHfB を構成し、登録ウィザードを表示する | 「登録時に必ず WHfB を強制したい」場合にのみ利用（本記事のゴールとは逆） |
| Disabled | 登録時に WHfB を有効化しない。ユーザーは登録時点では WHfB をプロビジョニングできない | Autopilot OOBE で WHfB を一切出したくない場合の選択肢。ただし後段のポリシーで別途有効化する前提 |
| Not configured | Intune では登録時の WHfB を制御しない（既存設定を変更しない） | 登録時の挙動を固定せず、後段のポリシー（Account Protection や CSP）で制御する場合 |
Microsoft 公式ドキュメントでも、テナント全体のポリシーは「登録時のみ」有効であり、通常は Disabled/Not configured にして、グループ単位のポリシーで WHfB を管理する運用が推奨されています。
パターンBの構成イメージ
パターンBは、次のような多段構成を取ります。
- テナント全体の「登録時 WHfB ポリシー」を
- Not configured または Disabled に設定し、登録時の強制を止める
- そのうえで、必要なユーザー／デバイス グループにだけ
- Intune の Account Protection ポリシー（Endpoint security）や、
- 設定カタログ／カスタム OMA-URI（PassportForWork CSP）、
- あるいは GPO（オンプレ／ハイブリッド環境）
- 「全画面セットアップを出したくない」対象には、パターンAの
DisablePostLogonProvisioningも併用する
Microsoft Q&A でも、「テナント レベルの WHfB を無効化し、GPO や CSP で必要な範囲だけ有効化する」という運用パターンが紹介されています。
ステップ例：Intune 中心でのパターンB構成
ステップ 1：テナント全体の WHfB ポリシーを見直す
- Intune 管理センターで [デバイス] → [Windows] → [Windows の登録] → [Windows Hello for Business] を開く
- [Configure Windows Hello for Business] を
- Autopilot OOBE での強制を完全に止めたい場合は Disabled
- 現行挙動を維持したい・影響を最小化したい場合は Not configured
「Disabled」にすると、登録の瞬間だけではユーザーが WHfB をプロビジョニングできなくなる点に注意が必要です。ただし、その後に配布する別の Intune ポリシー（Account Protection や CSP）で WHfB を有効化すれば、ユーザーはサインイン オプションから登録できるようになります。
ステップ 2：Account Protection などで WHfB を有効化
登録後のデバイスに対して WHfB を有効化するには、代表的に次の方法があります。
- Endpoint security → Account protection ポリシーで WHfB を有効化
- [Endpoint security] → [Account protection] → [ポリシー作成]
- プラットフォーム：Windows 10 以降
- プロファイル：「アカウント保護」
- 「Use Windows Hello for Business」や PIN 長、TPM 利用、顔認証可否などを設定
- 設定カタログで「Windows Hello for Business」関連の設定を選択して構成
- より細かい制御が必要であれば、パターンAと同様に カスタム OMA-URI（PassportForWork CSP） で定義
ステップ 3：DisablePostLogonProvisioning を併用（任意）
「登録時の強制も止めたいし、サインイン後の全画面ウィザードも止めたい」場合は、パターンAと同じ DisablePostLogonProvisioning を併用します。
- Autopilot OOBE で WHfB のセットアップが出ない（テナント ポリシー）
- サインイン直後の全画面ウィザードも出ない（DisablePostLogonProvisioning）
- ユーザーは設定画面から任意に WHfB を有効化できる
この構成は非常に柔軟ですが、どのポリシーが「有効化」担当で、どのポリシーが「自動プロビジョニング抑止」担当なのかを整理しておくことが重要です。
Intune ポリシーと GPO を混在させないための考え方
Windows Hello for Business は、CSP（PassportForWork）と GPO の両方で構成できますが、混在は非推奨です。
公式ドキュメントでは、以下のポイントが強調されています。
- WHfB のポリシーは、GPO または CSP のどちらか一方で構成するべき（両方は不可）
- GPO と CSP が競合すると、CSP 側の設定が適用されない場合がある
- MDMWinsOverGP ポリシーは WHfB には効かない （WHfB のポリシーは Policy CSP ではなく PassportForWork CSP 配下のため）
実務では、次のような方針で割り切るとトラブルが減ります。
| 環境 | 推奨する構成主体 | ポイント |
|---|---|---|
| Entra ID 参加 + Intune 管理 | CSP（Intune）に統一 | GPO での WHfB 設定は行わない。既存 GPO がある場合は無効化・削除してから Intune に移行 |
| オンプレ AD 参加のみ | GPO に統一 | Intune 管理していない端末は GPO で一元管理。CSP での WHfB 設定は行わない |
| ハイブリッド（AD + Entra + Intune） | どちらを「正」とするかを明確に決める | 基本は Intune へ寄せるのがモダンだが、移行期間中は「どの OU／グループに GPO を残すか」を厳密に管理 |
Autopilot／条件付きアクセスとの関係
DisablePostLogonProvisioning を有効化すると、Autopilot + 条件付きアクセス（CA）の体験も変わる点には要注意です。
- 通常、Autopilot では
- 最初のサインイン：デバイス登録・Entra 参加のための MFA
- 2 回目のサインイン後：WHfB プロビジョニング（ここで WHfB 用の MFA）
- DisablePostLogonProvisioning = true にすると、この「2 回目の WHfB プロビジョニング」が発生しない
- 結果として、初回からシームレスな SSO を期待する CA 設計との相性が変わる
特に、以下の点を事前に検討しておくと安心です。
- CA で「WHfB を信頼済み多要素」として扱っているかどうか
- Autopilot 完了直後から、どのアプリに SSO させたいか
- 「最初はパスワード＋MFA で利用開始、その後ユーザー任意で WHfB を登録」という体験を許容できるか
ユーザー体験を最重視するなら「まずは DisablePostLogonProvisioning をパイロット限定で適用し、CA を含めた実際の挙動を確認してから本番展開」がおすすめです。
動作確認とトラブルシューティングのコツ
| 症状 | 原因候補 | チェックポイント |
|---|---|---|
| 全画面 Hello セットアップがまだ表示される | DisablePostLogonProvisioning が適用されていない OS ビルドが要件を満たしていない GPO が競合している | 端末の [設定] → [アカウント] → [サインイン オプション] にある「一部の設定は組織によって管理されています」の表示内容 HKLM\SOFTWARE\Microsoft\Policies\PassportForWork\<TenantID>\Device\Policies に DisablePostLogonProvisioning = 1 があるか イベントログ「DeviceManagement-Enterprise-Diagnostic-Provider」にエラー 404（CSP 失敗）が出ていないか |
| サインイン オプションで Windows Hello がグレーアウトし、「組織によって無効化されています」と出る | UsePassportForWork / GPO 側の Enabled が 0（無効） テナント全体ポリシーが「Disabled」のままで、後段ポリシーがない | Intune の Account Protection／設定カタログ／カスタム OMA-URI で Use Windows Hello for Business / UsePassportForWork が有効になっているか AD GPO で「Use Windows Hello for Business」「Turn on convenience PIN sign-in」などが無効化されていないか |
| 一部の端末でだけ DisablePostLogonProvisioning の CSP が失敗する | OMA-URI の typo Conditional Access との組み合わせによる一時的なエラー Intune クライアントの状態不良 | Intune のデバイス詳細でエラーコード 0x87d1fde8 が出ていないか OMA-URI のスペル（TenantId、Policies 名）を再確認 対象端末の OS とパッチ レベルが要件を満たしているか再確認 |
よくある質問（FAQ）
Q. DisablePostLogonProvisioning を有効にしても、将来的に WHfB を強制することはできますか？
A. はい、可能です。DisablePostLogonProvisioning = true はあくまで「サインイン直後の自動プロビジョニングを止めるだけ」の設定です。後からポリシーを変更して Disabled に戻したり、別のポリシー（Account Protection など）で WHfB を必須にすれば、強制登録のフローを再び有効にできます。
Q. DisablePostLogonProvisioning は GPO でも設定できますか？
A. はい、オンプレ／ハイブリッド環境では GPO 経由でも同様のレジストリ（PassportForWork\...\DisablePostLogonProvisioning）を設定できます。ただし、Intune（CSP）と GPO を同じ端末で混在させると競合の原因になるため、どちらで管理するかを明確に分けることが重要です。
Q. テナント全体ポリシーを Disabled にしてしまうと、ユーザーは永遠に WHfB を使えなくなりませんか？
A. テナント全体ポリシーは「登録時点での挙動」にのみ影響し、その後に配布される Intune ポリシー（Account Protection や設定カタログ、カスタム CSP）で WHfB を有効化すれば、ユーザーはサインイン オプションから登録可能です。構成の優先順位や動作については、公式ドキュメントでも解説されています。
Q. Registry 直接書き換え（スクリプト配布）で対応しても問題ありませんか？
A. 技術的には可能であり、Sikich のブログなどでも Win32 アプリ経由でレジストリを投入する方法が紹介されています。 ただし、
- 公式には Intune ポリシー（CSP）や GPO を使うことが推奨
- スクリプトで直接レジストリを書き換えると、後から「どのポリシーが正か」が分かりづらくなる
といった運用上のデメリットがあるため、まずは CSP / GPO での実装を検討し、どうしても一部端末だけ手動補正が必要な場合に限定してスクリプト対応する方が現実的です。
まとめ：最短でゴールに届くのは「WHfB 有効 + DisablePostLogonProvisioning」
本記事では、
- パターンA：PassportForWork CSP の
DisablePostLogonProvisioningで「サインイン直後の全画面セットアップだけ」抑止する方法（推奨） - パターンB：テナント全体の WHfB 登録ポリシーを抑止し、必要な範囲だけ WHfB を別ポリシー（Account Protection／CSP／GPO）で有効化する方法
の 2 つを紹介しました。
要点を整理すると：
- ユーザーに WHfB を強制したくないが、いつでも任意で使える状態にしたい → パターンA
UsePassportForWork = trueDisablePostLogonProvisioning = true
- Autopilot OOBE での WHfB 強制自体も止めたい／ハイブリッド含めて設計を整理したい → パターンB + 必要に応じてパターンAを併用 テナント全体の WHfB ポリシーを Disabled/Not configured にし、そのうえで Account Protection や CSP で対象グループにだけ WHfB を許可します。
- GPO と CSP の混在は避ける WHfB は MDMWinsOverGP の対象外であり、競合すると期待通りに動作しません。どちらを「正」とするかを決めてから展開することが重要です。
WHfB は「パスワードレス」という大きな価値を持つ一方で、初期体験を誤るとユーザーにとってはただの「邪魔なウィザード」になりがちです。DisablePostLogonProvisioning とテナント全体ポリシーの組み合わせをうまく使いこなして、セキュリティとユーザー体験のバランスを取った設計を目指してみてください。
参考リンク（公式ドキュメント中心）
- PassportForWork CSP（DisablePostLogonProvisioning / UsePassportForWork など）
- Configure Windows Hello for Business on devices when they enroll with Intune（テナント全体の WHfB ポリシー）
- Configure Windows Hello for Business（CSP/GPO の役割分担、MDMWinsOverGP 非対象など）
- Windows Hello for Business policy settings（WHfB ポリシーの一覧）
- Windows Hello for Business – Disable required setup prompt while allowing manual configuration（Microsoft Q&A）
- Windows 11: WHfB – DisablePostLogonProvisioning（Intune での具体例と Autopilot/CA の注意点）
コメント