Windows Autopilot 疑難解答常見問題

Windows Autopilot 的設計目的是要簡化 Windows 裝置生命週期的所有部分，但一律會發生問題。 針對問題進行疑難解答時，瞭解：

• Windows Autopilot 程式流程。
• 如何下載 Windows Autopilot 裝置配置檔 。
• 疑難解答期間要執行的重要活動。

無論是執行使用者驅動或自我部署裝置部署，疑難解答程式大致相同。 瞭解特定裝置的流程很有用：

1. 建立網路連線。 連線可以是無線 (Wi-fi) 或有線 (乙太網路) 連線。

2. 已下載 Windows Autopilot 配置檔。 使用有線連線或建立無線連線時，配置檔會在網路連線就緒時，立即從 Windows Autopilot 部署服務下載。

3. 發生用戶驗證。 在使用者驅動部署期間，用戶會輸入其 Microsoft Entra 認證，然後進行驗證。

4. Microsoft Entra 聯結發生。 針對使用者驅動部署，裝置會使用指定的使用者認證加入 Microsoft Entra ID。 在自我部署案例中，裝置會加入，而不指定任何用戶認證。

5. 發生自動行動裝置管理 (MDM) 註冊。 在 Microsoft Entra 加入程式中，裝置會註冊在 Microsoft Entra ID (中設定的 MDM 服務，例如，Microsoft Intune) 。

6. 會套用設定。 如果已設定 註冊狀態頁面 ，則會在顯示註冊狀態頁面時套用大部分的設定。 如果未設定或可用，則會在使用者登入之後套用設定。

當連線到因特網的 Windows 裝置啟動時，它會嘗試連線到 Windows Autopilot 服務並下載 Windows Autopilot 配置檔。 Windows Autopilot 配置檔會儘快下載，並在每次重新啟動后再次下載。

要執行的主要疑難解答活動包括：

• 檢閱設定：Microsoft Entra ID 和 Microsoft Intune 或非Microsoft行動裝置管理 (MDM) 服務是否已如 Windows Autopilot 設定需求中所指定設定？

• 檢查網路連線能力：裝置是否可以存取 Windows Autopilot 網路需求中所述的服務？

