What Exchange 2010 on Windows Datacenter Means

Exchange Server has historically come in two flavors for many versions – Standard Edition and Enterprise Edition. The main difference this license change made for you was the maximum number of supported mailbox databases as shown in Table 1:

Version Standard Edition Enterprise Edition
Exchange 2003 1 (75GB max) 20
Exchange 2007 5 50
Exchange 2010 5 100

Table 1: Maximum databases per Exchange editions

However, the Exchange Server edition is not directly tied to the Windows Server edition:

  • For Exchange 2003 failover cluster mailbox servers, Exchange 2007 SCC/CCR environments [1], and  Exchange 2010 DAG environments, you need Windows Server Enterprise Edition in order to get the MSCS cluster component framework.
  • For Exchange 2003 servers running purely as bridgeheads or front-end servers, or Exchange 2007/2010 HT, CAS, ET, and UM servers, you only need Windows Server Standard Edition.

I’ve seen some discussion around the fact that Exchange 2010 will install on Windows Server 2008 Datacenter Edition and Windows Server 2008 R2 Datacenter Edition, even though it’s not supported there and is not listed in the Operating System requirements section of the TechNet documentation.

HOWEVER…if we look at the Prerequisites for Exchange 2010 Server section of the Exchange Server 2010 Licensing site, we now see that Datacenter edition is, in fact listed as shown in Figure 1:

Exchange 2010 server license comparison

Figure 1: Exchange 2010 server license comparison

This is pretty cool, and the appropriate TechNet documentation is in the process of being updated to reflect this. What this means is that you can deploy Exchange 2010 on Windows Server Datacenter Edition; the differences between editions of Windows Server 2008 R2 are found here.[2] If you take a quick scan through the various feature comparison charts in the sidebar, you might wonder why anyone would want to install Exchange 2010 on Windows Server Datacenter Edition; it’s more costly and seems to provide the same benefits. However, take a look at the technical specifications comparison; this is, I believe, the meat of the matter:

  • Both editions give you a maximum of 2 TB – more than you can realistically throw at Exchange 2010.
  • Enterprise Edition gives you support for a maximum eight (8) x64 CPU sockets, while Datacenter Edition gives you sixty-four (64). With quad-core CPUs, this means a total of 32 cores under Enterprise vs. 256 cores under Datacenter.
  • With the appropriate hardware, you can hot-add memory in Enterprise Edition. However, you can’t perform a hot-replace, nor can you hot-add or hot-replace CPUs under Enterprise. With Datacenter, you can hot-add and hot-remove both memory and CPUs.

These seem to be compelling in many scenarios at first glance, unless you’re familiar with the recommended maximum configurations for Exchange 2010 server sizing. IIRC, the maximum CPUs that are recommended for most Exchange 2010 server configurations (including multirole servers) would be 24 cores – which fits into the 8 socket limitation of Enterprise Edition while using quad core CPUs.

With both Intel and AMD now offering hexa-core (6 core) CPUs, you can move up to 48 cores in Enterprise Edition. This is more than enough for any practical deployment of Exchange Server 2010 I can think of at this time, unless future service packs drastically change the CPU performance factors. Both Enterprise and Datacenter give you a ceiling of 2TB of RAM, which is far greater than required by even the most aggressively gigantic mailbox load I’d want to place on a single server. I’m having a difficult time seeing how anyone could realistically build out an Exchange 2010 server that goes beyond the performance and scalability limits of Enterprise Edition in any meaningful way.

In fact, I can think of only three reasons someone would want to run Exchange 2010 on Windows Server Datacenter Edition:

  • You have spare Datacenter Edition licenses, aren’t going to use them, and don’t want to buy more Enterprise Edition licenses. This must be a tough place to be in, but it can happen under certain scenarios.
  • You have a very high server availability requirements and require the hot-add/hot-replace capabilities. This will get costly – the server hardware that supports this isn’t cheap – but if you need it, you need it.
  • You’re already running a big beefy box with Datacenter and virtualization[3]. The box has spare capacity, so you want to make use of it.

The first two make sense. The last one, though, I’d be somewhat leery of doing. Seriously, think about this – I’m spending money on monstrous hardware with awesome fault tolerance capabilities, I’ve forked over for an OS license[4] that gives me the right to unlimited virtual machines, and now I’m going to clutter up my disaster recovery operations by mixing Exchange and other applications (including virtualization) in the same host OS instance? That may be great for a lab environment, but I’d have a long conversation with any customer who wanted to do this under production. Seriously, just spin up a new VM, use Windows Server Enterprise Edition, and go to town. The loss of hardware configuration flexibility I get from going virtual is less than I gain by compartmentalizing my Exchange server to its own machine, along with the ability to move that virtual machine to any virtualization host I have.

