RE: [ActiveDir] Adding custom fields to AD
Yes, I think Sept 20th, 2005, but as anything I or msft produces, there is a caveat that it would release when it is ready. http://groups.google.com/group/microsoft.public.windows.server.active_directory/browse_thread/thread/39151ab777c4582d/7b3bf007a7b96f26?lnk=stq=JET+Kodiak+Exchangernum=2#7b3bf007a7b96f26 I slay me. Cheers, BrettSh P.S. - Eric, the answer is still no. This posting is provided AS IS with no warranties, and confers no rights. On Mon, 10 Oct 2005, joe wrote: Ah true, I didn't think uses of ADAM which I think may make more sense than AD for some of those internet uses. So do we have a timeline on these blog entries? eg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Monday, October 10, 2005 1:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Yes, I was hoping you wouldn't take it has who has a bigger database contest, that was not my intent. Besides it was really who has seen the bigger database, and who wants to admit that, you want to HAVE the bigger database. My databases aren't really that big, usually a smidgen over the default 10 MB size for testing, really quite small actually. As for the wondering what kind of crap is stuffed into the AD DB, I'd agree with you to some degree ... for corp / NOS type AD DBs ... but the ones I'm think of are almost always internet auth DBs, and have millions to 10s of millions of identities stored. Then the size starts to make sense. So you can imagine why they get big. And finally about the size limit on AD objects, how many attrs, multi-values, link values, etc, and such, I have a blog post planned about that ... actually 3 posts ... Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, joe wrote: Ah Brett, you incorrigible one, you misunderstand my point of posting those numbers It wasn't to say, look how big I have seen, but instead, look how big these companies are and they still have small DBs. When I hear of some giant DB I don't think wow, what a big DB, I think, what kind of sh*t is being thrown into that AD to bloat it to that extent[1]? I especially love hearing about companies that jam huge binaries into the directory like images that get replicated to the four corners of the earth and are only read by one program, a web app, in one or two of the company's datacenters. Great use of bandwidth. I also especially love seeing a crap load of data going into the directory for Exchange when Exchange is centralized, also great use of bandwidth. That site in South America or in Kuala Lumpur with 10 people and a GC because they have crappy connectivity certainly needs to have every object and the entire Exchange selection of data for the other 200,000 users. No possible issues in data theft there... I think after we get past the training of everyone to only grant permissions to those that really need the permissions and just those specific permissions to just those specific people, we will start training everyone to only put the data where it is really needed. Anyone with a really large DIT should sit down and look at what is in it and say, is it really necessary for all of this data to go where it goes? Is there additional exposure that I have for putting it there that isn't necessary? Brett, while we have your attention if we do... How about some training on max data stored per object. What are the limits that we will hit as we stuff more and more data into say every user object? I know I have found the magic admin limit exceeded when punching a bunch of data into a non-linked multivalue attribute and it causing me to not be able to add any new attributes to the same user object. What other limits are we going to see? Also, why do I see that admin limit on new attributes when the one single multivalue attribute get filled up? joe [1] I really am not an entirely negative person. I am best described as a optimistic pessimist. Hope for the best of all worlds but plan for the worst. I have also been called a Socialist because I am willing to buy a burger for a friend and a good conversation. ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 11:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/e se/por tal.asp This frequent confusion, is the reason we use the more
RE: [ActiveDir] Adding custom fields to AD
Ah, Brettsh, maybe that explains why I had trouble opening my Exchange 5.5 store with Access 97 ;) Rich -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 10:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese /portal.asp This frequent confusion, is the reason we use the more desired term, ESE. The two JETs once compatible at the top level API, have not even had to maintain API compatibility for nearly 10 years, so they are quite different. If the _active amount of data_ (and the active amount of data, can be grossly enlarged by bad queries) exceeds memory, some operations will probably be thrown down to random disk IO speed (100 IOs / second is a standard single spindle/disk) ... ergo you get slow quick. And like most database servers in such a situation, you can often throw hardware at it. We have Exchange servers with a TB of databases attached, and a much higher update rate, BUT a big SAN to satisfy the IO load. With AD you have the added advantage of being able to throw RAM at the situations, with a 64-bit native OS and 32 GBs of RAM, a 29 GB database performs quite well. So where AD caves in, is very hardware and workload dependant ... joe's production numbers aren't even interesting anymore. (implying many customers are in production with much bigger databases) ;-) Cheers, BrettSh [msft] JET Blue, not JET Red Developer. On Sat, 8 Oct 2005, Gil Kirkpatrick wrote: Much of AD's heritage lies in the old Exchange directory, which was ESE-based. -gil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, October 08, 2005 8:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What do you feel is wrong with ESE (aka Jet Blue)? What's the ceiling on actual database size before it caves in (performance-wise)? Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max pages [1]). As for when it caves perf wise from an AD standpoint it really depends on what you are doing with it and what you have indexed from what I have seen. If someone is issuing crappy inefficient queries it will seem to be pretty slow pretty fast with relatively little data. The largest DB I have seen in production has been ~20GB and that was with W2K on a GC and a bunch of that data shouldn't have been in the AD like duplicated ACEs and misc unneeded objects, etc. Going to K3 would probably reduce that DB to about 10-12GB or better due to single instance store, cleanup would reduce it even further. One Fortune 5 company I have worked with had a K3 GC DB in the area of 5GB and that was for some 250,000 users with Exchange and multiple custom attributes. joe [1] See the docs for JetCreateDatabase - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese /jet createdatabase.asp?frame=true -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 9:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all
RE: [ActiveDir] Adding custom fields to AD
Your blog link being what? :) :m:dsm:cci:mvp marcusoh.blogspot.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Monday, October 10, 2005 1:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Yes, I was hoping you wouldn't take it has who has a bigger database contest, that was not my intent. Besides it was really who has seen the bigger database, and who wants to admit that, you want to HAVE the bigger database. My databases aren't really that big, usually a smidgen over the default 10 MB size for testing, really quite small actually. As for the wondering what kind of crap is stuffed into the AD DB, I'd agree with you to some degree ... for corp / NOS type AD DBs ... but the ones I'm think of are almost always internet auth DBs, and have millions to 10s of millions of identities stored. Then the size starts to make sense. So you can imagine why they get big. And finally about the size limit on AD objects, how many attrs, multi-values, link values, etc, and such, I have a blog post planned about that ... actually 3 posts ... Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, joe wrote: Ah Brett, you incorrigible one, you misunderstand my point of posting those numbers It wasn't to say, look how big I have seen, but instead, look how big these companies are and they still have small DBs. When I hear of some giant DB I don't think wow, what a big DB, I think, what kind of sh*t is being thrown into that AD to bloat it to that extent[1]? I especially love hearing about companies that jam huge binaries into the directory like images that get replicated to the four corners of the earth and are only read by one program, a web app, in one or two of the company's datacenters. Great use of bandwidth. I also especially love seeing a crap load of data going into the directory for Exchange when Exchange is centralized, also great use of bandwidth. That site in South America or in Kuala Lumpur with 10 people and a GC because they have crappy connectivity certainly needs to have every object and the entire Exchange selection of data for the other 200,000 users. No possible issues in data theft there... I think after we get past the training of everyone to only grant permissions to those that really need the permissions and just those specific permissions to just those specific people, we will start training everyone to only put the data where it is really needed. Anyone with a really large DIT should sit down and look at what is in it and say, is it really necessary for all of this data to go where it goes? Is there additional exposure that I have for putting it there that isn't necessary? Brett, while we have your attention if we do... How about some training on max data stored per object. What are the limits that we will hit as we stuff more and more data into say every user object? I know I have found the magic admin limit exceeded when punching a bunch of data into a non-linked multivalue attribute and it causing me to not be able to add any new attributes to the same user object. What other limits are we going to see? Also, why do I see that admin limit on new attributes when the one single multivalue attribute get filled up? joe [1] I really am not an entirely negative person. I am best described as a optimistic pessimist. Hope for the best of all worlds but plan for the worst. I have also been called a Socialist because I am willing to buy a burger for a friend and a good conversation. ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 11:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese /por tal.asp This frequent confusion, is the reason we use the more desired term, ESE. The two JETs once compatible at the top level API, have not even had to maintain API compatibility for nearly 10 years, so they are quite different. If the _active amount of data_ (and the active amount of data, can be grossly enlarged by bad queries) exceeds memory, some operations will probably be thrown down to random disk IO speed (100 IOs / second is a standard single spindle/disk) ... ergo you get slow quick. And like most database servers in such a situation, you can often throw hardware at it. We have Exchange servers with a TB of databases attached, and a much higher update rate, BUT a big SAN to satisfy the IO load. With AD you have the added advantage of being
RE: [ActiveDir] Adding custom fields to AD
Heck NetBEUI with all broadcasts would work
perfectfor all internal SBS needs. :o)
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley,
CPA aka Ebitz - SBS Rocks [MVP]Sent: Monday, October 10, 2005 12:33
AMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir]
Adding custom fields to AD
coughI love DNS and AD and argue strongly for the
glue all the time. {example answer in SBS newsgroup to person not wanting
a domain."why in the WORLD do you want to run as workgroup? A domain
is just a workgroup with more toys!"}But then again I run insecure SBS
where our wizards set up the glue for us and we don't have to worry about
it.okay back to lurkingjoe wrote:
I don't think the rest of the planet loves DNS, I think a
lot of people put up with it as a necessary evil due to exactly the reason you
state. There isn't even a viable option on the table. WINS simply won't scale
due to the lack of hierarchy. I myself also realize that it is a necessary
evil but it doesn't mean I have to necessarily like it. ;o) I certainly
don't like managing it nor running it as integrated into the AD itself. The
fact that AD is critically dependent on a service that it itself provides
smacks my internal like it or hate it sensors about. I am very much
pro-someone else running DNS properlyand I run AD properly.
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Rick KingslanSent: Sunday, October 09, 2005
11:31 AMTo: ActiveDir@mail.activedir.orgSubject:
RE: [ActiveDir] Adding custom fields to AD
"what would you think would be a good
replacement for dns/wins?"
There currently isn't one. Not really even a
viable option on the table. joe doesn't like DNS. The rest of the
planet loves DNS- including those eggheads (loveable eggheads that they
are) at IETF are the holders of the standards, and they love DNS too.
:-)
Microsoft fought hard to get TO standards cooperation
. Don't look for anything in the near future to break away from that in
regards to DNS.
Rick
--Posting is provided "AS IS", and confers no rights or
warranties ...
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]
On Behalf Of Tom KernSent: Saturday, October 08, 2005 4:44
PMTo: ActiveDir@mail.activedir.orgSubject:
Re: [ActiveDir] Adding custom fields to AD
I've had the reverse-
last place i worked at had corrupted WINS at least once every 2
months(this could of been due to my lousy admin skills)
i've never had issues with dns(could be my dumb luck)
now i work for a corp that has netbios/tcp disabled and relies solely on
dns(both MS and BIND) with no name resolution issues.
also wins replication seems much more complex than standard
primary/secondarydns replication.
and i'm not one to think i know anything as an admin or would even think
of getting into such a disscussion with someone as experienced and knowldgable
as you, but i've always found dns easier than wins and netbios names in
general.
my only diffculty came with learning dns on BIND/Linux and just wrapping
my head around AD intergrated dns when i first came to Windows.
sometimes when you learn something via the command line, using the gui
just confuses things.
then again i'm probably one of those guys who "thinks" he knows dns but
really doesn't know anything and hasen't found out yet :(
what would you think would be a good replacement for dns/wins?
thanks
On 10/8/05, joe
[EMAIL PROTECTED]
wrote:
I wasn't saying I like WINS better than DNS or vice versa, just
said I don't like DNS. I especially dislike the AD/DNS integration. I don't
like chicken and egg problems.
BTW, as you
bring up WINS. 1. I've never had a corrupted WINS Database. 2.
Fewer admins had name resolution issues replication based issues with WINS
than they do with DNS. 3. The complexity ofDNS seems to put many
admins off the deep end, interestingly enough, the same admins who said they
couldn't figure out WINS say they know all about DNS.
But again, my
comment wasn't I like WINS more than DNS, or I like any name resolution
systems better than DNS, it was simply I don't like DNS.
From: [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]] On Behalf Of Tom
KernSent: Saturday, October 08, 2005 12:42 PM
To: ActiveDir@mail.activedir.orgSubject: Re:
[ActiveDir] Adding custom fields to
AD
ok, i'll bite.
GPO's, i understand but whats there to hate about DNS?
its better than WINS.
I've never had a corrputed dns database.
thanks
On 10/8/05, joe
[EMAIL PROTECTED] wrote:
Yeah,
GPOs aren't AD. GPOs are an application that use AD. I hate GPOs.
DNStoo.:o)-Original Message-From: [
RE: [ActiveDir] Adding custom fields to AD
You are holding onto that 3.50 functionality anger much too long Darren -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Monday, October 10, 2005 12:51 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD In the NT 3.50 days, WINS was a mess. I'm sorry but no amount of good design would help it. It just sucked. It got progressively better in NT 4.0 but I saw lots of corruptions of many kinds in 3.5x and I knew a thing or two about WINS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, October 09, 2005 8:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I would guess that it never got that far. My experience with folks troubleshooting WINS is that they don't look very deep, someone can't resolve XYZ server name and they stop the service, delete the DB, and repopulate and call the DB corrupt. I think I said this in another post but I have never seen a corrupt WINS DB though I have had lots of people tell me that WINS was corrupt. I have seen lots of dorked up individual entries and simply deleting that entry and reregistering gets everything working fine again. The worst cases I have seen have been really poorly configured SAMBA machines stomping on domain records though I once heard of a really misconfigured Windows machine knocking a Fortune 50 down for a bit because someone built there own domain with the same domain name as the corporate domain and registered it in the production WINS environment. The solution there ended up being shut down WINS and deleting the WINS DB and letting it rebuild... joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 8:24 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Tom Kern *Sent:* Saturday, October 08, 2005 12:42 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL
RE: [ActiveDir] Adding custom fields to AD
Ah true, I didn't think uses of ADAM which I think may make more sense than AD for some of those internet uses. So do we have a timeline on these blog entries? eg -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Monday, October 10, 2005 1:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Yes, I was hoping you wouldn't take it has who has a bigger database contest, that was not my intent. Besides it was really who has seen the bigger database, and who wants to admit that, you want to HAVE the bigger database. My databases aren't really that big, usually a smidgen over the default 10 MB size for testing, really quite small actually. As for the wondering what kind of crap is stuffed into the AD DB, I'd agree with you to some degree ... for corp / NOS type AD DBs ... but the ones I'm think of are almost always internet auth DBs, and have millions to 10s of millions of identities stored. Then the size starts to make sense. So you can imagine why they get big. And finally about the size limit on AD objects, how many attrs, multi-values, link values, etc, and such, I have a blog post planned about that ... actually 3 posts ... Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, joe wrote: Ah Brett, you incorrigible one, you misunderstand my point of posting those numbers It wasn't to say, look how big I have seen, but instead, look how big these companies are and they still have small DBs. When I hear of some giant DB I don't think wow, what a big DB, I think, what kind of sh*t is being thrown into that AD to bloat it to that extent[1]? I especially love hearing about companies that jam huge binaries into the directory like images that get replicated to the four corners of the earth and are only read by one program, a web app, in one or two of the company's datacenters. Great use of bandwidth. I also especially love seeing a crap load of data going into the directory for Exchange when Exchange is centralized, also great use of bandwidth. That site in South America or in Kuala Lumpur with 10 people and a GC because they have crappy connectivity certainly needs to have every object and the entire Exchange selection of data for the other 200,000 users. No possible issues in data theft there... I think after we get past the training of everyone to only grant permissions to those that really need the permissions and just those specific permissions to just those specific people, we will start training everyone to only put the data where it is really needed. Anyone with a really large DIT should sit down and look at what is in it and say, is it really necessary for all of this data to go where it goes? Is there additional exposure that I have for putting it there that isn't necessary? Brett, while we have your attention if we do... How about some training on max data stored per object. What are the limits that we will hit as we stuff more and more data into say every user object? I know I have found the magic admin limit exceeded when punching a bunch of data into a non-linked multivalue attribute and it causing me to not be able to add any new attributes to the same user object. What other limits are we going to see? Also, why do I see that admin limit on new attributes when the one single multivalue attribute get filled up? joe [1] I really am not an entirely negative person. I am best described as a optimistic pessimist. Hope for the best of all worlds but plan for the worst. I have also been called a Socialist because I am willing to buy a burger for a friend and a good conversation. ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 11:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/e se/por tal.asp This frequent confusion, is the reason we use the more desired term, ESE. The two JETs once compatible at the top level API, have not even had to maintain API compatibility for nearly 10 years, so they are quite different. If the _active amount of data_ (and the active amount of data, can be grossly enlarged by bad queries) exceeds memory, some operations will probably be thrown down to random disk IO speed (100 IOs / second is a standard single spindle/disk) ... ergo you get slow quick. And like most database servers in such a situation, you can often throw hardware at it. We have Exchange servers with a TB of databases
RE: [ActiveDir] Adding custom fields to AD
http://blogs.msdn.com/brettsh/ I would post a comment to the blog, but it requires a post first. :) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, October 10, 2005 10:05 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Your blog link being what? :) :m:dsm:cci:mvp marcusoh.blogspot.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Monday, October 10, 2005 1:32 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Yes, I was hoping you wouldn't take it has who has a bigger database contest, that was not my intent. Besides it was really who has seen the bigger database, and who wants to admit that, you want to HAVE the bigger database. My databases aren't really that big, usually a smidgen over the default 10 MB size for testing, really quite small actually. As for the wondering what kind of crap is stuffed into the AD DB, I'd agree with you to some degree ... for corp / NOS type AD DBs ... but the ones I'm think of are almost always internet auth DBs, and have millions to 10s of millions of identities stored. Then the size starts to make sense. So you can imagine why they get big. And finally about the size limit on AD objects, how many attrs, multi-values, link values, etc, and such, I have a blog post planned about that ... actually 3 posts ... Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, joe wrote: Ah Brett, you incorrigible one, you misunderstand my point of posting those numbers It wasn't to say, look how big I have seen, but instead, look how big these companies are and they still have small DBs. When I hear of some giant DB I don't think wow, what a big DB, I think, what kind of sh*t is being thrown into that AD to bloat it to that extent[1]? I especially love hearing about companies that jam huge binaries into the directory like images that get replicated to the four corners of the earth and are only read by one program, a web app, in one or two of the company's datacenters. Great use of bandwidth. I also especially love seeing a crap load of data going into the directory for Exchange when Exchange is centralized, also great use of bandwidth. That site in South America or in Kuala Lumpur with 10 people and a GC because they have crappy connectivity certainly needs to have every object and the entire Exchange selection of data for the other 200,000 users. No possible issues in data theft there... I think after we get past the training of everyone to only grant permissions to those that really need the permissions and just those specific permissions to just those specific people, we will start training everyone to only put the data where it is really needed. Anyone with a really large DIT should sit down and look at what is in it and say, is it really necessary for all of this data to go where it goes? Is there additional exposure that I have for putting it there that isn't necessary? Brett, while we have your attention if we do... How about some training on max data stored per object. What are the limits that we will hit as we stuff more and more data into say every user object? I know I have found the magic admin limit exceeded when punching a bunch of data into a non-linked multivalue attribute and it causing me to not be able to add any new attributes to the same user object. What other limits are we going to see? Also, why do I see that admin limit on new attributes when the one single multivalue attribute get filled up? joe [1] I really am not an entirely negative person. I am best described as a optimistic pessimist. Hope for the best of all worlds but plan for the worst. I have also been called a Socialist because I am willing to buy a burger for a friend and a good conversation. ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 11:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese /por tal.asp This frequent confusion, is the reason we use the more desired term, ESE. The two JETs once compatible at the top level API, have not even had to maintain API compatibility for nearly 10 years, so they are quite different. If the _active amount of data_ (and the active amount of data, can be grossly enlarged by bad queries) exceeds memory, some operations will probably be thrown down to random disk IO speed (100
Re: [ActiveDir] Adding custom fields to AD
:-P
I think someone needs to run SBS at home. See what nice solid DNS/AD is
all about :-)
lurk mode back on
joe wrote:
Heck NetBEUI with all broadcasts would work perfect for all internal
SBS needs. :o)
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Susan
Bradley, CPA aka Ebitz - SBS Rocks [MVP]
*Sent:* Monday, October 10, 2005 12:33 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Adding custom fields to AD
cough
I love DNS and AD and argue strongly for the glue all the time.
{example answer in SBS newsgroup to person not wanting a
domain.why in the WORLD do you want to run as workgroup? A
domain is just a workgroup with more toys!}
But then again I run insecure SBS where our wizards set up the glue
for us and we don't have to worry about it.
okay back to lurking
joe wrote:
I don't think the rest of the planet loves DNS, I think a lot of
people put up with it as a necessary evil due to exactly the reason
you state. There isn't even a viable option on the table. WINS simply
won't scale due to the lack of hierarchy. I myself also realize that
it is a necessary evil but it doesn't mean I have to necessarily like
it. ;o) I certainly don't like managing it nor running it as
integrated into the AD itself. The fact that AD is critically
dependent on a service that it itself provides smacks my internal
like it or hate it sensors about. I am very much pro-someone else
running DNS properly and I run AD properly.
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Rick Kingslan
*Sent:* Sunday, October 09, 2005 11:31 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Adding custom fields to AD
what would you think would be a good replacement for dns/wins?
There currently isn't one. Not really even a viable option on the
table. joe doesn't like DNS. The rest of the planet loves DNS -
including those eggheads (loveable eggheads that they are) at IETF
are the holders of the standards, and they love DNS too. :-)
Microsoft fought hard to get TO standards cooperation . Don't look
for anything in the near future to break away from that in regards to
DNS.
Rick
--
Posting is provided AS IS, and confers no rights or warranties ...
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Tom Kern
*Sent:* Saturday, October 08, 2005 4:44 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Adding custom fields to AD
I've had the reverse-
last place i worked at had corrupted WINS at least once every 2
months(this could of been due to my lousy admin skills)
i've never had issues with dns(could be my dumb luck)
now i work for a corp that has netbios/tcp disabled and relies solely
on dns(both MS and BIND) with no name resolution issues.
also wins replication seems much more complex than standard
primary/secondary dns replication.
and i'm not one to think i know anything as an admin or would even
think of getting into such a disscussion with someone as experienced
and knowldgable as you, but i've always found dns easier than wins
and netbios names in general.
my only diffculty came with learning dns on BIND/Linux and just
wrapping my head around AD intergrated dns when i first came to Windows.
sometimes when you learn something via the command line, using the
gui just confuses things.
then again i'm probably one of those guys who thinks he knows dns
but really doesn't know anything and hasen't found out yet :(
what would you think would be a good replacement for dns/wins?
thanks
On 10/8/05, *joe* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I wasn't saying I like WINS better than DNS or vice versa, just
said I don't like DNS. I especially dislike the AD/DNS
integration. I don't like chicken and egg problems.
BTW, as you bring up WINS. 1. I've never had a corrupted WINS
Database. 2. Fewer admins had name resolution issues replication
based issues with WINS than they do with DNS. 3. The complexity
of DNS seems to put many admins off the deep end, interestingly
enough, the same admins who said they couldn't figure out WINS
say they know all about DNS.
But again, my comment wasn't I like WINS more than DNS, or I like
any name resolution systems better than DNS, it was simply I
don't like DNS.
*From:* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]] *On Behalf Of *Tom Kern
*Sent:* Saturday, October 08, 2005 12:42 PM
*To:* ActiveDir@mail.activedir.org
mailto:ActiveDir@mail.activedir.org
*Subject: *Re
RE: [ActiveDir] Adding custom fields to AD
Won't work for me. I have about 50,000 users in my home AD on about 3
domains and 8 DCs... Oh I also have trusts to a couple of R2 and NT4
Domains. eg
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Susan Bradley, CPA
aka Ebitz - SBS Rocks [MVP]
Sent: Monday, October 10, 2005 3:05 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Adding custom fields to AD
:-P
I think someone needs to run SBS at home. See what nice solid DNS/AD is all
about :-)
lurk mode back on
joe wrote:
Heck NetBEUI with all broadcasts would work perfect for all internal
SBS needs. :o)
--
--
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Susan
Bradley, CPA aka Ebitz - SBS Rocks [MVP]
*Sent:* Monday, October 10, 2005 12:33 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Adding custom fields to AD
cough
I love DNS and AD and argue strongly for the glue all the time.
{example answer in SBS newsgroup to person not wanting a
domain.why in the WORLD do you want to run as workgroup? A
domain is just a workgroup with more toys!}
But then again I run insecure SBS where our wizards set up the glue
for us and we don't have to worry about it.
okay back to lurking
joe wrote:
I don't think the rest of the planet loves DNS, I think a lot of
people put up with it as a necessary evil due to exactly the reason
you state. There isn't even a viable option on the table. WINS simply
won't scale due to the lack of hierarchy. I myself also realize that
it is a necessary evil but it doesn't mean I have to necessarily like
it. ;o) I certainly don't like managing it nor running it as
integrated into the AD itself. The fact that AD is critically
dependent on a service that it itself provides smacks my internal
like it or hate it sensors about. I am very much pro-someone else
running DNS properly and I run AD properly.
-
---
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Rick
Kingslan
*Sent:* Sunday, October 09, 2005 11:31 AM
*To:* ActiveDir@mail.activedir.org
*Subject:* RE: [ActiveDir] Adding custom fields to AD
what would you think would be a good replacement for dns/wins?
There currently isn't one. Not really even a viable option on the
table. joe doesn't like DNS. The rest of the planet loves DNS -
including those eggheads (loveable eggheads that they are) at IETF
are the holders of the standards, and they love DNS too. :-)
Microsoft fought hard to get TO standards cooperation . Don't look
for anything in the near future to break away from that in regards to
DNS.
Rick
--
Posting is provided AS IS, and confers no rights or warranties ...
-
---
*From:* [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] *On Behalf Of *Tom Kern
*Sent:* Saturday, October 08, 2005 4:44 PM
*To:* ActiveDir@mail.activedir.org
*Subject:* Re: [ActiveDir] Adding custom fields to AD
I've had the reverse-
last place i worked at had corrupted WINS at least once every 2
months(this could of been due to my lousy admin skills) i've never
had issues with dns(could be my dumb luck) now i work for a corp that
has netbios/tcp disabled and relies solely on dns(both MS and BIND)
with no name resolution issues.
also wins replication seems much more complex than standard
primary/secondary dns replication.
and i'm not one to think i know anything as an admin or would even
think of getting into such a disscussion with someone as experienced
and knowldgable as you, but i've always found dns easier than wins
and netbios names in general.
my only diffculty came with learning dns on BIND/Linux and just
wrapping my head around AD intergrated dns when i first came to Windows.
sometimes when you learn something via the command line, using the
gui just confuses things.
then again i'm probably one of those guys who thinks he knows dns
but really doesn't know anything and hasen't found out yet :(
what would you think would be a good replacement for dns/wins?
thanks
On 10/8/05, *joe* [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I wasn't saying I like WINS better than DNS or vice versa, just
said I don't like DNS. I especially dislike the AD/DNS
integration. I don't like chicken and egg problems.
BTW, as you bring up WINS. 1. I've never had a corrupted WINS
Database. 2. Fewer admins had name resolution issues replication
based issues with WINS than they do with DNS. 3. The complexity
of DNS seems to put many admins off the deep end, interestingly
enough, the same admins who said they couldn't figure out WINS
say they know all about DNS.
But again, my comment
RE: [ActiveDir] Adding custom fields to AD
A lot of things sucked with NT 3.50. Ed Crowley MCSE+Internet MVP Freelance E-Mail Philosopher Protecting the world from PSTs and Bricked Backups!T -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-Elia Sent: Sunday, October 09, 2005 9:51 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD In the NT 3.50 days, WINS was a mess. I'm sorry but no amount of good design would help it. It just sucked. It got progressively better in NT 4.0 but I saw lots of corruptions of many kinds in 3.5x and I knew a thing or two about WINS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, October 09, 2005 8:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I would guess that it never got that far. My experience with folks troubleshooting WINS is that they don't look very deep, someone can't resolve XYZ server name and they stop the service, delete the DB, and repopulate and call the DB corrupt. I think I said this in another post but I have never seen a corrupt WINS DB though I have had lots of people tell me that WINS was corrupt. I have seen lots of dorked up individual entries and simply deleting that entry and reregistering gets everything working fine again. The worst cases I have seen have been really poorly configured SAMBA machines stomping on domain records though I once heard of a really misconfigured Windows machine knocking a Fortune 50 down for a bit because someone built there own domain with the same domain name as the corporate domain and registered it in the production WINS environment. The solution there ended up being shut down WINS and deleting the WINS DB and letting it rebuild... joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 8:24 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Tom Kern *Sent:* Saturday, October 08, 2005 12:42 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too
Re: [ActiveDir] Adding custom fields to AD
Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Tom Kern *Sent:* Saturday, October 08, 2005 12:42 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Mylo Sent
RE: [ActiveDir] Adding custom fields to AD
Yur just a problem child. -r -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, October 08, 2005 10:40 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible
RE: [ActiveDir] Adding custom fields to AD
"what would you think would be a good replacement for dns/wins?" There currently isn't one. Not really even a viable option on the table. joe doesn't like DNS. The rest of the planet loves DNS- including those eggheads (loveable eggheads that they are) at IETF are the holders of the standards, and they love DNS too. :-) Microsoft fought hard to get TO standards cooperation . Don't look for anything in the near future to break away from that in regards to DNS. Rick --Posting is provided "AS IS", and confers no rights or warranties ... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, October 08, 2005 4:44 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondarydns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who "thinks" he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o)-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very
RE: [ActiveDir] Adding custom fields to AD
So for those organizations that have exchange deployed... how do you make the argument to shove things into adam? Exchange would have been the perfect application to shove into adam. :m:dsm:cci:mvp marcusoh.blogspot.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications
RE: [ActiveDir] Adding custom fields to AD
I agree with you that WINS has largely had a bad rap. Every WINS problem I've seen has been poor architecture or administrative practices. Ed Crowley MCSE+Internet MVPFreelance E-Mail PhilosopherProtecting the world from PSTs and Bricked Backups! From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Saturday, October 08, 2005 2:18 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o)-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick KingslanSent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to ADInteresting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworksstuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning).One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)?Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider addingthe data to AD.IF the data is going to be needed only at a couple of sites or a singlesite, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAPdoesn't support.There is also the possibility of using app partitions but if you weregoing to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD isbecoming, in many companies, a dumping ground of all the crap
RE: [ActiveDir] Adding custom fields to AD
I would guess that it never got that far. My experience with folks troubleshooting WINS is that they don't look very deep, someone can't resolve XYZ server name and they stop the service, delete the DB, and repopulate and call the DB corrupt. I think I said this in another post but I have never seen a corrupt WINS DB though I have had lots of people tell me that WINS was corrupt. I have seen lots of dorked up individual entries and simply deleting that entry and reregistering gets everything working fine again. The worst cases I have seen have been really poorly configured SAMBA machines stomping on domain records though I once heard of a really misconfigured Windows machine knocking a Fortune 50 down for a bit because someone built there own domain with the same domain name as the corporate domain and registered it in the production WINS environment. The solution there ended up being shut down WINS and deleting the WINS DB and letting it rebuild... joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 8:24 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Tom Kern *Sent:* Saturday, October 08, 2005 12:42 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one
RE: [ActiveDir] Adding custom fields to AD
I don't think the rest of the planet loves DNS, I think a lot of people put up with it as a necessary evil due to exactly the reason you state. There isn't even a viable option on the table. WINS simply won't scale due to the lack of hierarchy. I myself also realize that it is a necessary evil but it doesn't mean I have to necessarily like it. ;o) I certainly don't like managing it nor running it as integrated into the AD itself. The fact that AD is critically dependent on a service that it itself provides smacks my internal like it or hate it sensors about. I am very much pro-someone else running DNS properlyand I run AD properly. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick KingslanSent: Sunday, October 09, 2005 11:31 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD "what would you think would be a good replacement for dns/wins?" There currently isn't one. Not really even a viable option on the table. joe doesn't like DNS. The rest of the planet loves DNS- including those eggheads (loveable eggheads that they are) at IETF are the holders of the standards, and they love DNS too. :-) Microsoft fought hard to get TO standards cooperation . Don't look for anything in the near future to break away from that in regards to DNS. Rick --Posting is provided "AS IS", and confers no rights or warranties ... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, October 08, 2005 4:44 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondarydns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who "thinks" he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o)-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority
RE: [ActiveDir] Adding custom fields to AD
Absolutely perfect, at least for some of the data such as the config info. I personally also think the user data could be there too with links back to the AD principals but many would argue against that. An issue with ADAM though is that it doesn't implement all of the interfaces needed for Exchange, or at least the Exchange/Outlook dance. Outlook now and I believe still (unbelievably) in O12 requires NSPI which is only available from Global Catalogs and 5.5 servers. The special Exchange AB functionality doesn't exist (as it should be IMO) in ADAM. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Sunday, October 09, 2005 8:16 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD So for those organizations that have exchange deployed... how do you make the argument to shove things into adam? Exchange would have been the perfect application to shove into adam. :m:dsm:cci:mvp marcusoh.blogspot.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked
RE: [ActiveDir] Adding custom fields to AD
Ah Brett, you incorrigible one, you misunderstand my point of posting those numbers It wasn't to say, look how big I have seen, but instead, look how big these companies are and they still have small DBs. When I hear of some giant DB I don't think wow, what a big DB, I think, what kind of sh*t is being thrown into that AD to bloat it to that extent[1]? I especially love hearing about companies that jam huge binaries into the directory like images that get replicated to the four corners of the earth and are only read by one program, a web app, in one or two of the company's datacenters. Great use of bandwidth. I also especially love seeing a crap load of data going into the directory for Exchange when Exchange is centralized, also great use of bandwidth. That site in South America or in Kuala Lumpur with 10 people and a GC because they have crappy connectivity certainly needs to have every object and the entire Exchange selection of data for the other 200,000 users. No possible issues in data theft there... I think after we get past the training of everyone to only grant permissions to those that really need the permissions and just those specific permissions to just those specific people, we will start training everyone to only put the data where it is really needed. Anyone with a really large DIT should sit down and look at what is in it and say, is it really necessary for all of this data to go where it goes? Is there additional exposure that I have for putting it there that isn't necessary? Brett, while we have your attention if we do... How about some training on max data stored per object. What are the limits that we will hit as we stuff more and more data into say every user object? I know I have found the magic admin limit exceeded when punching a bunch of data into a non-linked multivalue attribute and it causing me to not be able to add any new attributes to the same user object. What other limits are we going to see? Also, why do I see that admin limit on new attributes when the one single multivalue attribute get filled up? joe [1] I really am not an entirely negative person. I am best described as a optimistic pessimist. Hope for the best of all worlds but plan for the worst. I have also been called a Socialist because I am willing to buy a burger for a friend and a good conversation. ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 11:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese/por tal.asp This frequent confusion, is the reason we use the more desired term, ESE. The two JETs once compatible at the top level API, have not even had to maintain API compatibility for nearly 10 years, so they are quite different. If the _active amount of data_ (and the active amount of data, can be grossly enlarged by bad queries) exceeds memory, some operations will probably be thrown down to random disk IO speed (100 IOs / second is a standard single spindle/disk) ... ergo you get slow quick. And like most database servers in such a situation, you can often throw hardware at it. We have Exchange servers with a TB of databases attached, and a much higher update rate, BUT a big SAN to satisfy the IO load. With AD you have the added advantage of being able to throw RAM at the situations, with a 64-bit native OS and 32 GBs of RAM, a 29 GB database performs quite well. So where AD caves in, is very hardware and workload dependant ... joe's production numbers aren't even interesting anymore. (implying many customers are in production with much bigger databases) ;-) Cheers, BrettSh [msft] JET Blue, not JET Red Developer. On Sat, 8 Oct 2005, Gil Kirkpatrick wrote: Much of AD's heritage lies in the old Exchange directory, which was ESE-based. -gil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, October 08, 2005 8:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What do you feel is wrong with ESE (aka Jet Blue)? What's the ceiling on actual database size before it caves in (performance-wise)? Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max pages [1]). As for when it caves perf wise from an AD standpoint it really depends on what you are doing with it and what you have indexed from what I have seen. If someone is issuing crappy inefficient queries it will seem to be pretty slow pretty fast
RE: [ActiveDir] Adding custom fields to AD
I am not certain I would like to use hosts, but I do think it would be nice if I could put in SRV records into hosts files IF I wanted to use them. I know having the LMHOSTS file as a backup to WINS always gave me a warm fuzzy feeling even if I wasn't having WINS issues. It can be a pain to manage, but that is like any management issue, it can be... Well managed if you are doing your job properly. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Saturday, October 08, 2005 5:40 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD I used to work at a place where WINS and DNS were used. IMO, WINS was faster in resolution and *just* worked but is not standard as DNS resolution is. DNS integration with AD is a pain and can be a hassle when troubleshooting, sometimes doing a ipconfig /flush client and flushing the DNS on the DC's to resolve an issue. SP1 has several fixes for w2k3 DNS but I'm sure something else will come up. :) I say we just use hosts files again. :( Steve - Original Message - From: joe [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Saturday, October 08, 2005 5:18 PM Subject: RE: [ActiveDir] Adding custom fields to AD I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though
RE: [ActiveDir] Adding custom fields to AD
Tuppence follows ... although I don't represent anything like the rest of the planet, FWIW I do indeed very much like DNS (love is perhaps a tad overboard). --Dean WellsMSEtechnology* Email: dwells@msetechnology.comhttp://msetechnology.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Sunday, October 09, 2005 8:52 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD I don't think the rest of the planet loves DNS, I think a lot of people put up with it as a necessary evil due to exactly the reason you state. There isn't even a viable option on the table. WINS simply won't scale due to the lack of hierarchy. I myself also realize that it is a necessary evil but it doesn't mean I have to necessarily like it. ;o) I certainly don't like managing it nor running it as integrated into the AD itself. The fact that AD is critically dependent on a service that it itself provides smacks my internal like it or hate it sensors about. I am very much pro-someone else running DNS properlyand I run AD properly. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick KingslanSent: Sunday, October 09, 2005 11:31 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD "what would you think would be a good replacement for dns/wins?" There currently isn't one. Not really even a viable option on the table. joe doesn't like DNS. The rest of the planet loves DNS- including those eggheads (loveable eggheads that they are) at IETF are the holders of the standards, and they love DNS too. :-) Microsoft fought hard to get TO standards cooperation . Don't look for anything in the near future to break away from that in regards to DNS. Rick --Posting is provided "AS IS", and confers no rights or warranties ... From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, October 08, 2005 4:44 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondarydns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who "thinks" he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o)-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and
Re: [ActiveDir] Adding custom fields to AD
cough
I love DNS and AD and argue strongly for the glue all the time.
{example answer in SBS newsgroup to person not wanting a
domain."why in the WORLD do you want to run as workgroup? A domain
is just a workgroup with more toys!"}
But then again I run insecure SBS where our wizards set up the glue for
us and we don't have to worry about it.
okay back to lurking
joe wrote:
I don't think the rest of the
planet loves DNS, I think a lot of people put up with it as a necessary
evil due to exactly the reason you state. There isn't even a viable
option on the table. WINS simply won't scale due to the lack of
hierarchy. I myself also realize that it is a necessary evil but it
doesn't mean I have to necessarily like it. ;o) I certainly don't like
managing it nor running it as integrated into the AD itself. The fact
that AD is critically dependent on a service that it itself provides
smacks my internal like it or hate it sensors about. I am very much
pro-someone else running DNS properlyand I run AD properly.
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Rick
Kingslan
Sent: Sunday, October 09, 2005 11:31 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Adding custom fields to AD
"what would you think would be a
good replacement for dns/wins?"
There currently isn't one. Not really even
a viable option on the table. joe doesn't like DNS. The rest of the
planet loves DNS- including those eggheads (loveable eggheads that
they are) at IETF are the holders of the standards, and they love DNS
too. :-)
Microsoft fought hard to get TO standards
cooperation . Don't look for anything in the near future to break away
from that in regards to DNS.
Rick
--
Posting is provided "AS IS", and confers no rights or warranties ...
From:
[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Tom
Kern
Sent: Saturday, October 08, 2005 4:44 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Adding custom fields to AD
I've had the reverse-
last place i worked at had corrupted WINS at least once every 2
months(this could of been due to my lousy admin skills)
i've never had issues with dns(could be my dumb luck)
now i work for a corp that has netbios/tcp disabled and relies
solely on dns(both MS and BIND) with no name resolution issues.
also wins replication seems much more complex than standard
primary/secondarydns replication.
and i'm not one to think i know anything as an admin or would
even think of getting into such a disscussion with someone as
experienced and knowldgable as you, but i've always found dns easier
than wins and netbios names in general.
my only diffculty came with learning dns on BIND/Linux and just
wrapping my head around AD intergrated dns when i first came to Windows.
sometimes when you learn something via the command line, using
the gui just confuses things.
then again i'm probably one of those guys who "thinks" he knows
dns but really doesn't know anything and hasen't found out yet :(
what would you think would be a good replacement for dns/wins?
thanks
On 10/8/05, joe [EMAIL PROTECTED] wrote:
I wasn't saying I like WINS better than DNS or vice
versa, just said I don't like DNS. I especially dislike the AD/DNS
integration. I don't like chicken and egg problems.
BTW,
as you bring up WINS. 1. I've never had a corrupted WINS Database.
2. Fewer admins had name resolution issues replication based issues
with WINS than they do with DNS. 3. The complexity ofDNS seems to put
many admins off the deep end, interestingly enough, the same admins who
said they couldn't figure out WINS say they know all about DNS.
But
again, my comment wasn't I like WINS more than DNS, or I like any name
resolution systems better than DNS, it was simply I don't like DNS.
From: [EMAIL PROTECTED]
[mailto:
[EMAIL PROTECTED]] On Behalf Of Tom Kern
Sent: Saturday, October 08, 2005 12:42 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Adding custom fields to AD
ok, i'll bite.
GPO's, i understand but whats there to hate about DNS?
its better than WINS.
I've never had a corrputed dns database.
thanks
On 10/8/05, joe [EMAIL PROTECTED]
wrote:
Yeah,
GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS
too.
:o)
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]
] On Behalf Of Rick Kingslan
Sent: Saturday, October 08, 2005 11:19 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Adding custom fields to AD
Interesting question - and as to the 'implode point' for ESE/Jet Blue,
Brettsh can answer that one.I'm pretty sure that we have a good idea
on
where the point of diminishing returns is, but
RE: [ActiveDir] Adding custom fields to AD
In the NT 3.50 days, WINS was a mess. I'm sorry but no amount of good design would help it. It just sucked. It got progressively better in NT 4.0 but I saw lots of corruptions of many kinds in 3.5x and I knew a thing or two about WINS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, October 09, 2005 8:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I would guess that it never got that far. My experience with folks troubleshooting WINS is that they don't look very deep, someone can't resolve XYZ server name and they stop the service, delete the DB, and repopulate and call the DB corrupt. I think I said this in another post but I have never seen a corrupt WINS DB though I have had lots of people tell me that WINS was corrupt. I have seen lots of dorked up individual entries and simply deleting that entry and reregistering gets everything working fine again. The worst cases I have seen have been really poorly configured SAMBA machines stomping on domain records though I once heard of a really misconfigured Windows machine knocking a Fortune 50 down for a bit because someone built there own domain with the same domain name as the corporate domain and registered it in the production WINS environment. The solution there ended up being shut down WINS and deleting the WINS DB and letting it rebuild... joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 8:24 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. -- *From:* [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] *On Behalf Of *Tom Kern *Sent:* Saturday, October 08, 2005 12:42 PM *To:* ActiveDir@mail.activedir.org *Subject:* Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer
RE: [ActiveDir] Adding custom fields to AD
That is entirely believable (about WINS being a mess). JET Blue used to suck. In Win2k, finally the older JET Blue 200 / 400 series was replaced by the version (ESE97) that underwent the top-to-bottom rewrite during Exch 5.5. That is why I asked if it was a 4.0 NT server. I'm not interested in chasing down a corruption bug in old JET 400, but if there are consistent corruptions in ESE 97+ variants, I'm curious to know how they're showing up. If it's in ESE98+ I'm especially curious ... or at least as curious as time allows. That said, joe's comment about how WINS admins treat thier servers is very interesting, I'll have to keep that in mind when people claim such a server is corrupt. Thanks joe for the info! BTW, I don't think WINS was even in NT 3.50, I thought it showed up in 3.51? Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, Darren Mar-Elia wrote: In the NT 3.50 days, WINS was a mess. I'm sorry but no amount of good design would help it. It just sucked. It got progressively better in NT 4.0 but I saw lots of corruptions of many kinds in 3.5x and I knew a thing or two about WINS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, October 09, 2005 8:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I would guess that it never got that far. My experience with folks troubleshooting WINS is that they don't look very deep, someone can't resolve XYZ server name and they stop the service, delete the DB, and repopulate and call the DB corrupt. I think I said this in another post but I have never seen a corrupt WINS DB though I have had lots of people tell me that WINS was corrupt. I have seen lots of dorked up individual entries and simply deleting that entry and reregistering gets everything working fine again. The worst cases I have seen have been really poorly configured SAMBA machines stomping on domain records though I once heard of a really misconfigured Windows machine knocking a Fortune 50 down for a bit because someone built there own domain with the same domain name as the corporate domain and registered it in the production WINS environment. The solution there ended up being shut down WINS and deleting the WINS DB and letting it rebuild... joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 8:24 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I
RE: [ActiveDir] Adding custom fields to AD
Someone told me offline, they think I'm wrong about WINS not being in 3.50. Hmmm, was it DHCP that didn't exist til 3.51? Maybe RPL? Maybe WINS just wasn't JET Blue based until then? H, now I'm all curious. Cheers, -BrettSh [msft] On Sun, 9 Oct 2005, Brett Shirley wrote: That is entirely believable (about WINS being a mess). JET Blue used to suck. In Win2k, finally the older JET Blue 200 / 400 series was replaced by the version (ESE97) that underwent the top-to-bottom rewrite during Exch 5.5. That is why I asked if it was a 4.0 NT server. I'm not interested in chasing down a corruption bug in old JET 400, but if there are consistent corruptions in ESE 97+ variants, I'm curious to know how they're showing up. If it's in ESE98+ I'm especially curious ... or at least as curious as time allows. That said, joe's comment about how WINS admins treat thier servers is very interesting, I'll have to keep that in mind when people claim such a server is corrupt. Thanks joe for the info! BTW, I don't think WINS was even in NT 3.50, I thought it showed up in 3.51? Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, Darren Mar-Elia wrote: In the NT 3.50 days, WINS was a mess. I'm sorry but no amount of good design would help it. It just sucked. It got progressively better in NT 4.0 but I saw lots of corruptions of many kinds in 3.5x and I knew a thing or two about WINS. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Sunday, October 09, 2005 8:52 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I would guess that it never got that far. My experience with folks troubleshooting WINS is that they don't look very deep, someone can't resolve XYZ server name and they stop the service, delete the DB, and repopulate and call the DB corrupt. I think I said this in another post but I have never seen a corrupt WINS DB though I have had lots of people tell me that WINS was corrupt. I have seen lots of dorked up individual entries and simply deleting that entry and reregistering gets everything working fine again. The worst cases I have seen have been really poorly configured SAMBA machines stomping on domain records though I once heard of a really misconfigured Windows machine knocking a Fortune 50 down for a bit because someone built there own domain with the same domain name as the corporate domain and registered it in the production WINS environment. The solution there ended up being shut down WINS and deleting the WINS DB and letting it rebuild... joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 8:24 AM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD Tom, what revision of the server OS was the WINS server? NT 4.0? Did you ever determine if the WINS DB corruptions were being exposed at the app/WINS level (esentutl /g succeeds) or ESE level (esentutl /g fails)? esentutl /g (the svc/DB must be offline for this) is the (slightly simplistic) method for determining if the corruption is exposing itself at the app logic level or the ESE level. Was the server being hard powered down (power outage)? Just curious. Cheers, -BrettSh [msft] - ESE Developer On Sat, 8 Oct 2005, Tom Kern wrote: I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondary dns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW
RE: [ActiveDir] Adding custom fields to AD
Yes, I was hoping you wouldn't take it has who has a bigger database contest, that was not my intent. Besides it was really who has seen the bigger database, and who wants to admit that, you want to HAVE the bigger database. My databases aren't really that big, usually a smidgen over the default 10 MB size for testing, really quite small actually. As for the wondering what kind of crap is stuffed into the AD DB, I'd agree with you to some degree ... for corp / NOS type AD DBs ... but the ones I'm think of are almost always internet auth DBs, and have millions to 10s of millions of identities stored. Then the size starts to make sense. So you can imagine why they get big. And finally about the size limit on AD objects, how many attrs, multi-values, link values, etc, and such, I have a blog post planned about that ... actually 3 posts ... Cheers, -BrettSh [msft] This posting is provided AS IS with no warranties, and confers no rights. On Sun, 9 Oct 2005, joe wrote: Ah Brett, you incorrigible one, you misunderstand my point of posting those numbers It wasn't to say, look how big I have seen, but instead, look how big these companies are and they still have small DBs. When I hear of some giant DB I don't think wow, what a big DB, I think, what kind of sh*t is being thrown into that AD to bloat it to that extent[1]? I especially love hearing about companies that jam huge binaries into the directory like images that get replicated to the four corners of the earth and are only read by one program, a web app, in one or two of the company's datacenters. Great use of bandwidth. I also especially love seeing a crap load of data going into the directory for Exchange when Exchange is centralized, also great use of bandwidth. That site in South America or in Kuala Lumpur with 10 people and a GC because they have crappy connectivity certainly needs to have every object and the entire Exchange selection of data for the other 200,000 users. No possible issues in data theft there... I think after we get past the training of everyone to only grant permissions to those that really need the permissions and just those specific permissions to just those specific people, we will start training everyone to only put the data where it is really needed. Anyone with a really large DIT should sit down and look at what is in it and say, is it really necessary for all of this data to go where it goes? Is there additional exposure that I have for putting it there that isn't necessary? Brett, while we have your attention if we do... How about some training on max data stored per object. What are the limits that we will hit as we stuff more and more data into say every user object? I know I have found the magic admin limit exceeded when punching a bunch of data into a non-linked multivalue attribute and it causing me to not be able to add any new attributes to the same user object. What other limits are we going to see? Also, why do I see that admin limit on new attributes when the one single multivalue attribute get filled up? joe [1] I really am not an entirely negative person. I am best described as a optimistic pessimist. Hope for the best of all worlds but plan for the worst. I have also been called a Socialist because I am willing to buy a burger for a friend and a good conversation. ;o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Sunday, October 09, 2005 11:29 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Mylo, from the way you speak of JET, I suspect you might not know of the two JETs, and be thinking that JET = Access ... make sure you're edJETicated (man, I slay me! ;), see Notes at bottom of this: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese/por tal.asp This frequent confusion, is the reason we use the more desired term, ESE. The two JETs once compatible at the top level API, have not even had to maintain API compatibility for nearly 10 years, so they are quite different. If the _active amount of data_ (and the active amount of data, can be grossly enlarged by bad queries) exceeds memory, some operations will probably be thrown down to random disk IO speed (100 IOs / second is a standard single spindle/disk) ... ergo you get slow quick. And like most database servers in such a situation, you can often throw hardware at it. We have Exchange servers with a TB of databases attached, and a much higher update rate, BUT a big SAN to satisfy the IO load. With AD you have the added advantage of being able to throw RAM at the situations, with a 64-bit native OS and 32 GBs of RAM, a 29 GB database performs quite well. So where AD caves in, is very hardware and workload dependant ... joe's production numbers aren't even interesting anymore. (implying many customers are in production
RE: [ActiveDir] Adding custom fields to AD
Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org
RE: [ActiveDir] Adding custom fields to AD
Oh, and just so there is no question - see addition to my post below. (yeah - I'm not yet used to the disclaimer thingie) Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 10:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick [msft] -- Posting is provided AS IS, and confers no rights or warranties ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add
RE: [ActiveDir] Adding custom fields to AD
One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What do you feel is wrong with ESE (aka Jet Blue)? What's the ceiling on actual database size before it caves in (performance-wise)? Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max pages [1]). As for when it caves perf wise from an AD standpoint it really depends on what you are doing with it and what you have indexed from what I have seen. If someone is issuing crappy inefficient queries it will seem to be pretty slow pretty fast with relatively little data. The largest DB I have seen in production has been ~20GB and that was with W2K on a GC and a bunch of that data shouldn't have been in the AD like duplicated ACEs and misc unneeded objects, etc. Going to K3 would probably reduce that DB to about 10-12GB or better due to single instance store, cleanup would reduce it even further. One Fortune 5 company I have worked with had a K3 GC DB in the area of 5GB and that was for some 250,000 users with Exchange and multiple custom attributes. joe [1] See the docs for JetCreateDatabase - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese/jet createdatabase.asp?frame=true -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 9:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info
RE: [ActiveDir] Adding custom fields to AD
Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants
Re: [ActiveDir] Adding custom fields to AD
ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o) -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick KingslanSent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworksstuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning).One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)?Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider addingthe data to AD.IF the data is going to be needed only at a couple of sites or a singlesite, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAPdoesn't support.There is also the possibility of using app partitions but if you weregoing to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD isbecoming, in many companies, a dumping ground of all the crap that wasin all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a largecompany and thought that was silly even then.The number one most important thing for AD is to authenticate Windowsusers. Every time you dump more crap into AD you are working towards impactingthat capability or the capability to quickly restore or the ability toquickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only.Plus, I wonder how long before we hit some interesting object sizelimits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get whenoverpopulating a normal multivalue attribute (i.e. not linked) and itcausing no other attributes to be added to the object. I wonder what otherlimits like that exist. joe-Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Steve ShaffSent: Tuesday, August 09, 2005 12:16 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Adding custom fields to ADGroup,My manager wanted me to check, even though, I don't think that it ispossible, but, I will present the question. He would like to add some custom fields, about 30, to AD.He wouldlike to add bio information into AD to be pulled by Sharepoint andother applications for people to read. I think that this is a waste of time, space and effort.However
RE: [ActiveDir] Adding custom fields to AD
Much of AD's heritage lies in the old Exchange directory, which was ESE-based. -gil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Saturday, October 08, 2005 8:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What do you feel is wrong with ESE (aka Jet Blue)? What's the ceiling on actual database size before it caves in (performance-wise)? Max size for an ESE DB for AD is ~16TB (8KB pages * 2147483646 max pages [1]). As for when it caves perf wise from an AD standpoint it really depends on what you are doing with it and what you have indexed from what I have seen. If someone is issuing crappy inefficient queries it will seem to be pretty slow pretty fast with relatively little data. The largest DB I have seen in production has been ~20GB and that was with W2K on a GC and a bunch of that data shouldn't have been in the AD like duplicated ACEs and misc unneeded objects, etc. Going to K3 would probably reduce that DB to about 10-12GB or better due to single instance store, cleanup would reduce it even further. One Fortune 5 company I have worked with had a K3 GC DB in the area of 5GB and that was for some 250,000 users with Exchange and multiple custom attributes. joe [1] See the docs for JetCreateDatabase - http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ese /jet createdatabase.asp?frame=true -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mylo Sent: Friday, October 07, 2005 9:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ
RE: [ActiveDir] Adding custom fields to AD
I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o)-Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick KingslanSent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to ADInteresting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworksstuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning).One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)?Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider addingthe data to AD.IF the data is going to be needed only at a couple of sites or a singlesite, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAPdoesn't support.There is also the possibility of using app partitions but if you weregoing to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD isbecoming, in many companies, a dumping ground of all the crap that wasin all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a largecompany and thought that was silly even then.The number one most important thing for AD is to authenticate Windowsusers. Every time you dump more crap into AD you are working towards impactingthat capability or the capability to quickly restore or the ability toquickly add more DCs. The more I
Re: [ActiveDir] Adding custom fields to AD
I used to work at a place where WINS and DNS were used. IMO, WINS was faster in resolution and *just* worked but is not standard as DNS resolution is. DNS integration with AD is a pain and can be a hassle when troubleshooting, sometimes doing a ipconfig /flush client and flushing the DNS on the DC's to resolve an issue. SP1 has several fixes for w2k3 DNS but I'm sure something else will come up. :) I say we just use hosts files again. :( Steve - Original Message - From: joe [EMAIL PROTECTED] To: ActiveDir@mail.activedir.org Sent: Saturday, October 08, 2005 5:18 PM Subject: RE: [ActiveDir] Adding custom fields to AD I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity of DNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Kern Sent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNS too. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue, Brettsh can answer that one. I'm pretty sure that we have a good idea on where the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes. As for why ESE - it works, it is self maintaining to a great degree, there is very little overhead in the DB, and it is quite optimized to the type of work that is required for AD. Brettsh can certainly add more. I am one for preaching more svelte attitudes on your AD. As joe mentions - it's for authN purposes first and foremost. It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to an attribute, while the actual GPO pieces reside in SYSVOL, so not much AD - lots of FRS), etc. App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas. I, too, like joe advocate ADAM. I try to sell ADAM constantly as THE solution for most anything that doesn't have to do with authN. Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides. Partly, they think they have to learn something new. Partly, they don't really care if YOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified. So, it's up to you, Mr. Admin and Mr. Architect to tell whoever wants to use your AD, no - we don't do it that way because it's very bad. We will use ADAM. Get used to it. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] ] On Behalf Of Mylo Sent: Friday, October 07, 2005 8:04 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] Adding custom fields to AD That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using
Re: [ActiveDir] Adding custom fields to AD
I've had the reverse- last place i worked at had corrupted WINS at least once every 2 months(this could of been due to my lousy admin skills) i've never had issues with dns(could be my dumb luck) now i work for a corp that has netbios/tcp disabled and relies solely on dns(both MS and BIND) with no name resolution issues. also wins replication seems much more complex than standard primary/secondarydns replication. and i'm not one to think i know anything as an admin or would even think of getting into such a disscussion with someone as experienced and knowldgable as you, but i've always found dns easier than wins and netbios names in general. my only diffculty came with learning dns on BIND/Linux and just wrapping my head around AD intergrated dns when i first came to Windows. sometimes when you learn something via the command line, using the gui just confuses things. then again i'm probably one of those guys who thinks he knows dns but really doesn't know anything and hasen't found out yet :( what would you think would be a good replacement for dns/wins? thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: I wasn't saying I like WINS better than DNS or vice versa, just said I don't like DNS. I especially dislike the AD/DNS integration. I don't like chicken and egg problems. BTW, as you bring up WINS. 1. I've never had a corrupted WINS Database. 2. Fewer admins had name resolution issues replication based issues with WINS than they do with DNS. 3. The complexity ofDNS seems to put many admins off the deep end, interestingly enough, the same admins who said they couldn't figure out WINS say they know all about DNS. But again, my comment wasn't I like WINS more than DNS, or I like any name resolution systems better than DNS, it was simply I don't like DNS. From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Tom KernSent: Saturday, October 08, 2005 12:42 PM To: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to AD ok, i'll bite. GPO's, i understand but whats there to hate about DNS? its better than WINS. I've never had a corrputed dns database. thanks On 10/8/05, joe [EMAIL PROTECTED] wrote: Yeah, GPOs aren't AD. GPOs are an application that use AD. I hate GPOs. DNStoo.:o) -Original Message-From: [EMAIL PROTECTED][mailto:[EMAIL PROTECTED] ] On Behalf Of Rick Kingslan Sent: Saturday, October 08, 2005 11:19 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Adding custom fields to AD Interesting question - and as to the 'implode point' for ESE/Jet Blue,Brettsh can answer that one.I'm pretty sure that we have a good idea onwhere the point of diminishing returns is, but it likely FAR exceeds what anyone might practically do today - even with added classes and attributes.As for why ESE - it works, it is self maintaining to a great degree, thereis very little overhead in the DB, and it is quite optimized to the type of work that is required for AD.Brettsh can certainly add more.I am one for preaching more svelte attitudes on your AD.As joe mentions -it's for authN purposes first and foremost.It CAN handle DNS, it does GPO (though - truth be told the majority of GPO function is but a link to anattribute, while the actual GPO pieces reside in SYSVOL, so not much AD -lots of FRS), etc.App Parts make sense in some arenas where the amount of data is going to be very small and contained to just a few areas.I, too, like joe advocateADAM.I try to sell ADAM constantly as THE solution for most anything thatdoesn't have to do with authN.Customer AppDev wants to stuff new things into AD constantly. Partly, they don't know the down sides.Partly, theythink they have to learn something new.Partly, they don't really care ifYOUR AD is affected by their decisions, as long as they deliver the solution in the timeframe specified.So, it's up to you, Mr. Admin and Mr. Architectto tell whoever wants to use your AD, no - we don't do it that way becauseit's very bad.We will use ADAM.Get used to it.Rick -Original Message-From: [EMAIL PROTECTED][mailto: [EMAIL PROTECTED] ] On Behalf Of MyloSent: Friday, October 07, 2005 8:04 PMTo: ActiveDir@mail.activedir.orgSubject: Re: [ActiveDir] Adding custom fields to ADThat's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information forsoftware distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JETas the DB ofchoice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylojoe wrote:I am going to basically say what the other said only I am going to putit this wayIF the data needs to be available at all locations or a majority of locations where your
Re: [ActiveDir] Adding custom fields to AD
That's a good point about plonking stuff in AD a case of once a good thing comes along everyone wants to climb aboard. I remember doing ZENworks stuff with Novell where all the application configuration information for software distribution was shunted into NDS/E-Directory... all that bloat adds up replication-wise (still, at least there was partitioning). One thing I am curious about though is why MS opted for JET as the DB of choice for AD.. was it the only viable option at the time ? What's the ceiling on actual database size before it caves in (performance-wise)? Mylo joe wrote: I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adding custom fields to AD
Can you outline how ADAM could be made transparent to an application? I've been considering this myself but haven't delved far enough into the subject yet... :m:dsm:cci:mvp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, August 10, 2005 1:55 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? I realize this is tongue in cheek but no I don't think it would be good. I am not of the opinion that everything should go into an LDAP Store. LDAP isn't really designed for easily working with binary blobs which is what that is all about. SQL Server is probably still a little on the hokey side with it as well but handles it better than AD does. If the app is already doing LDAP to get basic user info then I don't see the point to jump to SQL unless there is some overriding major factor that requires it. Plus, switching to AD/AM could be nearly or actually could be transparent to apps which can't be discounted, that is HUGE in the world of app dev. Consider that MANY of the apps that are used in larger orgs are UNIX/LINUX/JAVA based and you will probably find it generally easier to access LDAP than an MS SQL Server from something other than Windows and vbscript/VB. In this case it is sharepoint, so maybe SQL Server is the best solution. Plus there is the syncronization piece and I think there are more pre-built options to sync AD with AD/AM than AD with SQL. It certainly should be more straightforward. Plus, like you with WINS, I have never been a fan of SQL Server. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Wednesday, August 10, 2005 12:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD joe, You hit the nail on the head with what my problem is with this whole thread - we're dumping crap into AD that really doesn't belong there. Seriously, the data needs to be available to a SharePoint server and some other apps, unless I read something wrong (wouldn't be the first time today...). Let AD do the authN, let SQL serve the data to the SharePoint and the other apps. It confounds me sometimes AD shouldn't be the repository for this type of data, unless we're applying the We've got a solution, as long as it's AD mentality. I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? ;op Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, August 09, 2005 4:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I
RE: [ActiveDir] Adding custom fields to AD
It depends entirely on how the application talks to the LDAP Server, or more specifically finds the ldap server and what is in it and authNs. Each application will be different just like it is when trying to incorporate them into AD in the first place. You will not have a one size fits all solution with all defined as any app that could ever use AD or AD/AM. I am thinking about mostly non-windows based apps here, so you don't have the auto resource location skills that a Windows app can have by virtue of using the Windows LDAP libs. They simply need to know a base, host name, and binding info. As long as the same attributes are available for searching and sometimes even the same basic hierarchy exists, they are usually quite fine. In fact, if you force the entire forest hierarchy into a single AD/AM, that is much better for many of those apps versus using a GC and then having to chase into other DCs for more info, easier to config. If you have multiple trees it is a little more involved to do this since you will need to add a top level DN to encompass all of the trees (say like cn=root) but if you are specifying the search base in the app, that isn't a problem. Transparency would be more of a challenge with apps using default Windows location services. For instance, Exchange, if it could put its data into ADAM would never work since you can't specify anything, it looks at the defaults of the machine it is sitting on and goes from there. This is a complete PITA to anyone managing multiple forests and means one admin managing multiple Exchange forests (say like a service provider) either needs multiple workstations (real or virtual) or needs to TS into other machines to do their admin work which is just plain silly. There really is no reason other than developer laziness there and a kind of thinking that the world revolves around you and your app. Unfortunately, if you have tried to set up the _ldap DNS entries to get the location services to locate an AD/AM as a DC you know that AD/AM doesn't respond properly to the UDP LDAP query of ((DnsDomain=domain.com)(Host=ServerName)(NtVer=\006)) so the whole Windows location service breaks down. But then MS isn't really using the SRV record for that properly anyway, they ignore the port setting so even if ADAM did respond properly, the client would only query properly if ADAM was on 389 and one of the nice things about using SRV records is so you can jump ports... So plain and simple, Windows LDAP location services doesn't work for this. However, if the app has implemented its own SRV record lookup which I have seen on a couple of UNIX based apps now, that can work fine as they simply look for the SRV records and go from there. So if you have a UNIX app that knows how to find a resource based on SRV records it could probably find an ADAM just fine that way. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, August 10, 2005 7:34 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Can you outline how ADAM could be made transparent to an application? I've been considering this myself but haven't delved far enough into the subject yet... :m:dsm:cci:mvp -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, August 10, 2005 1:55 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? I realize this is tongue in cheek but no I don't think it would be good. I am not of the opinion that everything should go into an LDAP Store. LDAP isn't really designed for easily working with binary blobs which is what that is all about. SQL Server is probably still a little on the hokey side with it as well but handles it better than AD does. If the app is already doing LDAP to get basic user info then I don't see the point to jump to SQL unless there is some overriding major factor that requires it. Plus, switching to AD/AM could be nearly or actually could be transparent to apps which can't be discounted, that is HUGE in the world of app dev. Consider that MANY of the apps that are used in larger orgs are UNIX/LINUX/JAVA based and you will probably find it generally easier to access LDAP than an MS SQL Server from something other than Windows and vbscript/VB. In this case it is sharepoint, so maybe SQL Server is the best solution. Plus there is the syncronization piece and I think there are more pre-built options to sync AD with AD/AM than AD with SQL. It certainly should be more straightforward. Plus, like you with WINS, I have never been a fan of SQL Server. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Wednesday, August 10, 2005 12:19 AM To: ActiveDir@mail.activedir.org
RE: [ActiveDir] Adding custom fields to AD
Certainly it is possible. And, it's not overly difficult to DO, but the upfront planning that SHOULD be done can be tedious. Remember - this is the schema. My opinion - and it seems to be free today (as if I've ever been afraid to give it...) - This is a job that just screams SQL server. I can't imagine WHY AD would be a better choice in this case. As long as the apps are all able to connect via a SQL provider in some method (and goodness knows Microsoft has made a lot of them available), this should be no pain at all. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 11:16 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adding custom fields to AD
...or ADAM. These kinds of requests have a tendency to creep beyond the original scope, which can have unintended consequences if the upfront planning falls short. Hunter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Tuesday, August 09, 2005 10:41 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Certainly it is possible. And, it's not overly difficult to DO, but the upfront planning that SHOULD be done can be tedious. Remember - this is the schema. My opinion - and it seems to be free today (as if I've ever been afraid to give it...) - This is a job that just screams SQL server. I can't imagine WHY AD would be a better choice in this case. As long as the apps are all able to connect via a SQL provider in some method (and goodness knows Microsoft has made a lot of them available), this should be no pain at all. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 11:16 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adding custom fields to AD
The downside of both of these approaches (SQL and ADAM) is that they require some sync of accounts. One nice thing about putting the data into AD is that it is just there for applications to consume if they need it. Your accounts follow your normal account management process. No additional sync is required. You also have the built in high availability and locator services built in to AD. However, this sync isn't necessarily a big deal, especially with ADAM and some of the new tools that do that such as ADAM sync. Personally, I like both approaches, depending on the other details of the deployment. Given that SharePoint was mentioned and the servers are already likely to be domain members that have access to at least some DCs, AD seems like a natural fit to me. Joe K. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Coleman, Hunter Sent: Tuesday, August 09, 2005 12:34 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD ...or ADAM. These kinds of requests have a tendency to creep beyond the original scope, which can have unintended consequences if the upfront planning falls short. Hunter -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Tuesday, August 09, 2005 10:41 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD Certainly it is possible. And, it's not overly difficult to DO, but the upfront planning that SHOULD be done can be tedious. Remember - this is the schema. My opinion - and it seems to be free today (as if I've ever been afraid to give it...) - This is a job that just screams SQL server. I can't imagine WHY AD would be a better choice in this case. As long as the apps are all able to connect via a SQL provider in some method (and goodness knows Microsoft has made a lot of them available), this should be no pain at all. Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 11:16 AM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adding custom fields to AD
I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adding custom fields to AD
joe, You hit the nail on the head with what my problem is with this whole thread - we're dumping crap into AD that really doesn't belong there. Seriously, the data needs to be available to a SharePoint server and some other apps, unless I read something wrong (wouldn't be the first time today...). Let AD do the authN, let SQL serve the data to the SharePoint and the other apps. It confounds me sometimes AD shouldn't be the repository for this type of data, unless we're applying the We've got a solution, as long as it's AD mentality. I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? ;op Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, August 09, 2005 4:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
RE: [ActiveDir] Adding custom fields to AD
I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? I realize this is tongue in cheek but no I don't think it would be good. I am not of the opinion that everything should go into an LDAP Store. LDAP isn't really designed for easily working with binary blobs which is what that is all about. SQL Server is probably still a little on the hokey side with it as well but handles it better than AD does. If the app is already doing LDAP to get basic user info then I don't see the point to jump to SQL unless there is some overriding major factor that requires it. Plus, switching to AD/AM could be nearly or actually could be transparent to apps which can't be discounted, that is HUGE in the world of app dev. Consider that MANY of the apps that are used in larger orgs are UNIX/LINUX/JAVA based and you will probably find it generally easier to access LDAP than an MS SQL Server from something other than Windows and vbscript/VB. In this case it is sharepoint, so maybe SQL Server is the best solution. Plus there is the syncronization piece and I think there are more pre-built options to sync AD with AD/AM than AD with SQL. It certainly should be more straightforward. Plus, like you with WINS, I have never been a fan of SQL Server. :o) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Wednesday, August 10, 2005 12:19 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD joe, You hit the nail on the head with what my problem is with this whole thread - we're dumping crap into AD that really doesn't belong there. Seriously, the data needs to be available to a SharePoint server and some other apps, unless I read something wrong (wouldn't be the first time today...). Let AD do the authN, let SQL serve the data to the SharePoint and the other apps. It confounds me sometimes AD shouldn't be the repository for this type of data, unless we're applying the We've got a solution, as long as it's AD mentality. I'm sure that if we tried, the TerraServer could be served by a few optimized ADAM servers, don't you think? ;op Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Tuesday, August 09, 2005 4:58 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Adding custom fields to AD I am going to basically say what the other said only I am going to put it this way IF the data needs to be available at all locations or a majority of locations where your domain controllers are located, consider adding the data to AD. IF the data is going to be needed only at a couple of sites or a single site, put them into another store. My preference being AD/AM unless you need to do some complicated joins or queries of the data that LDAP doesn't support. There is also the possibility of using app partitions but if you were going to go that far, just use AD/AM. The thing I have about sticking this data into AD is that AD is becoming, in many companies, a dumping ground of all the crap that was in all the other directories in the company. I realize this was the initial view from MS on how this should work but I worked in a large company and thought that was silly even then. The number one most important thing for AD is to authenticate Windows users. Every time you dump more crap into AD you are working towards impacting that capability or the capability to quickly restore or the ability to quickly add more DCs. The more I see the one stop everything loaded into ADs the more I think that the NOS directory should be NOS only. Plus, I wonder how long before we hit some interesting object size limits. I have asked for details from some MS folks a couple of times on the issues with admin limit exceeded errors that you get when overpopulating a normal multivalue attribute (i.e. not linked) and it causing no other attributes to be added to the object. I wonder what other limits like that exist. joe -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Shaff Sent: Tuesday, August 09, 2005 12:16 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Adding custom fields to AD Group, My manager wanted me to check, even though, I don't think that it is possible, but, I will present the question. He would like to add some custom fields, about 30, to AD. He would like to add bio information into AD to be pulled by Sharepoint and other applications for people to read. I think that this is a waste of time, space and effort. However, it is not my call and if this is what he wants What are everyone's thoughts on the topic? Thanks S List info : http://www.activedir.org/List.aspx List FAQ: http://www.activedir.org/ListFAQ.aspx List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/List.aspx List
