From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Mulnick
Sent: Friday, January 27, 2006 2:16 PM
To: [email protected]
Subject: Re: [ActiveDir] Developer Best Practices doc
Oh you misunderstand me... I don't have sympathy for older apps now, I understood they would have issues back in say 2000/2001 when AD and the whole SRV record thing was new, not now. Now it is their fault that they don't work right and they need to be whapped for it.joe--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Al Mulnick
Sent: Thursday, January 26, 2006 11:09 AM
To: [email protected]
Subject: Re: [ActiveDir] Developer Best Practices doc
I can't begin to tell you how much I agree with Joe on this one. AD is a fully distributed app and acts like a fabric. It was designed to run with minimal effort for long periods of time and runs well as a scale out application.In the end, it's about expectations: setting and meeting them. If you set the expectation that AD is the infrastructure, and your app is something you control, then it's pretty obvious that it needs to be fixed by the application dev if not done right the first time.Unlike Joe, I have no sympathy for older apps. None. The cost/return ratio is often too low to make it worth the time spent to deal with it. In those cases where it's not possible to upgrade appropriately, I often suggest migration to a product that can provide the high-availability that this one can't. I also often suggest that they re-evaluate their expectations.It is true that this doesn't always end happily. Nor do the vendors always follow it (even Microsoft, who wrote it, right?) But that just leaves us with a choice: accept that it may be down during normal operating times, else get a different application, else...well there is no else after that. Accept it or change to something else.In my mind, it's the expectations that have to be set properly. If you expect that this application will be unstable because it's not written properly, then you'll get what you expect. If you expect it to be stable in this environment and use AD, then you'll need to write it accordingly.FWIW, vendors will continue to write poorly architected applications until such time that customers stop buying them. Then they'll change to what they're buying.You're not alone though Mark. I've had many conversations with vendors over exactly the same things. I've had one that actually said, "hey, I like the way you're talking. What else can we do to provide higher availability and play well with AD?" They were moving from SunOne solutions to encompass both AD and SunOne, OpenLDAP, etc. They new it, but they needed a lot more time.That would be one vendor down, many hundreds of thousands to go :)Set the expectations with your management. At least let them go into it with eyes open and they can then make their own decision. Make sure to tell them the limits of hardware availability and how the AD works in terms of availability (it's always available, but sometimes individual domain controllers may not be; we've taken that into account and properly written applications won't care until the very last domain controller becomes unavailable or the network stops working properly.)My $0.04 worth anyway.
On 1/25/06, joe <[EMAIL PROTECTED]> wrote:Yeah it sucks. It isn't just in the area of AD, developers suck across many of the areas. Too many people writing code that really shouldn't be simply because it got easier to do.Again, what I always told folks when I did ops for AD... "No particular domain controller is guaranteed to be up at any given time nor to even be a domain controller for a specific domain at any given time. Active Directory is a fully distributed system, we expect you to use it as such. If your application (written by you or integrated by you) does not work well with that, that is strictly in the realm of your problem and you need to find a way to deal with it as it isn't our problem." If anyone questioned that philosophy the answer was always in the realm of why try to change the infrastructure that is fully fault tolerant for an application that was written so poorly it can't use the fault tolerance. I had some understanding for folks coming out with apps in 2000 when AD was still wet, but it has been out over 5 years now and apps should not be having these issues at this point. If they are, they shouldn't be issues that Ops has to inherit, the place to correct this is in dev and in the integration phase. I fully have no problem saying that an app shouldn't be in production. If it is harmful to me or others I will actively block it. If it is harmful to the dev or integration folks they can do what they want but I have all of the paperwork showing that we had a discussion on how they will fail when the system is running as designed. We once had someone try to bust us over it once when sure enough, a DC became unavailable and they broke. They started getting everyone up in arms until I started forwarding the email chains around where I pointed out that exact issue and the integrators said they would be fine.Active Directory is too big and is the foundation for too many apps for the Admins to have to be paying special attention and running everything in special ways for a bunch of applications that were written in piss poor ways. Something that follows that is Developers and integrators shouldn't expect AD Admins to become experts on their apps so the AD Admins can figure out why the app is breaking, that is the job of the Developers and Integrators. Again, there are too many Apps that AD has to deal with.Big companies especially should be especially harsh on vendors when they do things half ass. They have the weight to push it. I have often thought how much fun it would be if all of the big Enterprise customer sort of formed a Union where if a software vendor was being a d**k about something and doing whatever it is they do half-ass, then all of the big companies report the problems to the vendor and take whatever additional actions as necessary. Big companies don't like to share info though, they are too afraid everyone will find that they run things internally in a poor way.Speaking of running things poorly, I had a great example today of where that absolutely wasn't the case, things were being run great. I took a half-day personal time day and drove and saw friends I used to work with in my last position. The group was comprised of the entire Enterprise/Domain admins team (the group I worked in) as well as a couple of the good Dev/Integration folks. We all got together like we occasionally to eat some lunch and chat about things and so I could show them the copy of "The Book" (see here --> http://www.joeware.net/win/ad3e.htm). Anyway, we met up at about 11:30 (meaning they stopped working probably around 11:10 or so) and after a couple of hours one of the Enterprise Admins had to leave (another trainy admin left earlier but she doesn't count because she has only been there 3 weeks and so is at least another month away from getting any kind of admin rights) and then the other Enterprise Admins stayed for another hour and half. During that time, I don't recall a pager going off once. So let me recap, Fortune 5 company, 100% of the Enterprise Admins away from their desks for at least 2 hours, 75% away for at least 3.5 hours. No pages. At about the third hour I realized that and started smiling and mentioned, hey that makes me feel great, you guys have been here all this time and no one has had to race away. We discussed it and almost no issue tickets were coming in, mostly it was all upgrades and new object requests which are all of the request nature and usually have an SLA of 1-2 weeks (though are usually handled in hours or less). How great is that. That is what you get if you really fight with people and push hard to work for a good stable infrastructure and application environment that is supportable and designed to work even if there are failures. They don't do what they did today everyday, but it certainly was nice that they could today. Let me tell you, when I returned to that position in the fall of 2001, what they did would have been impossible, sleeping 1 hour straight at night was impossible. That job has gone from pager going off constantly and very consistently with everything being described as an emergency and it actually was to what I just described.
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Creamer, Mark
Sent: Wednesday, January 25, 2006 4:09 PM
To: [email protected]
Subject: RE: [ActiveDir] Developer Best Practices doc
What's frustrating to me, is that even some of the most significant players in many software categories (and hardware for that matter) are not allowing some of the Microsoft best practices listed in these documents to be used. (I'm not referring to in-house development this time)
Example: An app that requires one or more hard-coded domain controllers, because the app was not designed to know how to search for an available server (WebMethods). Or one that has to be patched to know how to do referral chasing because we have multiple domains and not all the needed attributes are in the GC (Cognos).
What do you guys do? Surely you can't expect to always be able to take the high-ground and say to a business unit – "you can't bring in this new state-of-the-art application because it isn't querying the AD correctly." Especially if it works (in their minds, albeit not efficiently in mine). I'd be laughed out of a job. AD is just one small part of the big package.
<mc>
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of joe
Sent: Tuesday, January 24, 2006 11:16 PM
To: [email protected]
Subject: RE: [ActiveDir] Developer Best Practices doc
Yep, Joe and Ryan have a book they put together for NET program for the Directory Services stuff. I believe it is completed from a writing standpoint, just doing all of the stuff it takes to get it ready to get it out the door. I am not a NET person but I reviewed it for the directory related logic and processes ( i.e. queries and the general thoughts of how you would attack things). Again not being a NET person, it still seemed to be pretty good, it read fairly well.
Other than that, I would point at the writing efficient apps document from MS as well as the MSDN docs on using AD. Specific DOCs
http://msdn.microsoft.com/library/default.asp?url="">
http://msdn.microsoft.com/library/default.asp?url="">
http://msdn.microsoft.com/library/default.asp?url="">
http://msdn.microsoft.com/library/default.asp?url="">
ADAM docs are good to learn from as well
http://msdn.microsoft.com/library/default.asp?url="">
Gil wrote the book that I initially learned to write apps from called Active Directory Programming. It is broken up into ADSI and LDAP sections. It isn't the end all be all and there is an occasional issue but it obviously got me going in the right direction. I still refer back to it on occasion.
Other than that, make them read some of the better AD books out there to really understand the idea and capabilities and uses behind AD. Yes it is an LDAP directory but if you only go in thinking that you will probably not write the best apps you can write. Recommended books would be Sakari's book, get Second Edition and if I may be so bold and not sound bad doing so, O'Reilly Active Directory Third Edition.
Oh finally, send them into the various AD Programming Interface and ADSI newsgroups to see the kinds of questions other folks are asking about how to do this stuff.
joe
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Brian Desmond
Sent: Tuesday, January 24, 2006 4:33 PM
To: [email protected]
Subject: RE: [ActiveDir] Developer Best Practices docI believe Joe Kaplan and Ryan Dunn have a book which is going to be published soon on the matter.
From: [EMAIL PROTECTED] on behalf of Al Mulnick
Sent: Tue 1/24/2006 3:50 PM
To: [email protected]
Subject: Re: [ActiveDir] Developer Best Practices docIIRC, There are several books that relate to this. Somebody on this list may have written one even :)
That said, I think the normal applies to the best practices:
Use efficient LDAP queries (see Microsoft web site;several blogs as well) when LDAP is used
Use .NET best practices for dealing with code
Try to stay away from legacy practices where possible (WINNT provider if using ADSI)
Limit queries to the exact information needed.
Be sure to remember that group membership gets truncated to a limited number of members if using intuitive methods to read them. Limitation of .NET.
I'm sure there are other pieces, but I've not had to write one more specific than that.
On 1/24/06, Creamer, Mark < [EMAIL PROTECTED]> wrote:
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.
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.
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.
