After a painstaking examination of the various pros and cons of signing up for a cloud-based email service and that of an on-premise deployment, your company finally decides on the latter option.  Before jumping into deployment phrase however, there remain a number of important decisions that need to be made first.  Today, I want to highlight some of these areas, and offer some suggestions that I hope will be helpful to administrator tasked with setting up Exchange Server.

Deployment Scenario

While this article is about setting up Exchange Server “on-premise,” it is not an altogether uncommon occurrence for companies to host their servers in a data center.  Administrators should decide early if they would like such a deployment scenario, since cost and other practicalities may curtail the number of servers or appliances placed with a hosting provider.

On the other hand, businesses that opt to setup their Exchange Server within the bounds of their corporate networks will have another set of decisions to make.  This includes availability of sufficient upstream and downstream bandwidth on their existing Internet connectivity, and whether there is adequate static IP address for allocation to the new mail server.  In addition, redundancies may also need to be examined in terms of fallback Internet access and presence of uninterruptible power supply (UPS) to guard against power trips.

Edition of Exchange Server

A decision for Exchange 2010 is pretty much a no-brainer for companies setting up Exchange Server for the first time, though some may stick with the older Exchange 2007 for various reasons.  Do note however that both Exchange 2007 and Exchange 2010 require the presence of a 64-bit processor – which means that your 5 year old server hardware may not make the cut.  Finally, depending on whether you have the license for the stand-alone version of Exchange Server or as part of Small Business Server, there might be a need to acquire Microsoft Outlook separately.

And yes, companies who may be unable to deploy Exchange Server, but desire to have something compatible with Outlook may want to read Exchange-compatible email servers for suggestions.

Protective Mechanisms

Protective mechanisms can be segregated into two distinct components: protecting end-users from malware and spam, as well as procedures and tools to defend your Exchange Server from malicious hackers.  I wrote a post on Securing Your Microsoft Exchange 2010 Server in March, which linked to various resources with tips on how to defend your Exchange Server.  Getting a good spam filter is usually a more challenging proposition however, thanks to the constantly changing tactics used by spammers.  On this front, I would recommend that administrators check with sister-site All Spammed Up for the latest tips and developments on the anti-spam front.

Backup and Archiving

Inexperienced IT professions may confuse the need for proper backup and archival with the protective mechanisms mentioned in the previous section – they are not the same thing.  Although reactive in nature, backup and archival measures play a vital role to help businesses recover from catastrophic failures.  Indeed, even the largest corporations in the world like Google make use of offline backup as a last line of defense.  In the case of Google, I chronicled in The Big Gmail Crash and the Lesson for Email Administrators how the company’s tape backups helped them to recover from an internal bug that left the mailboxes of some users corrupted earlier this year.

Decide on an Exchange Server Role

Finally, businesses who are installing Exchange Server 2010 should be aware that it can operate in various roles:

• Mailbox Server
• Client Access Server
• Unified Messaging Server
• Hub Transport Server
• Edge Transport Server

All the above roles can be combined with the exception of Edge Transport server role, which is designed for deployment on perimeter networks.  An Exchange Server configured as an Edge Transport Server allows the establishment of a secure boundary to buffer between the internal network and the Internet – in effect acting like a proxy.

Administrators who are not familiar with the various roles of Exchange 2010 may want to look at Exchange 2010 server roles explained, which offers detailed explanations together with tips about hardware requirements.  In addition, Microsoft’s TechNet Understand the Exchange Server Roles in Exchange Server 2010 is also a worthwhile read on this topic.

Are there any other considerations that I’ve missed out?  Feel free to chip in!

Decisions to Make When Deploying an On-Premise Exchange Server

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

Something gained, something lost – so the saying goes as I remember. And with Microsoft Exchange Server 2010 there were many features lost, I mean removed. Here is a list of the features that were removed.

