Joe/Steve,
I've modified my code to so that the filter reads:
filter =>
"(&(objectcategory=msExchPrivateMDB)($object_name=*))",
and the attrs read:
attrs => "$object_name;range=0-3"
I still get way too much information back from the
query. In fact, if I comment out the "attrs" line it
makes no difference - the same result set gets
returned.
I've managed to get this query working OK using the
LDP Resource Kit GUI tool though so I'm not sure what
is happening here.
I also went to the site you specified (Glen's Exchange
Dev Blog) but couldn't find where you wanted me to
look exactly.
Also, how do I determine the number of values in a
multi-valued attribute - so that I can determine if I
need to use ranging to get to all the values?
Any further suggestions?
Thanks very much,
PJ
--- joe <[EMAIL PROTECTED]> wrote:
> There is page size and there is max values.
>
> By default the max page size is 1000 objects. Note
> that again... OBJECTS.
> This is the number of objects returned from a query.
>
> By default the max values in Windows 2000 AD is 1000
> values and the max
> values in Windows Server 2003 and ADAM is 1500
> values. Again... VALUES.
>
> When you are returning a single object but multiple
> values of a specific
> attribute and that attribute is a linked attribute
> (i.e. it has a linkid and
> is a DN type attrib) the number of values can exceed
> the default Max values
> returned setting. This can NOT happen with normal
> multivalue attributes as
> they peak out at ~850 values in 2K and ~1350 values
> in K3 and ADAM.
>
> You have two options for getting around this.
>
> First and the most common, you can use RANGING which
> is where you append a
> RANGING attribute option onto the attribute name,
> for example
> homemdbbl;range=1-* or homemdbbl;range=1500-*, etc.
>
>
http://www.microsoft.com/technet/scriptcenter/guide/sas_ads_emwf.mspx?mfr=tr
> ue
>
>
> The second mechanism is to use what is called an
> Attribute Scoped Query.
> This allows you to simply use paging as each entry
> is returned as a separate
> object instead of as a value in an attribute. This
> is only available with
> Windows Server 2003 AD and ADAM.
>
>
> Oh on the query itself.... You probably want to use
> homemdbbl=* or better
> yet
> (&(objectcategory=msExchPrivateMDB)(homemdbBL=*)).
> The reason for this
> is that while linked attributes are implicitely
> indexed and Windows Server
> 2003 AD and ADAM are smart enough to use them (2K AD
> wasn't) the implicit
> index WILL NOT be used for an exists filter. This is
> a tricky aspect of the
> implementation of the Query Processor and how it
> does index selection and
> the fact that the linked attributes kind of sit in a
> single table all
> together so the approximate count of the index/table
> size is actually larger
> than the total number of objects in the directory so
> the DNT index will
> *most likely* be used since its approximate count of
> the table size will be
> smaller.
>
> You can prove this out pretty easily if you want by
> checking the STATS
> output that AD is capable of displaying if you use
> LDP or my command line AD
> query tool called adfind (google adfind with I feel
> lucky). The STATS info
> can be displayed with the adfind -STATS* switches,
> note you will need debug
> rights on the DC so basically you need to be an
> admin. However if you want
> to play and test it, spin up ADAM on an XP
> workstation if you aren't an
> admin.
>
> Note my explicit use of objectcategory over
> objectclass. Objectclass is not
> indexed by default in 2K or K3 AD or ADAM, but is
> likely to be in LH but who
> knows it isn't even B2 yet. Objectclass unless
> indexed, is a horrible
> attribute to use by itself for a query as again, you
> are walking the entire
> DNT table. In a small AD that won't amount to much
> time but when you hit a
> directory with hundreds of thousands of objects
> goodnight Gracy.
>
> Oh, homemdbBL is the backlink attribute connected to
> homeMDB which is set on
> mailbox enabled objects. It is the fastest way to
> find mailbox enabled
> objects especially across an entire org. It isn't a
> "real" attribute in that
> you can't set it, it simply reflects the settings on
> the objects that have
> the homeMDB values set. In 2K AD it is at least an
> order of magnitude faster
> using the backlink attribute than searching on
> homeMDB (forward link query)
> if getting all entries for a specific AG, server, SG
> or DB in a large org.
> In K3, the implicit indexing can significantly help
> the speed of the forward
> link query depending on the exact query. Again if it
> is an exists query it
> will suck.
>
> If you have any specific questions on this please
> feel free to email me
> directly at this email or joe@ the same domain which
> I tend to get faster
> since I only occasionally look at the listmail email
> that comes in.
>
>
> joe
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
> -----Original Message-----
> From:
> [EMAIL PROTECTED]
>
[mailto:[EMAIL PROTECTED]
> On Behalf Of
> Steven Manross
> Sent: Thursday, April 13, 2006 6:02 PM
> To: Paul Jansen; [EMAIL PROTECTED]
> Subject: RE: net ldap, paging of large values from
> AD - problems
>
> > -----Original Message-----
> > From:
> [EMAIL PROTECTED]
> >
>
[mailto:[EMAIL PROTECTED]
> On Behalf
> > Of Paul Jansen
> > Sent: Thursday, April 13, 2006 12:42 AM
> > To: [EMAIL PROTECTED]
> > Subject: net ldap, paging of large values from AD
> - problems
> >
> > Hello.
> > I'm having some trouble dealing with ranges or
> pages being returned
> > when I do a query.
> > I'm querying the homeMDBBL attribute which lists
> the mailboxes in an
> > Exchnage mail store.
> > When I view the entry using the Microsoft LDAP
> browser
> > (ldp.exe) it shows only a small amount of detail
> and says tha tthe
> > range returned is 0-1499. Apparently Windows 2003
> AD has a page size
> > of 1500.
>
> I was always under the impression that the maximum
> page size was 1000.
> drop your page size down to 200 and see what happens
> -- the page size is
> just how many records you return at a time --
> smaller sets of data return
> quicker and leave less memory open handling the
> requests.
> Win32::Exchange has a properly formed (and paged
> search -- that could be
> used as a sample) if you want to go back to the OLE
> methods. I have no
> familiarity with the Net::LDAP functions, sorry.
> HTH
>
> However, if you are looking for homeMDBBL, your
> filter should really be:
>
> filter => "(homeMDBBL=*)",
>
> Since that will enumerate all the objects that have
> this property set.
> As well, since your filter is objectClass=*, you are
> enumerating objects
> that may or may not have this attribute set -- so,
> in a sense, your
> filter is too lax and actually including results
> that it need not
> look at.
>
> To find all the objects that have (both -- and only
> ones
=== message truncated ===
Send instant messages to your online friends http://au.messenger.yahoo.com
_______________________________________________
Perl-Win32-Admin mailing list
Perl-Win32-Admin@listserv.ActiveState.com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
