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 bad.We will use ADAM.Get used
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] Schema Updates
Title: Schema Updates Hmmm. I need to think about that again. I think I only saw this behavior in the lab where all the servers were upgraded instead of wipe and replace. In production, we upgraded initially then did a replacement effort later. More to the point, UGH Cisco Unity I wish to Christ theyd stick to hardware and stop venturing into software :m:dsm:cci:mvp marcusoh.blogspot.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Friday, October 07, 2005 9:03 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Schema Updates Was it maybe the app itself disallowing the update? Did you try to just modify the schema to see if it would work? Say change the rangeupper of cn or something like that and then change it back. Something innocuous. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 07, 2005 5:17 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Schema Updates Yep, same here. I think upgraded scenarios have this. :m:dsm:cci:mvp marcusoh.blogspot.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Vander Kooi Sent: Friday, October 07, 2005 10:57 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Schema Updates Upgraded. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, October 07, 2005 9:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Schema Updates Upgraded to 2003 or fresh install? :m:dsm:cci:mvp marcusoh.blogspot.com From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Vander Kooi Sent: Friday, October 07, 2005 10:12 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Schema Updates I just did this last week to install Cisco Unity and I still had to enable schema updates in Windows 2003 even though the user was in Schema Admins. I was under the same impression as Travis, but after enabling updating in the registry it worked fine. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Thursday, October 06, 2005 10:03 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Schema Updates Did you work this out Travis? If not, I would recommend pulling up the sysinternal registry and file monitors as well as tracing the AD calls. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, August 11, 2005 2:59 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Schema Updates Hi, I am having some problems updating the schema for Avaya Unified Messaging. It is my thinking that in Windows 2003 the schema is already enabled for updates as long as you are in the Schema Admins group. In Windows 2000 you had to enable the Schema to be updated. Am I correct or misguided? Thanks! Travis Abrams
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 that
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 for
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 of GPO function is but a link to
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 for
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 with
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 attributes.As for why ESE -
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 it likely FAR exceeds
what
anyone might
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 that
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, as
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 with
