Hacktoberfest 2026：維護者為十月標記出來的 issue，仍然開放、適合新手。 瀏覽 Hacktoberfest issue

SearchHighlightOff aborts Phase 5 on Microsoft-account devices — IsDynamicSearchBoxEnabled is protected by Consumer Cloud Policy

未關閉 適合新手
  • 哪裡不對？
#127 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視

維護者通常 1 天內回覆

還沒有人認領這個 Issue。

評估

難度
1/5
預估耗時
1 小時以內
新手友好度
90/100
Issue 類型
缺陷
描述清晰度
描述清楚
活躍度
活躍
技術堆疊
powershell
領域
operating-systems, tooling

研究方向

檢查 steps/registry-taskbar-search.ps1 以及 src/ 中對應的 SearchHighlightOff 項目，然後將其處理方式與 WidgetServiceOff 項目進行比較。加入相同的 BestEffort 行為，並執行 dev-config.ps1 -Action Full，以驗證遭拒的搜尋設定寫入不再中止 Phase 5，後續階段也能繼續執行。

由索引模型根據 Issue 內容生成。

描述

Summary

On a Windows 11 machine signed in with a Microsoft account, dev-config.ps1 -Action Full aborts at Phase 5/11 with:

-> Disable Show search highlights...

Calm OS setup stopped early.
  Windows blocked changing HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings\IsDynamicSearchBoxEnabled. Administrator access or Windows policy may restrict this setting.
  (_registry.ps1 line 50)

The setup is otherwise fully idempotent and resumes correctly, but it never gets past Phase 5, so Phases 6–11 never run.

Environment
  • OS: Windows 11, build 10.0.26300
  • Signed in with a Microsoft account (not a local account, not an Entra/work account)
  • Ran both as a normal user (-NoElevate) and as an elevated administrator — same failure in both cases
  • PowerShell 7.6.6 (PSEdition: Core)
What I checked (and ruled out)

I went through the usual suspects before concluding this is a policy issue:

Check Result
ACL on HKCU\...\SearchSettings User has FullControl; owner is the user
HKLM\SOFTWARE\Policies\Microsoft\Windows\Explorer Empty
HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search Empty
HKLM\SOFTWARE\Microsoft\PolicyManager\current\device (recursive, filtered by Search) Empty
gpresult /h "User has no RSoP data"
HKLM\SOFTWARE\Microsoft\Enrollments Only the three built-in authorities (Deploy, Cloud, Local); no real MDM enrollment
HKCU\...\SearchSettings value enumeration IsDynamicSearchBoxEnabled isn't even present as a value
Elevated Set-ItemProperty / .NET RegistryKey.SetValue Both fail with UnauthorizedAccessException ("Attempted to perform an unauthorized operation")
Settings UI → Privacy & security → Search Shows "Some of these settings are managed by your organization", and the "Show search highlights" toggle is greyed out / disabled

So this isn't an ACL problem, an MDM enrollment, a Group Policy, or a missing elevation. The write is blocked at the kernel level.

Root cause

This looks like Windows 11's Consumer Cloud Policy protection. When the device is signed in with a Microsoft account, Windows treats a set of search-related settings as cloud-managed and marks the corresponding registry keys so that no user-mode process — including an elevated administrator — can write them. The Settings UI itself surfaces this as "managed by your organization" and disables the toggle.

The practical consequence for the script: the desired end state (Show search highlights = off) is already in effect on these machines. The script simply cannot confirm it by writing the value.

Suggested fix

steps/registry-taskbar-search.ps1 already has a mechanism for exactly this situation. The WidgetServiceOff entry carries:

# Windows may protect the Widgets policy even from an administrator.
@{
    Name        = 'WidgetServiceOff'
    KeyPath     = 'HKLM\SOFTWARE\Policies\Microsoft\Dsh'
    ValueName   = 'AllowNewsAndInterests'
    Value       = 0
    Description = 'Disable Widgets'
    BestEffort  = $true
}

But SearchHighlightOff does not:

@{
    Name        = 'SearchHighlightOff'
    KeyPath     = 'HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\SearchSettings'
    ValueName   = 'IsDynamicSearchBoxEnabled'
    Value       = 0
    Description = 'Disable Show search highlights'
}

I verified locally that adding BestEffort = $true to the SearchHighlightOff entry lets Phase 5 complete (the item is skipped when the write is denied) and the script proceeds to Phases 6–11. Given that WidgetServiceOff is already documented as best-effort for the same class of OS protection, it would make sense to mark SearchHighlightOff the same way.

Workaround (for anyone hitting this in the meantime)

Edit C:\ProgramData\CalmOS\steps\registry-taskbar-search.ps1, add BestEffort = $true to the SearchHighlightOff entry, then re-run:

& "C:\ProgramData\CalmOS\dev-config.ps1" -Action Full -AllowUnsigned
Offer

Happy to open a PR against the src/ tree (not the signed release copies) if that's the preferred path — let me know.

主要語言
PowerShell
星號
2.9k
分支
202
平均合併
18 小時 49 分鐘
30 天內合併 PR
24

環境準備

  • 沒有 Dockerfile 或 Docker Compose 檔案
  • 沒有 Pull Request 範本
  • 閱讀貢獻指南

從這裡開始

  1. 先讀完整個 Issue，再讀專案的貢獻指南。
  2. 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
  3. Fork 儲存庫，在一個分支上完成修改。
  4. 送出 Pull Request，並在描述裡引用這個 Issue 編號。

microsoft/WindowsDeveloperConfig 的其他 Issue

查看 microsoft/WindowsDeveloperConfig 的全部 Issue

相似的 Issue

更多 Operating Systems Issue

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。