So, there you have it: Exchange 2010 can now be run on Windows Server Datacenter Edition, which means yay! for options. But in the end, I don’t expect this to make a difference for any of the deployments I’m like to be working on. This is a great move for a small handful of customers who really need this.

[1] MSCS is not required for Exchange 2007 SCR, although manual target activation can be easier in some scenarios if your target is configured as a single passive node cluster.

[2] From what I can tell, the same specs seem to be valid for Windows Server 2008, with the caveat that Windows Server 2008 R2 doesn’t offer a 32-bit version so the chart doesn’t give that information. However, since Exchange 2010 is x64 only, this is a moot point.

[3] This is often an attractive option, since you can hosted an unlimited number of Windows Server virtual machines without having to buy further Windows Server licenses for them.

[4] Remember that Datacenter is not licensed at a flat cost per server like Enterprise is; it’s licensed per socket. The beefier the machine you run it on, the more you pay.


  1. Kevin Miller says

    Another Difference between Enterprise and Datacenter is the number the Hyper-V guests you can have. If I remember right 5 for enterprise and unlimited for Datacenter.

  2. says

    Kevin, that’s true, but it only comes into play if you’re running Exchange on the host. Those virtualizations licenses allow you to run the same edition as the host or downgrade; if I were running Datacenter on the host, I could run Datacenter (although what’s the point there?), Enterprise, or Standard in my VMs. If I were running Enterprise on the host, I could run either Enterprise or Standard in the VMs.

    However, here’s a key difference: for Enterprise, I only get those extra VMs license *if virtualization is the only host-level application I run*. That is, I’ve only added the Hyper-V role or equivalent (because IIRC the licenses can be used with other virtualization suites, not just Hyper-V). If that host server performs any other role, I’m violating the licensing and don’t get the additional licenses for the guest VMs. On the other hand, with Datacenter, which is licensed by CPU socket, there seem to be no such restrictions.

    At any point, the VM licensing is kind of moot for whether I’m running Exchange directly on those editions — unless I want to run virtualization and Exchange side-by-side. I’d argue that’s a less than optimal thing to do.

  3. Sigi says


    When I was writing the Exchange 2010 Best Practices book for MS Press, I came over various discussions thus I wanted to clarify the information you posted here:
    – Exchange 2010 Standard edition can “mount” up to 5 databases, you can have up to 257 local databases maximum (active “mounted and passive “non-mounted”) on the server. The same applies to Exchange 2010 Enterprise edition.
    – Exchange 2010 Enterprise Edition has a technical database limitation of 16 TB, the 2 TB is the max. recommed size if you use JBOD disks and have at least 3 database copies in a DAG. If you have 1 Database copy only, still the 200 GB recommendation applies.
    – Exchange 2010 Standard still has a database limit of somewhere about 1024 GB, but you change that limit to the maximum of 16 TB
    – Exchange 2010 does run on more than 32 cores, but it reduces the speed of exchange as Windows needs more cycles to handle all the processors. Thus it is not recommended to go above 32 cores, if you reach 64 cores, you will see a dramatic decrease in performance.

    Just to clarify these small but important things


  4. says

    I must say that is it not true that “Exchange 2010 Standard edition can “mount” up to 5 databases, you can have up to 257 local databases maximum (active “mounted and passive “non-mounted”) on the server. The same applies to Exchange 2010 Enterprise edition.”

    You can have a total of 5 databases on the Exchange STANDARD, both active and passive databases, unfortunately.(example: 5 active + 0 passive, or 3 active + 2 passive DBs)

    Please check the following article for demo:


  5. says

    Thanks for the clarification on the server cores and database sizes for Exchange 2010 editions. However, the article was about what physical cores and RAM are supported under *Windows Server*.

    According to http://technet.microsoft.com/en-us/library/bb232092.aspx Exchange 2010 Standard has a default 50GB size limit for databases (although it can be easily changed, so it’s not a hard ceiling as was the case in Exchange 2003).

    I’ve seen a lot of back-and-forth on the merits of going over the 32-core recommendation. One opinion that I lean toward is that it is worth taking the performance penalty if it’s cheaper to add the cores to meet the load (plus penalthy) than it would be to outfit another server to handle the same load on “fewer” cores.

  6. says

    Ilsa’s experiment that you linked to only tells us that Exchange 2010 recognizes DAG replicas somehow as “mounted” in some state (since even if they’re not mounted on the local server, they could very well be mounted on another server in the DAG. I cannot find the reference to support it, but I believe that you can in fact create many more local non-replicated databases as long as no more than 5/100 (Standard/Enterprise) databases are mounted, whether local databses actually mounted or DAG replicas irrespective of state.