依序檢查 Intune 授權、Enrollment Restriction、Autopilot Profile、合規政策、BitLocker／Secure Boot 與 Win32 App 偵測規則。
Autopilot 與註冊：裝置為什麼「沒進公司流程」
先建立一個最關鍵的觀念，這個觀念能替你省下一半的抓蟲時間：已經註冊到 Autopilot、但還沒指派設定檔的機器，會套用預設 Autopilot 設定檔，並不會退回消費者畫面。反過來說，你在 OOBE 看到的是消費者版的區域設定流程，幾乎可以直接斷定——這台的硬體雜湊（hardware hash）根本沒成功上傳到租戶。方向抓對了，才不會白忙一場。
硬體雜湊到底是什麼，為什麼 Excel 一開就壞
硬體雜湊不是序號，也不是隨便一組識別碼。它是一段從主機板 SMBIOS、TPM、網卡等硬體特徵萃取、再經過 base64 編碼的二進位指紋，長度動輒好幾 KB。裝置就是靠這段指紋，在雲端被辨認成「這是公司的機器」。Get-WindowsAutopilotInfo 腳本抓出來的 CSV，欄位包含序號、Windows 產品 ID、硬體雜湊，其中序號與雜湊兩欄是必填，而且標頭大小寫敏感、不能多欄。
最常翻車的動作，是拿 Excel 去開這個 CSV。Excel 會自作聰明地重排欄位、把長字串截斷、改動編碼與換行，甚至把那段 base64 的尾巴吃掉；存回去以後上傳，服務端就回你 HTTP 400，錯誤裡帶著 Edm.Binary 字樣——意思是那個二進位欄位的格式壞了，雲端拒收。官方文件白紙黑字建議：這個匯入 CSV 一律用純文字編輯器開，別碰 Excel。正解是用腳本直接輸出檔案（雜湊預設會存到 C:\HWID\AutopilotHWID.csv），或乾脆加 -Online 參數當場上傳，全程不落地、不手動編輯，就沒有格式被弄壞的空間。
時序問題：設定檔要在「連網那一步之前」就已指派
雜湊傳上去只是第一步。傳統 Autopilot（有人叫它 v1）的運作邏輯是：裝置在 OOBE 一連上網，就拿自己的雜湊去雲端「認領」對應的部署設定檔。所以設定檔必須在裝置連網那一刻之前，就已經是「已指派」狀態才會生效。你如果先開機、再回頭去改設定檔或補指派，那台已經錯過時機，只能整台重設、重新走一次 OOBE。這也是為什麼建議先在後台把整批機器的雜湊、群組標籤、設定檔都備妥，再讓現場開機，而不是邊開邊設、開了才發現漏。
兩支長得很像的註冊錯誤碼，千萬別搞混
Windows 註冊天天遇到的一支是 0x80180014，畫面通常寫「貴組織不支援這個版本的 Windows」或裝置管理無法啟用。很多人一看到就以為是裝置數量爆了，跑去砍舊裝置——方向錯了。這支碼官方的意思是 MDM 註冊被停用、或被註冊限制擋下：到 Devices 的 Enrollment restrictions，把 Windows（MDM）平台設成 Allow 就解。真正代表「使用者註冊裝置數到上限」的是另一支 0x80180013，預設每位使用者最多註冊 15 台。兩支碼只差一個數字，處理方向卻天差地遠，看錯就白花半小時。
Hybrid Join 與 v1／v2 的工程取捨
還有一個常被問到的：混合式 Entra 加入（Hybrid Join）搭 Autopilot 到底能不能用？能用，但微軟現在明確「不建議」新裝置走這條路。原因在機制：Hybrid Join 的首次登入必須連得到地端網域控制站（DC）才能完成，使用者在家、在外、公司 VPN 還沒起來的時候，就卡死在登入畫面。請注意用詞是「不建議」，不是「已淘汰」；被真正淘汰的是舊版的 Intune 連接器元件，兩件事別混為一談。
如果你的環境還在評估要走哪條路，可以用這組準則判斷：
- 還需要地端 AD、要 Hybrid Join、機隊裡還有 Windows 10、OOBE 階段要塞很多大型 App 或要用預先佈建（white glove）——留在傳統 Autopilot（v1），因為新的 Autopilot Device Preparation（v2）這些都不支援。
- 全機隊已是 Windows 11、純雲端、只做 Entra Join、OOBE 佈署的 App 控制在 25 個、指令碼 10 支以內——可以評估改用 Device Preparation（v2）。v2 最大的差別是不再需要事先上傳硬體雜湊，改用「註冊時分組」（Enrollment Time Grouping），使用者在 OOBE 通過 Entra 驗證後才動態拿到設定，現場不用再為漏傳雜湊而抓狂，導入速度也更快。
一句話總結取捨：要地端相容就走 v1，要輕量純雲端就走 v2，但 v2 不吃 Hybrid Join，這條紅線先畫清楚，免得選錯架構整案重來。
合規政策：裝置莫名「不合規」怎麼查
裝置突然被標成 Not compliant，先深呼吸，別急著動政策。到 Devices 的 Compliance、Monitor 分頁點進去，看清楚到底是哪一條設定沒過，再對症下藥。九成的「莫名不合規」，其實都是可以解釋、也可以預防的。
BitLocker 與 Secure Boot：頭號假性不合規
最容易誤判的兩條，是 BitLocker 與 Secure Boot。關鍵在它們的量測機制：這兩項狀態不是即時讀取的，而是在開機當下透過裝置健康證明（Device Health Attestation，DHA）從系統開機記錄裡量出來的。DHA 拿的是「上一次開機」那份 boot log，送到證明服務比對，再於下一次簽到時把結果回報給 Intune。
這個機制會造成一個天天發生的假象：磁碟明明已經加密完成、Secure Boot 明明開著，但因為裝置還沒重開機、還沒重新產生一份新的 boot log，Intune 讀到的仍是舊狀態，於是顯示不合規。更麻煩的是，如果裝置剛重開機、或剛從睡眠喚醒就立刻 sync，這一項甚至可能短暫報成 Error。解法很直接：重開機一次，讓它產生新的開機記錄，再同步。另外要記得一個硬性前提——Secure Boot 要求 TPM 2.0 加 UEFI，老機器如果還卡在 Legacy BIOS，這條是永遠過不了的，那不是設定問題，是硬體不符，別在政策裡繞。
租戶層那個沒人注意的隱藏開關
有一個租戶等級的預設值，很多人裝了大半年都沒發現。在 Endpoint security、Device compliance、Compliance policy settings 裡，有一項「沒有指派任何合規政策的裝置，標記為」——它預設是 Compliant（合規）。單看沒問題，但一旦你搭配條件式存取（Conditional Access）拿合規當放行門檻，這個預設就變成一個大漏洞：任何漏網、沒被政策涵蓋到的裝置，會被當成合規直接放行。微軟的建議是把它改成 Not compliant，這樣沒被政策管到的機器會立刻現形，你也能在「無合規政策的裝置」報表裡把它們揪出來補指派。
兩個「天數」別搞混：立即生效 vs 有效期間
很多人以為合規政策有 30 天的寬限期，其實這裡藏了兩個完全不同的「天數」，把它們分清楚很重要：
- 不合規時採取的動作，預設 0 天、立即生效。「標記裝置為不合規」這個動作是每條政策內建的，預設就是 0 天——規則一破，馬上標不合規。如果你有搭條件式存取，這裡的行為要特別注意：把它調成「X 天後才標記」，裝置在那 X 天內會進入「寬限期（In grace period）」狀態，而在寬限期內，Entra 還沒收到不合規訊號，條件式存取不會擋人；一定要等寬限期過完、使用者還沒補救，Intune 才把不合規寫進 Entra，存取才被擋下。想給使用者留緩衝，就是靠調這個天數，但也要理解它會連帶延後 CA 的封鎖時點。
- 合規狀態有效期間，預設 30 天。那個常被誤傳成「寬限期」的 30 天，其實是裝置回報的有效期。裝置太久沒跟雲端簽到、超過這個期限，就會被當成不合規——這是在防「一台機器離線太久、狀態早就過時卻還掛著合規」的情形。
要讓狀態馬上更新，別乾等例行的簽到週期。管理員在 admin center 按 Sync，或請使用者打開公司入口網站（Company Portal）按一下檢查狀態，都能強制回報，比苦等一輪週期快得多。
App 派送與 IME 紀錄檔：裝了沒、為什麼一直重裝
Win32 App（.intunewin 封裝）派不下去，八成不是安裝本身出錯，而是偵測規則（detection rule）寫歪了。這是最反直覺、也最耗時間的一塊，值得講細一點。
0x87D1041C：明明裝成功了，卻被判「沒裝到」
錯誤碼 0x87D1041C 的真正含義是：App 其實已經成功安裝，但 Intune 事後拿偵測規則去驗，卻驗不到它的存在。於是系統認定「還沒裝」，下一個週期又派一次、又裝一次——你就看到同一支 App 陷入無限重裝的迴圈，畫面一直卡在安裝中。
這個迴圈最常見的兇手，是偵測規則的 32 位元與 64 位元搞錯。關鍵機制在於：Intune 管理擴充（IME）本身是一個 32 位元行程。它去讀登錄或檔案路徑時，如果你的規則指向的是 64 位元的 Program Files 或 64 位元的登錄檢視，IME 用 32 位元視角去看就會被系統重導到 WOW6432Node、找不到目標，於是誤判成沒裝。反過來，如果規則寫得太寬鬆（例如只檢查一個資料夾存不存在），又會在還沒真的裝好時就誤判成「已安裝」而直接跳過。偵測規則要精準指到唯一、且安裝後才會出現的證據——特定版本的檔案、或安裝程式寫入的版本登錄機碼——太緊會漏、太鬆會誤放，這中間的分寸就是工程判斷。
用自訂偵測指令碼的三條原則
如果你用 PowerShell 自訂偵測指令碼，它的判定邏輯跟直覺不一樣，這三條一定要背：離開代碼（exit code）必須是 0、而且 STDOUT 必須有輸出，兩者同時成立才算「已安裝」；更陰險的是——只要 STDERR 吐出任何一個字，整支就會被判成沒裝。所以指令碼裡任何可能噴紅字的指令，記得補上 -ErrorAction SilentlyContinue 之類的手段把雜訊壓乾淨，否則一個無害的警告，就足以讓整支 App 陷進重裝迴圈。
紀錄檔位置與「為什麼按了 Sync 還是不動」
要查 App 到底卡在哪，紀錄檔的位置請直接背起來：C:\ProgramData\Microsoft\IntuneManagementExtension\Logs。App 安裝的細節，從 2408 版之後主要看 AppWorkload.log（舊版看 IntuneManagementExtension.log），搭配 CMTrace 這類工具開最好讀，能即時捲動又能過濾關鍵字，比在事件檢視器裡大海撈針有效率。
還有一個很多人踩過的認知誤區：在 admin center 按 Sync，觸發的只是 MDM 的簽到，它不會立刻叫 IME 去跑 App 的安裝流程。想讓 IME 馬上動起來，最快的做法是重啟裝置上的 Intune Management Extension 服務，服務一起來就會重新評估待辦的 App，比空等下一個週期有效率得多。
iOS 那兩張會過期的憑證，別搞混續約規則
管到蘋果裝置，有兩張憑證每年都會到期，續約規則不一樣，混淆的代價很高：
- Apple 推播憑證（APNs）：有效期一年，續約務必用「同一個」Apple ID。它是所有 iOS／iPadOS 裝置能被管理的命脈。萬一過期，官方雖留了約 30 天的補救寬限，但如果你用了不同的 Apple ID 去續、或讓它真的失效，會逼全部蘋果裝置重新註冊——那是一場災難。這個 Apple ID 建議用公司共用信箱申請、記進交接文件，別綁在某個離職就找不到人的個人帳號上。
- ADE／DEP 權杖：有效期也是一年，但換 Apple ID 不會逼裝置重註冊。它管的是自動裝置註冊的對應關係，續約時從商務管理後台下載新權杖上傳即可，Intune 會自動重新同步一批裝置，就算換了帳號，也不會有 APNs 那種連鎖重註冊的後果。
一句話記法：APNs 認 Apple ID、過期會逼全體重註冊；ADE 權杖比較寬容、換帳號沒事。兩者都要提前設好到期提醒，別等使用者反映「手機不能用了」才發現憑證早就過期。
環環相扣，才是 Intune 真正難的地方
把上面這些攤開來看，你會發現 Intune 的麻煩很少出在單一設定，而在 Autopilot、合規政策、條件式存取、App 派送這幾塊環環相扣：一段硬體雜湊沒傳成功，整批機器就卡在門口進不了公司流程；一條偵測規則的 32／64 位元勾錯，一支 App 就無限重裝；一個租戶層的合規預設值沒改，條件式存取就默默放行了不該放的裝置。每一塊單看都不難，難在它們串在一起、又各有各的時序與量測機制，出事的時候要能快速定位是哪一環出了問題。
廷皓科技在高雄楠梓，服務高雄、台南、屏東的中小企業。從 Autopilot 註冊、合規政策設計、條件式存取，到 Win32 App 封裝與派送，我們都能代管，也能在你現有的環境上做健檢，把上面這些坑先一次補起來。想把公司筆電的部署與日常管理，交給真的懂 Intune、出了事還找得到人的在地團隊，歡迎跟廷皓聊聊。
