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.

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.

If you are installing Exchange 2010 and looking for a little help building some guide templates for your deployment Microsoft has released some new templates.

Overview

You can use these templates as a starting point for formally documenting your organization’s server build procedures for servers that will have Microsoft Exchange Server 2010 server roles installed on them. Templates are provided for the Client Access, Hub Transport, and Mailbox server roles, plus a template for the Mailbox role configured for a database availability group.

Click here to download…

Ok, now this is very cool. Courtesy of Bharat Suneja of the MS Exchange team this article walks you through the steps of adding photos to your GAL.

The process is broken down into three steps:

1. A minor schema change
2. Loading the picture into Active Directory
3. Updating the Offline Address Book

Instructions: Click here to read the original article…

Other Useful Links…

• GAL Photos: FAQ
• Click here for a step by step with screen shots and a nice script to help import pictures for multiple users…

Originally released in November of 2009, this tool was created based on customer feedback and helps streamline the deployment experience for Exchange customers whishing to upgrade or deploy a new installation of Exchange 2010.

Review the MS Exchange Team’s for more information…

Overview

Microsoft Exchange Server 2010 introduces the Exchange Deployment Assistant or ExDeploy, a new Web-based tool that can help you with your Exchange deployment. ExDeploy asks you a few questions about your current environment and then generates a custom checklist and procedures that help simplify your deployment.

You can use ExDeploy for the following scenarios:

• Upgrade from Exchange Server 2003
• Upgrade from Exchange 2007
• Upgrade from mixed Exchange 2003 and Exchange Server 2007
• New installation of Exchange 2010

To access ExDeploy, see Exchange Server 2010 Deployment Assistant.

Special thanks to fellow colleague and Exchange MVP Dustin Smith for sharing…

As you know, Exchange 2010 became generally available last November.  Unfortunately, the GA version had several issues which prevented Unity Unified Messaging interoperability. Cisco and Microsoft together have identified these issues and as of mid-December Microsoft has delivered an updated version of MAPI addressing the primary issues. Cisco is now working aggressively to validate the new MAPI version as well as make the necessary changes in Unity to support Exchange 2010 as follows:

Unity 7.X – March 31, 2010

Unity 5.X – May 31, 2010

Unity 8.X – June 30, 2010

We urge Unity 4.X Unified Messaging customers who plan to upgrade to Exchange 2010 to first upgrade to Unity 7.X once the ES is available in preparation for their upgrade to Exchange 2010.

As for Meeting Place, unfortunately planned support for Office (Outlook) 2010 has been pushed back to MP 8.5, which is not even officially announced at this point.  It’s possible this could be supported in a later version of 8.0 once that has been released, but for 6.0 and 7.0 there is nothing planned.

Customers should ultimately be working with their Cisco representative if they are considering Exchange 2010 soon, but this will at least provide some ideas when Unity support is expected.