Identify the issue section

Pavel Yurenev · Pavel Yurenev · commit 5fec5fc35e5b · 2026-01-12T13:33:20.000Z
diff --git a/support/mem/configmgr/discovery/ad-group-not-discovered.md b/support/mem/configmgr/discovery/ad-group-not-discovered.md
@@ -1,7 +1,7 @@
 ---
 title: Delta AD Group Discovery skips the membership discovery for a group scope in child OU of other group scope
 description: Troubleshoot an issue when AD Delta Discovery fails to detect group membership change.
-ms.date: 01/06/2026
+ms.date: 01/12/2026
 ms.reviewer: kaushika, jarrettr, brianhun, payur
 ms.custom: sap:Boundary Groups, Discovery and Collections\Active Directory Discovery (all types)
 ---
@@ -17,120 +17,64 @@ You set up an Active Directory Group Discovery to target specific AD Groups as d
 
 You notice that AD Group Delta Discovery fails to catch the changes in certain group membership. At the same time, forcing a Full Discovery cycle resolves the issue.
 
-In particular, this happens when the following conditions are met:
+In particular, the issue happens when the following conditions are met:
 
 - Scope A: Group A located in organizational unit OU-A
 - Scope B: Group B located in organizational unit OU-B
-- OU-B is located under OU-A (being, then, a child OU)
+- OU-B is located under OU-A (being, hence, a child OU)
 
-If all above conditions are met, changes in Group B's membership are not detected by AD Group Delta Discovery.
+If all above conditions are met, changes in Group B's membership aren't detected by AD Group Delta Discovery.
 
 ## Cause
 
 During AD Group Delta Discovery, Configuration Manager detects the organizational units (OUs) of the target groups in discovery scopes and builds a tree structure of OUs. It ignores the child OUs of the target groups' OUs.
 
-## Resolution
-
-This issue is fixed in [Configuration Manager current branch, version 2203](/mem/configmgr/core/plan-design/changes/whats-new-in-version-2203).
-
-If the issue still occurs after upgrading to version 2203 and later versions, make sure that you meet the requirements for establishing the Kerberos connection from the site server to the domain controllers of the target domain. For example:
+AD Group Full Discovery follows different algorithm that doesn't ignore child OUs, so it works as expected.
 
-- TCP traffic on port 88 (Kerberos) is allowed.
-- TCP and UDP traffic on port 389 (LDAP and CLDAP) is allowed.
-- The site server can resolve service location (SRV) records for Kerberos services. For example:
-
-    ```output
-    _kerberos._tcp.contoso.com
-    _kerberos._udp.contoso.com
-    _kerberos._tcp.dc._msdcs.contoso.com
-    ```
-
-## Workaround
+## Resolution
 
-To work around this issue, change collection rules to include both the NetBIOS domain name and the DNS domain name. For example:
+Microsoft is aware of this issue, however as per January 2026 there's no ETA or even commitment to fix it. To work around this issue, you can either:
 
-`select * from SMS_R_System where SMS_R_System.SystemGroupName in ("AAA\\Group1","BBB\\Group1")`
+- Move the Group B to another OU that isn't a child of OU-A (or any other OU in the discovery scopes).
+- Include OU-B in the discovery scopes as Organizational Unit.
+- Fall back to Full AD Group Discovery.
 
 ## Identify the issue
 
 Here are the steps to check logs and identify the issue:
 
