High Availability Tips in Exchange Server 2010

Exchange Server 2010 offers lots of highly availability (HA) feature that ensures availability of messaging services. HA can be achieved by deploying multiple Hub Transport, Edge Transport and Client Access servers and placing the additional servers within the Active Directory sites, which in turns ensure availability if any of the Exchange Server 2010 roles fails.

· Deleted Item Retention allows users to recover their deleted items or an entire folder from the Microsoft Office Outlook.

· Deleted Mailbox Retention allows administrators to restore entire mailbox if accidently deleted without restoring it from the backup.

·  Database Availability Group (DAG) creates one copy of a database that is hosted and active on another member server. Continuous replication maintains copies of databases on each Exchange Server.

· Archive Mailboxes are used to store users old messages to comply company policies or legal requirements.

· Message Retention Policy is applied when retention period is reached and messages are processed based on the actions defined in the Message Retention tags.

· Multiple Mailboxes databases, configuring storage appropriately and distributing users across these databases can significantly reduce the impact of failover.

How to Recover Deleted Mailboxes in Exchange Server 2010

Deleted mailboxes and user accounts are retained as disconnected mailboxes and we can recover them within the mailbox retention intervals. We can use Exchange Management Shell to recover deleted mailboxes. Deleted items are kept in dumpster till the retention period. The default retention period is 30 days.

We can use Cmdlet or Exchange Management Console to reconnect the disconnected mailbox to an existing Active Directory user.

How to Connect a Disconnected mailbox from Exchange Management Console

1. Open the Exchange Management Console.

2. Expand Recipient Configuration and click on Disconnected Mailbox.

3. From the Action pane, select the Connect Mailbox wizard.

How to Connect a Disconnected mailbox from Cmdlet

Syntax:

Connect-Mailbox -Identity OrigMailboxIdentity  -Database DatabaseIdentity -User NewUserIdentity

[-ActiveSyncMailboxPolicy PolicyId] [-Alias Alias] [-DomainController DCName]

[-ManagedFolderMailboxPolicy PolicyId] [-ManagedFolderMailboxPolicyAllowed <$true | $false>]

[-Archive <$true | $false>] [-Equipment <$true | $false>] [-Room <$true | $false>] [-Shared <$true | $false>] [-ValidateOnly <$true | $false>]

[-LinkedCredential Credential] [-LinkedDomainController DCName]

[-LinkedMasterAccount UserId]

Usage:

Connect-Mailbox -Identity "Sachin Mehn"

-Database "Manager Mails" -User "TECHPEOPLES\sachm -Alias "sachm"

Connect-Mailbox -Identity "Sachin Mehn"

-Database "Manager Mails" -LinkedDomainController Exch001

-LinkedMasterAccount "TECHPEOPLES\sachm"

We can also delete the disconnected mailboxes from the mailbox database by using Remove-Mailbox cmdlet.

Legal Hold in Exchange Server 2010

Legal Hold feature can be used to preserve mailbox items deleted be the users (soft or hard deletion), and placing mailboxes on hold as well.

Unlike previous Exchange versions which use dumpster, Exchange Server 2010 uses a new feature called, Recoverable Items Folder for legal hold. The Recoverable Item Folder is hidden by default to the users when they try to view it from Microsoft Outlook, Outlook Web App or any other e-mail clients. When a message is soft or hard deleted by a user, that message is moved to the Recoverable Items Folder, and from that it can be recovered within 14 days, by default.

User and Recoverable Items Folder have their own quota in Exchange Server 2010. An Application log event is generated on the Mailbox server when Recoverable Items Folders exceeds its warning level of quota. The default RecoverableItemsWarningQuota is 20GB whereas; default RecoverableItemsQuota value is set to 30GB. We can change these values by using Set-MailboxDatabase Cmdlet.

Failover Redundancy and Load Balancing Methods in Exchange Server 2010

Microsoft Exchange Server 2010 provides us lots of tools for failover redundancy (in case of server failure) and load balancing (distributes traffic between servers). In this article, we will try to know a little bit about on these methods to get an idea of them:-

1.       High Availability and Site Resilience

Exchange Server 2010 offers us Database Availability Groups (DAGs) where we can deploy two Active Directory sites in two different locations, and keeping their mailbox data synchronized. In case one site fails, other site will take over its role. We can achieve high availability by configuring up to 16 mailbox servers for automatic recovery without installing any new servers. DAGs provides us local and site-level high availability.

2.       Online Mailbox Move

We can now move the mailboxes whilst the users are logged in. This is only possible if source mailboxes are residing on Exchange Server 2007 SP2 or later, or Exchange Server 2010. It will give users the continuous access to their mailboxes while their mailbox is in the moving process.

3.       Shadow Redundancy

It protects the messages when they are in the deletion process. Before they are actually deleted from the transport database, the transport server first verifies that all the next hops for the message have been completed. If next hop is not completed, the message is resubmitted for delivery to the next pending hop. This is very similar to Transport Dumpster. In shadow redundancy, the source server will delete the shadow copy of the message after it receives the discard status notification from the next hop.