1. In Exchange Server 2007 you had three different types of replication to support high availability. But as of Exchange Server 2010, Local Continuous Replication (LCR), Cluster Continuous Replication (CCR) and Standby Continuous Replication (SCR) are no longer available. Even Single Copy Clusters (SCCs) have been removed. SCCs are reminiscent of earlier high availability solutions for Exchange but as of Exchange Server 2010 they are being replaced by Database Availability Groups (DAGs). Database Availability Groups are easily configured and are similar to disk drive related fault-tolerant solutions.
2. The deployment of Auto Archive based retention settings through Outlook 2010 via the Group Policy is no longer available. Retention policies can now be set by way of the Messaging Records Management (MRM) features in Microsoft Exchange Server 2007 and later versions.
3. Windows Server Fail-over Clustering has also been removed from Exchange Server 2010. A lot of Exchange Administrators reported that the fail-over clustering was too complex and difficult to manage. The result was that there were more errors and problems associated with Windows Server Fail-over Clustering to outweigh the benefits. It was therefore pulled from Exchange Server 2010.
4. Exchange Server 2007 included built-in support for incoming faxes but is no longer supported in Exchange 2010. Email administrators will have to evaluate third party solutions to meet their fax requirements. One such company is Concord Fax from Concord Technologies. Both incoming and outgoing fax services will need to be evaluated.
5. Exchange Server 2010 no longer includes Storage Groups. Administrators can still work with the Storage Group concept in terms of a database, log files and a checkpoint file. But they are better known simply as a Database. It is similar to the Cluster Continuous Replication (CCR) in Exchange Server 2007 in that there is only one Database per Storage Group.
6. There were major reengineering efforts made to the Exchange Server 2010 database which affected the Single Instance Storage (SIS). As a result of those changes the Single Instance Storage (SIS) was removed. This change has affected the size of the Exchange Server database when emails and their attachments are sent. For example, a 1MB message sent to 200 recipients can result in the database growing by 200MBs. Administrators need to readjust their sizing calculations to bring their storage estimates up to date and in line with the new growth projections.
7. Client authentication using Integrated Windows authentication (NTLM) for POP3 and IMAP4 users has been impacted in Exchange Server 2010. NTLM is no longer supported for POP3 or IMAP4 client connectivity. The recommended POP3 and IMAP4 setting alternatives to NTLM are:  Kerberos (GSSAPI) and Plain Text Authentication with SSL. If NTLM is used then connections from POP3 or IMAP4 client programs to Exchange 2010 will fail. Administrators who need the NTLM capability can still use an Exchange 2003 or Exchange 2007 server in their environment.
8. Architectural changes include:

• Routing groups – Exchange Server 2010 uses Active Directory site-based routing.
• Administrative groups – Exchange Server 2010 uses the Exchange 2007 split permissions model that’s based on universal security groups.
• Intelligent Message Filter – Exchange Server 2010 uses anti-spam agents in the Hub Transport and Edge Transport server roles.
• Link state routing – Exchange Server 2010 uses Active Directory site-based routing.
• Routing objects – If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.
• Network-attached storage – Exchange Server 2010 supports Internet SCSI (iSCSI).
• Exchange Installable File System (ExIFS) – Use Exchange Web Services or MAPI.
• Event service – If you need this functionality, retain an Exchange 2003 server in your Exchange 2010 organization.
• Recovery storage group – Exchange 2010 uses the recovery database.
• User Datagram Protocol (UDP) – Support for User Datagram Protocol (UDP) notifications is removed from Exchange Server 2010. This impacts the user experience when Outlook 2003 clients connect to their mailboxes on Exchange 2010 server. In Outlook 2003, users will experience long send and receive times if they are connected to an Exchange Server 2010 mailbox.

8 Unavailable Exchange Server 2010 Features and Changes

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

In his blog, Aaron Tiensivu discusses one of the new features of Exchange Server 2010, that of “Speech to Text”. 

As everyone knows, this is a feature whereby a caller’s voicemail message is left through an answering service and then it is converted into text. In this case, Exchange Server 2010 now provides the capability to send that converted voice mail message into an email message.

In Exchange Server 2007, Microsoft introduced voice mail as part of their new Unified Messaging methodology. Unified Messaging gave the end users the capability to have all their communications, be it voice mail or email, all come into the end users inbox to be managed from one location. Now with Exchange Server 2010, Microsoft extended that capability to include a text transcription of any voice mail message.

