Intune Fresh Start で Windows 11 展開が失敗する原因と対処法：DirectoryValueExistsException（デバイス登録/DRS）

Intune の「Fresh Start」で Windows 11 を再展開しようとすると、OOBE 中のデバイス登録（Device Registration Service）で毎回失敗し、Microsoft.Online.DirectoryServices.DirectoryValueExistsException が出る――この症状は、Entra ID / Intune 側に残った古いデバイス情報や重複属性が新規登録と衝突しているケースが多いです。原因の切り分けから復旧手順、再発防止までを実務目線で整理します。

症状の整理：失敗しているのは「端末初期化」ではなく「デバイス登録」

今回の状況を要点だけ抜き出すと、問題の中心ははっきりします。

Intune の Fresh Start で Windows 11 展開を進めると、デバイス登録（Device Registration Service） の段階で毎回失敗する
エラーは Microsoft.Online.DirectoryServices.DirectoryValueExistsException
ログ上の識別子として 52596dbd-b271-4e66-b699-70efed9257d0 が見えている（DeviceId として出てくることが多い）
2024 年の障害（クラッシュ）以前は展開できていた（2024 年 10 月頃まで）
BIOS のセキュアブート有効／無効どちらでも失敗し、ハード要因の濃度は低い
障害以降、Entra ID / Intune 内に古い／壊れた情報が残っている疑いがある

Fresh Start 自体（OS リセット）に成功していても、Entra ID 上のデバイス登録が成立しない と、MDM（Intune）登録が続かず、ポリシー適用やアプリ配布も正常に進みません。つまり「端末はきれいになったのに管理に戻らない」という状態になります。

Fresh Start の流れと「5 ステップ目」が意味する場所

環境や UI 表現により多少前後しますが、Fresh Start で再展開が進むときは概ね次のような流れになります。今回の「5 ステップ目で失敗」は、クラウド側にデバイスを登録する段階に相当します。

フェーズ	端末側で起きること	クラウド側で起きること	失敗するとどうなるか
初期化（Fresh Start）	Windows の再構成・不要アプリ削除・初期状態化	基本的に動きは少ない	OS 自体が起動しない等の別系統障害
OOBE	言語/ネットワーク/アカウント入力	認証や Join の前段	ネットワークや時刻不整合でサインイン不可
デバイス登録（DRS）	組織への登録情報生成、証明書や識別子の作成	Entra ID にデバイスオブジェクト作成/更新	DirectoryValueExistsException などの一意制約で失敗
MDM 登録（Intune）	MDM への登録、管理チャネル確立	Intune に管理対象デバイスとして登録	ポリシー/アプリ配布が始まらない
配布・準拠	プロファイル/アプリ適用、コンプライアンス評価	割り当てと評価が回り始める	準拠にならない、配布が止まる

今回の核心は、DRS が Entra ID にデバイス情報を書き込もうとした瞬間に「重複」が見つかって弾かれている点です。

DirectoryValueExistsException の正体：Entra ID の「一意制約違反」

Microsoft.Online.DirectoryServices.DirectoryValueExistsException は、ひとことで言えば 「重複してはいけない値が、すでに別のオブジェクトに存在する」 という意味です。Entra ID はディレクトリなので、ある種の属性は “世界で 1 つ” でなければいけません。

代表的に衝突しやすい対象は次の通りです。今回のエラーはデバイス登録で出ていますが、ハイブリッド構成（オンプレ AD + Entra Connect）だとユーザー属性の問題が間接的に波及することもあるため、ユーザーとデバイスの両面で疑います。

カテゴリ	重複しやすいもの	よくある発生原因	優先度
デバイス	DeviceId、証明書由来の識別子、Autopilot 関連の物理 ID	古いデバイスオブジェクト残存／同一端末の複数登録／削除漏れや同期戻り	最優先
ユーザー	proxyAddresses、UPN、mail	メール別名の重複／一括変更の失敗／.local UPN の運用継続	高
同期/マッチング	Soft match / Hard match の不整合	Entra Connect の同期途中で停止、競合解消前に運用継続	高（ハイブリッド時）

