I'd add that even if you did have an AD DIT sufficiently large to run into the memory limitation on the "normal (x86/32bit)" Win2k3 Std. Edition, you'd can still save a lot of $$$ by moving to the Win2003 x64 Std. Edition. 
 
While the 32bit Std. Edition only supports 4GB memory, the x64 Std. Edition supports 32GB. This is the same memory support as the 32bit Ent. Edition used to have (which has been increased to 64GB with Win2k3 SP1). Taking into account that there is no cost-difference for the licences (the costs for 32bit Std. = cost for 64bit Std. etc.) and that almost all modern Server hardware either comes with the Intel EM64T or AMD Opteron 64bit procs (that can also run 32bit code natively), you should seriously consider going down the 64bit route.  This really is: "getting more for less" :-)
 
Agree that you'll have to do some additional testing for driver compatibility etc., but all well-known server vendors provide full x64 driver support and AntiVirus and other similar tools are also available in 64bit versions. Plus don't forget - you can run most of your other 32bit apps very efficiently on x64. For example monitoring tools will take a while until they offer true 64bit agents - but most of the 32bit agents run just fine. Naturally some restrictions do apply - Exchange 2003 is one example, which is not supported on Win2003x64 (and Exchange 12 requires it...). But the main reason for the lack of support for Exchange 2003 is fairly straight forward: Win2003x64 requires that all kernel mode components - including drivers - need to be true 64bit binaries, but Exchange 2003 needs to install a 32 bit driver during setup (exifs.sys => Installable File System driver). Accrd. to MS, this can't be fixed in an SP release.
 
If you're wondering about which apps are known to be compatible to run on Win2003x64, check out this list, which also includes a ton of 32bit apps that are fully supported on Win2003x64: http://www.microsoft.com/windowsserver2003/64bit/x64/app64catalog.aspx
 
 
Anyways, moving your AD DCs to x64 is extremely interesting, as you should typically run them as a closed system anyways (no other LOB apps running on them etc.) - so a perfect way to move to 64bit and gain some experience with the OS, prior to leveraging it for other servers as well. There are things to know and understand about Win2003x64, so this experience will certainly be worthwhile.  And yes, you can run x64 DCs side-by-side with 32bit DCs :-)
 
 
That said, it would be interesting to know, how many of you are considering to leverage the Win2003 x64 OS versions today and what you'd use them for. Or what issues you've ran into while moving to this OS (I'm currently planning a larger AD deployment on x64 with a customer and all is well so far - but it would be good to hear what others have to say).
 
Thanks,
Guido

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan A. Conrad
Sent: Dienstag, 14. Februar 2006 19:29
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] W2K3 Std. vs. Ent. for DCs

Thanks to all...
 
We've been aware of the ram justifications/limitations, but don't have a large enough DIT size (nor do we foresee one in the distant future) alone to justify the memory limitations.
 
If Susan's post is correct about just having the bits loaded properly and we establish a potential MIIS integration with a Ent. DC then I'll toss our ideas out the Window and succumb to the fact that we should save the co. $$$.
 
Ryan

 
On 2/14/06, Almeida Pinto, Jorge de <[EMAIL PROTECTED]> wrote:
yes you could have a mix of DCs where some are std. and some are ent. AD does not care about that. and if you really wanna go nuts you could even throw in datacenter edition! ;-)

don't forget what neil said: think about CURRENT and possible FUTURE requirements

jorge

________________________________

From: [EMAIL PROTECTED] on behalf of Ryan A. Conrad
Sent: Tue 2006-02-14 17:15
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] W2K3 Std. vs. Ent. for DCs


Jorge,

Are you suggesting that some DCs an be Ent. Ed. and some Std.?  I noticed in the matrix that MIIS integration/support was limited to Ent. Ed., as well as pieces of ADFS.  We presently have an empty root (ignoring why we have it, as I don't want to spark any heated conversations), with several child domains that we are working on eliminating. Forest is at 2003 FFL.

Thanks again!

Ryan


On 2/14/06, Almeida Pinto, Jorge de <[EMAIL PROTECTED]> wrote:

       I these are plain vanila DCs standard edition is OK. However it really depends on what additional features you want to use on your DCs. Compare the editions of W2K3 and see what you need for each DC.
       http://www.microsoft.com/windowsserver2003/evaluation/features/comparefeatures.mspx

       jorge

       ________________________________

       From: [EMAIL PROTECTED] on behalf of Ryan A. Conrad
       Sent: Tue 2006-02-14 16:37
       To: ActiveDir@mail.activedir.org
       Subject: [ActiveDir] W2K3 Std. vs. Ent. for DCs


       Dean posted this comment in a recent post:

       ----------------------------
       I have no concerns using Standard edition for DCs, I don't see it too often since the majority of my customers are licensed up the wazoo and use whatever ISO they stumble across first :o)
       ----------------------------

       As ironic as it is, we have recently been prodded by our internal server support group to provide sufficient documentation (beyond saying "because we want it") as to why we need W2K3 Ent. instead of W2K3 Std.  Thus far the only thing official I've been able to come up with is the fact that we have multiple DFS roots.  They seem to think that the license costs for Ent. being 3x that of Std. doesn't justify implementation.

       Can anyone point me to some documentation or specific reasons to stick with Ent.? Ultimately this is what we want for AD, but somehow our desires are not good enough when it comes to $$$ savings.

       Thanks!

       Ryan


       This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.






Reply via email to