This ability to be able to read a text transcription in addition to being able to listen to voice mail can help a user to determine if they have heard the voice mail correctly. This can be very helpful when a caller has left their own phone number or an important address and time for a meeting on their voice mail message. I know that there are many times I have had to listen to a voice mail message a couple time straining my ears to verify that I have heard some important unintelligible detail of the message. Sometimes it has been frustrating to the point that I need to contact the caller just to verify the initial communication.

Aaron mentions that he utilizes Office Communications Server and uses it as his primary number. All in all, Aaron has three phone numbers – his OCS phone number, his local office phone number and his work cell phone number. Each of those three numbers is associated with their own voice mailbox that must be managed.

One of the considerations left out by Aaron regarding the speech to text transcription feature is that of how much processor utilization is needed. When deploying the speech to text transcription service within your company administrators should first try to determine how much processor capacity could potentially be consumed for this capability.

As a first cut, rough draft guesstimate, an administrator can start off by identifying what variables should be used to guesstimate total processor needs.  Here are some of the most likely variables for the computation:

1. Total number of users.
2. Average number of hours of utilization.
3. Average number of voice mails per utilization period.
4. Average time duration of each voice mail message.

For example, here are some numbers for a possible calculation:

U = 2000 users
H = 10 hours of utilization
V = 10 voice mails (assume each user gets 10 calls per 10-hour day)
T = 1 minute of voice mail duration

Using these numbers we can guesstimate how many minutes of voice mail per day will need to be transcribed as follows:

Total transcription minutes = U x H x V x T

So we end up with the following calculation:

Total transcription minutes (TTM) = 2000 x 10 x 10 x 1 (minute)
TTM = 20000 x 10
TTM = 200000 minutes of voice mail needing transcription per day
TTM = 200000 divide by 60 minutes
TTM = 3333 hours

That’s a lot of hours, far too many than are available in one day. Luckily it does not take that long to transcribe one minute of voice mail. If we assume it takes one second of clock time to transcribe 1000 minutes of voice mail then our calculation becomes:

Total clock seconds needed for transcription = 200000 divide by 1000
Total Clock Seconds = 200 seconds

Further evaluation leads to:
Total Clock Hours = 200 divide by 60 seconds
Total Clock Hours = 3.33 hours

What all these calculations are intended to do is to help administrators size their systems accordingly. If the email servers have been deployed in virtual environments then these calculations can help to estimate the number of and granularity of virtual processors. They can also be used to guesstimate how much memory should be allocated for speech to text transcription by performing similar calculations for memory usage. Of course there are other factors to consider such as the speed of the processors.

And if we circle back to Aaron Tiensivu’s blog post, specifically his mention of using three mailboxes for three phone numbers then you could add in another factor representing average number of phone number mailboxes per user.

In summary, I agree with Aaron that the speech to text feature can be very beneficial to end users. I would add that with each new feature introduced into a company’s data center it must be weighed against the costs – both tangible and intangible – of each new capability.

Using the Email Transcription Service in Exchange Server 2007

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

Back in Part 2 of this series I demonstrated how to backup the Exchange Server 2007 Mailbox Server role, and then how to use that backup to restore an entire mailbox database in the event of a disaster.  In this part of the series I will demonstrate how to use that same backup to recover individual mailbox items.

Mailbox Item Recovery for Exchange Server 2007

The backup utility that is provided with Windows Server 2003 is capable of backing up and restoring entire mailbox databases for Exchange Server 2007.  However it is not natively capable of restoring an individual mailbox item (such as a single email) should the need arise.

Some third party Exchange backup products do provide this functionality however this comes at a cost.  Fortunately all they are doing is providing a simple interface for a built-in feature of Exchange Server 2007 to perform the restore.

For businesses on a budget or anyone who simply chooses to use the built-in backup utility for backing up their Exchange servers you can still recover individual items thanks to Recovery Storage Groups.

What is a Recovery Storage Group?