「2024 年のクラッシュ以前はできていた」のが重要で、これは多くの場合、クラウド側に “中途半端なデータ” が残って整合が崩れた ことを示唆します。端末を何度初期化しても、クラウドの衝突が残っていれば同じ地点で落ち続けます。

まずやるべき切り分け：ユーザー依存か、端末依存か

復旧を速くするコツは「削除や初期化を始める前に、依存関係を切り分ける」ことです。次の表の順に当てると、原因領域がかなり絞れます。

切り分け観点	やること	読み取り	次に進む方向
特定ユーザーだけ失敗	別ユーザーで登録/展開を試す（可能なら検証端末）	ユーザー属性（UPN/proxyAddresses）やライセンス/MDM スコープの可能性	IdFix・同期ログ・ライセンス確認
特定端末だけ失敗	同一ユーザーで別端末は成功するか	端末固有の識別子がクラウド上の古い情報と衝突している可能性	Entra/Intune デバイスクリーンアップ
新品端末なら成功	一度も登録したことのない端末で試す	既存端末の “登録残骸” が原因でほぼ確定	端末側痕跡リセット＋クラウド整理

復旧の全体像：「クラウド側の重複解消」→「端末側の痕跡リセット」

今回のような DRS 失敗は、最終的に次の 2 つを揃えると解決しやすいです。

クラウド側（Entra ID / Intune）：同一端末に相当する古いオブジェクトや競合を除去する
端末側（Windows 11）：証明書・レジストリ・Join 状態などの “登録痕跡” を消してクリーンにする

重要なのは、どちらか片方だけでは再発しやすい点です。クラウドで古いデバイスが残ったまま端末だけ初期化しても衝突しますし、クラウドを掃除しても端末側が古い識別子を使い回すと衝突が戻ります。

Intune 側：管理対象デバイスレコードを整理する

Fresh Start のやり直しを重ねると、Intune に同名のデバイスが増え、どれが本体か分からなくなりがちです。まずは Intune 側の “管理対象デバイス” を整理します。

削除前に控える情報（後戻り防止）

端末名（表示名）
最終チェックイン
プライマリユーザー
可能ならシリアル番号

整理手順

Intune 管理センター：［デバイス］→［すべてのデバイス］
対象 PC 名で検索し、同名/類似名の一覧を出す
最終チェックインが古いもの、明らかに不要なものから削除する

迷った場合は、後段の Entra ID 側も含めて「1 台に収束させる」方針で進めると、衝突の根が消えやすくなります。

Entra ID 側：古いデバイスオブジェクトを削除して衝突を止める

DRS の段階で DirectoryValueExistsException が出るなら、Entra ID 側に “すでに同一性が存在している” 可能性が高いです。Entra 管理センターで対象デバイスを探し、古いものを削除します。

管理センターでの実施

Entra 管理センター：［デバイス］→［すべてのデバイス］
端末名で検索し、同名/類似名が複数ないか確認
Join 種別や最終アクティビティを見て、不要なデバイスを削除

Graph PowerShell で DeviceId（GUID）から探す例

ログに GUID（例：52596dbd-b271-4e66-b699-70efed9257d0）が出ている場合、それが DeviceId として扱えるケースがあります。管理センターで見つからないときは、Graph で検索すると絞り込みやすくなります。

# 例：必要な権限でサインイン（環境の運用に合わせて調整）
Connect-MgGraph -Scopes "Device.ReadWrite.All","Directory.ReadWrite.All"

# DeviceId が一致するデバイスを探す（例）
Get-MgDevice | Where-Object { $_.DeviceId -eq "52596dbd-b271-4e66-b699-70efed9257d0" } |
  Select-Object Id,DisplayName,DeviceId,ApproximateLastSignInDateTime

# 表示名でピンポイント検索できる場合
Get-MgDevice -Filter "displayName eq 'PC-NAME'" |
  Select-Object Id,DisplayName,DeviceId,ApproximateLastSignInDateTime

# 削除（必ず objectId（Id）を確認してから）
Remove-MgDevice -DeviceId "<objectId>"

