Revisions from review feedback

Author: v-tappelgate

support/mem/configmgr/discovery/ad-group-not-discovered.md

@@ -11,15 +11,15 @@ appliesto:
 
 ## Summary
 
-Active Directory Group Discovery (AD Group Discovery) in Configuration Manager uses different algorithms for delta and full discovery cycles. During the delta discovery process, Configuration Manager doesn't process child organizational units (OUs). Because of this behavior, delta discovery might miss group membership changes when groups belong to nested OUs within your discovery scopes.
+Active Directory Group Discovery (AD Group Discovery) in Configuration Manager uses different algorithms for delta and full discovery cycles. During the delta discovery process, Configuration Manager might miss group membership changes when groups belong to nested OUs within your discovery scopes.
 
 This article helps you identify this issue in your environment, and provides workarounds to make sure that Configuration Manager detects all group membership changes.
 
 ## Symptoms
 
 You set up discovery scopes for AD Group Discovery to target specific Active Directory Domain Services (AD DS) groups, as described in [Configure Active Directory Group Discovery](/intune/configmgr/core/servers/deploy/configure/configure-discovery-methods#bkmk_config-adgd). The initial full discovery cycle correctly discovers groups in all the in-scope OUs.
 
-Some time after the initial full discovery cycle finishes, the delta discovery cycle runs. After the delta discovery cycle finishes, you notice that changes in particular group memberships are missed. However, if you force a full discovery cycle to run, the issue resolves as the full discovery cycle discovers changes in all groups in the in-scope OUs.
+Some time after the initial full discovery cycle finishes, you change the membership of a group that belongs to a child OU of another OU. After the delta discovery cycle runs, you notice that Configuration Manager didn't detect your changes. However, if you force a full discovery cycle to run, the issue resolves as the full discovery cycle discovers changes in all groups in the in-scope OUs.
 
 In particular, the issue occurs when you define scopes that resemble the following example:
 
@@ -33,32 +33,32 @@ If you want to review log entries to verify this behavior in your system, see [M
 
 ## Cause
 
-During the delta cycle of AD Group Discovery, Configuration Manager detects the OUs of the target groups in the discovery scopes, and then builds a tree structure of OUs. It ignores any child OUs of the OUs in the target groups.
+During the delta cycle of AD Group Discovery, Configuration Manager identifies the target groups in the discovery scopes, and the OUs to which those groups belong. It builds a tree structure of those OUs. However, that tree doesn't include any child OUs of those OUs.
 
 During the full discovery cycle of AD Group Discovery, Configuration Manager uses a different algorithm that doesn't ignore child OUs. Therefore, the discovery process works as expected.
 
 ## Workaround
 
 Microsoft is aware of this issue. To work around this issue, use any of the following methods:
 
-- Move all groups to top-level OUs. For the earlier example, this action means moving Group B to another OU that isn't a child of OU-A (or of any other OU in the discovery scopes).
+- Move the affected groups to higher-level OUs. For the earlier example, this action means moving Group B to another OU that isn't a child of OU-A (or of any other OU in the discovery scopes).
 - Reconfigure the discovery scopes to include the child OUs as target OUs. For the previous example, this action means including OU-B in the discovery scopes as an Organizational Unit.
 - Use only the full discovery process for AD Group Discovery.
 
 ## More information
 
 To see what this behavior looks like in the ADSGDis.log file, follow these steps:
 
-1. Open ADSGDis.log in a text editor, and then review the log entries to identify any discovery cycle.
+1. Open ADSGDis.log in a tool such as [CMTrace](/intune/configmgr/core/support/cmtrace), and then review the log entries to identify any discovery cycle.
 1. For that discovery cycle, create a list of the discovery scopes that appear in the log entries.
-1. Verify the LDAP path of each scope. In particular, check that the affected group is in a child OU of another one in the list. In the example that this article uses, the scopes and paths resemble the following example:
+1. Verify the Lightweight Directory Access Protocol (LDAP) path of each scope. In particular, check that the affected group is in a child OU of another one in the list. In the example that this article uses, the scopes and paths resemble the following example:
 
    ```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
    ```
 
-1. Review the log entries to identify any delta discovery cycle. Look for an entry that resembles the following example, and then use the name of the thread to filter log entries.
+1. Review the log entries to identify any delta discovery cycle. Look for an entry that resembles the following example, and then use the thread ID to filter log entries.
 
    ```output
    INFO: CADSource::incrementalSync returning 0x00000000~
@@ -75,7 +75,7 @@ To see what this behavior looks like in the ADSGDis.log file, follow these steps
       INFO: -------- Finished to process search scope (Affected Group) --------
       ```
 
-   1. Delta discovery processes the scopes themselves, starting at `immediate search base`.
+   1. Delta discovery processes the LDAP search paths, starting at `immediate search base`.
 
       ```output
       INFO: -------- Starting to process search scope (Immediate search base) --------