Zoho Banner September 2011

Archive for October, 2008


The other day I had a customer ask what the recommended maximum database size is for Exchange Server 2007 mailbox stores.  I knew I had seen the information somewhere on-line, so I did some Googling.  Initially, I didn’t have much luck. 

First of all I found the article below, which recommends stores grow no larger than 50GB. On the other hand it also mentions .stm files (no longer used in Exchange 2007), so I wasn’t convinced it is still relevant.


Then I found KB823144, which also recommends a 50GB max, but the article only applies to Exchange 2003.

After that, I found the following Blog entry written by Gerod Serafin.  The article references some Microsoft on-line content that talks about different recommendations, but comes back to the 50GB recommendation.


Feeling somewhat confused, I put the question to the Exchange MVP brains trust.  I was referred to the on-line Technet article that covers Mailbox Server Storage Design.  This provides the authoritative recommendation for Exchange Server 2007, as quoted below.

We recommend the following maximum database sizes for Exchange 2007:

  • Databases hosted on a Mailbox server without continuous replication: 100 GB
  • Databases hosted on a Mailbox server with continuous replication and gigabit Ethernet: 200 GB


    Large databases may also require newer storage technology for increased bandwidth to accommodate repair scenarios.


    The true maximum size for your databases should be dictated by the SLA in place at your organization. Determining the largest size database that can be backed up and restored within the period specified in your organization’s SLA is how you determine the maximum size for your databases.

For me, the key element is the comment regarding the SLA in place within your organisation.  When carrying out a high level design the 100GB/200GB recommended maximums shown above are good starting points, but these may need to be adjusted during your proof of concept phase.


Last week I initiated a discussion on the ActiveDir.org mailing list about running Windows Server 2008 Domain Controllers on Server Core.  I was curious to see whether there were any good reasons why all DCs (RODCs and RWDCs) should not be run on Server Core as a best practice.   The conclusion reached was that, with the possible exception of smaller organisations, the benefits of Server Core far outweigh any limitations.

Why Server Core is a good thing

  • Because it installs only a subset of the full operating system, Server Core provides a smaller surface area for potential security compromise.
  • Server Core requires fewer patches, thereby reducing both the administrative overhead and the potential risk of instability.
  • Server Core has a lower system resource overhead, delivering a better bang-for-buck for your server hardware investment.
  • Because of it’s small footprint, Server Core lends itself to virtualisation, again delivering a better return on your hardware investment.

Server Core sounds perfect, so why isn’t everyone using it?

  • There is no UI, which means that administrators unfamiliar with the command line have to get to grips with new ways of doing things.  Having said that, you still have the option to run all of the AD admin tools remotely by running RSAT on a machine running VISTA or the full UI version of Windows Server 2008.
  • DC promotion becomes a little more long-winded as it requires you to create an answer file and run DCPROMO in unattended mode.
  • The .NET Framework (and hence Powershell) is not supported, which means you cannot run code locally that requires the Framework.  There are however a number of workarounds to this and changes coming in Powershell 2.0 improve the options for running cmdlets against remote computers.

Despite the minor inconveniences for administrators I would recommend using Server Core for all your Windows Server 2008 Domain Controllers.  For me benefits are too compelling not to.   I predict that as more Windows Server 2008 forests are deployed, Domain Controllers on Server Core will start to be considered best practice.  I also believe that Server Core will become the primary Windows Server platform within the next 10 years, with the full UI version either vanishing altogether or becoming marginalised for use only in small organisations. 

But then I chose Betamax over VHS, so what do I know. :-)


Yes, I know PST files are BAD, but due to circumstances that would take too long to explain, I still use SMTP and POP3 with Outlook 2007 for my home email.  The other day I had a power outage that caused a corruption to one of my PST files.  I know that you can repair PSTs within SCANPST, so I Googled where to find it.

The Microsoft KB article, How to use the Inbox Repair Tools to recover e-mail messages in Outlook 2002, Outlook 2003 and Outlook 2007 has this to say on the location of SCANPST.EXE:

“The Inbox Repair Tool installs automatically during setup. These programs are typically located in one of the following folders:

disk drive :\Program Files\Common Files\System\Mapi\1033\

disk drive :\Program Files\Common Files\System\MSMAPI\1033

For a 64-bit operating system, the programs are typically installed in one of the following folders:

disk drive:\Program Files(x86)\Common Files\System\Mapi\1033\

disk drive:\Program Files(x86)\Common Files\System\MSMAPI\1033″

The problem was I couldn’t find my SCANPST in any of the location mentioned. Eventually, after searching my Vista machine with the option “Include non-indexed, hidden and system files (might be slow)” I found it here:

C:\Program Files\Microsoft Office\Office12

They weren’t kidding about the “might be slow” part.  Anyway, after locating the file, it worked perfectly for my problem.

I’ve provided feedback on the KB article, so hopefully Microsoft will update the location soon.


Yesterday I fired up an old Exchange Server 2007 VM lab environment.  The first thing I saw when I started the Exchange Management Console (EMC) was a pop-up message saying, “The following servers in your organization are currently unlicensed”, as shown below.

Licence expiry warning

After clicking OK, I got the another pop-up message saying, “The server ‘<server_name>’ is unlicensed and has exceeded its trial period for licensing.

Licence expiry warning 2

Fair enough, it had been a long time since I had installed the test environment.  After obtaining a valid license key from MSDN I went back to the EMC to update the product key.  The only problem was I couldn’t find the option anywhere!  I found the following information on Technet:

“Open the Exchange Management Console.

  • In the console tree, expand Server Configuration.
  • In the result pane, select the server that you want to license.
  • In the action pane, under the server name, click Enter Product Key. The Enter Product Key wizard appears.
  • On the Enter Product Key page, type the product key for the Exchange server, and then click Enter.”

Even with these instructions I still couldn’t find the option. 

Action Pane

Then it struck me that I was using the 32-bit version of Exchange Server 2007, which clearly can’t be licensed because it is not supported for production use.  Doh!

After some further digging I even found wording in the Help documentation that talks about entering the product key:

This action is available only if you installed the 64-bit version of Exchange 2007″

RTFM anyone? :-)

Because you cannot license a 32-bit version of Exchange Server 2007 your options are to either re-install the trial version or to live with the warning messages.  Interestingly the license warnings are just that – i .e. they do not impede or remove functionality.

I thought I would blog about this to save others from going through the same time-wasting process :-)