Are you prepared for outages that affect e-mail service or data availability? Have you defined recovery strategies and procedures for disasters big and small?

This Webcast will cover the recommended strategies for protecting Microsoft Exchange Server 2007 messaging service and data, with an emphasis on the ultimate disaster: a full site failure.  Join Scott Schnoll this Friday (August 15, 2008) from 9:30 AM to 10:30 AM PST as he dives deep into standby continuous replication (SCR), which was designed with these disasters in mind. This is a 300-400 level Webcast that covers disaster recovery options and strategies for Exchange 2007 SP1, standby continuous replication, and site resilience.

You can register for this free Webcast at http://msevents.microsoft.com/CUI/EventDetail.aspx?EventID=1032381322&Culture=en-US.

WEB HOST INDUSTRY REVIEW) -- In a major extension of its server virtualization offerings for Apple environments, cloud services automation and virtualization software Parallels (www.parallels.com) has introduced the world's first bare-metal hypervisor solution for the Apple Xserve.

According to the company's Wednesday announcement, Parallels Server for Mac Bare Metal Edition offers greater performance for applications running in virtual machines on the Xserve, and enable businesses to standardize on the Apple platform, and open a new opportunity for cloud services providers to offer profitable Mac OS X services. The addition of Parallels Virtual Automation provides comprehensive management tools for monitoring and maintaining the virtual environment.

"The 33 percent year-on-year increase in sales of Macintosh computers reported by Apple this quarter indicates a growing interest in Apple hardware," Parallels chief executive officer Serguei Beloussov said in a statement. "Virtualization solutions can help make this a practical reality for users, giving them the ability to run the Windows and Linux applications they need on the Apple system they want. Parallels Server for Mac Bare Metal Edition provides a high performance solution that enables IT professionals and developers to capitalize on the power of Mac OS X Server while having the flexibility to run Windows and Linux workloads both on-premise and through the Cloud."

Building on Parallels' virtualization portfolio for Apple environments (most notably the existing server virtualization solution, Parallels Server for Mac), the new architecture represents the first ever bare-metal hypervisor for Intel-powered Apple systems, offering users greater performance and hot migration, the ability to migrate systems without needing to go completely offline.

"The Xserve offers unbeatable performance, and Mac OS X Server is the world's easiest to use server operating system," said Ron Okamoto, Apple's vice president of Worldwide Developer Relations. "With the Mac more popular than ever, and Parallels' new virtualization tools, there has never been a better or easier time for entire organizations to switch to Mac." 

Not just for on-premise deployments, Parallels Server for Mac Bare Metal Edition presents an opportunity for cloud services providers to diversify their offerings into new growth areas -- capitalizing on Apple's popularity. Parallels' service provider partners can quickly and easily offer profitable Mac OS X services, including Virtual Private Servers and application hosting as a cloud service. 

At this week's Parallels Summit in Miami, hosting company Go Daddy (www.godaddy.com) announced plans to offer Mac OS X services based on virtual private servers built on Parallels Server for Mac Bare Metal Edition. "Go Daddy is always looking for ways to enhance our customer experience, and provide simple solutions," Go Daddy chief operating officer and president Warren Adelman said in a statement. "We do this by offering the products our customers want and need. Together with the innovative minds at Parallels and the usability experts at Apple, we have opened the door to a line of Mac OS X hosting products."

With the release of Exchange 2007 SP2 we provided a Supportability Matrix which outlined the supported configurations for Exchange 2000 SP3, Exchange 2003 SP2, and Exchange 2007 (RTM, SP1, and SP2).   But as many are aware, with the release of Windows Server 2008 R2 there have been a variety of questions raised about our support policies and a multitude of feedback.  Two pieces of feedback occurred numerous times -  the need to support Exchange 2007 on Windows Server 2008 R2 and the need to support Exchange 2003 against Windows Server 2008 R2 Active Directory servers. 

In response to this feedback we will be making several updates to the supportability matrix.

