共用方式為

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

  • 發行項

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

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

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

Microsoft Entra 連線流程圖的螢幕快照。

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

必要條件

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

錯誤的疑難解答做法

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) 互動。 如需常見的移轉問題，請參閱 移轉常見問題。 注意： 1.0.x 版的 MSOnline 可能會在 2024 年 6 月 30 日之後中斷。

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

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

  • 您正在解除委任內部部署同步處理伺服器，而且想要繼續完全從雲端管理身分識別，而不是從混合式身分識別管理身分識別。
  • 租使用者中有一些同步物件，您想要在 Microsoft Entra ID 中保留為僅限雲端，並從內部部署 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 連接器空間中的屬性 『A' Microsoft Entra
Acl 存取控制 清單 (也稱為ADDS許可權)
ADCA AD 連接器帳戶
Adc 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。

A D 連接器空間 A D 複寫的螢幕快照。

步驟 1 的描述

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

[A A D C 連線選項] 對話框的螢幕快照。

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

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

針對 Active Directory 進行疑難解答

與 AD 的連線能力

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

此螢幕快照顯示 [從 D 匯入] 步驟中的 [連線狀態] 區域。

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

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

  • 無效的 AD 認證。 例如，ADCA 已過期或密碼已變更。
  • 當 DirSync 控件未與 AD 複寫服務通訊時，會發生「搜尋失敗」錯誤，通常是因為高網路封包片段。
  • “no-start-ma” 錯誤，發生於 AD 中 DNS) (名稱解析問題時。
  • 其他可能由名稱解析問題、網路路由問題、封鎖的網路埠、高網路封包片段、沒有可寫入的 DC 等等所造成的問題。 在這種情況下，您可能必須與目錄服務或網路支援小組合作，以協助進行疑難解答。

疑難解答摘要

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

執行同步處理疑難解答員

針對 AD 連線能力進行疑難解答之後，請執行 疑難解答物件同步處理 工具，因為這可以單獨偵測對象或屬性未同步處理的最明顯原因。

Microsoft Entra 連線疑難解答畫面的螢幕快照。

AD 許可權

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

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

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

下列預設權限是最相關的：

  • 已驗證的使用者

    顯示已驗證用戶的螢幕快照。

  • 所有人

    顯示 [允許] 選項設定為 [所有人] 的螢幕快照。

  • 自訂ADCA或 MSOL 帳戶

    顯示自定義ADCA或 MSOL 帳戶的螢幕快照。

  • Windows 2000 之前相容存取

    顯示 Windows 2000 之前相容存取的螢幕快照。

  • SELF

    顯示允許 SELF 許可權的螢幕快照。

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

螢幕快照顯示 [進階安全性設定] 視窗中 [有效存取] 索引標籤上的資訊。

重要事項

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

例如：

  • Make sure that you are making the necessary changes directly to the closest domain controller (see the "Connectivity with AD" section):
  • 等候 ADDS 複寫發生。
  • 可能的話，請重新啟動ADSync服務以清除快取。

疑難解答摘要

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

重要： 請勿使用此作為解決方案。

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

AD 複寫

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

Active Directory [變更域控制器] 選項的螢幕快照。

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

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

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

    使用 showattr 之 RepAdmin 工具的螢幕快照。

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

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

    RepAdmin 工具的螢幕快照，其中包含 showobjmeta 命令。

  • AD 複寫摘要

    repadmin /replsummary

    使用 replsummary 命令的 RepAdmin 工具螢幕快照。

疑難解答摘要

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

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

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

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

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

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

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

    對於使用者和群組而言，這種情況並不常見。 不過，如果 ADCS 中缺少特定物件類型的所有物件，則檢查在 ADDS 連接器組態中啟用的物件類型可能很有用。

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

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

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

    顯示物件類型 Get-ADSyncConnector 螢幕快照。

    注意事項

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

  • ADCS 中排除的屬性

    同樣地，如果所有對象的屬性都遺失，請檢查是否已在 AD 連接器上選取屬性。

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

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

    AD 連接器同步處理管理員的螢幕快照。

    注意事項

    不支援在同步處理 Service Manager 中包含或排除物件類型或屬性。

疑難解答摘要

步驟 1 的資源

主要資源：

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

  • ADConnectivityTool

  • 使用 ADDS 識別連線問題

  • Trace-ADSyncToolsADImport (ADSyncTools) - 從 ADDS 匯入的追蹤數據

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

  • 在ADCA的安全性內容中測試AD系結連線能力和讀取物件的許可權

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

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

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

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

顯示 A D C S 到 MetaVerse 流程圖的螢幕快照。

步驟 2 的目標

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

步驟 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

    此螢幕快照顯示 Get-ADSyncRule 命令用來檢查輸入布建規則。

  • 檢查 ADCS 物件的譜系

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

    A D C S 中連接器空間物件屬性的螢幕快照。

  • 在 ADCS 物件上執行預覽

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

    A D C S 物件預覽畫面的螢幕快照。

    D C S 中 [來源物件詳細數據] 畫面的螢幕快照。

  • 將物件匯出至 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 輸入」輸入布建規則的範圍篩選。
  • Create 對象的預覽。
  • 執行完整同步處理迴圈。
  • 使用 Export-ADSyncObject 腳本匯出對象數據。

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

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

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

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

    A D C S 中 編輯器 同步處理規則的螢幕快照。

  2. 檢查 ADCS 物件的譜系

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

    連接器空間物件屬性譜系畫面的螢幕快照。

    如果有多個連接器 (多個 AD 樹系) 連結至 MV 物件，您可能必須檢查 Metaverse 物件屬性 ，以判斷哪一個連接器正在將屬性值提供給您嘗試進行疑難解答的屬性。 識別連接器之後，請檢查該 ADCS 物件的譜系。

    Metaverse 物件屬性畫面的螢幕快照。

  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 Sync\Bin\miiserver.exe.config) 。 這個方法會產生大量詳細資訊文本檔，以顯示同步處理規則的所有處理。 不過，可能很難解譯所有資訊。 使用此方法做為最後的手段，或是 Microsoft 支援服務 指示。

