|
Define “real” I guess. Both are “real” in the sense that you can read them and for the forward link you can modify it. Neither are single columns in the main data table where non-linked attr’s are stored. They are both built on the fly out of the link value table.
We should take this part of the discussion offline, it is hairy.
~Eric
From: joe
[mailto:[EMAIL PROTECTED]
Oh. No kidding. I learned something else then... It won't use the attribute because it doesn't exist...
Maybe I am even more confused now though... How is member or homeMDB not a real attribute? I could understand if the BL wasn't considered a real attribute, but the FL?
joe
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman On 2k if you index this attribute it would have no impact on the dit and no impact on perf. The attribute doesn’t “exist” in the true sense of the word. Rather, it is a query of a table that yields the value of the attribute. Therefore no new index will be created in 2k. In 2k03 the same index is there but QP uses it and therefore gets the perf benefit.
Glad that the list learned something new. That’s always a good thing.
More generally, QP is better and faster (does better==faster for QP you think?) in 2k03 than 2k. This is a big example, but there are others both big and small.
~Eric
From: joe
[mailto:[EMAIL PROTECTED]
Ok after further discussions with ~Eric on this and some testing in AD/AM on my flight back to MI and against one major Active Directory since being back I have learned something very cool.
In Windows Server 2003 AD there should be no real difference in speed in hitting the FL's of a linked attribute and the BL's. This is a huge change in AD from Windows 2000. In Windows 2000 there was no doubt that pulling the memberof attribute of cn=joe,cn=users,dc=joe,dc=com was not only faster than pulling the group DNs based on a the following query "(member=cn=joe,cn=users,dc=joe,dc=com)" but not even worth comparison in larger deployments. Now, in K3 AD.... These times are almost equal in every test I have done so far. This is EXTREMELY cool and helps with an issue with enumerating groups for a user across a forest. No longer in K3 AD would you need to query the memberof attribute of a user on a GC in every domain.
Of course if running from a Windows machine it may still be more performant to hit every GC and grab the tokenGroups attribute so you can avoid having to recurse into the groups for nesting but from a non-Windows platform where binary blob of the SID to userid may be a pain this is a great boon to have this search speed be so much better.
Specific to the post below, this means you do NOT have to go against the homeMDBBL to get the list of users in a given Exchange Database in a performant way. You can query the FL's via a query as simple as
(homeMDB=blah blah blah). Where blah blah blah is the full DN of the store you are interested in.
This is just one more reason to deploy K3 out there...
After rereading the whole thread again, this brings up a question in my mind for ~Eric I didn't ask offline but which goes back to the heart of the original question. On 2K specifically if you index this attribute, what would be the impact to the size of the DIT? Since it is already implicitly indexed I would think that should mean there is no impact. Would that be accurate?
joe
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of listmail I sit corrected. :o)
I guess what I meant is that a linked attribute is used as an implied indexed attribute for queries in K3.
Might be interesting to just have the engine light the indexed flag of any attributes that are linked and clear all confusion in K3.
On another topic, I know everyone on the list is jealous, I actually met ~Eric face to face today. He looks amazingly like Tom Cruise.
joe
From:
[EMAIL PROTECTED] on behalf of Eric Fleischman That’s not entirely true either, but close. A more accurate statement: the index is not used _by query processor_ in 2k, but is in 2k03. The index is used by other things in AD in 2k, like a simple read of the ‘member’ attribute of a group.
~Eric
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
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 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 Holland Matthew BC GB
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 Holland Matthew BC GB 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 Eric Fleischman
