Partager via


La fonction Delta AD Group Discovery ne détecte pas les changements d’appartenance aux groupes dans les unités d’organisation imbriquées

Résumé

La découverte de groupes Active Directory (découverte de groupes AD) dans Configuration Manager utilise différents algorithmes pour les cycles de découverte delta et complets. Pendant le processus de découverte delta, Configuration Manager peut ne pas détecter les modifications d’appartenance au groupe lorsque des groupes appartiennent à des unités organisationnelles imbriquées dans vos étendues de découverte.

Cet article vous aide à identifier ce problème dans votre environnement et fournit des solutions de contournement pour vous assurer que Configuration Manager détecte toutes les modifications d’appartenance au groupe.

Symptômes

Vous configurez des étendues de découverte pour la découverte de groupes AD afin de cibler des groupes AD DS (Active Directory Domain Services), comme décrit dans Configurer la découverte de groupes Active Directory. Le cycle de découverte complet initial découvre correctement les groupes dans toutes les UO concernées.

Une fois le cycle initial complet de découverte terminé, vous modifiez l'appartenance d'un groupe situé dans une unité d'organisation fille d'une autre unité d'organisation. Une fois le cycle de découverte delta exécuté, vous remarquez que Configuration Manager n’a pas détecté vos modifications. Toutefois, si vous forcez l’exécution d’un cycle de découverte complet, le problème se résout puisque le cycle de découverte complet découvre les modifications de tous les groupes dans les unités d’organisation délimitées.

En particulier, le problème se produit lorsque vous définissez des étendues qui ressemblent à l’exemple suivant :

  • Étendue A : Groupe A, dans l’unité organisationnelle OU-A
  • Étendue B : Groupe B, dans l’unité organisationnelle OU-B
  • OU-B est une unité d’organisation enfant de OU-A

Dans cet exemple, le cycle delta de la découverte de groupes AD ne détecte pas les modifications apportées à l’appartenance au groupe B.

Si vous souhaitez consulter les entrées de journal pour vérifier ce comportement dans votre système, consultez Plus d’informations.

La cause

Pendant le cycle delta de la découverte de groupes AD, Configuration Manager identifie les groupes cibles dans les étendues de découverte et les unités d’organisation auxquelles appartiennent ces groupes. Il génère une arborescence de ces unités d’organisation. Toutefois, cette arborescence n’inclut aucune unité d’organisation enfant de ces unités d’organisation.

Pendant le cycle complet de découverte de groupes Active Directory, Configuration Manager utilise un algorithme différent qui ne néglige pas les unités d’organisation enfants. Par conséquent, le processus de découverte fonctionne comme prévu.

Contournement

Microsoft est conscient de ce problème. Pour contourner ce problème, utilisez l’une des méthodes suivantes :

  • Déplacez les groupes affectés vers des unités d’organisation de niveau supérieur. Pour l’exemple précédent, cette action signifie le déplacement du groupe B vers une autre unité organisationnelle qui n’est pas un enfant de OU-A (ou d’une autre unité organisationnelle dans les étendues de découverte).
  • Reconfigurez les étendues de découverte pour inclure les unités d’organisation enfants en tant qu’unités d’organisation cibles. Pour l’exemple précédent, cette action signifie inclure OU-B dans les étendues de découverte en tant qu’unité organisationnelle.
  • Utilisez uniquement le processus complet de découverte pour la découverte de groupes AD.

Plus d’informations

Pour voir à quoi ressemble ce comportement dans le fichier ADSGDis.log, procédez comme suit :

  1. Ouvrez ADSGDis.log dans un outil tel que CMTrace, puis passez en revue les entrées du journal pour identifier tout cycle de découverte.

  2. Pour ce cycle de découverte, créez une liste des champs de découverte qui apparaissent dans les entrées des journaux.

  3. Vérifiez le chemin LDAP (Lightweight Directory Access Protocol) de chaque étendue. En particulier, vérifiez que le groupe concerné se trouve dans une unité d’organisation enfant d’une autre dans la liste. Dans l’exemple que cet article utilise, les étendues et les chemins ressemblent à l’exemple suivant :

    !!!!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
    
  4. Consultez les entrées du journal pour identifier tout cycle de découverte de delta. Recherchez une entrée semblable à l’exemple suivant, puis utilisez l’ID de thread pour filtrer les entrées du journal.

    INFO: CADSource::incrementalSync returning 0x00000000~
    
  5. Passez en revue les entrées de journal pour le cycle de découverte delta. Les entrées doivent ressembler aux exemples suivants :

    1. La découverte Delta traite la liste des périmètres.

      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) --------
      
    2. La découverte delta traite les chemins de recherche LDAP, en commençant à immediate search base.

      INFO: -------- Starting to process search scope (Immediate search base) --------
      INFO: Processing search path: 'LDAP://OU=OU-A,DC=FOURTHCOFFEE,DC=COM'.~
      
    3. La découverte delta identifie le chemin de recherche de l’unité d’organisation enfant (OU-B dans l’exemple) comme chemin d’accès non valide et l’ignore pour traiter le chemin suivant.

      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) --------