Is this thing on?

Understanding Internet Database Availability Groups

Scott Schnoll [MSFT] — Sun, 01 Apr 2012 16:40:00 GMT

The high availability and site resilience platform built into Exchange 2010 provides automatic recovery from storage, network and server and other failures that affect active mailbox database copies. In addition, it provides manual recovery from failures affecting an entire site or datacenter.

Customers have asked for, and many have tried desperately to create, an Exchange 2010 architecture or design that provides automatic failover from datacenter-level events. At the time we released the RTM version of Exchange 2010, we strongly felt that manual recovery from events that affect an entire datacenter (for example, loss of power, fire, natural disaster, etc.) was preferable to automatic recovery by the system. After all, the system has no awareness of the nature of the failure and it can’t really make intelligent decisions as to whether or not users should have service and data access moved to an alternate datacenter.

But after more than five years of running Exchange in a cloud-based service environment in one form or another (Business Productivity Online Suite, Live@EDU, Office 365, etc.) we have realized that automatic recovery could be accomplished by the system in an intelligent way, provided the system had enough replication endpoints, and a sufficient number of points of Internet ingress and egress. So, we also started side development on a feature we internally called the “super DAG”. Obviously, using that name as the actual feature name does not work well for localization and other reasons, so we asked Marketing to come up with a more professional name.

The Internet Database Availability Group

Today, we are announcing the Internet database availability group (iDAG). The iDAG is an extension to the database availability group (DAG) component built into Exchange 2010. An iDAG is a group of an unlimited number of Mailbox servers that hosts an unlimited number of databases and provides automatic recovery from datacenter-level failure events.

Once a DAG has been extended with an iDAG, the iDAG becomes the new boundary for mailbox database replication, database and server switchovers, failovers, and a new internal component called Internet Active Manager (iAM). iAM, which runs on every server in a DAG, manages switchovers and failovers for iDAGs. Will iAM enable better management and recovery scenarios for your iDAG? Absolutely!

The iDAG overcomes several limitations of the traditional DAG:

It can contain more than 16 Mailbox servers. In fact, there is no limit to the number of Mailbox servers that can be added to an iDAG.
It can contain more than 1600 databases. In fact, there is no limit to the number of mailbox databases that can be hosted on a Mailbox server in an iDAG.
It uses HTTPS instead of TCP for log shipping, making it much more firewall-friendly.
It provides automatic recovery from all failures.

Any server in an iDAG can host a copy of a mailbox database from any other server in the same iDAG.

Internet Database Availability Group Lifecycle

As with DAGs, iDAGs leverage the Exchange 2010 feature known as incremental deployment, which is the ability to deploy redundant Mailbox servers and databases after Exchange is installed. After you deploy Exchange 2010, you create an iDAG, add Mailbox servers to the iDAG, and then replicate mailbox databases between the iDAG members.

Note: It is supported to create an iDAG that contains a combination of physical Mailbox servers and virtualized Mailbox servers, provided that the servers and solution comply with the Exchange 2010 System Requirements. As with all high availability configurations, you must ensure that all Mailbox servers in the iDAG are sized appropriately to handle the necessary workload during scheduled or unscheduled outages.

An iDAG is created by using the New-InternetDatabaseAvailabilityGroup cmdlet. An iDAG is initially created as an empty Active Directory object. This directory object is used to store relevant information about the iDAG, such as server membership information, HTTP URL and location. When you add the first server to an iDAG, an Internet-based failover cluster is automatically created. This failover cluster is used exclusively by the iDAG, however the cluster does not need to be dedicated to the DAG. You can use the cluster for any other purpose you like.

In addition to a failover cluster being created, the infrastructure that monitors the servers for network or server failures is initiated. The failover cluster heartbeat mechanism and cluster database are then used to track and manage information about the iDAG that can change quickly, such as database mount status, replication status, and last mounted location.