• As I recently blogged about, we will be adding support for Exchange 2007 on the Windows Server 2008 R2 platform.   While we had hoped to add this application/operating system combination quickly, unfortunately adding this support requires code changes to setup in Exchange 2007.  Therefore, our vehicle for adding this support will be via a third Service Pack for Exchange 2007 in the second half of calendar year 2010.
• Exchange 2003 SP2 will now be supported against writeable Windows Server 2008 R2 Active Directory Servers.  Additionally, with the General Availability of Exchange Server 2010, and those looking to standardize on Windows Server 2008 R2 we have enhanced the supportability of forest and domain functional levels up to Windows Server 2008 R2.  This change is effective immediately on Exchange 2003 SP2.
• Exchange 2007 is now supported on servers running .NET Framework 3.5 SP1 provided that the .NET platform was upgraded from .NET Framework 2.0.  This change is also effective immediately on Exchange 2007 SP2.

Each of these changes are being made to provide the flexibility you requested - to change your operating system architecture without changing your messaging architecture.  In addition to the existing combinations, we will be adding supportability guidance for Exchange 2010 to the matrix.    Note that all of these changes may not immediately appear on the supportability matrix, but be assured that any documentation update lag will not affect your supportability with Microsoft Support.

Finally I do want to update all on one other piece of feedback we have received - allowing the in place upgrade of the operating system under Exchange.  Technically the work required to provide this capability is consistent with the work we would need to do to support an in-place upgrade of Exchange itself.  As such the amount of work needed is outside the scope and complexity of what we can do in a post release product update.  Still we do understand the demand and desire and it is something we will continue to look at for future versions of the product.

While we hope these changes are welcome news and address questions you may have had, we also understand we have areas to improve in.  Our desire is to simplify and improve the support experience with Exchange.   If you have more feedback, please continue to provide it.

The Delivery Reports feature which was introduced in Exchange 2010 enables both Information Workers, and administrators to view delivery status of messages and discover answers to questions such as: why a message was not delivered, where a message is now, who received a message, why a message was delivered to a particular folder, etc. While an earlier post introduced the Delivery Reports feature and provided an overview of its functionality, this post will dive a bit further into their architecture and how administrators can use them.

From an admin perspective the Delivery Reports feature was designed to assist in quickly and easily answering questions users may have around why a message they were supposed to receive (or a message they sent) was not delivered. Unlike previous versions of Exchange which forced administrators to manually examine the Message Tracking logs on multiple servers when troubleshooting missing (or delayed) messages, Message tracking logs in Exchange 2010 are automatically index and by using the Delivery Reports feature admins can quickly view a report which displays the Message Tracking events from all servers a message passed through. There are a number of ways Admins can access the Delivery Reports feature, namely: EMC (from the Toolbox), ECP (from Options -> Reporting), or via PowerShell Tasks.

Using ECP to track a message as an Administrator

Delivery Reports in ECP

If a user complains that a message they sent was not delivered the following steps can be used to track the message:

1. Under "Mailbox to search", select the user's mailbox of the user who reported the issue.

2. Select "Search for messages sent to:", and select the users who were supposed to receive the message. (Hint: If the message was sent to someone an internet recipient you can SMTP addresses under "Message Recipients" )

3. To reduce the number of results, you can also optionally specify keywords for the subject by entering in "Search for these words in the subject line"

4. Click "Search"

5. A list of messages will appear in the Search Results pane. To view the Delivery Report details for a specific message simply double-click on it.

If a user complains that they did not receive a message they were supposed to the following steps can be used to track the message:

1. Under "Mailbox to search", select the user's mailbox of the user who reported the issue.

2. Select "Search for messages received from:", and select the user who sent the message. (Hint: If the message came from an internet sender you can enter their SMTP addresses under "Message Recipients" )

3. To reduce the number of results, you can also optionally specify keywords for the subject by entering in "Search for these words in the subject line"

4. Click "Search"

5. A list of messages will appear in the Search Results pane. To view the Delivery Report details for a specific message simply double-click on it.

Delivery Reports Architecture

The following diagram provides a high-level overview of the architecture for the Delivery Reports feature (a.k.a. tracking). Please click for full size version:

In the above example a user uses ECP to track a message which was sent from a user on Mailbox Server 1 to a recipient on Mailbox Server 2.

1. ECP Calls the Search-MessageTrackingReport task and specifies the parameters of the search.

2. The Search-MessageTrackingReport task finds the senders Mailbox Server.

3. The Log Search Service running on Mailbox Server 1 is queried with the search parameters to determine where the message was sent to next.