• OOBE) 行為 (Windows 全新體驗： 是否顯示預期的 OOBE 畫面？ Microsoft Entra 認證頁面是否如預期般使用組織特定的詳細數據進行自定義？

• Microsoft Entra 聯結問題：裝置是否能夠加入 Microsoft Entra ID？

• MDM 註冊問題：裝置是否能夠註冊 Microsoft Intune 或非Microsoft MDM 服務？

• 檢閱在 Windows Autopilot 失敗時自動收集的記錄。 如需詳細資訊，請參閱 從 Windows 裝置收集診斷。

在 Windows 11 上，可以開啟 Windows Autopilot 診斷頁面，以檢視有關 Windows Autopilot 布建程式的其他詳細疑難解答資訊。 若要啟用 Windows Autopilot 診斷頁面：

1. 移至需要啟用 Windows Autopilot 診斷頁面的 ESP 配置檔 。

2. 請確定 [ 顯示應用程式和設定檔設定進度 ] 已選取為 [ 是]。

3. 請確定 [ 開啟終端用戶的記錄收集和診斷] 頁面 已選取為 [ 是]。

若要在啟用診斷頁面之後存取任何診斷資訊，請選取 [ 檢視診斷] 按鈕或輸入按鍵 CTRL + SHIFT + D。在下列情況下，目前支援診斷頁面：

• Windows 11。
• Windows Autopilot 用戶驅動模式。
• 使用公司或學校帳戶登入時。 不支援個人Microsoft帳戶。

Windows Autopilot 會將項目記錄到事件記錄檔中。 記錄專案可用來查看與 Windows Autopilot 配置檔設定和 OOBE 流程相關的詳細數據。 您可以使用 事件檢視器 來檢視這些專案。 在應用程式和服務記錄 -Microsoft -Windows> -ModernDeployment-Diagnostics-Provider ->>Autopilot 檢閱 事件檢視器 中的資訊。>

根據案例和配置檔組態，可能會記錄下列事件：

從 Windows Autopilot 部署服務接收到的 Windows Autopilot 設定檔設定會儲存在裝置的登錄中。 您可以在登入中找到下列登入機碼的這項資訊：

HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot

可用的登入專案包括：

ETW 追蹤可用來從 Windows Autopilot 和相關元件取得詳細資訊。 您可以使用 Windows 效能分析器 或類似的工具來檢視 ETW 追蹤檔案。 如需詳細資訊，請參閱 針對 Windows Autopilot 進行疑難解答。

下列其中一種情況可能會發生錯誤碼 0x80180014 ：

1. Microsoft Intune 已變更 Windows Autopilot 自我部署模式和預先布建模式體驗。 若要重複使用裝置，必須刪除 Intune 所建立的裝置記錄。

   這項變更會影響使用自我部署或預先布建模式的所有 Windows Autopilot 部署。 當裝置重複使用、重設或重新部署配置檔時，這項變更會影響裝置。

   若要解決並修正此案例中的問題，並使用 Windows Autopilot 重新部署裝置，請遵循下列步驟：

   1. 登入 Microsoft Intune 系統管理中心。

   2. 在 [ 首頁] 畫面中，選取左側窗格中的 [ 裝置 ]。

   3. 在 [ 裝置] 中 |概觀 畫面， 在 [依平臺] 底下，選取 [Windows]。

   4. 在 Windows 中 |Windows 裝置 畫面的 [ 裝置上線] 底下，選取 [ 註冊]。

   5. 在 Windows 中 |註冊 畫面，在 [Windows Autopilot] 底下，選取 [ 裝置]。

   6. 選取發生錯誤的裝置，然後在工具欄中選取 [ 解除封鎖裝置]。

   7. 重新部署 Windows Autopilot 部署配置檔。

      注意事項

      選取 [ 解除封鎖裝置] 之後可能不會顯示成功訊息，但裝置已準備好再次使用。

2. Intune 租使用者中的 Windows MDM 註冊已停用。

   若要解決並修正此案例中的問題，並使用 Windows Autopilot 重新部署裝置，請遵循下列步驟：

   1. 登入 Microsoft Intune 系統管理中心。

   2. 在 [ 首頁] 畫面中，選取左側窗格中的 [ 裝置 ]。

   3. 在 [ 裝置] 中 |概觀 畫面， 在 [依平臺] 底下，選取 [Windows]。

   4. 在 Windows 中 |Windows 裝置 畫面的 [ 裝置上線] 底下，選取 [ 註冊]。

   5. 在 Windows 中 |註冊 畫面，在 [ 註冊選項] 底下，選取 [ 裝置平臺限制]。

   6. 在 [註冊限制] 畫面的 [裝置類型限制] 下，選取 [名稱] 數據行底下的 [所有使用者]。

   7. 在開啟的 [ 所有使用者] 畫面中，選取 [ 管理] 底下的 [ 屬性]。

   8. 在開啟的 [ 屬性] 畫面中，選取 [ 平台設定] 旁的 [ 編輯] 連結。

   9. 開啟的 [編輯限制 ] 畫面中：

   10. 在 [類型] 資料行底下找出 Windows (MDM) 。

   11. 請確定 [平臺] 資料行下的 [Windows (MDM) ] 已設定為 [允許]。

   12. 如果 Windows (MDM) 設定為 [封鎖]，請將它變更為 [允許]。

   13. 選 取 [檢閱 + 儲存]，然後選取 [變更設定 時儲存]，如果未變更設定，則選取 [ 取消 ]。

   14. 針對 [所有使用者] 以外的 [註冊限制] 畫面中可能存在的任何其他限制，重複上述步驟。 只需要驗證 Windows 平臺的限制。

   注意事項

   存在多個限制時，可能存在只允許特定群組 MDM 註冊的限制。 封鎖 MDM 註冊的某些限制可能根據指派限制的群組而有效。 發生此問題時，請確認裝置不是其中一個已封鎖 MDM 註冊的群組成員。 或者，如果適用，請將該限制的 MDM 註冊設定變更為 [允許]。

在這兩種案例中，除了發生錯誤 0x80180014 外，Windows 事件追蹤 (ETW) 記錄也可能會顯示下列行動裝置管理 (MDM) 錯誤：

MDM Enroll: Server Returned Fault/Code/Subcode/Value=(DeviceNotSupported) Fault/Reason/Text=(Enrollment blocked for AP device by SDM One Time Limit Check)

此問題通常會發生，因為 CSV 檔案中的裝置哈希格式不正確。 發生問題時，可以執行網路追蹤來確認問題。 如果網路追蹤中發生錯誤 400 ，很可能 CSV 檔案中的裝置哈希格式不正確。 400 錯誤訊息的訊息本文顯示：

Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'

損毀所收集哈希的任何專案都可能導致此錯誤。 其中一個可能性是哈希本身無法譯碼，即使哈希有效也一樣。

裝置哈希為Base64。 在裝置層級，它會編碼為未填補的Base64，但Windows Autopilot預期填補Base64。 通常，承載不需要填補，而且程式會正常運作。 不過，有時候承載不會乾淨地排列，而且需要填補。 在此情況下，會發生 400 錯誤訊息。 PowerShell 的Base64譯碼器也需要填補Base64，因此這個譯碼器可用來驗證哈希是否已正確填補。

哈希結尾的 「A」 字元實際上是空的數據。 Base64 中的每個字元都是6位。 Base64 中的 是等於 0 的 6 位。 在結尾刪除或新增 A 並不會變更實際的承載數據。

若要解決並修正此問題，必須修改哈希。 然後必須測試新值，直到 PowerShell 成功譯碼哈希為止。 結果大多難以辨識，只要未顯示 Base-64 char陣列或字串的長度 無效的錯誤即可。

若要測試base64，請使用下列PowerShell：

[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DEVICE HASH"))

例如:

[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("Q29udG9zbwAAA"))

這個特定範例不是裝置哈希，而是未填補的Base64不一致，因此適合用於測試。

現在適用於填補規則。 填補字元為 “=”。 填補字元只能在哈希的結尾，而且最多只能有兩個填補字元。 以下是基本邏輯。

• 譯碼哈希是否失敗？
  • 是：最後兩個字元是否為 “=”？
    • 是：以單一 “A” 字元取代 “=”，然後再試一次
    • 否：在結尾新增另一個 “=” 字元，然後再試一次
• 否：該哈希有效

在上一個範例哈希上循環邏輯時，我們會取得下列排列：

• Q29udG9zbwAAA
• Q29udG9zbwAAA=
• Q29udG9zbwAAA==
• Q29udG9zbwAAAA
• Q29udG9zbwAAAA=
• Q29udG9zbwAAAA== - 此結果具有有效的填補。

將收集到的哈希取代為此新的填補哈希，然後再次嘗試匯入。

如果符合下列條件，則不會套用 Windows Autopilot 配置檔：

• 裝置上發生硬體變更。

• 裝置會在下列其中一個版本之前重新安裝映像到 Windows 版本：

  • Windows 11 版本 21H2 與 KB5017383。

  • Windows 10 22H2 版。

這是預期的行為。

[ 修正擱置 中] 或 [ 需要注意 ] 訊息也可能顯示在裝置的 [Windows Autopilot 裝置 ] 頁面中。 這些訊息表示裝置上發生硬體變更。 選取 [ 修正暫止 狀態] 的連結時，會出現下列訊息：

We've detected a hardware change on this device. We're trying to automatically register the new hardware. You don't need to do anything now; the status will be updated at the next check in with the result.

若要解決並修正此問題，請取消註冊並重新註冊裝置。 如需有關如何取消註冊裝置的詳細資訊，請參閱下列文章：

• 取消註冊裝置。
• 傳回 Windows Autopilot 登入和部署體驗的重要功能。
• Windows Autopilot 主機板更換案例指引。

如果裝置先前在加入 Microsoft Entra ID 之前已在 Microsoft Entra ID 中註冊，就會發生此問題。 裝置可能透過工作場所加入等 Microsoft Entra ID 註冊。 如果在裝置加入 Microsoft Entra ID 之前，未從 Microsoft Entra ID 刪除 Microsoft Entra ID 註冊的裝置，則會將先前的信任類型保留在記錄中。 將現有的 Microsoft Entra 註冊裝置加入 Microsoft Entra ID 會導致 Windows Autopilot 裝置顯示為已註冊 Microsoft Entra，而不是 Microsoft Entra 加入。

若要解決並修正此問題，在將現有 Microsoft Entra ID 註冊的裝置註冊為 Windows Autopilot 裝置之前，應該先刪除裝置的下列現有裝置物件：

• Microsoft Intune。
• Microsoft Entra ID。
• Windows Autopilot。

刪除所有裝置物件之後，請將裝置重新註冊為 Windows Autopilot 裝置，然後重新註冊裝置。 如需正確刪除所有裝置對象的詳細資訊，請參閱 取消註冊裝置。

若要針對 Microsoft Intune 中的註冊問題進行疑難解答，例如發生錯誤錯誤頁面中的錯誤碼80180018，請參閱針對 Intune 中的 Windows 裝置註冊錯誤進行疑難解答。 常見問題可能包括：

• 指派給用戶的授權不正確或遺失。
• 為用戶註冊的裝置太多。

如果 Windows Autopilot 重設立即失敗並出現錯誤，請參閱 Windows Autopilot 重設：疑難解答 以取得更多說明：

Ran into trouble. Please sign in with an administrator account to see why and reset manually.

檢查裝置是否收到 Windows Autopilot 配置檔很有用。 如果裝置確實收到 Windows Autopilot 配置檔，請確認配置檔中的設定正確無誤。

此錯誤訊息通常表示授權有問題。 完整的錯誤訊息會顯示：

Something went wrong

Can't connect to the URL of your organization's MDM terms of use. Try again, or contact your system administrator with the problem information from this page.

確認登入裝置的使用者具有有效的 Intune、EMS 或 Microsoft 365 授權。

將裝置加入 Microsoft Entra ID的最常見問題與 Microsoft Entra 許可權有關。 請確定已備妥正確的設定，以允許使用者加入裝置以 Microsoft Entra ID。 如需詳細資訊，請參閱 設定需求。

如果使用者超過允許可以加入的裝置數目，就會發生錯誤。 此預設限制為 50 部裝置，但可在 Microsoft Entra ID 中設定。 如需詳細資訊，請參閱瞭解 Intune 和 Microsoft Entra 裝置限制。

匯入時會建立 Microsoft Entra 裝置。 請務必不要刪除此物件。 物件會在群組成員資格和目標設定的 Microsoft Entra ID 中作為 Windows Autopilot 的錨點，包括配置檔。 刪除它可能會導致 Microsoft Entra 聯結錯誤。 如果刪除此物件，可以藉由將裝置刪除並重新匯入為 Windows Autopilot 裝置來修正此問題。 刪除裝置並重新匯入為 Windows Autopilot 裝置，會在 Microsoft Entra ID 中重新建立相關聯的物件。

Windows 有大量可用的原則設定，包括：

• 原生行動裝置管理 (MDM) 原則。
• 組策略 (ADMX 支援的) 設定。

某些原則設定可能會在某些 Windows Autopilot 案例中造成問題。 這些問題可能會因為原則如何變更 Windows 行為而發生。 如果發現上述任何問題，請移除有問題的原則以解決問題。

已知下列原則會造成 Windows Autopilot 的問題。 請務必適當地設定原則，以免與 Windows Autopilot 發生衝突：

Windows Autopilot 所使用的註冊狀態頁面 (ESP) 不支援混合企業營運 (LOB) 和 Win32 應用程式。 LOB 和 Win32 應用程式都使用 TrustedInstaller ，不允許同時安裝。 如果 LOB 和 Win32 應用程式同時嘗試安裝，ESP 期間會發生下列錯誤訊息：

Another installation is in progress, please try again later.

如需詳細資訊， 請參閱設定註冊狀態頁面 - 裝置設定：應用程式。

如果需要混合 LOB 和 Win32 應用程式，請考慮使用 Windows Autopilot 裝置準備，這不會使用 ESP，因此支援混合 LOB 和 Win32 應用程式。

Microsoft 365 隨選即用版本 Office 的 Teams Machine-Wide 安裝程式 元件包含 MSI 安裝。 ESP 不會追蹤 Teams Machine-Wide 安裝程式 MSI 安裝。 因為 ESP 不會追蹤 Teams Machine-Wide 安裝程式 MSI 安裝，所以當其他 Win32 應用程式 MSI 型安裝嘗試在 ESP 期間安裝時，可能會造成衝突。 MSIS 會透過 TrustedInstaller 安裝，但不允許同時安裝。 此衝突可能導致 Teams Machine-Wide 安裝程式失敗，或 ESP 期間的其他 MSI 型安裝失敗。 如需詳細資訊， 請參閱設定註冊狀態頁面 - 裝置設定：應用程式。

此問題可能是隨機的，而且不一定會發生。 發生此問題的原因是 Teams Machine-Wide 安裝程式 MSI 安裝與其他 Win32 應用程式 MSI 安裝之間的計時問題。

若要解決此問題或避免錯誤，請使用下列其中一個解決方案：

1. 請勿在 Office 的 Microsoft 365 隨選即用安裝中安裝 Teams 。 相反地，在 Windows Autopilot 部署完成之後，將 Teams 部署為 Win32 應用程式。

2. 請勿在 ESP 期間安裝 Microsoft 365 隨選即用版本的 Office。 相反地，在 Windows Autopilot 部署完成之後，部署 office 的 Microsoft 365 隨選即用安裝。

3. 使用自定義 PowerShell 腳本 Intune 管理延伸模組 (IME) ，檢查 TrustedInstaller 目前是否正在安裝另一個 MSI。 如果是，請等候目前的 MSI 完成安裝，然後再啟動新的 MSI 安裝。

4. 針對 Windows 11 部署，請使用 Windows Autopilot 裝置準備。 Windows Autopilot 裝置準備不會使用 ESP，因此支援 LOB 和 Win32 應用程式的混合。

5. ESP 失敗時發生錯誤時繼續。 如果啟用此選項時發生問題，則可能無法安裝包括 Teams 在內的某些應用程式。 不過，ESP 會繼續且不會失敗。

相關內容

• Windows Autopilot - 已知問題。
• 收集 MDM 記錄。
• 從 Windows 裝置收集診斷。