A Recovery Storage Group is an Exchange Server 2007 feature that allows the administrator to create an “invisible” storage group that can be used to restore a mailbox database and extract data from it without affecting the production database that is being accessed by end users.

The Recovery Storage Group is only used for restore and recovery operations.  It is never connected to by an end user using Outlook or other mail protocols, and the mailboxes contained within it are not associated with any Active Directory user accounts.

Restoring Mailbox Items using the Recovery Storage Group

In this example the user “John Smith” has deleted an email from the inbox that was received last week.  The Mailbox server is backed up every night and so the email administrator knows that the item is likely contained within one of the previous nights’ backups.To begin the recovery process launch Database Recovery Management from the Toolbox of the Exchange Management Console.

Fill out the activity name, server name, and domain controller name and click Next to continue.

From the list of tasks choose “Create a recovery storage group”.

Link the Recovery Storage Group to the same storage group as the mailbox you intend to recover data from, and click Next to continue.

Give the Recovery Storage Group a name (the default name is fine) and modify the other settings if you wish.  The Recovery Storage Group does not need to be located on the same drive as the storage group or mailbox database you are recovering, but once it is created it cannot be moved so make sure you choose a location with enough free disk space to hold a copy of the mailbox database.

When this has completed go back to the task center and click on “Set up ‘Database can be overwritten by restore’ flag”.  Choose the mailbox database for the Recovery Storage Group and complete the task.

Now that the Recovery Storage Group has been created a restore operation from the Windows Server 2003 backup utility will recover data to the Recovery Storage Group rather than to the production database.

Once the restore has been performed click on “Mount or dismount databases in the recovery storage group”.  Select the mailbox database and click on “Mount selected database”.

Return to the task center.  Now we can begin to extract mailbox data from the Recovery Storage Group.  Click on “Merge or copy mailbox contents”.  The mounted database within the Recovery Storage Group will be selected.  Click on “Gather merge information”.

Click on “Show Advanced Options” and set the start data and finish date to the date range that you wish to recover mailbox items from.

Click on “Perform pre-merge tasks”.  A list of available mailboxes will be displayed.  Make sure you have only selected the mailbox that you wish to recover items for, then click on “Perform merge actions”.

When the merge has completed the items will be visible in the end user’s mailbox without them needing to restart Outlook.

After the mailbox item recovery is complete we need to remove the Recovery Storage Group from the server.  In the task center click on “Mount or dismount databases in the recovery storage group” and dismount the recovery mailbox database.  Return to the task center once more, click on “Remove the recovery storage group” and follow the steps to complete the task.

Exchange Server 2007 Backup and Recovery Part 5 – Recovering Individual Mailbox Items

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

In Part 1 of this series I discussed backup and recovery for each of the Exchange Server 2007 server roles and associated systems such as Active Directory.  In Part 2 I then described the process of backing up and recovering a Mailbox Server from the loss of a mailbox database.  In this part of the series I will demonstrate backup and recovery of the Hub Transport Server and Edge Transport Server roles.

Backing up Transport Servers

Unlike Mailbox Servers, the Hub Transport and Edge Transport roles do not require any special Exchange-aware backup software.  All of the necessary data for recovering a Transport server is contained within:

• Active Directory (for Hub Transport servers, but not Edge Transport servers)
• The Active Directory Application Mode (ADAM) database (for Edge Transport servers)
• The server’s file system
• The server’s System State

Hub Transport servers can be backed up using the built in Backup utility in Windows Server.  At the very least the backup should include the System State and the C:\Program Files\Microsoft\Exchange Server\TransportRoles location of the file system (and all sub directories).

Edge Transport servers are backed up in the same way as Hub Transport servers except for the Exchange Server configuration.  Because this is stored in ADAM it must first be cloned using the Export-EdgeConfig.ps1 script located in C:\Program Files\Microsoft\Exchange Server\Scripts.  Execute the script with the name of the file you wish to export to. Note this is a single command run on one line in the Exchange Management Shell.

export-edgeconfig.ps1 c:\edgeconfig.xml
 -key "abcdefghijklmnop"