同名デバイスが多いほど衝突は起きやすいので、「対象 PC と推定できる古いエントリを消す」ことが復旧の近道です。

Autopilot を使う環境での追加チェック

Autopilot を使っている場合、ハードウェアに紐づく情報が別枠で管理されます。通常は Autopilot デバイス自体を安易に消す必要はありませんが、次の状態があると Entra/Intune の整合が崩れやすくなります。

同一シリアル/同一端末と思われる Autopilot 登録が重複している
プロファイル割り当てやグループタグが意図せず変わっている
運用上「削除→再インポート」を繰り返して履歴が荒れている

端末側：Intune 登録痕跡（証明書・レジストリ）を完全に消す

クラウド側を掃除しても、端末側に古い登録情報が残っていると、同じ識別子を使い回して再び衝突することがあります。Fresh Start のやり直し前に、端末の登録状態をクリーンにします。

職場/学校アカウントを切断

Windows：［設定］→［アカウント］→［職場または学校にアクセスする］
対象の接続を選択し、切断を実行
切断できたことを確認

dsregcmd で Join 状態を確認・必要なら離脱

dsregcmd /status

ここで AzureAdJoined / WorkplaceJoined などの状態を把握します。状態が不整合に見える場合や、再登録で衝突を繰り返す場合は離脱も検討します。

dsregcmd /leave

Intune 登録用証明書の削除

ユーザー提示の条件では、発行元が SC_Online_Issuing の証明書が残っている可能性が挙がっています。証明書は、登録の “鍵” になるため、古いものが残ると衝突の引き金になり得ます。

certlm.msc（ローカルコンピューター）を起動
［個人］→［証明書］ を開く
発行元が SC_Online_Issuing の証明書があれば削除（発行先/用途を確認して誤削除を避ける）

環境によっては、Intune/登録関連の証明書として以下が見えることもあります（名称は環境で揺れます）。

Microsoft Intune MDM Device CA 相当
MS-Organization-Access / MS-Organization-P2P-Access 相当

IME（Intune Management Extension）ログで “どこまで進んだか” を確認

登録の途中で落ちているのか、登録はできているが配布が進んでいないのかを見分けるには、IME ログが役立ちます。

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

設定確認：MDM スコープとライセンスを「復旧作業の途中で」再チェック

今回の本命は重複衝突ですが、復旧作業中に基本設定の抜けがあると、登録できても運用に戻りません。最低限ここは押さえます。

MDM ユーザースコープ

Entra 管理センターの Mobility (MDM and MAM) → Microsoft Intune にて、MDM ユーザースコープが対象ユーザーを含むことを確認します。

「すべて」または対象ユーザーを含むグループ

ライセンス割り当て

対象ユーザーに Intune を含む必要なライセンスが割り当てられていることを確認します。グループベースライセンス運用の場合は、例外設定や最近の変更履歴も確認しておくと安全です。

ハイブリッド環境：IdFix と Entra Connect ログで “重複の根” を潰す

オンプレ AD があり Entra Connect で同期している場合、クラウド側で見える症状が「デバイス登録失敗」でも、根がユーザー属性の重複ということがあります。障害後にデータが荒れたなら、ここを放置すると別トラブルも連鎖します。

IdFix で重複チェック

IdFix を使い、特に次の属性を重点的にスキャンします。

proxyAddresses
userPrincipalName (UPN)
メール関連属性（mail など）

同期ログで競合キーワードを探す

Entra Connect サーバーのイベントログで、次のような競合を示すキーワードがないか確認します。

AttributeValueMustBeUnique
InvalidSoftMatch

修正後は差分同期で反映

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

UPN が .local のままなら是正を検討

[email protected] のような非ルーティングドメインを UPN に使い続けると、不整合や例外処理が増えがちです。Entra ID 側で確認済みドメイン（例：[email protected]）へ寄せることで、重複・同期エラーの温床を減らせます。

復旧後の確認：Entra / Intune / 端末が「1 台として一致」しているか

再登録に成功したら、成功を感覚で終わらせず、必ず “一致” を確認します。これができていると、再発時の切り分けが一気に楽になります。

