Microsoft Entra Connect 物件和屬性的端對端疑難排解

本文旨在建立如何針對Microsoft Entra ID 中的同步處理問題進行疑難解答的常見作法。 此方法適用於物件或屬性未同步處理至 Azure Active AD 的情況，而且不會在同步處理引擎、應用程式查看器記錄或Microsoft Entra 記錄中顯示任何錯誤。 如果沒有明顯的錯誤，很容易在詳細數據中遺失。 不過，藉由使用最佳做法，您可以隔離問題，併為 Microsoft 支援服務 工程師提供見解。

當您將此疑難解答方法套用至您的環境時，一段時間后，您將能夠執行下列步驟：

• 針對從端對端同步處理引擎邏輯進行疑難解答。
• 更有效率地解決同步處理問題。
• 藉由預測發生問題的步驟，以更快速地找出問題。
• 識別檢閱數據的起點。
• 判斷最佳解析度。

此處提供的步驟會從本機 Active Directory 層級開始，並逐步Microsoft Entra ID。 這些步驟是同步處理最常見的方向。 不過，相同的原則適用於反向方向（例如，針對屬性回寫）。

必要條件

若要進一步瞭解本文，請先閱讀下列必要條件文章，以深入瞭解如何搜尋不同來源中的物件（AD、AD CS、MV 等），以及如何檢查對象的連接器和譜系。

• Microsoft Entra Connect：帳戶和權限
• 針對未 Microsoft 與 entra 識別符同步處理的物件進行疑難解答
• 針對使用 Microsoft Entra Connect 同步所執行的物件同步處理進行疑難排解

不正確的疑難解答做法

Microsoft Entra ID 中的 DirSyncEnabled 旗標可控制租使用者是否準備接受來自內部部署 AD 的物件同步處理。 我們已看到許多客戶習慣在針對物件或屬性同步處理問題進行疑難解答時停用租使用者上的 DirSync。 執行下列 PowerShell Cmdlet，即可輕鬆地關閉目錄同步處理：

Set-MsolDirSyncEnabled -EnableDirSync $false "Please DON'T and keep reading!"

注意

自 2024 年 3 月 30 日起，Azure AD 和 MSOnline PowerShell 模組已被淘汰。 若要深入了解，請閱讀淘汰更新。 在此日期之後，對這些模組的支援僅限於對 Microsoft Graph PowerShell SDK 的移轉協助和安全性修正。 淘汰的模組將繼續運作至 2025 年 3 月 30 日。

我們建議移轉至 Microsoft Graph PowerShell 以與 Microsoft Entra ID (以前稱為 Azure AD) 互動。 如需了解常見的移轉問題，請參閱移轉常見問題。 注意：MSOnline 1.0.x 版可能會在 2024 年 6 月 30 日之後發生中斷。

不過，這可能會是災難性的，因為它會觸發複雜且冗長的後端作業，以將SoA從本機 Active Directory 傳輸至租使用者上所有同步物件Microsoft Entra ID / Exchange Online。 這項作業必須將每個物件從 DirSyncEnabled 轉換成僅限雲端，並清除從內部部署 AD 同步處理的所有陰影屬性（例如 ShadowUserPrincipalName 和 ShadowProxyAddresses）。 視租使用者的大小而定，此作業可能需要超過 72 小時的時間。 此外，您無法預測作業何時完成。 請勿使用此方法對同步問題進行疑難解答，因為這會造成額外的傷害，而且不會修正問題。 您將無法再次啟用 DirSync，直到此停用作業完成為止。 此外，在您重新啟用 DirSync 之後，AADC 必須再次比對所有內部部署對象與現有Microsoft Entra 物件。 此程式可能會造成干擾。

唯一支援停用 DirSync 命令的案例如下：

• 您要解除委任內部部署同步處理伺服器，而您想要從雲端完全管理身分識別，而不是從混合式身分識別管理身分識別。
• 您在租使用者中有一些同步的物件，您想要保留為僅限雲端的 Microsoft Entra 識別符，並永久從內部部署 AD 移除。
• 您目前使用自定義屬性作為 AADC 中的 SourceAnchor （例如 employeeId），而且您正在重新安裝 AADC 以開始使用 ms-Ds-Consistency-Guid/ObjectGuid 作為新的 SourceAnchor 屬性（反之亦然）。
• 您有一些案例涉及具風險的信箱和租使用者移轉策略。

在某些情況下，您可能必須暫時停止同步處理，或手動控制AADC同步處理週期。 例如，您可能必須停止同步處理，才能一次執行一個同步步驟。 不過，您可以執行下列 Cmdlet 來停止同步排程器，而不是停用 DirSync：