Note: The Log Search Service, which provides Delivery Reports with a query-able interface to data in the Message Tracking logs, generally loads about two weeks' worth of data (though this number may vary depending on server configuration, mailflow, etc ).

4. As the message went from Mailbox Server 1 to Hub Server 1, tracking follows the path and queries the Log Search Service on Hub Server 1 to determine what happened to the message next

5. Tracking then discovers that the message went across a boundary (Premise/ Forest/ Site).

6. Tracking makes an EWS request to CAS Server 2 in the remote premise/forest/site.

7. CAS Server 2 Queries the Log Search Service on Hub Server 2

8. The message is followed to Mailbox Server 2

9. Delivery Status information is retrieved and returned to CAS 2

10. CAS 2 returns the delivery status information to CAS 1

11. The task merges all of the results and returns them to the user through ECP.

Tip: Configure the Message Tracking files sizes for each server in such a way that the log data will be persisted for about the same length of time on each server, as tracking depends on the log information being available at each hop.

With the launch of Exchange 2010, we have introduced a new way to manage the set of languages available for Exchange.

In previous versions of Exchange, you had one server language per DVD. In Exchange 2010, we have changed to a new language neutral design. This allows us to release all available languages in a single DVD. We can also add and update additional languages over the lifetime of the product. This model also allows us to easily update the translation quality over the lifetime of the product. We are no longer dependent on component updates or service pack deployments.

We provide this flexibility through the use of a language pack bundle. The Exchange 2010 RTM DVD contains our initial version of this bundle. Exchange Setup will install this bundle from the DVD, from a network share, or recommend you to download the most up to date version of the bundle if your server has internet access. Since Exchange 2010 RTM, we have released an updated build of the bundle, available from here. Our recommendation is that all customers deploy this updated bundle as it contains both additional client languages, as well as translation improvements for all the languages. An up to date list of supported languages can be found in Exchange 2010 Language Support. Going forward, we do expect to release updated language pack bundles to improve quality and add additional languages.

The language bundle is delivered as a single downloadable file which includes all localized resources for the server— including Exchange Management Console (EMC) and client (OWA & ECP) interfaces within Exchange. To get a localized experience in EMC, ECP and OWA, you need to install the language pack. Listed below are three scenarios that we would like to call out and provide guidance around them with regards to language pack installation.

1. Language pack bundle deployment as part of the initial server setup
   This scenario applies to an environment where you are installing the language during the fresh setup of your server. We recommend you to install the Language pack in this scenario from the DVD. While the installation of the bundle is available from the usual graphical setup, commands line options are also available. For this scenario use:
   Setup.com /mode:install /roles:.... [/LanguagePack:]
2. Language pack bundle deployment for the first time post initial server setup
   This scenario applies to you, if you have set up your server first and now want to install the Language pack , we recommend you to download the latest Language pack from the download center and follow the steps therein. If you prefer to use the command line option, use :
   Setup.com /mode:install /LanguagePack:
3. Language pack update
   You are already using the language pack bundle, and now want to update it to the latest available. In this scenario, update the exiting bundle with the latest Language pack from the download center and follow the steps therein. In addition, you could also install it using the command line:
   Setup.com /mode:upgrade [/LanguagePack:]
   
   Note:
   • Before installing the language pack bundle, ensure that your OS is installed in the language that you would like to use Exchange in.
   • You should deploy the new or updated language pack bundle starting with your mailbox servers.
   • After installing the Exchange language packs, restart the computer to complete the installation of the language packs.
   • If there is no language pack bundle deployed, English will be the only language available for Client and Server, regardless of the OS Language.

Let's say you have a business process that requires the approval of two different people. Well, with moderation and transport rules, you can automate that process with Exchange 2010 and Outlook 2010.

In this example, we'll set up transport rules so that all messages with 'Project Kiwi' in the subject will be sent for the approval of two people: ej@contoso.com, then administrator@contoso.com

If we created a single transport rule with moderation as the action, and added these two recipients, the message could be approved by either ej@contoso.com or administrator@contoso.com (just like approving a message sent to a moderated group). However, in this case we want approval from both. To do that, we need to create two rules. The order in which the rules are processed specifies who has to approve the message first.

As with any transport rule, you can use any set of conditions with this kind of transport rule. For this example, I've kept it simple (just matching a string in the subject). Here are some screenshots for illustration:

