|
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 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 I 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 IIRC, 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 | 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. |
- RE: [ActiveDir] Developer Best Practices doc joe
