:o) ________________________________
From: [EMAIL PROTECTED] on behalf of Dean Wells Sent: Mon 4/18/2005 10:05 AM To: Send - AD mailing list Subject: RE: [ActiveDir] GroupBy type queries in LDAP Nobody likes you Richards ... :) -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> http://msetechnology.com <http://msetechnology.com/> ________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Monday, April 18, 2005 10:02 AM To: [email protected]; [email protected] Subject: RE: [ActiveDir] GroupBy type queries in LDAP > Sorry, joe, if that is sort of throwing fishing pole and line > to someone in the desert sounding, Not all Brett, thanks for taking the time to post. Actually this goes back to my initial response to this of using a server side sort. I haven't found a case where the sort control will return out of order; it will either sort, timeout, or throw an error when you try to sort on something it won't allow like a constructed attrib say distinguishedName. I completely agree on the comment about Dean not getting the memo.... joe ________________________________ From: [EMAIL PROTECTED] on behalf of Brett Shirley Sent: Mon 4/18/2005 2:50 AM To: [email protected] Subject: RE: [ActiveDir] GroupBy type queries in LDAP Basically sorting it by using the NTFS B-Tree for file names as your indexing method ... very cunning! As hackerly as this solution is, it has some cons ... 1 - Requires disk space to store such information. 2 - It will churn the disk a bunch, dumping all the DNs+Attribute1 to a file. Then sorting them into a whole bunch of files. I.e. you may become disk bounded on the client you're running this from. 3 - BTW, if your Attribute1's values have a tendency towards similar prefixes, ensure you 8.3 naming off on that volume, or slowness. It may sound like I'm attacking, I'm not, just weighing options .. My Solution: If Attribute1 is indexed, there is a better way ... we have this control, it says to the server, hey I'd like the entries back in sorted order, based on this attribute. - See winldap.h in SDK, and see LDAP_SERVER_SORT_OID for details on it. Then one could loop and print the current and previous iterations DNs if the previous iteration's Attribute1 value equaled the current Attribute1 value ... This is nice, it requires no intermediate storage, couldn't really become throttled on client disk subsystem, uses server side DB index, ... Aside: One could also of course implement cunning aggregate / count functionality as well, for attribute's that may have similar values, like "title". Though w/ Deans method it'd be easier, b/c you could do "wc *" in the TEMPDIR. More sexyness w/ Dean's solution. More perf thoughts: Though, my intuition says, your solution will still be faster in some situations, if running on a seperate client machine (i.e. not running on the DC), and the DIT doesn't fit in memory. Also yours is already coded, a big plus for most people. Basically in any case where in order traversal of the DIT is faster than index based walk, will end up being faster for your method. Also mine will just plain break I think if Attribute1 isn't indexed. In fact I think the server just returns the objects not in the order you requested, but maybe I'm wrong, and it does the right thing and returns an error. Sorry, joe, if that is sort of throwing fishing pole and line to someone in the desert sounding, but Dean has definately seen water / LDAP. Everyone forgets (or doesn't know of) the sort control, so I thought I'd give it some "air time" ... if only I had a blog to mention this kind of thing. Cheers, -BrettSh [msft] Posting "AS IS" ... no rights are confired ... P.S. - I didn't understand all of the .cmd file, FYI, Dean, people are supposed to move to bash or perl before they get this good at .cmd. You may not have gotten the memo. (from the love) So for my own edification, what exactly are these lines doing: set UNIQUEVALUE=!LINE:~0,80! set UNIQUEVALUE=!UNIQUEVALUE:%ATTRIBUTE%: =! set UNIQUEVALUE=!UNIQUEVALUE:\=-! set UNIQUEVALUE=!UNIQUEVALUE:/=-! set UNIQUEVALUE=!UNIQUEVALUE::=-! -----Original Message----- Date: Sun, 17 Apr 2005 10:01:51 -0400 From: joe <[EMAIL PROTECTED]> Reply-To: [email protected] To: 'Send - AD mailing list' <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] GroupBy type queries in LDAP Very cute. Your batch files scare the crap out of me. :o) joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Wednesday, April 06, 2005 6:18 PM To: Send - AD mailing list Cc: [EMAIL PROTECTED] Subject: RE: [ActiveDir] GroupBy type queries in LDAP Since a solution hasn't manifested itself to date, I got intrigued and tried to put this together in a simple and relatively fast shell script ... which I've enclosed as a text file (if memory serves I am able to enclose small text files). The script requires two args; a QUOTED "DN" and the LDAP name of the attribute to look at. Hope this serves your purpose, if not, I'm certain it will serve me at some point in the future :) Dean -- Dean Wells MSEtechnology * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jeremy Palenchar Sent: Monday, April 04, 2005 5:23 PM To: [email protected] Subject: [ActiveDir] GroupBy type queries in LDAP OK, LDAP evangelists, I need to query our customer-facing AD for a list of all the users who share a particular attribute. Let's call that attribute "Attribute1." So, if two people have the same value in Attribute1, I need their DN. The trick is, that I want the results for all possible values of Attribute1. In SQL, I would use group by Attribute1 having count(Attribute1) >1 to get a list of all Attribute1 values where more than one object had the same value. I would then join that back to the table to get a list of all the DN's with those values of Attribute1. Is there a way to do this with an LDAP query. Please note that the directory contains millions of objects and iterating through them will be painful. -Jeremy 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/ 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/
<<winmail.dat>>