It is recommended to either include this config file in your Edge Transport backups or use a path that is a shared folder on a remote server.

Recovering Hub Transport Servers

In this scenario the EXCHHUB server has been lost due to hardware failure.  Spare server hardware has been used to reinstall Windows Server 2003 along with the Exchange Server 2007 pre-requisites.  The newly built server has the same name and IP address of EXCHHUB.  Now we can begin the recovery of the Hub Transport server.
First, remove any Edge Subscriptions that existed for the Hub Transport server being recovered.  If you skip this step you may receive a certificate error during the recovery install.

In a command prompt run the following command from the location of the Exchange setup files.

setup /m:RecoverServer /DoNotStartTransport

This runs setup in recovery mode along with an additional instruction to not start the Transport services straight away.  This is so we can restore our mail queue databases and log files from the most recent backup before the server is put back into operation.

Recovering Edge Transport Servers

In this scenario the EXCHEDGE server has been lost due to hardware failure.  As with the Hub Transport server a new server and operating system has been installed with the same name and IP address.

To recover the Edge Transport server we will use the ImportEdgeConfig.ps1 script that ships with Exchange Server 2007.  First we run the script against the exported Edge config file from earlier to validate its contents. Note, this command is all one line.

ImportEdgeConfig.ps1 -cloneConfigData c:\edgeconfig.xml
 -isImport $false -CloneConfigAnswer c:\configanswer.xml
 -key "abcdefghijklmnop"

Validation succeeded for ConnectivityLogPath element of
 type DirectoryPath
Validation succeeded for MessageTrackingLogPath element of
 type DirectoryPath
Validation succeeded for PickupDirectoryPath element of
 type DirectoryPath
Validation succeeded for PipelineTracingPath element of
 type DirectoryPath
Validation succeeded for ReceiveProtocolLogPath element
 of type DirectoryPath
Validation succeeded for ReplayDirectoryPath element of
 type DirectoryPath
Validation succeeded for RoutingTableLogPath element of
 type DirectoryPath
Validation succeeded for RootDropDirectoryPath element of
 type NullableDirectoryPath
Validation succeeded for SendProtocolLogPath element of
 type DirectoryPath
Validation succeeded for SourceIPAddress element of
 type IPAddress
Validation succeeded for SourceIPAddress element of
 type IPAddress
Validation succeeded for Bindings element of type Bindings
Validation succeeded for Fqdn element of type FQDN
Answer File is successfully created: c:\configanswer.xml

Note that the key is the same one used when the Edge config was exported earlier.  If any validation steps were unsuccessful open the answer file in a text editor and adjust the settings that it lists as invalid.

Once the config has been validated it can be imported with the same command but modifying the -isImport parameter to $true. Note again this is a single command.

ImportEdgeConfig.ps1 -cloneConfigData c:\edgeconfig.xml
 -isImport $true -cloneConfigAnswer C:\configanswer.xml
 -key "abcdefghijklmnop"

Importing Edge configuration information Succeeded.

Now that the Edge Transport server configuration has been restored you can re-create the Edge subscription between the Edge Transport and Hub Transport servers.

How to Back Up and Restore Client Access Servers

In the final part of this series I will demonstrate the process of backing up Client Access servers and then recovering them from failure.

Exchange Server 2007 Backup and Recovery Part 3 – Transport Servers

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

In Part 1 of this series I explored what needs to be backed up for each of the different Exchange Server 2007 server roles.  In this post I will demonstrate a Mailbox Server failure and the recovery of the mailbox database from backup.

Backing up the Databases

The first thing we’ll need is a backup of the databases on the Mailbox Server.  For this demonstration I am using the built in NTBackup program for Windows Server 2003 to back up both of the storage groups for the server.

Mailbox Server Failure

The next step is to cause a server failure.  In the real world a potential point of failure for Mailbox Servers is the storage.  Typically databases will be located on SAN volumes, and a storage failure will cause the database to go offline.  To simulate this I simply remove the database file from its path on the test server.

Restoring the Database

Before beginning the database restore operation we must first prepare the database for recovery.  To do this open the properties of the Mailbox Database and tick the “This database can be overwritten by a restore” check box.