Rule Summary:

Rule: Project Kiwi #1

Rule: Project Kiwi #2

As a result of these rules: when a message is sent with 'Project Kiwi' in the subject line, it will be sent for approval-first to ej@contoso.com, then to administrator@contoso.com. This notes an important behavior in moderation as a transport rule action. When the message is approved, it is processed through transport rules again, picking up where it left off in the order of rules.

In the comments below, please let us know other creative ways you use transport rules or moderation.

There is potential for calendar related problems when new diagnostic logging for Message Access, which is available in Exchange Server 2007 Service Pack 2 (SP2) is raised from its default setting of Lowest. 

A Knowledge Base article and a fix are in the works at this time and will be available soon.

Important - some calendar items may remain broken even after applying the update. This post addresses scenarios where those lingering symptoms remain.

What the users may see

Symptoms before applying the pending update:

• Access to recurring appointments (which have attachments for the instances) is broken - Outlook in online mode receives an "Item cannot be opened" error.
• Sending an embedded message in cached mode results in the attachment being stripped.
• Availability is not shown for some users.

The following symptoms may persist, even after applying the update or manually setting the Message Access diagnostic level back to Lowest:

• Certain users show no availability information from Outlook or OWA scheduling assistant.  Also, event id 4009 for MSExchange Availability is logged on servers with the CAS role

Exception returned:

Microsoft.Exchange.Data.Storage.ObjectNotFoundException: Cannot open embedded message.

• Delegates viewing calendars receive the error:

Cannot read on instance of this recurring appointment. Close any open appointments and try again, or recreate the appointment

• Messages are sent to ActiveSync devices with the following text:

Microsoft Exchange was unable to send the following items to your mobile device. These items have not been deleted. You should be able to access them using either Outlook or Outlook Web Access.

• When accessing Calendar from OWA, the day, week or month viewing will fail with the error:

The item that you attempted to access no longer exists.

We have determined these symptoms are primarily due to calendar items affected between the time logging was increased and when the pending update or workaround is implemented. Recurring calendar items with no end date that have had an occurrence modified seem most susceptible.  A quick method to find these visually is to look for the circling arrows with a line through it.

Does this apply to you?

Before the release of the pending update, if any Exchange Server 2007 SP2 server with the Mailbox role has the following new event log level raised from Lowest, this applies to you.

MSExchangeIS\9000 Private\Message Access

How to check your Organization for the problem

You can determine if your MBX servers are at risk by looking in the following places:

1) The new GUI introduced in SP2 - in the Exchange Management Console under Server Configuration, Mailbox, select the server and choose Manage Diagnostic Logging Properties...

2) In the registry for each MBX server [Lowest = 0]

3) Run the following Exchange CMDlet to find all Exchange 2007 MBX servers and this specific diagnostic logging level for Message Access:

Get-MailboxServer | foreach {Get-EventLogLevel -id ($_.name + "\MSExchangeIS\9000 Private\Message Access")}

How to correct the problem

If any MBX server is found to have logging above the default before the pending update is applied, you should reset it to Lowest manually.  Note which MBX servers are configured with the non-default level and then run this CMDlet to ensure they are all set to "Lowest"

Then either remount the databases or restart the Information Store service.

Get-MailboxServer | foreach {Set-EventLogLevel -id ($_.name + "\MSExchangeIS\9000 Private\Message Access") -Level "Lowest"}

A sample PowerShell script is available here to track down calendar items contributing to the symptoms that persist after applying the workaround detailed above.  This script will identify the day containing problem appointments and can be run against a specific mailbox or all Exchange 2007 mailboxes.  The requirements for running the script are detailed in the script comments. The sample script uses the $true argument to enumerate all Exchange 2007 mailboxes and user42@contoso.com to initialize the Autodiscover portion of the Web Services object:

[PS] C:\Powershell\scripts> .\Find-BadCalendarItems.ps1 user42@contoso.com $true
Checking mailbox: user01@contoso.com
Checking mailbox: user02@contoso.com
...
Checking mailbox: user42@contoso.com
Checking mailbox: repro01@contoso.com
Failed: 11/30/2009 - 12/30/2009

Error: Mailbox logon failed., inner exception: Cannot open embedded message.

