locked
SCCM 2012 Active Directory Group Discovery; Strange Domain Prefix behaviour RRS feed

  • Question

  • Hello Techies,

    I seem to have run into a strange problem while configuring SCCM 2012 AD Group Discovery, where the domain prefix of the groups are inconsistant when adding a second domain.

    First we are only checking groups in the domain "Probiblio.tld".

    The output is checked using a custom query, note the "User Group Name" column of the Probiblio.tld users (syntax: PROBIBLIOTLD\<group_name>):

    Next we add the domain Manage.tld to the AD Group Discovery, and immidiately run a full discovery.

    Now the syntax/prefix of the Group Names for the Probiblio.tld domain have changed to "PROBIBLIO\<group_name>":


    Is this a bug, or behaviour that can be explained somehow?

    Can I somehow force these names to consistantly containt the TLD part, both for querying purposes and the fact that I cannot distinquish groups that exist in domains with the same prefix, like probiblio.TLD, probiblio.NL and probiblio.LOCAL?

    And what are the conditions for SCCM 2012 to determine these prefixes; as we can't afford to rewrite all queries, like now when AD Group Discovery is being changed, as this is just one example of simple configuration change which makes ALL these queries invallid?

    Thanks,

    Kevin

    Tuesday, September 2, 2014 12:43 PM

Answers

  • As mentioned, you are doing some non-standard naming of domains with NETBIOS domain names that don't match the DNS domain names in addition to the disjoint DNS domain names. I'm not saying any of this is wrong, just that the code doesn't account for any of these.

    You really need to call CSS as there's simply no way to magically make it better here in the forums.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Joyce L Tuesday, September 9, 2014 9:26 AM
    • Marked as answer by Joyce L Thursday, September 11, 2014 8:40 AM
    Tuesday, September 2, 2014 3:17 PM
  • The AD Group Discovery can act a bit weird with discovering names/OU's of Computers. Especially in disjoined domains.

    Check the Adsgdis.log and search for your prefixes to see exactly how it differs in discovery from the normal ones. This might shed some light on it.

    Also as others advise, call Microsoft about your specific configuration, they might already have a registered solution for it.


    All the best, Jesper Hassing - MCTS SCCM 2012 - MCSA 2012 Server - MCP

    • Proposed as answer by Joyce L Tuesday, September 9, 2014 9:18 AM
    • Marked as answer by Joyce L Thursday, September 11, 2014 8:41 AM
    Friday, September 5, 2014 7:38 AM

All replies

  • That's a bit non-standard naming for AD and a disjoint DNS namespace that is most likely not accounted for. You should contact Microsoft CSS to verify.

    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, September 2, 2014 1:24 PM
  • I don't see how this is, or is related to, a Disjoint DNS namespace. Since the output is different between scanning 1 and more then 1 domain, and reverts back to the old values if I delete the 2nd domain. Imho, output should be consistant; but it isn't.
    Tuesday, September 2, 2014 1:36 PM
  • As mentioned, you are doing some non-standard naming of domains with NETBIOS domain names that don't match the DNS domain names in addition to the disjoint DNS domain names. I'm not saying any of this is wrong, just that the code doesn't account for any of these.

    You really need to call CSS as there's simply no way to magically make it better here in the forums.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Proposed as answer by Joyce L Tuesday, September 9, 2014 9:26 AM
    • Marked as answer by Joyce L Thursday, September 11, 2014 8:40 AM
    Tuesday, September 2, 2014 3:17 PM
  • The AD Group Discovery can act a bit weird with discovering names/OU's of Computers. Especially in disjoined domains.

    Check the Adsgdis.log and search for your prefixes to see exactly how it differs in discovery from the normal ones. This might shed some light on it.

    Also as others advise, call Microsoft about your specific configuration, they might already have a registered solution for it.


    All the best, Jesper Hassing - MCTS SCCM 2012 - MCSA 2012 Server - MCP

    • Proposed as answer by Joyce L Tuesday, September 9, 2014 9:18 AM
    • Marked as answer by Joyce L Thursday, September 11, 2014 8:41 AM
    Friday, September 5, 2014 7:38 AM