Using the NTBackup program we can now commence the restore of the Storage Group containing the Mailbox Database.

Mailbox Database restores will not automatically initiate a transaction log replay and then mount the database unless we specifically choose to.  This is for situations where the restore will involve a “full” backup set followed by a “differential” backup set, or followed by one or more “incremental” backup sets.  In this case we are only restoring a full backup set, so we can enable the “Last Restore Set” and “Mount Database after Restore” settings.  We must also specify a temporary path for log and patch files.

Once the restore operation is complete we can see that the Mailbox Database is now mounted and online again.

What Just Happened?

When the last restore set has been restored to the server it begins rebuilding the database using the recovered database and transaction log files from the backup set.  These transaction logs are replayed from the temporary location specified during the restore operation.  This achieves the outcome of restoring the database as at the time the backup was taken.  In the real world this would typically mean the previous night.  So what about all of the email that has been sent and received since then?

Again, in the real world Exchange Mailbox Server storage uses SAN volumes, or at the very least a disk layout that uses separate storage for the database and transaction logs.  This improves recoverability by ensuring that a failure of a single disk volume only causes the loss of the database or the transaction log, and not both at the same time.

In this demonstration that means that the transaction logs that have been generated by all of the current day’s email activity are still intact.  When the restore operation finishes with the data that came off the backup set it then begins to reply the transaction logs that still reside on the Exchange Mailbox Server.

This operation brings the database completely backed up to the current point in time, fully recovering all email items that were contained in it prior to the database failure.  Once this log replay operation is complete the database is mounted and made available to email users again.

How to Back Up and Restore Transport Servers

In the next part of this series I will demonstrate the process of backing up Hub Transport and Edge Transport servers and then recovering them from a failure.

Exchange Server 2007 Backup and Recovery Part 2 – Mailbox Servers

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

One of the least exciting yet most important parts of an Exchange administrator’s job is making sure that the Exchange Server environment is properly backed up.  Throughout my career I’ve spent many long nights with customers who have suffered a failure of an Exchange server and discovered that their backups are unreliable or even non-existent.  In this series I will discuss Exchange Server 2007 backup and recovery and demonstrate some actual disaster recovery scenarios that I have encountered on the job.

What to Back Up on Exchange Server 2007

To understand what to back up in an Exchange Server 2007 environment you must first consider the server roles that you have deployed.  In the most basic Exchange Server 2007 deployment the Client Access, Hub Transport, and Mailbox server roles are installed.  In more complex environments more than one of each of those roles might be deployed, the Mailbox server might also be clustered for high availability, and other roles such as Edge Transport and Unified Messaging might also be in use.

In addition to the Exchange server roles there are also considerations such as the Active Directory (a pre-requisite of any Exchange environment), client data such as PST files or POP3 mailboxes, and any server-based anti-spam system that is deployed.

All Exchange Servers

Generally speaking all Exchange servers in an organisation should have their local file systems and System State data backed up.  However because Exchange Server 2007 stores much of its configuration in Active Directory you can recover some server roles without needing to have backed up any data at all.

For example, if a Hub Transport server crashes and is unrecoverable the Exchange administrators can build a new server of the same name, and then install Exchange Server 2007 on it with the /m:recoverserver setup parameter.  This tells the installation to use the configuration stored in Active Directory for the server being rebuilt.

Despite this feature there are still several items to be aware of for Exchange Server 2007 backups.

Mailbox Servers

The most obvious role that an organisation will backup is the Mailbox server role.  As the name suggests this role hosts all of the mailbox databases and public folder databases.  Because of the database format in use, backups must be performed using an Exchange-aware backup product.  These products can use one of two different methods to backup the database.

Streaming Backup – this backup “streams” data directly from the live database page by page.  The built-in Backup utility for Windows Server 2003 performs this type of backup of Exchange.  Remote streaming backups are disabled by default in Exchange Server 2007 Service Pack 1 but can be re-enabled with a registry change.

Shadow Backup – a VSS shadow copy (or snapshot) of the database is made so that a “point in time” backup can be performed.  Most third party backup products perform this type of Exchange backup.

