針對 Azure 網路連線進行疑難解答
Azure 網路連線 (ANC) 定期檢查您的環境，以確定所有需求都符合且處於狀況良好的狀態。 如果任何檢查失敗，您可以在系統管理中心 Microsoft Intune 看到錯誤訊息。 本指南包含一些進一步的指示，可針對可能導致檢查失敗的問題進行疑難解答。
Active Directory 網域加入
布建雲端計算機時，它會自動加入提供的網域。 若要測試網域加入程式，每次執行 Windows 365 健康情況檢查時，都會在定義的組織單位 (OU) 中建立網域計算機物件，其名稱類似 “的 #D07BA88ADEEF64765A9E706DB363CB35C Hth”。 當健康狀態檢查完成時，會停用這些計算機物件。 Active Directory 網域加入失敗的原因有很多。 如果網域加入失敗，請確定：
- 網域加入用戶有足夠的許可權可加入提供的網域。
- 網域加入使用者可以寫入組織單位 (提供的 OU) 。
- 網域加入使用者在可以加入的計算機數目中不受限制。 例如，每位用戶的預設聯結上限為10，而此上限可能會影響雲端電腦布建。
- 所使用的子網可以連線到域控制器。
- 您) 連線到雲端電腦 vNet/子網的 VM (虛擬機上，使用網域加入認證來測試 Add-Computer。
- 您可以針對網域加入失敗進行疑難解答，例如組織中的任何實體計算機。
- 如果您有可在因特網上解析的功能變數名稱， (如 contoso.com) ，請確定您的 DNS 伺服器已設定為內部。 此外，請確定他們可以解析 Active Directory 網域 DNS 記錄，而不是您的公用功能變數名稱。
Microsoft Entra 裝置同步處理
在行動裝置管理 (MDM) 註冊可以在布建期間進行之前，雲端電腦必須有 Microsoft Entra ID 物件。 這項檢查的目的是要確保您的組織計算機帳戶會及時同步至 Microsoft Entra ID。
請確定您的 Microsoft Entra 計算機物件會快速出現在 Microsoft Entra ID 中。 我們建議在 30 分鐘內，且不超過 60 分鐘。 如果計算機物件未在 90 分鐘內抵達 Microsoft Entra ID，布建就會失敗。
如果布建失敗，請確定：
- Microsoft Entra ID 上的同步期間組態已適當設定。 與身分識別小組交談，以確定您的目錄同步速度夠快。
- 您的 Microsoft Entra ID 作用中且狀況良好。
- Microsoft Entra Connect 正在正確執行，而且同步伺服器沒有任何問題。
- 您會手動對提供給雲端電腦的 OU 執行 Add-Computer。 該計算機物件在 Microsoft Entra ID 中出現所需的時間。
Azure 子網 IP 位址範圍使用方式
在 ANC 設定過程中，您必須提供雲端電腦將連線的子網。 針對每個雲端計算機，布建會建立虛擬 NIC，並從這個子網取用 IP 位址。
請確定有足夠的IP位址配置可供您預期布建的雲端電腦數目使用。 此外，請規劃足夠的地址空間來布建失敗和潛在的災害復原。
如果這項檢查失敗，請確定您：
- 檢查 Azure 虛擬網路 中的子網。 它應該有足夠的位址空間可用。
- 請確定有足夠的地址可處理三次布建重試，每個重試都可能會保留使用數小時的網路位址。
- 拿掉任何未使用的 vNIC。 最好使用雲端電腦專用的子網，以確保沒有其他服務會耗用IP位址的配置。
- 展開子網以提供更多位址。 如果裝置已連線，則無法完成此作業。
在布建嘗試期間，請務必考慮可在資源群組層級或更高層級套用的任何 CanNotDelete 鎖定。 如果這些鎖定存在，就不會自動刪除在進程中建立的網路介面。 在不會自動刪除它們中，您必須先手動移除 vNIC，才能重試。
在布建嘗試期間，請務必考慮資源群組層級或更高層級的任何現有鎖定。 如果這些鎖定存在，則不會自動刪除在進程中建立的網路介面。 發生這種情況時，您必須先手動移除 vNIC，才能重試。
Azure 租用戶整備程度
執行檢查時，我們會檢查提供的 Azure 訂用帳戶是否有效且狀況良好。 如果無效且狀況良好，我們就無法在布建期間將雲端計算機連線回您的 vNet。 計費問題之類的問題可能會導致訂用帳戶停用。
許多組織會使用 Azure 原則來確保資源只會布建到特定區域和服務。 您應該確定任何 Azure 原則都考慮雲端電腦服務和支持的區域。
登入 Azure 入口網站，並確定 Azure 訂用帳戶已啟用、有效且狀況良好。
此外，請流覽 Azure 入口網站 並檢視原則。 請確定沒有任何原則會封鎖資源建立。
Azure 虛擬網路整備程度
建立 ANC 時，我們會封鎖使用位於不支持區域中的任何 vNet。 如需支援區域的清單，請參閱 需求。
如果此檢查失敗，請確定提供的 vNet 位於支援區域清單中的區域。
DNS 可以解析 Active Directory 網域
若要 Windows 365 成功執行網域加入，連結至所提供 vNet 的雲端電腦必須能夠解析內部 DNS 名稱。
這項測試會嘗試解析提供的功能變數名稱。 例如，contoso.com 或 contoso.local。 如果此測試失敗，請確定：
- Azure vNet 中的 DNS 伺服器已正確設定為可成功解析功能變數名稱的內部 DNS 伺服器。
- 子網/vNet 的路由正確，讓雲端計算機可以連線到提供的 DNS 伺服器。
- 宣告子網中的雲端電腦/虛擬機可以在 DNS 伺服器上使用 NSLOOKUP，並以內部名稱回應。
除了提供之域名的標準 DNS 查閱，我們也會檢查_ldap._tcp.yourDomain.com記錄是否存在。 此記錄指出提供的 DNS 伺服器是 Active Directory 域控制器。 記錄是確認 AD 網域 DNS 可連線的可靠方式。 請確定這些記錄可透過 Azure 網路連線中提供的 vNet 存取。
端點連線能力
在布建期間，雲端計算機必須連線到多個Microsoft公開可用的服務。 這些服務包括 Microsoft Intune、Microsoft Entra ID 和 Azure 虛擬桌面。
您必須確定可以從雲端電腦所使用的子網連線到所有 必要的公用端點 。
如果此測試失敗，請確定：
- 您可以使用 Azure 虛擬網路 疑難解答工具，確保提供的 vNet/子網可以連線到檔中列出的服務端點。
- 提供的 DNS 伺服器可以正確解析外部服務。
- 雲端計算機子網與因特網之間沒有 Proxy。
- 實體、虛擬 (或 Windows) 中沒有任何防火牆規則可能會封鎖必要的流量。
- 您會考慮在針對雲端電腦所宣告的相同子網上，從 VM 測試端點。
如果您不是使用 Azure CloudShell，請確定您的 PowerShell 執行原則已設定為允許不受限制的腳本。 如果您使用 群組原則 來設定執行原則，請確定在 ANC 中定義的組織單位 (OU) 群組原則 物件) (GPO 設定為允許不受限制的腳本。 如需詳細資訊，請參閱 Set-ExecutionPolicy。
環境和設定已就緒
這項檢查適用於許多可能與客戶負責的基礎結構相關的基礎結構相關問題。 其中可能包含錯誤，例如內部服務逾時或客戶在執行檢查時刪除/變更 Azure 資源所造成的錯誤。
如果您遇到此錯誤，建議您重試檢查。 如果持續存在，請連絡支持人員以取得協助。
第一方應用程式許可權
建立 ANC 時，精靈會授與資源群組和訂用帳戶的特定層級許可權。 這些許可權可讓服務順暢地布建雲端計算機。
持有這類許可權的 Azure 系統管理員可以檢視和修改這些許可權。
如果撤銷其中任何一個許可權，此檢查就會失敗。 請確定已將下列許可權授與 Windows 365 應用程式服務主體：
- Azure 訂用帳戶上的讀者角色。
- 指定資源群組上的 Windows365 網路介面參與者角色。
- 虛擬網路上的 Windows365 網路使用者角色。
訂用帳戶上的角色指派會授與雲端電腦服務主體。
此外，請確定不會將許可權授與為 傳統訂用帳戶管理員角色 或「角色 (傳統) 」。 此角色不足。 它必須是先前所列的其中一個 Azure 角色型訪問控制內建角色。