4.       Load Balancing

As the name suggests, it provides balancing of network load or traffic across different servers. Unlike previous Exchange versions, where Mailbox servers were directly connected with the Outlook, Exchange Server 2010 Client Access Server is now used for connecting internal or external Outlook connections.

5.       Block mode

It was introduced in the Exchange Server 2010 SP1- which reduces the exposure of data loss during failover by replicating all logs to the passive database copies in parallel to writing them locally. In other words, it reduces the possibility of any data loss during a failover and the time it takes to perform a switchover.

6.       Multiple Exchange Server roles can now reside on servers providing high availability, thereby reducing servers cost.

7.       High availability can be achieved with only 2 servers in Exchange Server 2010, unlike in Exchange Server 2007, where 4 servers are required.

8.       Exchange Server 2010 added more new options in the Exchange storage menu, like SATA hard disk drive and raid-less- JBOD. Application-level redundancy allows RAID-less (JBOD) storage configuration by replicating 16 copies of each mailbox database resulting in cost savings.

9.       Exchange Server 2010 reduced administrative overhead cost by eliminating the need for creating failover cluster to achieve high availability when Exchange 2010 High availability feature is enabled.

10.   Database Availability Groups (DAGs) provides failover on individual mailbox database level, but not on storage group level which takes time to move the failed mailbox server to the other clustered node or other option was to restore from the backup leaving users offline for few minutes.

Messaging Records Management (MRM) in Exchange Server 2010

In this exercise, we will perform below steps so that items in Deleted Items folder are permanently deleted in 30 days and applying new retention policy with the mailbox.

· Create a Retention Tag

· Create a Retention Policy

· Apply a Retention Policy to Mailboxes

· Schedule the Managed Folder Assistant

· Start the Managed Folder Assistant

Create a Retention Tag

Retention policy tags are created for default folders like, Inbox, Deleted Items, Sent Items etc, but no support for the Calendar and Tasks folders.

Default policy tags are applied to all items having no retention tag applied.

Personal tags are created for applying retention settings on custom folders.

You can't use the EMC to create a retention policy tag, default policy tags and personal tags.

In this example, we will create a new Retention policy tag, RETAG-DeletedItems for the default Deleted Items folder to permanent delete items in 30 days.

New-RetentionPolicyTag " RETAG-DeletedItems " -Type "DeletedItems" -Comment "Permanent delete items in 30 days" -RetentionEnabled $true -AgeLimitForRetention 30 -RetentionAction PermanentlyDelete

Create a Retention Policy

This example will create a new retention policy RP-FIN and links the tag RETAG-DeletedItems

This example creates the retention policy RP-VPs and links the tags RPT-VPs-Default, RPT-VPs-Inbox, and RPT-VPs-DeletedItems to the policy.

New-RetentionPolicy "RP-Tech" -RetentionPolicyTagLinks " RETAG-DeletedItems "

You can't use the EMC to create a retention policy.

Apply a Retention Policy to Mailboxes

This example applies the retention policy RP-Tech to Sachin's mailbox:

Copy Code Set-Mailbox "Sachin" -RetentionPolicy "RP-Tech"

You can't use the EMC to apply a retention policy to a mailbox.

Schedule the Managed Folder Assistant

In Microsoft Exchange Server 2010, the Managed Folder Assistant is scheduled to run from 01:00 (1:00 A.M.) to 09:00 (9:00 A.M.) daily. You can modify the schedule to suit your requirements.

Use the EMC to schedule the Managed Folder Assistant

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the "Messaging records management" entry in the Messaging Policy and Compliance Permissions topic.

1. Open the Exchange Management Console.

2. Click Server Configuration and then Mailbox.

3. Right-click on the Mailbox server where you want to schedule the Managed Folder Assistant, and then click on Properties.

4. Click on the Messaging Records Management tab.

5. Click Custom Schedule in the Schedule the Managed Folder Assistance box.

6. Select the times and days for Managed Folder Assistant to run.

7. Click Ok.

How to Schedule the Managed Folder Assistant from the Shell

You can use the Set-MailboxServer Cmdlet to schedule the Managed Folder Assistant. Below command will schedule the Managed Folder Assistant to start running at 15:00 (Sunday) until all mailboxes are processed or 16:00 (the following Sunday), whichever is first.

Set-MailboxServer -Identity EX01 -ManagedFolderAssistantSchedule "Sun.15:00-Sun.16:00"

Start the Managed Folder Assistant

Run the below command to start the Managed Folder Assistant

Start-ManagedFolderAssistant

You can't use the EMC to manually start the Managed Folder Assistant.

File Share Witness in Exchange Server 2010

As we know, Exchange Server 2007 supported three different kind of high availability methods which varied from the single server to across multiple Exchange servers. And then, Exchange Server 20010 introduced Database Availability Group (DAG) which is essentially a collection of at least two and maximum 16 mailbox servers to achieve the high availability.