For Mailbox servers with database replication enabled (either Local Continuous Replication, or Cluster Continuous Replication) an Exchange-aware backup product can usually perform its backups using the “passive” copy of each database.  This is an advantage in many environments because the entire backup I/O load is kept off the active database, preventing any performance impact on end users.  This makes it possible to perform backups during business hours, which is important to some organisations.

Hub Transport Servers

Although most of the Hub Transport configuration is stored in Active Directory the local file system still contains important data such as the message queues, log files, and some configuration files that are often modified by administrators for performance tuning.

By including the C:\Program Files\Microsoft\Exchange Server\TransportRoles folder (and all sub-folders) in the backups you provide some protection from failure, however the queues and logs change on a minute by minute basis so unless you run multiple backups through the day the recovery benefits are minor.  Additionally, these files are often locked and in use at all times so the backup must be performed by a product that can handle locked files correctly.

Client Access Servers

Most of the important configuration information for Client Access servers is not stored in Active Directory, but rather is located on the local file system of the server and also the IIS metabase.  The IIS metabase in particular contains vital information such as customised settings on the Exchange virtual directories.

To backup these important items you should include the C:\Program Files\Microsoft\Exchange\ClientAccess folder and the System State of the server in your backups.

Edge Transport Servers

Edge Transport servers are not members of any Active Directory domain, so cannot be restored using /m:recoverserver.  Instead their configuration must be exported using the ExportEdgeConfig.ps1 PowerShell script, and the export file then backed up elsewhere.

In addition, the message queues and log files should be backed up in the same manner as with Hub Transport servers.

Unified Messaging Servers

Most of the configuration for Unified Messaging servers is stored in Active Directory, but as with other server roles some customisations are only stored on the local file system of the server.  The C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging folder should be included in backups.

Active Directory

Exchange Server 2007 relies on Active Directory and uses it to store most of its server configuration information.  The Active Directory database is backed up by including the System State of one or more Domain Controllers in backups.

Client Data

Although organisations are moving away from the use of PST files for email storage some still persist in using them.  PST files can be difficult to back up because the Outlook client will lock them “in use” and prevent some backup software from successfully backing them up.  Furthermore, if the PST file is stored on an end user machine it probably will not be included in server backups.

I have seen this dealt with in several ways, such as storing PST files on a file server share and using backup software that can handle locked files.  In many organisations though they simply consider PST files as being excluded from backups and accept any data loss that may occur from them.

POP3 clients are fairly rare in Exchange Server 2007 environments but the simplest approach with these is to configure the POP3 client to leave copies of mail items on the server so that the Mailbox Server backups can protect them.

Other Messaging Systems

To ensure that the entire messaging environment is backed up you should also consider any other non-Exchange servers that are involved, such as an anti-spam server.  In most cases this will mean backing up the file system of the anti-spam server, as well as any SQL databases it uses for storing quarantined items and reporting data.

How to Backup and Restore a Mailbox Server

In the next part of this series I will walk through the process of backing up a Mailbox server, simulating a failure, and then performing a recovery of the server and its databases.

Exchange Server 2007 Backup and Recovery Part 1 – What Needs to be Backed Up?

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

In part 1 of this series I introduced Exchange Server 2007 Resource Mailboxes and demonstrated how to create Room Mailboxes.  In part 2 of this series I went on to demonstrate how to create Equipment Mailboxes.  Now in part 3 of this series I’ll demonstrate creating custom resource properties for Resource Mailboxes.

What are Custom Resource Properties?

Custom resource properties are additional attributes that can be assigned to Room and Equipment mailboxes to indicate which features are available for those resources.

For example, in an organisation that has several meeting rooms with different features, custom resource properties can be used to show which room has teleconferencing equipment, which one has a whiteboard, which one has tea and coffee facilities, etc.

Similarly for Equipment mailboxes custom resource properties can indicate features such as which vehicles have a GPS installed, or what kind of vehicle (such as truck, van, car) it is.

Extending the Resource Property Schema

By default in an Exchange Server 2007 there is no custom resource properties defined.