Day failed: 12/2/2009
Checking mailbox: repro02@contoso.com
Failed : 11/30/2009 - 12/30/2009

Error: Mailbox logon failed., inner exception: Cannot open embedded message.

Day failed: 12/23/2009
Checking mailbox: user43@contoso.com
Checking mailbox: lastuser@contoso.com
Problems found:
repro01@contoso.com: 12/2/2009
repro02@contoso.com: 12/23/2009
Done!

Now that 12/23/2009 has been identified as the problem date for user repro02@contoso.com, you can use Outlook to find any recurring calendar items with no end date that have had an occurrence modified on that day. Copy that occurrence [either to a temporary Calendar folder or even to a different time that day] then delete just that occurrence. Moving the copy back or manually recreating the instance will resolve the symptom for that user.

When looking for Exchange controls to copy messages for regulatory compliance needs, you may have come across both Transport Rules and Journaling and wondered, "Which one best serves the needs of my organization?" 

Both features have the capability to intercept and copy messages to another mailbox, but they differ in how they intercept messages and in what details are included in the copied message.  Transport Rules can be employed to satisfy needs for message review and monitoring, while Journaling can be employed to meet the regulatory compliance needs for message archiving.  The purpose of this article is to contrast these features' capabilities of message interception, and to help you identify which will best meet your particular compliance and control requirements.  For a broader understanding of these two Exchange features, please reference the links provided below.

Transport Rules-based message interception

Transport rules are applied when messages are sent or received in your organization. 

Transport Rule = Condition + Action + Exception

First, a criteria is evaluated such as who the sender or receiver of the message is, or the keywords in a message.  If messages meet particular criteria (conditions and exceptions), then an action can be applied like 'block,' 'copy,' 'moderate,' or 'append a disclaimer to the message'.  Transport Rules are used to enforce message control and protection policies.

The Transport Rules agent runs on the Exchange Hub Transport server, evaluating every message against the set of Transport Rules.

If your goal is to clandestinely copy certain messages to a supervisory mailbox for post-send review, one could use the "Blind carbon copy (Bcc)" action. For example:

In this rule, external bound messages containing sensitive project key words are copied to a mailbox, where they will be reviewed periodically for policy violations, except for messages which are addressed to members of the trusted partner group.

If your goal in message interception is to have a supervisor review and approve the message before delivery, then you may want to use the moderation action (new in Exchange 2010). An example of how to configure a Transport Rule for moderation, using the Exchange Management Console (EMC):

Figure 1: Transport rule conditions

Figure 2: Transport rule actions

In the example rule above, members of the "Contractors" group are working on a sensitive project and corporate policy dictates that messages sent outside of the organization must be first approved by the user's manager before being delivered. The manager gets an approval request message for the intercepted message, and has the ability to approve or reject the message (via Outlook or OWA).

The advantage that Transport Rules presents is the rich set of conditions & exceptions to which one can scope the rule. One can create very specific rules to intercept messages based on recipients, senders, message content, and/or message properties. For additional details on Transport Rules see:

• Transport Rules documentaton on TechNet
• Exchange Server 2007 Transport Rules Editor GUI
• Moderation with transport rules
• Spotlight on Exchange 2010: E-mail Moderation

Journaling for compliance

The journaling feature was developed to meet the needs of enterprise class message archiving, often driven by legal and regulatory requirements, such as the Sarbanes Oxley Act, SEC Rule 17A-4, and other similar regulations. If an archive is required, then Exchange journaling can be used to create records of email communications, including BCC data, DL membership at the time of delivery, etc..  These records are then delivered via SMTP to the archive for de-duplication / discovery and production. 

Similar to the Transport Rules agent, the Journaling agent also runs on Hub Transport servers (the Journaling agent runs after the Transport Rules agent), evaluating every message against the set of journal rules.

Journal rules are policies for intercepting and archiving messages to and from regulated users (or sets of users); the journal rule configuration allows one define the target user(s) and scope to global, internal, or external messages. For example:

Figure 3: Journal rule properties

In the example journal rule above, all messages sent to or from User01 will be journaled. The journal reports are sent to the Journal mailbox for archiving.

In the example journal report below, the message, "Sales Forecast," from Test User01 was intercepted by the journal rule. A copy of the original message is attached to the journal report, and message metadata (e.g. recipient details) is included in the journal report body:

