為什麼 ADMT 會視「使用者」不是 leaf object？

在 Active Directory 中，理論上 user、computer 及 group 都屬於 leaf object；但如果該物件底下被某些應用程式建立了「子物件」，它就不再是 leaf，ADMT 在嘗試搬移 (Move) 時會被目錄服務阻擋而拋出 0x8007208c 錯誤。
最常見的子物件來源：

• Exchange ActiveSync 裝置記錄：CN=ExchangeActiveSyncDevices (屬性類型 msExchActiveSyncDevices)
• Terminal Services 授權快取：CN=TermSrvLicensing
• Microsoft Dynamics GP、Citrix SSOSecret／SSOConfig 等軟體所建立的保護或加密資訊物件

可能場景

• 使用者曾在手機或平板設定 行動版 Outlook／原生郵件 App，Exchange 伺服器會在該帳號下建置 ExchangeActiveSyncDevices 子物件。
• 伺服器/VDI 用戶開啟 RDS 授權功能，於帳號下產生 TermSrvLicensing 子物件。
• 部署第三方安全或 SSO 產品，於帳號節點下寫入其專屬設定子物件。

解決方式

Microsoft 的官方建議相當直接：
必須先刪除子物件再行遷移，否則沒有已知替代方案。

具體執行步驟（以 Exchange ActiveSync 為例）：

1. 於來源網域 DC 上開啟 ADSI Edit → Default Naming Context。
2. 展開問題帳號，確認存在 CN=ExchangeActiveSyncDevices 子容器。
3. 右鍵刪除該容器；若其下仍有裝置節點，需一併刪除。
4. 執行 repadmin /syncall /APed 促使複寫。
5. 重跑 ADMT 遷移精靈，即可成功搬移帳號。

影響評估

ExchangeActiveSyncDevices 只存放已註冊行動裝置資訊，刪除後 不會影響信箱內容；使用者僅需在手機重新配對郵件帳號。

其他應用程式（如 Citrix SSO）則必須依廠商文件評估是否會失去儲存的密鑰或授權設定。

預防建議

在 正式遷移前，先用 ADMT「分析」模式或撰寫腳本掃描目錄，找出含子物件的帳號並提前清理。

若大量使用 Exchange ActiveSync，可考慮在遷移後批次推送行動裝置設定檔，降低使用者重新設定的負擔。

對第三方應用進行 AD 架構稽核，確定其是否會在使用者節點下建立子物件，並洽廠商取得安全清除或匯出/匯入流程。