Determining the megacycles per core value of your Exchange Mailbox server platform is more of an art than a science.  Though Microsoft provides instructions on how to do this, I thought they could use some massaging to make them more user friendly.  To determine the megacycles per core value of your chosen server platform follow the steps below.

Calculating the formula’s values

New Platform per Core Value

1. Open a web browser and go to www.spec.org or you can click here and go straight to Step 7.
2. Select Results Search from the menu.
3. Click Search. (No need to specify any value in the search field)
4. Under Available Configurations at the top, select SPECint2006 Rates.
5. Select Simple under Search Request Form.
6. Click Go.
7. Under Simple Request, choose the search value (e.g. Processor) and enter the search criteria (e.g. x5550).
8. Click Execute Simple Fetch.
9. Find the server and processor you are planning to deploy and take note of the Result value.  For example, let’s say you are deploying a Dell PowerEdge M710 server with Intel x5550 2.67GHz processors (8 cores).  The SPECint_Rate2006 Result value is 240.  This translates to a a value of 30 per core (Result/# of cores or 240/8).  This value is known in the formula as “New platform per core value“.

Baseline per Core Value

The platform used to determine the Storage Calculator baseline of 3300 megacycles is an HP DL380 G5 x5470 3.33GHz with 8 cores.  This has a SPECint_Rate2006 Result value of 150, or 18.75 per core.  This is known in the formula as “Baseline per core value“.

Calculate the total Megacycles per Core

To determine the megacycles of the new platform, we will use the following formula:

Megacycles/core = ((New platform per core value) * (Hertz per core of new platform)) / (Baseline per core value)

= 30 * 2670 / 18.75

= 4272 megacycles/core

Enter this value into the Megacycles/Core field under the Server Configuration section of the MS Mailbox Role Storage Calculator.

Virtualization Factor

To calculate the total Mailbox Role CPU Megacycles requirement when hosting the Mailbox servers in a virtual platform add an additional 10% overhead for the host OS.  IE: If your total megacycle requirements per server is 16000 then virtualizing the Mailbox role will increase that value to 17600 megacycles per server.

To calculate the megacycles per core value when virtualizing the Exchange Mailbox role use the hardware platform of your host server to determine the “New platform per core value”.

Other Roles

To determine how many cores you will need for your Client Acces, Hub Tranport and Global Catalog server use this table as a guide.

For more detailed information on calculating server core ratios for the different Exchange server roles, see the Microsoft documentation at: http://technet.microsoft.com/en-us/library/dd346701.aspx.

Overview

The Office Communications Server Netmon Parsers are a set of files that extend the parsers in Microsoft Network Monitor. The Microsoft Network Monitor tool loads these files and uses the rules defined in them to analyze network traffic.

Click here to download…

Other noteworthy links…

• Network Monitor Open Source Parsers
• Network Monitor Blog
• Download Network Monitor

This provides early adopters of the new application with a basic protection option in advance of support planned for the next release of the NetWorker Module for Microsoft Applications

The new option is made available via a small NetWorker plug-in and an EMC Technical Note, and is supplemented by step-by-step backup and recovery instructions in the NetWorker Procedure Generator. With it NetWorker users gain:

• Full backup support for Exchange 2010 server, database, and volume levels (incremental backups are not supported).
• Database Availability Group (DAG) support, including DAG Active Node and Passive Node backups.
• Optional Exchange consistency checks.
• VSS software provider support.
• Server and database recovery.
• Recovery Database (RDB) recovery.
• Directed database recovery.
• Mailbox level recovery via RDBs and Exchange tools.
• Deduplication via Avamar or Data Domain.

Solution Information

The new solution is available for use with NetWorker 7.5 SP2 and requires the software plug-in and the NetWorker client software. For full details and download information, read the Microsoft Exchange 2010 Backup and Recovery Support with EMC NetWorker Technical Note.

Below you’ll find a few useful links to automating the installation of prerequisites and rollups for Exchange 2010.  There are a couple different flavors.  I encourage you to try them out for yourselves and let me know which one you like better and why.

• Ucblogs.net: Automated prerequisite installation via PowerShell for Exchange Server 2010 on Windows Server 2008 R2 – v2.0
• Exchangemaster.net: How to install Exchange 2010 prerequisites automatically
• TechNet Bhargav Shukla: How to install Update Rollups remotely on Exchange 2010 server

Other useful links…

• For a detailed listing of prerequisites for Exchange 2010 follow this link…
• For a nice list of useful Exchange 2010 tools follow this link…
• To download the offline Exchange help file for easy reference click here…
• For information on the Office 2010 Filter Pack for Exchange click here…

While recently attending TEC2010 in Los Angeles, I was asked what do I think of deploying Exchange 2010 using JBOD and why do I need to use network attached storage?  After discussing the topic in length with both attendees and presenters it became clear that there was a misunderstanding of what JBOD means for Exchange 2010.  Simply put, JBOD means that you will not be using the native RAID features of your storage platform and instead rely on Exchange 2010 to manage individual database protection.  Ergo, one database and log set per disk.  With JBOD, a disk failure equals a database failover which equals a reseed.

Microsoft’s targeted I/O ranges for Exchange 2010 were driven by the goal of deploying Exchange 2010 on cheaper, lower I/O, higher capacity 7.2k SATA disks.   The concept of one database and log set per disk sounds promising providing you are deploying your architecture in line with Microsoft’s supported recommendation of managing at least three copies of each database.  For more details on Exchange 2010’s mailbox storage requirements click here.

A typical enterprise class 2TB 3G 7.2k 3.5” SATA drive retails for around $950.  (Bulk and vendor discounts are not applied)  That will equal a rough disk cost estimate of $2850 per database for a supported JBOD architecture.  We’ will need a minimum of three mailbox servers with three DAS arrays so we don’t have a single point of failure.  With Exchange 2010 we can now combine the CAS, HUB and Mailbox role onto a single server to keep server hardware and licensing costs down.  Be aware that if the CAS and the Mailbox role reside on the same server and said server is a member of a DAG Windows Network Load Balancing will not be available.  A hardware load balancer will be required to achieve true high availability among the Client Access services.

Using Microsoft’s Mailbox role storage calculator for Exchange 2010 with the following data let’s examine the results.

• User count: 1000
• Disk specs: 2TB 7.2k SATA 3.5” – ~$950 each
• Mailbox Servers: 3
• DAG: 1
• User profile: 250 message per day (your mileage will vary)
• Mailbox Size: 5GB (most companies will choose smaller values)
• Multi-role: Yes
• Lagged Copies: 0
• HA: Yes
• Site Resiliency: No

Reviewing the JBOD storage recommendations we are looking at six disks for the databases at a cost of $2850 per database.  Total disk cost for all servers is ~$17,100.  Each disk is only being utilized up to 1.6TB effectively losing 20% of total disk capacity.  At only 6 disks per mailbox server, there are a number of DAS storage options available.  There are a number of considerations we are not factoring into our calculations such as backup strategy, I/O requirements, preferred vendors, rack and power requirements, etc…  I want to keep this example as simple as possible.  Microsoft recommends that if you want to go backup-less you will need at least one lagged copy in your environment.

Scale things up a bit to 10,000 users and the results are dramatic.

Disk count has now increased by 95% from six disks per server to 57, or 171 disks total.  Total disk cost is now at ~$163,000.  Now considering that each Mailbox server will need at least 57 disks the DAS vendor options are reduced.  Doing a quick search on the Internet shows a typical DAS unit retails for around $75k with support for up to 70 2TB disks.  (your mileage will vary)

For a 10,000 user environment we are now at total cost of ~$225,000 for the DAS array with disks.  Since we are only utilizing ~80% percent of the total capacity of the DAS, we are wasting about $45,000 of our initial investment.  Pause for a moment here and think of the overhead involved with administrating 171 database copies.  Since the storage device is dedicated to Exchange we will be unable to allocate the unused 20% of capacity to other applications in our environment but, at least we have room for growth.

At 20,000 users (all things still being equal) three Mailbox servers isn’t going to support the environment.  Two more mailbox servers will need to be added along with two more DAS arrays to support the solution.  Disk count increased to 66 per server for a total of 330 disks or databases.  That’s an increase of 48%.  Now what if you don’t want to go with the 2TB disks and only can afford a 1TB disk?  Add two more mailbox servers for a total of seven and we are now at 90 disks per server or 630 disks/databases total.  I’m not going to even do the math, you get the point.

I hope this has helped illustrate the often overlooked complexities involved in deploying JBOD with DAS and the extra overhead that comes with scaling the solution.  Exchange administrators are very excited about the new JBOD option but do your homework, weigh all the options, talk to your storage vendors or consult a professional consulting services organization for planning assistance.  In the end, the initial investment will be well worth it in the long run.  More often your specific business needs will be better served investing in a SAN or NAS device where the storage services can be shared among servers and the technologies of thin provisioning and tiered storage can be implemented.  As this white paper illustrates, your initial investment in a SAN/NAS solution will provide a better TCO overall and a better quality of life for your Exchange administrators.

In our 10,000 user example introducing RAID would reduces our database count by 47% to 36 while also allowing a reduction in the number of database copies to two.    Disk count increases 29% from 57 to 80 but, let’s face it, not all users in your environment have (or require) 5 GB of mail data.  Keep in mind the mailbox role calculator designs the storage for 120% of mailbox capacity.  Realistically you would design a tiered model at around 1 GB for the general population with a small portion of the staff getting a larger mailbox capacity.  Or maybe you want everyone to have higher a mailbox capacity and import the user’s PSTs into their mailbox and eliminating the use of PSTs altogether.  With Exchange 2010, Microsoft now considers a mailbox above 10GB to be “large.”

But don’t just take my word for it.  Here are some articles worth reading.

• From Whence Redundancy? Exchange 2010 Storage Essays, part 1
• The Disk’s The Thing! Exchange 2010 Storage Essays, part 2
• FAS, the new DAS – Using FAS in a DAS configuration for Exchange
• Why Microsoft’s Head is up its DAS
• TechEd Online – Storage in Microsoft Exchange Server 2010
• TechNet Webast – How Microsoft IT Deployed Exchange 2010 on Premises

Considering all the benefits around TCO, capacity utilization, scalability, management, HA, DR, Backup and Recovery and Server Virtualization…is DAS the right choice for you?  Exchange is often a business critical application and the underlying infrastructure should reflect that.

Below is a matrix put together by the Exchange product team displaying their recommended guidance for Exchange 2010 storage.

One of the best sources for Exchange information is the online TechNet library.  However if you aren’t online or have a slow internet connection then this is the best substitute.  These are quite literally copies of what you’ll find on the TechNet Library.  These files are in CHM format and can be easily viewed offline at your leisure.  A great reference for anyone working with Exchange.  Check back regularly as they are updated often.

Exchange Server 2010 Help

Exchange Server 2007 SP2 Help

Online TechNet Library for Exchange

Looking for more information on load balancing Exchange 2010?

Load Balancing Requirements of Exchange Protocols

Microsoft Exchange protocols and client access services have different load balancing requirements. Some Microsoft Exchange protocols and client access services require client to Client Access server affinity. Others will work without it but will display performance improvements from such affinity. Other Exchange protocols don’t require client to Client Access server affinity and performance doesn’t decrease without affinity.

Topics

• Exchange protocols that require client to CAS affinity
• Exchange protocols that benefit from client to CAS affinity
• Exchange protocols that don’t require affinity
• Understating IP ports

Understanding Load Balancing in Exchange 2010

Load balancing is a way to manage which of your servers receive traffic. Load balancing provides failover redundancy to ensure your users continue to receive Exchange service in case of computer failure. It also enables your deployment to handle more traffic than one server can process while offering a single host name for your clients.

Topics

• Overview of Load Balancing
• Understanding Exchange 2010 Traffic loads
• Understanding Load Balancing Options
• Load Balancing Recommendations
• Affinity Options

Other Useful links…

• Script to configure static ports on Exchange Server 2010
• Exchange 2010 Databases and the RPCClientAccessServer Database Parameter
• Exchange 2010 RTM High Availability Load Balancing Options
• Configuring WNLB for Exchange 2010 CAS Load Balancing
• Exploring Exchange 2010 RPC Client Access service

Commissioned by EMC and is distributed under license from ESG, this recently released white paper by Mark Peters includes topics on the Current Market Situation, Options and Opportunities, Implementation Considerations and the Bigger Truth as they relate to networked storage and direct attached storage (DAS).

Synopsis

Beginning with a brief discussion of the current market situation, Mark discusses the decades old IT trend of the replacement of rigid DAS systems with a more flexible storage architecture.  Mark makes special note how this trend is very strong in virtual server environments.   Despite the strong encouragement from Microsoft to run Exchange 2010 on DAS, almost two thirds of the leading edge adopters of Exchange 2010 are favoring networked storage over DAS.  There are clear advantages that Microsoft gains by pushing DAS over NAS/SAN, citing tighter integration, lower costs and improved application performance.  As Mark is quick to point out, this all comes at a cost of flexibility and management.  IT administrators could quickly find themselves in a situation where they are managing dozens (if not hundreds) of independent and isolated storage platforms.  If more capacity is needed, free space from another server cannot be used resulting in poor storage utilization.  Backup and DR operations need to be executed and monitored on individual servers.  Microsoft specific tools such as VSS are free, but are traditionally suited for simple environments with few servers and minimal storage capacity as they too are configured on a per device basis.  It’s no secret that Microsoft has made great strides in reducing the IO load that Exchange 2010 places upon storage, which Microsoft states can make DAS more relevant, but it can be easily argued that this makes it easier to benefit from the many other advantages that a network storage model provides.  Networked storage devices can benefit the entire data center and business including, but not limited to, Exchange and SQL.  Such areas of improvements can be seen in TCO, capacity utilization, scalability, management, high availability, disaster recovery, backup and recovery and server virtualization.

Exchange and SQL are often business critical applications and their underlying infrastructure should reflect that.  In the holistic sense of making progress, networked storage can be an engine whereas DAS can all too easily become an anchor.  The job of IT is to deliver business value, whether that’s measured as minimizing cost, maximizing agility or reducing risk.

Click here to download the white paper…

Regardless of your opinion on the subject, the white paper is a good read and provides some good food for thought when the time comes for a decision to be made on the storage platform for your Exchange 2010 architecture.  I hold high praise for the Exchange product team, especially those working on the ESE engine and their hard efforts to reduce the IO load of Exchange.  I welcome the additional storage choices available to Exchange 2010. As Mark points out, there are many factors that should be considered when choosing your storage platform for your Exchange architecture.  Consult your vendors, ask questions and read between the lines.  If you are overwhelmed with options and don’t know which way to go, get help.  It’s a immeasurably cheaper in the long run to start your design with a solid foundation than have to change gears a year into the project.  Just because you can use DAS, doesn’t mean that it’s best for your business model.

Outlook 2010 introduced a change to the way the AutoComplete list (aka: nickname cache) is stored on the client.  The new Roaming AutoComplete list is now stored on the Exchange Server. A user’s recipient AutoComplete list is now available to any computer on which Outlook 2010 runs that is connected to the same Exchange account. Individual names can be easily removed from the list by using the new inline Delete function.  Just simply type the first few characters of the name you wish to delete and press the Delete key or click the X.

What this means for you is that your AutoComplete list is synchronized between platforms: OWA, Windows Mobile and Outlook will all share the same AutoComplete list.  While this sounds up front like a great enhancement there are some changes that you need to be aware of in case you need to clear this list.

First, there is no more NK2 file.  The actual file you are looking for is located is:

C:\Users\%username%\AppData\Local\Microsoft\Outlook\RoamCache\Stream_Autocomplete*.dat.

Deleting this file will not clear your AutoComplete list.  As soon as you start Outlook 2010 the file will reappear, along with any bad addresses.  So how does one clear the entire list?

Use one of the methods listed below to reset the Outlook nickname cache for Microsoft Outlook 2010.

Method 1

1. With Outlook 2010 open, click File (BackStage), and then click Options.
2. Click the Mail tab.
3. Under Send Messages, click Empty Auto-Complete List.

Outlook will generate a new nickname cache.

Method 2

1. Click Start, and then click Run.
2. Start Outlook by using the /CleanAutoCompleteCache switch.
   For example: Outlook.exe /CleanAutoCompleteCache
   Note If Outlook is not installed in the default location, you will need to point to the path of Outlook.exe.

Outlook will generate a new nickname cache.

Reference KB287623 for more information…