During creation, an iDAG is given a unique name (that must start with the letter “i” in lower case, and assigned three static IPv6 addresses (for redundancy). Specify a comma-separated list of IP addresses by using the InternetDatabaseAvailabilityGroupIPAddresses parameter.

Consider an iDAG that will have three servers. Two servers (EX1 and EX2) are on the same subnet, and the third server (EX3) is on a different subnet.

New-InternetDatabaseAvailabilityGroup -Name iDAG1
-InternetDatabaseAvailabilityGroupIPAddresses 2001:0:4137:1f9a:1037:1d90:b3e4:3e79, 2001:4898:80a8:f019:d8d6:250e:baf0:9393
Add-InternetDatabaseAvailabilityGroupServer -Identity iDAG1 –Server EX1
Add-InternetDatabaseAvailabilityGroupServer -Identity iDAG1 –Server EX2
Add-InternetDatabaseAvailabilityGroupServer -Identity iDAG1 –Server EX3

The cluster for iDAG1 is created when EX1 is added to the iDAG. During cluster creation, the Add-InternetDatabaseAvailabilityGroupServer cmdlet retrieves the IP addresses configured for the iDAG and ignores the ones that don't match any of the subnets found on EX1. In this example, the cluster for iDAG1 is created with an IP address of 2001:0:4137:1f9a:1037:1d90:b3e4:3e79, and 2001:4898:80a8:f019:d8d6:250e:baf0:9393 is ignored.

Then, EX2 is added, and the Add-InternetDatabaseAvailabilityGroupServer cmdlet again retrieves the IP addresses configured for the iDAG. There are no changes to the cluster's IP addresses because EX2 is on the same subnet as EX1.

Then, EX3 is added, and the Add-InternetDatabaseAvailabilityGroupServer cmdlet again retrieves the IP addresses configured for the DAG. Because a subnet matching 2001:4898:80a8:f019:d8d6:250e:baf0:9393 is present on EX3, the 2001:4898:80a8:f019:d8d6:250e:baf0:9393 address is added as an IP address resource in the cluster group. In addition, an OR dependency for the Network Name resource for each IP address resource is automatically configured. The 2001:4898:80a8:f019:d8d6:250e:baf0:9393 address will be used by the cluster when the cluster group moves to EX3.

This process is then repeated an unlimited number of times to extend the iDAG further and further into cyberspace.

Windows failover clustering registers the IP addresses for the cluster in the Domain Name System (DNS) when the Network Name resource is brought online. In addition, a cluster network object (CNO) is created in Active Directory. The name, IP addresses and CNO for the cluster are used only internally by the system to secure the iDAG and for internal communication purposes. Administrators and end users don't need to interface with or connect to the iDAG name or IP address for any reason.

In addition to a name and one or more IP addresses, the iDAG is also configured to use a witness server, witness directory, alternate witness server, and alternate witness directory. The witness server and witness directory are either automatically specified by the system, or they can be manually specified by the administrator. The alternate witness server and directory must be specified manually by the administrator. In addition, multiple alternate witness servers can be configured for increased redundancy. In the event of a datacenter failover, the iDAG will automatically reconfigure the witness server and alternate witness server for you.

By default, an iDAG is designed to use the built-in continuous replication feature to replicate mailbox databases among servers in the iDAG. If you're using third-party data replication that supports the Third Party Replication API in Exchange 2010, you must create the iDAG for use with third-party replication mode by using the New-InternetDatabaseAvailabilityGroup cmdlet with the ThirdPartyReplication parameter. After this mode is enabled, it can't be disabled.

After the iDAG is created, Mailbox servers can be added to the iDAG. When the first server is added to the iDAG, a cluster is formed for use by the iDAG. iDAGs make limited use of Windows failover clustering technology, such as the cluster heartbeat, cluster networks, and the cluster database (for storing data that changes, such as database state changes from active to passive or vice versa, or from mounted to dismounted and vice versa). As each subsequent server is added to the iDAG, it's joined to the underlying cluster, the cluster's quorum model is automatically adjusted by the system, and the server is added to the iDAG Active Directory object in.

After Mailbox servers are added to an iDAG, you can configure a variety of iDAG properties, such as whether to use network encryption or network compression for database replication within the iDAG. You can also configure iDAG networks and create additional iDAG networks.

After you add members to an iDAG and configure the iDAG, the active mailbox databases on each server can be replicated to the other iDAG members. After you create mailbox database copies, you can monitor the health and status of the copies using a variety of built-in monitoring tools. In addition, you can perform database and server switchovers.

Internet Database Availability Group Quorum Models

Underneath every iDAG is a Windows failover cluster. Failover clusters use the concept of quorum, which uses a consensus of voters to ensure that only one subset of the cluster members (which could mean all members or a majority of members) is functioning at one time. Quorum isn't a new concept for Exchange 2010. Highly available Mailbox servers in previous versions of Exchange also use failover clustering and its concept of quorum.

But what is new is the iDAGs use of a new quorum model called the Internet Node Majority and File Share Witness Model (iNMFSW). The iNMFSW is similar to traditional quorum models that require a minimum number of votes to maintain quorum. However, the minimum number of votes needed for quorum in an iDAG is one. This is because, unlike traditional DAGs (which are limited to using voting members and a single witness server), an iDAG uses all Internet-capable devices to maintain quorum. So unless the Internet is down or otherwise unavailable, an iDAG can never lose quorum. If quorum is lost, however, administrator intervention will be required to correct the quorum problem and restore iDAG operations.

Using an Internet Database Availability Group for High Availability

To illustrate how an iDAG can provide high availability and site resilience for your mailbox databases, consider an iDAG with five hundred members.

In this example, the database copies aren't mirrored across each server, but rather spread across hundreds of servers scattered across the Internet. This ensures that no two servers in the iDAG have the same set of database copies, providing the iDAG with greater resilience to failures, including failures that occur while other components are unavailable as a result of regular maintenance.

Consider the following scenario, using the preceding example iDAG, which illustrates resilience to multiple database and server failures.

Initially, all databases and servers are healthy. You need to install some operating system updates on EX212. You perform a server switchover, which activates the database copies on another Mailbox server somewhere on the Internet. A server switchover moves all active mailbox database copies from their current server to one or more other Mailbox servers in the iDAG in preparation for a scheduled outage for the current server. You can perform a server switchover quickly by running the following command in the Exchange Management Shell.

Move-ActiveMailboxDatabase -Server EX212

In this example, all of the active mailbox databases on EX212 are moved. By omitting the ActivateOnServer parameter in the preceding command, you chose to have the system select the best possible new active copy.

While you perform maintenance on EX212, EX306 experiences a catastrophic hardware failure and goes offline. Prior to going offline, EX306 active database copies. To recover from the failure, the system automatically activates the copies on alternate servers in the iDAG within 30 seconds.

After the scheduled maintenance is completed for EX212, you bring the server online. As soon as EX212 is available, the other members of the iDAG are notified, and the database copies hosted on EX212 are automatically synchronized with the active copy of each database.

After the failed hardware component in EX306 is replaced with a new component, EX306 is brought online. After EX306 is available, the other members of the iDAG are notified, and the databases hosted on EX306 are automatically synchronized with the active copy of each database.

Using an Internet Database Availability Group for Site Resilience

In addition to providing high availability within a datacenter, an iDAG can also be extended an unlimited number of datacenters in a configuration that provides site resilience all datacenters. Incremental deployment can be used to extend any iDAG to any datacenter by deploying Mailbox servers and the necessary supporting resources.

Using Multiple Internet Database Availability Groups for Site Resilience

Prior to iDAGs, in order to achieve site resilience for multiple locations, you had to use multiple DAGs. With an iDAG, this is no longer necessary. A single iDAG can be extended across an unlimited number of datacenters, providing site resilience for all of your locations and databases. When using a single iDAG to provide site resilience in an environment where each datacenter to which you extend the DAG has an active user population, the Internet eliminates all single points of failure because quorum no longer requires a majority of the voters to be active and able to communicate with each other. It simply requires connectivity to another iDAG member.

Client Experience When Using Internet Database Availability Groups

As mentioned above, iDAGs can be used to provide both high availability and site resilience. The client experience when using an iDAG no longer depends on the type and version of the client and the protocol used by the client to access mailbox data. For example, if a datacenter failover occurs, the behavior and reconnection logic used by an Exchange ActiveSync, POP3, or IMAP4 client is the same as the behavior and reconnection logic used by Microsoft Outlook clients.

TechEd 2012 Registration Time!

Scott Schnoll [MSFT] — Tue, 24 Jan 2012 20:58:32 GMT

Registration is now open for both TechEd North America 2012 and TechEd Europe 2012!

Celebrate 20 years of Microsoft TechEd North America! TechEd is Microsoft's premier technology conference for IT professionals and developers, offering the most comprehensive technical education across Microsoft's current and soon-to-be-released suite of products, solutions, tools, and services. Our four day event in Orlando, Florida offers hands-on learning, deep product exploration and countless opportunities to connect with a community of industry and Microsoft experts.

There are many reasons why you can't miss TechEd 2012. If you are developing, deploying, managing, securing and mobilizing Microsoft solutions, TechEd is your best opportunity to focus on the key technology and business issues that will help you solve today's real-world IT challenges and prepare you for tomorrow's innovations.

Year after year, technology professionals gather at Microsoft TechEd North America to immerse themselves in more than 1,000 learning opportunities that cover an unparalleled breadth and depth of Microsoft technologies. TechEd is the best place as an industry professional to focus on technology education and professional development opportunities that are relevant to you and your business without all the distractions of the office. Meeting face-to-face with Microsoft and industry experts can start relationships that will help your work for years to come.

Join myTechEd to network with the brightest people in the industry, and then register for the 20th Annual TechEd!

Come to TechEd Europe, unplug from your day job, & dive into the thousands of learning & networking opportunities. In addition to over 400 sessions with Microsoft and industry speakers, TechEd offers you face-to-face connections with thousands of your peers who share your challenges. TechEd is the forum to gain the expertise and insights that will help you get the most from your IT investments.
TechEd offers 4 days to:

LEARN in-depth about the latest technology trends and how you can leverage these effectively in your business
DISCOVER the future of Microsoft’s products, technologies, solutions and services directly from Microsoft’s leaders with news, announcements, and demos
NETWORK with Microsoft and industry thought leaders, and fellow delegates that share your technology interests and business challenges
PLAN the features and architecture to support your business goals and product roadmap

Need Even More? Attend a Pre-Conference Seminar

By arriving a day early on Monday, 25 June and registering for the special Pre-Conference Seminars you will get in-depth training and insights on the Microsoft technologies and products that power your business. Select from 10 different topics taught by John Craddock, Kate Gregory, Steve Fox, Mikael Nystrom, Kent Agerlund, Alberto Ferrari, Richard Hundhausen, and more!

Register NOW for TechEd Europe (limited number of academic tickets available for students and educators)

Free Microsoft Private Cloud Training

Scott Schnoll [MSFT] — Thu, 19 Jan 2012 19:23:51 GMT

On February 21 & 22 we are running a 2-day virtual training event to help the world learn about the upcoming enhancements with Creating & Managing a Private Cloud with System Center 2012 Jump Start. It is 100% free so register now!

Event Overview

Adopting this exciting new computing paradigm provides a whole new landscape of technology and career direction for IT professionals. Microsoft Learning and the Microsoft System Center 2012 team have partnered to bring you an exciting opportunity to learn what you need to know to deploy, manage and maintain Microsoft’s private cloud solution. Leveraging the popular Jump Start virtual classroom approach, the industry’s most gifted cloud experts will show attendees why this new private cloud solution, based on System Center 2012 and Windows Server, has garnered so much attention. Presenters include Symon Perriman, Sean Christensen, Adam Hall, Kenon Owens, Prabu Rambadran & Chris Van Wesep and there will be a live Q&A during the event.

Event Agenda

Day 1: Deployment & Configuration (Feb. 21)

Part 1: Understanding the Microsoft Private Cloud
Part 2: Deploying the Infrastructure Components
Part 3: Deploying the Private Cloud Infrastructure
Part 4: Deploying the Service Layer
Part 5: Deploying the Applications & VMs

Day 2: Management & Operations (Feb. 22)

Part 6: Managing the Infrastructure Components
Part 7: Managing the Private Cloud Infrastructure
Part 8: Managing the Service Layer
Part 9: Managing the Applications & VMs

Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2

Scott Schnoll [MSFT] — Mon, 21 Nov 2011 16:12:35 GMT

I just posted an entry on the Exchange Team Blog about a Windows hotfix that is strongly recommended for database availability groups that are deployed on Windows Server 2008 R2. Go check it out and install the hotfix, if applicable.

TechNet Print-a-Book Beta Available

Scott Schnoll [MSFT] — Thu, 21 Jul 2011 19:23:46 GMT

This week, a feature known as Print/Export a Collection (a.k.a. Print-a-Book) went live in our TechNet Library Lightweight as Beta service. This new feature offers improved printing features for TechNet articles and the ability to export one or more topics to PDF format.

To check out this feature, go to the TechNet Lightweight Library and click on the printer icon in the upper right-hand corner.

Enjoy!

Circular Logging and Mailbox Database Copies

Scott Schnoll [MSFT] — Mon, 27 Jun 2011 17:27:04 GMT

In the transaction logging mechanism used by Exchange , each database transaction is written first to a log file and then to the database file. When a log file reaches a certain size (1 MB in Exchange 2010), it's renamed with the next generation sequence number, and a new log file is created. Over time, this results in a set of log files known as the log stream. If the Exchange Information Store or Windows stops unexpectedly, the log stream is used to recover the transactions by replaying the data from the log files into the database.

Circular logging is a feature of the Joint Engine Technology (JET) database used by all versions of Exchange Server that can be enabled or disabled by an administrator. When enabled, circular logging allows Exchange to overwrite transaction log files after the data contained in the log files is committed to the database. By enabling it, you can reduce storage space requirements. However, without a complete set of transaction log files, you won’t be able to recover any data more recent than the last full backup. In Exchange Server 5.5 and earlier, circular logging was enabled by default, and starting with Exchange 2000 Server and continuing to Exchange 2010, it is disabled by default.

In Exchange Server 2007, we introduced continuous replication, and a companion feature that came to be known as continuous replication circular logging (CRCL). CRCL is different from JET circular logging. JET circular logging is performed by Information Store, and CRCL is performed by the Microsoft Exchange Replication Service.

We introduced CRCL because JET circular logging can’t really work in a continuous replication environment; it doesn’t generate additional log files and instead overwrites the current log file when needed. In a continuous replication environment, log files are needed for log shipping and replay. As a result, unlike Jet circular logging, when you enable CRCL, the current log file is not overwritten and closed log files are generated for the log shipping and replay process.

Specifically, the Microsoft Exchange Replication Service manages CRCL so that log continuity is maintained and logs are not deleted if they are still needed for replication. The Microsoft Exchange Replication Service and the Microsoft Exchange Information Store service communicate by using remote procedure calls (RPCs) regarding which log files can be deleted.

For truncation to occur on highly available (non-lagged) mailbox database copies, the answer must be "Yes" to the following questions:

Has the log file been backed up, or is CRCL enabled?
Is the log file below the checkpoint?
Do the other non-lagged copies of the database agree with deletion?
Has the log file been inspected by all lagged copies of the database?

For truncation to occur on lagged database copies, the answer must be "Yes" to the following questions:

Is the log file below the checkpoint?
Is the log file older than ReplayLagTime + TruncationLagTime?
Is the log file deleted on the active copy of the database?

You enable and disable both features the same way; either by using the checkbox on the Maintenance tab of the database Properties dialog that says Enable circular logging, or by using the Set-MailboxDatabase cmdlet with the -CircularLoggingEnabled parameter. When you enable circular logging for a mailbox database, the type of circular logging you get depends on whether or not the mailbox database is replicated using continuous replication:

If the mailbox database is not replicated, it will use JET circular logging. In this case, enabling or disabling JET circular logging will require a dismount and mount of the database.
If the mailbox database is replicated, it will use CRCL. In this case, enabling or disabling CRCL takes effect dynamically; there is no need to dismount and re-mount the database.

Because of the differences between JET circular logging and CRCL, there is no way to transition a database between JET circular logging and CRCL or vice versa. As a result, when you add the first passive copy of a database or remove the last passive copy of a database, circular logging (JET or CRCL) must be disabled. Both of these operations result in a transition between a non-replicated database and a replicated database or vice versa:

If you have circular logging enabled for a non-replicated database and you add your first passive copy, Exchange will block that action to prevent switching from JET CL to CRCL. This behavior is there because we need to prevent logs from being truncated while the new copy seed starts. The newly added passive copy would not seed correctly if required logs were removed.
Same thing (sort of ) for remove. When you try to remove the last passive copy, that would result in a transition from CRCL to CL, and we block that because that transition would require a dismounting and re-mounting of the active copy of the database.

Where it gets tricky is that in both cases where we block an operation because circular logging is enabled, the error message returned to the administrator is not accurate. It says:

Database "{0}" has circular logging enabled. It is not possible to add or remove database copies while circular logging is enabled. Please disable circular logging before adding or removing mailbox database copies.

In addition, a couple of topics on TechNet also repeated this requirement.

It is actually only when you add the second copy of a database (e.g., add the first passive copy), or when you are trying to remove the last passive copy of a database that we block and display this error message. If you are adding a third or subsequent passive copy, circular logging can remain enabled because adding the copy doesn’t require a transition between the two types of circular logging. Similarly, if you are removing any passive copy except for the last passive copy of a database, circular logging can remain enabled.

The TechNet topics have been updated to reflect this, and those updates will be published with our next document refresh. And I will be updating the string in Exchange 2010 Service Pack 2 to clarify this, as well.

Witness Server Warning Message When Using Certain Database Availability Group Tasks

Scott Schnoll [MSFT] — Wed, 08 Jun 2011 23:38:53 GMT

Recently, some customers reported that when they create a DAG, they get a warning message that states the following:

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server <ServerName>.

In these cases, the customer’s intended witness server was not an Exchange 2010 server. As documented in TechNet, if the witness server you specify isn't an Exchange 2010 server, you must add the Exchange Trusted Subsystem (ETS) universal security group (USG) to the local Administrators group on the witness server. These security permissions are necessary to ensure that Exchange can create a directory and share on the witness server as needed.

After some inspection, the customers confirmed that, contrary to the error message, the ETS USG was a member of the local administrators group on their intended witness server. Moreover, even though this warning appeared, there were no ill effects in functionality. The directory and share on the witness server were created as needed, the file share witness cluster resource was online, and the DAG passed all replication health checks.

After hearing about this, I went to my lab to test this, and I was able to reproduce the issue. I added the ETS USG to the local administrators group on my witness server (a Windows 2008 file server) and ran New-DatabaseAvailabilityGroup, specifying my witness server. I received the same warning message, and verified that despite the message, all was perfectly healthy with the DAG, and there were no permission problems, witness server or cluster problems or other issues.

Even though it appeared as though this warning message could be safely ignored, I wondered why we were getting it in the first place. So I went digging into the source code to find out.

Let me describe what is happening and why you, too, can safely ignore the warning message.

During various DAG-related tasks that configure witness server properties (namely, New-DatabaseAvailabilityGroup, Set-DatabaseAvailabilityGroup and Restore-DatabaseAvailabilityGroup), the code is actually checking to see if the witness server is a member of the Exchange Trusted Subsystem USG.

As you may know, there is no requirement that the witness server be a member of the ETS USG. Nonetheless, the code for these tasks does check for this, and if it finds that the witness server is not a member of the ETS USG, it issues a warning message.

Unfortunately, to confuse things even more, the warning message says:

The Exchange Trusted Subsystem is not a member of the local Administrators group on specified witness server <ServerName>.

It says nothing about the witness server not being a member of the ETS USG, even though the code is checking for that. Instead, it makes it appear as though the permission perquisites have not been satisfied, even though they actually have.

But, even though the message does not pertain to the actual check that failed, that does not make this a string bug. This is a code bug, as there is no requirement that the witness server be a member of the ETS USG. Thus, the code should not be checking for this condition. If this bug is fixed and the check is removed, the string will be removed with it. Unless and until that happens, if you are seeing this warning message when you are using any of the above-mentioned tasks, and you have verified that the ETS USG is a member of the local administrators group on your witness server, then you can likely safely ignore the warning message. You should run Test-ReplicationHealth to verify the health of the DAG once members have been added to it.

Because we are doing this check in code, you can of course add the witness server to the ETS group, and also make the ETS group a member of the local administrators group on the witness server, and all of these tasks will complete without this warning message. But, don't do that in production because (1) it is not needed and (2) it gives the witness server way more permissions than it should ever have (unless of course, the witness server is an Exchange 2010 server).

Exchange 2010 High Availability Misconceptions Addressed

Scott Schnoll [MSFT] — Tue, 31 May 2011 21:33:24 GMT

We just published a blog post I wrote about some common Exchange 2010 high availability misconceptions that I heard repeated at Tech.Ed North America. In it, I discuss and dispel several misconceptions:

Misconception Number 1: The Alternate Witness Server (AWS) provides redundancy for the Witness Server (WS)
Misconception Number 2: Microsoft recommends that you deploy the Witness Server in a third datacenter when extending a two-member DAG across two datacenters
Misconception Number 2a: When I have a DAG with an even number of members that is extended to two datacenters, placing the witness server in a third datacenter enhances resilience
Misconception Number 3: Enabling DAC mode prevents automatic failover between datacenters; therefore, if I want to create a datacenter failover configuration, I shouldn’t enable DAC mode for my DAG
Misconception Number 4: The AutoDatabaseMountDial setting controls how many log files are thrown away by the system in order to mount a database
Misconception Number 5: Hub Transport and Client Access servers should not have more than 8 GB of memory because they run slower if you install more than that
Misconception Number 6: A Two-Member DAG is designed for a small office with 250 mailboxes or less

Enjoy!

Understanding and Troubleshooting Microsoft Exchange Server Integration

Scott Schnoll [MSFT] — Wed, 11 May 2011 21:07:39 GMT

Today we released a new Word document that introduces you to some of the new client features that are available when Microsoft Lync Server 2010 is integrated with Exchange Server 2010.

Lync 2010, as well as other unified communications (UC) clients and devices, interact with Microsoft Exchange and Microsoft Outlook to provide integrated features to the end user, such as:

Contact Information
Calendar Information
Conversation History
Missed Conversations
Missed Calls
Voice Mail Playback

Successfully integrating these two enterprise communications solutions can be challenging, especially considering that there are subtle differences in the way that services from each product are leveraged by Lync Server 2010 clients. The information contained in the document is not intended to be authoritative with regard to these topics. Rather, it is a collection of information that the author (Dave Howe) gathered from various product specifications as well as some general troubleshooting information.

Enjoy!

Exchange 2010 SP1 and Windows Bugchecks

Scott Schnoll [MSFT] — Wed, 13 Apr 2011 13:13:00 GMT

In case you aren’t familiar with the word, a bugcheck is one of several technical terms used to describe the situation in which an operating system halts because it has encountered an error that prevents it from safely continuing to operate. Other technical terms we used to describe this condition include:

Kernel panic
System halt
Fatal system error
Stop error

And some non-technical terms to describe this condition include:

System crash
Blue screen of death (BSOD)

When this condition occurs, the system creates a system dump (also known as memory dump or crash dump), which provides information about what the system was doing at the time, which can be very useful in debugging the problem and determining why the bugcheck occurred in the first place. Depending on how the administrator has configured the operating system, after the system dump is written to disk (if possible), the operating system may restart itself as a form of self-corrective action.

Exploiting Bugcheck Behavior

I sometimes hear administrators describe a bugcheck as a bad thing. The bugcheck behavior itself is a good thing. It’s the problem that caused the bugcheck to occur that is the bad thing. Simply put, bugchecking is there because it enables the system to try to recover from an otherwise unrecoverable error. Understanding bugchecks for what they are lends itself to understanding how an application might exploit this behavior to its own advantage. For example, in Windows Server 2008 R2, new logic was added to Windows Failover Clustering (WFC) that enabled WFC to self-recover under specific conditions. When certain errors occur in a cluster running Windows 2008 R2 that are catastrophic and unrecoverable, WFC will intentionally bugcheck the server as a last resort method of recovery.

Exchange 2010 SP1 Bugcheck Behavior

In Exchange 2010 SP1, we added logic to the system that leverages bugcheck behavior when certain conditions occur. Specifically, when hung IO occurs. In SP1, Extensible Storage Engine (ESE) has been updated to detect hung IO and to take corrective action to automatically recover the server. ESE keeps an IO watchdog thread that will detect when an IO has been outstanding. If the IO is outstanding for more than one minute, ESE will log an event. If an Exchange database has an IO outstanding for greater than 4 minutes, it will log a specific failure event, if it is possible to do so. ESE event 507, 508, 509 or 510 may or may not be logged, depending on the nature of the hung IO. Obviously, if the nature of the problem is such that the OS volume is affected or the ability to write to the event log is affected, the events will not be logged. If the events are logged, the Microsoft Exchange Replication service (MSExchangeRepl.exe) will detect those failure events and intentionally cause a bugcheck of Windows by terminating the wininit.exe process.

In many of the hung IO incidents we have seen, the entire stack has been affected by the hang, making it impossible to write failure events to the crimson channel or any other area of the event log. So ESE also monitors the crimson channel by verifying that the event log can be written to. If writing to the event log fails for a long period of time, MSExchangeRepl will intentionally cause a bugcheck of Windows by terminating wininit.exe. When this condition occurs, obviously the system is unable to write any ESE events to the event log.

When the bugcheck does occur, it will always be as follows:

CRITICAL_OBJECT_TERMINATION (f4)
A process or thread crucial to system operation has unexpectedly exited or been terminated.

NOTE: the presence of this bugcheck does not necessarily mean Exchange was the cause. Any termination of wininit.exe, including one performed by an administrator using Task Manager or some other task management tool, will cause this bugcheck error code.

Conclusion

The hung IO detection feature in Exchange 2010 is designed to make recovery from hung IO or a hung controller fast, rather than re-trying or waiting until the storage stack raises an error that causes failover. It’s a great addition to the set of high availability features built into Exchange 2010.

UDP Notification is coming to Exchange 2010

Scott Schnoll [MSFT] — Fri, 28 Jan 2011 23:23:27 GMT

We just made another cool announcement this week about UDP notification and Exchange 2010. If you have clients running Outlook 2003 against Exchange 2010, check out this post.

GAL Segmentation in Exchange Server 2010 SP2

Scott Schnoll [MSFT] — Thu, 27 Jan 2011 17:56:20 GMT

We just posted some important information about GAL segmentation, address book policies and Exchange Server 2010 SP2 on the Exchange team blog. I know this is critical information for some of you out there, so I’ll keep this post short and sweet and just say: Go read it!

Exchange Server 2010 Mailbox Server Role Requirements Calculator Update Released

Scott Schnoll [MSFT] — Wed, 19 Jan 2011 17:50:03 GMT

Today we've released an update to the Exchange Server 2010 Mailbox Server Role Requirements Calculator that addresses some issues that were identified in the previous (v12.8) release. You can visit the updates tracking page to see what is in this new version, but here’s a brief synopsis of what’s fixed/changed:

Fixed the Activation Results Scenarios so that it no longer displays #NAME when dealing with dedicated lagged copy servers.
Fixed 2 LUNs / Backup Set formula for the 11th database grouping set in the DB and Log LUN Design / Server table so that it displays the correct number of databases in the grouping set.
Fixed the "Number of Active Databases / SDC Server (After First PDC Server Failure)" calculations to take into account stretched single DAG without dedicated DR servers.
Fixed the "Number of Required Mailbox Processor Cores (Primary Datacenter)" formula to respect when site resilience is disabled and A/A (single DAG) is selected.
Fixed formatting for scenario that resulted in more HA database copies being deployed in the secondary datacenter than in the primary datacenter and also improved validation checks.
Updated "Custom Number of Databases" (Input Section) and "Number of Databases" (Role Requirements section) text to indicate in standalone situations that the "Custom Number of Databases" is per server and "Number of Databases" is for the environment.
Fixed 2nd PDC failure formula to enable site resilient scenarios that have 3 copies in the primary datacenter to allow for a double server failure event.
Optimized the Number of Mailboxes per Database (I/O Driven) to not round up odd numbers to the next even number.
Fixed text in various comment fields.
Added conditional formatting for the Exchange Native Data Protection input factor to alert when you are deploying with less than the recommended number of HA copies.
The calculator now includes the ability to select different disk types and capacities for the storage architecture being deployed in the secondary datacenter.

You can find more information and download the calculator on the Exchange Team blog at http://msexchangeteam.com/archive/2009/11/09/453117.aspx.

Updated Exchange Deployment Assistant Available!

Scott Schnoll [MSFT] — Mon, 06 Dec 2010 16:15:23 GMT

Last week, we released an updated version of the Exchange Deployment Assistant (EDA). In case you haven’t heard of this tool, EDA is a Web-based deployment tool that asks you a few questions about your environment and then generates customized instructions for migrating to Exchange 2010. EDA was designed to make upgrading to Exchange 2010 or deploying a new Exchange 2010 organization as easy as following a checklist. Not only does the tool provide you with step-by-step instructions, but it also helps you verify that each step was completed successfully before moving on to the next step.

The version we released last week includes new cloud-based scenarios, such as cross-premises co-existence (where Exchange 2010 is deployed on-premises and in the cloud), and cloud-only deployments. The first co-existence scenario handles upgrading from Exchange 2003 to a cross-premises Exchange 2010 deployment. Cross-premises scenarios for Exchange 2007 and Exchange 2010 are coming soon. With coexistence, you get directory synchronization, single sign-on, Transport Layer Security (TLS) for transport, Free/Busy and calendar sharing, and more!

The cloud scenario involves migrating to Microsoft Office 365 for Enterprises. A cloud-only deployment is most often used when you want to migrate from your existing on-premises e-mail system to Exchange Online.

For more information, or to use EDA, visit http://technet.microsoft.com/en-us/exdeploy2010/default.aspx. We welcome your feedback, too, so if you have any comments, concerns, questions or praise, please send them to the EDA team.

Back From Down Under

Scott Schnoll [MSFT] — Tue, 07 Sep 2010 03:30:50 GMT

I just got back from delivering Exchange 2010 presentations at TechEd Australia 2010 in Gold Coast, and TechEd New Zealand 2010 in Auckland. I delivered several presentations, such as Exchange Server 2010 High Availability Deep Dive, Exchange Server 2010 Virtualisation, and others. I also got a chance to chat about Service Pack 1 with Paul Schnackenburg, who posted his interview with me online on his blog.

And in case you haven’t heard, several cool things happened in August and September:

RELEASED: Updated Mailbox Server Role Requirements Calculator, Jetstress 2010 RTM and Load Generator 2010 RTM

Scott Schnoll [MSFT] — Wed, 16 Jun 2010 19:36:32 GMT

It's only Wednesday, and it's been quite a week for Exchange tool releases. Seems like only yesterday we released Remote Desktop Connection Manager (RDCMan). But, alas, that was Friday. Since then, we've had three major updates to some Exchange "must-have" tools:

Mailbox Server Role Requirements Calculator - We actually updated the calculators for both Exchange Server 2007 and Exchange Server 2010. You can review the updates we've made to the Exchange 2007 calculator at http://msexchangeteam.com/archive/2007/07/05/445802.aspx, and download it from http://msexchangeteam.com/files/12/attachments/entry438481.aspx. You can review the updates we've made to the Exchange 2010 calculator at http://msexchangeteam.com/archive/2010/01/22/453859.aspx and download it from http://msexchangeteam.com/files/12/attachments/entry453145.aspx. If you're not familar with the Mailbox Server Role Requirements Calculator, you can read all about it at http://msexchangeteam.com/archive/2009/11/09/453117.aspx.
Microsoft Exchange Server Jetstress 2010 - Jetstress 2010 is used to verify the performance and stability of a disk subsystem prior to putting an Exchange Server server into production. Jetstress helps verify disk performance by simulating Exchange disk I/O. Specifically, Jetstress simulates the Exchange database and log file loads produced by a specific number of users. You use Performance Monitor, Event Viewer, and ESEUTIL in conjunction with Jetstress to verify that your disk subsystem meets or exceeds the performance criteria you establish. After a successful completion of the Jetstress Disk Performance and Stress Tests in a non-production environment, you will have ensured that your Exchange disk subsystem is adequately sized (in terms of performance criteria you establish) for the user count and user profiles you have established. We strongly recommend reading the included documentation before using Jetstress.
Exchange Load Generator 2010 - Microsoft Exchange Load Generator 2010 (LoadGen) is a simulation tool you can use to measure the impact of MAPI, OWA, ActiveSync, IMAP, POP and SMTP clients on Exchange 2010 and 2007 servers. LoadGen allows you to test how a server running Exchange responds to e-mail loads. To simulate the delivery of these messaging requests, you run LoadGen tests on client computers. These tests send multiple messaging requests to the Exchange server, thereby causing a mail load. LoadGen is a useful tool for administrators who are sizing servers and validating a deployment plan. Specifically, LoadGen helps you determine if each of your servers can handle the load to which they are intended to carry. Another use for LoadGen is to help validate the overall solution. Note, though, that LoadGen should be used only in laboratories that have no connection to the production environment. This tool should never be used in any way in a production environment, an environment that is mission-critical, or an environment that contains important information of any kind anywhere on the network.

Enjoy!

Exchange Server 2010 Service Pack 1 Beta Available for Download

Scott Schnoll [MSFT] — Mon, 07 Jun 2010 14:40:00 GMT

This morning, we released a Beta of Service Pack 1 for Exchange 2010 to the Microsoft Download Center. You can download the beta from http://go.microsoft.com/fwlink/?linkid=193120.

Exchange Server 2010 SP1 Beta includes archiving and discovery enhancements, a faster Outlook Web App, upgraded mobility features, and several additions to the Exchange Management Console.

So what are you waiting for? Go get the Beta! And remember, the Beta is for labs, development, testing, and other non-production environments. Please don't install the Beta in production.

Update for Exchange Server 2007 Mailbox Storage Requirements Calculator Released

Scott Schnoll [MSFT] — Mon, 10 May 2010 20:29:00 GMT

We just updated the Exchange 2007 Mailbox Server Role Storage Requirements Calculator to coincide with the BlackBerry Enterprise Server for Microsoft Exchange 2007 Performance Benchmarking Guide whitepaper update.

The main blog post has been updated, and you can view the Updates Tracking page to see what changed. Download the updated version here.

TechNet Webcast: How Microsoft IT Deployed Exchange 2010 on Premises

Scott Schnoll [MSFT] — Sun, 09 May 2010 17:01:00 GMT

Ever wondered how we deployed Exchange 2010 on premise internally at Microsoft? You can find out on Tuesday, May 11th (9:30 AM Pacific Time), when Microsoft IT Service Manager Luisa Garcia Zapata presents a 60-minute Webcast that discusses the Exchange Server 2010 deployment within Microsoft IT. She'll cover design criteria, hardware choices, and operational changes related to our deployment.

You can register for the event at https://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032448859. Note that a Windows Live ID is needed to register.

New High Availability Features in Exchange 2010 SP1

Scott Schnoll [MSFT] — Sat, 10 Apr 2010 15:13:00 GMT

As you may read by now, we've started to release the first details on Exchange 2010 SP1. In addition to the features mentioned in the Exchange Team blog post, there's a lot of other goodness in there, too. In this post, I describe the new high availability features in Exchange 2010 SP1, and there are some pretty awesome features.

But a quick note: everything in this post is based on pre-release software and preliminary information that is subject to change. These are things we are working on or are about to work on. The feature names, behaviors and descriptions used below might not be the final names, behaviors and descriptions. The behvaiors described may or may not make it into the final shipping version of SP1 or a future version of the product. Standard disclaimers apply regarding pre-Beta software and content.

EDITED December 1, 2010 to remove reference to cross-site feature that did not make it into SP1.

In the Exchange team blog post, and in my previous post on SP1, you read about the new UI enhancements for DAGs in the Exchange Management Console. These enhancements complete the GUI experience for DAGs. In the RTM version of Exchange 2010, there is GUI to create the DAG, to manage DAG membership, and to manage DAG networks. But the GUI assumed the use of DHCP for the DAG IP address(es). If you wanted use one or more static IP addresses for your DAG, you had to use the Set-DatabaseAvailabilityGroup cmdlet in the Exchange Management Shell. In SP1, you can do all IP addressing for your DAG in the GUI. I'm proud to say that I had a hand in making this change happen. :-)

In addition, you can now use the DAG Properties GUI to manage the DAG's alternate witness server and directory settings. In RTM, only the DAG's witness server and directory could be managed through the GUI. If you wanted to configure an alternate witness server and alternate witness directory in RTM, you had to use the Exchange Management Shell.

Ok, so on to the new stuff we hope to have for high availability in Exchange 2010 SP1. The following new features for high availability and improvements to existing high availability features are available in SP1:

Continuous replication - block mode
Active mailbox database redistribution
Improved Outlook cross-site connection behavior and experience
Enhanced datacenter activation coordination support
New and enhanced management and monitoring scripts
Improvements in failover performance

These features are discussed in greater detail below.

Continuous Replication - Block Mode

In the RTM version of Exchange 2010 and in all versions of Exchange 2007, continuous replication operates by shipping copies of the log files generated by the active database copy to the passive database copies. Beginning with SP1, this form of continuous replication is known as continuous replication - file mode. SP1 also introduces a new form of continuous replication known as continuous replication - block mode. In block mode, as each update is written to the active database copy's active log file it is also shipped to the passive mailbox copies. In the event of a failure affecting the active copy, the passive copies will have been updated with most or all of the latest updates. The active does not wait for replication to complete in order to preclude replication issues from affecting the client experience. Continuous replication - block mode is only active when continuous replication is up-to-date in file mode. The transition into and out of block mode is performed automatically by the log copier. Block mode dramatically reduces the latency between the time a change is made on the active copy and when the change is replicated to a passive copy. In addition to replicating individual log file writes, block mode also changes the activation process for a passive copy. If a copy is in block mode when a failure occurs, the system uses whatever partial log content is available during the activation process.

Active Mailbox Database Redistribution

This feature is present in two forms. The first form is a script that can be periodically run by administrators to balance the distribution of active database copies across a database availability group (DAG). The second form we hope to implement is the addition of copy distribution awareness to Active Manager's best copy selection (BCS) process.

Enhanced datacenter activation coordination support

Exchange 2010 RTM includes a special mode for DAG site resilience support called datacenter activation coordination (DAC) mode. In DAC mode, Exchange cmdlets can be used to perform a datacenter switchover. In the RTM version, DAC mode is limited to DAGs with at least three members that have at least two or more members in the primary datacenter.

In SP1, DAC mode has been extended to support two-member DAGs that have each member in a separate datacenter. DAC mode support for two-member DAGs leverages the witness server to provide additional arbitration. In addition, DAC mode has been extended to support DAGs that have all members deployed in a single Active Directory site, including Active Directory sites that have been extended to multiple locations.

So basically in SP1, you can now use DAC mode for all DAGs with two or more members.

New and Enhanced Management and Monitoring Scripts

SP1 includes several new and enhanced scripts that greatly improve the management and monitoring experience. The following scripts are included in SP1:

CheckDatabaseRedundancy.ps1 (new) - This script is used to check the redundancy of replicated databases, and it will generate events if database resiliency is found to be in a compromised state (e.g., you are down to a single copy of a replicated database). This is accompanied by a System Center Operations Manager management pack change that can be used to monitor for databases without redundancy, which is particularly useful in an environment with JBOD.
StartDagServerMaintenance.ps1 and StopDagServerMaintenance.ps1 (new) - This script is used to take a DAG member of service for maintenance. It will move active databases off of the server and block databases from moving to that server. It will also make sure all critical DAG support functionality (e.g., the PAM role) that might be on the server is moved to another server, and blocked from moving back to the server. A second script (StopDagServerMaintenance) is provided to complete the operation and remove the blocks.
CollectOverMetrics.ps1 (enhanced)
CollectReplicationMetrics.ps1 (enhanced)

Improvements in Failover Performance

We're also looking at including changes targeted at improving failover and switchover performance and behavior in SP1. Other changes are targeted and tuning timeouts and other algorithmic details to improve failover performance, as well as I/O performance after failovers.

First Details of Exchange Server 2010 Service Pack 1 Available!

Scott Schnoll [MSFT] — Wed, 07 Apr 2010 13:37:00 GMT

We've published a post on the Exchange Team Blog that provides the first public details about Exchange Server 2010 Service Pack 1 (SP1). SP1 will of course include fixes and enhancements in the areas customers have helped us identify (including code from all of the Exchange 2010 post RTM update rollups we've released to date). But SP1 will also include some new features and functionality changes, as well. For example, we've made several improvements to the Multi-Mailbox Search features:

