>"Never take me to serious" > >Seriously? :) Absolutely ;)
>(Great thread by the way) I agree! Ulf |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of |Crawford, Scott |Sent: Tuesday, April 18, 2006 1:16 AM |To: [email protected] |Subject: RE: [ActiveDir] User Accounts | |"Never take me to serious" | |Seriously? :) | |(Great thread by the way) | |-----Original Message----- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED] On Behalf Of Ulf B. |Simon-Weidner |Sent: Monday, April 17, 2006 6:06 PM |To: [email protected] |Subject: RE: [ActiveDir] User Accounts | |Hi Brett, | |I don't want you to say or admit anything - I'm just curious |and having a conversation here ;-) | |I was refering to your sentence |> I've heard of two production ADs in excess of 50 M (less than 100 M |though) |Which really made me curious and I started to think that these |are not that unlikely to hit the limit. Rest of the |conversation is just curiousity and for the sake of being |interested - no real scenario - just interested in opinions. | |Never take me to serious - I'm german but that wasn't my fault |;-) I like to discuss what-if scenarios and am mainly |interested in geeky chit-chat. | |And I've never and will never ask someone of your group or |company to confess something in public. We are just chatting here. | |Ulf | | | ||-----Original Message----- ||From: [EMAIL PROTECTED] ||[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley ||Sent: Tuesday, April 18, 2006 12:32 AM ||To: [email protected] ||Subject: RE: [ActiveDir] User Accounts || || ||In my experience the type of forest you're thinking about is a ||different beast, Ulf ... || ||I don't know a single customer that has a NOS / IT infrastructure ||forest with 10M objects, in fact I can't even think of one with 5 M. ||Anything north of 5M - 10M objects is almost assuredly e-commerce, ||internet facing web portal type stuff ... || ||There is natural churn because of user accounts on the web |facing stuff ||churn, multiple personas, forgotten password, what ever, but |they don't ||get any of the normal churn you associate with the IT infrastructure ||(DNS objects, computer accounts join/unjoin, MIIS or "HR control ||system" ||injected changes, etc). They're basically using it like a |specialized ||database. || ||They are more prone to IFM though, which doesn't recycle DNTs. || But all things consider the object churn seems to be less ... ||I believe the churn isn't too ridiculous. || ||But it seems you just want to say or me to admit, yes if you hit this ||limit you will need to repromote. That is true. ||People dealt w/ NT4 SAM when it balked at 70k accounts or whatever, ||people will have to deal w/ AD when they use 2B RDNs ... if you're ||actually dealing with numbers that ballpark into that area, I'd be ||curious to hear about your scenario, but I suspect no one is |doing that ||... yet. || ||Cheers, ||-BrettSh || ||On Mon, 17 Apr 2006, Ulf B. Simon-Weidner wrote: || ||> Hi ~eric, ||> ||> >> I don't look very happy ||> >> imagining running ADMT or some other migration tool against 100M ||> >> Object ||> ADs ||> > ||> > You don't need to think about anything like ADMT. In your ||scenario, ||> > with ||> object overturn and DNT depletion, you would simply need to ||re-promote ||> the machines ||> > slowly over time, perhaps when doing OS version upgrades or ||> > something, and ||> not use IFM. ||> > This is not a forest concept, nor domain, nor NC.....this is a DB ||> > instance ||> concept. DNTs are different in each instance in your forest. ||They are ||> not replicated. ||> ||> Yes - agree. My intend was to outline that we might approach the ||> DNT-limit with directories this large because: ||> - they might run for a longer time ||> - object overturn will happen ||> - AD will stay over time since I doubt a upgrade will touch the dit ||> and recycle DNTs, and companies with that large forests will rather ||> upgrade to a new OS than using ADMT ||> ||> I'm aware that a repromote of the DCs will take care of it. I just ||> tried to say that there might be the time when a repromote ||because of ||> DNTs might be necessary in some larger domains. However still ||> unlikely, but not that much away from reality if you look at the ||> numbers posted (100M Objects are 5-10% of the limit, employees and ||> customers as well as other objects (DNS) tend to change, and ||the limit is the forest (b/c total number of objects on a GC)). ||> ||> >> Were these real objects, or what the regular AD-Guy |would refer to ||> > ||> > Yes, but I don't understand why this matters to you? ||> ||> Just being curious if Brad was talking about 50M+ Accounts ||or Objects ||> - main reason because of plain curiousity to figure out if we are ||> talking about ||> 50M+ Objects or 50M+ Accounts + another couple M ||dnsNodes/phantoms/... ||> ||> Gruesse - Sincerely, ||> ||> Ulf B. Simon-Weidner ||> ||> MVP-Book "Windows XP - Die Expertentipps": ||> <http://tinyurl.com/44zcz> http://tinyurl.com/44zcz ||> Weblog: <http://msmvps.org/UlfBSimonWeidner> ||> http://msmvps.org/UlfBSimonWeidner ||> Website: <http://www.windowsserverfaq.org/> ||> http://www.windowsserverfaq.org ||> Profile: ||> ||<http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F1 ||> 214C81 ||> 1D> ||> ||http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B48 ||9-F2F1214C811 ||> D ||> ||> ||> ||> ||> _____ ||> ||> From: [EMAIL PROTECTED] ||> [mailto:[EMAIL PROTECTED] On Behalf Of Eric ||> Fleischman ||> Sent: Monday, April 17, 2006 4:43 PM ||> To: [email protected]; [email protected] ||> Subject: RE: [ActiveDir] User Accounts ||> ||> ||> > I don't look very happy ||> > imagining running ADMT or some other migration tool against 100M ||> > Object ||> ADs ||> ||> You don't need to think about anything like ADMT. In your scenario, ||> with object overturn and DNT depletion, you would simply need to ||> re-promote the machines slowly over time, perhaps when doing OS ||> version upgrades or something, and not use IFM. ||> This is not a forest concept, nor domain, nor NC.....this is a DB ||> instance concept. DNTs are different in each instance in ||your forest. ||> They are not replicated. ||> ||> > Were these real objects, or what the regular AD-Guy would refer to ||> ||> Yes, but I don't understand why this matters to you? ||> ||> ~Eric ||> ||> ||> _____ ||> ||> From: [EMAIL PROTECTED] on behalf of Ulf B. ||> Simon-Weidner ||> Sent: Mon 4/17/2006 1:09 AM ||> To: [email protected] ||> Subject: RE: [ActiveDir] User Accounts ||> ||> ||> ||> Very interesting again, thanks for those explainations. ||> ||> So you've seen Ads with 50M - <100M Objects. This makes the ||> theoretical part of my brain a bit anxious - theoretically ;-) ||> ||> Were these real objects, or what the regular AD-Guy would refer to ||> (Sum of users, computers, groups, a.s.o - leaving out technical ||> objects like phantoms, objects in the C-NC, S-NC, ||D-NC/System,.. dnsNode-Objects [1],..)? ||> ||> That means they'll have issues after a "account overturn" ||[2] of 20-40 ||> (or 10 if 100M Objects and you feel comfortable with 1.07B) because ||> then they hit the "unreleased DNTs" and have to start ||repromoting DCs ||> to get them back. ||> OK - while a "account overturn" of 20 seems very long term |- I doubt ||> that DNTs are being released by inplace upgrades and I don't ||look very ||> happy imagining running ADMT or some other migration tool ||against 100M Object ADs. ||> And the limit is still the forest, not the domain. ||> ||> So in the long term they might be even hitting the ||DNT-Limit, without ||> even creating a bigger AD DIT (considering they perform regular ||> DIT-maintenance) ||> - just by deleting and recreating each object b/c of its natural ||> overturn up to 40 times and not releasing their DNTs. However long ||> term - if we assume 100M Objects and a object overturn about 10yrs ||> we'll have 20 cycles and 200 yrs to figure that out - or ||just get the last bit back and rethink. ||> ||> Limit on RIDs - this one is interesting as well, since we ||only need to ||> create 2147483 DCs and create 325 objects on the last one. ||Anyone out ||> there to borrow me some hardware ;-) ||> ||> However I'm still curious what would happen when we have the 2^31+1 ||> newly created objects (handled error, major bang of the ||server against ||> the wall) (no matter how many are currently existing - same issue ||> whold happen with lower numbers of objects and frequent ||deletion/creation)? ||> Also - as Dean mentioned - what would happen when we have more than ||> 2^30-1000+1 Security Principles - Bang boom bang - or start |the RIDs ||> over at 1000, or overflow which would cause the RIDs to start at ||> 1(yeah - I'd like to be the 2^30-1000+500 user then)? ||> ||> OK - everything extremely unlikely - but the d... [3] thing ||is that my ||> brain wants to know that now - and I can't find the soft reset ;-) ||> ||> [1] Uupsi - they tend to be deleted and recreated quite frequently ||> (compared to accounts) ||> ||> [2] How would you call this? "Inventory overturn" comes to my mind ||> (the cycle when a warehouse has all inventory sold and new one in ||> there), so "account overturn" may be appropriate defining when each ||> account has been dismissed and a new one created (however ||technically ||> I'm talking to "object ||> overturn") - people leave and people join - people die and ||people are ||> being instantiated (aka born). ||> ||> [3] Swearword? Do clue - I'm german - we have our own - |can't keep a ||> dictionary of approabriate words in foreign languages in the same ||> brain which is interested in those answers. ||> ||> Gruesse - Sincerely, ||> ||> Ulf B. Simon-Weidner ||> ||> MVP-Book "Windows XP - Die Expertentipps": |http://tinyurl.com/44zcz ||> Weblog: http://msmvps.org/UlfBSimonWeidner ||> Website: http://www.windowsserverfaq.org ||> <http://www.windowsserverfaq.org/> ||> Profile: ||> ||http://mvp.support.microsoft.com/profile=35E388DE-4885-4308-B489-F2F12 ||> 14C811 ||> D ||> ||> ||> ||> |-----Original Message----- ||> |From: [EMAIL PROTECTED] ||> |[mailto:[EMAIL PROTECTED] On Behalf Of Brett ||> |Shirley ||> |Sent: Monday, April 17, 2006 2:47 AM ||> |To: [email protected] ||> |Subject: RE: [ActiveDir] User Accounts ||> | ||> | ||> |Eric's quoting didn't come across in pine so well, so I've |improved ||> |it by using ">>" where he was quoting others ... ||> | ||> |*Ahem* ... for the hex heads ... ||> | ||> |ESE limits: ||> | ||> |The underlying store (aka ESE or JET Blue) does not have a 4.2 ||> |billion row constraint to the # of rows in a single table ... ||> |ESE will support from ||> |2^1 up to 2^(~240*8) rows in a single table, _depending upon your ||> |primary key_ ... and if you found ESE's old max 9.95e+583 ||rows to be ||> |woefully under sized, you'll be able to go to around _I think_ ||> |2^(~1875*8) rows in Vista ... if you can find the storage ||for it [1]. ||> | ||> |AD design limits: ||> | ||> |Active Directory however choose a primary key ("The DNT") that has ||> |only 32 bits, and is signed, so limiting to positive values is ||> |limited to 2.1 billion rows (as ~Eric mentions), but this is not ||> |ESE's fault, nor an ESE limitation. Exchange for example choose a ||> |63-bit message ID on thier message table (called "1-23" ||IIRC), and is ||> |thus limited to no more than ||> |2^63 / 9.22 quintillion rows (though probably a bit less |due to the ||> |way they parse up the message ID). ||> | ||> |Clearly the Exchange limit of # of message rows, shows that ESE is ||> |not limited to 2.1 or 4.2 billion rows in a single table, ||this is why ||> |it is crucial to be able to distinguish how ESE differs ||from the data ||> |layer / schema (of AD) constructed on top of ESE. ||> | ||> |At this point we think we've established the max # of |objects in an ||> |AD database, BUT the actual hard limitation would be the |minimum of ||> |several competing constraints, any which could reduce us far lower ||> |... ||> | ||> |Actual hard limitation will be the ||> |1. Dean points out over "the lifetime of the database". This is ||> |crucial to understand, you should consider his meaning, he |is right ||> |on about that. ||> |This is again an AD limitation, not an ESE limitation though. ||> |AD could've concocted (not even that hard) a scheme to |reuse rows / ||> |DNTs. ||> | ||> |2. joe pointed out the 16 TB DB size limit, he is right |about that, ||> |which means at 2 billion objects, your net aggregate object ||size cost ||> |(including SD which may be single instanced, the link ||values, the ESE ||> |overhead to maintain the database, indices, rows, record ||format, etc) ||> |must be below 8KB / object. ||> | This is worth noting because the average size of ONLY the |raw data ||> |(i.e. excluding ESE overhead) _in the datatable_ of an AD ||user in our ||> |primary corp domains is 11,924 bytes. Dang certs. ||> | ||> |3. Eric, also points out about LID (which is a Long-value ID) is a ||> |signed int (again 31 bits available in positive value |space), so we ||> |could be limited to less than 2 billion objects, if each ||object had a ||> |couple "burst long values" (only _burst_ LVs use LIDs). LV = ||> |Long-Value, not Link Value for this discussion. This _IS_ an ESE ||> |limitation. Expeience tells us replProperlyMetaData and ||> |supplementalCredentials on typical AD users are burst, and |thus the ||> |limit could be as low as 1 billion. ||> | ||> |4. SIDs (well RIDs actually) can limit how many security |principals ||> |you use, but RIDs are a security aspect, and so I have no ||idea if you ||> |can use 32, 31, or less of that number space, I suspect 1 ||billion but ||> |don't know that at all. ||> | ||> |Anyway along time ago we (some AD people) went through all the ||> |various aspects, issues, etc and we came up with "the safe value", ||> |that special value we wanted to claim / support ... ||> |and we started saying 1 billion was the official limit. I updated ||> |the wikipedia topic on it awhile back. ||> | ||> |The issue joe mentioned with the # of pages in an ESE ||database being ||> |2^31 ... I like to state it as: "Jordie (my pseudonym for a ||> |paticularly talented developer) took away the high bit before he ||> |moved off the ESE team, and won't give it back.". ||> |<g> That is the funny way to say, paranoia drove one of us ||to cap it ||> |to explicitly positive page numbers. Given that the file |system is ||> |limited to 16 TBs for a single file for some paticular ||(?default? 4k? ||> |max?) "allocation size", I don't really see this being ||fixed anytime ||> |soon... ||> | ||> |My confidence ranges from 53% to 72% for all the above info ... I ||> |don't give a confidence of more than 80% to anything I didn't ||> |personally verify in code, and never a confidence of over ||90% that I ||> |didn't personally test that the code worked like it looked |... that ||> |is experience talking. ||> |Confidences of 53% to 72% probably means talented and smart / ||> |non-blowheart types told me this information. ||> | ||> |*Cough* ... for the realists ... ||> | ||> |I've heard of two production ADs in excess of 50 M (less |than 100 M ||> |though), and have seen 46, 85 and 100 M object test DITs. ||I've never ||> |seen an AD database in excess of 100 GBs in size. Basically, I'm ||> |neither worried about the # of objects nor the database size of AD ||> |databases, as clearly people haven't even gotten to an order of ||> |magnitude of the theoretical limits, and we've still tested higher ||> |than production deployments I've heard of / seen. 3 - 5 M ||is common ||> |for e-commerce directories. ||> | ||> |While thoretically we could give ~2/7ths of the world an ||account in a ||> |single AD database, that is not practical, limitations on ||> |backup/restore time, SLAs, amount of query load per server, will ||> |likely cause one to scale out and _probably_ partition (via NCs ||> |replicated to only some ADAM ||> |instances) before going to billion area scales. Management of ||> |database size on these scales is non-trivial, and drives ||the real per ||> |server #'s of objects / database sizes one should support ||down below ||> |1 billion. ||> | ||> |Even e-commece doesn't care about these kind of numbers, |because if ||> |you look at the income of the 1 billionth richest person in the ||> |world, you'll probably realize she/he is not worth selling ||to. Only ||> |hippies and the U.N. care about going above 1 billion accounts. ||> | ||> |[1] which you can't, as there are only IIRC ~1.0e+83 [or |84 or 82?] ||> |particles in the universe anyway. ||> | ||> |Sorry, if this mail used too much lingo, it was aimed at the super ||> |experts (Dean, joe, et al), I'll try to digest it into a series of ||> |more edible blog posts that would explain the terms as ||introduced ... ||> |:P ||> | ||> |Anyway, all I'm saying, is the Garage Door Operator has |never heard ||> |of this 2.1 or 4.2 billion row limit of an ESE database you ||speak of ||> |... ||> | ||> |Cheers, ||> |Brett ||> | ||> |P.S. - I've never heard of negative link IDs, I'm most ||curious to see ||> |Eric's description of this ... ||> | ||> | ||> |On Sat, 15 Apr 2006, Eric Fleischman wrote: ||> | ||> |> Good thread. ||> |> ||> |> ||> |> ||> |> A few corrections, for the sake of keeping the search ||> |engines fresh.... ||> |> ||> |> ||> |> ||> |>> The underlying store used by AD supports a theoretical ||> |maximum of 4.2 ||> |>> billion rows (limited by the 32 bit DNT or distinguished ||name tag) ||> |> ||> |> ||> |> ||> |> Actually, you can only have 2^31 DNTs. This is because we ||> |start at 1, ||> |> but it is actually a signed int. So we only get up to ~2bil ||> |or so, and ||> |> don't use the negative side. Sorry, you can't have the bit back, ||> |> unless you ask REALLY nicely. <g> ||> |> ||> |> ||> |> ||> |>> A row could be said to correlate to an object but it's ||> |certainly not ||> |>> a one-to-one relationship since rows also house many other ||> |structures ||> |>> such as tables, long-values, etc ||> |> ||> |> ||> |> ||> |> Ah, no, not quite (thankfully :-)). ||> |> ||> |> There is a similar limit for # of long values (doesn't work ||> |the same, ||> |> but mechanics omitted for the sake of brevity), but it has ||> |nothing to ||> |> do with row count in the data table. Long values are |burst out to ||> |> their own b-tree, and as such would not be related to the ||DNT count ||> |> max that you were talking about before. In fact, the LID ||concept is ||> |> entirely orthogonal to the max row count governed by DNTs ||that was ||> |> being discussed. ||> |> ||> |> Dean and I also IM'd on this thread some, and the |concept of link ||> |> value also came up. Rest assured, link values also do |not consume ||> |> DNTs, they are stored entirely differently. ||> |> ||> |> ||> |> ||> |> But, I do agree with the general feeling here, though for a ||> |> slightly different reason. :) A row being used on a DC does not ||> |> necessarily correlate with only what people think of as "their ||> |> objects hosted by that particular server." You have phantoms, ||> |> structural phantoms, schema definitions, etc. Further, GCs of ||> |> course drive the limitation in large forests, when the # ||of objects ||> |> that is large are in domain NCs, of course (more on this below). ||> |> ||> |> ||> |> ||> |>> So ... to my knowledge, there's no user-related maximum ||other than ||> |>> the ESE constraints outlined above. Hundreds of ||millions of users ||> |>> seems perfectly practical. I personally have no first-hand ||> |>> experience of a directory of that scale but if memory serves I ||> |>> believe public documentation does exist referencing either ||> |(or both) ||> |>> test or production directories well within this arena. ||> |> ||> |> ||> |> ||> |> There is actually a subtle point here....there is max # of ||> |users in a ||> |> single directory instance (ie, on one given DC/ADAM ||> |instance), and max ||> |> # in the entire distributed system. They are somewhat different. ||> |> ||> |> In the ADAM world (read: no GCs), it is entirely possible ||to have a ||> |> series of instances, each of which house different NCs, ||and each NC ||> |> approaches the limits mentioned in this thread (ie, each |has 2bil ||> |> objects say). So long as no one instances breaks the thresholds, ||> |> you are golden. ||> |> ||> |> It is only AD that can't play this game because GCs of ||course have ||> |> partial NCs. But ADAM, no worries. Well, unless your large # of ||> |> objects in AD are in NDNCs. ||> |> ||> |> ||> |> ||> |> The larger directories I have worked with had ~100M objects on a ||> |> single server. I haven't seen people break that on a single ||> |box....but ||> |> I don't deny it has been done, I just haven't seen it. :-) ||> |> ||> |> ||> |> ||> |> Oh yea, the concept of negative linkIDs somehow came up in ||> |> conversation as well. I'll blog about that I think. Perhaps even ||> |> tonight, if I get my stuff done. ||> |> ||> |> ||> |> ||> |> ~Eric ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ________________________________ ||> |> ||> |> From: [EMAIL PROTECTED] ||> |> [mailto:[EMAIL PROTECTED] On Behalf Of joe ||> |> Sent: Saturday, April 15, 2006 11:15 AM ||> |> To: [email protected] ||> |> Subject: RE: [ActiveDir] User Accounts ||> |> ||> |> ||> |> ||> |> Actually I am going to bust myself here before Dean or ||someone else ||> |> does. The SIDS are going to be limited into the |billions. Not due ||> |> to the SID structure, but due to locations where RIDs are ||stored as ||> |> DWORDs (32 ||> |> bits) instead of as 6 bytes (48 bits). ADAM thoughts ||still stand as ||> |> they use the GUID logic for producing the SIDs, they are not ||> |based on ||> |> a domain SID coupled with an artificially limited 32 bit "RID". ||> |> ||> |> ||> |> ||> |> -- ||> |> ||> |> O'Reilly Active Directory Third Edition - ||> |> http://www.joeware.net/win/ad3e.htm ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ________________________________ ||> |> ||> |> From: [EMAIL PROTECTED] ||> |> [mailto:[EMAIL PROTECTED] On Behalf Of joe ||> |> Sent: Saturday, April 15, 2006 11:49 AM ||> |> To: [email protected] ||> |> Subject: RE: [ActiveDir] User Accounts ||> |> ||> |> I agree with Dean on this. :o) ||> |> ||> |> ||> |> ||> |> The only user logical or implementation related ||limitation I could ||> |> think of off the top of my head would be around SIDs and you are ||> |> talking a number in the trillions for Active Directory and much ||> |> much errr much higher for ADAM since they changed how SIDs are ||> |generated[1]. ||> |> ||> |> ||> |> ||> |> For completeness though not directly related to Christine's ||> |question I ||> |> also wanted to add that the other physical limit is simply ||> |one of size ||> |> which is ~16TB. This is governed by the max pages of ESE ||> |> (2147483646[2]) coupled with the page size used for the Active ||> |> Directory DB which is 8KB. That works out to 8*1024*2147483646 / ||> |> 1099511627776[3] or 15.9999TB. ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> joe ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> [1] See discussion in book mentioned in signature[7] ||> |> ||> |> ||> |> ||> |> [2] This max page size is publicly available in the ESE ||docs. It is ||> |> located on the page ||> |> ||> |||http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese/ ||> |e ||> |> se ||> |> /jetcreatedatabase2.asp?frame=true ||> |> ||> |||<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ese ||> |/ ||> |> es e/jetcreatedatabase2.asp?frame=true> however note there ||> |is a doco ||> |> bug where it says that is 2^32 - 2 and it obviously |isn't... It is ||> |> 2^31 - 2[4]. Why not 2^32 - 2 which effectively doubles ||the size of ||> |> the DB for those who find ~16TB a trifle claustrophobic? ||You would ||> |> have to ask our Garage Door guy but I __know__ that the page ||> |vars are ||> |> specified as 32 bit "longs" and I would __theorize__ it ||is to avoid ||> |> hitting bit issues and make it is easier (and faster) for ||> |comparisons ||> |> and calculations so you don't have to watch out for ||overflows, etc. ||> |> This isn't something you tend to think about in scripting and ||> |> languages like VB and .NET but I can assure you, something ||> |below your ||> |> code has to handle it and it is extra work. So not using the ||> |high bit ||> |> gets you a nice one bit buffer[5] which sounds like very ||> |little but is ||> |> a lot of buffer for the calculations that would need to be made. ||> |> ||> |> ||> |> ||> |> [3] This is the number of bytes in a TB. 1024^4. If you had ||> |that much ||> |> in pennies you would be a billionaire. But still not as rich ||> |as billg. ||> |> ||> |> ||> |> ||> |> [4] I have submitted this feedback to MSDN for a second ||> |time. Usually ||> |> they are a little better about that when you submit |something. :) ||> |> Oh how do I know which number is the correct one? I cheated and ||> |looked at ||> |> the source. ;o) ||> |> ||> |> ||> |> ||> |> [5] Not like a storage buffer but a programming buffer ||sort of like ||> |> putting tape up when painting so you don't have to go and ||do extra ||> |> work of scraping (or repainting another colour) later. ||> |> ||> |> ||> |> ||> |> [6] Why are you reading this footnote, I didn't reference it. :) ||> |> ||> |> ||> |> ||> |> -- ||> |> ||> |> [7]O'Reilly Active Directory Third Edition - ||> |> http://www.joeware.net/win/ad3e.htm ||> |> <http://www.joeware.net/win/ad3e.htm> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ________________________________ ||> |> ||> |> From: [EMAIL PROTECTED] ||> |> [mailto:[EMAIL PROTECTED] On Behalf Of ||Dean Wells ||> |> Sent: Saturday, April 15, 2006 9:48 AM ||> |> To: Send - AD mailing list ||> |> Subject: RE: [ActiveDir] User Accounts ||> |> ||> |> That number isn't accurate I'm afraid. The underlying |store used ||> |> by AD supports a theoretical maximum of 4.2 billion rows ||> |(limited by the ||> |> 32 bit DNT or distinguished name tag) within its ||lifetime, deleted ||> |> objects (garbage collected or otherwise) do not return row ||> |numbers to ||> |> the available pool. A row could be said to correlate to an ||> |object but ||> |> it's certainly not a one-to-one relationship since rows ||also house ||> |> many other structures such as tables, long-values, etc. ||> |Note that the ||> |> limitation also differs from DC to DC since long-standing ||DCs will ||> |> have less row space available than those recently promoted. ||> |> Windows ||> |> 2003 does not address this limitation (although improvements ||> |have been ||> |> made in other areas). ||> |> ||> |> ||> |> ||> |> So ... to my knowledge, there's no user-related maximum ||> |other than the ||> |> ESE constraints outlined above. Hundreds of millions of users ||> |> seems perfectly practical. I personally have no first-hand ||> |experience of a ||> |> directory of that scale but if memory serves I believe public ||> |> documentation does exist referencing either (or both) test or ||> |> production directories well within this arena. ||> |> ||> |> ||> |> ||> |> -- ||> |> Dean Wells ||> |> MSEtechnology ||> |> * Email: [EMAIL PROTECTED] ||> |> http://msetechnology.com <http://msetechnology.com/> ||> <http://msetechnology.com/> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> ________________________________ ||> |> ||> |> ||> |> From: [EMAIL PROTECTED] ||> |> [mailto:[EMAIL PROTECTED] On Behalf Of ||> |Medeiros, Jose ||> |> Sent: Friday, April 14, 2006 10:39 PM ||> |> To: [email protected] ||> |> Subject: RE: [ActiveDir] User Accounts ||> |> ||> |> I was told 5 billion objects ( In Theory ) when I took ||> |the Windows ||> |> Server 2000, " Designing a Microsoft Windows 2000 ||> |Networking Services ||> |> Infrastructure ", taught by Cathy Moya at Quickstart ||Technologies ( ||> |> Now with Microsoft ). ||> |> ||> |> ||> |> ||> |> Joe, has Microsoft changed this in AD 2003? ||> |> ||> |> ||> |> ||> |> Jose ||> |> ||> |> ||> |> ||> |> ||> |> ________________________________ ||> |> ||> |> ||> |> From: [EMAIL PROTECTED] ||> |> [mailto:[EMAIL PROTECTED] On Behalf Of ||> |Christine Allen ||> |> Sent: Friday, April 14, 2006 7:51 AM ||> |> To: [email protected] ||> |> Subject: [ActiveDir] User Accounts ||> |> ||> |> ||> |> ||> |> ||> |> ||> |> Hello, ||> |> ||> |> How many user accounts can Active Directory ||2000/2003 support ||> |> (including email)? ||> |> ||> |> -Christine ||> |> ||> |> Christine N. Allen ||> |> Systems Engineer ||> |> BMC HealthNet Plan ||> |> 2 Copley Place ||> |> Boston, MA 02116 ||> |> 617-748-6034 ||> |> 617-293-4407 ||> |> ||> |> [EMAIL PROTECTED] ||> |> ||> |> ||> | ||> |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/