You should be familiar with the term, File Share Witness (FSW) if you have already implemented the CCR in the Exchange 2007 environment. As the name suggest, file share witness is a file share residing on the third server outside of the DAG for ensuring quorum availability in the cluster. We can provide the file share witness directory and share name while creating the DAG.  Unlike Exchange 2007, where Microsoft recommended hosting file share witness on the Hut Transport server, Exchange 2010 provides you full control to host file share witness on non-Exchange Server as well, but you have to add the Exchange Trusted Subsystem Universal Security Group to the local Administrator Group on the FSW Server.

You can configure the FSW and FSW directory during DAG creation as shown below:-

New-DatabaseAvailabilityGroup -Name DAG01 -WitnessServer ACENT001 -WitnessDirectory C:\FSW_DAG01

How to Design DAG environment in Exchange Server 2010

As we know, Exchange Server 2010 DAG supports 16 members with up to 1600 database; therefore, it turns into complex part to design the layout. The rule of thumb is that the more servers in the DAG provide us more option for sizing databases copies efficiently and resiliently.

  

Above scenario is designed to support a single-node failure. If more than one member is down, four databases would be offline. Just adding more nodes in the DAG does not automatically enable it to sustain multiple failures. You should be very careful while adding nodes in the DAG and keeping database copies to the relevant nodes.

As you can see in the below diagram, servers are mirrored to each other in a four-node DAG. Failure in A and B or C and D would cause a large number of databases unavailable. This design does not provide better redundancy.  

  

Follow the below two rules while designing DAG redundancy to meet your SLAs:-

1.       One-member failure requires two or more high-availability copies, two or more servers, and a witness server.

2.       Two-member failure requires three or more high-availability copies, four or more servers, and a witness server.

We can design DAGs in a variety of environments which solely depends upon your organization SLAs and recovery time/point objective for the mailbox services.  We will discuss on few DAG design which may fit in your environment:-

·         Two-Member DAG in Single Datacenter/Active Directory Site

·         Four-Member DAG in Single Datacenter/Active Directory Site

·         Four-Member DAG in Two Datacenter/Active Directory Sites

·         Two Four-Member DAGs in Two Datacenter/Active Directory Sites

Two-Member DAG in Single Datacenter/Active Directory Site

This design is suited for small offices and branch offices to meet their high availability requirements with the smallest possible DAG design taking into account the cost factor associated with adding more servers and don’t require site resiliency. This design provides redundancy for the Client Access, Hub Transport and mailbox roles by using only two servers.

Unified Messaging role can also be co-located in this scenario with other roles, but it is not recommended by the Microsoft.

It is always recommended to use load balancing for achieving high availability for Client Access and Hub Transport. Windows Network Load Balancing can’t be used, therefore other load balancing options must be used.

Two-member DAG provides three quorum votes (two member server and one witness server). Outage in one vote will not impact the services. But the loss of two of the voters (for example, a DAG member and the witness server) will result in loss of quorum and service interruption. 

Four-Member DAG in Single Datacenter/Active Directory Site

Two or three-member DAG restricts us to failure in only one vote, but four-member DAG provides greater resiliency which has five quorum voters and can sustain the loss of two voters without impacting the service.

 

Two Four-Member DAGs in Two Datacenter/Active Directory Sites

As discussed above, a four-member DAG would cause one datacenter losing voters and quorum and resulting offline. We can deploy the two four-member DAGs to overcome this problem. We can configure one witness server in each datacenters. Since both DAG contains equal number of members and one witness server, outage in WAN will maintain the service across the datacenters.

 

• For DAG1, members REDMBX1 and REDMBX2 would be in the majority and would continue to service users in the Chicago datacenter because they can communicate with the DAG1's witness server, HUB1.
• For DAG2, members BLMBX3 and BLMBX4 would be in the majority and would continue to service users in the Madrid datacenter because they can communicate with DAG2's witness server, HUB2.

Using Mailbox Servers That Don't Contain Databases in a DAG for Additional Votes

As we mentioned earlier, larger DAGs provide greater resilience because they can maintain more failures without service interruption. One more design strategy can help us to get more resilience by leveraging the Hub Transport servers. We can use the existing Hub Transport servers in our environment by adding Mailbox server role (without any databases or database copy) on them and then add that server to the DAG just for voting. More voters can sustain more voter failures in the DAG and still maintain the quorum.

 

In the above diagram, we have four-member DAG extended across two remote datacenters. We have four voters in this scenario (4 DAG members and 1 Witness server). Failure in losing two voters would still maintain the quorum. If the DAG loses a third voter, it loses quorum and would require manual administrative intervention to restore the services.

Based upon the above designing scenarios, let us try to put them in some possible designing structure for our organization. We can have either Active/Passive or Active/Active model.

 

Refer this link for more details