Unfortunately this can be pretty common as well. Both with internal developers and vendors. I have spent hundreds of hours doing this type of consulting when I had other things I really should have been getting done but you have to realize that if it is going to come hit your directory, you are better off finding the issues before it is beating the crap out of your directory or you are getting beat because of perceived AD Perf issues which are simply due to a poorly written app. Many have heard the story that my UNLOCK utility was written because I sat in a meeting and had a developer tell me it was impossible to unlock an account with less than account operator rights. By far the biggest issues I hit were all around lack of fault tolerance and scale-perf testing of apps. Developers use the fastest hardware available to known man with memory popping out the back and the fast disk subsystems and make a single domain DC with 5 users and two groups and the one app hitting the directory and get sub-ms times and then run against production and see anywhere from multiple seconds to multiple minutes for the same functions or they bring to production and a DC they found last week goes away this week and their app hits the floor because it isn't smart enough to go find another DC or even worse is hard coding into the config. I have too many true life stories of both items. I had some folks trying to implement WebSphere that started off by basically telling us and I think our management that our directory sucked and it needed to be run better. In the end I had to write a full blown test framework that showed ms timings of all the various calls used to do basic LDAP operations to show which calls were taking how much time based on the different mechanisms of retrieving the data. I tended to tell Devs/Integrators three main things when chatting with them. 1. Don't ever depend on any given DC being up or even being a DC. I may shut down a machine in production just to see who will break so it doesn't happen at 3AM and I get yelled at. 2. Don't expect the best fastest hardware in production so when you scale test, load to production levels or above and do everything you can to slow it down to see how your app handles it. 3. Understand what your app actually does so when something goes wrong and you look at a network trace you can say, hey that isn't right so someone, say a domain admin, who doesn't know anything about the app has to try and figure it out. This stuff goes both for apps the dev/integrator is writing or simply trying to integrate into the environment that was written by someone else. If you are an integrator and trying to integrate an AD app into your directory and you haven't done a network trace or used something like Insight for AD to look at the queries and other traffic, you really aren't doing your job.
_____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Desmond Sent: Tuesday, January 24, 2006 3:07 PM To: [email protected] Subject: RE: [ActiveDir] Developer Best Practices doc Last time I had to do this they submitted their code to me and I rewrote the relevant parts and told them to use that as copy/paste fodder for their next project. <g> Thanks, Brian Desmond [EMAIL PROTECTED] c - 312.731.3132 _____ From: [EMAIL PROTECTED] on behalf of Creamer, Mark Sent: Tue 1/24/2006 2:22 PM To: [email protected] Subject: [ActiveDir] Developer Best Practices doc Anybody seen/created a best practices document to 'teach' internal application development teams to interact with AD? I've just been asked to do one and could use some guidance on things to include. Mark Creamer Systems Engineer Cintas Corporation | 6800 Cintas Boulevard | Mason, OH 45040 Email: [EMAIL PROTECTED] | http://www.cintas.com This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.
<<attachment: winmail.dat>>