Figure 4: A journal report includes message metadata and the original message as an attachment

Attaching a copy of the original message to the journal report ensures that the original headers and properties of the message are maintained, as opposed to a message copied by transport rules where some headers will be stripped and properties transformed on delivery. This is one significant difference between a message intercepted by Journaling and a message intercepted by Transport Rules. Other differences are provided in the next section below.

The other advantage that Journaling has over Transport Rules is in the message recipient meta-data provided in the journal report envelope. This lists all of the recipients in the SMTP envelope (P1 recipient list, RFC821), and how each recipient got on the message, including:

• Distribution group expansion ("To: user01@contoso.com, Expanded: salesteam@contoso.com")
• Forwarded recipients ("To: user03@contoso.com, Forwarded: user02@contoso.com")
• BCC'd recipients ("Bcc: reporterdude@treyresearch.net")
• Recipients added by Transport Rules or any other transport agent (not in the example above, but would be listed as "Recipient: someone@example.com"

Lastly, the journal report messages themselves are privileged messages, which will not be intercepted by transport rules, and can be configured such that they will never expire in a transport queue (e.g., will not NDR). Messages redirected or bcc'd by a Transport rule, on the other hand, are treated just like any other standard message in the system (e.g., can NDR if the target mailbox is unreachable).

For additional details on Journaling see:

• Technet documentation on Exchange Journaling
• Technet article on Exchange Journaling
• Whitepaper on Exchange 2007 Journaling

Which feature should I use?

In most cases, this decision will probably pivot around how important it is for you to capture the meta-data around intercepted messages. In summary:

1. Transport Rules support redirecting or BCC'ing messages to another user or mailbox for moderation or review.  This is not suitable for legal e-discovery due to missing metadata and the modified message contents (headers, etc).  This best suited for internal surveillance or corporate policy enforcement, where reviewing the message body content is the primary need.
2. Journaling supports e-discovery archives and enables copying a full fidelity version of the message.  The journal reports contain BCC, DL membership, etc.  This is best suited for enterprise class archiving and regulatory compliance. If your organization wants to support e-discovery via a third party archive, you need to use Journaling.

Below is a chart of some typical requirements organizations have for message interception (be it for review or archiving), and how each feature meets those needs:

Both Transport Rules and Journaling are powerful tools for the Exchange admin to meet message policy enforcement needs and regulatory compliance needs of your organization - understanding your organization's real archiving and control needs is key to picking the right technology.

Exchange CXP team has released Update Rollup 2 for Exchange Server 2007 Service Pack 2 (KB 972076) to the download center.

In addition to bug fixes reported by customers we have added new rules to the Exchange Best Practices Analyzer to check the health of your system. Starting this rollup, customers who wish to deploy the new BPA health rules to a server with no internet connection can do so by downloading the installing the update rollup on the server. Until Exchange Server 2007 Service Pack 2, updates to the BPA rules were available only via the web which meant customers wanting to deploy the new health check rules to servers not connected to the internet would have had to copy over the XML files manually. In Exchange 2007 SP2, we implemented a work item which allows us to ship updates to the BPA health check rules via the rollup and as well as via the traditional web based channel. More on this via a blog post in the near future.

KBA 972076 lists all the fixes included in this rollup. Here are some of the product improvements and critical bug fixes we'd like to call out:

1. KB 972705: This one is for all the IT pros and anyone who has ever had to explain abnormal database size/log file growth in a short period of time. We have added three new registry entries to help speed up troubleshooting the issue:
   • BytesLogWarningThreshold
   • BytesLogErrorThreshold
   • BytesLogCheckPeriodInMinutes
   More information on the values to set in the above registry keys is documented in KB 972705.
2. KB 975404: Accepting meeting requests sent via an application using CDO like Blackberry devices sometimes results in rendering an embedded message attached to the meeting request inaccessible.
3. KB 976137: We have made a change to the behavior of the Unified Messaging Auto attendant when it plays the greeting for callers on a holiday. Currently when callers call on a holiday, they hear the non-business hours greeting followed by the holiday greeting. In this rollup we have made a change so that the callers calling on a holiday will only hear the holiday greeting. If your greetings are configured such that they would make sense to callers calling on a holiday only if they hear both the non-business hours greeting and the holiday greeting, then you need to re-configure them when you install this update rollup.
4. KB 971177: Another change in the UM Auto Attendants configuration in the Exchange Management Console. It is now aware if your time zone follows Daylight Saving Time.
5. KB 975165: In an environment using self-signed certificates and CAS-CAS proxying, Exchange Web Services requests proxied may start failing after the Availability Service has made a proxy request.
6. A bug where the OWA Virtual Directory cannot be accessed via the Exchange Management Console in an environment coexisting with Exchange 2010 if the Exchange 2007 server was upgraded from Exchange 2007 SP1 to SP2.

KB 972076 has more details about this release and a complete list of all fixes included in this rollup.

==Version 3.5 Updates==

Version 3.5 introduces the following fixes:

• Improved the text on the input tab with regards to the number of database copy instances you would like for both HA and lagged copies.
• Fixes an issue where in a high availability architecture the calculator may size the solution based on activating more database copies during a second server failure event than the total number of database copies deployed on the server.

==Version 3.4 Updates==

Version 3.4 corrects a memory and CPU utilization issue where you deploy a site resilient architecture with multiple mailbox servers and a single database copy in the primary datacenter.  Specifically, the calculator would determine the active database copy configuration after a single server failure and then size the CPU and memory requirements.  However, since there is only a single database copy in the primary datacenter, the solution cannot survive with all copies hosted in the primary datacenter.  Therefore, the copies need to be activated in the secondary datacenter.  Version 3.4 corrects this scenario by ensuring there are at least 2 database copies in the primary datacenter in order  to calculate the active database count after a single server failure.

==Version 3.2 Updates==

It's been a while since we discussed the Exchange 2010 Mailbox Server Role Requirements Calculator. Well I am pleased to say that today we are launching version 3.2 of the calculator.

This version includes the following improvements and new features:

• Added processor core guidance for Hub Transport and Client Access server roles.
• Added the ability to define a custom number of databases that you would like to implement in the solution.
• Added support for 2-node site resilient Database Availability Groups.
• Added 1 and 6 processor cores as selectable options.
• Improved breakdown of the activation scenarios in a site resilient solution.
• Improved breakout of the role requirements section.
• The Storage Design tab now indicates that when you select a custom RAID configuration that the calculator ignores RAID-5 and RAID-6 for 5.xK and 7.2K spindles due to performance concerns.
• Updated processor utilization results to show the processor utilization even if it is above the recommended threshold.
• Made conditional formatting improvements throughout the calculator to warn you when you have a configuration that will not work.
• Improved various cell comments.

This version also corrects the following bugs:

• Fixed LUN Requirements tables to accurately reflect space requirements when database copies are deployed as each server may not host all database copies.
• Fixed conditions that resulted in -1 lagged copies.
• Improved the active database copies after first/second server failure calculations:
  • We now calculate and expose the worst case scenario (the server that has to host the most active databases) is used in sizing memory and CPU.
  • We now ensure that the secondary datacenter calculations only consider double server failures when there are 3+ HA copies located in the secondary datacenter.
• Removed maximum memory stipulation in the minimum ESE cache memory calculation.

Hey where is Active/Active?

And for those that I know will ask, this version of the calculator does not include the Active/Active user distribution site resiliency scenario. For those that need that scenario, what I recommend is the following:

1. Launch two versions of the calculator.
2. Populate the first version for the first DAG in your design. This DAG (DAG1) will utilize Datacenter 1 as its primary location (and thus its user population is based out of Datacenter 1). It has site resiliency by having servers and database copies located in Datacenter 2 that can be activated in the event Datacenter 1 is lost.
3. Populate the second version for the second DAG in your design. This DAG (DAG2) will utilize Datacenter 2 as its primary location (and thus its user population is based out of Datacenter 2). It has site resiliency by having servers and database copies located in Datacenter 1 that can be activated in the event Datacenter 2 is lost.

By implementing the architecture in this way, you can ensure that for the majority of scenarios except loss of datacenter, the users remain operational in their primary datacenter location.

Conclusion

Hopefully you will find this calculator invaluable in helping to determine your mailbox server role requirements for Exchange 2010 mailbox servers. If you have any questions or suggestions, please email strgcalc AT microsoft DOT com.

For the explanation of different tabs and how the calculator works, go here. Yup, we updated that too!