步驟 2 的資源

  • 同步處理 Service Manager UI
  • 同步處理規則 編輯器
  • Export-ADsyncObject 腳本
  • Start-ADSyncSyncCycle -PolicyType Initial
  • ETW 追蹤 SyncRulesPipeline (miiserver.exe.config)

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

M V 和 A D C S 流程圖的螢幕快照。

步驟 3 的目標

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

步驟 3 的描述

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

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

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

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

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

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

    用來檢查輸出同步處理規則的 Get-ADSyncRule 螢幕快照。

  2. 檢查 ADCS 物件的譜系

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

    Metaverse 搜尋 畫面的螢幕快照。

    如果沒有 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 Entra ID」輸出布建規則的範圍篩選。
  • Create 對象的預覽。
  • 執行完整同步處理迴圈。
  • 使用 Export-ADSyncObject 腳本匯出對象數據。

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

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

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

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

    同步處理規則 編輯器 的螢幕快照。

  2. 檢查 ADCS 物件的譜系

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

    顯示 A D C S 物件上 [譜系] 索引標籤詳細數據的螢幕快照。

  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 Sync\Bin\miiserver.exe.config) 。 這個方法會產生大量詳細資訊文本檔，以顯示同步處理規則的所有處理。 不過，可能很難解譯所有資訊。 僅使用此方法做為最後的手段，或是 Microsoft 支援服務 指示。

資源

  • 同步處理 Service Manager UI
  • 同步處理規則 編輯器
  • Export-ADsyncObject 腳本
  • Start-ADSyncSyncCycle -PolicyType Initial
  • ETW 追蹤 SyncRulesPipeline (miiserver.exe.config)

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

A D C S 與 Microsoft Entra ID 之間的同步流程圖螢幕快照。

步驟 4 的目標

此階段會比較 AADCS 物件與在 Microsoft Entra ID 中布建的個別物件。

步驟 4 的描述

匯入和匯出資料的多個元件和程式 Microsoft Entra ID 可能會造成下列問題：

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

幸運的是，影響這些元件的問題通常會在事件記錄檔中產生錯誤，Microsoft 支援服務 可加以追蹤。 因此，這些問題不在本文的範圍內。 不過，仍有一些「無訊息」問題可供檢查。

針對 AADCS 進行疑難解答

  • 匯出至 Microsoft Entra ID 的多部使用中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 和其他行動屬性的同步處理從 Microsoft Entra ID 還原至 內部部署的 Active Directory 的詳細資訊，請參閱如何使用 Microsoft Entra 租使用者的 BypassDirSyncOverrides 功能。

  • UserPrincipalName 變更不會在 Microsoft Entra ID 中更新

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

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

    注意事項

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

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

  • 無效的字元和 ProxyCalc 內部

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

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

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

    3. 包含空格符 的UserPrincipalName 或包含隱藏字元的 ProxyAddress 將會導致相同的問題。

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

      此螢幕快照顯示針對 UserPrincipalName 或 ProxyAddress 進行疑難解答的範例。

  • ThumbnailPhoto 屬性 (KB4518417)

    有一般誤解，即第一次從 AD 同步 ThumbnailPhoto 之後，您就無法再更新它，這僅部分成立。

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

    ThumbnailPhoto 疑難解答的基本步驟

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

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

    3. 如果 AD (或 AzureAD) thumbnailPhoto 具有正確的映射，但在其他 線上服務 上則不正確，則可能適用下列條件：

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

其他資源

與我們連絡，以取得說明

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