確認すること	確認場所	期待する状態
Entra のデバイスが乱立していない	Entra 管理センター（デバイス）	同名が増殖していない／Join 種別が想定通り
Intune のデバイスが最新 1 台で管理される	Intune 管理センター（すべてのデバイス）	チェックインが継続／準拠・構成・アプリが進む
端末が正しい Join 状態	`dsregcmd /status`	AzureAdJoined 等が想定通り／異常が出ていない
IME が正常稼働	IME ログ	ポリシー取得・配布が連続失敗しない

それでも直らない場合：ログ採取のポイント（サポート依頼にもそのまま使える）

「削除したはずなのに同じエラーが出る」「管理センター上では見えないのに衝突している気がする」場合、ログで “何が一意制約に引っかかっているか” を詰めます。

端末側で採取しておくもの

イベントログ：Microsoft-Windows-User Device Registration（Admin/Operational）
イベントログ：DeviceManagement-Enterprise-Diagnostics-Provider（Admin）
Intune ログ：C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\

MDM 診断レポート

mdmdiagnosticstool.exe -out C:\Temp\MDMDiag

クラウド側で確認しておくもの

Entra の監査ログ（デバイス作成/更新/削除の履歴）
Intune の監査ログ（Fresh Start 実行履歴、デバイス操作履歴）
Entra Connect の同期エラー（競合・一意制約違反）

よくある落とし穴：ここを潰すと再発しにくい

同名デバイスが増えすぎて判断できない

表示名だけで追うと混乱します。最終アクティビティ、シリアル、プライマリユーザーなど “判断軸” を決め、残す 1 台を作っていく意識が重要です。端末名に資産番号を入れる運用も、後々効きます。

削除しても同期で戻る

ハイブリッド構成では、オンプレ AD 側に残るデバイスオブジェクトや同期の関連付けにより、クラウドで消したものが再作成されることがあります。クラウドだけを叩くのではなく、オンプレ側と同期整合を先に直すのが近道です。

セキュアブートや BIOS に寄りすぎる

セキュアブート有効/無効で結果が変わらないなら、今回の本命はハードではなく クラウド側の重複衝突 です。端末設定の検証より、デバイスオブジェクトの整理に時間を割いた方が解決が早いケースが多いです。

再発防止：壊れにくい運用へ寄せる

復旧できても、運用が同じだとまた増殖します。再発防止は「デバイスの棚卸し」「同期の健全性」「登録ルール」の 3 つが核です。

再発防止策	効果	実装のコツ
古いデバイスの定期クリーンアップ	同名乱立と衝突を抑える	「休眠の定義」を決め、Intune/Entra の整理を定期運用にする
ユーザーのデバイス登録上限を管理	登録の詰まりを回避	上限到達前に不要端末を削除するフローを用意
Entra Connect の監視と競合即時解消	属性重複を早期に潰せる	競合エラーの定期点検、IdFix で原因を除去
UPN/メール属性の統一	一意制約エラーの温床を減らす	.local を避け、確認済みドメインへ統一する
検証用の“新品扱い端末”を1台確保	原因切り分けが速い	障害時の基準点として、未登録端末を温存する

まとめ：解決の鍵は「重複の掃除」と「登録痕跡のリセット」

Intune の Fresh Start で Windows 11 展開が DRS（デバイス登録）で失敗し、DirectoryValueExistsException が出る場合、根本原因は Entra ID の一意制約に引っかかる重複 です。特に、2024 年の障害以降に再現し続けているなら、古いデバイスオブジェクトや同期途中で壊れたデータの残存を強く疑います。

効果の出やすい進め方は次の順序です。

ユーザー依存か端末依存かを切り分ける
Intune と Entra の古いデバイスを整理し、衝突の元を消す
端末側の証明書・レジストリ・Join 状態をクリアにする
ハイブリッドなら IdFix と同期ログで “重複の根” を解消する
再登録後は Entra/Intune/端末が 1 台として一致していることを確認する

ここまで実施しても改善しない場合は、端末ログ（User Device Registration / MDM 診断 / IME）とクラウド側の監査ログ・同期ログをセットで揃えることで、原因特定とサポート連携が一気に進みます。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。