Query-based Distribution Groups

Discussion in 'Active Directory' started by Cary Shultz, Feb 15, 2006.

  1. Cary Shultz

    Cary Shultz Guest

    Good morning to all!

    I am suffering from 'cerebral flatulence' so please pardon my ignorance.

    I understand completely how to create these wonderful little groups.
    However, I am having a problem getting my head around how to properly use

    Here is what I know:

    You can create one of these little goodies based on just about anything.
    For example, you can base it on which Exchange Server the users 'mailbox' is
    housed...or, more specifically, in what Mailbox Store it is located. Or,
    you can base it on any given number of attributes (well, better said, the
    corresponding value). So, if you had four offices (Roanoke, Blacksburg,
    Richmond and Raleigh) you could create a QBDG based on the value for the
    attribute "l" (for 'locale', or 'City' for non-ldap speakers). So, as long
    as when you create a user account object and you populate the 'Address'
    stuff with the city information (or, do it after the fact) all those user
    account objects who have the value "Roanoke" for the attribute l will be a
    member of the QBDG. Same for the other three cities. Or, you could base it
    on the Manger attribute (say that Manager Joe Smith has 100 people working
    under him and it is his birthday so you create a QBDG based on the 'Manager'
    attribute (naturally, you want the value to be Joe Smith) so that you can
    send all of the people who work under him an e-mail with the details of the
    party. That is a whole lot easier than manually doing this!

    All this is crystal clear to me.

    Here is what is not clear to me.

    Okay, I have created these four QDBGs (based on the city, for example). Or,
    this QBDG for the people who have 'Joe Smith' as their Manager.

    I know that I can send e-mails directly to the QBDGs, just like I would to
    any 'static' Distribution Group. I have done this. No problems. However,
    I have read in a couple of places (conveniently can not find those articles
    right now) that you should not use QBDG if the membership is going to exceed
    25/30 users. If that is the case, then I do not see the value of these
    QDBGs. I am sure that I am missing something here. They are a wonderful
    tool. Thank you, Microsoft, for making these possible! Yes, I have read
    about creating an 'expansion server'. I understand how the categorizer has
    to contact a GC to expand the membership. Sounds a lot like a Universal
    Group to me. Only dynamically generated instead of static.

    Now, if that 25/30 limit is indeed accurate how in the world could you use
    these wonderful things to create something based on Exchange Server or
    Mailbox store? I would think that this number could get in the upper
    hundreds if not thousands. Or, on the users who have 'Joe Smith' as their
    manager? I might be a little bit older but when I went to school 100 was a
    lot more than 25/30! And 800 is really a lot more than 25/30.

    Is it a better idea to create a Universal Group and then populate that with
    the QBDG? Like you are supposed to do, anyway. Only, this time the groups
    with which you are populating the membership of the GC is a QBDG. So,
    instead of sending directly to the QBDG you send to the Universal DG? This
    also works. Obviously.

    But what is the 'Best Practice' way to do this?

    I have seen a ton of articles on how to create them but that is where all of
    them stop. I guess it must be very clear to everyone except me!

    Thank you, everyone.
    Cary Shultz, Feb 15, 2006
    1. Advertisements

  2. Cary Shultz

    Cary Shultz Guest

    Let me clarify one thing:

    I did say that you could base these "on just about anything". Clearly,
    since the categorizer needs to hand this off to a Global Catalog server for
    the expansion then that "anything" needs to be able to pass the PAS test.
    Cary Shultz, Feb 15, 2006
    1. Advertisements

  3. Cary,

    The only reason I can image to limit the amount of recipients in your QBDG
    is the memory involved. Each recipient in the group consumes 2k of memory on
    the Exchange server when it is being "used".

    If your group consists of 500 addresses, Exchange server needs an additional
    10Mb only to 'resolve' the names in the group when the mail is send.
    As such, if the QBDG are used quiet often, this could cause memory issues on
    your server.

    In general though, there is no hard-coded limit on the number of recipients
    in the group. After all, both Exchange and Active Directory are sized for
    hosting 1000s or 10000s users.

    I hope this makes things more clear.



    Peter De Tender, Feb 15, 2006
  4. Cary Shultz

    Cary Shultz Guest


    Yes, it does.

    Although I have seen very similar text in many different articles it clicks
    now. Thank you!

    I still need to find those articles in which it is written that anything
    above 25/30 members negates the use of the QBDG. Unfortunately they were
    not direct links in google (well, I can not find them again) and I believe
    that I found them by clicking on an article, then clicking on links from
    that article and then clicking on one of the links from those...But, these
    two or three different articles were not written by 'just some guy' who has
    'just some website'. I can not remember who the people were now...how
    convenient! Anyway, that 'information' was polluting my thought process!

    Oh, and the PAS test would only be a real requirement in a multi-domain
    environment. In my test lab I used both the 'l' attribute and the
    'physicalDeliveryOfficeName' attributes. Not sure if they are part of the
    PAS in WIN2003. I would have to look. I know that neither of these two are
    in WIN2000 (well, by default).

    Cary W. Shultz
    Roanoke, VA 24012

    Cary Shultz, Feb 15, 2006
  5. [ snip ]
    Wow! If that's the case I should stop using the ones I have that
    return more than 4,500 results! (They work fine, BTW.)

    Rich Matheisen
    MCSE+I, Exchange MVP
    MS Exchange FAQ at http://www.swinc.com/resource/exch_faq.htm
    Don't send mail to this address mailto:
    Or to these, either: mailto: mailto: mailto:
    Rich Matheisen [MVP], Feb 16, 2006
  6. Cary Shultz

    kj Guest

    kj, Feb 16, 2006
  7. Cary Shultz

    Cary Shultz Guest


    Actually I was a bit persistent today and found one of the links:


    Here is a snip from (it about 2/3 of the way down the article):


    Query-based distribution groups work best when the member list results are
    25 to 30 members or fewer. Potential member lists in the hundreds or
    thousands will put severe processing demands on a global catalog server
    because of the inefficient nature of the LDAP queries. If query-based
    distribution groups have potential to grow to larger numbers, switching the
    processing tasks from the global catalog server to a dedicated LDAP
    expansion server will help in resolving large distribution lists more

    I guess that I kinda remembered it not quite so correctly. But kinda sorta!
    I just could not get my head around why there would be such a limitation
    like this (well, according to this article). Anyway, there it is.

    Thank you to everyone who has replied to my post. Things are much, much,
    much more clear now!

    Cary W. Shultz
    Roanoke, VA 24012

    Cary Shultz, Feb 16, 2006
  8. Cary Shultz

    Cary Shultz Guest


    That really helps. Thank you.
    Cary Shultz, Feb 16, 2006
  9. Cary Shultz

    kj Guest

    There was some really insightfull information in there. I marked it myself
    for later reference. Most interesting was mitigating the GC issues with an
    expansion server.
    kj, Feb 16, 2006
  10. I would tend to argue that they may consider getting out of the writing
    business. ;o) That load isn't anything out of the ordinary that the DCs aren't
    already taking on from Exchange.

    The queries will be inefficient only if you make inefficient queries. Everything
    in the query for a QB group should be PAS enabled and indexed and you should
    avoid like the plague any of the normal stuff that makes queries inefficient
    such as NOT, multiple stacking of OR/AND, bitwise queries, anything medial, etc.

    In general I recommend that Exchange not have DLs greater than 1000 members
    simply because Exchange then has to use ranging to retrieving the membership and
    it seems to do some odd stuff when that occurs (including not using the standard
    Windows LDAP library) when it does that but that isn't the case for QBDLs
    because it isn't a single attribute being returned, it is separate objects and
    it already handles paging (not the same as ranging) pretty normally apparently.
    However, it is a lot of data to being pulling across if being used a lot.


    Joe Richards Microsoft MVP Windows Server Directory Services
    Author of O'Reilly Active Directory Third Edition

    ---O'Reilly Active Directory Third Edition now available---

    Joe Richards [MVP], Mar 5, 2006
  11. Cary Shultz

    Cary Shultz Guest


    Thank you for adding some more clarification. I was initially confused as I
    read the articles (the one to which I supplied the link is but one of
    several) before actually playing with them.

    Things are much more clear now.
    Cary Shultz, Mar 5, 2006
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.