A new search preview helps with early case assessment by providing you an estimate on the number of items in the result set-with keyword statistics-before e-mail located in the search are copied to the designated discovery mailbox.
And, a new search result de-duplication option, when checked, only copies one instance of a message to the discovery mailbox.

We've also made improvements to the Exchange Management Console (EMC) and the Exchange Control Panel (ECP). For example, one of my favorite changes is in there - new GUI property fields for database availability group (DAG) IP addresses and alternate witness server and alternate witness directory settings:

There are other cool GUI enhancements, too:

Create/configure Retention Tags + Retention Policies in EMC
Recursive public folder settings management (including permissions) in EMC
Configure Transport Rules in ECP
Configure Journal Rules in ECP
Configure MailTips in ECP
Provision and configure the Personal Archive in ECP
Configure Litigation Hold in ECP & EMC
Configure Allow/Block/Quarantine mobile device policies in ECP
RBAC role management in ECP

Finally, there are two big changes with respect to the archive mailbox. Both are such huge changes, that I don't want to spoil the surprise. So, head over to the Exchange team blog, and check out the post Yes Virginia, there is an Exchange Server 2010 SP1.

Update to Windows Server 2008 Brings Failure Behavior Change for the File Share Witness resource

Scott Schnoll [MSFT] — Mon, 15 Feb 2010 14:43:00 GMT