-1. Increase the size of the _ADSgDis.log_ file to 100 megabytes (MB) or more to accommodate a full Active Directory group discovery. Under the following registry key, change the `MaxFileSize` registry value to `104857600` (the default value is `2621440`).
-
-   `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT`
-
-1. Enable verbose logging for the _ADSgDis.log_ file. Under the following registry key, change the `Verbose Logs` registry value to `1` (the default value is `0`).
-
-   `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT`
-
-1. Run a full Active Directory group discovery and make sure the following message is logged in the _ADSgDis.log_ file upon completion.
-
-   `INFO: Succeeded running full sync stored procedure`
-
-1. Filter by the thread ID that logged the above message and find the following message in the filtered logs.
-
-   `VERBOSE : Could not get Domain Name using DSCrackNames, will parse ADs Path to get it`
-
-1. Check the following lines around. You'll find a group and its member are from different domains.
-
-   ```output
-   INFO: DDR was written for group 'contoso\ParentGroup' - C:\ConfigMgr\inboxes\auth\ddm.box\userddrsonly\asg1607o.DDR at <Date Time>.~ 
-   VERBOSE: group has 1 members~
-   ...
-   VERBOSE: Domain controller name for the SID is: \\DC.fourthcoffee.local
-   VERBOSE: full ADs path of member: LDAP://DC.fourthcoffee.local/CN=ChildGroup,CN=Users,DC=fourthcoffee,DC=local~
-   ...
-   VERBOSE: Could not get Domain Name using DSCrackNames, will parse ADs Path to get it
-   VERBOSE: ParentGroup: "contoso\ParentGroup" ChildGroup: "fourthcoffee\ChildGroup"
-   ```
-
-1. Check the Windows system event logs of the time-correlated event ID 40970 as follows. You'll find the domain controller of the Service Principal Name (SPN) and the realm are from different domains. This event may not occur if the Kerberos authentication attempt is cached.
-
-   ```output
-   The Security System has detected a downgrade attempt when contacting the 3-part SPN LDAP/DC.contoso.local/fourthcoffee.LOCAL
-   with error code "The SAM database on the Windows Server does not have a computer account for this workstation trust relationship. (0xc000018b)".
-   Authentication was denied.
-   ```
-
-1. If so, you've identified the issue successfully.
-
-## Additional information
-
-This issue can also occur if the **Discover objects within Active Directory groups** option is enabled in System or User Discovery scope settings. In this case, here are the steps to check logs and identify the issue. You can also temporarily disable the option for the discovery scopes in which you have groups with members from other domains.
-
-1. Increase the size of the _ADSysDis.log_ or _ADUsrDis.log_ file to 100 megabytes (MB) or more to accommodate a full Active Directory system or user discovery. Under one of the following registry keys, change the `MaxFileSize` registry value to `104857600` (the default value is `2621440`).
-
-   - `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_AD_SYSTEM_DISCOVERY_AGENT`
-
-   - `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Tracing\SMS_AD_USER_DISCOVERY_AGENT`
-
-1. Enable verbose logging for the _ADSysDis.log_ or _ADUsrDis.log_ file. Under one of the following registry keys, change the `Verbose Logs` registry value to `1` (the default value is `0`).
+1. Create the list of scopes by checking the beginning of any discovery cycle in ADSGDis.log. Verify the LDAP Paths: in particular, validate that the affected group is in child OU of another one in the list.
 
-   - `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_AD_SYSTEM_DISCOVERY_AGENT`
+```output
+!!!!Valid Search Scope Name: Unaffected Group     Search Path: LDAP://CN=GROUP-A,OU=OU-A,DC=FOURTHCOFFEE,DC=COM     IsValidPath: TRUE
+!!!!Valid Search Scope Name: Affected Group     Search Path: LDAP://CN=GROUP-B,OU=OU-B,OU=OU-A,DC=FOURTHCOFFEE,DC=COM     IsValidPath: TRUE
+```
 
-   - `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\COMPONENTS\SMS_AD_USER_DISCOVERY_AGENT`
+1. Find any Delta Discovery cycle in the log. Look for the following line and filter by the thread writing it.
 
-1. Run a full Active Directory system or user discovery and make sure the following message is logged in the _ADSysDis.log_ or _ADUsrDis.log_ file upon completion.
+```output
+INFO: CADSource::incrementalSync returning 0x00000000~
+```
 
-   `INFO: CADSource::fullSync returning 0x00000000~`
+1. First, Delta Discovery goes through the list of scopes:
 
-1. Filter by the thread ID that logged the above message and find the following message in the filtered logs.
+```output
+INFO: -------- Starting to process search scope (Unaffected Group) --------
+INFO: -------- Finished to process search scope (Unaffected Group) --------
+INFO: -------- Starting to process search scope (Affected Group) --------
+INFO: -------- Finished to process search scope (Affected Group) --------
+```
 
-   `VERBOSE : Could not get Domain Name using DSCrackNames, will parse ADs Path to get it`
+1. The Delta Discovery proceeds to "immediate search base" then:
 
-1. Check the following lines around. You'll find a group and its member are from different domains.
+```output
+INFO: -------- Starting to process search scope (Immediate search base) --------
+INFO: Processing search path: 'LDAP://OU=OU-A,DC=FOURTHCOFFEE,DC=COM'.~
+```
 
-   ```output
-   INFO: Processing discovered group object with ADsPath = 'LDAP://DC1.CONTOSO.COM/CN=GROUP1,OU=OU,DC=CONTOSO,DC=COM'~
-   VERBOSE: group not found in discovered group list~
-   VERBOSE: Bound to group.~
-   VERBOSE: group has 3 members~
-   ...
-   VERBOSE: full ADs path of member: LDAP://DC2.fourthcoffee.com/CN=Machine1,OU=US,DC=fourthcoffee,DC=com~
-   ...
-   VERBOSE: Could not get Domain Name using DsCrackNames, will parse ADs Path to get it
-   VERBOSE: domain = 'FourthCoffee' full domain name = 'fourthcoffee.com'
-   INFO: DDR was written for system 'Machine1' - C:\ConfigMgr\inboxes\auth\ddm.box\adsqznjr.DDR at <Date Time>.~
-   ```
+1. If you see this error message for the OU-B, you successfully identified the issue:
 
-1. If so, you've identified the issue successfully.
+```output
+INFO: Found invalid Search Path: LDAP://OU=OU-B,OU=OU-A,DC=FOURTHCOFFEE,DC=COM. Probably it's sub search path of other search path and will be covered by them.
+INFO: -------- Finished to process search scope (Immediate search base) --------
+```
