RE: [ActiveDir] stupid ldap queries

[joe]

Yeah I am always confused on whether I should write indexes or indices. Indices (in dih sees) is what I want to write but have seen too many MS docs that had it written as indexes. Ditto viruses and virii. English and computer speak don't meld well...   There is some old quote that goes something like (I know this isn't right but it is the gist...)   If you had a computer language that was based on proper english you couldn't find any programmers who could use it.        joe   -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm      From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, April 20, 2006 9:48 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries I'm not sure I see the link here between indices and extensions.   The former are utilised to help optimise queries against the database whilst the latter are used to store additional data in the (same) database.   If an attribute is queried on a frequent basis and it's not indexed, then I'd suggest there's a good argument for adding a new index. However, the addition of new data types and hence attributes (and/or classes) does not necessarily flow from that change - at least not in my experience.   Did I read too much into your post? Judging from DEC, I'd say you are a little paranoid about making changes to the schema - even the addition of indices :) [nice to see the word spelt correctly, for a change :) ]   I completely agree that the schema should be treated with respect and only changed where necessary - a new index is a relatively small change that can result in big improvements within the environment, however. I would not approach an extension in the same way though :)   my 2 penneth, neil From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee, Wook Sent: 19 April 2006 16:48 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries Adding indices will start you down the slippery slope that ultimately leads to custom schema extensions. Do you like new OIDs? J   Wook   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, April 19, 2006 4:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries   Exactly, you can tell you AD to do it efficiently versus trying to train everyone who writes a query that goes against AD. I mean you want to try and train everyone because there are other bad things they can do that you can't easily handle but this is a nice quick easy thing to do to help.   I HIGHLY HIGHLY HIGHLY recommend folks use adfind or ldp to test their queries and have the STATS output generated and displayed when they are doing dev work to figure out how good their queries are, in adfind, look at the -STATS* set of switches. Seriously, they are very cool. You will learn a lot about how the queries are working whether you intend to or not.     joe   -- O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm        From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, April 19, 2006 12:34 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries It’d the same relative gain running a query using objectcategory versus objectclass.  Most of the time, I would run into queries that people were using, utilizing objectclass instead of objectcategory.  Indexing objectclass made this moot.   :m:dsm:cci:mvp | marcusoh.blogspot.com   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jef Kazimer Sent: Tuesday, April 18, 2006 5:55 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries   It seems like an obvious idea to implement. Sad we never thought about it. :)   Has anyone done any tests to reveal what performance gains this yields on queries?   Thanks,   Jef Subject: RE: [ActiveDir] stupid ldap queries Date: Tue, 18 Apr 2006 17:03:35 -0400 From: [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org I did the same after I saw some of the activedir folks post about doing it… J   :m:dsm:cci:mvp | marcusoh.blogspot.com   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lee, Wook Sent: Tuesday, April 18, 2006 4:47 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries   I never understood why Microsoft chose not to index objectclass by default. I indexed it in our directory as soon as we got the go ahead from Microsoft that it was supported. That was years ago.   Wook   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Tuesday, April 18, 2006 11:50 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] stupid ldap queries   No. isMemberOfPartialAttributeSet just means that the attribute is replicated into the GC. Being in the GC does not imply that the attribute is indexed. There’s an attribute (I think “isIndexed”) which says the attribute should be indexed in the database.   Thanks, Brian Desmond [EMAIL PROTECTED]   c - 312.731.3132     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Matheesha Weerasinghe Sent: Tuesday, April 18, 2006 2:15 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] stupid ldap queries   bummer! I meant adfind -schema -f "&(objectclass=attributeschema)(ismemberofpartialattributeset=TRUE)" ldapdisplayname -list On 4/18/06, Matheesha Weerasinghe <[EMAIL PROTECTED]> wrote: sorry that was meant to be adfind -schema -f "&(objectclass=attributeschema)(ismemberofpartialattributeset=T RUE)" ldapdisplayname -list   On 4/18/06, Matheesha Weerasinghe <[EMAIL PROTECTED]> wrote: Thanks for the reply. In that case why does adfind -schema -f "&(objectclass=attributeschema)(ismemberofpartialattributeset=T RUE)" ldapdisplayname -list returning objectclass amongs the others? Doesn't this mean objectclass is indexed? The reason I ask is because I wanted to make sure I didn't write stupid ldap queries that load up the server. I am still learning so please be patient with this n00b. Thanks M@ On 4/18/06, Brian Desmond < [EMAIL PROTECTED]> wrote: > Not sure I understand the question fully, but, no objectClass is not > indexed. objectCategory is. So if you want to get all users you do: > > (&(objectCategory=person)(objectClass=user)) > > Thanks, > Brian Desmond > [EMAIL PROTECTED] > > c - 312.731.3132 > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:ActiveDir- > > [EMAIL PROTECTED]] On Behalf Of Matheesha Weerasinghe > > Sent: Tuesday, April 18, 2006 1:00 PM > > To: ActiveDir@mail.activedir.org > > Subject: [ActiveDir] stupid ldap queries > > > > All > > > > Could someone please explain how Non-indexed queries (e.g. > > "objectClass=user") fall in this category? I saw this mentioned in > some > > slides by Gil and couldnt quite understand what he meant. Isn't > > objectclass indexed as part of the partial attribute set? > > > > Thanks > > > > M@ > > List info   : http://www.activedir.org/List.aspx > > List FAQ    : http://www.activedir.org/ListFAQ.aspx > > List archive: http://www.mail- > > archive.com/activedir%40mail.activedir.org/ > List info   : http://www.activedir.org/List.aspx > List FAQ    : http://www.activedir.org/ListFAQ.aspx > List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ >       PLEASE READ: The information contained in this email is confidential and intended for the named recipient(s) only. If you are not an intended recipient of this email please notify the sender immediately and delete your copy from your system. You must not copy, distribute or take any further action in reliance on it. Email is not a secure method of communication and Nomura International plc ('NIplc') will not, to the extent permitted by law, accept responsibility or liability for (a) the accuracy or completeness of, or (b) the presence of any virus, worm or similar malicious or disabling code in, this message or any attachment(s) to it. If verification of this email is sought then please request a hard copy. Unless otherwise stated this email: (1) is not, and should not be treated or relied upon as, investment research; (2) contains views or opinions that are solely those of the author and do not necessarily represent those of NIplc; (3) is intended for informational purposes only and is not a recommendation, solicitation or offer to buy or sell securities or related financial instruments. NIplc does not provide investment services to private customers. Authorised and regulated by the Financial Services Authority. Registered in England no. 1550505 VAT No. 447 2492 35. Registered Office: 1 St Martin's-le-Grand, London, EC1A 4NP. A member of the Nomura group of companies.