I was asked about the whole indexing objectclass topic I talked about in my last post. I have one thing to say about it.
Just do it.
It is a good thing, it helps every single app out there that has a crappy query that uses objectclass and no indexed attributes. This includes many scripts, many apps, and even MS applications. It used to be you could search the KB for objectclass and you could get all sorts of examples of where mistakes where made and objectclass was used without an indexed attribute and it caused perf issues. I don’t know what happened to those articles but I can’t seem to find them anymore. Regardless indexing objectclass is still a great thing to do.
🙂
This logic is not sound joe. By this logic, index everything! Why not, right? I mean, “just do it.”
Better: turn on field engineering. These searches will quickly bubble to the top if you are paying a perf cost for them. If you have them, go for it. But why pay the index cost (and there is a cost, and it involves disk seeks I would add) when you don’t need it?
The logic of “crappy apps” breaks down. By this logic, you should do every index type for every attribute you populate….and perhaps those you don’t as well, in case you populate them one day.
Ah you misunderstand. I am not specifying general logic of just do it for indexing everything. For instance, I will probably never say to everyone at large, index employeeID, it will make your AD run faster.
I wouldn’t have to do it for this attribute if there were some “easy” way for any capability level AD Admin to determine the bulk of queries hitting the AD. The current methods are a little inconvenient and if you asked all of the AD Admins out there, maybe 15% might known how to figue out what queries are coming in.
That being said, objectclass is a special case. MS should have indexed it out of the box, I am not just saying that, I saw an email from Don Hatcherl once saying that very thing and when it comes to AD, I tend to listen to DonH.
I would wonder if the MS Internal AD has objectclass indexed? What about your future LongHorn AD?
The note from Don isn’t the only reason I say that though, I say that from years of experience with large production Active Directories and seeing the kind of code and scripts being written which in many cases use objectclass as the main search key and no other attributes in the query are indexed except for maybe on accident. I have found that this seems to generally speed up many apps, especially apps ported from other LDAP directories including Exchange.
Further reason can be found by doing a quick google of support.microsoft.com of the word objectclass and check how many KB articles specify inefficient queries that could become immensely more efficient by indexing objectclass. If you don’t find at least 5 or so in the first 10 minutes I would argue you aren’t looking hard or all of the corrections I am working on submitting to MS KB content owners now have been made.
Again, so we are clear, I am not saying “index the world”, I think in a large directory that is probably a quick way to break AD. However, I do stand very strongly behind my recommendation to index objectclass unconditionally.
I posted on your other post so I wont’ way much here, but I would add….
> I would wonder if the MS Internal AD has objectclass indexed?
Nope.
> What about your future LongHorn AD?
It’s being seriously entertained. I’m actually for this. 🙂 See my other post for why. But, I still don’t recommend indexing things w/o careful analysis. This is why we are so slow and careful to change such indexes in the product….we want to make informed decisions.