I have spent more
than two days banging my head against several brick walls trying to solve this
one with no success. If anyone can enlighten me on the matter, you'd make
my day.
Creating an address
list in exchange 2k is *supposed* to be a simple matter. Create a new
list, stick in an appropriate filter like (&(objectcategory=user)(cn=b*))
and outlook displays the rather useless address list of every user with a common
name starting with b. So extrapolating from that success, I tried to
create a useful address list like - show me all users in a particular OU (We
have multiple sites, and the AD is set up in such a way that users from each
site are in seperate OU's. Pretty simple stuff so
far.)
Using the Exchange
system manager like before, I choose to create a custom search, select the user
object from the list and select the x500DistinguishedName attribute to query
(the DN describes the full path to any object in the directory.) Setting
the query up as (&(objectcategory=user)(distinguishedName=CN=Nick
Bradford,OU=<my dept>,OU=<My Site>,DC=<My Domain>,DC=Net))
returns the expected results - namely my user object. So now the obvious
requirement is to wildcard the distinguished name (like I wildcarded the common
name attribute before.) Using the UI to construct this query (not just banging
out the syntax myself, but using the pretty drop down menus to select
distinguished name 'ends with' etc) and the UI builds the query
as (&(objectcategory=user)(distinguishedName=*OU=<my
dept>,OU=<My Site>,DC=<My Domain>,DC=Net)).
Needless to say -
this is where it fails - or rather, returns no results.
A query that is
only a wildcard as the DN successfully returns all
user objects in the directory.
yet a query that
contains partial wildcards, fails.
I have
tried.
*OU=<my
dept>,OU=<My Site>,DC=<My Domain>,DC=Net
*,OU=<my
dept>,OU=<My Site>,DC=<My Domain>,DC=Net
CN=*,OU=<my
dept>,OU=<My Site>,DC=<My Domain>,DC=Net
CN=\*,OU=<my
dept>,OU=<My Site>,DC=<My Domain>,DC=Net
to no
avail.
So then I hunted high and low
for other solutions. A few things are worth
mentioning.
A full ldap query allows the
user to specify the search base and depth. The search base takes the form
of a distinguished name (eg (OU=<My Site>,DC=<MyDomain>,DC=Net)) and
allows you to specify to search starting at an arbitrary point below the top of
the tree. Unfortunately the address list query builder UI only allows you
specify the filter, not the base and/or depth. Digging into the AD using
ADSI edit, and an attribute called msExchSearchBase is available on the address
list object itself. It takes a data type of DN, so I thought I had solved
my little problem. Not to be - as far as I can tell, changing this
attribute appears to have no effect. The query itself appears to be
encoded within multiple strings in the attribute called
msExchPurportedSearchUI. Additionally there is an attribute called
msExchSearchScope, which would appear to be the search depth, but playing with
that attribute appears to have no affect either.
Searching MS aswell as the
whole internet for any of these attributes by name returns a big fat zip.
I have also in my searching
stumbled accross a supposedly supported 'extensible filter syntax' You are
supposedly able to format the query in such a way that you can specify the
actual comparison that is done on the filter (namely there is a comparison type
called 'distinguishedNameMatch') but this appears to have no effect, even when I
script the query using ADO and VBScript. (Ive also been using the ldp.exe tool
from the support tools to quickly test queries...)
On top of all that - I have
also found an additional attribute to query on that contains the necessary info
to describe an objects position int he AD - canonicalName. Strangely
enough - I cant seem to get a hit at all using that attribute(regardless of
whether I use wildcards or not). Does it have to be replicated to the GC
as part of the partial attribute set to make it searchable??? Of this Im not
sure
So the only solutions I can see
at this stage are:
1 Put up with having
cruddy address lists.
2 Create a group policy
applied to each ou, use login scripts specified in those GPO's to modify group
membership of objects in the OU and use the Group membership attribute to build
the query on. YUK!
3 Pray to some deity that
someone on this list has been here before and has a
solution....
I hoping that 3 turns out to be
true... :)
TIA
Nick Bradford MCP, MCSE
Systems Analyst
Media Command
+613 9261-6489
http://www.sunbelt-software.com/exchange_list_charter.htm
