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=st&q=JET+Kodiak+Exchange&rnum=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 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 > > > /e > > > se > > > /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 : 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 : 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 : 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/
