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