My friend and colleague, Tim McMichael, recently blogged about a behvaior change that was made in Windows Server 2008 R2 that was back-ported to Windows Server 2008. The basics of the behavior change are as follows:

When the server hosting the File Share Witness becomes unavailable, the File Share Witness resource will fail and cause the Cluster core resources to move between nodes. Assuming the File Share Witness server remains unavailable, it's corresponding cluster resource will remain in a failed state. If the Cluster service determines that the File Share Witness resource is needed to maintain quorum, and the witness resource is in a failed state, the Cluster service will attempt to bring the witness resource online. If the attempt is successful, quorum is maintained. If the online attempt is not successful, the cluster will lose quorum.

The back-port is in the form of a hotfix (KB978790). You can download the hotfix from http://support.microsoft.com/kb/978790. Note: The package is marked for the product Windows Vista, but it is actually for Windows 2008.

The hotfix is applicable to both Exchange 2007 (when running on Windows Server 2008) and Exchange 2010.

Exchange 2010 Mailbox Server Role Requirements Calculator v3.2 Available

Scott Schnoll [MSFT] — Fri, 22 Jan 2010 19:25:00 GMT

We just released an updated version of the Exchange Server 2010 Mailbox Server Role Requirements Calculator. This version includes several improvements and new features, as well as some important bug fixes. For more information about the updates to the Exchange 2010 Mailbox Server Requirements Calculator, check out Ross' blog post.

