|
Note what he indicates though. Indexed for free due to the
nature of being a linked attribute, ***but the index isn't used unless it is on
Windows Server 2003 AD***. I actually spoke to ~Eric about this in the past and
it had completely slipped my mind when discussing here. The whole idea is that
someone at MS realized, hey wait, basically all of the linking info needed
for these attributes is already available and so they enhanced the engine
to take advantage of it. This is just one more reason to use Windows Server 2003
for your Domain Controllers.
But again, use the BL if it is possible for you. Much much
faster.
joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Holland Matthew BC GB Sent: Wednesday, November 10, 2004 2:08 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [ActiveDir] Indexing an attribute Interesting, I didn’t
realize HomeMDB is ‘indexed for free’! Although, as you
mentioned, it seems to make sense to use homeMDBBL. Thanks for your
help! Matty From: Eric Fleischman
[mailto:[EMAIL PROTECTED] HomeMDB need not be
indexed. Linked values are implicitly indexed and those indexes will be used by
QP in 2k03 out of the box. If you run it with STATS spew, you’ll see that the
index type is L, for linked. ~Eric From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of listmail First off, your
initial query isn't optimal. ObjectClass user is not a valid objectcategory
attrib, it would be converted to objectcategory=person which includes contacts,
inetorgpersons, and contacts. A good solution there, IMHO, is to index
objectclass and go a search with objectclass=user. For the second piece, concerning
what you do for homeMDB, if you are looking at all users across the board, I
would switch it around and do it from the back end (shush Al - security term, I
am sitting here in Microsoft Conference Center listening to Mike Nash and
thinking security). Anyway, anytime you have to do something with all of the
Exchange users based on their database/sg/server I look at the homeMDBBL
attribute. That is an attribute in the Exchange config info section under the
Exchange server objects and you can go from taking many minutes to gather the
homeMDB info to seconds. The more I think about it though,
the less I think you will get a performance benefit for indexing homeMDB or any
DN based attrib. joe From:
[EMAIL PROTECTED] on behalf of The gain we are seeking
is to speed up the LDAP query. The background:
We have a scheduled process that populates groups with members based upon
matching results from LDAP queries for department, location and country-name
(c) Example:
Search filter for
country ‘mycountry’ is
(&(objectCategory=user)(c=mycountry))) Results from query
populate a group called mycountry-allusers Although location was
indexed, c and department so the process was unacceptably slow as we use the
domain root as a SearchBase, hence we decided to index these two attributes –
which solved the problem! Now we have a new
requirement to populate groups with members based upon the Mail Storage Group
/Server hence we want to query the HomeMDB attribute. Or course, this is
again slow due to the attribute not being indexed. This raised a small
concern of indexing a DN attribute and what the impact of this would be.
It would be great to get your thoughts, let me know (after your next
shower maybe ;-)). Thanks for your
help! Matty From: joe [mailto:[EMAIL PROTECTED]
You know though as I
took a shower and thought about this[1]. This is a DN attribute, I am wondering
if indexing may not help a lot or at all; not that I implied it would be any
great help below. I look forward to reading a response from the likes of Dean or
~Eric and what they have to say.
joe [1] Yes sick I know. I
would read books in the shower too if I could figure out a way to keep the pages
dry. Showers are a huge waste of time, right behind commuting if you drive
yourself though I refuse to take short showers both for the benefit of those
around me and because I feel hot showers are the culmination of great western
civilization. From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of joe You will have a little
DIT growth, creation of new mailboxes might be impacted a little in terms of
speed as insertion of the attribute might be a trifle slower (nothing you would
notice I expect unless doing a ton of new creations quickly with MT C code and
still you could blame it on the RUS faster than blaming it on the indexing).
Anything that searched
on that attribute would possibly be more efficient or be
quicker. You still won't be able
to do wildcard searches because it is a DN attribute. What are you looking to
get out of it? Or to put it another way, why do you think you should do
it? Overall in the end, MS
and pretty much anyone is going to say you need to test it in your test lab with
a comparable test data set as production to really know specifically what it
will do.
joe From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Hi all, Does anyone know the potential
impact of indexing an attribute in Active Directory? The attribute is
HomeMDB, it’s Single Valued and is a member of the PAS (We have approx 17,000
Mail Enabled User objects in Active Directory). Cheers, Matty |
- RE: [ActiveDir] Indexing an attribute joe
- RE: [ActiveDir] Indexing an attribute joe
- RE: RE: [ActiveDir] Indexing an attribute deji
- RE: RE: [ActiveDir] Indexing an attribute listmail
- RE: [ActiveDir] Indexing an attribute Eric Fleischman
- RE: [ActiveDir] Indexing an attribute listmail
- RE: [ActiveDir] Indexing an attribute joseph.e.kaplan
- RE: [ActiveDir] Indexing an attribute Eric Fleischman
