It does not take much to encourage me, and the positive comments I received on the post Inside Exchange 2010: What is the Transport Dumpster? was enough to convince me to take on another Inside Exchange 2010 post. In this post, we are going to take a look at a feature added to Exchange 2010 called Shadow Redundancy.

Shadow Redundancy is related to the Transport Dumpster in that it is a high availability mechanism implemented to prevent data loss if a failure occurs while a message is in transit. Whereas the Transport Dumpster is designed to protect against the failover of a mailbox server that is a part of a database access group, which means that it doesn’t offer anything for mailbox servers that aren’t, Shadow Redundancy can protect against data loss in an Exchange environment that includes only a single Edge Transport server and a Hub Transport/Client Acesss/Mailbox server.

Given the key role of a Hub Transport server, and the number of messages that could be in transit to a Hub Transport server if it suffers a failure, the potential for data loss might be significant without a way to preserve messages sent to an HT server until it can be confirmed that the messages were received, and this is where Shadow Redundancy comes into play. Shadow redundancy keeps a copy of every message it sends into the Exchange infrastructure until it receives a confirmation that the message was delivered successfully to the next server in the chain. Message delivery can include multiple hops in a larger environment where a message may need to cross multiple Hub Transport servers, and can have multiple paths to the destination mailbox. Shadow Redundancy only needs to keep a copy of a message until the next hop confirms that it has the message committed to its database. Once that confirmation is received, the message can be deleted from the transport database of the sending server. The process will repeat along each hop until the message finally reaches a mailbox server and is committed to the mailbox database. If a Hub Transport server sends a message to another server, and that server has a failure (unplanned, or even something as simple as an administrator shutting it down for maintenance, then when the sending server queries for delivery status, the confirmation cannot be obtained. The sending server will keep the message in a shadow queue so that when the server comes back online, it can resend the message. It will try to deliver the message again at five minute intervals, and will retry three times.

You may see this shadow queue appear and disappear when you are viewing queues on Edge or Hub Transport servers. The higher the volume of mail sent, the more likely you will see this queue appear and disappear as all messages are confirmed as being committed to the transport or mailbox database. The settings for Shadow Redundancy can be viewed, and changed, using the Exchange Management Shell. To view the parameters of Shadow Redundancy, enter this command at the EMS.

Get-TransportConfig | fl Shadow*

…fl is short for Format-List and Shadow* limits the output to parameters whose names start with Shadow.

There are four parameters, and their default values are returned.

ShadowRedundancyEnabled              : True
ShadowHeartbeatTimeoutInterval       : 00:05:00
ShadowHeartbeatRetryCount            : 3
ShadowMessageAutoDiscardInterval     : 2.00:00:00

Shadow Redundancy is enabled by default, and is set to check for delivery confirmations using a 5 minute heartbeat, and to retry 3 times. If it never gets a response, it will automatically delete messages after 2 days. All of these values can be configured, but should not be unless your specific situation is unusual, like a WAN connection that chronically fails. To change the parameters, you can use the Set-TransportConfig command.

If you found this post useful, leave a comment or retweet it and I’ll work on adding a third to the series.

Inside Exchange 2010: What is Shadow Redundancy?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

There has been a lot of buzz created about Exchange Server 2010’s new database capabilities.  The terms “RAID-less” and “backup-less” get mentioned in conversations but are often taken out of context, or used with incorrect assumptions.

But why are people so excited about Exchange Server 2010 and talking about throwing out RAID and backups?  There are three main reasons for this.

Three Big Exchange Server 2010 Improvements

Improved Database Performance – the Exchange database schema has been overhauled to deliver much greater efficiency and therefore much better performance in terms of disk I/O.  This overhaul stirred some controversy because it put an end to single instance storage, however the small loss of SIS delivers much greater benefits in performance.

Improved High Availability – Exchange Server 2007 had four different HA/DR options, each one with its own complexities and limitations, and each one administered in a different way.  Exchange Server 2010 simplifies this to one single, vastly more effective high availability model called Database Availability Groups.  This basically involves replicating a database between as many as 16 servers (DAG members) that can seamlessly fail over if any individual server experiences a fault.

Improved Data Retention – In Exchange Server 2010 mailboxes and databases can be much bigger than previous versions, archiving has been built in, and longer retention is feasible making recovery of single items and mailboxes possible over longer periods without having to access backups.

These improvements have led to the idea that an organization can deploy multiple Exchange servers in a DAG using cheaper, slower storage sub-systems, without RAID to replicate the data, and without backing up because emails can be recovered almost indefinitely.

Which is true, but only if Exchange Server 2010 is deployed correctly with enough resources to make this possible.

Going RAID-Less for Exchange Server 2010

RAID-less mailbox servers is not recommended if you have not deployed at least three DAG members, so that there are at least three copies of each database.

Other server roles would naturally be protected by RAID for their operating system volumes, although you could go RAID-less for these as well provided there are more than one of each role deployed in a redundant configuration.

Going Backup-Less for Exchange Server 2010

A backup-less Exchange Server 2010 environment is more complex than some people seem to assume.  For a backup-less environment to be feasible you must:

• Have at least three DAG members across two physical locations
• Have at least one lagged database copy (this is a copy that “lags” behind at a set interval before committing replication data to the database)
• Have circular logging enabled for all of the databases
• Have your archive and retention settings fully implemented and optimized to prevent permanent deletion of data
• Have your Role-Based Access Control fully locked down to prevent inexperienced administrators from destroying the DAG itself through error or malicious intent
• Not be using Public Folders (which are not protected by DAGs)

Obviously that all becomes complex in its own right, not to mention potentially very expensive.  Multiple physical locations means more datacentre costs, and the number of DAG members increases the number of expensive Enterprise Edition licenses required for Windows Server 2008.

Even with all of the complexities understood and the expenses affordable for an organization, there still remains some risk of complete loss of email data through a disaster.  With that in mind it is more feasible that a less complex DAG deployment can simply be used to reduce the frequency of backups, rather than eliminate them entirely.

In summary, RAID-less Exchange servers may become common over time, but the idea of backup-less Exchange is unlikely to gain any real traction in production deployments.

Data Protection for Exchange Server 2010

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

The worst possible time to define your uptime and availability requirements for an Exchange environment is when that environment is unavailable.  No email administrator wants to hear “We need this working within 2 hours” when they are looking at a dead server that is going to take all night to recover.

Uptime and availability should be defined within an SLA, or Service Level Agreement.  An Exchange Server SLA should exist in all organizations, even those that provide their own internal IT services.  The SLA is between the IT supplier or IT department and the rest of the business, and clearly defines what is an acceptable downtime or outage of the Exchange environment.

Why Are SLAs So Important?

The existence of an SLA supports many facets of the design and operation of the Exchange Server environment.

Budget – When a business defines their service level requirements they are making a commitment to providing the funds necessary to deliver those service levels.  An SLA is one of the best pieces of leverage the IT department has to secure those funds and implement an appropriate Exchange system.  Without the backing of an SLA the IT department may struggle to get approval for Enterprise server licensing, multiple servers for clustering, and other high availability components.

Server and Network Design – Exchange Server environments are designed to meet defined SLAs.  Certain uptime expectations can only be met with the right server design.  A business that is willing to go a day without email would not need the same infrastructure deployed as a bank that can’t go more than 15 minutes without email.  Clustering, redundancy, site-to-site failover, are all design points that would be included or excluded based on the SLA.

Third Party Warranty – In very resilient environments, such as those with clustered servers, this is less of an issue.  But for an environment with SLAs for single points of failure, the right warranty response times need to be in place for SLAs to be met.  A 4 hour return to service target will not always work if it is paired with a 4 hour vendor response time, because the vendor meets their target simply by showing up on site within 4 hours.  After they then spend time fixing or replacing failed components, the IT team then has to potentially deal with other software and data recovery processes.

Backups – The backup system will be heavily influenced by the SLAs that are in place.  If the backup system cannot restore all of the required data within the SLA timeframe then of course the SLA cannot be guaranteed.

Staffing – The SLA will define the service levels for different times of day, and this will impact staffing levels.  If 8×5 support is all that is required, then that is a different staff level and rostering schedule than 24×7 support would be.

It all starts with the SLA.  Sometimes an organization has trouble defining their requirements before an actual outage occurs.  For those without any SLA at the moment my suggestions would be:

1. Analyze your current infrastructure and make an estimate as to how long a recovery would take under a variety of failure scenarios (e.g. single mailbox, single database, single server)
2. Identify the business processes that email supports and is involved in
3. Survey a sample of staff from various departments and teams, ensuring that each tier of employee is well represented in the survey

From that exercise you will gain an understanding of your business needs, technical capabilities, and the gaps that exist between them, and you can then begin work to formalise them as SLAs and implement changes in the environment to close those gaps.

Exchange Server SLAs, and Why You Need One

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In my recent post I examined the question of whether Exchange Server 2010’s new replication and retention features could mean an organization no longer needed to back up their Exchange servers.

One reader emailed me to suggest that avoiding backups would be unwise, citing the example of potential corruption within the database that might replicate to all copies within the Database Availability Group and cause loss of data.

The scenario is one that definitely needs to be considered.  Although Exchange Server 2010 includes application intelligence to detect and handle some database corruption scenarios, there still exists the possibility of logical corruption leading to data loss.

Fortunately the solution to this problem is already included in the DAG feature of Exchange Server 2010.

If you are already familiar with Exchange Server 2007 Standby Continuous Replication then you already understand the concept of replay lag time.  Replay lag time is a configurable setting on each database copy within a DAG that delays the replay of a transaction log into that database replica.  A database copy with a replay lag time of more than zero is referred to as a lagged copy.

For example, within a DAG there may be 3 servers hosting replicas of Database 1.  Two of the servers are located in a primary data center, and the third server is located at a secondary data center.

The servers at the primary data center are configured with a replay lag time of zero, meaning the passive copy of the database is kept up to date with the latest transaction log information in near real-time.  A failure of one server permits seamless failover to the second server and continued email operation for the business.

The server at the secondary data center can be configured with a lag of 24 hours.  This means that even though transaction logs are immediately replicated to the server, they are not replayed into the database copy until 24 hours later.

This configuration means some additional configurations for the high availability design of the Exchange Server 2010 environment.

• The lagged copy is not for high availability through automatic failover, rather it is for disaster recovery scenarios.
• When a lagged copy is activated it can take some time to come online depending on the number of transaction logs that need to be replayed and the speed of the server.
• When a lagged copy is activated the administrator can choose to replay all log files, or only those log files up to a certain point in time.
• Because a lagged copy is generally activated only in a disaster scenario, it is possible that no other database copies within the DAG will be functional at that point in time.  To maintain a resilient Exchange Server environment either the server hosting the lagged copies should be configured with RAID storage, or more than one server should be configured with a lagged copy of the database.
• Lagged copies are themselves susceptible to corruption.  The servers must be monitored for event log errors that indicate a problem.  When a problem occurs the lagged copy must be reseeded, which therefore temporarily loses its lagged status.

What if You Never Backed Up Your Exchange Server Again? (Part 2)

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Imagine for a moment that you never had to back up your Exchange servers again.  Sounds crazy right?  Well with Exchange Server 2010, it may not be as crazy as you think.

In a recent post I described the killer new High Availability feature of Exchange Server 2010 – the Database Availability Group (or DAG for short).

A DAG is an Organization-level object that allows a database to have several passive replicas on other servers (DAG members).  When a DAG is configured it permits individual mailbox databases to failover to passive instances should any problem with the active database arise.

The nature of DAGs means that they can be deployed to protect from failures at almost any layer of the Exchange infrastructure.  DAGs can protect from anything from a single failed server hard disk to an entire data center failure as long as the DAG is architected accordingly.

How this relates to backups is simply this – if a database is protected from all failure scenarios by the DAG, why would you need to back it up at all?  Let’s take a closer look at this question.

Exchange Failure Scenarios

The DAG will protect data from any Exchange failure scenario:

Database Corruption –the database will simply failover to one of the passive copies.

Server or Server Component – all active databases on the server (or just those on the disk that failed if that is the case) will failover to one of the passive copies.

Network Failure – if a DAG member becomes unreachable another member will bring those databases online.

Site Failure – because DAGs can easily span multiple physical locations, even those in separate Active Directory sites, if a data center fails another DAG member at a different site will bring those databases online.

Other Data Loss Scenarios

Deleted Mailbox Items – Exchange Server 2010 introduces a new feature known as Single Item Recovery.  This means that when a user deleted a mailbox item it is put into a recoverable items area instead of being permanently deleted.  This area has a configurable retention period, and so the administrator can simply configure a reasonable period to allow people to recover deleted items without relying on backups.

Deleted Mailboxes – although it is quite easy to export mailboxes before deleting them this requires manual effort to do so.  However because of the Journaling capability of Exchange Server the mailbox items for deleted mailboxes can be recovered from the journal store.  In addition to this, deleted mailboxes are not immediately purged from the database and so can be easily reattached if necessary.

What’s the Catch Then?

You might be thinking from the above that it is entirely possible and practical to never back up your Exchange Server 2010 environment provided the right features are configured for replication and retention.

In fact in some organizations this level of protection will be quite acceptable.  But none of the above protects the Exchange environment from accidental or malicious deletion of Exchange Server data.

For example, if someone deleted the Database Availability Group all of the associated databases would also be deleted.  Without a backup these could not then be restored.

To protect from both accidental and malicious destruction of the Exchange environment you must make use of the new Role Based Access Control (RBAC) features in Exchange Server 2010.  Although RBAC itself is not a new concept, previous versions of Exchange Server never included the depth and granularity of control over access permissions that Exchange Server 2010 does.

Using RBAC to allow people only the minimum permissions they need to do their job can protect the environment from accidental or malicious deletion of data.  Ultimately though someone needs to be trusted with the highest level of permissions, which still opens the door to some risks.

It is likely that even the least risk adverse organizations will still employ backups of some kind for their Exchange Server 2010 environment, though perhaps on a less frequent schedule.

Do you plan to modify your normal backup practices in light of the new Exchange Server 2010 features?

What if You Never Backed Up Your Exchange Server Again?

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

I recently wrote a five part series about Exchange Server 2007 high availability, describing each of the HA features (LCR, SCC, CCR, and SCR) in detail and demonstrating their uses, strengths and weaknesses.

With the release of Exchange Server 2010 these high availability features are no longer available.  The features have now been replaced by a single high availability option known as Database Availability Groups (or DAGs for short, admittedly a horrible acronym for what is truly the product’s finest feature).

A little background is required to fully understand the evolution of Exchange storage architecture to its current incarnation in DAGs.  Going back to Exchange Server 2003 the product was limited to a maximum of 4 Storage Groups, each containing a maximum of 5 databases.  This meant a maximum of 20 databases (of either Mailbox or Public Folder type) per Exchange server.

Exchange Server 2007 improved on this in two ways.  Firstly, the product was limited to 5 Storage Groups and 5 databases for the Standard Edition, and up to 50 Storage Groups and databases for the Enterprise Edition.  The best practice with Exchange Server 2007 was to use one Storage Group per database, unlike Exchange Server 2003.

Naturally this lead to the question of why have Storage Groups at all?  Exchange Server 2010 answers this question by doing away with the concept of Storage Groups entirely.  Databases are now Organization-level objects that contain both the transaction logs and the database itself.

Exchange Server 2010 then introduces the Database Availability Group to provide high availability.  A DAG is a group of Mailbox Servers (up to 16 per DAG) that replicate databases and perform automatic failover and recovery for either individual database or entire server failures.

So how does this compare to Exchange Server 2007 high availability?  An immediate advantage is that DAGs unify Exchange high availability into a single feature and management toolset, unlike Exchange Server 2007 which had 4 different features each managed with different tools.

Let’s take a more detailed look at each of the features to see how they compare to DAGs.Firstly, Local Continuous Replication (LCR) was ultimately a pretty useless feature.  LCR protected from failure of a single database by replicating it to other local disk storage.  Most servers already use some form of RAID or highly available storage such as SAN, so protecting from storage failures was usually not necessary.  LCR was also cumbersome to activate in a failure scenario.  In comparison, DAGs offer more useful replication of databases to an entirely different server which can also be located at a different site, offering both host and site resilience.  The failover is also automatic.

The two cluster models, Single Copy Cluster (SCC) and Cluster Continuous Replication (CCR) also carried some limitations.  Failover occurred at the server level instead of the database level, so the failure of a single database for any reason caused all of the databases to failover to the passive cluster node.  DAGs on the other hand offer database-level failover.  Exchange Server 2007 also required that an underlying failover cluster be configured first.  Exchange Server 2010 configures the underlying cluster automatically when the first server is added to a DAG, allowing what is called incremental deployment (ie, you can make any Mailbox Server a member of a DAG without having to rebuild it as a cluster first).

Standby Continuous Replication (SCR), which did offer site resilience for Exchange Server 2007, was cumbersome to deploy, manage, and activate in the event of a disaster.  Failover to the passive replica was not automatic and required manual intervention.  It also required manual modification of user mailbox attributes using scripts.  Again DAGs provided automated failover, but in addition to this the redirection of user Outlook clients occurs automatically.

Finally one of the most attractive features of Exchange Server 2010 high availability is that it does not require that other server roles be located to separate servers.  Exchange Server 2007 cluster nodes were Mailbox Servers only and could not also be Client Access or Hub Transport servers.  Exchange Server 2010 allows these roles to stay on the Mailbox Server even when it becomes a member of a DAG.  This greatly lowers the hardware and software costs of deploying a highly available Exchange environment.

Overall the Database Availability Group is one of the killer features of Exchange Server 2010 and is sure to be a popular deployment option for Exchange Server users.

Exchange Server 2010 Delivers Improved Availability

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In my last posts I discussed Exchange Server 2007 Single Copy Clusters, which is one of two clustering features available in Exchange.  In this post I will discuss the other type of Exchange Server 2007 clustering, Cluster Continuous Replication

What is Cluster Continuous Replication?

Cluster Continuous Replication (CCR) for Exchange Server 2007 would not be familiar to anyone who only has clustering experience with previous versions of Exchange.  In a CCR cluster two cluster server nodes connect to non-shared resources in an active/passive configuration.  Exchange storage group and mailbox database information is replicated between the active and passive node using asynchronous log shipping.  I explained asynchronous log shipping in the first part of this series on the basic concepts of Exchange Server 2007 high availability.  The same log shipping occurs in Local Continuous Replication.

The two CCR cluster nodes appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

CCR provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node, as well as protecting it from storage failure.  Because each cluster node is connected to its own non-shared storage, the failure of one does not impact the other.  This also means that CCR disk storage can consist of much cheaper hardware alternatives than an enterprise-grade SAN would cost, making Exchange high availability a reality for businesses with smaller budgets.

CCR is available in the Enterprise edition of Exchange Server 2007.  Because it uses an underlying Windows Server failover cluster, the servers that form part of the cluster must also run the Enterprise edition of Windows Server (either 2003 or 2008).

Like LCR a CCR cluster offers high availability as well as performance benefits.  Backup operations can be performed against the passive copy of the database, making it possible to back up the server at any time of day without impacting end user performance.

Another advantage of CCR over SCC is that it increases the maximum recommended mailbox database size from 100Gb to 200Gb, thanks to the additional reliability and recoverability of a CCR cluster.

How to Install a Single Copy Cluster

In this example two Windows Server 2003 Enterprise edition servers have been configured with the basic requirements of a failover cluster:

• A public network interface for normal network operations
• A private network interface for the cluster “heartbeat”
• Matching disk configurations

Because there is no shared disk storage the cluster is installed as a Majority Node Set.

A Majority Node Set cluster needs to be configured with a third node called the File Share Witness.  The FSW acts as a “tie breaker” in the event that one of the cluster nodes fails.  One of the best places to locate the File Share Witness is on the Hub Transport Server in that site.

One the failover cluster has been configured we can install Exchange Server 2007 on the first node.  Run setup as normal, and when selecting the roles to install choose “Active Clustered Mailbox Role” as the server role.  You will notice that a clustered mailbox server cannot co-exist with any other server role.

Choose “Cluster Continuous Replication” as the cluster type, give the cluster a name, and specify a path for the database files.

Finally, give the cluster an IP address.

Exchange setup will configure all of the required cluster groups and resources for the underlying failover cluster automatically.  Once the active node is installed repeat the setup process on the passive cluster node, this time choosing “Passive Clustered Mailbox Role”.

Managing a CCR Cluster

For most Exchange administrative tasks the clustered mailbox server will appear like any other mailbox server.  For example, the storage group will show up as with any other mailbox server, but will have a value of “Clustered” for the Replicated attribute.

[PS] C:\>Get-StorageGroup

Name                      Server            Replicated
----                      ------            ----------
First Storage Group       EXCHMAILBOX       None
Second Storage Group      EXCHMAILBOX       None
First Storage Group       exchcms           Clustered

As with Single Copy Clusters a CCR cluster should not be administered using Cluster Admin (cluadmin.exe).  Instead, Exchange cluster operations such as moving the cluster group to another node should be performed in the Exchange Management Shell.

[PS] C:\>Move-ClusteredMailboxServer

Supply values for the following parameters:
Identity: exchcms
TargetMachine: exchmailbox2
MoveComment: Testing

Confirm
Are you sure you want to perform this action?
Moving clustered mailbox server "exchcms" to
target node "exchmailbox2" with move
comment "Testing".

[Y] Yes  [A] Yes to All  [N] No  [L] No to All
[S] Suspend  [?] Help
(default is "Y"):y

Similar to Local Continuous Replication the replication health of the CCR cluster should be monitored.

[PS] C:\>Get-StorageGroupCopyStatus

Name                SummaryCopy CopyQueue ReplayQueue
                    Status      Length    Length
----                ----------- --------- -----------
First Storage Group Healthy     0         0

The copy and replay queues should remain at zero or very close to it under most circumstances.  An increasing number for either can indicate a problem with replication.

Standby Continuous Replication

In the final post in this series I will demonstrate Exchange Server 2007 Standby Continuous Replication.

Exchange Server 2007 High Availability Part 4 – Cluster Continuous Replication

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In my recent posts I discussed the fundamentals of Exchange Server 2007 high availability and how to use Local Continuous Replication.  In this post I will demonstrate one of the two Exchange Server 2007 clustering methods, Single Copy Clusters.

What are Single Copy Clusters?

Single Copy Clusters (SCC) for Exchange Server 2007 is basically the same as clustering in previous versions of Exchange Server.  Two cluster server nodes connect to shared resources in an active/passive configuration.  The two servers appear to other computers to be a single system, and when one server node fails the clustered resources are able to fail over to the other node and continue operation.

SCC provides high availability for the Mailbox Server by protecting it from the failure of either cluster server node.  Typically the cluster will also consist of redundant networking (e.g. teamed network interfaces, multiple switches) and storage components (e.g. a SAN that is in itself a highly available system through redundant components).  The servers are also usually located in high quality data centers with redundant power and cooling.

SCC is available in the Enterprise edition of Exchange Server 2007.  Because it uses an underlying Windows Server failover cluster, the servers that form part of the cluster must also run the Enterprise edition of Windows Server (either 2003 or 2008).

Unlike LCR an SCC cluster offers high availability benefits but no performance benefits.  Because there is a single copy of each mailbox database within the cluster there is no opportunity to use a passive copy for backup operations.

How to Install a Single Copy Cluster

In this example two Windows Server 2003 Enterprise edition servers have been configured with the basic requirements of a failover cluster:

• A public network interface for normal network operations
• A private network interface for the cluster “heartbeat”
• Shared disk storage for the database, log files, and cluster quorum disk

Once the failover cluster has been configured we can install Exchange Server 2007 on the first node.  Run setup as normal, and when selecting the roles to install choose “Active Clustered Mailbox Role” as the server role.  You will notice that a clustered mailbox server cannot co-exist with any other server role.

Choose “Single Copy Cluster” as the cluster type, give the cluster a name, and specify a path for the database files.  The database path must be on a shared cluster disk.

Finally, give the cluster an IP address.

Exchange setup will configure all of the required cluster groups and resources for the underlying failover cluster automatically.  Once the active node is installed repeat the setup process on the passive cluster node, this time choosing “Passive Clustered Mailbox Role”.

Managing a Single Copy Cluster

For most Exchange administrative tasks the clustered mailbox server will appear like any other mailbox server.  For example, the storage group will show up as with any other mailbox server.

[PS] C:\>Get-StorageGroup

Name                      Server            Replicated
----                      ------            ----------

First Storage Group       EXCHMAILBOX       None
Second Storage Group      EXCHMAILBOX       None
First Storage Group       EXCHCMS           None

You can view the status of the CMS using the Exchange Management Shell.

[PS] C:\>Get-ClusteredMailboxServerStatus

Identity                        : EXCHCMS
ClusteredMailboxServerName      : EXCHCMS.contoso.com
State                           : Online
OperationalMachines             : {EXCHMAILBOX1 <Active,...
FailedResources                 : {}
OperationalReplicationHostNames : {exchmailbox1, exchmail...
FailedReplicationHostNames      : {}
InUseReplicationHostNames       : {exchmailbox1, exchmail...
IsValid                         : True
ObjectState                     : Unchanged

Although the CMS is configured as part of the Microsoft Cluster Service it should not be administered using Cluster Admin (cluadmin.exe).  Instead, Exchange cluster operations such as moving the cluster group to another node should be performed in the Exchange Management Shell.

[PS] C:\>Move-ClusteredMailboxServer
cmdlet Move-ClusteredMailboxServer at command pipeline
position 1

Supply values for the following parameters:
Identity: exchcms
TargetMachine: exchmailbox2
MoveComment: Testing

Confirm
Are you sure you want to perform this action?
Moving clustered mailbox server "exchcms" to target
node "exchmailbox2" with move comment "Testing".

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend
[?] Help  (default is "Y"):y

Cluster Continuous Replication

In the next part of this series I will demonstrate Cluster Continuous Replication for Exchange Server 2007.

Exchange Server 2007 High Availability Part 3 – Single Copy Clusters

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

In my last post I explained the basic concepts of Exchange Server 2007 high availability.  In this post I will demonstrate one of the Exchange Server 2007 HA features that is called Local Continuous Replication.

What is Local Continuous Replication?

Local Continuous Replication (LCR) uses asynchronous log shipping technology to maintain a copy of a mailbox database on another locally connected disk volume.

For example, the mailbox database and transaction logs may reside on fast, expensive SAN disks, but the LCR copy is kept on slower, cheaper SATA disks.

LCR provides high availability for the Mailbox Server by protecting it from a storage failure.  If the SAN disks failed or became disconnected for some reason the server could continue serving end users via the replica database, possibly at a degraded performance level if the slower disks were not able to handle the required I/O load.

Because LCR is available in both Standard and Enterprise editions of Exchange Server 2007 it is a fairly easy way to achieve some high availability for the server.Another advantage of LCR is that Exchange streaming backups can be performed off the replica database, which means backup I/O load does not slow down the production database.  This permits backups to be run any time of day with no fear of end user impact.

How to Enable Local Continuous Replication

In this example a mailbox server has been configured with a storage group containing a single mailbox database.  An additional disk volume has been mounted on the server, and we can now enable replication of this storage group to the second volume using LCR.

To enable LCR right-click on the storage group and choose Enable Local Continuous Replication.

Proceed through the wizard and set the storage group system file and log file paths.  These should be on a disk volume that is separate to the volume that holds the live database.  It should also be a volume of equal or greater disk capacity so that it can hold an entire replica of the production data.

Continue through the wizard and choose a replica path for the mailbox database as well.

When you are happy with your choices complete the wizard to enable LCR.

Depending on the size of the database and the number of transaction logs to be shipped and replayed this operation may take some time.  You can monitor the progress in the Exchange Management Shell.

As you can see, the storage group’s “Replicated” attribute has changed to “Local”.

[PS] C:>Get-StorageGroup

Name                      Server            Replicated
----                      ------            ----------
First Storage Group       EXCHMAILBOX       Local
Second Storage Group      EXCHMAILBOX       None

We can also view the progress of the log shipping. Each transaction log is first placed into the copy queue to be shipped to the replica folder.  Once it has been shipped it is placed into the replay queue, and then replayed into the database.

[PS] C:>Get-StorageGroupCopyStatus
Name                 SummaryCopy CopyQueue ReplayQueue
                     Status      Length    Length
----                 ----------- --------- -----------
First Storage Group  Healthy     2750      0
Second Storage Group Disabled    0         0

Under normal conditions once the initial replication has occured the copy and replay queues should be quite low.  A high number of log files waiting to be copied or replayed may indicate a problem with LCR.

Switching to the Replica Database

In this demonstration the production database has become corrupt and will not mount, and so the decision is made to activate the passive copy.  To bring the LCR replica database online right-click on the storage group and choose Restore Storage Group Copy.

Complete the wizard to enable the passive copy.  This process checks that the replica log files have been brought completely up to date and replayed into the replica database so that it is ready to be mounted.  Before the passive copy can be brought online it must be placed in the location of the original production database.  For a large database file copying it from one location to the other would be very time consuming.  Instead you should modify the drive letter and folder path of the passive copy so that it matches the original active copy.  For example, if the passive copy was in F:SG1Data-LCR, use Disk Manager to re-assign that volume to the drive letter E: and then rename the path to SG1Data.

Note that this is not necessary if during the Restore Storage Group Copy wizard you ticked the box to update the database paths to match the passive copy location.  This method means that you can immediately mount the database without having to remap any volumes, however it may cause confusion for administrators later on when they encounter an active database in what they thought was a passive replica location.

The activation of the passive copy is completed by simply mounting the database.  Once the database is back online you then need to re-enable LCR to protect it from future failure situations by using the same process as demonstrated earlier in this blog post.

Summary

As you can see Local Continuous Replication is a simple high availability feature to implement for an Exchange Server 2007 mailbox server and can be used to quickly recover from some database failure scenarios.  LCR also carries some additional benefits such as offloading backup I/O onto a passive copy.

In the next post in this series I will demonstrate Exchange Server 2007 clustering with Single Copy Clusters.

Exchange Server 2007 High Availability Part 2 – Local Continuous Replication

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

Microsoft Exchange Server 2007 has several different Mailbox Server high availability features included with the product.  Each of the features is similar to the others in some ways but also very different.

In this post I will explain each of the high availability features and which types of scenarios they are suitable for.

What is High Availability?

High availability is a term used to describe the avoidance of unplanned downtime for a computer system through the implementation of hardware and/or software solutions.  Generally speaking a high availability solution will involve the elimination of and single points of failure in the system, often by duplicating or replicating components of the system so that if one fails the other is able to continue performing the role.

An example of downtime would be an email server that has suffered a hard disk crash and is unavailable to users who are then unable to send or receive email.  An example of a high availability solution in this case would be the use of a RAID volume to protect from single disk failures.Exchange Server 2007 contains several high availability features in the Mailbox Server role that can protect a system from multiple types of failure.  These features are a combination of database replication and server clustering technology.

What is Asynchronous Log Shipping?

Some of the features I am going to describe will include the term “asynchronous log shipping“.  “Asynchronous” means “not synchronised“, and “log shipping” refers to the copying of a transaction log file from one location to another where it is then replayed into a replica of the original database to keep it updated with the changes made to the source database.

Exchange Server 2007 writes transaction log files of 1Mb in size, meaning as each log file reaches 1Mb it is closed off and the next transaction log file is created.  Asynchronous log shipping occurs after a transaction log file is closed off and no longer in use as the active log file.

In essence, asynchronous log shipping is how Exchange Server 2007 database replication occurs.

What is Clustering?

A server cluster is two or more servers working together to perform a particular role so that it appears to be performed by a single system.  There are several different types of clustering commonly used.

Compute Clusters – this refers to the combination of processing power to perform tasks at a high speed than a single system is capable of.  A compute cluster usually involves a master node and several slave nodes.  The master node hands off computational tasks to the slaves and then receives the completed tasks back from them.  For example, many animated movies are created using computer graphics that are rendered by compute cluster farms, with individual frames of animation being processed by different slave nodes.

Load Balanced Clusters – this refers to the combination of several systems to act as a single system by distributing workload across all of the cluster nodes.  For example, a cluster of two web servers will load balance web page requests, so that approximately half of the requests are served by one web server and half by the other.  Very highly trafficked web sites that need to handle millions of visitors each month will operate on load balanced clusters.

High Availability Clusters – these clusters, also commonly known as Failover Clusters, provide high availability for servers by having redundant nodes that are able to take over serving requests if the active node should fail.  Exchange Server 2007 clustering makes use of failover clustering.

Local Continuous Replication

In the next part of this series I will demonstrate the Exchange Server 2007 Local Continuous Replication feature.

Exchange Server 2007 High Availability Part 1 – HA Fundamentals

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators