|
That specific example I think does make sense as it is
directly related to authentication. Also putting it in the main partition gets
around my other issue. GID/UID/NIS info for Unix integration also works there as
it is authentication/authorization.... etc.
Lots of stuff like that. Exchange? No, unless you have a small centralized AD or a
large decentralized Exchange deployment then it makes sense to be in the main AD
or you have a separate forest for Exchange that you keep entirely in the
datacenter (sounds like an AD/AM implementation almost...).
I think the smaller the deployment the more you would get
away with and the more intelligent it is to use app partitions over AD/AM
because it is adding considerable complexity in relation to what is probably
already there plus usage should be much lower. Your support model is completely
different and the people involved tend to have a wide scope of control and
responsibility. As you get bigger and bigger your support model gets more
segregated and "binned" and things should get moved to logical locations that
help facilitate that binning and segregation so responsibility of one particular
thing doesn't require the ability to be able to damage some other area. I.E.
Managing App partitions on a DC that you aren't overall responsible for.
We haven't had any serious well known wide spread issues
yet where people started knocking down DCs with non-auth/auth type of stuff yet
but once we do, if ever, a lot more people will start touting the idea of
running as little as possible on DCs and questioning why in the world are we
putting everything except the kitchen sink in the directory that is for making
sure people are who they say they are. Obviously this will be more likely to
occur in larger deployments. Actually wait... there is a hot fix in K3 it seems
for a DC that gets so busy it forgets its a GC... This is a hint of what I am
trying to forecast. That could be caused by users authenticating but would
expect it would more often be related to machines beating a on DC getting App
data.
-------------
http://www.joeware.net (download joeware)
http://www.cafeshops.com/joewarenet (wear joeware)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Tuesday, March 09, 2004 3:28 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] "Program Data" container really depends on the app and how it is related to security
in the enterprise - similar to what Eric said rgd. ADAM "But if you don't need
them (independent Schmema/DSA), don't go with it. Let's not over-engineer the
solution."
I wouldn't want app specific data, which is very much
related to authentication in my forest to be held on yet another directory, that
I need to secure. E.g. are serial-numbers for certain smart-card authentication
solutions - I sure am happy to have these added to the NOS AD and don't want
them stored separately (either directly in the domain partitions or within a
separate app-partition.)
my 0.02 Euro-Cents ;-)
/Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Dienstag, 9. März 2004 06:42 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] "Program Data" container I'm a big fan of DCs primarily doing
authorization/authentication. The app stuff can go somewhere else to play.
:oP The more stuff you stack up on a domain controller the more chances
you have of making it so it can't do its primary job. All of the other stuff is
cool and all, but if it can't authenticate someone, so what.
I am Enterprise Bred I am told and maybe that accounts for
that.
Throwing app partitions is adding more stuff to DCs to be
managed there that has nothing to do with auth/auth. I was never a fan of the
idea and when I saw the announcements of AD/AM I was quite excited and started
looking at Exchange saying "hint hint". When you run 10,20,30,200,400,700 DCs
the last thing you want to do is worry about which ones get the app partition
for App1, App2, and AppC. Managing your replciation of the default containers is
more than enough fun.
If you have an app that needs forest or domain wide
coverage, that is a little better and I would start to consider it. But doing
one off DCs is generally a bad idea because you start raising criticality of
specific machines. Lets see on this DC I need to watch replication for this this
and that. For this one that that and this. etc. Now I can look at all DCs in a
given domain and I know I have either 3 partitions or 9 partitions. You come
into my forest and take a shot gun to some of my DCs I will go tsk tsk, I won't
go holy shit you just killed a one off. This lets me manage things in a calm
cool collected manner.
As you get larger consistency wins out over most anything
else for decision making processes for supportability reasons. You sacrifice
some flexibility and possibly some hardware savings but support costs can easily
trump that stuff if people have to overly aware of the configuration of the
environment.
Plus MS has made using AD/AM a fairly painless thing.
-------------
http://www.joeware.net (download joeware)
http://www.cafeshops.com/joewarenet (wear joeware)
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman Sent: Tuesday, March 09, 2004 12:11 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] "Program Data" container Maybe. I'm a HUGE ADAM
guy, totally love it, but if AD does the job, why introduce another
infrastructure to support? If you can do it in an app partition and that is
acceptable (security, performance, etc.) why bring in another set of DSA that
need be supported? There are plenty of reasons to use ADAM
here: 1)
Independent
schema 2)
Dsa
independent (security, perf, etc.) from dcs But if you don't need
them, don't go with it. Let's not over-engineer the solution.
:-) ~Eric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe CoughAD/AMcough. ------------- http://www.joeware.net (download
joeware) http://www.cafeshops.com/joewarenet (wear
joeware) From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Eric
Fleischman Another approach: if we
are talking about w2k03, application-specific data can be put in an application
partition. I love using app partitions for this sort of stuff. It lets you have
a custom replication topology such that the data is only on those DCs where
required, across domain boundaries, plus none of it is ever replicated to the
GCs (as NDNCs are independent of PAS replication and don't participate in that
process). My
$0.02 ~Eric From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Mulnick,
Al I didn't have a link, I
was just asking if you'd checked. There is very little about what it's
there for that I see so far. This link indicates it's to be used by
developers, but not a lot of detailed information beyond that http://msdn.microsoft.com/library/default.asp?url=""> If your application has
nothing to do with an OU, then does it matter where you put it? I can see
if you didn't want to incur the replication overhead, that it would make sense
to put it in a different partition. But I can't see why you wouldn't use
an OU to at least house the data you want to store to give it some
organization. Ether way, maybe somebody from Microsoft will chime in with
a really definitive link and let us know what the heck it's intended for vs.
what it can be used for..... Al From: Alice
Joseph [mailto:[EMAIL PROTECTED] Al: Do you have any link to
an MSDN page that talks about the Program Data container? If you have, let me
know (I couldn't find anything, even a Google search didn't
help). Technically, yes, you
can put data anywhere in Active Directory. But each of those partitions and
containers are there to serve some purpose (otherwise you wouldn't need a config
partition, schema partition, domain parttion and a place for LostAndFound, NTDS
Quotas...etc in domain partiton - technically you could put everything under one
single node in there). And why would I want to
create an OU structure for an application, if the application hasn't got
anything to do with it? And how does it relate to the existence of a "Program
Data" container? I just wanted to know what goes in
there. From: Mulnick,
Al [mailto:[EMAIL PROTECTED] Technically, you can
put data anywhere you want in Active Directory. However, is there any
reason you wouldn't create your own OU structure for an application?
Have you checked MSDN
for information on the program data container to see what uses it?
From: Alice
Joseph [mailto:[EMAIL PROTECTED] What is the purpose of "Program
Data" container in the domain naming context of Active Directory? Is it a
general purpose container where I can store any type of data or is it meant for
specific purpose? Thanks Alice
Joseph |
- RE: [ActiveDir] "Program Data&quo... Free, Bob
- RE: [ActiveDir] "Program Data&quo... Mulnick, Al
- RE: [ActiveDir] "Program Data&quo... Mulnick, Al
- RE: [ActiveDir] "Program Data&quo... Eric Fleischman
- RE: [ActiveDir] "Program Data&quo... Eric Fleischman
- RE: [ActiveDir] "Program Data&quo... GRILLENMEIER,GUIDO (HP-Germany,ex1)
- RE: [ActiveDir] "Program Data&quo... GRILLENMEIER,GUIDO (HP-Germany,ex1)
- joe