Set-ADSyncScheduler -SyncCycleEnabled $false

當您準備好時，請執行下列 Cmdlet 以手動啟動同步迴圈：

Start-ADSyncSyncCycle

字彙

縮寫/縮寫	名稱/描述
AADC	Microsoft Entra Connect
AADCA	Microsoft Entra 連接器帳戶
AADCS	Microsoft Entra 連接器空間
AADCS:AttributeA	Microsoft Entra Connector Space 中的屬性 'A'
ACL	存取控制 清單 （也稱為 ADDS 許可權）
ADCA	AD 連接器帳戶
ADCS	Active Directory 連接器空間
ADCS:AttributeA	Active Directory 連接器空間中的屬性 'A'
ADDS 或 AD	Active Directory 網域服務
CS	連接器空間
MV	Metaverse
MSOL 帳戶	自動產生的 AD 連接器帳戶 (MSOL_########)
MV:AttributeA	Metaverse 物件中的屬性 'A'
SoA	授權來源

步驟 1：ADDS 與 ADCS 之間的同步處理

步驟 1 的目標

判斷物件或屬性是否存在，並在 ADCS 中保持一致。 如果您可以在 ADCS 中找到物件，而且所有屬性都有預期的值，請移至 步驟 2。

步驟 1 的描述

ADDS 和 ADCS 之間的同步處理會在匯入步驟發生，而此時 AADC 會從來源目錄讀取，並將數據儲存在資料庫中。 也就是說，在連接器空間中暫存數據時。 從 AD 匯入差異期間，AADC 會要求指定目錄浮浮水印之後發生的所有新變更。 AADC 會針對 Active Directory 複寫服務使用目錄服務 DirSync Control 來起始此呼叫。 此步驟會提供最後一個浮浮浮水印作為最後一個成功的 AD 匯入，並提供 AD 從應擷取所有 （delta） 變更的時間點參考。 完整匯入不同，因為 AADC 會從 AD 匯入所有資料（在同步範圍中），然後標示為過時（並刪除）仍在 ADCS 但未從 AD 匯入的所有物件。 AD 與 AADC 之間的所有資料都會透過 LDAP 傳輸，且預設會加密。

如果與 AD 的連線成功，但 ADCS 中沒有物件或屬性（假設網域或對象處於同步範圍中），則最可能涉及 ADDS 許可權的問題。 ADCA 需要 AD 中物件的最小讀取許可權，才能將數據匯入 ADCS。 根據預設，MSOL 帳戶具有所有使用者、群組和計算機屬性的明確讀取/寫入許可權。 不過，如果下列條件成立，這種情況可能仍然有問題：

• AADC 使用自定義 ADCA，但未在 AD 中提供足夠的許可權。
• 父 OU 已封鎖繼承，這可防止從網域根目錄傳播許可權。
• 對象或屬性本身已封鎖繼承，這可防止傳播許可權。
• 對象或屬性具有明確的 Deny 許可權，可防止 ADCA 讀取它。

針對 Active Directory 進行疑難解答

與 AD 的連線

在同步處理服務管理員中，[從 AD 匯入] 步驟會顯示在 [連線狀態] 底下連絡的域控制器。 當有會影響 AD 的連線問題時，您很可能會在這裡看到錯誤。

如果您必須進一步針對AD的連線能力進行疑難解答，特別是如果Microsoft Entra Connect 伺服器中未出現任何錯誤，或您仍在安裝產品的過程中，請先使用 ADConnectivityTool。

ADDS 的連線問題有下列原因：

• 無效的 AD 認證。 例如，ADCA 已過期或密碼已變更。
• 「失敗搜尋」錯誤，當 DirSync Control 未與 AD 複寫服務通訊時發生，通常是因為高網路封包分散。
• 「無啟動馬」錯誤，會在 AD 中發生名稱解析問題 （DNS） 時發生。
• 其他可能由名稱解析問題、網路路由問題、封鎖的網路埠、高網路封包分散、無可寫入DC等所造成的問題。 在這種情況下，您可能必須涉及目錄服務或網路支援小組，以協助進行疑難解答。

疑難解答摘要

• 識別使用哪一個域控制器。
• 使用慣用的域控制器，以相同的域控制器為目標。
• 正確識別ADCA。
• 使用 ADConnectivityTool 來識別問題。
• 使用LDP工具嘗試使用ADCA與域控制器系結。
• 請連絡目錄服務或網路支援小組，以協助您進行疑難解答。

執行同步處理疑難解答員

針對 AD 連線問題進行疑難解答之後，請執行 疑難解答物件同步 處理工具，因為這樣一來，就能夠偵測到物件或屬性無法同步處理的最明顯原因。

AD 許可權

缺少 AD 權限可能會影響同步處理的兩個方向：

• 當您從 ADDS 匯入 ADCS 時，缺少許可權可能會導致 AADC 略過物件或屬性，讓 AADC 無法在匯入數據流中取得 ADDS 更新。 因為ADCA沒有足夠的許可權可讀取物件，因此會發生此錯誤。
• 當您從 ADCS 匯出至 ADDS 時，缺少許可權會產生「許可權問題」導出錯誤。

若要檢查許可權，請開啟AD物件的 [屬性] 視窗，選取 [安全性>進階]，然後選取 [停用繼承] 按鈕來檢查對象的允許/拒絕 ACL（如果已啟用繼承）。 您可以依 類型 排序數據行內容，以找出所有「拒絕」許可權。 AD 許可權可能會有很大的差異。 不過，根據預設，您可能只會看到一個「Exchange 受信任子系統」的「拒絕 ACL」。大部分的許可權都會標示為 [允許]。

下列預設權限最相關：

• 已驗證的使用者

  

• 每個人

  

• 自訂ADCA或 MSOL 帳戶

  

• Pre-Windows 2000 Compatible Access

  

• SELF

  

疑難解答許可權的最佳方式是在AD使用者和計算機控制台中使用「有效存取」功能。 此功能會檢查您想要疑難解答之目標物件或屬性上指定帳戶的有效許可權（ADCA）。

重要

針對AD許可權進行疑難解答可能很棘手，因為 ACL 中的變更不會立即生效。 請務必考慮這類變更受限於AD複寫。

例如：

• 請確定您直接對最接近的域控制器進行必要的變更（請參閱<與 AD 的連線>一節）：
• 等候 ADDS 複寫發生。
• 可能的話，請重新啟動ADSync服務以清除快取。

疑難解答摘要

• 識別使用哪一個域控制器。
• 使用慣用的域控制器，以相同的域控制器為目標。
• 正確識別ADCA。
• 使用設定 AD DS 連接器帳戶許可權 工具。
• 在 AD 使用者和電腦中使用「有效存取」功能。
• 使用LDP工具來系結至具有ADCA的域控制器，並嘗試讀取失敗的物件或屬性。
• 暫時將ADCA新增至企業系統管理員或網域系統管理員，然後重新啟動ADSync服務。

重要事項： 請勿將此作為解決方案。

• 驗證許可權問題之後，請從任何高許可權群組移除 ADCA，並將必要的 AD 許可權直接提供給 ADCA。
• 請洽詢目錄服務或網路支援小組，以協助您針對情況進行疑難解答。

AD 複寫

此問題較不可能會影響 Microsoft Entra Connect，因為它會造成更大的問題。 不過，當Microsoft Entra Connect 使用延遲復寫從域控制器匯入數據時，它不會從 AD 匯入最新資訊，這會導致最近在 AD 中建立或變更的對象或屬性不會同步處理到 Microsoft Entra ID，因為它未復寫到Microsoft Entra Connect 所連絡的域控制器。 若要確認這是問題，請檢查 AADC 用於匯入的域控制器（請參閱「連線至 AD」），並使用 AD 使用者和電腦 控制台直接連線到這部伺服器（請參閱 下一個映射中的變更域控制器 ）。 然後，確認此伺服器上的數據對應至最新的數據，以及它是否與個別 ADCS 數據一致。 在這個階段，AADC 會在域控制器和網路層上產生更大的負載。

另一種方法是使用 RepAdmin 工具來檢查物件在所有域控制器上的複寫元數據、從所有域控制器取得值，以及檢查域控制器之間的復寫狀態：

• 來自所有網域控制器的屬性值：

  repadmin /showattr * "DC=contoso,DC=com" /subtree /filter:"sAMAccountName=User01" /attrs:pwdLastSet,UserPrincipalName

  

• 來自所有 DC 的物件元資料：

  repadmin /showobjmeta * "CN=username,DC=contoso,DC=com" > username-ObjMeta.txt

  

• AD 複寫摘要

  repadmin /replsummary

  

疑難解答摘要

• 識別使用哪一個域控制器。
• 比較域控制器之間的數據。
• 分析 RepAdmin 結果。
• 請連絡目錄服務或網路支援小組，以協助針對問題進行疑難解答。

網域和 OU 變更，以及在 ADDS 連接器中篩選或排除的物件類型或屬性

• 變更網域或 OU 篩選需要完整匯入

  請記住，即使已確認網域或 OU 篩選，網域或 OU 篩選的任何變更只有在執行完整匯入步驟之後才會生效。

• 使用 Microsoft Entra 應用程式和屬性篩選的屬性篩選

  未同步處理之屬性的易失案例是，Microsoft Entra Connect 設定 了 Microsoft Entra 應用程式和屬性篩選 功能。 若要檢查功能是否已啟用，以及針對哪些屬性，請取得一 般診斷報告。

• ADDS 連接器組態中排除的物件類型

  這種情況通常不會像使用者和群組一樣發生。 不過，如果 ADCS 中遺漏特定物件類型的所有物件，檢查 ADDS Connector 組態中啟用的物件類型可能會很有用。

  您可以使用 Get-ADSyncConnector Cmdlet 來擷取連接器上啟用的物件類型，如下圖所示。 以下是預設應啟用的物件類型：

  (Get-ADSyncConnector | where Name -eq "Contoso.com").ObjectInclusionList

  以下是預設應啟用的物件類型：

  

  注意

  只有在啟用 [郵件啟用公用資料夾] 功能時，才會顯示 publicFolder 物件類型。

• ADCS 中排除的屬性

  同樣地，如果所有物件缺少 屬性，請檢查是否已在 AD 連接器上選取屬性。

  若要檢查 ADDS 連接器中已啟用的屬性，請使用 Synchronization Manager，如下圖所示，或執行下列 PowerShell Cmdlet：

  (Get-ADSyncConnector | where Name -eq "Contoso.com").AttributeInclusionList

  

  注意

  不支援在 Synchronization Service Manager 中包含或排除物件類型或屬性。

疑難解答摘要

• 檢查Microsoft Entra 應用程式和屬性篩選功能
• 確認物件類型已包含在 ADCS 中。
• 確認屬性已包含在 ADCS 中。
• 執行完整匯入。

步驟 1 的資源

主要資源：

• Get-ADSyncConnectorAccount - 識別 AADC 所使用的正確連接器帳戶

• ADConnectivityTool

• 識別 ADDS 的連線問題

• Trace-ADSyncToolsADImport （ADSyncTools） - 從 ADDS 匯入的追蹤數據

• LDIFDE - 從 ADDS 傾印物件，以比較 ADDS 與 ADCS 之間的數據

• LDP - 測試 AD 系結連線能力，以及讀取 ADCA 安全性內容中對象的許可權

• DSACLS - 比較和評估 ADDS 許可權

• Set-ADSync< 功能 >許可權 - 在 ADDS 中套用預設的 AADC 許可權

• RepAdmin - 檢查 AD 物件元數據和 AD 複寫狀態

步驟 2：ADCS 與 MV 之間的同步處理

步驟 2 的目標

此步驟會檢查物件或屬性是否從 CS 流向 MV（換句話說，對象或屬性是否投影至 MV）。 在這個階段中，請確定物件存在，或 ADCS 中屬性正確無誤（如步驟 1 中所述），然後開始查看物件的同步處理規則和譜系。

步驟 2 的描述

ADCS 與MV之間的同步處理會在差異/完整同步處理步驟上發生。 此時，AADC 會讀取 ADCS 中的分段數據、處理所有同步處理規則，以及更新個別的MV物件。 此MV物件將包含指向 CS 物件，指向其屬性的 CS 物件，以及同步處理步驟中套用的同步處理規則譜系。 在這個階段中，AADC 會在 SQL Server （或 LocalDB） 和網路層上產生更多負載。

針對物件的 ADCS > MV 進行疑難解答

• 檢查輸入同步處理規則以進行布建

  在 ADCS 中存在但MV中遺漏的物件，表示套用至該物件的任何佈建同步處理規則沒有任何範圍篩選。 因此，物件不會投影到MV。 如果已停用或自定義同步處理規則，可能會發生此問題。

  若要取得輸入布建同步規則的清單，請執行下列命令：

  Get-ADSyncRule | where {$_.Name -like "In From AD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

  

• 檢查 ADCS 物件的譜系

  您可以在 “Search Connector Space” 中搜尋 “DN 或 Anchor”，以從 ADCS 擷取失敗的物件。在 [ 譜系] 索引標籤上，您可能會看到物件是 Disconnector （沒有 MV 的連結），而且譜系是空的。 此外，請檢查物件是否有任何錯誤，以防有同步錯誤索引標籤。

  

• 在 ADCS 物件上執行預覽

  選取 [預覽>產生預覽認可預覽>] 以查看物件是否投影至 MV。 如果是這種情況，則完整同步處理週期應該修正相同情況下其他對象的問題。

  

  

• 將物件匯出至 XML

  如需更詳細的分析（或離線分析），您可以使用 Export-ADSyncObject Cmdlet 收集與物件相關的所有資料庫數據。 這個導出的資訊將有助於判斷哪一個規則正在篩選出物件。 換句話說，布建同步處理規則中的輸入範圍篩選可防止將物件投影到MV。

  以下是 Export-ADsyncObject 語法的一些範例：

  • Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
  • Export-ADsyncObject -DistinguishedName 'CN=TestUser,OU=Sync,DC=Domain,DC=Contoso,DC=com' -ConnectorName 'Domain.Contoso.com'
  • Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose

疑難解答摘要 （物件）

• 檢查「從 AD」輸入布建規則的範圍篩選。
• 建立物件的預覽。
• 執行完整同步處理週期。
• 使用 Export-ADSyncObject 腳本匯出對象數據。

針對屬性的 ADCS > MV 進行疑難解答

1. 識別屬性的輸入同步處理規則和轉換規則

   每個屬性都有自己的一組轉換規則，負責將值從ADCS導向MV。 第一個步驟是識別哪些同步處理規則包含您要疑難解答之屬性的轉換規則。

   識別哪些同步處理規則具有指定屬性轉換規則的最佳方式，是使用同步處理規則編輯器的內建篩選功能。

   

2. 檢查 ADCS 物件的譜系

   CS 與 MV 之間的每個連接器（或連結）都會有一個譜系，其中包含套用至該 CS 物件的同步處理規則相關信息。 上一個步驟會告訴您哪一組輸入同步處理規則（無論是布建或聯結同步處理規則）必須存在於物件的譜系中，才能將正確的值從 ADCS 流向 MV。 藉由檢查 ADCS 物件的譜系，您將能夠判斷該同步處理規則是否已套用至物件。

   

   如果有多個連接器（多個 AD 樹系）連結到MV物件，您可能必須檢查 Metaverse 物件屬性 ，以判斷哪一個連接器將屬性值貢獻至您嘗試疑難解答的屬性。 識別連接器之後，請檢查該 ADCS 物件的譜系。

   

3. 檢查輸入同步處理規則的範圍篩選

   如果同步處理規則已啟用，但不存在於物件的譜系中，則應該由同步規則的範圍篩選篩選來篩選物件。 藉由檢查同步處理規則的範圍篩選、ADCS 對象上的數據，以及同步處理規則是否已啟用或停用，您應該能夠判斷同步處理規則為何未套用至 ADCS 物件。

   以下是負責同步處理 Exchange 屬性之同步處理規則中常見的麻煩範圍篩選範例。 如果物件具有 mailNickName 的 Null 值，則轉換規則中的 Exchange 屬性都不會流向Microsoft Entra ID。

   

4. 在 ADCS 物件上執行預覽

   如果您無法判斷 ADCS 物件譜系中遺漏同步處理規則的原因，請使用產生預覽和認可預覽來執行預覽，以取得物件的完整同步處理。 如果屬性在MV中更新並具有預覽，則完整同步處理週期應該修正相同情況下其他對象的問題。

5. 將物件匯出至 XML

   如需更詳細的分析或離線分析，您可以使用 Export-ADSyncObject 腳本收集與物件相關的所有資料庫數據。 這個導出的信息可協助您判斷對象上遺漏的同步處理規則或轉換規則，以防止屬性投影到MV（請參閱本文稍早的 Export-ADSyncObject 範例）。

疑難解答摘要 （適用於屬性）

• 識別負責將 屬性流向MV的正確同步處理規則和轉換規則。
• 檢查物件的譜系。
• 檢查同步處理規則是否已啟用。
• 檢查物件譜系中遺漏之同步規則的範圍篩選。

同步規則管線的進階疑難解答

如果您需要在同步處理規則方面進一步偵錯 ADSync 引擎（也稱為 MiiServer），您可以在 .config 檔案上啟用 ETW 追蹤（C：\Program Files\Microsoft Azure AD 同步\Bin\miiserver.exe.config）。 此方法會產生廣泛的詳細資訊文本檔，以顯示同步處理規則的所有處理。 不過，可能很難解譯所有資訊。 使用此方法作為最後手段，或如果以 Microsoft 支援服務 表示。

步驟 2 的資源

• Synchronization Service Manager UI
• 同步規則編輯器
• Export-ADsyncObject 腳本
• Start-ADSyncSyncCycle -PolicyType Initial
• ETW 追踪 SyncRulesPipeline （miiserver.exe.config）

步驟 3：MV 與 AADCS 之間的同步處理

步驟 3 的目標

此步驟會檢查物件或屬性是否從MV流向AADCS。 此時，請確定物件存在，或屬性在 ADCS 和 MV 中正確無誤（步驟 1 和 2 涵蓋）。 然後，檢查物件的同步處理規則和歷程。 此步驟類似於 步驟 2，其中會檢查從 ADCS 到 MV 的輸入方向，不過，在這個階段，我們將專注於從 MV 流向 AADCS 的輸出同步處理規則和屬性。

步驟 3 的描述

當 AADC 讀取 MV 中的數據、處理所有同步處理規則，以及更新個別的 AADCS 物件時，MV 與 AADCS 之間的同步處理會在差異/ 完整同步步驟中發生。 此MV物件將包含 CS 連結（也稱為連接器），指向參與其屬性的 CS 物件，以及同步處理步驟中套用之同步處理規則的譜系。 此時，AADC 會在 SQL Server （或 localDB） 和網路層上產生更多負載。

針對物件的MV對AADCS進行疑難解答

1. 檢查輸出同步處理規則以進行布建

   MV 中存在但 AADCS 中遺漏的物件，表示任何套用至該物件的布建同步處理規則都沒有範圍篩選。 例如，請參閱下一個影像中顯示的「Out to Microsoft Entra ID」同步處理規則。 因此，對象並未布建在AADCS中。 如果已停用或自定義同步處理規則，就會發生此錯誤。

   若要取得輸入布建同步規則的清單，請執行下列命令：

   Get-ADSyncRule | where {$_.Name -like "Out to AAD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

   

2. 檢查 ADCS 物件的譜系

   若要從MV擷取失敗的物件，請使用 Metaverse搜尋，然後檢查連接器索引標籤。在此索引標籤上，您可以判斷MV物件是否連結至AADCS物件。 此外，檢查物件是否有任何錯誤，以防同步錯誤索引標籤存在。

   

   如果沒有 AADCS 連接器存在，物件很可能設定為 cloudFiltered=True。 您可以檢查同步處理規則是否使用 cloudFiltered 值參與的 MV 屬性，來驗證物件是否經過雲端篩選。

3. 在 AADCS 物件上執行預覽

   選取 [預覽>產生預覽認可預覽>]，以判斷物件是否連接到AADCS。 如果是，則完整同步處理周期應該會修正相同情況下其他對象的問題。

4. 將物件匯出至 XML

   如需更詳細的分析或離線分析，您可以使用 Export-ADSyncObject 腳本收集與物件相關的所有資料庫數據。 這個導出的資訊以及 （輸出） 同步處理規則組態，有助於判斷哪一個規則正在篩選出物件，而且可以判斷布建同步處理規則中的哪個輸出範圍篩選條件會防止物件與 AADCS 連線。

   以下是 Export-ADsyncObject 語法的一些範例：

   • Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
   • Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose
   • Export-ADsyncObject -DistinguishedName 'CN={2B4B574735713744676B53504C39424D4C72785247513D3D}' -ConnectorName 'Contoso.onmicrosoft.com - AAD'

物件的疑難解答摘要

• 檢查「輸出到Microsoft專案標識碼」輸出布建規則的範圍篩選。
• 建立物件的預覽。
• 執行完整同步處理週期。
• 使用 Export-ADSyncObject 腳本匯出對象數據。

針對屬性對 AADCS 的 MV 進行疑難解答

1. 識別屬性的輸出同步處理規則和轉換規則

   每個屬性都有自己的一組轉換規則，負責將值從MV流向AADCS。 首先，識別哪些同步處理規則包含您要疑難解答之屬性的轉換規則。

   識別哪些同步處理規則具有指定屬性轉換規則的最佳方式，是使用同步處理規則編輯器的內建篩選功能。

   

2. 檢查 ADCS 物件的譜系

   CS 與 MV 之間的每個連接器（或連結）都會有一個譜系，其中包含套用至該 CS 物件的同步處理規則相關信息。 上一個步驟會告訴您哪一組輸出同步處理規則（無論是布建或聯結同步處理規則）必須存在於物件的譜系中，才能將正確的值從MV流向AADCS。 藉由檢查 AADCS 物件的譜系，您可以判斷同步處理規則是否已套用至物件。

   

3. 檢查輸出同步處理規則的範圍篩選

   如果同步處理規則已啟用，但未出現在物件的譜系中，則應該由同步規則的範圍篩選篩選來篩選。 藉由檢查同步規則的範圍篩選是否存在，以及MV對象上的數據，以及同步處理規則是否已啟用或停用，您應該能夠判斷同步處理規則為何未套用至AADCS物件。

4. 在 AADCS 物件上執行預覽

   如果您判斷 ADCS 物件的譜系遺漏同步處理規則的原因，請執行預覽，以使用 產生預覽 和 認可預覽 來完整同步處理物件。 如果屬性在MV中更新為預覽，則完整同步處理週期應該修正相同情況中的其他對象問題。

5. 將物件匯出至 XML

   如需更詳細的分析或離線分析，您可以使用 「Export-ADSyncObject」 腳本收集與物件相關的所有資料庫數據。 這個導出的資訊以及 （輸出） 同步處理規則組態，可協助您判斷物件缺少哪些同步處理規則或轉換規則，以防止屬性流向 AADCS（請參閱先前的「Export-ADSyncObject」範例）。

屬性的疑難解答摘要

• 識別負責將 屬性流向 AADCS 的正確同步處理規則和轉換規則。
• 檢查物件的譜系。
• 檢查同步處理規則是否已啟用。
• 檢查物件譜系中遺漏之同步規則的範圍篩選。

針對同步規則管線進行疑難解答

如果您需要在同步處理規則方面進一步偵錯 ADSync 引擎（也稱為 MiiServer），您可以在 .config 檔案上啟用 ETW 追蹤（C：\Program Files\Microsoft Azure AD 同步\Bin\miiserver.exe.config）。 此方法會產生廣泛的詳細資訊文本檔，以顯示同步處理規則的所有處理。 不過，可能很難解譯所有資訊。 只使用此方法做為最後手段，或如果方法以 Microsoft 支援服務 表示。

資源

• Synchronization Service Manager UI
• 同步規則編輯器
• Export-ADsyncObject 腳本
• Start-ADSyncSyncCycle -PolicyType Initial
• ETW 追踪 SyncRulesPipeline （miiserver.exe.config）

步驟 4：AADCS 與 AzureAD 之間的同步處理

步驟 4 的目標

此階段會比較 AADCS 物件與Microsoft Entra 標識碼中布建的個別物件。

步驟 4 的描述

涉及將數據匯入和匯出至 Microsoft Entra ID 的多個元件和程式，可能會導致下列問題：

• 線上到因特網
• 內部防火牆和 ISP 連線能力（例如封鎖的網路流量）
• DirSync Webservice 前面Microsoft Entra 網關（也稱為 AdminWebService 端點）
• The DirSync Webservice API
• Microsoft Entra Core 目錄服務

幸運的是，影響這些元件的問題通常會在事件記錄檔中產生錯誤，而事件記錄檔可由 Microsoft 支援服務 追蹤。 因此，這些問題不屬於本文的範圍。 然而，仍有一些可以檢查的“無訊息”問題。

針對 AADCS 進行疑難解答

• 匯出至 Microsoft Entra 識別碼的多個作用中 AADC 伺服器

  在Microsoft Entra ID 中的物件來回翻轉屬性值的常見案例中，有一部以上的使用中Microsoft Entra Connect 伺服器，其中一部伺服器會失去與本機 AD 的連絡，但仍會連線到因特網，並且能夠將數據導出至 Microsoft Entra ID。 因此，每當這個「過時」伺服器從Microsoft Entra ID 匯入另一個作用中伺服器所建立之同步物件上的變更時，同步處理引擎就會根據 ADCS 中的過時 AD 數據還原該變更。 此案例中的一般徵兆是您在 AD 中進行變更，該變更會同步至 Microsoft Entra ID，但變更會還原為幾分鐘后的原始值（最多 30 分鐘）。 若要快速減輕此問題，請返回任何已解除委任的舊伺服器或虛擬機，並檢查 ADSync 服務是否仍在執行中。

• 使用 DirSyncOverrides 的行動屬性

  當系統管理員使用 MSOnline 或 AzureAD PowerShell 模組，或使用者移至 Office 入口網站並更新 Mobile 屬性時，即使物件是從內部部署 AD 同步處理，仍會在 AzureAD 中覆寫更新的電話號碼（也稱為 DirSyncEnabled）。

  加上此更新，Microsoft Entra ID 也會在 對象上設定 DirSyncOverrides ，以標幟此使用者Microsoft Entra ID 中有行動電話號碼「覆寫」。 從此開始，將會忽略源自內部部署的行動屬性的任何更新，因為此屬性將不再由內部部署AD管理。

  如需 BypassDirSyncOverrides 功能的詳細資訊，以及如何將 Mobile 和其他Mobile 屬性的同步處理從 Microsoft Entra ID 還原至 內部部署的 Active Directory，請參閱如何使用 Microsoft Entra 租使用者的 BypassDirSyncOverrides 功能。

• UserPrincipalName 變更不會在 entra 標識符Microsoft更新

  如果在 Microsoft Entra ID 中未更新 UserPrincipalName 屬性，而其他屬性會如預期般同步處理，則租使用者上可能未啟用名為 SynchronizeUpnForManagedUsers 的功能。 這種情況經常發生。

  新增此功能之前，在使用者布建 Microsoft在 entra ID 中布建使用者並指派授權之後，來自內部部署的 UPN 的任何更新會「以無訊息方式」忽略。 系統管理員必須使用 MSOnline 或 Azure AD PowerShell，直接在 Microsoft Entra 識別碼中更新 UPN。 更新此功能之後，不論使用者是否獲得授權，UPN 的任何更新都會流向 Microsoft Entra。

  注意

  啟用此功能之後，就無法停用此功能。

  如果使用者未獲得授權，UserPrincipalName 更新將會運作。 不過，如果沒有 SynchronizeUpnForManagedUsers 功能， UserPrincipalName 會在布建用戶之後變更，並獲指派授權，該授權不會在 Microsoft Entra ID 中更新。 請注意，Microsoft不會代表客戶停用此功能。

• 無效的字元和 ProxyCalc 內部

  由於 ProxyCalc 處理中的串連效果，導致不產生任何同步處理錯誤的無效字元，在 UserPrincipalName 和 ProxyAddresses 屬性中比較麻煩。因為 ProxyCalc 處理中的串聯效果會以無訊息方式捨棄從內部部署 AD 同步處理的值。 這種情況會發生如下：

  1. Microsoft Entra ID 中產生的 UserPrincipalName 將會是 MailNickName 或 CommonName @ （at） 初始網域。 例如，John.Smith@Contoso.comMicrosoft Entra ID 中的 UserPrincipalName 可能會變成 smithj@Contoso.onmicrosoft.com ，因為 UPN 值中有來自內部部署 AD 的隱藏字元。

  2. 如果 ProxyAddress 包含空格符，ProxyCalc 將會捨棄它，並根據初始網域的 MailNickName 自動產生電子郵件位址。 例如，“SMTP： John.Smith@Contoso.com” 不會出現在 Microsoft Entra ID 中，因為它在冒號後面包含空格符。

  3. 包含空格字元的UserPrincipalName或包含不可見字元的 ProxyAddress 會導致相同的問題。

     若要針對 UserPrincipalName 或 ProxyAddress 中的無效字元進行疑難解答，請檢查從從 LDIFDE 或 PowerShell 導出至檔案的本機 AD 中儲存的值。 偵測不可見字元的一個簡單訣竅是複製匯出檔案的內容，然後將它貼到PowerShell視窗中。 不可見字元會取代為問號 （？），如下列範例所示。

     

• ThumbnailPhoto 属性 （KB4518417）

  有一般誤解，當您第一次從 AD 同步 ThumbnailPhoto 之後，您就無法再更新它，這隻是部分事實。

  通常， Microsoft Entra 標識符中的 ThumbnailPhoto 會持續更新。 不過，如果已更新的圖片不再由個別工作負載或合作夥伴從Microsoft Entra標識符擷取，就會發生問題（例如EXO或 SfBO）。 此問題會造成圖片未從內部部署 AD 同步至 Microsoft Entra ID 的錯誤印象。

  疑難解答 ThumbnailPhoto 的基本步驟

  1. 請確定映像已正確儲存在AD中，而且不會超過大小限制100 KB。

  2. 檢查帳戶入口網站中的影像，或使用 Get-AzureADUserThumbnailPhoto ，因為這些方法會直接從 Microsoft Entra ID 讀取 ThumbnailPhoto 。

  3. 如果 AD （或 AzureAD） thumbnailPhoto 具有正確的影像，但在其他 線上服務 上則不正確，可能會套用下列條件：

  • 使用者的信箱包含 HD 映射，且不接受來自 entra thumbnailPhoto Microsoft低解析度影像。 解決方案是直接更新使用者的信箱映像。
  • 使用者的信箱映射已正確更新，但您仍然看到原始影像。 解決方案是等待至少六個小時，才能在 Office 365 使用者入口網站或 Azure 入口網站 中看到更新的映射。

其他資源

• 針對同步處理期間的錯誤進行疑難排解
• 針對使用 Microsoft Entra Connect 同步所執行的物件同步處理進行疑難排解
• 針對未 Microsoft 與 entra 識別符同步處理的物件進行疑難解答
• Microsoft Entra Connect 單一物件同步處理

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。 您也可以向 Azure 意見反應社群提交產品意見反應。