[PS] C:\>Get-ResourceConfig

Name                      ResourcePropertySchema
----                      ----------------------
Resource Schema           {}

Resource properties can be defined using the Set-ResourceConfig cmdlet in the Exchange Management Shell.

In this example I define a custom resource property to indicate that a Room Mailbox contains a projector.  The change is immediately applied and will appear when running the Get-ResourceConfig cmdlet again.

[PS] C:\>Set-ResourceConfig -ResourcePropertySchema
 Room/Projector

[PS] C:\>Get-ResourceConfig

Name                      ResourcePropertySchema
----                      ----------------------
Resource Schema           {Room/Projector}

Schema changes made by the Set-ResourceConfig cmdlet overwrite existing settings instead of adding to them.  For example if I run another command to add a whiteboard property the earlier property of “projector” is overwritten.

[PS] C:\>Set-ResourceConfig -ResourcePropertySchema
 Room/Whiteboard

[PS] C:\>Get-ResourceConfig

Name                      ResourcePropertySchema
----                      ----------------------
Resource Schema           {Room/Whiteboard}

To prevent existing properties being overwritten with new updates you must first read the existing configuration into an array.

[PS] C:\>$ResourceConfig = Get-ResourceConfig

[PS] C:\>$ResourceConfig

Name                      ResourcePropertySchema
----                      ----------------------
Resource Schema           {Room/Whiteboard}

Make modifications to the array using PowerShell commands.  For example, to add an additional feature of “whiteboard” to the schema:

[PS] C:\>$ResourceConfig.ResourcePropertySchema.Add
 ("Room/Projector")

Apply the changes to the resource property schema.

[PS] C:\>Set-ResourceConfig -Instance $ResourceConfig

[PS] C:\>Get-ResourceConfig

Name                      ResourcePropertySchema
----                      ----------------------
Resource Schema           {Room/Projector, Room/
Whiteboard}

Note that the Get-ResourceConfig cmdlet now shows both the existing and newly added properties.

You can use the same method to add multiple new entries.

[PS] C:\>$ResourceConfig = Get-ResourceConfig

[PS] C:\>$ResourceConfig.ResourcePropertySchema.Add
 ("Room/Teleconference")
[PS] C:\>$ResourceConfig.ResourcePropertySchema.Add
 ("Room/TeaCoffee")
[PS] C:\>$ResourceConfig.ResourcePropertySchema.Add
 ("Equipment/Van")
[PS] C:\>$ResourceConfig.ResourcePropertySchema.Add
 ("Equipment/Car")
[PS] C:\>$ResourceConfig.ResourcePropertySchema.Add
 ("Equipment/GPS")

[PS] C:\>Set-ResourceConfig -Instance $ResourceConfig
[PS] C:\>Get-ResourceConfig | fl ResourcePropertySchema

ResourcePropertySchema : {Equipment/GPS, Equipment/Car
, Equipment/Van, Room/TeaCoffee, Room/Teleconference,
 Room/Projector, Room/Whiteboard}

Custom properties can also be removed from the resource schema using a similar method.  For example, to remove the “TeaCoffee” feature from the schema:

[PS] C:\>$ResourceConfig = Get-ResourceConfig

[PS] C:\>$ResourceConfig.ResourcePropertySchema.Remove
 ("Room/TeaCoffee")
True
[PS] C:\>Set-ResourceConfig -Instance $ResourceConfig
[PS] C:\>Get-ResourceConfig | fl ResourcePropertySchema

ResourcePropertySchema : {Equipment/GPS, Equipment/Car,
 Equipment/Van, Room/Teleconference, Room/Projector,
 Room/Whiteboard}

Applying Changes to Resource Mailboxes

Custom resource properties can be added to mailboxes via the Resource Information tab in the mailbox properties.

Click on the Add button, choose the custom property you wish to add, and then click OK.

Click on OK again to apply the change to the mailbox

The custom property is now visible to end users in Outlook when choosing the room for a meeting request.

Exchange Server 2007 Resource Mailboxes Part 3 – Custom Resource Properties

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