Installing Update Rollup 1 for Exchange 2010 on DAG Members

Scott Schnoll [MSFT] — Thu, 10 Dec 2009 17:43:00 GMT

Update Rollup 1 (UR1) for Exchange Server 2010 is available for public download, and we recommend installing it on all of your Exchange 2010 servers. In a few days, we'll refresh our content on TechNet, and the refresh will include step-by-step instructions for installing UR1 on Mailbox servers that are members of a database availability group (DAG). In the meantime, I thought I would post the steps here so you don't have to wait for the content refresh. So, here they are:

Servers that are members of DAGs do not use Microsoft Update to install update rollups. Instead, update rollups must be downloaded from the Microsoft Download Center and installed manually. When you install an update rollup on a server that is a member of a DAG, several services will be stopped during the installation, including all Exchange services, and the Windows Cluster service. The general process for installing update rollups on a DAG member is as follows:

Suspend activation for the databases on the server being updated.
Perform a server switchover so that all databases on the server are passive copies. There will be a brief interruption in service for the mailboxes hosted on the active databases during the switchover process.
Install the update rollup.
Resume activation for the databases on the updated server.
Perform database switchovers as needed.

You can download the latest update rollup for Exchange 2010 from the Microsoft Download Center.

To update all DAG members, perform the following procedures on each member of the DAG, one at a time. You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Database availability groups" entry in the High Availability Permissions topic.

