Re: AD Limits
- From: "Al Mulnick" <amulnick_No_SPAM@xxxxxxxxxxx>
- Date: Wed, 25 Jan 2006 22:31:18 -0500
One additional thought:
You may want to consider 64bit servers for the added memory ability. There
are several adjustments and tweaks that can be made to optimize performance,
but to better do that, a thorough understanding of how the application will
use the authentication is needed. For example, will it auth once for several
accounts, or once for each account object it holds? If for each account
object, what is the concurrency expected? If only for several accounts,
then no big deal most likely. If it's going to be for all of the user
objects, and you determine concurrency, how often will authentication
requests be made in your application? Or will this be one time per session?
Per object?
Memory adjustments would be advisable. Network would as well as disk layout
depending on the answers to similar questions from above.
FWIW, you may just want to call up Microsoft and have them give you a hand
with this. Might be worth the time/money spent to have a developer listen
to what you're proposing, analyze it, and make suggestions.
Al
"Ace Fekay [MVP]"
<PleaseSubstituteMyActualFirstName&LastNameHere@xxxxxxxxxxx> wrote in
message news:u72YX1VIGHA.2696@xxxxxxxxxxxxxxxxxxxxxxx
> In news:vutct1hqgv0p9lmr4vhgqh0imrudv47cgt@xxxxxxx,
> Peter Lecki <plecki2@xxxxxxxxxxxx> stated, which I commented on below:
>> We have a web/sql/mail application that uses AD for authentication of
>> user accounts. Single domain, single OU. There are no other objects
>> that we use, no groups (other than built-in), no computers (other than
>> the servers running the app), no Exchange, etc. We are
>> rearchitecturing the application right now as we prepare for an
>> increase of users to several million.
>>
>> Currently, once the user is authenticated during website logon, there
>> are no other security checks made against that account when accessing
>> resources, all resources are accessed by just a handful of service
>> accounts. One of the goals of the rearchitecture is to add that
>> security into the mix.
>>
>> Some members of our team were under the impression that there are
>> limitations to the number of objects, specifically user accounts, that
>> can be efficiently held in an OU and in the forest. From what I've
>> read over the past few days, I understand that there are such
>> theoretical limitations but they are probably far beyond of what we'd
>> be using. Several sources quote very different numbers, though, so
>> I'm trying to make sure I have the correct information. For example,
>> I've ran across, from various reputable sources, including MS itself
>> and several books on the topic, as well as other experts' articles on
>> the web, object limitations of 1 million, 100 million, 1 billion and
>> now you with over 4 billion. I would be satisfied with any of these
>> numbers except the first one. Furthermore, I also need to examine
>> hardware requirements to handle these numbers, as I currently have
>> only two DC's with dual Xeon 3.2GHz, 1GB of RAM and 60GB of HD space
>> each. I have not been able to find much concrete information on this
>> subject either, perhaps looking in the wrong places?
>>
>> Thanks for your time gents,
>> Peter.
>
> It is over 4 billion. It's been discussed in the past. This is because of
> the GC's limitation because it stores a read only subset of all objects
> that need to be available for lookups, logon authentication because
> Universal groups are stored in the GC, and authentication will fail if it
> cannot enumerate Universal groups, whether any were created or not.
>
> Look in the reg under Services/Lanman Server. Look at the shares entries.
> Notice that number? That is the limit of what it can handle. It's based on
> the i386 architecture.
>
> To determine what your server will handle as a DC and how many DCs you
> should need, if Exchange or no Exchange, Sites, etc, download and run the
> ADSizer design tool. Don't be fooled by the "2000" in it, for it works for
> 2003 as well. Replication is optimized, as well as other features, but I
> don;t think replication applies in your case. The results are less than
> one expects being the bare minimum requirements, but it gives you an idea
> where you're at. Unfortunately they've never updated it for the faster
> CPUs of today.
>
> Windows 2000 Free Tool Downloads:
> http://www.microsoft.com/windows2000/techinfo/reskit/tools/default.mspx
>
> Here's a link on how to use it (look for the video in the list):
> NT 4.0 and Windows 2003 Active Directory Interoperability:
> http://www.microsoft.com/technet/community/events/windows2003srv/tnt1-79.mspx
>
> Ace
>
.
- Follow-Ups:
- Re: AD Limits
- From: Ace Fekay [MVP]
- Re: AD Limits
- References:
- AD Limits
- From: Peter Lecki
- Re: AD Limits
- From: Peter Lecki
- Re: AD Limits
- From: Ace Fekay [MVP]
- AD Limits
- Prev by Date: Re: Web Resolution / Likely DNS?
- Next by Date: Add Windows Security Principal as ADAM Admin via LDIFDE?
- Previous by thread: Re: AD Limits
- Next by thread: Re: AD Limits
- Index(es):
Relevant Pages
|
