RE: [ActiveDir] Simple LDAP Query

[Mulnick, Al]

Hey Groupie!! ;-)   Paul, I think you make a good point about looking into what MIIS can do for them.  Disabling the RUS is likely a good idea for them in terms of reliability, speed, and reliability.  Or, put another way, it might be more reliable in a hosting situation to disable the RUS and take over it's functions on your own.  That's where MIIS might provide some value, saving some time in the scripting/coding area.    But removing the RUS and taking over it's functions is aimed at hosting providers. That's where the idea came from and for good reasons :)   Al From: Cotter, Paul M. [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 5:04 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Simple LDAP Query So based on what I'm reading on this thread, Address lists are formed by defining an LDAP query that determines which objects are stamped with the GUID for that address list, this is then set by the AL portion of RUS.   Since the membership of an address list is not directly defined by the LDAP query in the list itself, but rather by the presence of the AL's GUID in the showInAddressLists attribute of the user object, I think you could use the Identity Integration Feature Pack (IIFP) to stamp the following attributes appropriately:   proxyAddresses mail showInAddressLists targetAddress (if appropriate) msExchHideFromAddressLists msExchPoliciesExcluded (Populate with "{26491CFC-9E50-4857-861B-0CB8DF22B5D7}" to uncheck "update addresses based on recipient policy" checkbox)   This might relieve some of the burden from RUS and reduce the AL rebuild times, improving your overall maintainence time.   What do you use to provision the users to AD?  If it's driven by some external data source, you could also use the IIFP to provision new users/mailboxes, also possibly relieving some of the burden from the RUS.   Doing away with the RUS altogether (if it's even possible) could potentially introduce problems with Exchange Delegation and mailbox creation, if I'm reading the posts Joe mentioned correctly.   Paul   P.S. if it seems like I mention the IIFP/MIIS a lot, it's because I do.  I'm an MIIS groupie.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Wednesday, May 05, 2004 3:31 PM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Simple LDAP Query It's probably that last option that will be your best option for a hosting scenario.  It's why that kb is there in the first place and would like provide the best results in your situation.   Al From: joe [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 11:59 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Simple LDAP Query I haven't tried it but one of the things I was looking at previously is prepopulating the attribute that has the lists an object is part of. I think that attribute is showInAddressBook? It should have the DN of the list that the object is a member of.   Here is one article on the AL stuff - http://support.microsoft.com/default.aspx?scid=kb;EN-US;304516   Here is another talking about how RUS does the ALs - http://support.microsoft.com/default.aspx?scid=kb;EN-US;253828   You could look at http://support.microsoft.com/default.aspx?scid=kb;EN-US;253770 and possibly consider if you could get away from using the RUS by beefing up your provisioning system.      joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael B. Smith Sent: Wednesday, May 05, 2004 10:40 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Simple LDAP Query We do Exchange hosting, and as a service it has taken off.   Each company has it's own OU and then objects (users, groups, and contacts) within that OU.   Each company has 3 address list objects (an "All Address Lists", a "Global Address List", and an "Offline Address List"). Each address list is dedicated to that company. Only mail-enabled objects for that company are present in the address list (mail=*) and searching for (extensionattribute10=some-unique-tag) limits the A/L to that company.   Each server hosts a relatively small number of companies and is the address list server for the companies whose mailbox is on that server. Each server is also a "scaled-out" server. It's not a hefty box.   Client churn is a big deal. On some servers the store maintenance doesn't finish in the standard timeframe. Logging indicates that it is due to A/L rebuilds.   So... I was looking to improve my A/L queries. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Wednesday, May 05, 2004 10:06 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Simple LDAP Query Why do you need both attributes?  And if you're trying to build an AL, why is the speed such a big concern?  How many objects are we talking about?  What's the big picture of the solution? From: Michael B. Smith [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 05, 2004 9:31 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Simple LDAP Query I'm using an extensionattribute and the mail attribute right now, to do precisely this. But it's dog slow and it complicates provisioning.   If it just can't be done, well it can't be done. I'll live with what I've got -- I just wanted to improve my current process. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mulnick, Al Sent: Wednesday, May 05, 2004 9:13 AM To: '[EMAIL PROTECTED]' Subject: RE: [ActiveDir] Simple LDAP Query Trying to figure out exactly what you want to accomplish.  You cannot use an OU as the criteria for Address books as previously mentioned, you can however use an attribute, a group (as mentioned), etc. to make this work.  You could tag each object in the particular OU with criteria such as "my criteria for OU1". That would allow you to have a particular OU built into an AL in effect.    As for searching, why not just figure if it's mail-enabled or mailbox-enabled, it fits your match and you'll take it? From: Michael B. Smith [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 04, 2004 9:39 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Simple LDAP Query The problem is with contacts and public folders. I already do the crawl. But contacts within the OU's are a particular pain.   Perhaps I'm wrong, but I figure that there HAS to be a way. :-P   (Hope springs eternal...)   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Tuesday, May 04, 2004 8:33 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Simple LDAP Query   You can't do that with exchg. Get a security group with everybody in the OU, and search for (memberOf=DNToGroup). I know it's a pain - I do it. If the OUs are constantly going to change, write an agent to crawl them every night and update the groups.   --Brian Desmond -----Original Message----- From: Michael B. Smith [mailto:[EMAIL PROTECTED] Sent: Tue 5/4/2004 7:27 PM To: [EMAIL PROTECTED] Cc: Subject: RE: [ActiveDir] Simple LDAP Query Unfortunately, I don't have the luxury of specifying my search base. I need a query that I can, specifically, place into an "All Address Lists" object in Exchange System Manager. So effectively I'm limited to a search base of the domain.   But thanks for your response.   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. Simon-Weidner Sent: Tuesday, May 04, 2004 6:00 PM To: [EMAIL PROTECTED] Subject: AW: [ActiveDir] Simple LDAP Query   Hi Michael,   just define it in the search base, e.g. LDAP://ou=myou,dc=mydomain,dc=com. You define usually searchbase, filter, attribues and scope - and searchbase does not need to be the domain, it can be any LDAP Path.   HTH, Ulf   Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Michael B. Smith Gesendet: Dienstag, 4. Mai 2004 23:38 An: [EMAIL PROTECTED] Betreff: [ActiveDir] Simple LDAP Query I'm obviously missing something simple...   How do I construct a query to return all the objects in a particular OU?   (To be specific, I want to return everything in an OU that is mail-enabled -- but I can do the rest given the syntax to search only a particular OU.)   Thanks   =========================================================== Important: This electronic mail message and any attached files contain information intended for the exclusive use of the individual or entity to whom it is addressed and may contain information that is proprietary, privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information may be subject to legal restriction or sanction. Please notify the sender, by electronic mail or telephone, of any unintended recipients and delete the original message without making any copies. ===========================================================