Install a Update Rollup on a Database Availability Group Member

Suspend activation for the database copies on the server being updated

Run the following command in the Exchange Management Shell:

Get-MailboxDatabaseCopyStatus -Server <Server> | Suspend-MailboxDatabaseCopy -ActivationOnly -Confirm:$False -SuspendComment "Install update rollup for Exchange 2010"

Perform a server switchover on the server being updated

In the console tree, navigate to Server Configuration > Mailbox.
In the result pane, select the Mailbox server you want.
In the Actions pane, select Switchover Server.
In the Switchover server database copies dialog box, do one of the following:

Accept the default setting of Automatically choose a target server (in which case, the system automatically selects the best Mailbox server for each database being switched over), and then click OK.
Use the specified server as the target for switchover, click Browse to select a Mailbox server, and then click OK.

Install the update rollup

Close all Exchange management tools.
Right-click the update rollup file (.MSP file) you downloaded and select Apply.
On the Welcome page, click Next.
On the License Terms page, review the license terms, select I accept the License Terms, and then click Next.
On the Completion page, click Finish.

Resume activation for the databases on the updated server

Run the following command in the Exchange Management Shell:

Get-MailboxDatabaseCopyStatus -Server <Server> | Resume-MailboxDatabaseCopy

Perform database switchovers as needed

In the console tree, navigate to Organization Configuration > Mailbox.
In the result pane, click the Database Management tab, and then right-click the mailbox database whose copy you want to activate.
In the action pane, click Activate a Database Copy.
On the Activate a Database Copy page, click Browse to select the server you updated.
Select the desired setting for the automatic database mount dial setting on the selected server.
Click Move to activate the selected passive copy of the database to the updated server.
On the Completion page, review the following, and then click Finish to close the wizard.

Download Exchange 2010 RTM!

Scott Schnoll [MSFT] — Tue, 10 Nov 2009 06:53:00 GMT

Download Microsoft Exchange Server 2010
Microsoft Exchange Server 2010 helps you achieve new levels of reliability and performance by delivering features that simplify your administration, protect your communications, and meet demands for greater business mobility. Download it today from http://go.microsoft.com/?linkid=9694890.